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

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

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

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

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

Моделирование бизнес-процессов предприятия касается ряда аспектов его работы. При моделировании:

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

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

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

1. Нужно регламентировать деятельность. Содержание графической модели бизнес-процесса полностью совпадает с текстовой. Если компания располагает графиком, то в кратчайшие сроки и без труда переведет его в формат текста, чтобы подготовить нормо-регулирующую документацию. Благодаря некоторым ВРМ-системам на основе модели возможна автоматическая генерация регламентов исполнения и должностных инструкций.
2. Необходимо управлять рисками.С операционными рисками компания сталкивается в ходе выполнения бизнес-процессов. Модели бизнес-процессов могут стать основой для составления карты рисков всей организации при управлении ими.
3. Компания нуждается в организационных изменениях. Чтобы рассчитать оптимальную численность специалистов в штате, следует точно определить, сколько сотрудников должно участвовать во всех бизнес-процессах компании. Получить необходимую информацию помогает визуальное моделирование бизнес-процессов. Данное действие позволяет грамотно распределить человеческие ресурсы, которые требуются для выполнения того или иного процесса и связанных с ним задач, а также выявить, сколько специалистов должно состоять в каждом отделе, с рациональной точки зрения.
4. Проведение функционально-стоимостного анализа. Моделирование бизнес-процессов предприятия позволяет понять, сколько человеческих и материальных ресурсов нужно, чтобы выполнить одно действие в рамках бизнес-процесса. Данная информация может стать основой для автоматического распределения всех доходов и расходов на центры затрат и получения прибыли, в зависимости от подразделения.
5. Потребность в автоматизации. При моделировании бизнес-процесса однозначно описывается порядок действий и место специалистов, отвечающих за них. Это позволяет правильно разработать бизнес-требования. Благодаря автоматизированным информационным системам класса workflow-managemet можно моментально вносить корректировки в информационную систему.

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

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

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

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

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

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

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

Часто модели бизнес-процессов используют, оптимизируя схему управления и создавая систему мотивации персонала предприятия.

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

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

Современное техзадание вполне может состоять не только из списка требований, но и из моделирования.

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

При моделировании бизнес-процессов используют не только описанные выше задачи. Это лишь малая часть примеров.

Моделирование бизнес-процессов с помощью стикеров и листка бумаги

Большой лист бумаги и блок стикеров – вот и всё, что понадобится вам для применения метода создания бизнес-моделей по известной книге Александра Остервальдера и Ива Пинье. Добавьте еще креативность, острый ум и упорство членов команды, и вы получите отличный результат.

Один из разделов книги рассказывает о пяти бизнес-моделях, которые доказали свою работоспособность. Их описание вы найдете в статье электронного журнала «Генеральный директор».

Основные подходы к моделированию бизнес-процессов

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

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

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

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

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

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

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

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

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

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

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

Сейчас можно отметить тенденцию интеграции разных способов моделирования и анализа систем. Проявляется она в том, что создаются интегрированные средства моделирования бизнес-процессов. Одно из них – продукт немецкой компании IDS Scheer под названием ARIS – Architecture of Integrated Information System.

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

Система АRIS оказывает поддержку 4 видам моделей, отражающим различные объекты изучаемой системы:

Чтобы создать модели описанных выше типов, пользуются как собственными способами моделирования ARIS, так и разными известными методами и языками – ERM, UML, OMT и т.д.

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

В АRIS модели являются диаграммами, состоящими из различных объектов – «функции», «события», «структурные подразделения», «документы» и т.д. Между объектами устанавливают всевозможные связи. При этом каждый объект обладает своим набором атрибутов, который ему присваивают, что позволяет вводить дополнительные сведения о нем. Значения атрибутов могут быть использованы в ходе имитационного моделирования или при стоимостном анализе.

Ключевой бизнес-моделью АRIS является eEPC (extended Event Driven Process Chain – расширенная модель цепи бизнес-процессов, которыми управляют события). По сути, она расширяет возможности IDEF0, IDEF3 и DFD, обладает своими плюсами и минусами. Использование достаточного количества объектов, соединенных друг с другом различными видами связей, позволяет существенно увеличить размер модели и превратить ее в плохо читаемую.

В еЕРС бизнес-процесс является потоком последовательно проводимых работ (функций, процедур, мероприятий), расположенных в хронологическом порядке. Точная продолжительность процедур в еЕРС не отображается наглядно, вследствие чего не исключено появление в ходе разработки моделей ситуаций, в которых одному исполнителю придется решать две задачи в одно время. Символы логики, применяемые при моделировании, помогают отобразить ветвление и соединение процесса. Чтобы узнать, сколько на самом деле длятся процессы, следует пользоваться иными инструментами описания, к примеру, графиками Ганта в системе MS Project.

Ericsson-Penker

Способ Ericsson-Penker интересен, главным образом, тем, что в его рамках была предпринята попытка использовать UML, когда проводилось процессное моделирование бизнес-процессов. Разработчики метода создали собственный профиль UML, чтобы выполнять моделирование бизнес-процессов. Для этого вводили набор стереотипов, описывавших ресурсы, процессы, цели и правила работы компании.

В рамках метода применяют 4 главных категории бизнес-модели:

1. Ресурсы – разные объекты, которые используются или участвуют в бизнес-процессах (речь может идти о материалах, продуктах, людях, информации).

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

3. Цели – назначение бизнес-процессов. Их можно делить на составляющие и соотносить эти подцели с конкретными процессами.

4. Бизнес-правила – условия или ограничения реализации бизнес-процессов (функциональные, структурные, поведенческие). Правила можно определять, используя язык ОCL.

5. Основная диаграмма UML-метода – диаграмма деятельности. Ericsson-Penker демонстрирует процесс в виде деятельности со стереотипом «process» (основу представления составляет расширение метода IDEF0). В полную бизнес-модель входит много представлений, схожих с представлениями архитектуры ПО. Все представления в отдельном порядке выражены в одной диаграмме UML и более. Диаграммы могут включать в себя разные виды и изображать цели, правила, процессы и ресурсы при взаимодействии. Метод пользуется 4 разными представлениями бизнес-модели:

Rational Unified Process

Существует также моделирование бизнес-процессов по методике Rational Unified Process (RUP), в рамках которого строят две модели:

