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

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

Введение

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

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

1. Сокращение длительность бизнес-процессов.

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



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

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

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

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

ARIS. Сейчас можно отметить тенденцию интеграции разных способов моделирования и анализа систем. Проявляется она в том, что создаются интегрированные средства моделирования бизнес-процессов. Одно из них - продукт немецкой компании 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). Диаграммы последовательности (и кооперативные диаграммы), описывающие сценарии Business Use Case как последовательность обмена сообщениями между объектами - действующими лицами и объектами, являющимися исполнителями. Благодаря таким диаграммам можно определять, какими обязанностями должен быть наделен тот или иной исполнитель, и отображать в модели набор его операций. Диаграммы деятельности, описывающие взаимосвязь между сценариями одного или нескольких Business Use Case. Диаграммы состояний, описывающие, как себя ведут отдельные бизнес-процессы. В методике моделирования Rational Unified Process есть определенные достоинства: построение модели бизнес-процессов ведется вокруг заинтересованных людей, участвующих в процессе, и их задач; благодаря модели можно понять, что нужно клиентам компании. Подход используется, по большей части, для фирм, работающих в отрасли оказания услуг (торговые и страховые предприятия, банковские организации); при помощи моделирования, основой для которого становятся варианты использования, заказчики лучше понимают бизнес-модели. Но стоит подчеркнуть, что при моделировании работы крупного предприятия, которое как производит продукцию, так и оказывает услуги, пользоваться нужно разными способами создания моделей. Это обусловлено тем, что, к примеру, при моделировании производственных процессов лучше применять процессное моделирование бизнес-процессов, в частности, метод Eriksson-Penker. IBM WebSphere Business Modeler IBM WebSphere Business Modeler позволяет моделировать и имитировать бизнес-процессы, анализировать и создавать отчеты для их усовершенствования. У системы есть ряд преимуществ, среди которых: Обширные и лучшие в своем классе возможности для анализа, имитации и моделирования. Непрерывное улучшение процессов. Усовершенствованные возможности интеграции. Улучшенные сроки возврата инвестиций. Усовершенствованные функции разработки. Главной особенностью являются более обширные возможности для имитации бизнес-процессов. В модели можно добавлять бизнес-величины, вычленять дополнительные данные. Также можно экспортировать модели в форматах, используемых в других приложениях. При импорте или определении моделей из иных источников возможно проведение более точного анализа действия бизнес-процессов. Можно связывать процессы с информационными моделями, организациями, ресурсами. Благодаря настраиваемым и стандартным отчетам возможен обмен данными анализа. Допускается реализация одновременно нескольких версий моделей и публикация моделей процессов.

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

