ОРГ-Мастер^® и другие отечественные системы бизнес-моделирования

Лев Григорьев, генеральный директор
консалтинговой группы "БИГ-Петербург"

Этот материал появился в связи с многочисленными обращениями на сайт с просьбами сравнить ОРГ-Мастер с другими российскими системами моделирования. Последний всплеск интереса к теме сравнения возник в связи с началом интенсивного продвижения системы Business Studio (фирма БАЙТ, г. Самара).

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

Периодически на рынок выходят все новые программные продукты, заявляющие о поддержке той или иной популярной технологии менеджмента: Бизнес-Архитектор // Бизнес-процессы (Инталев), ЕМ-Tool (Ориент-Софт, Минск), Бизнес-Инженер (БИТЕК, Москва)¹ , ИСО Ратник (Украина), DocsVision (Digital Design, Санкт-Петербург) и др.

И вот - "Business Studio - новая система класса orgware".

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

Но чем больше продуктов, тем труднее понять, что отличает новую систему от предшествующих.

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

Вот как в случае с Business Studio авторы обосновывают причины, подвигнувшие их на создание этого продукта:

Действительно, есть спрос на качественные и удобные в использовании системы моделирования (Причина 2), который возможно "не закрывается ни одним существующим продуктом моделирования или orgware в полной мере" (Причина 1).

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

Далее, мимоходом лягнув ARIS с BPWin-ом (Причина 3), авторы заявляют, что "именно выходная отчетность в виде регламентных документов является тем краеугольным камнем (!?)³, о который разбиваются надежды (!?) остановиться (!?) в выборе среды моделирования". Поэтому, авторами и была сразу поставлена задача - генерация "конкретизированных регламентов". Вероятно, это надо понимать как создание системы организационной документации, т.е. регламентов выполнения бизнес-процессов, Положений о подразделениях и Должностных инструкций.

Что же на это ответить?

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

Можно просто сказать, что еще пять лет назад эта проблема была поставлена и гораздо эффективнее решена в системе ОРГ-Мастер (БИГ-Мастер⁵). Но почему-то эту систему авторы не замечают⁶, хотя им прямо указывают на нее на форуме их же сайта www.businessstudio.ru: "Раньше думал, что БС - что-то среднее между БИГом и BPwin. Сейчас кажется, что это улучшенный BPwin. Системность БИГа не присутствует".
Но раз сравнение не сделали авторы, придется попробовать сделать это самим, тем более, что многое заставляет сомневаться в эффективности предлагаемого решения.

Еще в 1999 г. в широко распространившейся в Интернете статье нашего ведущего консультанта Валентины Стародуб "Без бумажки ты букашка" были сформулированы подходы к построению современной системы формирования и актуализации организационных регламентов. Главная идея статьи:

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

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

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

Методологии моделирования, подобной тем, которые лежат в основе серьезных систем, вроде ARIS или BPwin (да и БИГ начал не с продукта, а с методологии, т. е. с проекта "Семь нот менеджмента") в материалах по Business Studio мы не обнаружили.

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

Тем не менее, представление о том, что такое моделирование процессов в среде Business Studio можно получить из демороликов, выставленных на сайте авторов этого продукта.

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

Т. е. все, что авторы отнесли к слабым сторонам BPWin, обнаруживается в их собственном продукте. При этом в качестве ядра системы выступает MS Visio, что еще больше усугубляет трудности при работе даже по сравнению с BPwin.

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

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

Вообще, системы, подобные Business Studio, весьма красиво работают на учебных примерах. Но пусть кто-нибудь попробует описать до конца хотя бы деятельность АО "Мир", модель которого представлена в демоверсии Business Studio. Даже этой простой референтной модели в системе не содержится. Что уж говорить о реальном предприятии даже небольшого масштаба!

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

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

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

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

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

1. Документы, точно оговаривающие порядок действий на языке операций

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

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

Отсюда вытекают два следствия: одно чисто техническое - деятельность предприятия в Business Studio описывается исключительно в виде дерева процессов. Но одна и та же функция (операция) может выполняться сотрудником в нескольких процессах. Если операция встречается в нескольких процессах, то при таком подходе она несколько раз попадет в Должностную инструкцию. Но это так, мелочи.

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

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

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

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

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

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

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

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

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

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

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

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

О "безграничных" же возможностях системы Business Studio в этой области - "Поддержка любых управленческих технологий и методик (Стратегический менеджмент, BSC, ИСО, Бюджетирование и др. - (см. раздел "Отличительные особенности и достоинства" в представлении продукта)) говорить не будем - мы их просто не заметили. Как-то уж очень незаметно реализуются.

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

В основном, как нам кажется, реальные проекты с применением Business Studio (а опыта их реализации в этой системе пока нет) потерпят неудачу на "эффекте масштаба". Причем, для этого не надо описывать систему размера Газпром или РАО ЕС. При описании любого реального предприятия, а не отдельно взятого процесса, сложность его модели растет в геометрической прогрессии.

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

Именно возможность строить модели масштаба предприятия и отличает настоящие orgware от систем "рисовалок" типа Business Studio. Хотя возможно и она разовьется до такого уровня.

Пока этот программный продукт можно рассматривать как "игрушечную" систему. Можно поиграть - попробуйте. Посмотрим потом на реальные проекты.

1. Неплохая копия первых версий БИГ-Мастера (версии "БИГ-Менеджмент"). Вероятно, это объясняется происхождением директора фирмы-разработчика - бывшего консультанта группы БИГ.

2. Например, баннер Business Studio появился на одном из популярных Интернет-ресурсов www.consulting.ru.

3. Здесь и далее экспрессивную стилистику текстов авторов Business Studio мы не правим, хотя там есть над чем поработать литературному редактору.

4. Этот термин введен БИГ, см. статью в журнале "Методы менеджмента качества", № 1, 2003 г.

5. Под этой торговой маркой продукт выходил до 2003 года.

6. Инталев, выпустив свою систему Бизнес-Архитектор был куда корректнее, указав на БИГ-Мастер как на первый российский продукт систем этого класса.