Модель бизнес-процессов является расширением модели вариантов применения UML за счет введения набора стереотипов – Business Actor (стереотипа действующего лица) и Business Use Case (стереотипа варианта использования). Business Actor – это некая роль, внешняя по отношению к бизнес-процессам компании. Business Use Case выступает как описание порядка мероприятий в отдельно взятом процессе, приносящее видимые результаты определенному лицу. Данное определение схоже с общим определением бизнес-процесса, но суть его точнее. В терминах объектной модели Business Use Case это класс. Его объекты – определенные потоки событий в описываемом бизнес-процессе.

При описании Business Use Case также можно обозначать цель. Ее, как и в случае с методом Eriksson-Penker, моделируют с помощью класса со стереотипом «goal», а дерево целей изображают как диаграмму классов.

Применительно к каждому Business Use Case необходимо строить объектную модель для описания бизнес-процесса в терминах объектов, находящихся во взаимодействии друг с другом (бизнес-объектов – Business Object), которые относятся к двум классам – Business Worker и Business Entity.

Business Worker – это класс, который представляет абстрактного исполнителя, выполняющего в бизнес-процессе определенную работу. Исполнители находятся во взаимодействии и реализуют сценарии Business Use Case. Что касается Business Entity (сущности), это объект различных действий, выполняемых исполнителями.

В модели бизнес-анализа могут присутствовать, помимо диаграмм вышеупомянутых классов:

• организационным, которые представляют системную структуру – подразделения компании, должности, конкретные лица в иерархии, взаимосвязь между ними, территориальную принадлежность структурных отделов;
• функциональным, в которых отражена иерархия цепей, стоящих перед управленческим аппаратом, с совокупностью деревьев функций, необходимых для реализации имеющихся задач;
• информационным, где отражена структура информации, которая требуется для выполнения всех функций в системе в целом;
• моделям управления, которые представляют собой комплексный взгляд на выполнение бизнес-процессов.
• концептуальным, показывающим структуру проблем и целей;
• представлением процессов, что является взаимодействием между ресурсами и процессом (как набор диаграмм деятельности);
• структурным представлением, показывающим структуру компании и ресурсов (отображаются диаграммы классов);
• представлением поведения (тем, как ведут себя отдельные ресурсы, а также детализацией ресурсов в виде диаграмм работ, состояний и взаимодействия).
• бизнес-процессов (Business Use Case Model);
• бизнес-анализа (Business Analysis Model).

1. Диаграммы последовательности (и кооперативные диаграммы), описывающие сценарии Business Use Case как последовательность обмена сообщениями между объектами – действующими лицами и объектами, являющимися исполнителями. Благодаря таким диаграммам можно определять, какими обязанностями должен быть наделен тот или иной исполнитель, и отображать в модели набор его операций.
2. Диаграммы деятельности, описывающие взаимосвязь между сценариями одного или нескольких Business Use Case.
3. Диаграммы состояний, описывающие, как себя ведут отдельные бизнес-процессы.

В методике моделирования Rational Unified Process есть определенные достоинства:

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

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

IBM WebSphere Business Modeler

IBM WebSphere Business Modeler позволяет моделировать и имитировать бизнес-процессы, анализировать и создавать отчеты для их усовершенствования. У системы есть ряд преимуществ, среди которых:

1. Обширные и лучшие в своем классе возможности для анализа, имитации и моделирования.
2. Непрерывное улучшение процессов.
3. Усовершенствованные возможности интеграции.
4. Улучшенные сроки возврата инвестиций.
5. Усовершенствованные функции разработки.

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

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

Допускается реализация одновременно нескольких версий моделей и публикация моделей процессов.

• Простая формула, чтобы понять, что предприятию нужна автоматизация бизнес-процессов

Какой использовать стандарт моделирования бизнес-процессов

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

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

Модель IDEF0 – это серия диаграмм с сопроводительными документами. Диаграммы разбивают многоступенчатый объект на несколько составляющих (блоков), что существенно упрощает процесс. Детали всех блоков показаны как блоки на других диаграммах. Все детальные диаграммы – это декомпозиции блока из предшествующего уровня. На каждом этапе декомпозиции диаграмму предшествующего уровня именуют родительской для более детализированной диаграммы. Общее количество уровней в модели – не более 5-6. Опыт показывает, что этого вполне хватает, чтобы построить полную функциональную модель современной компании, работающей в любой сфере.

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

Информационное моделирование бизнес-процессов включает несколько составляющих. Главные элементы – это:

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

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

Поскольку анализировать динамические системы достаточно сложно, в данный момент стандарт почти не используют, и он, едва появившись, перестал развиваться. Сегодня есть алгоритмы и их компьютерные реализации, при помощи которых становится возможным превращение набора статистических программ IDEF0 в динамические модели, базой для построения которых выступают «раскрашенные сети Петри» (CPN – Color Petri Nets).

IDEF3 – IDEF14

Основной элемент IDEF3 – диаграмма, как и в IDEF0. Не менее важный компонент – действие, которое также называют «единицей работы». Действия в рамках данной системы отражены в виде прямоугольника из диаграмм. Действия называют, используя для этого отглагольные существительные или глаголы. При этом каждое обладает уникальным идентификационным номером, который не применяют повторно, даже если в ходе разработки модели действие удаляют. В диаграммах IDEF3 перед номером действия обычно ставят номер его родителя. Окончание одного часто способствует началу другого действия или даже нескольких. Бывает и так, что одно действие может потребовать завершить другие до начала своей реализации.

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

IDEF5 является методологией изучения сложных систем.

IDEF6 – Design Rationale Capture – обоснование проектных действий. IDEF6 позволяет значительно упрощать процесс получения информации о моделировании, ее представление и применение при создании фирмами управленческих систем. «Знания о способе» – это определенные обстоятельства, причины, скрытые мотивы, обосновывающие выбранные методы создания моделей. То есть «знания о способе» можно интерпретировать как ответ на вопрос: «Почему получилась именно эта модель, с этими, а не иными характеристиками?». Большая часть способов моделирования концентрируется на создаваемых моделях, не углубляясь в их разработку. Вариант IDEF6 нацелен именно на разработку.

IDEF 7 – Information System Auditing – аудит информационных систем. Метод востребован, но его так и не доработали до конца.

IDEF8 – User Interface Modeling. Метод создания интерфейсов взаимодействия системы с оператором (пользовательских интерфейсов). В данный момент при разработке интерфейсов основное внимание уделяют их внешнему виду. IDFE8 сосредоточен на программировании оптимальной взаимной коммуникации пользователя и интерфейса на 3 уровнях: операции (какая она); вариантах взаимодействия, которые зависят от специфической роли пользователя (как именно тот или иной пользователь должен выполнять ее); и, наконец, на составляющих интерфейса (элементах управления, предлагаемых им для операции).

