Применение подхода для оптимизации бизнес-процессов

Содержание:

ВВЕДЕНИЕ

Процессным подходом считается систематическая идентификация и управление задействованных в организации процессов и особенно их взаимосвязей.

Процессом является любой вид деятельности или набор видов деятельности, в которых используются ресурсы для того, чтобы преобразовать входы в выходы.

Процессная модель предприятия состоит из множества бизнес-процессов, участниками которых являются структурные подразделения и должностные лица организационной структуры предприятия.

Процессно-ориентированные организации стараются устранять барьеры и задержки, возникающие на стыке двух различных подразделений организации при выполнении одного бизнес-процесса.

Под бизнес-процессом понимают совокупность различных видов деятельности, которые вместе создают результат, имеющий ценность для самой организации, потребителя, клиента или заказчика.

Актуальность исследования заключается в том, что из существующих подходов к проектированию информационных систем процессный подход в настоящее время считается наиболее эффективным поскольку оперирует абстракциями реальных объектов и операций.

Целью данной работы является освещение основных теоретических аспектов процессного подхода при проектировании информационной системы.

Предмет исследования – история развития и современное состояние процессного подхода.

Объект – средства проектирования.

1. Процессный подход к управлению

Теория систем рассматривает процесс как изменение системы. Действительно, любая деятельность — это действия, направленные на достижение результата, который выражается в том, что система обретает новое состояние.

С процессами мы сталкиваемся в разработке, технике, химии и даже социологии. Однако каждый из нас ежедневно является участником рабочих процессов.

Как показывает опыт, нередко руководители компаний избегают автоматизации и формализации процессов, им это кажется не совсем демократичным «закручиванием гаек».

Грамотное построение и управление процессами в компании любого профиля помогает обеспечить адекватное взаимодействие сотрудников, обусловленное ответственностью и вниманием к срокам.

Процессный лежит в основе множества модных теорий управления разработкой, компанией, персоналом.

Теория процессов определяет процесс как модель поведения, которое заключается в исполнении действий. Как правило, процесс не знает о деталях реализации каждого из действий (поведения системы, которой он принадлежит). [2, c.182]

Например, в процессе согласования документа в компании заложены сроки и порядок согласования, но процессу всё равно, с какого устройства и в какой географической точке будет согласован документ.

Ещё одно важное свойство процесса — это его управляемость, способность подвергаться изменениям извне.

Вообще, говоря о CRM и ERP, все привыкли слышать понятие «бизнес-процесс» и часто дискуссии сводятся к тому, чем отличается бизнес-процесс от процесса. Есть версия, что термин является калькой с англоязычного «business process» (деловой процесс) и составное слово бизнес- не несёт никакой нагрузки, кроме выделения процессов, проходящих в компаниях, из многочисленных процессов (технических, химических, биологических и проч). Собственно, с этой версией легко согласиться, вспомнив, как, например, судебный процесс называют просто процессом, откинув признак.

Процесс — это совокупность повторяемых во времени с заданной периодичностью действий, имеющих точку старта и точку достижения результата, целью которого является создание ценности для внутренних и внешних клиентов.

Бизнес — это экономическая деятельность, направленная на получение прибыли от производства и продажи товаров, оказания услуг и работ. Но ведь не каждый процесс приносит прибыль (исследовательский, благотворительный, оказания помощи социальным учреждениям). Да, есть результат (удовлетворение потребности), но не прибыль. Значит, в системе описываются не только бизнес-процессы.

Исследовательский процесс нацелен на поиск источников и обсуждение. Результат такого процесса заранее не определён, но по достижении ложится в основу стратегии. То есть это фактически концепция. Например, компания-разработчик (вендор) начинает искать идеи для новых фич и решений для рынка: проводятся кабинетные исследования, опросы, собирается информация, начинаются совещания и мозговые штурмы.

Никто заранее не знает, что команда решит включить в новый релиз. Однако в конце исследовательского процесса появляется концепция конкретной разработки — это одновременно точка входа проектного процесса. [7, c.110]

Проектный процесс — это организация работ в соответствие с сетевым планом-графиком (как вариации, это диаграмма Ганта, Scrum-доска и т.д.). На этом этапе рассчитываются KPI, человеко-часы, учитывается суммарная работа. Результат определён — это продукт. В случае сдвига срока одной из подзадач сдвигаются сроки всего проекта.

Производственный процесс — это своеобразное ветвление после исследовательского. Он может исполняться наряду с проектным или вне него. Он включает в себя бизнес-процессы с заданными маршрутами. Это больше «конвейерная» модель. 

Например, при разработке каждой новой функциональности или продукта проходит стандартное тестирование: регрессионное, функциональное, нагрузочное и юзабилити. Это, скорее, производственный процесс.

Информационный процесс — процесс, параллельный трём предыдущим. Это работа с документами, согласования, оповещение персонала и проч. Он обслуживает все этапы создания блага.

Эти процессы присутствуют в любой организации и требуют ресурсов и управления. Они могут быть последовательными, параллельными, иметь точки пересечения. Важно отладить процессы в компании, чтобы достичь несколько важных целей:

