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

О критериях успеха средств моделирования на мировом и российском рынках

В общемировом масштабе (в первую очередь для многонациональных компаний и в некоторых случаях - для компаний американских) одним из самых серьезных критериев выбора программного обеспечения для осуществления того или иного вида деятельности является высокая оценка продукта аналитическими компаниями, такими как Gartner Group, Forrester Research, IDC и Meta Group.

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

О компании QPR

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

Несколько лет назад QPR была названа аналитической компанией Gartner Group одним из ведущих производителей средств моделирования, обладающих видением рынка и перспектив его развития, во многом благодаря поддержке концепции BSC (Balanced Scorecard), очень популярной в области стратегического планирования. Впрочем, о поддержке BSC в продуктах QPR мы расскажем чуть позже.

QPR ProcessGuide - моделирование и документирование бизнес-процессов

Поддерживаемые нотации

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

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

Модель процесса в QPR ProcessGuide

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

Документирование процессов

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

Возможности документирования процессов в QPR ProcessGuide весьма широки - данный продукт обладает программным интерфейсом на основе технологии COM, позволяющим обратиться к абсолютно любым данным, содержащимся в моделях, а встроенный язык программирования представляет собой Visual Basic for Applications. Последний факт значительно упрощает генерацию отчетов в форматах приложений Microsoft Office - при наличии установленных офисных приложений можно обращаться из скрипта отчетности, созданного для QPR ProcessGuide, непосредственно к COM-интерфейсам Word, Excel, PowerPoint. Кроме того, наличие программного интерфейса подобного класса позволяет создавать на основе QPR ProcessGuide различные прикладные решения, такие как средства обмена моделями с другими инструментами моделирования, средства интеграции с различными информационными системами и т.д.

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

Имитационное моделирование и совершенствование процессов

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

Результаты имитационного моделирования в QPR ProcessGuide

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

Публикация моделей на корпоративном интранет-портале

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

Публикация моделей на корпоративном интранет-портале

QPR ScoreCard - поддержка технологии BSC

Balanced Scorecard (BSC), или система сбалансированных показателей (ССП), - это разработанный в 1992 году профессорами Гарвардского университета Робертом Капланом и Дэвидом Нортоном инструмент управления, позволяющий преобразовывать стратегические цели компании в четкий план оперативной деятельности подразделений и ключевых сотрудников и оценивать результаты их деятельности с точки зрения реализации стратегии компании с помощью ключевых показателей результативности. Применение сбалансированной системы показателей позволяет осуществить целенаправленный мониторинг деятельности предприятия, прогнозировать и упреждать появление проблем, контролировать наиболее существенные финансовые и нефинансовые показатели деятельности предприятия.

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

Указанный инструмент управления активно используется лидирующими западными компаниями (а именно - 402 организациями из 500 крупнейших в рейтинге газеты Financial Times), а в последнее время привлекает пристальное внимание топ-менеджеров в России. Подробнее о технологии BSC можно прочесть в отдельной статье, посвященной данному вопросу, которая будет опубликована в одном из ближайших номеров нашего журнала.

Дерево целей компании в QPR ScoreCard

Стратегическая карта компании в QPR ScoreCard

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

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

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

Продукты QPR в России

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

На российском рынке доступны русскоязычные версии продуктов компании QPR. Их поставку, внедрение и поддержку осуществляет компания «Тродос Консалтинг» - эксклюзивный дистрибьютор QPR Software plc в России и СНГ. Кроме того, указанная компания поставляет на российский рынок ряд созданных на основе указанных продуктов прикладных решений с использованием данных, полученных из учетных систем, например решения для автоматизации управления штатным расписанием, формирования системы мотивации персонала, бюджетирования, планирования. На данный момент этой компанией осуществлено несколько десятков успешных внедрений - как продуктов QPR, так и собственных решений на их основе. Это означает, что компании, решившиеся не просто внедрить продукты QPR, но и интегрировать их с имеющимися у них информационными системами (а современные бизнес-пользователи, как правило, категорически настаивают на подобной интеграции), не останутся с этими задачами один на один.

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