IDEF9 – Scenario-Driven IS Design (Business Constraint Discovery method) – метод исследования бизнес-ограничений. Призван облегчить обнаружение и анализ ограничений в условиях работы компании. Как правило, при создании моделей не в полном объеме описывают ограничения, способные изменить ход процессов в организации. Информация об основных ограничениях, характере их влияния в лучшем варианте остается не до конца согласованной, нераспределенной рационально, однако нередко она в принципе отсутствует. Это не всегда означает нежизнеспособность построенных моделей. Просто их воплощение будет сопровождаться определенными сложностями, что приведет к нереализованному потенциалу. Вместе с тем, когда имеет место именно совершенствование структур или адаптация к вероятным изменениям, информация об ограничениях становится очень важной.

IDEF10 – Implementation Architecture Modeling – моделирование архитектуры выполнения. Система моделирования бизнес-процессов достаточно востребована, несмотря на то, что не разработана до конца.

IDEF11 – Information Artifact Modeling. Также востребованный, но не доработанный полностью метод.

IDEF12 – Organization Modeling – организационное моделирование бизнес-процессов. Метод востребован, но не выработан полностью.

IDEF13 – Three Schema Mapping Design – трехсхемное проектирование преобразования информации. Востребованный, но не окончательно созданный метод.

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

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

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

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

• внешние сущности;
• системы и подсистемы;
• процессы;
• накопители информации;
• информационные потоки.

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

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

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

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

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

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

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

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

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

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

• Как навести порядок в бизнес-процессах, если вам досталась «нехорошая» компания

Главные этапы моделирования бизнес-процессов

Этап 1. Идентификация.

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

Этап 2. Сбор информации.

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

Этап 3. Анализ информации.

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

Этап 4. Внесение улучшений.

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

Этап 5. Контроль над внедрением.

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

Выпуск:

Библиографическое описание статьи для цитирования:

Никулина Т. Н., Фартушина А. С. Проблемы моделирования бизнес-процессов в современных организациях // Научно-методический электронный журнал «Концепт». – 2015. – Т. 13. – С. 4436–4440..htm.

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

Текст статьи

Никулина Тамара Николаевна,Кандидат экономических наук, доцент кафедры экономики и менеджмента, Астраханский филиал «Московский финансовопромышленный университет «Синергия»», г. Астрахань[email protected]

Фартушина Анастасия Сергеевна,Старший преподаватель кафедры кафедры экономики и менеджмента, Астраханский филиал «Московский финансовопромышленный университет «Синергия»», г. Астрахань[email protected]

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

Аннотация. В современной практике моделирования управленческой и производственной деятельности используются различные методики моделирования бизнеспроцессов. В условиях, когда необходимо достигнуть ожидаемых результатов, большая часть организаций сталкивается с рядом трудностей. Не получив быстрых, измеримых результатов, ожидая сложную и длительную работу, руководство компании завершает работы по разрабатываемому проекту. Целью данного исследования является выявление проблем моделирования бизнеспроцессов в современных организациях.Практическая значимость работы заключается в том, что работа представляет собой самостоятельное, завершённое научное исследование, а полученные результаты могут быть применены в деятельности современных организаций.Ключевые слова: моделирование бизнеспроцессов, интегрированныесредствамоделирования, процессныйподход к управлению, ситуативный подход.

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

Также необходимо отметить способ формирования бизнеспроцессов применение совокупности моделей бизнеспроцессов для создания корпоративной единой нормативноправовой системы и базы, например регламенты процессов, положения о подразделениях, должностные инструкции. Наиболее часто данные технологии используются при подготовке предприятия к сертификации в системе менеджмента качества. На сегодняшний день почти все инструменты и методы построения бизнеспроцессов дают возможность получать и анализировать данные об субъектах, объектах на модели и ее взаимосвязях и формировать их как документы. В тоже время, необходимо отметить, что инструменты и методы, заложенные в основе таких решений, могут различаться.Как правило, моделирование бизнеспроцессов используют при оптимизации системы управления предприятиями и формирования программы мотивации персонала. В этом случае моделируются цели предприятия, при этом каждая детализируется на более конкретные цели, пока эта детализация не станет достояно подробной, что конкретные цели должны быть взаимосвязанными с работой конкретных сотрудников. Далее для данных конкретных целей определяются количественные показатели, которые определяют степень достижения целей, и на базе этих показателей формируется программа мотивации персонала.Проектирование бизнеспроцессов служит для проектирования информационных систем и ИТрешений –сейчас разработка и формирование процессов при организации управления требованиями и разработке спецификаций становится практически необходимым условием, и в техническом задании достаточно часто представляется не только перечень требований, но также и модели самих процессов. Необходимо отметить, что независимо от мнения специалистов в области управленческого консалтинга, стоит обратить внимание, на то, что в большинстве случаях часто задача корректной информационной поддержки и автоматизации работы предприятия является одной из главных для принятия решений о формировании мoдели бизнеспроцессов.Область использования моделей бизнеспроцессов не ограничивается указанными выше задачами .В современной практике моделирования управленческой и производственной деятельности используются различные методики моделирования бизнеспроцессов.По мнению аналитиков во многих российских компаниях ставятся «адекватные» цели, разрабатываются планы, создается описание бизнеспроцессов, проводится их анализ и осуществляется реорганизация деятельности. Однако на заключительном этапе, в условиях когда необходимо достигнуть ожидаемых результатов, большая часть организаций сталкивается с рядом трудностей. Не получив быстрых, измеримых результатов, ожидая сложную и длительную работу, руководство компании завершает работы по разрабатываемому проекту. Начинаются поиск следующих «модных» и актуальных подходов к управлению изменениями.Данные трудности возникают в силу того, что:

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

существующие методы и средства используют различные языки моделирования, терминологию, плохо совместимы друг с другом, дорогостоящи и трудоемки в использовании.Эти обстоятельства обуславливают многочисленные проекты, предпринимаемые в настоящее время. Их целью сводится к объединению изучаемых методов и стандартов моделирования, также к созданию единого методического и технологического стандарта моделирования бизнеспроцессов. В более глобальном смысле –это моделирования архитектуры компаний (enterprise modeling).При проведении моделирования бизнеспроцессов компании необходимо применять следующую методику, которая содержит:

описание методов моделирования –способов демонстрации изучаемых объектов компании по средствам объектов модели;

процедуру –последовательность шагов по сбору первичной и вторичной информации, ее обработке и представлению в виде схем, диаграмм.При моделирования бизнеспроцессов аналитиками применяются различные методы, которые основаны на структурных, а также и объектноориентированных принципах моделирования. К сожалению разбивка методов на структурные и объектные является достаточно условной процедурой. Это вызвано тем, что наиболее актуальные методы интегрируют средства нескольких подходов. На рисунке 1 представлены методики моделирования бизнеспроцессов.

Рис.1.Методики моделирования бизнеспроцессов

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

ПодходСуть методикиДостоинства и недостаткиISO9000Функционирует на основе стандартов ISO9000. Результатом моделирования является схема, которая описывает бизнеспроцесс в привязке к Легкое и четкое описание бизнеспроцессов. Накопленный опыт примененияструктуре управления предприятия .SADT/ IDEF0, IDEF3Схема является основным компонентом модели. Данная методика применяется в случаях формирования новых бизнеспроцессов для введения ограничений к бизнеспроцессам, а затем при разработке бизнеспроцессов. Методика позволяет работать с существующими бизнеспроцессами по средствам анализа выполняемых ими функций и документирования механизмов, которыми достигается поставленные целиПредоставляет т возможность демонстрации управленческих воздействий на анализируемые процессы. Разрабатываемые модели легко интерпретируются в отличие от других методик. Методика не может применяться при описании динамики исполнения анализируемого процесса.BPELПредусматривается системный подход к описанию бизнеспроцессов с четко обозначенными абстракциями, описания. Разрабатываются и предлагаются механизмы совершенствования бизнеспроцессов.Существуют языковые трудности. Отсутствует качественный перевод и адаптация на русский язык. Методика не описывает сложные исследуемые бизнеспроцессы. Упрощает работу руководителя процесса в управлении им.DFDИспользуются при описании системы документооборота и обработки необходимой информации. Позволяет анализировать функции обработки информации, документы, объекты, персонал, которые участвуют в подготовке и обработке информации, а также таблицы для хранения документов. Для описания набора работ.Эффективное и простое описание процесса документооборота.UMLИспользуется высокий уровень проектирования с применением специфики, визуализации, конструирования и документирования. Применяются схемы классов, кооперации, взаимодействия, активности.Вносит ряд ограничений в процесс кодировки и позволяет устанавливать стандарт разработки программного кода.ARIS eEPCПозволяет описывать деятельность в динамике и отражает последовательность выполнения отдельных процедур (функций). Данная модель включает следующие модели: организационная структура управления; процессы на высшем уровне иерархии; функции руководителей различных уровней управления предприятием; функции руководителей подразделений по управлению и выполнению отдельных процессов; действия сотрудников по выполнению исследуемого процесса.Модели громоздкие и плохо читаемы. Отсутствует возможность визуального отражения деятельности выполнения проводимых шагов действий. Не отражает прямых управленческих воздействий, управление компанией отражено при указании входящих документов.ЯМТ (язык моделирования Тушкало)Методика дает возможность отказаться от традиционной текстовой формы записи интервью с функциональными исполнителями бизнеспроцессов в графическую форму схем бизнеспроцессов с использованием CASEсредства, но без участия исполнителей. ЯМТ схемы бизнеспроцессов имеют одноуровневую линейную структуру представления, в виде линии с нанесением временной оси или в виде набора отдельных листовПредназначена для описания бизнеспроцессов различной степени сложности и подробности. Дает оценку качества создаваемой модели бизнеспроцессов по восемнадцати нормативным правилам. Отмечается простота и доступность средств схематического изображения оцениваемых бизнеспроцессов

Для компании, проводящей реструктуризацию текущих бизнеспроцессов, возникает глобальная проблема выбора и применения методики моделирования процессов. Сложность этого выбора заключается в том, что в компаниях сталкиваются с рядом ограничений:1. Ограниченный бюджет компании. Для реализации процесса моделирования важно приобрести программное обеспечение. При этом каждый инструмент моделированияподдерживает большое количество нотаций. Поэтому, выбор стандарта моделирования обуславливается определением программного обеспечения, который в свою очередь ограничивается бюджетом.2. Потребность в квалифицированных специалистах аналитиках, которые могут эффективно работать с приобретаемым программным продуктом и знающими определенные нотации.3. Комплекс поставленных задач какойлибо методики моделирования.Учитывая, что основной целью моделирования бизнеспроцессов является отражение реального хода бизнеспроцессов предприятия, необходимо выявить, что именно будет являться результатом действительного выполнения конкретного бизнеспроцесса, кто и какие действия выполняет, какова последовательность этих действий, как организовано документационное обеспечение выполняемых процессов, насколько велика угроза неудачного выполнения процесса (насколько надежен процесс) и как он может быть модифицирован и/или расширен будущем.

Таким образом, модель бизнеспроцесса, представляющая собой графическое, табличное, текстовое или символьное его описание, должна содержать следующие сведения:набор бизнесфункций, то есть составляющих процесс «шагов»;порядок выполнения бизнесфункций;механизмы контроля и управления в рамках бизнеспроцесса; исполнителей каждой бизнесфункции; входящие документы (информацию), исходящие документы (информацию); необходимые для выполнения каждой входящей в процесс бизнесфункции ресурсы; порядок выполнения бизнесфункций; документацию (условия), регламентирующие выполнение каждой входящей в процесс бизнесфункции; параметры, характеризующие выполнение каждой бизнесфункции и бизнеспроцесса в целом. Руководство предприятия, бизнесаналитик, владелец бизнеспроцессаи другие заинтересованные стороны должны иметь четкое представление о том, как организован и функционирует бизнеспроцесс, отсюда следует, что модель должна обеспечить прозрачность хода бизнеспроцесса. Понимание хода существующих бизнеспроцессов позволит дать адекватную оценку их эффективности и качеству, что в свою очередь необходимо для разработки поддерживающего бизнес программного обеспечения. В глобализации бизнеса наблюдается тенденция объединения различных методов моделирования и анализа систем. Такого рода интеграция проявляется в форме создания интегрированных средств моделирования.Проведем сравнительный анализ методик ARIS и IDEF, результаты которого приведены в таблице 2.Таблица 2Сравнительный анализ методов ARIS, IDEF

