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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

Жизнь по плану

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

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

Для чего все это нужно

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

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

Это сделано в нужный момент;

Форма, в которой информация представлена, достаточно проста и понятна.

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

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

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

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

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

Простая классификация

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

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

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

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

Свойства

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

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

Граница - это начало и конец выполнения простой операции.

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

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

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

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

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

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

Обязательное выделение элементарных процессов

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

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

Как представить описание заказчику

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

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

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

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

Как правильно описывать бизнес-процесс

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

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

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

Упрощенная схема описания производственных процессов

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

• Что? Описывает, что конкретно делается в данной операции.
• Зачем? Передает цель выполнения операции.
• Когда? Определяет, кто инициирует выполнение.
• Кто? Называет конкретных исполнителей.
• Как? Перечисляет необходимые ресурсы.

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

Как собрать информацию

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

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

Рабочая группа

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

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

Из чего состоит описание

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

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

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

Показатели

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

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

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

В основе большинства методологий моделирования сейчас положены принципы структурного анализа и проектирования (SADT - Structured Analysis and Design Technique), а также некоторые Можно говорить о существовании нескольких основных моделей анализа бизнес-процессов:

Business Process Modeling - собственно, моделирование - раскрывает функциональную сторону существования фирмы.

Work Flow Modeling - описывает потоки работ и похож на составление блок-схем.

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

Цикл Шухарт-Деминга

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

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

При составлении регламента следует учесть принципы, которые обеспечивают соответствие модели Шухарта-Деминга:

1. Расчет плановых показателей на будущий период.
2. Анализ динамики отклонений и документирование предположительных причин.
3. Определение корректирующих операций и анализ их эффективности.

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

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

Ведь именно налаженная и тщательно проработанная система позволит не только упростить получение предприятием сертификатов соответствия международным стандартам качества ISO 9001:2008, но и значительно повысить эффективность работы каждого сотрудника.

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

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

Я уже писал о моделировании при помощи IDEF0 (Знакомство с нотацией IDEF0 и пример использования), об организации работы склада и работе с клиентами от лида до сделки (Внедрение CRM. От регистрации лида до закрытия сделки. Кейс и пояснения), о системе Bizagi (Bizagi. Описание. Пример). И везде я использовал при пояснении примеров и практических решений нотации бизнес-процессов.

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

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

Основные подходы

• Функциональный;
• Процессный;
• Ментальный (с применением ментальных карт).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Плюсы применения таких ментальных карт очевидны:

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

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

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

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

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

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

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

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

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

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

Преимущества разработки моделей бизнеса

На самом деле, стандарты и правила – это огромный плюс:

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

Применение моделей бизнеса на практике

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

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

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

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

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

В России для моделирования и анализа бизнес-процессов достаточно широко используются следующие средства моделирования: Rational Rose , Oracle Designer , AllFusion Process Modeler (BPWin ) и AllFusion ERwin Data Modeler (ERWin ), ARIS , Power Designer . За рубежом, помимо упомянутых, активно используются такие средства как System Architect, Ithink Analyst, ReThink и др. В Таблице 1 представлен перечень инструментальных средств, участвующих в рассмотрении. Представленная информация включает:

• наименование инструментального средства;
• данные о поставщике и представителе в России;
• краткая характеристика инструментального средства.

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

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

Из приведенного в таблице списка инструментальных средств для более подробного анализа выделим те программные продукты, которые удовлетворяют указанным критериям. В этом случае в рамки нашего дальнейшего рассмотрения попадают BPWIn/ERWin, Oracle Designer, Rational Rose, Power Designer, ARIS, по которым ниже представлено более подробное описание.

BPWin и ERWin компании Соmputer Associates . Computer Associates International, Inc. (CA) входит в пятерку ведущих производителей программного обеспечения, предлагая средства моделирования, резервного копирования, управления инфраструктурой предприятия (сетями, серверами и т.д.), информационной безопасности, business intelligence и т.д. Пакет BPWin основан на методологии IDEF и предназначен для функционального моделирования и анализа деятельности предприятия. Методология IDEF, являющаяся официальным федеральным стандартом США, представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области. Функциональная модель IDEF отображает функциональную структуру объекта, т.е. производимые им действия и связи между этими действиями.

Возможности BPwin:

• поддерживает сразу три стандартные нотации - IDEF0 (функциональное моделирование), DFD (моделирование потоков данных) и IDEF3 (моделирование потоков работ). Эти три основных ракурса позволяют описывать предметную область наиболее комплексно;
• позволяет оптимизировать процедуры в компании;
• полностью поддерживает методы расчета себестоимости по объему хозяйственной деятельности (функционально-стоимостной анализ, ABC);
• позволяет облегчить сертификацию на соответствие стандартам качества ISO9000;
• интегрирован с ERwin (для моделирования БД), Paradigm Plus (для моделирования компонентов ПО) и др.;
• интегрирован со средством имитационного моделирования Arena;
• содержит собственный генератор отчетов;
• позволяет эффективно манипулировать моделями - сливать и расщеплять их;
• имеет широкий набор средств документирования моделей, проектов.