Продукты QPR выгодно приобретать при большом количестве лицензий. Так, пакет лицензий QPR Process Guide для небольшого числа разработчиков (2-5) и нескольких десятков пользователей (20-100) с годовой техподдержкой стоит от 12 до 30 тыс. евро, тогда как в случае нескольких десятков разработчиков (20-40) и нескольких сотен пользователей (200-400) стоимость лицензий и годовой технической поддержки соствляет от 60 до 115 тыс. евро. Впрочем, основными потребителями продуктов подобного класса как раз и являются довольно крупные компании - ведь именно им в первую очередь требуются специализированные инструменты, помогающие совершенствовать бизнес-процессы.

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

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

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

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

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

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

Моделирование бизнес процессов преследует несколько целей:

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

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

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

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

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

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

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

Для целей совершенствования процесса применяют следующие виды моделирования:

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

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

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

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

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

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

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

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

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

• Flow Chart Diagram (диаграмма потока работ) – это графический метод представления процесса в котором операции, данные, оборудование процесса и пр. изображаются специальными символами. Метод применяется для отображения логической последовательности действий процесса. Главным достоинством метода является его гибкость. Процесс может быть представлен множеством способов.
• Data Flow Diagram (диаграмма потока данных). Диаграмма потока данных или DFD применяется для отображения передачи информации (данных) от одной операции процесса к другой. DFD описывает взаимосвязь операций за счет информации и данных. Этот метод является основой структурного анализа процессов, т.к. позволяет разложить процесс на логические уровни. Каждый процесс может быть разбит на подпроцессы с более высоким уровнем детализации. Применение DFD позволяет отразить только поток информации, но не поток материалов. Диаграмма потока данных показывает, как информация входит и выходит из процесса, какие действия изменяют информацию, где информация хранится в процессе и пр.
• Role Activity Diagram (диаграмма ролей). Она применяется для моделирования процесса с точки зрения отдельных ролей, групп ролей и взаимодействия ролей в процессе. Роль представляет собой абстрактный элемент процесса, выполняющий какую-либо организационную функцию. Диаграмма ролей показывает степень «ответственности» за процесс и его операции, а также взаимодействие ролей.
• IDEF (Integrated Definition for Function Modeling) – представляет собой целый набор методов для описания различных аспектов бизнес- процессов (IDEF0, IDEF1, IDEF1X, IDEF2, IDEF3, IDEF4, IDEF5). Эти методы строятся на базе методологии SADT (Structured Analysis and Design Technique). Для моделирования бизнес процессов наиболее часто применяют методы IDEF0 и IDEF3.
• IDEF0 – позволяет создать модель функций процесса. На диаграмме IDEF0 отображаются основные функции процесса, входы, выходы, управляющие воздействия и устройства, взаимосвязанные с основными функциями. Процесс может быть декомпозирован на более низкий уровень.
• IDEF3 – этот метод позволяет создать «поведенческую» модель процесса. IDEF3 состоит из двух видов моделей. Первый вид представляет описание потока работ. Второй – описание состояний перехода объектов.
• Цветные сети Петри – этот метод представляет модель процесса в виде графа, где вершинами являются действия процесса, а дугами события, за счет которых осуществляется переход процесса из одного состояния в другое. Сети Петри применяют для динамического моделирования поведения процесса.
• Unified Modeling Language (UML) - представляет собой объектно-ориентированный метод моделирования процессов. Он состоит из 9-ти различных диаграмм, каждая из которых позволяет моделировать отдельные статические или динамические аспекты процесса.

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

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

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

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

Основу многих современных методологий моделирования бизнес-процессов составили методология SADT (Structured Analysis and Design Technique - метод структурного анализа и проектирования), семейство стандартов IDEF (Icam DEFinition, где Icam - это Integrated Computer-Aided Manufacturing) и алгоритмические языки.

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

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

