Арис описание бизнес процессов

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

Общие сведения о моделировании бизнес-процессов

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

Китайский с нуля для начинающих
Увлекаем Китаем, китайским языком и культурой

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

Моделирование бизнес-процессов в ПО ARIS

К основным целям бизнес-моделирования можно отнести следующие моменты:

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

«Моделирование бизнес-процессов в ПО ARIS»
Готовые курсовые работы и рефераты
Решение учебных вопросов в 2 клика
Помощь в написании учебной работы

ARIS, то есть, Architecture of Integrated Information Systems является методологией и тиражируемым программным продуктом, предназначенным для моделирования бизнес-процессов организаций. Продукт и методология стали собственностью немецкой фирмы Software AG в результате поглощения компании IDS Scheer, которую создал автор методологии Август-Вильгельм Шеер.

Реализовать методологию можно путем задействования специализированного программного продукта, который способен обеспечить совместную работу над описаниями и диаграммами. Первая вариант этого программного продукта вышел в свет в 1994-ом году. В 2000-ом году данный продукт уже был поставлен примерно двадцати четырем тысячам организаций. Начиная с 2009-го года стала поставляться бесплатная версия инструмента, именуемая ARIS Express.

Программный продукт ARIS может использоваться в разных проектах по реинжинирингу и оптимизации бизнес-процессов, ИТ-проектах типа внедрения и эксплуатации ERP-систем, в том числе, имеется отработанное интеграционное решение для SAP R/3.

Программное обеспечение ARIS является основой пакета Business Process Analysis Suite компании Oracle. Технически инструментальный набор ARIS считается довольно простым для освоения и обладает интуитивно понятным интерфейсом. Сформированные модели можно копировать и вставлять в файлы документов (к примеру, формата Microsoft Word) в форме рисунков.

В программных продуктах ARIS предусматривается возможность формирования сценариев автоматизации создания разных аналитических отчетов, нормативной документации, новых моделей. Все сценарии являются подпрограммами, которые можно запустить в ARIS Business Architect (либо Toolset для более ранних версий) или прямо на сервере ARIS. Сценарии следует писать на специализированном языке программирования, который называется SAX Basic. Для того чтобы в автоматизированном режиме сформировать какой-либо отчет в ARIS, сценарии могут оперировать данными из базы моделей, выбирая из нее требуемые объекты и модели.

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

1. Создание нормативной документации на базе моделей ARIS, таких, как паспорт процесса, регламент процесса.
2. Создание аналитических отчетов на базе моделей ARIS.
3. Объединение ARIS Toolset с иными приложениями и базами данных.
4. Создание базы моделей ARIS на базе готовых спецификаций.

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

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

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

1. Подуровень описания требований.
2. Подуровень описания спецификации.
3. Подуровень описания внедрения.

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

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

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

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

1. eEPC (extended event-driven process chain), которая является событийной цепочкой процессов.
2. ERM (entity-relationship model), которая является моделью типа «сущность-связь» для описания структуры данных.
3. UML (unified modeling language), которая является унифицированным объектно-ориентированным языком моделирования.

Источник: spravochnick.ru

Глава 2. Основы моделирования бизнеса. ARIS

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

• Какие операции приносят потери, не добавляют ценности конечному продукту? Какова стоимость потерь?

• Где имеется избыток или недостаток ресурсов? Какие ресурсы необходимы?

• Какие процессы дублируются или размыты между подразделениями? Как построить или изменить бизнес-процесс?

• Как наиболее эффективно провести преобразования из одного состояния предприятия в другое? Как снизить риски?

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

• Как обеспечить выполнение регламентов и показателей качества? Какие регламенты, состав регламентов необходимы?

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

Типовые структуры организаций и модели

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

• организационная структура – иерархическая структура подразделений, должностей, полномочий, связей и отношений подчинения, территориальную привязку;

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

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

• структура входов и выходов организации – совокупность поступающих в организацию материальных и нематериальных ресурсов (входы) и совокупность материальных и нематериальных результатов деятельности (выходы) организации;

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

• финансово-экономическая структура – совокупность центров учета финансов, бюджетов и денежных потоков между ними;

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

• штатная структура – состав подразделений с перечнем должностей, окладов и пр.

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

Взаимосвязь и взаимосогласованность типов моделей в системе ARIS графически изображают в виде «домика» ARIS:

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

Этапы и средства создания моделей

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

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

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