Критерии ARISIDEF0IDEF3Принцип формирования диаграммы / логика бизнеспроцессаВременная последовательность реализации процедурПринцип преобладания Временная последовательность реализации процедурХарактеристика процедуры бизнеспроцессаНа диаграмме расположен объектНа диаграмме расположен объектНа диаграмме расположен объектВходящий документПрименяется самостоятельный объект для характеристики («документ»)Стрелка сверху, стрелка слеваНет (представлен в модели только привязкой объектакомментария)Входящая информацияПрименяется самостоятельный объект для характеристики («кластер» и «технический термин»)Стрелка сверху, стрелка слеваНет (представлен в модели только привязкой объектакомментария)Исходящий документПрименяется самостоятельный объект для характеристики («документ»)Стрелка расположена справаНет (представлен в модели только привязкой объектакомментария)Исходящая информацияПрименяется самостоятельный объект для характеристики («кластер» и «технический термин»)Стрелка расположена справаНет (представлен в модели только привязкой объектакомментария)Исполнитель процедурыПрименяется самостоятельный объект для характеристики («позиция» и «организационная единица»)Стрелка расположена снизуНет (представлен в модели только привязкой объектакомментария)Применяемое оборудованиеПрименяется самостоятельный объект для характеристики Стрелка расположена снизуНет (представлен в модели только привязкой объектакомментария)Управление процедуройОтсутствует. Представлено символами логики и событий (последовательность реализации процедур) и/или указанием входящих документовСтрелка расположена сверхуВременная последовательность реализации процедур и логика процессаКонтроль реализации процедурыОтсутствует. Представлен указанием входящих документовСтрелка расположена сверхуОтсутствует.Обратная связь по управлению/контролюОтсутствует. Представлен символами логики (последовательность реализации процедур)Стрелка расположена сверхуОтсутствует.

Следует учитывать тот факт, что при моделировании деятельности крупных компаний, которые занимаются производством товаров, а так же оказанием услуг, целесообразно использовать различные методики моделирования. Это обусловлено тем, что для моделирования производственных процессов более предпочтительным является процессный подход (например, метод ErikssonPenker).Спецификация требований к программному обеспечению является составной частью процесса управления требованиями. Выявленные в результате использования разного рода методов требования к программным продуктам оформляются в виде документов и моделей. При разработке модели бизнеспроцессов деятельности малых предприятий, занимающиеся как производством продукции, так и оказанием услуг, возможно применять упрощенные схемы моделирования, поскольку для моделирования производственных процессов более предпочтительным является ситуативный подход.Модель BPwin рационально применять для ведения небольших по размерам деятельности компаний (малый и средний бизнес предусматривает 25 человека в группе экспертов) и длительности (23 месяца) проектов. Для крупного бизнеса и длительных проектов (например, внедрение системы непрерывного совершенствования бизнеспроцессов в соответствии со стандартами ISO) следует использовать модель ARIS. В данных условиях подготовительные работы по созданию регламентирующей документации могут занять 13 месяца, но это является необходимым элементом последующей эффективной работы.Рассмотрим перспективные направления в моделировании бизнеспроцессов.В настоящее время разрабатываются многочисленные проекты. Их целью является интеграция существующих методов и стандартов моделирования, а также и формирование комплексного методического и технологического базиса моделирования бизнеспроцессов. В более широком контексте –это моделирования компаний (enterprisemodeling).Стандартное жесткое применение систем в современных условиях не работает, необходимо непрерывно учитывать человеческий фактор, так как BPM взаимодействует через людей, то должна обеспечиваться адаптивность процессов. Поэтому в ближайшее время ожидается появление стандарта BPMN 3.0 (с добавлением Case Management).Активно развиваются технологии Process Mining, которые основываются на анализе деятельности, логов, событий и на этом строятся карты процессов. Можно выделить следующие направления развития и роста BPM:

Mobile (мобильность);

Process Mining (исследование процессов);

Agility(адаптивность);

Event Driven (управление внешними событиями);

Case Management (управление случаями).BPMS в России сфокусировались на финансовых рынках (страхование и банки) и в телекоммуникационной отрасли.BPM нужны в первую очередь там, где невозможны «коробочные решения».Также следует отметить, что развивается направление Process Intelligent(анализ бизнеспроцессов на базе процессных показателей), позволяющее применить практически любую BIсистему.Огромное значение для эффективного внедрения BPM имеет ИТархитектура, а с этим понятием на многих предприятиях дела обстоят плохо. В западных компаниях эти понятия хорошо развиты, в отличие от ситуации в России. Нужно четко осознавать, что BPM –это управленческая сквозная методология, постоянно работающая и ориентированная на рост преимуществ растущего бизнеса.ОсобенностиBPMпроектов:

тесное взаимодействие ИТ и бизнеса;

возможность быстрых побед;

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

прозрачность деятельности предприятия;

сокращение рутинной работы;

скорость изменения бизнеспроцессов;

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

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

чтобы увидеть его целостную модель?

чтобы анализировать и оптимизировать работу, исходя из понимания, что это единая сложнаясистема, а не сумма отдельных фрагментов? (в системе отлично работающие части целого –это далеко не всегда эффективная работа системы в целом);

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

простота формирования графических схем;

интуитивная понятность схем;

минимальная потребность в обучении сотрудников;

наличие доступных инструментов для описания (MS Visio, MS Word).Для дальнейшего успешного внедрения процессного подхода к управлению предприятием необходимо проектирование таких бизнеспроцессов, которые способны реализовать стратегические цели организации. Основным шагом в этом направлении является описание и регламентация бизнеспроцессов организации.Описание бизнеспроцессов регламентирует работы по выделению и описанию бизнеспроцессов организации в однородном формате (в стандартных формах) и с использованием стандартного программного обеспечения. Характеристика бизнеспроцесса используются:

для анализа и оценки эффективности бизнеспроцесса;

для оптимизации бизнеспроцесса по определенным индикаторам эффективности;

для формирования эффективной системы управления;

для разработки нормативных документов по технологии;

выполнения бизнеспроцесса;