Описание потоков работ (Work Flow Modeling ). Стандарт IDEF3 предназначен для описания рабочих процессов и близок к алгоритмическим методам построения блок-схем.

Описание потоков данных (Data Flow Modeling ). Нотация DFD (Data Flow Diagramming ), позволяет отразить последовательность работ, выполняемых по ходу процесса, и потоки информации, циркулирующие между этими работами.

Прочие методологии.

По отношению к получению добавленной ценности продукта или услуги можно выделить следующие классы процессов:

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

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

Бизнес-процессы управления.

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

Цели моделирования бизнес-процессов обычно формулируются следующим образом:

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

Обеспечить понимание текущих проблем организации и возможностей их решения;

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

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

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

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

Этапы описания бизнес-процессов:

Определение целей описания.

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

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

Описание потоков (материальных, информационных, финансовых) процесса, построение DFD-диаграмм.

Построение организационной структуры процесса (отделы, участники, ответственные).

IDEF0

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

Место соединения дуги с блоком определяет тип интерфейса:

Управляющая информация входит в блок сверху.

Входная информация входит в блок слева.

Результаты выходят из блока справа.

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

Каждый компонент модели может быть декомпозирован (расшифрован более подробно) на другой диаграмме. Рекомендуется прекращать моделирование, когда уровень детализации модели удовлетворяет ее цель. Общее число уровней в модели не должно превышать 5-6.

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

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

IDEF3

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

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

Все связи в IDEF3 являются однонаправленными и организуются слева направо.

Типы связей IDEF3:

Временное предшествование (Temporal precedence), простая стрелка. Исходное действие должно завершиться, прежде чем конечное действие сможет начаться.

Объектный поток (Object flow), стрелка с двойным наконечником. Выход исходного действия является входом конечного действия. Исходное действие должно завершиться, прежде чем конечное действие сможет начаться. Наименования потоковых связей должны чётко идентифицировать объект, который передается с их помощью.

Нечеткое отношение (Relationship), пунктирная стрелка.

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

Ветвление процесса отражается с помощью специальных блоков:

- "И", блок со знаком &.

- "Исключающее ИЛИ" ("одно из"), блок со знаком Х.

- "ИЛИ", блок со знаком О.

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

DFD

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

Основными компонентами диаграмм потоков данных являются:

Внешние сущности (материальный объект или физическое лицо, являющиеся источником или приёмником информации, например, заказчики, персонал, поставщики, клиенты, склад);

Системы и подсистемы (например, подсистема по работе с физическими лицами);

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

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

Потоки данных (на диаграмме - стрелки).

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

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

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

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

ARIS

В настоящее время наблюдается тенденция интеграции разнообразных методов моделирования, проявляющаяся в форме создания интегрированных средств моделирования. Одним из таких средств является программный продукт, носящий название ARIS (Architecture of Integrated Information Systems), разработанный германской фирмой IDS Scheer.

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

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

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

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

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

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

Основная бизнес-модель ARIS - eEPC (extended Event-driven Process Chain, расширенная модель цепочки процессов, управляемых событиями). Нотация ARIS eEPC является расширением нотации IDEF3. Бизнес-процесс в нотации eEPC представляет собой поток последовательно выполняемых работ (процедур, функций), расположенных в порядке их выполнения. Реальная длительность выполнения процедур в eEPC визуально не отражается.

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

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

Основные объекты нотации eEPC:

Функция. Служит для описания функций (процедур, работ), выполняемых подразделениями/сотрудниками предприятия. Каждая функция должна быть инициирована событием и должна завершаться событием; в каждую функцию не может входить более одной стрелки, "запускающей" выполнение функции, и выходить более одной стрелки, описывающей завершение выполнения функции.

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

Организационная единица. Например, управление или отдел.

Документ. Отражает реальные носители информации, например, бумажные документы.

Прикладная система.

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

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

Логический оператор. Оператор "И", "ИЛИ" или исключающее "ИЛИ", позволяет описать ветвление процесса.

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

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

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

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

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

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

Кому это надо

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

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

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

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

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

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

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

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

