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

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

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

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

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

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

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

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

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. Контроль над внедрением.

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

Предисловие

Управление бизнес-процессами – важнейший элемент системы управления современной компании. Методики процессного управления активно развиваются. Появляются новые и совершенствуются существующие инструменты для описания и регламентации бизнес-процессов. Активно используются подходы и инструменты для управления процессами на основе показателей (метрик). Но собственникам и руководителям компаний подчас не хватает системного понимания возможностей процессного подхода и методов его внедрения. Для совершенствования управления нужно системно представлять себе существующие возможности. Эта книга – о концепции внедрения и возможностях современных методик и инструментов. Моя цель – передать системную картину, необходимые методики и практический опыт внедрения. Надеюсь, что осмысление опыта десятков консалтинговых проектов, проведения обучения сотрудников компаний позволит это сделать.
Глава 1 посвящена общей концепции внедрения процессного подхода, разъяснению основных терминов и определений. В ней приводится обоснование эффективности внедрения процессного подхода, рассматриваются типовой план проекта внедрения и необходимые для этого методики и инструменты.
В главе 2 обсуждается один из важнейших методов – определение, анализ и реорганизация сквозных (межфункциональных) процессов. Рассматриваются подходы к организации управления сквозными процессами в масштабах компании.
Глава 3 раскрывает подход к построению системы бизнес-процессов. В ней читатель узна́ет о наиболее популярных методах, найдет практические рекомендации по построению системы процессов компании и примеры.
Глава 4 посвящена вопросам описания процессов на операционном уровне. Обсуждаются часто используемые методики моделирования, вопросы создания электронного репозитория компании. Приводятся примеры схем бизнес-процессов в формате Work Flow.
В главе 5 подробно описаны построение в организации системы стандартизации бизнес-процессов, плюсы и минусы регламентации. Рассмотрены процедуры управления жизненным циклом нормативно-методических документов и автоматическая генерация регламентов при помощи современных систем бизнес-моделирования.
Глава 6 посвящена определению процессов управления и разработке показателей для управления процессами. Приводятся примеры показателей. Обсуждаются вопросы мониторинга процессов и выполнения корректирующих действий, совершенствования процессов на основе цикла PDCA.
Надеюсь, что книга принесет пользу как собственникам и руководителям компаний, так и специалистам подразделений организационного развития, бизнес-аналитикам, специалистам по менеджменту качества.

Глава 1
Процессный подход: концепция внедрения в организации

1.1. Зрелость компании в области процессного управления

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

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

Руководителю организации важно не только самому проникнуться идеей процессного управления, но и донести свою убежденность до сотрудников. Именно поэтому исключительно важны система терминов и концепция внедрения. Опыт показывает, что успеха добивались те компании, руководители которых создали собственную логичную и понятную концепцию внедрения процессного подхода и, прикладывая в течение нескольких лет немалые усилия, сумели ее реализовать. Важно создать систему управления, неотъемлемой частью которой станет управление процессами. Такую систему невозможно внедрить в приказном порядке или купить (например, в виде какой-либо автоматизации). Вопрос, скорее, в создании определенной культуры работы с процессами на всех уровнях управления.
В главе 1 приводятся необходимые термины и определения, а затем обсуждается концепция внедрения процессного управления. Руководители организаций могут использовать материалы этой главы для уточнения собственного ви́дения целей и задач внедрения процессного подхода, концепции внедрения, для разработки основных методических документов в области процессного управления .
Глава написана для тех, кто готов положить в основу своей деятельности систему управления, основанную на процессном подходе.
Перед тем как приступить к освоению методов процессного управления, оцените уровень зрелости своей организации. Для этого есть несколько способов, и я приведу пример одной из возможных моделей . Концепция уровней зрелости процесса (Process Maturity Levels) была создана в Институте программной инженерии (Software Engineering Institute, SEI) при Университете Карнеги – Меллона в 1990-е гг. В ее основу положена работа Уотса Хамфри. Впервые разработанная для поддержки анализа зрелости процесса программирования (CMM), последняя версия, интегрированная модель технологической зрелости (Capability Maturity Model Integrated, CMMI), была обобщена для любого из широкого спектра процессов в различных организациях (рис. 1.1.1).