IDEF0. При комплексном подходе к управлению в основном пользуются стандартом моделирования бизнес-процессов IDEF0, так как это классический метод. Ключевой принцип подхода заключается в том, что деятельность компании структурируется на основе ее бизнес-процессов, а не организационно-штатной схемы. Бизнес-процессы, формирующие значимый результат для потребителя, являются наиболее ценными, а в будущем необходимо их улучшать. Стандарт моделирования бизнес-процессов IDEF0 - это совокупность процедур и правил, предназначенных для разработки функциональной модели объекта определенной предметной области. Модель IDEF0 - это серия диаграмм с сопроводительными документами. Диаграммы разбивают многоступенчатый объект на несколько составляющих (блоков), что существенно упрощает процесс. Детали всех блоков показаны как блоки на других диаграммах. Все детальные диаграммы - это декомпозиции блока из предшествующего уровня. На каждом этапе декомпозиции диаграмму предшествующего уровня именуют родительской для более детализированной диаграммы. Общее количество уровней в модели - не более 5-6. Опыт показывает, что этого вполне хватает, чтобы построить полную функциональную модель современной компании, работающей в любой сфере. IDEF1. Изначально стандарт IDEF1 вырабатывался, чтобы стать инструментом для анализа и изучения связи между потоками информации в рамках финансовой деятельности предприятия. Моделирование бизнес-процессов по методике IDEF1 призвано показать, как должна выглядеть информационная структура компании. Информационное моделирование бизнес-процессов включает несколько составляющих. Главные элементы - это: диаграммы - рисунки информационной модели с определенной структурой, представляющие взаимосвязь и состав используемых данных на основе набора правил; словарь - каждый элемент модели сопровождает текстовое описание. Основное понятие в IDEF1 - сущность, которую определяют как абстрактный или реальный объект, наделенный совокупностью известных отличительных свойств. У каждой сущности есть атрибуты и имя. IDEF2. Поскольку анализировать динамические системы достаточно сложно, в данный момент стандарт почти не используют, и он, едва появившись, перестал развиваться. Сегодня есть алгоритмы и их компьютерные реализации, при помощи которых становится возможным превращение набора статистических программ 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 Диаграммы информационных потоков DFD - это иерархия функциональных процессов, связывающих потоки информации. Целью представления является демонстрация преобразования каждым процессом входных данных в выходные, а также выявление отношений между процессами. По этому методу модель системы определяют в виде иерархии диаграмм информационных потоков, описывающих асинхронный процесс преобразования данных от их ввода в систему до выдачи пользователю. Информационные источники (сущности извне) порождают потоки информации, переносящие данные к процессам или подсистемам. Те же преобразуют данные в новые потоки, которые передают сведения к другим подсистемам или процессам, накопителям информации или внешним сущностям - потребителям данных. В диаграммах потоков информации есть ряд составляющих, ключевые из которых: внешние сущности; системы и подсистемы; процессы; накопители информации; информационные потоки. Внешнюю сущность обозначают в виде квадрата, который находится над диаграммой и бросает на нее тень. Так удобнее выделять символ среди остальных. Подсистему идентифицируют по номеру - для этого он и предназначен. В поле имени вводят ее название в виде предложения, где есть подлежащее, соответствующие дополнения и определения. Процесс является преобразованием по определенному алгоритму входных информационных потоков в выходные. Физически он реализуется рядом способов: созданием в компании отдела, осуществляющего обработку входной документации, отчетов; подготовкой программ; использованием логического устройства в виде аппарата и т.д. Процесс, как и подсистему, идентифицируют по номеру. В поле имени вносят название процесса - предложение, где есть активный недвусмысленный глагол в неопределенной форме (рассчитать, просчитать, получить, проверить), за ним в винительном падеже ставят существительные, к примеру: "Ввести информацию о текущих затратах", "Проверить поступление средств" и т.д. Об отделе компании, программе или аппаратном устройстве, выполняющем данный процесс, узнают благодаря сведениям из поля физической реализации. Накопитель данных является абстрактным устройством, где хранят информацию. Эти данные в любой момент можно перенести в накопитель и, спустя определенное время, вычленить. При этом варианты размещения и вычленения могут быть разными. В качестве накопителя информации можно использовать ящик в картотеке, микрофишу, таблицу, файл и т.д. Накопителю данных присваивают произвольное число и букву D. Название накопителя подбирают так, чтобы, смотря на него, проектировщик получал максимум информации. Как правило, накопитель информации - прообраз будущей базы данных. Хранящиеся в нем сведения должны соответствовать модели. Поток данных определяет сведения, которые передаются через некоторое соединение от источника к приемнику. Поток сведений на диаграмме отражают в виде линии, которая заканчивается на стрелку, показывающую, куда движется поток. У каждого потока данных есть имя, которое отражает содержащуюся в нем информацию. Строительство иерархии DFD требуется, прежде всего, для ясного и понятного описания системы на всех уровнях детализации, а также разделения этих уровней на несколько частей с определенной взаимосвязью.

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

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

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

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

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

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



2. Цели моделирования бизнес-процессов

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

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

специалист по управлению качеством; бизнес-аналитик(и);

представитель ИТ-подразделения;

внешний консультант (не обязательно).

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

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

· чтобы своевременно получать данные;

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

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

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

· чтобы выполнять обязанности перед бизнес-партнерами или бизнес-сообществом (например, по сертификации предприятия),

· чтобы удовлетворять действующим правовым нормам,

· чтобы обучать сотрудников или вводить в курс дела,

· чтобы избегать потерь знаний (например, при увольнении сотрудника)

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

- Подготовка / проведение оптимизации бизнес-процессов:

· чтобы вводить новые организационные структуры,

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

· чтобы перестраивать или улучшать процессы предприятия.

- Подготовка автоматизации и внедрения информационных технологий,

- Установление показателей процесса и контроля результативности, партнерами и конкурентами.

- Нахождение Best Practice (лучшего опыта в компании, регионе, отрасли)

2.1 Бизнес модель

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

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

· Табличный;

· Текстовый.

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

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

· дерево (иерархический список) бизнес-процессов - графические модели бизнес-процессов;

· модель организационной структуры-модели целей и показателей (стратегические карты BSC / KPI);

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

· модели продуктов и услуг.

· модели по менеджменту качества и многое другое.

Все эти модели позволяют разработать профессиональные программные продукты бизнес-моделирования (ППБМ).

Более 10 лет автор использует в проектах и собственных разработках большинство известных на рынке ППБМ решений: Business Studio, ARIS, AllFusion Process Modeler (BPWIN), Бизнес-инженер, Microsoft Visio. У каждого из них есть свои функциональные особенности, ограничения и преимущества. В программном продукте Business Studio автором ведётся разработка "Комплексной типовой бизнес-модели коммерческого банка", которая представляет интерес для финансовых организаций.

Рис. Дерево бизнес-процессов банка (верхний уровень)



Рис. Модель организационной структуры банка (верхний уровень)

Рис. Модель библиотеки документов банка (фрагмент)

2.2 Особенности практического применения

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

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

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

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

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

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

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

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

2. Простыми и понятными рядовым сотрудникам организации;

3. Практически направленными, иметь достаточно "быстрые", и в то же время, долгосрочные результаты;

