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

В.Н. Тупкало, доктор технических наук, профессор

Всеукраїнський науково-практичний журнал
«Світ якості України» № 6-7(10-11), 11/ 2005 (русскоязычный перевод с украиноязычного аналога)

... стандартов должно быть много, хороших и разных...

Зрим в корень...

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

Рис.1 Сеть бизнес-процессов как основа базы знаний бизнеса предприятия

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

Как много языков хороших...

Сегодня наиболее известными языками (нотациями) графического моделирования бизнес-процессов являются UML, ARIS, IDEF (IDEF0, IDEF3 в программной интерпретации BPwin). Сравнительному анализу этих нотаций в части недостатков посвящено много публикаций (в т.ч. в Internet [1-4]). Поэтому автор статьи не ставит перед собой задачу внести свою лепту в этот анализ, а из своего практического опыта моделирования с использованием упомянутых языков полностью присоединяется к мнению авторов [1-4] и, в частности: «... как показал наш опыт, модели процессов, построенные в BPwin, вызывают трудности при понимании их экспертами предметной области. Это приводит к тому, что эксперты становятся пассивными слушателями  при обсуждении описания бизнес-процессов и им по существу навязывается понимание бизнес-процессов аналитиками. Ошибки неправильного описания бизнес-процессов затем выявляются, к сожалению, на более поздних этапах разработки...» [2]. В равной мере это мнение относится к UML и ARIS. К этому следует добавить и тот факт, что разрабатывая эти языки много лет назад, их создатели не предполагали о необходимости такого важного этапа синтеза бизнес-процессной модели «КАК ДОЛЖНО БЫТЬ», как аудит модели бизнес-процессов «КАК ЕСТЬ». Здесь снова на первый план выходят требования к высокой информативности и визуальному восприятию графического представления бизнес-процессов, которые (бизнес-процессы) должны отвечать определенным правилам их композиции.

И опыт – сын ошибок трудных...

Многолетний опыт использования графического представления процессов функционирования различных объектов управления (автор занимается графическим описанием процессов с середины 70-х, участвовал в описании сценариев работы автоматизированной системы управления наземными пунктами слежения за полетами космических аппаратов бывшего СССР АСУ «Скат») и критический анализ практического использования языков UML, IDEF, ARIS лишний раз подтвердил актуальность народной мудрости  «Новое – хорошо забытое старое» и привел к формированию и использованию с 2000 года языка графического моделирования бизнес-процессов ЯМТ (язык моделирования Тупкало). Данный язык моделирования прошел успешную апробацию  в 10 проектах (Харьковский КМЗ, Чугуевский РЭС АК «Харьковоблэнерго», ОАО «Кировоградоблэнерго», ЮЖД, ООО «ЭнТехЭко», Харьковский институт управления, ОАО «Центрэнерго», Киевский КБК, ООО «Астра», ЧП с ИИ «Унитех БАУ», ЗАО «РАКС»).  С 2000 г. методика моделирования бизнес-процессов на основе ЯМТ стала предметом изучения на открытых и корпоративных семинарах-тренингах автора по внедрению процессного менеджмента (в частности, в 2004 -2005гг. проведены семинары:  ООО «Ди Стар» (г. Полтава), Павлоградский химический завод, ООО «Связьинформсервис» (г. Киев), ООО «Астра» (г.Верхнеднепровск), промышленная группа « КМТ» (г.Винница), ООО «Платан» (г.Симферополь), Львовский банковский институт, ООО «Украинские новейшие технологии» (г.Киев); 24 открытых семинара в г. Киеве).

Покажем свой язык...

Семантической основой ЯМТ является так называемое правило «четырех сторон», которое продекларировано в методике структурного анализа и проектирования SADT [3]. Необходимо отметить, что первенство использования этого правила в стандарте США  сомнительно, т.к. оно использовалось до появления SADT в упомянутом выше проекте АСУ «Скат» бывшего СССР в 70-х годах.

ЯМТ позволяет описывать бизнес-процессы любой степени подробности, но как показала практика его использования в интересах наших Заказчиков (предприятий, внедряющих процессный менеджмент), наибольшую ценность для них представляет только максимальная степень подробности описания бизнес-процессов (одна функция (операция) процесса – конкретное должностное лицо). Только в этом случае возможно успешное решение известной задачи организационного программирования при реорганизации деятельности предприятия (рис. 2). Данная реальность заставила нас разработать и применять на практике соответствующую методику предварительного обследования предприятия, создание моделей «как есть» и «как надо» (данная методика является предметом отдельной статьи.) Кроме того, основываясь на утверждении: «Аудит бизнес-процессов – это оценка соответствия их осязаемого отображения установленным правилам композиции», ЯМТ – диаграммы позволяют оценивать качество модели бизнес-процессов по 18-ти базовым правилам (методика аудита является предметом отдельной статьи).