Рис. 1.1.1. Обзор основных уровней зрелости по модели СММI

Приведу краткое описание каждого из уровней, указанных на рис. 1.1.1.

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

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

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

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

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

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

На каком уровне зрелости находятся российские компании?
Считаю, что большинство российских организаций находится на первом или на втором уровне зрелости, некоторые приближаются к третьему, небольшая часть – к четвертому. Очень мало организаций, работающих на пятом уровне.
На мой взгляд, для определения зрелой с процессной точки зрения организации можно использовать следующие критерии:
наличие и поддержание в актуальном состоянии архитектуры (системы) бизнес-процессов компании (система BPA);
действующая система стандартизации (регламентации) деятельности (в первую очередь процессов); использование системы класса ECM для поддержки жизненного цикла нормативно-методических документов (регламентов, положений, инструкций);
наличие и активное использование для мониторинга, анализа, улучшения и стимулирования системы показателей (метрик) по бизнес-процессам; используется система BI /BPM;
наличие компетентных специалистов в области моделирования, анализа и регламентации бизнес-процессов в каждом функциональном подразделении;
наличие центра компетенции (департамента /отдела) по организационному развитию с представителями в каждом департаменте (функциональное подчинение);
автоматизация наиболее важных сквозных процессов в BPMS .

Рис. 1.2.1. Структурная схема процесса

1.2. Термины и определения процессного подхода

1.2.1. Структурная схема процесса

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

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

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

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

С точки зрения состояния ресурсы могут:
храниться;
перемещаться;
находиться в состоянии обработки.

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

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

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

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

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

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

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

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

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

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

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

1.2.2. Границы процесса

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

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

Пусть ресурс «А» является результатом преобразования в некотором процессе (рис. 1.2.2). С точки зрения владельца этого процесса ресурс «А» – выход. С точки зрения владельца процесса-потребителя ресурс «А» – вход. В момент передачи ресурса «А» от одного процесса к другому происходит переход ответственности за этот ресурс между владельцами процессов. Факт движения ресурса, сопровождающийся переходом ответственности, может быть идентифицирован при помощи события. С точки зрения владельца первого процесса это событие завершает процесс, с точки зрения владельца второго процесса – инициирует его. Одно и то же событие может быть сформулировано по-разному при описании границ двух рассматриваемых процессов. Первый владелец скажет, что ресурс «А» передан, а второй – что ресурс «А» получен. Чтобы при описании процессов было удобнее увязывать их в единую систему, лучше определять одно событие и давать ему примерно такую формулировку: «Ресурс “А” передан из процесса 1 в процесс 2» . В любом случае формулировки событий должны быть обязательно согласованы между владельцами процессов при регламентации границ.

Рис. 1.2.2. Границы процессов

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

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

Последний пример приведен в шутку. С практической точки зрения такая формулировка события недопустима. Лучше сформулировать так: «Поступило распоряжение руководителя приступить к выполнению работы» (желательно в письменной форме или хотя бы по e-mail).
Заметим, что переход ответственности за ресурсы возможен и внутри процесса, по ходу выполнения работы различными сотрудниками. Соответствующие события могут использоваться для определения зон ответственности сотрудников внутри процесса.
Рассмотрим более сложные случаи, когда событие, завершающее один процесс, не является событием, инициирующим другой процесс. Допустим, в одном из подразделений организации сотрудник подготовил отчет и поместил его на сервер. Завершающее процесс событие можно сформулировать так: «Отчет подготовлен и размещен на сервере». Через некоторое время (например, в конце месяца) сотрудник другого отдела скачивает или открывает на сервере и использует необходимую информацию. Событие, инициирующее его процесс, казалось бы, можно зафиксировать как «Получен отчет такой-то». В реальности отчет мог пролежать на сервере несколько дней до того момента, пока им воспользовались. Как быть? Ответ в формулировке события, инициирующего второй процесс. Это можно сделать так: «Наступил срок подготовки сводного отчета». Далее сотрудник проверяет наличие отчета на сервере. Результат – следующее событие: «Отчет такой-то присутствует на сервере». Очевидно, что определение такого типа событий зависит от степени детализации при описании процесса.
Еще пример: рассмотрим отправку какого-либо документа по корпоративной электронной сети. Факт отправки документа сотрудником можно описать событием «Документ отправлен по e-mail». Однако сотрудник, которому отправлен данный документ, может его получить не сразу или вообще не получить (сбой сети, случайное удаление и т. п.). Значит, инициировать процесс второго сотрудника будет событие «Получен документ по e-mail». Очевидно, что это два разных события. В данном случае можно:

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Размещено на http://www.allbest.ru/