Пакет ERWin это средство концептуального моделирования БД. Используется при моделировании и создании баз данных произвольной сложности на основе диаграмм "сущность - связь". В настоящее время ERWin является наиболее популярным пакетом моделирования данных благодаря поддержке широкого спектра СУБД самых различных классов. Возможности ERWin:

• поддерживает методологию структурного моделирования SADT и следующие нотации: стандартную нотацию IDEF1x для ER-диаграмм моделей данных, нотацию IE и специальную нотацию, предназначенную для проектирования хранилищ данных - Dimensional;
• поддерживается прямое (создание БД на основе модели) и обратное (генерация модели по имеющейся базе данных) проектирование для 20 типов СУБД: настольные, реляционные и специализированные СУБД, предназначенные для создания хранилищ данных;
• интегрирован линейкой продуктов Computer Associates для поддержки всех стадий разработки ИС, CASE-средствами Oracle Designer, Rational Rose, средствами разработки и др.;
• позволяет повторно использовать компоненты созданных ранее моделей, а также использовать наработки других разработчиков;
• возможна совместная работа группы проектировщиков с одними и теми же моделями (с помощью AllFusion Model Manager);
• позволяет переносить структуру БД (не сами данные!) из СУБД одного типа СУБД в другой;
• позволяет документировать структуру БД.

Oracle Designer компании Oracle . Набор инструментальных средств Oracle Designer предлагает интегрированное решение для разработки прикладных систем корпоративного уровня для Web и клиент/серверных приложений. Oracle Designer участвует в каждой фазе жизненного цикла разработки программного обеспечения - от моделирования бизнес-процессов до внедрения. Применение единого репозитория, делает возможным использование любых его компонент для быстрой разработки масштабируемых, кросс-платформных распределенных приложений. Задачей Oracle Designer является сбор данных о потребностях пользователей и автоматизация построения гибких графических приложений. Oracle Designer используется не только для создания приложений, но и для ведения учета изменений, которые неизбежно происходят при эксплуатации системы. Графические модели определений проекта, интегрированные с многопользовательским репозиторием существенно облегчают работу с Oracle Designer. Инструментальные средства построены на базе общепринятых методик, охватывающих весь жизненный цикл разработки и позволяющих пользователям привычным для их организации способом. Это обеспечивает гибкость и открытость подхода к разработке программного обеспечения за счет использования только тех частей продукта, которые требуются в данной задаче. В рамках процесса разработки обеспечивается поддержка методов RAD, JAD, информационного проектирования, водопадного метода (waterfall), итеративного метода и др. Пользуясь этими принципами, можно добиться успешного баланса организационных потребностей и технологических возможностей, и даже эффективно управлять риском, связанным с частыми неизбежными и важными изменениями как в одной, так и в другой области. Средства концептуального моделирования Oracle Designer включают в себя:

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

Такие модели представляют информационные потребности в удобном и наглядном для восприятия виде, что делает их хорошим средством коммуникации между проектировщиками и пользователями в процессе уточнения постановки задач. Любой разработчик заинтересован, чтобы описание концептуальной модели было использовано для создания спецификаций,описывающих структуру и основные компоненты будущей системы. В Oracle Designer все спецификации проекта системы разрабатываются на основе моделей концептуального уровня и обеспечивают выполнение всех содержащихся в них требований и ограничений. Полученные компоненты системы могут быть преобразованы в реальные объекты базы данных, экранные формы и отчеты. Финальная часть разработки проекта - автоматическая генерация серверных компонентов - возможна не только для сервера БД Oracle, но и для СУБД Microsoft SQL Server, DB/2, Sybase и ряда других. Любые изменения бизнес-процессов могут быть внесены в модели и тут же сгенерировано модифицированное приложение, основывающееся уже на новых схемах ведения бизнеса. При этом все разработанное ранее будет сохранено и войдет в новый проект. Oгасlе Designer автоматически создает отчеты, которые содержат всю информацию о проекте и могут быть использованы как набор документов, отражающих текущее состояние проекта.