для подготовки к созданию и внедрению автоматизированных систем управления.Документация, которая включает модели бизнеспроцесса, выполненные в стандартном формате стандартными программными средствами является результатом описания бизнеспроцессов.Важной составляющей, влияющей на эффективность бизнеспроцесса, является правильная их организация и управление ими. Бизнеспроцессом необходимо управлять для получения на выходе запланированных результатов. Поэтому необходимо создание и функционирование системы управления бизнеспроцессом.Таким образом, на современном этапе развития экономики, для описания бизнеспроцессов компаний можно предложить использовать методику IDEF, так как на в настоящее время на большинстве отечественных предприятий еще очень слабо развит процессный подход к управлению компаниями, а схема в IDEF позволит и графически показывать взаимодействие между ними. Важно, что в технике IDEF0 посредством специальных стрелок было возможно показывать административные влияния, что предоставляетвозможность характеризовать систему управления процессами и организацией. Подводя итог выше сказанному, следует отметить, что рассмотренные нами современные методы и инструменты моделирования в своем развитии достигли высокого уровня. С точки зрения изобретательских средств моделирования их возможности стали примерно одинаковыми. Выбор метода или инструмента моделирования бизнеспроцессов обусловлен уровнем компетентности консультанта или аналитика в данной сфере, а также грамотностью на языке моделирования, которая обеспечивает высокий уровень применения методик моделирования руководителями и специалистами компаний.

Ссылки на источники1. ЖудинМ.НОбзорпрограммныхпродуктовбизнес–моделирования//Корпоративныйменеджмент:сетевойжурнал.2009.–351c.2. СамуйловК.Е.,ЧукаринА.В.,ЯркинаН.В..Бизнеспроцессыиинформационныетехнологиивуправлениителекоммуникационнымикомпаниями.М.:АльпинаПаблишерз,2009.446с.

Антон Тимохин

Руководитель проектов дирекции по развитию НПО «ЭЛСИБ»

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

Начало начал

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

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

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

Список можно продолжить.

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

• Слепая вера топ-менеджмента компании в то, что внедрение новой программной системы (ERP, CRM, MRP и др.), которая (по заверению ее разработчиков) после внедрения и использования лучших практик, заложенных в референтных моделях, совершит чудо и бизнес сам начнет изменяться в положительную сторону…;
• Сложившийся факт, что описание бизнес-процессов многими рассматривается как универсальный инструмент решения проблем. Но на практике это далеко не так — описание может помочь в устранении проблемных зон, но не само по себе, а в рамках комплексного подхода, одним из компонентов которого может быть как раз формализация бизнес-процессов компании;
• Отсутствие бизнес-задачи. Компания работает, приносит некоторую прибыль. Да, при этом есть некоторые сложности в коммуникациях, но не более чем «рабочие моменты». Зачем менять сложившуюся практику выполнения работ, тем более, что описание бизнес-процессов потребует инвестиций в программное обеспечение, обучение специалистов, отвлечение сотрудников от рабочего процесса? Снижение эффективности компании и увеличение издержек неизбежно, если в цели проекта не входит увеличение бизнес-показателей.

Несколько слов об оптимизации

Описание бизнес-процессов в большинстве случаев воспринимается как «лекарство от всех болезней», но мало кто из руководителей задумывается о том, зачем необходимо описывать существующие бизнес-процессы? Ведь круг проблем, которые могут быть решены простой формализацией процессов ограничен, а в остальных случаях требуется оптимизация бизнес-процессов компании.
Как правило, к оптимизации относятся как к некоторому абстрактному понятию, не несущему никакой другой нагрузки, кроме эмоциональной: «теперь мы решим все проблемы», при этом, не уделяя никакого внимания критериям оптимизации — какой процесс, насколько улучшить и в каких допустимых пределах.

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

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

Про инструменты и методологии

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

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

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

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

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

Что можно получить в итоге

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

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

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

• Исполнитель (аналитики компании или внешние консультанты), не задавая лишних вопросов, добросовестно приступают к выполнению работ по проекту. При этом, т. к. четких указаний, что описывать, на этапе начала работ не было, описываются либо все процессы подряд, либо те, которые определяет руководитель компании. Дни проходят один за другим, проект, казалось бы, успешно реализуется, вот только полученный результат не оправдывает вложенных средств. Бизнес-процессы описаны так, как это действительно происходит в компании, полученные модели сложные, запутанные и зачастую не пригодны для дальнейшего использования. Несмотря на это исполнитель предпринимает попытку оптимизации процессов, но в силу недостаточного опыта работы в компании, используя мнение узкого круга лиц, не принимая во внимание взаимосвязи между процессами, по факту не улучшает ничего. В результате потрачено значительное количество времени и ресурсов, текущие проблемы бизнеса не решены, а у руководителя появляется негативный опыт, не позволяющий ему вернуться к подобной работе в дальнейшем;
• Исполнитель начинает задавать вопросы, уточняя, зачем необходимо описание бизнес-процессов, какой результат планируется достигнуть, какие критерии оптимизации установлены. На этом этапе может быть получен серьезный негатив от руководства компании, потому что, во-первых, ответов просто нет, а во-вторых, задача описания процессов формальная, не подкрепленная логической цепочкой выводов и подзадач. Выясняется ряд «особенностей» бизнеса, которые неприятны руководителю компании и на которые раньше он «закрывал глаза»:
  • Вдруг выясняется, что описание процессов «как есть» невозможно, просто потому, что их в компании нет — деятельность выполняется на основании опыта сотрудников, решения принимаются по ситуации, и даже регулярные процессы выполняются не так, как закреплено в регламентах, а так, как удобно исполнителям;
  • Бизнес подвержен внешним или внутренним рискам, отсутствуют целевые показатели, система мотивации не способствует повышению качества продукции/услуг, учет затрат ведется не в полном объеме или отсутствует;
  • При описании процессов выявляется необходимость проведения существенных изменений в модели бизнеса.

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

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

Лучшие практики

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

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

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

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

Этап первый — инициация проекта

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

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

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

Этап второй — бизнес-задача

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

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

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

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

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

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

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

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

Этап третий — программное обеспечение

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

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

Выбор программного продукта осуществлялся по следующим критериям:

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

После анализа рынка систем бизнес-моделирования было принято решение об использовании в нашем проекте системы Business Studio, наиболее полно соответствующей установленным критериям.

Этап четвертый — методология

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

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

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

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

• Организационную структуру;
• Информационные системы, поддерживающие выполнение бизнес-процессов;
• Носители информации, используемые в процессах.

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

Этап пятый — бизнес-модель, рабочие группы

Дальнейшая схема выполнения проекта подробно представлена на рисунке 1.

Рисунок 1. Схема выполнения основной фазы проекта по описанию и оптимизации бизнес-процессов

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

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

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