Министерство образования и науки РФ

Федеральное государственное бюджетное образовательное учреждение

высшего профессионального образования

Нижегородский государственный технический университет имени Р.Е. Алексеева

Институт Экономики и управления

Кафедра "Экономика, управление и финансы"

Курсовая работа

по дисциплине: "Моделирование бизнес-процессов и экономических систем"

на тему: «Моделирование бизнес-процессов. Основные этапы проекта по внедрению процессного подхода в компании»

Выполнил:

студент гр. 10ИНМк

Резвова А.В.

Проверил:

Ковылкин Д.Ю.

Нижний Новгород 2014 г.

Введение

1.2 Основные терминологии

2. Практическая часть

2.1 Исходные данные

2.2 Проектная часть

Заключение

Список использованных источников и литературы

Введение проектирование управление процессный

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

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

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

1. Основные этапы проекта по внедрению процессного подхода в компании

1.1 Возможности процессной системы управления

В настоящее время многие российские предприятия занимаются внедрением процессного подхода к управлению, проводят подготовку и сертификацию по стандартам ISO серии 9000:2000, автоматизируют деятельность при помощи корпоративных информационных систем (SAP R/3, BAAN и др.), внедряют системы стратегического управления. На практике часто складывается ситуация, когда в организации одновременно ведутся несколько проектов, которые частично дублируют задачи друг друга, непроизводительно расходуя ресурсы предприятия. Одновременно на предприятии могут проводиться следующие работы:

· отдел развития занимается описанием и реинжинирингом бизнес-процессов с использованием методик ARIS или IDEF для целей улучшения управления;

· служба по качеству описывает и регламентирует бизнес-процессы в своем формате для целей внедрения системы качества (СК) или системы менеджмента качества (СМК);

· служба информатизации (IT-подразделение) собирает информацию по бизнес-процессам для подготовки и внедрения ERP-системы.

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

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

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

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

· порядок планирования целей и деятельности;

· взаимодействие между процессами и подразделениями предприятия;

· ответственность и полномочия должностных лиц, в т.ч. владельцев процессов;

· порядок работы и действий в нештатных ситуациях;

· порядок и формы отчетности перед высшим руководством;

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

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

Внедрение на предприятии СУБП в первую очередь подразумевает работу по описанию и регламентации бизнес-процессов, в рамках которой:

· проводится распределение ответственности за результаты работ, входящих в состав процессов;

· определяется система взаимодействия процессов между собой и с внешними поставщиками и потребителями;

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

· составляется график разработки и внедрения этой документации;

· устанавливаются показатели деятельности процессов, способы и формы сбора информации и порядок отчетности перед руководителями;

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

· устанавливаются критерии, по которым начинается работы по устранению причин отклонения.

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

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

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

· показатели продуктов, производимых процессами предприятия;

· показатели удовлетворенности клиентов результатами работы.

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

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

· система основана на измерении показателей деятельности предприятия, планировании и достижении непрерывного улучшения результатов деятельности;

· система направлена на удовлетворение потребностей 5 групп лиц, заинтересованных в деятельности организации:

A. 1) соучредители (инвесторы);

2)потребители на рынке;

3) персонал организации;

4) поставщики.

5) общество.

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

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

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

1.2 Основные терминологии

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

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

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

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

Документооборот - система документального обеспечения деятельности предприятия.

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

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

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

Показатели продукта (услуги)(ПП) - параметры продукта бизнес-процесса.

Показатели (данные) удовлетворенности клиента (потребителя) (ДУК) - параметры удовлетворенности клиента.

Поставщик - субъект, предоставляющий ресурсы.

Потребитель (клиент) - субъект, получающий результат бизнес-процесса. Потребитель может быть:

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

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

Операция (работа) - часть бизнес-процесса.

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

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

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

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

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

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