• DFD (Data Flow Diagrams) – диаграммы потоков данных для анализа и функционального проектирования моделей систем. Описывают источники и адресаты данных, логические функции, потоки данных и хранилища данных к которым осуществляется доступ;

• STD (State Transition Diagrams) – диаграммы перехода состояний для проектирования систем реального времени;

• ERD (Entity-Relationship Diagrams) – диаграммы сущность-связь, описывающие объекты (сущности), свойства этих объектов (атрибуты) и их отношения объектов (связи);

• SADT (Structured Analysis and Design Technique) — технология структурного анализа, проектирования и моделирования иерархических многоуровневых модульных систем;

• IDEF0 – подмножество SADT – стандарт описания бизнес-процессов в виде иерархически взаимосвязанных функций;

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

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

• IDEF3 – стандарт описания процессов, основанная на сценариях. Сценарий есть описание последовательности изменения свойств объекта в рамках некоторого процесса. Стандарт позволяет описать последовательность этапов изменения свойств объекта (Process Flow Description Diagrams — PFDD) и состояния объекта на этапах (Object State Transition Network — OSTN). Стандарт позволяет решать задачи документирования и оптимизации процессов;

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

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

• UML – Unified Modeling Language — объектно-ориентированный унифицированный язык визуального моделирования. Позволяет описывать диаграммы действий, диаграммы взаимодействия, диаграммы состояний, диаграммы классов и компонент. Используется как для анализа, так и для проектирования моделей информационных систем.

Фрагменты моделей

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

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

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

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

Модель данных «сущность-связь» (Entity Relationship Model — ERM) используется для отражения структуры информации об объектах и их связях, которая обрабатывается в процессах предприятия. Фрагмент модели «сущность-связь» показан на рис.:

Модель процессов/управления (Event-driven Process Chain — EPC) описывает события и действия (функциональные шаги), выполняемые организационными подразделениями и исполнителями, в рамках одного бизнес-процесса ограниченного во времени. Она позволяет выявить взаимосвязи между организационной и функциональной моделями. Фрагмент событийной цепочки процессов EPC показан на рис.:

Источник: znanio.ru

ARIS eEPC или «Процедура» Business Studio?

Во многих современных системах класса Business Process Management (BPMS) для описания «исполняемых» процессов применяется спецификация BPMN (версия 1, 2). Эта спецификация является, вероятно, лучшей для целей формализации автоматизируемых процессов. Однако для описания и регламентации процессов, исполняемых людьми, она является слишком сложной так же, как и некоторые другие нотации, появившиеся ранее.

В статье рассмотрены проблемы выбора нотаций, адекватных задаче описания и регламентации процессов, исполняемых людьми. Выполнено сравнение нотации ARIS eEPC, «простой » в MS Visio и «Процедуры» Business Studio.

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

Введение

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

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

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

1. Описание исполняемых процессов в рамках системы BPM;
2. Регламентация деятельности сотрудников при помощи внутренних документов ( создание регламентной базы);
3. Описание требования к программному обеспечению.

При такой постановке задачи придется, скорее всего, использовать несколько нотаций: BPMN, некоторую нотацию типа Work Flow и, возможно, UML. Использовать одну нотацию и один инструмент моделирования для эффективного решения этих разнородных задач на практике вряд ли получится.

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

1. Наличие слишком сложной и избыточной для описания простых процессов семантики;
2. Неудобство при создании сложной, многоуровневой процессной модели организации в целом;
3. Значительные сложности по обучению сотрудников компании (в силу сложности спецификации и дефицита специалистов, способных проводить такое обучение).

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

1. Простота в освоении, интуитивная понятность для сотрудников компании;
2. Приемлемая информативность схем процессов при минимальном наборе используемых графических символов;
3. Поддержка нотации современными средствами моделирования;
4. Затраты на внедрение методики описания и регламентации процессов с использованием соответствующего инструмента;

Нотация ARIS eEPC

Нотация ARIS eEPC была одной из первых нотаций, получившей широкую известность на российском рынке. Она относится к нотации типа Work Flow (поток работ). Особенностями нотации является наличие элементов типа «событие» и наличие операторов логики: «и», «неисключающее или», «исключающее или» (см. Рис. 1).

Рис. 1. Схема процесса в нотации ARIS eEPC

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

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

Возникает вопрос: а за что, собственно, боролись? Типичная схема в ARIS eEPC:

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

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

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

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

«Простая »

Нотация «простая » реализована в популярном офисном продукте MS Visio. На Рис. 2. показаны элементы этой нотации и фрагмент соответствующей схемы. В полном объеме рассматриваемая нотация применяется редко.