• увеличение точности и скорости исполнения рутинных задач за счёт автоматизации и системы напоминаний
• рост ответственности на каждом этапе и минимизация человеческого фактора за счёт обозначения владельцев процесса, исполнителей и прозрачности контроля за ходом исполнения процесса
• предсказуемость конечного результата за счёт накопления базы знаний и управления ресурсами внутри проекта
• непрерывный контроль качества и создание улучшений за счёт непрерывной оптимизации процессов и их разделения
• вовлечённость всех элементов инфраструктуры и всех сотрудников за счёт грамотного планирования на основе результат предыдущих результатов.

В конечном итоге, управление процессами снижает себестоимость конечного продукта, даёт экономию на высвобождении и перераспределении ресурсов, делает работу компании прозрачной, но сохраняет гибкость — всегда можно внести изменения в процесс.

В стандартах сертификации системы качества ИСО 9000 одним из важнейших составляющих достижения качества является принцип процессного подхода к выполнению любых работ. Вот, что значится в стандарте ГОСТ Р ИСО 9001-2008:

«Настоящий стандарт отстаивает применение принципа «процессного подхода» при разработке, внедрении и улучшении результативности системы менеджмента качества с целью повышения удовлетворенности потребителей посредством выполнения их требований. [8, c.17]

Для успешного функционирования организация должна определить и осуществлять менеджмент многочисленных взаимосвязанных видов деятельности. Деятельность, использующая ресурсы и управляемая в целях преобразования входов в выходы, может рассматриваться как процесс.

Часто выход одного процесса образует непосредственно вход следующего. Применение в организации системы процессов наряду с их идентификацией и взаимодействием, а также менеджмент процессов, направленный на получение желаемого результата, могут быть определены как «процессный подход».

Преимущество процессного подхода состоит в непрерывности управления, которое он обеспечивает на стыке отдельных процессов в рамках их системы, а также при их комбинации и взаимодействии.

При применении в системе менеджмента качества такой подход подчеркивает важность:

a) понимания и выполнения требований;

b) необходимости рассмотрения процессов с точки зрения добавляемой ими ценности;

c) достижения запланированных результатов выполнения процессов и обеспечения их результативности;

d) постоянного улучшения процессов, основанного на объективном измерении.


 

Рис. 1 Система менеджмента качества

Приведенная на рисунке модель системы менеджмента качества, основанной на процессном подходе, иллюстрирует связи между процессами организации.

Эта модель показывает, что потребители играют существенную роль в установлении требований, рассматриваемых в качестве входов. Мониторинг удовлетворенности потребителей требует оценки информации о восприятии потребителями выполнения их требований. Приведенная на рисунке модель охватывает все основные требования настоящего стандарта, но не показывает процессы на детальном уровне.

Таким образом, стандарт рекомендует организации определить все основные виды деятельности и научиться управлять ими.

В свою очередь, деятельность, использующая ресурсы, имеющая цель и результат, уже рассматривается как процесс. Причём нередко результат одного процесса служит входной точкой другого.

Сам стандарт ГОСТ Р ИСО 9001:2008 обозначает значимыми видами деятельности компании планирование, руководство, анализ со стороны руководства, менеджмент ресурсов (в том числе персонала и инфраструктуры), управление процессами жизненного цикла продукции, проектирование и разработку, измерение, анализ и улучшение.

Учетные системы.

Большинство учетных систем – документо-ориентированные. В основе – формы внешних и внутренних документов (счета, акты и другие бумажные документы). По своей сути учетная система проста т.к. повторяет в электронном виде принятый на предприятии регламент документооборота.

Качественно разработанная учетная система автоматизирует рутинные действия по подготовке документов и отчетов, формализует взаимоотношения между подразделениями, путем создания документов фиксирует выполнение ключевых процессов и упрощает построение отчетов по результатам деятельности. [5, c.89]

Учетная система не меняет подходы к планированию деятельности, не позволяет управлять ресурсами и не прогнозирует результат. Формируемые отчеты содержат данные только документов т.к. других данных в системе попросту нет.

Процессные системы управления.

У процессных систем управления внутренняя структура сложнее. Внутри системы реализованы взаимосвязи между всеми сущностями – процессами, временем выполнения, ресурсами предприятия и контрагентов, географическим распределением ресурсов и их стоимостью и т.д.

Функции процессной системы значительно шире, чем учетной, при этом все функции учетной системы входят в процессную.

Рис. 2 Процессная система

В процессной системе учитывается продолжительность процессов, их последовательность и взаимосвязи между ними.

Процессные системы позволяют управлять разнородной деятельностью в рамках одного программного продукта. При этом используются разные карты процессов для разных видов деятельности, а не единые строгие шаблоны.

Формирование документов.

Любые внешние и внутренние документы – сопутствующий результат выполнения задачи или выход процесса. Нет необходимости печатать внутренние бумажные документы – заявки, требования, разнарядки. Управление происходит путем назначения процессов определенным сотрудникам.

Оперативные планы.

У каждого процесса есть дата начала и продолжительность. По этим данным подразделения формируют оперативные планы на любую будущую дату. Когда в карту процессов вносятся изменения – планы подразделений автоматически обновляются. Подразделение не тратит время на актуализацию.

Управление ресурсами.

Для каждой операции известно требуемое количество ресурсов – исполнительских, единиц техники, производственных мощностей и т.д. Учитываются собственные ресурсы, ресурсы поставщиков, клиентов и партнеров.

Процессная система предупреждает, когда не хватает ресурсов для выполнения запланированных процессов. Подразделения оперативно корректируют карту процессов или привлекают дополнительные ресурсы.

Построение прогнозов.