Rational Rose компании IBM . IBM Rational Rose - входит в состав пакета IBM Rational Suite и предназначен для моделирования программных систем с использованием широкого круга инструментальных средств и платформ. Rational Rose является одним из ведущих инструментов визуального моделирования в программной индустрии, благодаря полноценной поддержке языка UML и многоязыковой поддержке командной разработки. Инструмент полностью поддерживает компонентно-ориентированный процесс создания ИС. Любые участники проекта - аналитики, специалисты по моделированию, разработчики и другие - могут использовать модели, построенные в Rational Rose, для большей эффективности создания конечного продукта. Для бизнес-аналитиков средство Rational Rose дает возможность детально описать и проанализировать бизнес-процессы данной предметной области. Системные аналитики, используя указанные описания, смогут разработать необходимый функционал ИС, который максимально удовлетворит запросы заказчика. Для архитекторов средство Rational Rose будет полезно при создании мощной и гибкой архитектуры системы. Для аналитиков, специализирующихся в области разработки баз данных, Rational Rose даст возможность визуально проектировать и генерировать базы данных любого размера. Таким образом, можно создавать базы данных Microsoft SQL Server, Oracle, Sybase, SQL Anywhere, IBM DB2 и любые другие, которые поддерживают возможность запуска скриптов стандарта ANSI SQL. Любые модели, создаваемые с помощью данного средства, являются взаимосвязанными: бизнес-модель, функциональная модель, модель анализа, модель проектирования, модель базы данных, модель компонентов и модель физического развертывания системы. Есть возможность по созданию шаблонов архитектурных решений, позволяющих использовать опыт, накопленный в предыдущих проектах. Существуют расширения Rational Rose, которые позволяют выполнять скелетную (round-trip) разработку ИС, создаваемых на базе языков C/C++, Java, Smalltalk, Ada, Object Pascal (Borland Delphi) и др. Таким образом, можно сгенерировать каркас программного кода на любом из указанных языков или выполнить процедуру обратного проектирования, что позволяет сформировать модель на базе существующего кода. Есть возможность публикации модели в Интернете, которая служит основой для объединения работы удаленных команд разработчиков. Интеграция Rational Rose с Rational RequisitePro позволяет на базе визуальной модели разработать полный набор требований, которые необходимо реализовать при создании конечного продукта. Интеграция Rational Rose с Rational TestManager позволяет создавать сценарии тестирования на базе визуальной модели. Интеграция Rational Rose с Rational ClearCase позволяет поставить на версионный контроль модель целиком или по частям. Интеграция Rational Rose с Rational SoDA позволяет автоматизировать процесс создания документов и отчетов по визуальной модели.

PowerDesigner компании Sybase . Компания Sybase со дня своего основания традиционно является ведущим поставщиком информационных технологий на мировой рынок финансовых институтов: технологии Sybase используют 90% компаний мирового рынка ценных бумаг, 60% мировых банков и 68% компаний Wall Street. С 1996 года, когда открылся офис в Москве, Sybase активно работает в России и других странах СНГ. В апреле 2002 года открылись офисы компании в Санкт-Петербурге и Киеве. Офисы Sybase в Москве, Санкт-Петербурге и Киеве обеспечивают всестороннюю работу с клиентами, включая поставки технологий, оборудования, разработку законченных решений, обучение пользователей, полнофункциональную техническую поддержку и услуги консалтинга. PowerDesigner является комплексным решением для моделирования и разработки приложений и бизнес-процессов для организаций, которые нуждаются в быстром, последовательном и эффективном с точки зрения затрат создании или реинжиниринге бизнес-приложений. PowerDesigner позволяет устранить следующие препятствия, мешающие эффективной разработке проектов: различия в профессиональной подготовке участников проекта, разнородные платформы и изобилие языков разработки, - то, что характерно для большинства современных компаний. Это позволяет фокусироваться на бизнес-потребностях создания приложений на протяжении всего процесса разработки - от системного анализа и дизайна и вплоть до непосредственной генерации кода для приложения. Последняя версия продукта, PowerDesigner, обладает новыми возможностями по моделированию бизнес-процессов, объектному моделированию, базирующемуся на UML, и поддерживает как традиционные, так и вновь появляющиеся технологии моделирования в рамках одной развитой графической среды. Это позволяет значительно сократить затраты и время реализации проекта, который должен функционировать на различных платформах и инструментальных средах. Одним из основных преимуществ PowerDesigner является также использование репозитория масштаба предприятия для хранения и управления всей информацией, касающейся моделирования и дизайна приложений на всех уровнях ведения бизнеса в компании. Это позволяет правильно организовать рабочий процесс и кардинальным образом повысить эффективность работы разработчика. Ключевые характеристики PowerDesigner:

• Моделирование бизнес-процессов: PowerDesigner позволяет нетехническим специалистам компании разрабатывать и моделировать бизнес-процессы, ориентируясь на бизнес-задачи и опираясь на известные им термины, используя простую и интуитивно понятную графическую нетехническую модель.
• Моделирование данных: PowerDesigner позволяет разрабатывать и генерировать схему БД посредством двухуровневого (концептуального и физического) моделирования реляционной БД, поддерживающего классические методики проектирования баз данных. Имеет также встроенные средства моделирования хранилища данных.
• Объектное моделирование: PowerDesigner предлагает законченную технологию анализа и проектирования систем с использованием стандарта UML (диаграммы бизнес-процессов, последовательности выполнения, классов и компонентов). На основе диаграммы классов PowerDesigner автоматически осуществляет генерацию и реинжиниринг кода для популярных инструментальных сред, таких как JavaTM (включая EJB 2.0), XML, Web Servicies, C++, PowerBuilder, Visual Basic и других, посредством настраиваемого генератора.
• Репозиторий масштаба предприятия: Enterprise-версия PowerDesigner содержит функциональность репозитория класса предприятия. Репозиторий позволяет всем членам вашей команды легко просматривать модели и другую информацию, а также осуществлять обмен ими. Репозиторий обладает высокой масштабируемостью и поддерживает систему безопасности, основанную на роли пользователя, контроль версий, поиск и возможности составления отчетов.

ARIS компании IDS Scheer AG . В настоящее время наблюдается тенденция интеграции разнообразных методов моделирования и анализа систем, проявляющаяся в форме создания интегрированных средств моделирования. Одним из таких средств является продукт, носящий название ARIS, разработанный германской фирмой IDS Scheer. Компания IDS Sheer AG основана в 1984 г. Основное направление - программное обеспечение и консалтинг. В настоящее время компания обслуживает 4000 клиентов в 50 странах мира через сеть своих представительств и партнеров. Качество решений IDS Scheer было подтверждено в июне 2005 г. золотой медалью Международной познаньской ярмарки, на которой награждаются только лучшие продукты. А также в июле 2005 г., когда на мировом рынке была представлены программные продукты ARIS 7 с абсолютно новыми web-продуктами - все они имеют общую черту - интуитивно-понятный и выразительный интерфейс. Система ARIS представляет собой комплекс средств анализа и моделирования деятельности предприятия. Ее методическую основу составляет совокупность различных методов моделирования, отражающих разные взгляды на исследуемую систему. Одна и та же модель может разрабатываться с использованием нескольких методов, что позволяет использовать ARIS специалистам с различными теоретическими знаниями и настраивать его на работу с системами, имеющими свою специфику. Методика моделирования ARIS основывается на разработанной профессором Августом Шером теории построения интегрированных ИС, определяющей принципы визуального отображения всех аспектов функционирования анализируемых компаний. ARIS поддерживает четыре типа моделей, отражающих различные аспекты исследуемой системы:

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

Для построения перечисленных типов моделей используются как собственные методы моделирования ARIS, так и различные известные методы и языки моделирования, в частности, ER и UML. В процессе моделирования каждый аспект деятельности предприятия сначала рассматривается отдельно, а после детальной проработки всех аспектов строится интегрированная модель, отражающая все связи между различными аспектами. ARIS не накладывает ограничений на последовательность построения указанных выше типов моделей. Процесс моделирования можно начинать с любого из них, в зависимости от конкретных условий и целей, преследуемых разработчиками. Модели в ARIS представляют собой диаграммы, элементами которых являются разнообразные объекты - "функция", "событие", "структурное подразделение", "документ" и т.п. Между объектами устанавливаются разнообразные связи. Каждому объекту соответствует определенный набор атрибутов, которые позволяют ввести дополнительную информацию о конкретном объекте. Значения атрибутов могут использоваться при имитационном моделировании или для проведения стоимостного анализа. Таким образом, по результатам выполнения этого этапа возникает набор взаимосвязанных моделей, представляющих собой исходный материал для дальнейшего анализа. Стоит отметить несколько особенностей системы ARIS. Первая - семейство программных продуктов ARIS ориентированно на процессное описание. Основная бизнес-модель ARIS - eEPC (extended Event-driven Process Chain - расширенная модель цепочки процессов, управляемых событиями). По существу, модель eEPC расширяет возможности IDEF0, IDEF3 и DFD, обладая всеми их достоинствами и недостатками. Вторая особенность - в системе ARIS есть внутренняя база данных, которая позволяет проверять модель на непротиворечивость, целостность, проводить верификацию модели. В других продуктах это отсутствует. Третья особенность: ARIS - единственная система, ориентированная на описание бизнеса, где присутствуют различные взгляды на бизнес-систему, которую мы можем оценить и рассмотреть с разных сторон, чего нет в других программных продуктах. В течение последних пяти лет ARIS уверенно лидирует среди средств моделирования.

Укажем основное предназначение каждого рассматриваемого продукта из множества его применений:

• для моделирования баз данных больше подходят инструменты Erwin, Power Designer и Rational Rose;
• для моделирования компонентов разрабатываемых приложений больше подходят Oracle Designer, Power Designer и Rational Rose;
• для моделирования бизнес-процессов больше подходят BPwin, ARIS и Rational Rose.

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

Таблица 2. Сравнительный анализ по базовым функциям