Разумеется, возможны и другие причины – или комплекс причин, по которым проектирование системы управления становится необходимым. Главное, при принятии решения не следует забывать простую истину: «Если работает – не ремонтируй!». (В ходе написания статьи у авторов возникли некоторые разногласия в трактовке этой поговорки. Остановились на таком ее уточнении: то, что прекрасно работает сегодня – завтра может стать проблемой. И конечно, дальновидный руководитель просто обязан предусмотреть соответствующий «ремонт»).

Немного примеров из жизни

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

ИТ-компания – типичное предприятие среднего бизнеса. Основные направления деятельности:

● Продажа средств автоматизации бизнеса – от продажи бухгалтерских и офисных программ до полномасштабных АСУП

● Внедрение средств автоматизации бизнеса

● Системная интеграция

● Услуги по обучению и сертификации специалистов Заказчика

● Производство и реализация собственного программного обеспечения.

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

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

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

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

С чего начать?

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

Рисунок 1.

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

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

Какие элементы подвергаются анализу? В первую очередь, ассортимент предлагаемых компанией товаров и услуг. Составляется реестр – полный пакет этих предложений – и производится его анализ. Все ли из того, что мы производим, выгодно, полезно и способствует достижению основных целей? Стоит ли расширить наш ассортимент? Нужно ли сократить его в части невыгодных товаров или услуг? Можно ли невыгодные товары или услуги сделать выгодными (а выгодные – супер-прибыльными?). Составляется перспективный пакет продуктов и услуг, для которого и будет производиться моделирование бизнес-процессов. Для продуктового анализа можно, например, использовать матрицу Boston Consulting Group (рисунок 2).

Рисунок 2.

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

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

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

Команда участников

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

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

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

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

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

Пример – единственный менеджер по кадрам средней компании осуществляет свою функцию в рамках единственного бизнес-процесса, который называется просто «подбор персонала». Учитывая, что практически всю работу он выполняет самостоятельно, никакого регламента для этой работы писать не требуется. Другое дело – отдел кадров крупной компании, где существует разделение различных функций между сотрудниками. Процесс «подбор персонала» в таком случае складывается уже из десятков более простых действий, выполняемых различными людьми – и вот их взаимодействие и требуется описать бизнес-процессами нижнего уровня. Конечным уровнем для деления бизнес-процессов является бизнес-операция – процесс, полностью выполняемый и контролируемый одной кадровой единицей. И для очень крупных компаний вполне реальны тысячи бизнес-процессов. Теперь сделаем воображаемую проекцию картины бизнес-процессов на схему подразделений предприятия. Очевидно, что некоторые бизнес-процессы будут полностью укладываться в рамках одного подразделения. Будут также и процессы, за выполнение которых отвечает (в той или иной степени) два и более подразделения. И самые неприятные ситуации, это те, в которых ответственность за выполнение бизнес-процесса неоднократно переходит от одного подразделения к другому (забегая вперед, скажем, что таких бизнес-процессов рекомендуется, по возможности, избегать). На рисунке 4 схематично показаны бизнес-процессы условного предприятия по производству продукции. Часть бизнес-процессов, показанная черными стрелками – протекает внутри подразделений. Другая часть – синие стрелки – переходит из одного подразделения в другое. И, наконец, третья часть – процесс, в котором задействовано несколько подразделений. Красный пунктир.

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

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

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

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

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

Собственно проектирование…

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

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