Прогнозы строятся на основе текущих и запланированных процессов. Взаимосвязь между отдельными процессами – в том числе процессами разных цепочек – позволяет получать оперативные прогнозы сроков, загрузки подразделений, распределения ресурсов, себестоимости и т.д.

Управление результатом.

Прогнозирование позволяет управлять результатом. В схему можно добавить новую операцию или отредактировать существующую. После чего – изучить изменившийся результат (например, себестоимость проекта). Если результат устраивает – изменения подтверждаются.

Гибкие отчеты.

Отчеты в процессной системе строятся по всем параметрам и условиям, которые присутствуют в процессах. Руководители подразделений выделяют ключевые показатели эффективности (KPI), отлеживают их в режиме реального времени и могут посмотреть отчетность по нужному показателю за любой прошлый период. [2, c.272]

Результат внедрения процессной системы – оптимизация процессов, повышение эффективности выполнения подразделениями своих задач, снижение издержек и повышение рентабельности предприятия.

Внедрение процессных систем.

Внедрение процессной системы начинается с моделирования процессов. За основу берется один из отраслевых процессных программных продуктов, в котором и происходит моделирование.

На реальных данных предприятия модель корректируется и дополняется, выявляются требования по доработке и адаптации. Конечный продукт учитывает особенности конкретного предприятия и полностью отражает его процессы.

2. Графическое описание бизнес-процессов

Графическое описание бизнес-процессов представляет собой разработку графических моделей. В некоторых организациях их называют диаграммами, схемами, технологическими картами, но суть от этого не меняется.

На графической модели отображается логика выполнения бизнес-процесса с помощью специальных фигур (объектов) и стрелок в соответствии с выбранной нотацией (стандартом). Перечислим самые распространенные нотации бизнес-моделирования.

• Basic Flow Chart и IDEF0.
• CFFC (Cross Functional Flow Chart. Кросс-функциональная модель, или «диаграмма дорожек»). По мнению многих экспертов, она наиболее проста для разработки и чтения. Данная нотация интуитивно понятна сотрудникам и имеет очень широкое распространение.

Но есть два недостатка: ограничение по количеству «дорожек» (субъектов — исполнителей бизнес-процесса) на листе А4, недостаточный набор фигур для отображения всех необходимых сущностей и атрибутов (например, отсутствие фигур «базы данных» и «программный продукт»).

Рис. 3. Нотация «Cross Functional Flow Chart» — модель процедуры «Оформление и выдача кредита»

• EPC (Event driven Process Chain. Цепочка процесса, управляемая событиями) . Содержит большой набор фигур для отображения всех основных сущностей и атрибутов на моделях бизнес-процессов. Имеет хорошую визуализацию и цветовое оформление.

Рис. 4. Нотация «EPC» — модель процедуры «Разработка / модификация продукта банка»

• BPMN (Business Process Model Notation. Модель и нотация бизнес-процесса). Является наиболее сложной и многофункциональной нотацией. Есть организации, которые полностью описывают все свои бизнес-процессы в BPMN и имеют более 200 моделей в формате А4 с постоянной актуализацией.

Рис. 5. Нотация «BPMN» — модель процедуры «Прием сотрудников на работу»

Разработку графических моделей необходимо выполнять с помощью программных продуктов бизнес-моделирования (например, Business Studio или Microsoft Visio).

Каждый программный продукт поддерживает разный набор нотаций. Подробное описание всех нотаций утверждается в документе «Соглашение по бизнес-моделированию».

Для бизнес-аналитиков (методологов) это единые договорённости по разработке, а для сотрудников организации — памятка по правильному чтению (интерпретации) графических моделей.

Форматы описания бизнес-процессов по их формализации.

Рассмотрим 3 основных формата.

1. Текстовый формат. Для сложных бизнес-процессов это обычно несколько текстовых регламентов с общим объёмом более 100 страниц А4. У этого формата есть немало минусов и недостатков, тем не менее, он является самым распространённым на сегодняшний день.
2. Табличный формат  — более формализованный (структурированный) и компактный. Бизнес-процесс представляется в виде таблицы со следующими столбцами: функции (действия), вход, источник входа, выход, потребитель выхода, требования к срокам, комментарии и др.
3. Графический формат. В России уже известны организации, которые имеют все свои процессные регламенты в графическом формате (т. е. они состоят только из моделей). Такая практика с каждым годом получает всё более широкое распространение – все организации, которые ориентированы на долгосрочное и эффективное ведение бизнеса в условиях конкурентной среды, перейдут к графическому описанию бизнес-процессов.

Однако следует отметить, что специализированные методики и правила (например, методику анализа финансового состояния клиента, правила юридической проверки клиента) не нужно описывать в виде моделей.

Это технически сделать очень сложно и нецелесообразно. Поэтому подобные методики следует применять в качестве текстовых приложений к графическим моделям бизнес-процессов.

Есть ещё и четвёртый формат, редко встречающийся в организациях, но запоминающийся.

Это описание бизнес-процесса в формате презентационных слайдов (например, MS Power Point), состоящих из «живых» картинок (Clipart), фотографий и текстовых пояснений. Данному формату нельзя придать юридическую силу (официально утвердить), но, как это ни странно, бизнес-процессы в течение многих лет работают на основе этого формата описания. Работают с ошибками, операционными рисками и проблемами, но руководители не понимают этого или не хотят менять подход.