В рамках проекта владельцы бизнес-процессов отвечают за обеспечение выполнения работ по:

• Описанию и оптимизации своих бизнес-процессов;
• Выработке предложений по оптимизации бизнес-процессов;
• Анализу и согласованию предложений по оптимизации бизнес-процессов, сформированных участниками рабочих групп.

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

В рамках проекта на участников рабочих групп возлагаются обязанности по разработке модели бизнес-процессов, подготовке предложений по оптимизации бизнес-процессов, подготовке и проведению согласования разработанного пакета регламентирующей документации. Для эффективного выполнения работ по проекту рабочее время участников групп распределяется в соотношении 30/70 (проект/должностные обязанности) приказом руководителя компании.

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

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

Этап шестой — моделирование, оптимизация

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

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

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

Чтобы исключить дублирование информации в справочниках системы, на данном этапе в группах по описанию и оптимизации бизнес-процессов назначаются ответственные. Они осуществляют ввод данных в справочники на основании запросов участников группы.
Также в целях повышения эффективности работы групп, структурирования информации в базе данных системы, минимизации временных затрат на поиск информации в системе при вводе данных в справочники группы «Объекты деятельности» рекомендуется создавать структуру каталогов (например так, как это описано в статье «Организация работы с документами на платформе Business Studio»).

После завершения работ на 2-м уровне декомпозиции моделей бизнес-процессов верхнего уровня выполняется согласование границ подпроцессов и бизнес-процессов верхнего уровня по входам/ выходам, началу и результату процесса. Чтобы минимизировать временные затраты на согласование, рекомендуется проводить его в формате деловых игр, построенных по принципу докладов, в которых рабочие группы «моделируют» свой процесс, проговаривают его от момента начала до получения итогового результата, а остальные участники (владельцы процессов, представители группы управления проектом, куратор проекта, технические эксперты) вносят необходимые корректировки. При необходимости в ходе деловых игр участники игры вырабатывают совместные решения по спорным вопросам, возникающим в ходе описания бизнес-процессов. Как правило, в результате согласования происходит корректировка структуры процессов в бизнес-модели компании.

Полученная первая версия бизнес-модели компании подлежит дальнейшей декомпозиции — разрабатываются модели 3-го, 4-го уровня. Согласование данных моделей проводится в формате деловой игры с привлечением владельца процесса, представителей группы управления проектом, владельцев процессов-потребителей результатов бизнес-процесса, технических экспертов. В ходе согласования уточняется движение информационных потоков и потоков объектов, уточняются должности руководителей, ответственных за выполнение процессов, состав участников на уровне структурных подразделений и должностей сотрудников.

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

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

Этап седьмой — внедрение

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

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

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

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

Вместо заключения

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

Введение

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

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

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

процессов составила методология SADT. В настоящее время наиболее широко используемая методология описания бизнес-процессов – стандарт США IDEF.

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

моделирование бизнес-процессов это ответ практически на все вопросы,

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

1 Сущность и значение моделирования бизнес-процессов

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

Существует несколько подходов к определению понятия

«моделирование бизнес-процессов»:

1) моделирование бизнес-процессов - это описание бизнес-

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

2) моделирование бизнес-процессов - это эффективное средство поиска возможностей улучшения деятельности предприятия;

3) моделирование бизнес-процессов - это средство позволяющее предвидеть и минимизировать риски, возникающие на различных этапах реорганизации деятельности предприятия;

4) моделирование бизнес-процессов - это метод, позволяющий дать оценку текущей деятельности предприятия по отношению к требованиям,

предъявляемым к его функционированию, управлению, эффективности,

конечным результатам деятельности и степени удовлетворенности клиента

5) моделирование бизнес-процессов - это метод, позволяющий дать стоимостную оценку каждому процессу, взятому в отдельности, и всем бизнес-процессам на предприятии, взятым в совокупности;

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

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

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

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

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

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

Решения по моделированию бизнес-процессов обычно принимается по причинам, представленным на рисунке 1.

Рисунок 1 - Причины, по которым принимается решение по моделированию бизнес-процессов

Моделирование бизнес-процессов затрагивает многие аспекты

деятельности компании:

 изменение организационной структуры;

 оптимизацию функций подразделений и сотрудников;

 перераспределение прав и обязанностей руководителей;

 изменение внутренних нормативных документов и технологии проведения операций;

 новые требования к автоматизации выполняемых процессов и т.

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

Моделирование бизнес-процессов организации включает два этапа структурное и детальное.

Структурное моделирование бизнес-процессов организации может выполняться в нотации IDEF0 с использованием инструментария BPwin или на языке UML с использованием инструментария Rational Rose. Детальное моделирование выполняется на языке UML.

На этапе структурного моделирования в модели должны быть отражены:

1) существующая организационная структура;

2) документы и иные сущности, используемые при исполнении моделируемых бизнес-процессов и необходимые для моделирования документооборота, с описаниями их основного смысла;

3) структуру бизнес-процессов, отражающую их иерархию от более общих групп к частным бизнес-процессам;

4) диаграммы взаимодействия для конечных бизнес-процессов,

отражающие последовательность создания и перемещения документов

(данных, материалов, ресурсов и т.п.) между действующими лицами.

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

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

Детальная модель бизнес-процесса должна включать:

1) набор прецедентов отражающих возможные варианты выполнения бизнес-процессов «как есть»;

2) диаграммы действий, детально описывающие последовательность выполнения бизнес-процессов;

3) диаграммы взаимодействия, отражающие схемы документооборота.

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

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

2 Методика проведения моделирования бизнес-процессов

Под методологией (нотацией) создания модели (описания) бизнес-

процесса понимается совокупность способов, при помощи которых объекты реального мира и связи между ними представляются в виде модели. Любая методология (методика) включает три основные составляющие:

– теоретическая база;

–описание шагов, необходимых для получения заданного результата;

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

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

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

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

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

инструментом реорганизации бизнес-процессов в рамках создания системы автоматизации.

Необходимо учитывать важные характеристики моделирования бизнес-

процессов. В частности, к преимуществам моделирования бизнес-процессов относят: повышение качества и скорости производства продукции с одновременным снижением издержек; рост профессионализма сотрудников;

повышение конкурентоспособности компании. Недостатки, в свою очередь:

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

3 История развития методологий моделирования бизнес-процессов

Основу многих современных методологий моделирования бизнес-