Концентрация усилий на выполнение стратегических целей. Бизнес-процессы, не имеющие влияния на ключевые показатели, разрабатываются в последнюю очередь, либо не разрабатываются вообще. Проведем простейший расчет: для предприятия, имеющего три уровня бизнес-процессов (то есть не очень большое унитарное предприятие) мы имеем 7-8 процессов верхнего уровня, каждый из которых делится на 7-8 БП второго уровня, такой же принцип деления сохраняется и ниже. Как результат, уже на третьем уровне имеем более 350 бизнес-процессов. В среднем, каждый бизнес-процесс состоит из десятка операций, что дает четыре тысячи операций в целом для предприятия. И это только для небольшого! Геометрическую прогрессию до четвертого и пятого уровня предлагаю посчитать самостоятельно. Конечно, пятого уровня детализации требуют только такие монстры, как Газпром или РАО ЕЭС – но и для четвертого уровня число операций оказывается не маленьким. Каждый процесс, каждую операцию, в идеале, нужно оптимизировать, регламентировать и пересматривать хотя бы раз в год или по мере изменения внешних условий. Учитывая количество операций, понимаем, что идеал, как обычно, недостижим, а погоня за ним приведет лишь к неоправданному перерасходу ресурсов. Приходится принимать грустное, но верное решение – взяв стратегическую карту, проектировать лишь те бизнес-процессы, которые соответствую указанным в ней целям. И, если уборка внутренней территории не влияет ни на одну из целей или подцелей стратегической карты, не воздействует ни на один показатель из ССП – то пусть ее регламентируют сами уборщики. Хотя бы до тех пор, пока мы не разобрались окончательно с производством, сбытом и снабжением…

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

Не забывать при проектировании задавать основные параметры бизнес-процесса (рисунок 5).

Рисунок 5. Основные параметры бизнес-процесса

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

Оценка проблемности и важности процесса. Также позволяет понять, какие процессы следует проектировать сразу, а какие могут и подождать. Среди основных критериев здесь могут быть рассмотрены: 1) критичность для бизнеса. То есть насколько неправильное исполнение процесса может навредить компании – повысить затраты, привести к потере клиента, задержать принятие важного решения… 2) Частота повторения процесса (редко, часто, регулярно). 3) Количество передач ответственности в рамках одного процесса, например, от подразделения к подразделению. Такие процессы потенциально опасны и тянут за собой множество проблем.

Лидеры по всем трем номинациям – явные кандидаты к проектированию и оптимизации.

Рисунок 6. Иллюстрация процессного подхода

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

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

Что ожидаем в итоге

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

Регламенты бизнес-процессов (по крайней мере, ключевых), стандартные бланки документации, как наружной, так и внутренней, положения о подразделениях, должностные инструкции, штатное расписание предприятия – вот ее минимальный перечень. Не менее важно и внедрение системы, реализация регламентов на практике. Только после этого можно говорить о том, что силы и ресурсы на проектирование потрачены не напрасно. Хорошо, если удастся разделить внедрение на небольшие этапы и участки (например, сначала отдел закупок, потом складское хозяйство и т.п.) Помимо того, что это позволит сохранять уверенный контроль за процессом внедрения инноваций, каждый небольшой успех будет становиться хорошим стимулирующим фактором для продолжения дальнейшей работы. Правда, возможность разделить внедрение на отдельные независимые участки имеется далеко не всегда. Даже если новая система полностью позволяет избежать разделения ответственности между подразделениями, если структура новых бизнес-процессов строго линейна и проста – даже тогда необходимость внедрять измерения «на ходу» (кто же позволит остановить предприятие, приносящее прибыль?) приводит к тому, что внедрение одного нового процесса затрагивает десятки старых, которые, в свою очередь, заменены десятками «новых», каждый из которых… (и далее, по нарастающей). Поэтому в большинстве случаев по ходу внедрения коллектив вынужден какое-то время работать по старой системе, параллельно имитируя новую деятельность (большинство ваших сотрудников люди грамотные и прекрасно понимают, что долгое время придется делать двойную работу только ради того, чтобы итоговая нагрузка на них возросла бы по сравнению с изначальной – отсюда и сопротивление инновациям). В наиболее запущенных случаях для внедрения системы управления оказывается проще построить недалеко новый завод (именно так приходится поступать, например, на «АвтоВАЗе», где унаследованные из советских времен несуразности, помноженные на благоприобретенные в процессе перестройки создали среду, инновациям в которой сопротивляется практически каждый сотрудник). И, наконец, еще один закономерный результат проектирования – внедрение автоматизированной системы управления предприятием. Давно доказано, что автоматизация повышает эффективность работы. Особенно заметный эффект автоматизация дает на предприятиях, где имеется четкая и рациональная система управления, регламентированы все бизнес-процессы. И, напротив, автоматизировать управление без предварительного проектирования – значит обречь внедрение АСУ на провал (мы уже упоминали невозможность автоматизации неопределенным образом происходящих случайно возникающих взаимоотношений?). Наличие же строгой системы бизнес-процессов позволит подойти к внедрению АСУ с точки зрения максимальной эффективности. Теперь уже вполне реально автоматизировать сначала наиболее критичные участки работы, на вырученные или сэкономленные в результате деньги – следующие по важности… Можно делать это с той постепенностью, какую позволяют ресурсы или требует внешняя ситуация.