1.3 Процессный подход: концепция внедрения в организации

Для определения зрелой с процессной точки зрения организации можно использовать следующие критерии:

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

* Действующая система стандартизации (регламентации) деятельности (в первую очередь процессов);

* Наличие и активное использование для мониторинга, анализа, улучшения и стимулирования системы показателей (метрик) по бизнес-процессам;

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

* Наличие центра компетенции (департамента отдела) по организационному развитию с представителями в каждом департаменте (функциональное подчинение);

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

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

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

С точки зрения состояния ресурсы могут: A. Храниться; B. Перемещаться; C. Находиться в состоянии обработки.

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

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

Ресурс по управлению - необходимый для управлен-я процессом.

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

Выход процесса - преобразованный при выпо-нении процесса ресурс.

Обеспечивающие ресурсы могут:

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

* Выделяться процессу на постоянной основе.

В реальной жизни обеспечивающие ресурсы меняются:

A. Сотрудники приобретают опыт, стареют и так далее;

B. Оборудование изнашивается;

C. ПО морально устаревает.

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

В целом владелец процесса - это руководитель, способ-ый как минимум:

1. Проводить мониторинг хода процесса;

2. Анализировать факторы, влияющие на процесс и приводящие к вариациям;

3. Разрабатывать предложения по улучшению процесса и организовывать их обсуждения и согласования;

4. Координировать или управлять внутренние совершенствования процесса.

2. Практическая часть

2.1 Исходные данные

В данном разделе осуществляется моделирование описанного ранее бизнес-процесса с использованием нотации моделирования IDEF0 семейства стандартов IDEF.

Создание контекстной диаграммы

Рассматриваются некие продажи через интернет магазин.

Основные процедуры в продаже через интернет магазин таковы:

· Обработка заявки клиента

· Сборка товара на складе

· Подготовка документации

· Доставка

Рис.1 Контекстная диаграмма - 1-й уровень декомпозиции

2.2 Проектная часть

Создание диаграммы декомпозиции

В диалоге «Activity Box Count» устанавливаем число работ на диаграмме нижнего уровня - 4 - и нажимаем ОК.

Рис.2 Диалог «Activity Box Count»

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

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

2.3 Создание диаграммы декомпозиции A1

Декомпозируем работу «Поверка и внесение заказа».

Рис.4 Результаты декомпозиции подпроцесса «Обработка заявки клиента» 3-й уровень декомпозиции

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

2.4 Создание диаграммы декомпозиции A2

Декомпозируем работу «товар»

Рис 5. Результаты декомпозиции подпроцесса «Сборка товара на складе» 3-й уровень декомпозиции.

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

2.5 Создание диаграммы декомпозиции A3

Декомпозируем работу «Подготовка накладной»

Рис. 6 Результаты декомпозиции подпроцесса «Подготовка документации» 3-й уровень декомпозиции.

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

2.6 Создание диаграммы декомпозиции А4

Декомпозируем работу «Наличие накладной»

Рис.7. Результаты декомпозиции подпроцесса «Доставка» 3-й уровень декомпозиции.

Завершающий процесс. На входе сразу 3 стрелки: сформированные заявки клиентов, чеки, маршрутый лист. Пройдя через все блоки получаем на выходе товар и чек доставленные клиенту.

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

Из проведенной работы можно сделать вывод о успешном моделировании бизнес-процесса «Продажи через интернет магазин».

Была произведена декомпозиция бизнес-процесса «Продажи через интернет магазин» которая включила в себя 4 уровня декомпозиции: «Обработка заявки на складе», «Сборка товара на сладе», Подготовка документации», «Доставка». На 3 уровне декомпозиции включает в себя диаграммы декомпозиции всех подпроцессов составляющих бизнес-процесс контекстной диаграммы.

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

Заключение

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

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

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

Список используемой литературы

1. Моделирование бизнес-процессов и экономических систем: методические указания для выполнения курсовой работы студентам, обучающимся по профилю «Информационный менеджмент» направления 080200 «Менеджмент»/НГТУ; сост.: Д.Ю. Ковылкин. Н.Новгород, 2014. - 30 c.

2. Лекции по дисциплине «Инструментальные средства моделирования сложных систем», Д.Ю.Ковылкин. 2014.