Во многих организациях (особенно среднего и небольшого размера) бизнес-процессы, к сожалению, вообще не описаны. Нет ни моделей, ни регламентов, ни каких-либо официальных материалов. Есть только виртуальные знания и договорённости, которые находятся «в головах» сотрудников и руководителей организации.

Благодаря графическим моделям бизнес-процессов можно выполнить следующие практические задачи.

• Визуализировать (представить наглядно) логику бизнес-процесса. Например, для коллективного обсуждения и анализа.
• Быстро и точно выявить ошибки и операционные риски в бизнес-процессах. Также очень удобно на моделях отметить те места, в которых могут реализоваться операционные риски, и заранее принять необходимые меры.
• Найти «узкие места» и причины неэффективности в бизнес-процессе.
• Полноценно применить методы оптимизации, разработать модели «как надо» («TO-BE» или версию 2.0). Большое количество методов оптимизации основано на использовании графических моделей.
• Провести имитационное моделирование (Simulation) и функционально-стоимостный анализ (ФСА) бизнес-процесса с помощью программных продуктов бизнес-моделирования.
• Объяснить порядок выполнения бизнес-процесса сотрудникам, быстро вспомнить или понять основные моменты и детали. В некоторых организациях графические модели наиболее важных и сложных процедур постоянно находятся на рабочих столах сотрудников.
• Отследить все взаимосвязи с другими бизнес-процессами и объектами в компании, что особенно актуально для крупных и территориально разделённых организаций.
• Организовать качественный контроль бизнес-процесса (в том числе процедуры внутреннего аудита). Отметим, что в банках инициатором описания бизнес-процессов иногда выступает служба внутреннего контроля.
• Построить комплексную электронную бизнес-модель организации. Именно системный подход, т. е. разработка системы взаимосвязанных моделей по всем областям работы и управления в организации, позволяет добиться максимальных результатов.
• Обеспечить синхронизацию одинаковых объектов в разных бизнес-процессах. Например, если бизнес-аналитик изменил название должности (субъекта) в организационной структуре, то на моделях всех бизнес-процессов, в которых участвует данная должность (как исполнитель), должны автоматически измениться названия соответствующих фигур. При текстовом описании бизнес-процессов синхронизацию и актуализацию регламентов приходится выполнять вручную, поэтому при больших объёмах информации часто возникают неточности и даже противоречия.
• Автоматически сгенерировать текстовые и табличные регламенты с помощью программных продуктов бизнес-моделирования (например, Business Studio).

Таким образом, графические модели являются первичными по отношению к текстовым и табличным регламентам. Любое изменение модели влечёт автоматическое обновление регламентов, при этом экономится время. Остается только добавить, что выполнить перечисленные задачи на основе текстового или табличного описания бизнес-процессов технически очень сложно, либо это потребует очень больших ресурсов и трудозатрат.

3. Программные продукты с использованием процессного подхода

3.1 AllFusion Process Modeler (Bpwin) — ERwin Process Modeler

Создание современных информационных систем представляет собой сложнейшую задачу, решение которой требует применения специальных методик и инструментов. Неудивительно, что в последнее время среди системных аналитиков и разработчиков значительно вырос интерес к CASE-технологиям и инструментальным CASE-средствам, позволяющим максимально систематизировать и автоматизировать все этапы разработки программного обеспечения.

Рис.6 Интерфейс AllFusion Process Modeler (Bpwin)

Моделирование предметной области, как правило, выполняется с помощью CASE-средств. К таким средствам относятся BPwin (AllFusion Process Modeler), Oracle Designer (Oracle) и др.

При разработке или закупке программного обеспечения модели бизнес-процессов служат прекрасным средством документирования потребностей, помогая обеспечить высокую эффективность инвестиций в сферу IT. В руках же системных аналитиков и разработчиков BPwin — еще и мощное средство моделирования процессов при создании корпоративных информационных систем (КИС).

BPwin предоставляет средства для изучения операций и управления операциями на различных уровнях детализации. Например, иногда бывает важно сосредоточиться на определенной части бизнеса организации. BPwin позволяет вам разделить сложный процесс на множество управляемых частей, обеспечивая группам разработчиков модели возможность сосредоточиться на интересующих их аспектах. [5, c.128]

В итоге, эти различные аспекты могут быть согласованы и объединены, чтобы составить единый, целостный взгляд на ваше предприятие. BPwin позволяет вам объединить раздельные модели в единую согласованную модель и достигнуть согласования проекта. BPwin помогает вам понять общее влияние изменений на существующие бизнес-процессы, обеспечивая быструю и эффективную адаптацию.

BPwin поддерживает три методологии моделирования: функциональное моделирование (IDEF0) — верхнеуровневое; описание бизнес-процессов (IDEF3) — поток работ и диаграммы потоков данных (DFD). Чаще всего применяется для создания функциональной модели предметной области на начальных этапах проектирования информационной системы, а также для анализа существующей или проектируемой ИС.

Функциональная модель включает в себя:

• поименованные процессы, функции или задачи, которые должны выполняться в системе;
• взаимодействия этих процессов, функций, задач с внешним миром и между собой.

Функциональный блок — представляется в виде прямоугольника и олицетворяет собой некую конкретную функцию.

Будем разрабатывать модель компании, которая занимается разработкой сайтов. Слева входящая информация, справа выходящая информация. наверху находится управление (нормативные документы, документация, госты), внизу находится механизм (программа, люди и все такое).

Рис 7. Функциональный блок