Оценка потребности в ресурсах

Если вам ранее доводилось заниматься подобной деятельностью – то вы уже представляете себе, насколько облегчит проектирование Ваш расчетный счет, скольких сотрудников вы временно потеряете, как полноценные боевые единицы (и скольких вообще потеряете). Рассуждения ниже скорее для тех, кто впервые планирует приступать к такой работе – ведь опасно как переоценить, так и недооценить масштабы грядущих потерь. Завышенная оценка сложности может привести к отказу от проекта вообще (вместе с надеждами стать лидером отрасли), либо к излишне высоким суммам по договору с исполнителем. Заниженная оценка приведет к тому, что в какой-то момент ресурсов не хватит и проект будет заброшен – что снова означает потерянные деньги. Временная оценка не менее важна – и по тем же соображениям. Практика показывает, что компании среднего размера – от 500 до 1000 человек – разрабатывают и внедряют новую систему управления целиком за один год. Компаниям с 10 тыс. сотрудников потребуется примерно 2-3 года. Впрочем, в зависимости от сложности ситуации, время внедрения может увеличиться и в два и в три раза.

Из потребности в людских ресурсах можно предположить на весь этот период постоянную команду из 3-4 человек (стратег, аналитики) и необходимость привлечения к работе сотрудников предприятия по мере необходимости – начальников подразделений и рядовых исполнителей. Начальники будут привлекаться, приблизительно на один-два месяца чистого времени на протяжении всего цикла проектирования и внедрения, рядовые исполнители – меньше, от 2 недель до месяца. Затраты на своих специалистов, учитывая это время, можно оценить. Внешние консультанты стоят недешево. Услуги специалиста могут обойтись от 1,5 до 25 тыс. рублей за час работы.

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

Вопрос: Можно ли снизить затраты на проектирование системы управления?

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

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

● Вторая причина берет исток в понимании основ эффективности. Часто повторяющиеся процессы являются критичными для общего хода дела – ведь, несмотря на простоту и шаблонность, их вклад в общие трудозатраты весьма значителен. В проектировании бизнес-процессов достаточно много шаблонных, повторяющихся действий, которые, при ручной работе, заберут львиную долю всего времени разработки. Конечно, применение методик CTRL-C – CTRL-V заметно облегчает работу в WORD или Excel при их вводе, однако специализированное ПО предоставляет еще более удобную среду для проектирования.

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

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

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

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

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

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

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

Инструмент для моделирования и управления бизнес-процессами — системы BPM, позволяющие быстро создавать, запускать, мониторить и изменять процессы благодаря тесной интеграции сред проектирования, разработки и выполнения. В основе ВРМ-систем, как правило, лежит один из наиболее прогрессивных мировых стандартов моделирования — нотация BPMN 2.0.

Что такое нотация BPMN

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

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

5 BPM-систем с нотацией BPMN в основе

bpm’online

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

Для моделирования бизнес-процессов в нотации BPMN в bpm’online доступны два инструмента:

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

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

Выбор инструмента для моделирования в bpm’online зависит от сложности, назначения и способа запуска процесса.

BizAgi Suite

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

Business Studio

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

ELMA BPM

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

Visual Paradigm

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

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