Размещено на Allbest.ru

Подобные документы

Определение процессного подхода к управлению организацией. Моделирование бизнес-процессов; объекты и связи в IDEF0, преимущества и недостатки их использования. Процессно-организационная бизнес-модель компании ОАО "Урал"; паспорт процесса "Продажа".

курсовая работа , добавлен 03.05.2014


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

дипломная работа , добавлен 21.03.2013


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

курсовая работа , добавлен 25.05.2009


Эффективное внедрение процессного подхода. Основные виды бизнес-процессов. Вопросы управления бизнес-процессами. Проект реинжиниринга бизнес процессов организации. Общая характеристика организации ООО "Мир стекла". Разработка бизнес-процесса организации.

курсовая работа , добавлен 17.11.2014


Целесообразность внедрения процессного управления на ООО "Мир Алюминия". Разработка рекомендаций и механизма оптимизации основных бизнес-процессов как пути совершенствования системы управления на исследуемом предприятии. Моделирование бизнес-процессов.

дипломная работа , добавлен 08.01.2012


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

дипломная работа , добавлен 28.04.2011


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

реферат , добавлен 16.07.2016


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

контрольная работа , добавлен 22.02.2017


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

курсовая работа , добавлен 25.01.2016


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

Введение

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

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

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

процессов составила методология 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 поддерживает четыре типа моделей, отражающих различные аспекты исследуемой системы:

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

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

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

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

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

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

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

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

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

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

Существует несколько подходов к определению понятия «моделирование бизнес-процессов»:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Бизнес-стратегия есть теория, бизнес-модель - гипотеза.

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

Набор составляющих процесс шагов - бизнес-функций;

Порядок выполнения бизнес-функций;

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

Исполнителей каждой бизнес-функции;

Входящие документы/информацию, исходящие документы/информацию;

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

Документацию/условия, регламентирующие выполнение каждой бизнес- функции;

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

Для моделирования бизнес-процессов можно использовать различные методы. Метод, или методология, моделирования включает в себя последовательность действий, которые необходимо выполнить для построения модели, т. е. процедуру моделирования, и применяемую нотацию (язык). Наиболее популярной методологией бизнес-моделирования является ARIS, но также известны Catalyst компании CSC, Business Genetics, SCOR (Supply Chain Operations Reference), POEM (Process Oriented Enterprise Modeling) и др. Язык моделирования имеет свой синтаксис (условные обозначения различных элементов и правила их сочетания) и семантику (правила толкования моделей и их элементов). В теории и на практике существуют различные подходы к построению и отображению моделей бизнес-процессов, основными из которых являются функциональный и объектно-ориентированный. В функциональном подходе главным структурообразующим элементом является функция (бизнес-функция, действие, операция), и система представляется в виде иерархии взаимосвязанных функций. При объектно-ориентированном подходе система разбивается на набор объектов, соответствующих объектам реального мира и взаимодействующих между собой посредством посылки сообщений .

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

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

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

Модели бизнес-процессов применяются предприятиями для различных целей, что определяет тип разрабатываемой модели.

Рассмотрим основные случаи, при которых все-таки нужно описывать бизнес-процессы:

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

· Оптимизация деятельности предприятия. Модернизация и улучшение процессов помогают решить как организационные, так и технологические вопросы, повышая качество конечного продукта (товара/ услуги).

· Проведение сертификации организации по стандартам ISO и тиражирование процессов. Создание единой структуры взаимосвязанных процессов системы менеджмента качества, однозначно понимаемой всеми сотрудниками организации.

Само описание процесса может быть выполнено разными способами, а именно:

Текстовое описание процесса

При нем вся последовательность операций процесса описывается в простой текстовой форме (регламенты, стандарты).

Пример описания процесса «Инициация нового проекта»:

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

2. Данные анализа процесса направляются в отдел бизнес-процессов.

3. На основании полученных данных отдел бизнес-процессов проводит предпроектную работу (выработка предложений по улучшению процесса, разработка альтернативных вариантов процесса).

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

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

Табличное описание процесса

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

Таблица 1 - табличное описание бизнес процесса, пример описания процесса «Разработка нового проекта»

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

Графическое описание процесса

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

Что нужно отобразить в описании процесса

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

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

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