IDEF0 требует, чтобы в диаграмме было не менее трех и не более шести блоков. Эти ограничения поддерживают сложность диаграмм и модели на уровне, доступном для чтения, понимания и использования.

Вход — объекты, используемые и преобразуемые работой для получения результата (выхода). Допускается, что работа может не иметь ни одной стрелки входа. Стрелка входа рисуется как входящая в левую грань работы.

Управление -.информация, управляющая действиями работы. Обычно управляющие стрелки несут информацию, которая указывает, что должна выполнять работа. Каждая работа должна иметь хотя бы одну стрелку управления, которая изображается как входящая в верхнюю грань работы.

Выход — объекты, в которые преобразуются входы. Каждая работа должна иметь хотя бы одну стрелку выхода, которая рисуется как исходящая из правой грани работы.

Механизм — ресурсы, выполняющие работу. Стрелка механизма рисуется как входящая в нижнюю грань работы. По усмотрению аналитика стрелки механизма могут не изображаться на модели.

Вызов — специальная стрелка, указывающая на другую модель работы. Стрелка вызова рисуется как исходящая из нижней части работы и используется для указания того, что некоторая работа выполняется за пределами моделируемой системы.

У нас имеется 4 верхнеуровневых бизнес процесса (Сбор требований, разработка, тестирование, запуск), так как наша разработка сайтов будет работать по итерационной модели жизненного цикла ПО, то вывод в прод не переходит в начало бизнес процесса.

Рис 8. Итерационная модель ЖЦ ПО

Рис 9. Бизнес процессы

Дерево нашей модели будет иметь примерно такой вид. Декомпозируем верхнеуровневые процессы на подпроцессы. В моем примере я декомпозировал бизнес процесс тестирование на подпроцессы. Интеграционное тестирование, модульное тестирование и документирование — bag report.

Рис 10. Дерево процессов

В левом углу квадрата представлены доступные центры затрат их можно определить с помощью кнопки Cost Center Editor или в библиотеке центров затрат.

Рис 11. Центры затрат

Определение стоимости нужно для метода расчета себестоимости по объему хозяйственной деятельности (ABC). В правом столбце можно ввести стоимость выполнения функции в соответствии с определенным центром затрат.

Ниже имеется два переключателя:

Override decompositions — не учитывать данные, введенные ниже по декомпозиции. Стоимость определяется вручную.

Compute from decompositions — вычислить на основе данных, введенных ниже по декомпозиции.

Поле Frequency — определяет кратность выполнения данной функции в цикле.

Поле Duration — определяет длительность выполнения функции.

Преимущества BPwin:

• Легко освоить
• Позволяет облегчить сертификацию на стандарт качества ISO9000
• Интегрирован с ERwin (для моделирования БД)
• Пример модели, построенной в Bpwin интегрирован со средством имитационного моделирования Arena. Имитационное моделирование — создание компьютерной модели системы (физической, технологической, финансовой и т. п.) и проведение на ней экспериментов с целью наблюдения/предсказания. Реальный эксперимент проводить дороже, а зачастую опасно или невозможно;
• Содержит собственный генератор отчётов;
• Позволяет эффективно манипулировать моделями — сливать и расщеплять их;
• Имеет широкий набор средств документирования моделей, проектов.

Интуитивно-понятный графический интерфейс, который быстро и легко осваивается, что позволяет сосредоточиться на анализе самой предметной области, не отвлекаясь на изучение инструментальных средств. Интерактивное выделение объектов обеспечивает постоянную визуальную обратную связь при построении модели. BРwin поддерживает ссылочную целостность, не допуская определения некорректных связей и гарантируя непротиворечивость отношений между объектами при моделировании.

3.2 ARIS

ARIS является одним из популярных и эффективных средств, применяемых для моделирования и анализа бизнес процессов.

Изначально ARIS (Architecture of Integrated Information System) позиционировался как CASE средство. В дальнейшем, акцент был сделан на моделировании процессов.

Сейчас он представляет собой платформу по управлению и улучшению бизнес процессов, состоящую из программных продуктов различного назначения. Девятая версия ARIS включает в себя более десятка продуктов.

В основе ARIS моделирования лежит методология, разработанная профессором Шеером (prof. Scheer A. –W.). Модель должна представлять процесс как единый, целостный элемент бизнес структуры организации. Для сохранения этой целостности процесс моделируется в нескольких аспектах.

Рис. 12 Интерфейс ARIS

В соответствии с методологией ARIS каждый процесс может быть рассмотрен в пяти аспектах:

• Организационный аспект – представляет собой совокупность организационных единиц, их взаимосвязей и соответствующих структур, участвующих в процессе;
• Информационный аспект  – отображает состав данных и информации, задействованной в процессе;
• Управляющий аспект – описывает взаимосвязь между моделями процессов различных типов;
• Функциональный аспект – содержит описаний функций, отдельных подфункций и их связей между собой, и с основными функциями.
• Продуктовый аспект – определяет состав продуктов и ресурсов процесса, а также их взаимосвязь между собой и с элементами других моделей.

Эти аспекты представляют архитектуру ARIS. Для описания процессов и построения моделей каждый из аспектов архитектуры ARIS содержит различные типы моделей. Модели позволяют представить широкий спектр процессов с точки зрения данных, функций, организационных единиц, ресурсов, материалов, включая взаимосвязи между ними. [9, c.78]