Рис. 2   Схема непрерывного улучшения результативности и эффективности деятельности предприятия

При начертании диаграмм бизнес-процессов с использованием ЯМТ используются следующие базовые  соглашения и  элементы:

1. Функциональные действия (работы) изображаются прямоугольником. 
2. Стрелки слева (входы) отображают входные информационные и/или материальные потоки,   необходимые для осуществления функциональных действий.
3. Стрелки справа (выходы) отображают результаты исполнения функциональных действий.
4. Стрелки снизу отображают необходимые для исполнения функциональных действий ресурсы(например: оператор, рабочий, станок и т. п.).
5. Стрелки сверху отображают объекты, являющиеся основанием для исполнения функциональных действий. Это могут быть ГОСТы и/или рабочие инструкции, а также другие документы – основания.
6. Стрелки могут разветвляться и сливаться, тем самым, образуя иерархию данных.
7. ЯМТ-диаграммы бизнес–процессов должны начинаться и заканчиваться графическим изображением информационных и/или материальных сущностей.

Элементы связей (туннелирования):

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

Базовые функциональные элементы:

	Функциональное действие; F3 – третья функция бизнес-процесса;
	Документ на входе (выходе) функционального действия (функции); D3.1 – первый документ на выходе третьей функции ( F3 ) данного бизнес – процесса;
	Первый документ – основание для выполнения второй функции данного процесса;
	Электронная форма документа D3.1 и/или База Данных (БД);
	Центр должностной ответственности за выполнение данной функции данного бизнес-процесса;
	Комментарий;
	Центр должностной ответственности при выполнении данной функции бизнес-процесса использует компьютер;
	Программный модуль АРМа исполнителя (ресурс), поддерживающий выполнение четвертой функции данного бизнес-процесса.

В отличие от известной нотации описания бизнес-процессов IDEF 0 в ЯМТ- нотации для отображения логики взаимодействия потоков данных (информации) используется пять базовых логических элементов:

	Ветвление процесса по условию;
	Последующее действие возможно при условии одновременного наличия на входах всех результатов предшествующих работ;
	Последующие действие на выходе возможно при условии наличия на входах любого сочетания результатов предшествующих работ;
	Результат одного предшествующего действия передается на входы последующих действий (размножение одного входа на несколько выходов по логике ИЛИ)
	Результат одного предшествующего действия обязательно (одновременно) передается на входы всех последующих действий

Пример использования элементов ЯМТ при создании модели бизнес-процесса представлен на рис. 3 (Этот же бизнес-процесс в нотации IDEF0 BPwin представлен на рис. 4 [5]). Из сравнения рис. 3 и рис. 4 следует, что в отличие от IDEF0 BPwin в ЯМТ предусмотрено:

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

ЯМТ – диаграммы бизнес-процессов имеют одноуровневую ленточную структуру представления (рис. 5), что позволяет ее композировать собственно как ленту с нанесением временной оси (при необходимости) или в виде набора отдельных листов (рис.6-1 ÷ 6-3 ).

Опыт работы с ЯМТ – диаграммами показал, что известная рекомендация [3]: «... для ведения небольших по масштабам (малые и средние предприятия, 2-5 человек в группе консультантов (2-3 месяца) проектов рационально использовать BPwin. Для крупных и/или длительных проектов (например, внедрение системы непрерывного улучшения бизнес-процессов, ISO, TQM) больше подходит ARIS...» не является ограничением для использования ЯМТ. Кроме того, ясность и простата бизнес-процессов с использованием ЯМТ позволяет нашим бизнес-консультантам отказаться от традиционной текстовой (промежуточной) формы записи интервью с исполнителями бизнес-процессов с последующим «переводом» текста в графическую форму диаграмм бизнес-процессов с использованием CASE-средства, но уже без участия самих исполнителей. Это интервью после небольшого пояснения правила «четырех сторон» и сути логистики бизнес-процессов сразу записывается в виде ЯМТ – диаграмм с активным участием и интересом со стороны интервьюируемых.

И еще об одном известном суждении [3]: « ...Рациональный выбор системы (CASE- системы описания – прим. автора) возможен при понимании руководством компании и ее специалистами нескольких аспектов:

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

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

Цитируемые источники информации:

1. Сахаров Павел. Rational Rose, BPwin и другие  - аспекты анализа бизнес-процессов / www.osp.ru
2. Золотухина Е.Б., Алфимов Р.В. Пример описания предметной области с использованием Unified Modeling Language (UML) при разработке программных систем / www.interface.ru
3. Репин В.В. Сравнительный обзор нотаций. Часть 1. Введение. Типовые задачи описания бизнес-процессов. Требования к описанию бизнес-процессов предприятий / www.interface.ru
4. Репин В.В. Проблемы применения IDEF0 (и не только) для описания процессов / www.finexpert.ru
5. Разработка документа «А», модель в IDEF0-IDEF3 / www.finexpert.ru