процессов составила методология SADT (Structured Analysis and Design Technique – метод структурного анализа и проектирования) и

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

В сжатом виде история развития методологий моделирования бизнес-

процессов представлена на рисунке 2. Для наглядности параллельно приведена история развития подходов к управлению качеством .

Рисунок 2 - История развития методологий моделирования бизнес-

процессов

В настоящее время для описания, моделирования и анализа бизнес-

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

 моделирования бизнес-процессов (Business Process Modeling);

 описания потоков работ (Work Flow Modeling);

 описания потоков данных (Data Flow Modeling).

Методологии моделирования бизнес-процессов (Business Process Modeling). Наиболее широко используемая методология описания бизнес-

процессов – стандарт США IDEF0. С момента разработки стандарт не претерпел существенных изменений. В настоящее время развитие методологии IDEF0 сопряжено с совершенствованием поддерживающих ее инструментов – программных продуктов для моделирования бизнес-

процессов (например, BPWin 4.0, ProCap, IDEF0/EM Tool и др.).

Методология IDEF0 предоставляет аналитику широкие возможности для описания бизнеса организации на верхнем уровне с акцентом на управление процессами. Нотация позволяет отражать в модели процесса обратные связи

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

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

настоящий момент к семейству IDEF можно отнести следующие стандарты:

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

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

IDEF1X (IDEF1 Extended) – методология построения реляционных структур. IDEF1X относится к типу методологий ―Сущность-взаимосвязь‖

(ER – Entity-Relationship) и, как правило, используется для моделирования реляционных баз данных;

IDEF2 – методология динамического моделирования развития систем.

В связи с весьма серьезными сложностями анализа динамических систем от этого стандарта практически отказались, и его развитие приостановилось на самом начальном этапе;

IDEF3 – методология документирования процессов, происходящих в системе, которая используется, например, при исследовании технологических процессов на предприятиях. С помощью IDEF3

описываются сценарий и последовательность операций для каждого процесса. IDEF3 имеет прямую взаимосвязь с методологией IDEF0 – каждая

функция может быть представлена в виде отдельного процесса средствами

IDEF4 – методология построения объектно-ориентированных систем.

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

IDEF5 – методология исследования сложных систем .

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

ARIS поддерживает четыре типа моделей, отражающих различные аспекты исследуемой системы:

организационные модели, представляющие структуру системы -

иерархию организационных подразделений, должностей и конкретных лиц,

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

функциональные модели, содержащие иерархию целей, стоящих перед аппаратом управления, с совокупностью деревьев функций,

необходимых для достижения поставленных целей;

информационные модели, отражающие структуру информации,

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

модели управления, представляющие комплексный взгляд на

реализацию бизнес-процессов в рамках системы.

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

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

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

Книга:

Введение

Введение

В настоящее время государственные и негосударственные организации Российской Федерации начинают активно реализовывать проекты по созданию бизнес-моделей. Данная активность не является данью некой новой «технологической» моде – для нее существуют вполне объяснимые причины, связанные с действием совокупности объективных экономических и организационно-правовых факторов. Во-первых, наличие документированной бизнес-архитектуры предприятия является обязательным условием его сертификации как по международным стандартам ISO 9001:2000, так и по российским ГОСТ Р ИСО 9001–2001. Более того, в настоящее время в ряде развитых зарубежных стран приняты стандарты, определяющие требования к структуре и порядку построения бизнес-архитектуры. Во-вторых, в условиях все возрастающих инвестиций в информационно-технологическую инфраструктуру организации предварительное моделирование ожидаемых изменений в бизнес-процессах и оценки эффектов является одним из основных инструментов обоснования и оптимизации расходов на модернизацию.

Наличие в организации документированной бизнес-архитектуры является одним из характеристик ее управленческой зрелости, дополнительным фактором инвестиционной привлекательности. Такое понимание роли и места модели бизнес-процессов в жизни современного предприятия полностью соответствует современной государственной политике Российской Федерации в области совершенствования механизмов управления в Российской Федерации в целом. В частности, в проекте документа «Стратегия развития и использования информационных и коммуникационных технологий в Российской Федерации», разработанной Минсвязи России, количество предприятий и организаций, имеющих разработанную модель бизнес-архитектуры, является одним из ключевых целевых показателей реализуемого на уровне государства процесса информатизации. В этом документе указывается, что «при формировании программ и проектов информатизации федеральных органов исполнительной власти недостаточное внимание уделяется вопросам экономической эффективности их реализации, функциональному анализу и оптимизации управленческих и административных процессов в деятельности ведомств». При этом к ожидаемым результатам реализации стратегии относятся:

? увеличение доли федеральных органов государственной власти, выполнивших описание и оптимизацию административно-управленческих процессов, с 7 % до 60 %;

? увеличение доли органов государственной власти субъектов Российской Федерации, выполнивших описание и оптимизацию административно-управленческих процессов, с 5 % до 50 %.

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

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

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

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

Архитектура предприятий по своей сути является некоторым механизмом, который обеспечивает прозрачность представления, «трансформацию» «стандарных» услуг (деятельности) правительства в электронные регламенты, основанные на использовании современных ИТ. В каждой из стран существует своя специфика в организации, наименовании и стандартизации проектов по созданию электронного правительства. Например, в США реализуется проект «Федеральная архитектура», в Германии – «Стандарты и архитектура прикладных систем электронного правительства» (SAGA – Standards and Architecture for e-Government Applications). Однако при всем многообразии специфик реализации основной лейтмотив заключается в процессном подходе организации деятельности государства по предоставлению на современной технологической основе услуг гражданам и бизнесу. Соответственно, проектирование национальной инфраструктуры государственных информационных систем осуществляется в контексте обеспечения эффективной реализации государственных функций.

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

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

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

В качестве примера можно привести один из результатов такой разобщенности, озвученный бывшим министром обороны США Дональдом Рамсфельдом: «Наличие 673 различных и нескоординированных систем финансового учета сделало невозможным найти следы транзакций на общую сумму в 2,3 млрд долларов» .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2. Что такое модель бизнес-процессов. Типовая архитектура модели бизнес-процессов. В главе представлены основные теоретические вопросы, понимание которых необходимо для дальнейшего рассмотрения проблематики моделирования, а именно: классификация моделей, виды анализа, а также варианты улучшения бизнес-процессов в организации.

3. Как проектировать архитектуру модели бизнес-процессов организации: методические рекомендации и подходы по разработке.

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

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

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