В рамках каждого из аспектов модель процесса может детализироваться по уровням. Уровни зависят от «близости» модели к формальным языкам программирования и создания информационных систем.

ARIS разделяет модели на три уровня детализации:

• Уровень формулировки требований. Этот уровень ближе к описанию проблем бизнеса, поэтому модели этого уровня относятся к смысловым моделям. На этом уровне описываются функции, задачи, документы, различные ресурсы и продукты, вовлеченные в бизнес процесс.
• Уровень спецификации проекта. На этом уровне ARIS модель представляет элементы связанные с информационными технологиями. Здесь осуществляется переход от понятий бизнес процессов к понятиям информационных систем. Модели этого уровня описывают пользовательские и модульные транзакции, которые выполняют элементы бизнес процесса.
• Уровень описания реализации. Этот уровень является самым близким к информационным системам. Модели этого уровня содержат описание аппаратных и программных компонентов.

Указанные выше аспекты и уровни моделирования в методологии ARIS представляют в виде следующей схемы.

Рис. 13 Уровни моделирования в методологии ARIS

Все модели и их описания, применяемые в ARIS , основываются на общем семантическом представлении, поэтому между различными моделями и их элементами может быть легко выстроена взаимосвязь.

Программные продукты ARIS представляют собой интегрированную среду, включающую в себя большое количество компонентов.

Эти компоненты обеспечивают возможности по моделированию и анализу процессов, разработки архитектуры информационной системы и ее интеграцию с системой автоматизации SAP R3, анализу и управлению данными и пр.

Девятая версия бизнес платформы ARIS включает в себя следующие компоненты:

• ARIS Architect & Designer. Этот компонент предназначен для статического моделирования процессов. Для моделирования применяются различные методы и нотации. Компонент включает в себя более 150 видов диаграмм, которые обеспечивают анализ и моделирование процессов во всех аспектах методологии ARIS.
• ARIS Business Strategy. Компонент является расширением для ARIS Architect & Designer. Он обеспечивает разработку и управление бизнес стратегией организации. За счет этого компонента можно смоделировать и провести анализ ценности процессов организации.
• ARIS Connect. Это средство, позволяющее вести коллективную работу над моделями. В данном компоненте реализована возможность удаленной работы с применением мобильных устройств. Работа строится по принципу социальной сети.
• ARIS Enterprise Architecture. Этот компонент также является расширением для ARIS Architect & Designer. Он позволяет проводить анализ и гармонизировать документацию предприятия с ИТ архитектурой.
• ARIS for ArchiMate. Является расширением для ARIS Design Server. Этот компонент позволяет создавать модели ИТ архитектуры с использованием стандартов ArchiMate и TOGAF.
• ARIS for DMS. Является расширением для ARIS Architect & Designer. Позволяет получить доступ и обмениваться данными между хранилищем (репозиторием) ARIS и системами управления документацией.
• ARIS for SAP Solutions. Данный компонент является расширением ARIS Architect & Designer и позволяет синхронизировать модели бизнес процессов со средой SAP R3.
• ARIS IT Inventory. Расширение для ARIS Architect & Designer, которое позволяет проводить инвентаризацию приложений, технологий и проектов.
• ARIS MashZone. Этот компонент позволяет создавать интерактивные контрольные панели для работы с различными видами данных.
• ARIS Process Governance. Расширение для ARIS Architect & Designer. С помощью него можно установить политики, роли и ответственность за управление бизнес процессами и включить эти политики в модели.
• ARIS Process Performance Manager. Этот компонент используется для мониторинга и анализа показателей процессов, таких как производительность, стоимость, качество.
• ARIS Publisher. Расширение для ARIS Architect & Designer. Оно позволяет обеспечить простой доступ сотрудникам к информации о процессах и ИТ архитектуре.
• ARIS Risk & Compliance Manager. Этот компонент применяется для управления рисками и включения системы управления рисками в модель процессов.
• ARIS Simulation. Применяется для динамического моделирования процессов. С помощью этого компонента можно осуществлять реинжиниринг, оптимизацию и анализ бизнес процессов, а также проводить ресурсное планирование. Компонент является расширением для ARIS Architect & Designer.
• ARIS UML Designer. С помощью этого компонента модели ARIS могут быть представлены в виде стандарта UML , что обеспечивает совместимость бизнес моделей и ИТ моделей.
• ARIS Viewer. Компонент, который позволяет просматривать всю информацию ARIS репозитория в ARIS Publisher, получать доступ к информации в ARIS IT Inventory и управлять задачами ARIS Process Governance через web-интерфейс.

Подробная информация по составу компонент ARIS и их возможностях размещена на сайте компании разработчика SOFTWARE AG.

ARIS платформа является удобным и эффективным средством моделирования бизнес процессов. Она обеспечивает поддержку работы, как бизнес аналитиков, так и специалистов ИТ, осуществляющих внедрение информационных систем. [1, c.98]

Среди множества преимуществ этой платформы можно выделить существенные для целей моделирования бизнес процессов:

• Хорошо развитый графический интерфейс. Пользователи могут создавать модели, используя систему графических символов. Есть возможность использовать web – интерфейс. Полноэкранный режим и система навигации позволяет представлять данные в удобном виде. Интерфейс можно конфигурировать под потребности пользователей.
• Поддержка мощного хранилища данных (репозитория). Хранилище данных ARIS содержит большое число элементов и описаний. При этом обеспечивается совместная работа пользователей с объектами хранилища данных.
• Интеграция с другими программными продуктами. ARIS позволяет импортировать модели процессов в программные продукты, поддерживающие стандартные интерфейсы, например, такие как X ML, XMI, WSDL, XSD, XPDL, CADM (DoDAF), BPEL, BPML Export , Visio, txt и Excel.
• Детализация моделей. В ARIS есть возможность детализировать модели и их компоненты, используя различные аспекты.
• Динамическое моделирование. За счет дополнительных средств можно осуществить дискретное выполнение действий процесса. ARIS предоставляет графические средства для контроля и анализа действий в моделях процессов.

3.3 Oracle Designer

Инструментарий Oracle Designer обеспечивает интегрированное решение для разработки приложений для сред Web и клиент/сервер масштаба предприятия. Oracle Designer участвует во всех фазах жизненного цикла разработки программного обеспечения - от бизнес-моделирования до внедрения. Подход, в основе которого лежит концепция репозитория, делает возможным использование любые или даже всех его компонент для быстрой разработки масштабируемых, кросс-платформных распределенных приложений.

Рис. 14 Интерфейс Oracle Designer

Известно, что задачи разработки выполняются более продуктивно и точно, если пользоваться инструментальными средствами, работающими на наглядном языке диаграмм.

К числу таких задач можно отнести определение, модификацию и понимание компонент системы и связей между ними. Диаграммы вместе с отчетами, утилитами и генераторами обеспечивают надежную интегрированную среду для проектирования систем. Набор инструментария для моделирования Oracle Designer обеспечивает богатый набор диаграмм для поддержки деятельности по проектированию и реализации проекта.

Гибкое бизнес-моделирование.

За счет предоставления инструментальных средств поддержки как объектно-ориентированных (OO) моделей моделирования, так и моделей типа "сущность-связь" (ER) Oracle обеспечивает гибкий метод бизнес-моделирования. Оба построителя диаграмм (diagrammers) поддерживают стандартные соглашения для соответствующих стилей моделирования: Унифицированный Язык Моделирования (Unified Modeling Language - UML) поддерживается разработчиком моделей (modeler) объектно-ориентированного типа, а моделирование ER - разработчиком моделей "сущность-связь".

Генерация для сред Web и клиент/сервер.

На основе определений, хранящихся в репозитории , генерируются приложения, которые затем развертываются в средах клиент/сервер или Web. Используя Oracle Developer , на основе определения модуля или даже целого приложения можно получить систему, которая развертывается в обеих средах, без изменения каких бы то ни было частей определения.

Реинжениринг проекта.

Проектирование серверной части.

Oracle Designer предоставляет возможности реинжиниринга и повторной генерации проекта серверной части как для баз данных Oracle, так и для других баз данных. Это позволяет провести миграцию баз данных из "наследуемых" систем напрямую в репозиторий Oracle Designer для генерации базы данных Oracle, способной полностью использовать преимущества надежного, масштабируемого сервера базы данных.

Проектирование приложений.

Аналогично, мы можем сделать реинжениринг проекта приложений, построенных на языке Visual Basic или Developer Reports и Forms Developer, включая логику приложения.

Циклическое (круговое) проектирование.

При условии, что приложение построено в Oracle Developer, используя возможность реинжениринга проекта, мы можем поместить определения проекта в репозиторий, внести в них требующиеся изменения и повторно сгенерировать приложение. Если в сгенерированное приложение с помощью Developer внесены какие-то изменения, например, добавлена дополнительная бизнес-логика в форме триггеров PL/SQL, они также могут быть определены и помещены в репозиторий, и их не придется переписывать в процессе дальнейшей генерации.

Эта способность изменять приложение вне рамок Oracle Designer, определять изменения и повторно генерировать (сохраняя изменения) известна под названием "циклическое проектирование" (Round-Trip Engineering) и является основным элементом продуктивной среды проектирования и разработки. [2, c. 88]

Если мы принимаем, что приложение изменяется в течение своего жизненного цикла, то способность поддерживать такое высокопродуктивное циклическое проектирование является одним из основных преимуществ использования Oracle Designer.

Средства управления репозиторием.

В Oracle Designer включены средства для управления содержимым репозитория и доступом к нему пользователя. Утилита Администрирования Репозитория (Repository Administration Utility) предназначена АБД репозитория.

Используя средства управления репозиторием, можно определить прикладные системы, которые распределяют объекты между многочисленными проектами. Кроме того, эти же средства используются, чтобы распространить определения на многочисленные системы приложений, тем самым способствуя многократному использованию объектов в средах разработки.

Средства выделения, загрузки и слияния данных репозитория поддерживают распределенную разработку, при которой могут использоваться многочисленные репозитории Oracle Designer. Определения из одного репозитория загружаются в другие и согласовываются, гарантируя, что разработчики, не имеющие возможности работать в команде, могут все-таки извлечь пользу из плодов работы других разработчиков.

Так же репозиторий служит опорой понятия "мобильная разработка". В рамках этого понятия аналитики или дизайнеры системы могут дистанционно (то есть, не покидая своих постоянных рабочих мест) работать с пользователями или клиентами, чтобы совместно определить требования, или прототипы, прежде чем вернуться к повторной загрузке новых определений проекта в центральный репозиторий.

Утилита Администрирования Репозитория обеспечивает очень эффективные, но, тем не менее простые в использовании характеристики, которые гарантируют, что полномасштабная разработка систем может проходить гладко, расширяя преимущества разработчиков, которые вместе трудятся в единой контролируемой среде.