4. Учитывали специфику менеджмента российских компаний;

5. Содержали примеры и типовые решения.

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

1. Ориентация на потребителя;

2. Лидерство руководителя;

3. Вовлечение работников;

4. Процессный подход;

5. Системный подход к менеджменту;

6. Постоянное улучшение;

7. Принятие решений, основанное на фактах;

8. Взаимовыгодные отношения с поставщиками.

Действительно, несоблюдение даже 1-2 принципов может оказать негативное влияние на развитие организации.

2.3 Цель и задача

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

· Цель - то чего мы хотим достичь.

· Задача - то что необходимо сделать чтобы достичь цели.

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

К примеру цель "Увеличить эффективность производства", не понятна. Необходимо четко определить на сколько увеличить эффективность и в какой срок. Так что меняем формулировку "Увеличить эффективность производства на 10 % к 1 апреля 2014 года".

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

Если понятие спорно - дайте конкретную методику расчета данного показателя.

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

Итак, какие цели вы можете поставить исходя из текущей ситуации? Для этого необходимо просмотреть карту основных процессов и список всех бизнес процессов и ответить на несколько вопросов:

· Что необходимо изменить в карте основных процессов? Какой она должна быть?

· Нужно ли изменить текущие процессы, участвующие в цепочке создания ценности, и если нужно, то как?

· Что в списке процессов вызывает сомнения и должно быть изменено?

· Как или на что, это должно быть изменено?

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

· Соответствуют ли текущие процессы нашему представлению о том, как это должно быть в компании?

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

Теперь согласуйте полученные цели и пожелания с целями компании.

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

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

Итак, можно ставить цели в следующих областях:

· Объединение процессов в один, или наоборот, разделение процессов.

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

· Изменение владельцев процессов.

· Перераспределение (изменение компоновки) процессов.

· Внедрение новых процессов.

· Устранение процессов из структуры компании.

· Изменение вспомогательных процессов или процессов управления.

· Цели, связанные с конкретными изменениями тех или иных показателей процессов. К примеру сокращение затрат на процесс.

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

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

Каждая задача должна иметь:

· Конкретный критерий ее выполнения - что именно должно быть выполнено, и как понято, что это собственно сделано.

· Срок выполнения.

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

· Ответственный - кто несет ответственность за данную задачу. Далеко не всегда исполнитель и ответственный это одно лицо.

· Ресурсы на выполнение задачи. Нужно указать что дается для того чтобы выполнить задачу.

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

Пример.

Цель - повысить эффективность процесса производства на 10 % к 1 апреля 2014 года.

Задача 1 - уменьшить использование расходных материалов на 15 % к 1 января путем усовершенствования оборудования. Ответственный - Иванов.

Задача 1.1 - Подобрать поставщика оборудования к 1 октября. Исполнитель - Т. Питерс.

Задача 1.2 - Согласовать бюджет закупки оборудования к 14 октября. Исполнитель - Т. Питерс.

И т.д.

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

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

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

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

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

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

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

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



3. Обзор нотаций

3.1 VAD (value adde chain diagram)

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

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

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

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

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

Модель нотации VAD можно нарисовать во множестве инструментов, например, в MS Visio, ARIS, Archi и многих других инструментах моделирования бизнес-процессов.

3.2 EPC (event-driven process chain)

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

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

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

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

Существует множество вариантов нотации EPC, в формате столбцов, строк, а также с разными перечнями используемых объектов, однако все эти варианты доступны только в инструментарии ARIS, тогда как в остальных инструментах, например, MS Visio или Business Studio доступно моделирование бизнес-процессов EPC лишь в классическом формате.

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

3.3 BPMN (Business Process Model and Notation 2.0)

Нотация BPMN создана консорциумом Object Management Group (OMG) и предназначена для моделирования бизнес-процессов с целью их последующей автоматизации. Нотация BPMN используется для детального моделирования бизнес-процесса, а количество объектов в данной нотации превышает 100, что позволяет описать все нюансы поведения бизнес-процессов для того, чтобы информационная система могла преобразовать созданную модель в исполняемый код.

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

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

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

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

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

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



Заключение

Итак, я рассмотрел некоторые нотации моделирования бизнес-процессов, которые можно встретить на российском рынке (более подробно они описаны в главе BPM CBOK, посвященной моделированию бизнес-процессов). Какую из нотаций выбрать для использования - это вопрос открытый, например, для моделирования бизнес-процессов организации на верхнем уровне я использую нотацию VAD, для первичного моделирования бизнес-процесса, выбранного для оптимизации, проще использовать SIPOC или VAD. Для создания детальных моделей бизнес-процессов - упрощённый BPMN для моделирования кросс-функционального взаимодействия или EPC для детального моделирования с целью формализовать информационный поток и множество объектов, связанных с бизнес-процессом. Ну а если необходимо автоматизировать бизнес-процесс в BPMS системе, то тут уже не обойтись без нотации BPMN.

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