Вообще, в MS Visio представлено несколько нотаций типа , которые являются достаточно сложными. Очевидно, по этой причине они не нашли широкого применения, хотя и были включены в набор нотаций, поставляемых с системой.

Нотация «простая » в своем самом простом и часто используемом на практике варианте, содержит всего несколько элементов:

1. Процесс;
2. Решение;
3. Ручная операции (реже);
4. Документ;
5. Данные;
6. Стрелка (для отображения связей между объектами схемы).

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

Рис. 2. Нотация «Простая » в MS Visio

Рассмотрим некоторые особенности применения «Простой », в частности применение стрелок. На практике, сотрудники компании, формирующие схемы при помощи «Простой » придерживаются двух подходов:

1. Не именуют стрелки вообще;
2. Стараются присваивать стрелкам, связывающие элементы схемы, простые и понятные названия;

На Рис. 3 показан пример применения нотации «Простая » в одной из компаний. Использованы все пять типов элементов. Тем не менее, схема выглядит вполне читаемой и понятной пользователю — сотруднику компании.

Нотация «Простая » при использовании в компаниях часто подвергается различным вариациям:

1. Изменяется смысл элемента «решение»;
2. используют стрелки связей (именуют или не именуют );
3. используют стрелки связей в сочетании с объектом «документ»;
4. Прочее.

Интересно, что нотация «простая » в том или ином виде часто используется специалистами по менеджменту качества при описании процессов СМК.

Рис. 3. Пример схемы в нотации «Простая »

Преимуществами нотации «Простая » (с сокращенным до минимума количество элементов) являются:

1. Простота формирования графических схем процессов;
2. Интуитивная понятность схем сотрудникам (даже без специального обучения);
3. Минимальная потребность в обучении сотрудников;
4. Наличие доступных инструментов для описания процессов (MS Visio, MS Word).

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

1. Внутренний стандарт использования этой нотации;
2. Внутренний стандарт формирования, хранения и актуализации файлов со схемами процессов.

В целом, масштабное использование в компании нотации «Простая » без современного средства моделирования представляется весьма неэффективным.

«Процедура» Business Studio

На Рис. 4 представлена схема, сформированная в нотации «Процедура» среды моделирования процессов Business Studio (Россия). В рассматриваемой нотации используются следующие условные обозначения:

1. Процесс;
2. Решение;
3. Событие;
4. Стрелка предшествования (как в классических нотациях класса Work Flow);
5. Стрелка потока объектов;
6. Сноска;
7. Внешняя ссылка.

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

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

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

Рис. 4. Схема процесса в нотации «Процедура» Business Studio

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

На Рис. 4. видно, что по ходу процесса для повышения информативности схемы используются («Ежедневно, в 9–00», «В течение дня», «12–00»). Таким образом, информацию о событиях можно показывать как виде специальных элементов, так и путем соответствующего именования стрелок.

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

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

• Представлен минимально необходимый набор графических элементов для описания процессов типа Work Flow (поток работ);
• Быстрота создания графических схем для целей регламентации;
• Возможность повышения информативности схем процессов за счет гибкого использования событий и именованных стрелок (одновременно с возможностью привязки документов к стрелкам и последующей выгрузки информации в регламентирующих документах);
• Схемы процессов просты и понятны всем сотрудникам даже без специального обучения;
• Простота в обучении (нет необходимости привлекать дорогостоящих специалистов со стороны — обучение можно проводить силами сотрудников отдела орг. развития);
• Схемы процессов являются , что удобно для описания «сквозных» процессов компании;
• Можно выгружать и редактировать схемы в MS Visio (при необходимости).

Среда моделирования Business Studio позволяет достаточно быстро создавать процессную модель компании. Информация о процессах может быть выгружена из системы в виде регламентирующих документов в требуемом формате. Заметим, что в Business Studio есть возможность описывать процессы в нотации ARIS eEPC, нотации IDEF0 и нотации «Процесс» (см. руководство по системе).

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

Таблица 1. Информация о процессе, представленном на Рис. 4

Рис. 5. Пример схемы в нотации «Процедура» в Business Studio

Выводы

В целом, нотация «Процедура» в версии, реализованной в среде моделирования Business Studio, является более удобной и понятной сотрудникам, чем нотация ARIS eEPC. Она позволяет быстро описывать и регламентировать процессы компании.

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

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

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

Источник: www.businessstudio.ru