Мощная база данных предварительных настроек и преобразователи проектов приложений.

Отталкиваясь от созданной модели связи сущностей (ER), преобразователь проектов БД (Database Design Transformer) может автоматически выполнить эскизный проект базы данных со всеми таблицами, столбцами, индексами, и ограничениями ссылочной целостности.

Аналогично, преобразователь проектов приложений (Application Design Transformer) использует информацию, содержащуюся в функциональной модели и модели потоков данных, и создает полные определения модулей для экранов, отчетов и меню, готовых для проверки и дополнительной работы по проектированию еще до этапа генерации программного кода.

Такой метод при проектировании создает базис для будущего приложения, и позволяет разработчикам концентрироваться на выяснении требований пользователя, способствуя, тем самым, возрастанию производительности и улучшению качества в уже завершенных системах.

Гибкость репозитория и открытые интерфейсы.

Репозиторий Oracle Designer сконфигурирован таким образом, что он имеет возможность управлять объектами, используя собственный программный интерфейс.

Описание нового объекта можно ввести в репозиторий с помощью диалогового интерфейса и без потребности в программировании.

Доступ к новым объектам можно получать из имеющихся инструментальных средств и легко манипулировать ими, используя для этого Матричный Диаграммер (Matrix Diagram) или Навигатор Объектов Репозитория (Repository Object Navigator).

Разработчики или другие поставщики инструментальных средств имеют доступ к содержимому репозитория непосредственно из программ, написанных на языках 3GL или 4GL, используя полный API моделирования.

С помощью этого API существенно упрощается процесс интеграции с репозиторием продуктов третьих фирм и облегчается их поддержка.

Используя гибкость и открытые интерфейсы, доступные при работе с Oracle Designer, разработчики могут, не прибегая к сложному программированию, приспособить репозиторий к своим специфическим потребностям и использовать Oracle Designer в гетерогенной среде разработки, куда включены и инструментальные средства от других поставщиков.

ЗАКЛЮЧЕНИЕ

Основой управления отдельным бизнес-процессом и группой бизнес-процессов являются показатели эффективности, среди которых можно выделить:

• затраты на осуществление бизнес-процесса,
• расчет времени на осуществление бизнес-процесса,
• показатели качества бизнес-процесса.

Для более глубокого понимания процессного подхода необходимо применять цикл Деминга-Шухарта «Plan — Do — Check — Act» (PDCA). Это «планирование — осуществление — проверка — действие». Использование этого цикла позволяет на практике реализовать непрерывное улучшение процессов, направленное на повышение эффективности работы организаци.

Принципы процессного подхода закреплены в международном стандарте сертификации системы качества серии ИСО 9000 с целью повышения удовлетворенности потребителей посредством выполнения требований системы менеджмента качества.

Согласно ИСО 9000, при оценке системы управления процессами необходимо:

1. выявить и определить процесс;
2. распределить ответственность;
3. внедрить и поддерживать в рабочем состоянии процедуры (управление процессом);
4. оценить эффективность процесса в достижении требуемых результатов

Следующим этапом на пути к достижению качества является оптимизация использования ресурсов в каждом выделенном процессе. Это означает строгий контроль за использованием каждого вида ресурсов и поиск возможностей для снижения затрат на производство продукции или оказание услуг.

СПИСОК ЛИТЕРАТУРЫ

1. Балдин, К.В. Информационные системы в экономике: учебное пособие/ Балдин К.В., Уткин В.Б. - М.: Дашков и К, 2012.

2. Буч Г., Якобсон А., Рамбо Дж. UML. Классика CS. 3-е изд./ Пер. с англ.; Под общей редакцией проф. С. Орлова – СПб.: Питер, 2016.

3. Боггс У., Боггс М.. UML и Rational Rose: Пер. с англ. - М.: Издательство «Лори», 2000. - 581 с.

4. Дубаков А.А. Проектирование информационных систем: Учебное пособие. Томск.: Изд. ТПУ, 2011.

5. Иванова Г. С. Технология программирования: Учебник для вузов / Г. С. Иванова. - М.: Изд-во МГТУ им. Н.Э. Баумана, 2002. - 320 с.

6. Леоненков А. В. Объектно-ориентированный анализ и проектирование с использованием UML и IBM RATIONAL ROSE: учебное пособие/ А.В. Леоненков. 2006г

7. Орлов, С.А. Технологии разработки программного обеспечения: учеб. / С.А. Орлов. – СПб. : Питер, 2014. – 464 с.

8. Проектирование информационных систем: учеб. пособие / П. В. Минеев ; Сиб. федер. ун-т, ХТИ - филиал СФУ. - Абакан : РИСектор ХТИ - филиала СФУ, 2012

9. Петров, В.И. Информационные системы / В.Н. Петров. – СПб. : Питер, 2013. – 688 с.

10. Терра-Лексикон: Иллюстрированный энциклопедический словарь. – М.: ТЕРРА, 2015. - 672 с.

11. Элиенс, А. Принципы объектно-ориентированной разработки программ / А. Элиенс. – М.: Издательский дом «Вильямс», 2014. – 496 с.

12. Якобсон, А. Унифицированный процесс разработки программного обеспечения / А. Якобсон, Г. Буч, Дж. Рамбо. - СПб.: Питер, 2014. - 496 с.