Файл: Применение процессного подхода для оптимизации бизнес-процессов (Информационные технологии в управлении бизнесом и производством).pdf

Различие междунотациями Процесс и Процедура состоит в том, что дополнительно к графическим элементам, применяемые в нотации Процесс, в нотации Процедура употребляются дорожки (Swim Lanes), обозначающие организационные единицы – исполнителей действий процесса. Это позволяет повысить наглядность диаграммы. Используемые графические элементы представлены в таблице 2.

Рисунок 2- Диаграмма процесса нотации IDEF0

Таблица 2- Используемые графические элементы

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

Пример диаграммы в нотации Процесс приведен на рис.3., а диаграммы в нотации Процедура – на рис. 4.

Рисунок 3- Пример диаграммы в нотации Процесс

Рисунок 4-. Пример диаграммы в нотации Процедура

Нотация EPC (Event-DrivenProcessChain – цепочка действий, управляемые событиями) была разработана в 1992 г. Институтом информационных систем при Саарском институте (Германия) в рамках научно-научного проекта, финансировавшегося компанией SAPAG. Ведомую роль в проекте сыграл управляющий Института врач Август-Вильгельм Шеер (учредитель организации IDS Scheer, выпускающий ПО семейства ARIS). Метод EPC стал частью изготовленной им мысли ARIS (Architecture of Integrated Information Systems – архитектура интегрированных информационных систем).

EPC по своей сути является расширением методике IDEF3 за счет использования этого понятия, как событие (англ. event). Под событием мы будем обдумывать то событие, что информационный объект (например, заказ) получает связанный с бизнес-действием статус (например, «получен»), которые управляют или воздействует на дальнейшее реализация бизнес-процесса. Деяния могут «переключать» бизнес-функции, т.е. передавать управление от одной функции к другой, а так же быть результатом реализации функций. В отличие от бизнес-функций,которые имеют некоторую продолжительность, деяния происходят одномоментно.

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

Потому что деяния определяют, какое состояние или отношение будет переключать функцию и какое состояние будет определять конец ее реализации, начальные и конечные узлы на диаграммах EPC повсевременно являются событиями. Измененный статус информационного объекта может относиться или к первому появлению этого объекта (например, «Заявка клиента поступила»), или к модифицированному состоянию, что выражается внедрением различных атрибутов (к примеру, «Предложение отклонено»).

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

Рисунок 5- Пример диаграммы EPC

Рисунок 6-Операторы в нотации EPC

Операторы не только демонстрируют графические связи между элементами модели, ну и определяют логические связи меж соответствующими объектами. Распространение того или другого оператора не повсевременно приемлимо: деяния, в отличие от функций, не могут принимать решения, поэтому переключающее событие не должно быть соединено с результирующими бизнес-функциями операторами «ИЛИ» или «исключающее ИЛИ».

Для построения диаграмм бизнес-действий в методике ARIS применяется расширение нотации EPC – extended EPC (eEPC), но на данный момент под EPC нередко подразумевают уже расширенную нотацию. В eEPC не считая рассмотренных нами объектов – функций, событий, связей (стрелок) и операторов – употребляются следующие объекты.

- организационная единица (англ. organizational unit) служит для обозначения различных организационных звеньев компании;

- документ (англ. document) отражает истинные носители информации, например картонный документ;

- прикладная система (англ. application system) обозначает реальную прикладную систему, используемую при выполнении функции;

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

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

Рисунок 7- Пример использования нотации eEPC

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

1.3 Состояние рынка средств описания бизнес-процессов и практический опыт описания бизнес-процессов в российских компаниях

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

ВЫБОР ИНСТРУМЕНТАРИЯ И МЕТОДОЛОГИИ ДЛЯ ОПИСАНИЯ ПРОЦЕССОВ

Часто данной теме в принципе не уделяется никакого внимания при принятии решения по описанию бизнес-процессов. При всем этом предполагается (совсем неверно), что нет различия в том, какое ПО и какую методологию применять.

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

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

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

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

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

Поверхностный изучение интернета указывает, что эта тема (выбор методике и инструментария) недостаточно освещена (изучение META Group не много того, что больше нацелен на IT-решения, так к тому же практически не учитывает особенностей Российского рынка, разглядывает лишь обычных уполномоченных лиц сложившегося западного рынка). Более нередко видятся статьи сопоставления методологий ARIS и IDEF. Иной самой популярной темой является перечисление мощных и слабых сторон (обычно методологий) без учета того, применительно к какой задачке эти качества анализируются. Становится несколько удивительно: неуж-то, к примеру, грузоподъемность грузового автомобиля постоянно является бесспорным преимуществом, вне зависимости от того, для чего я выбираю машину?

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

- CA ERwin Data Modeler (до этого называвшийся AllFusion Data Modeler, BPwin). Более успешно реализована возможность описания взаимосвязанных трудных моделей, задачки описания алгоритмов и последовательности действий реализованы приметно слабее. Обыкновенные (немногословные) нотации описания. Трудно, или в принципе никак не реализуются доп задачки (увязка задач и процессов, создание дерева характеристик, проведение имитационного моделирования);

- ARIS (набор программных обеспечений, модулей компании IDS Scheer). Само заглавие (Architecture of Integrated Information Systems) гласит о том, что ПО вначале было нацелено на решение задачки описания алгоритмов и последовательности действий. Все другое в ARIS тоже можно делать, но это будет получаться чрезвычайно тяжело. Для описания бизнес-действий придётся применять огромное число моделей (в ARIS их более 80, и количество их растет) довольно трудной семантики, в которой путаются даже более ярые адепты. Без огромного опыта и существенного переосмысления основ методике воплотить трудные описания взаимосвязанных моделей тяжело;

- Corporate Modeler (Casewise Systems) во многом является английским более молодым аналогом ARIS — не по методологии и решениям, но по самим идеям1 ПО. Кроме того, нацелено на помощь в описании бизнес-процессов для следующей разработки программного обеспечения. Однако стоит оно в среднем дешевле;

- iGrafx Enterprise Central (отделение Corel Inc) пока наименее популярное в России, но очень привлекательное решение из Канады. Включает в себя целый набор модулей по описанию, моделированию процессов, приложения по планированию и управлению качеством управлением рисками. Значительным ее минусом является ее нераспространённость;