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

CASE – средства моделирования

Хотя рисовать модели на бумаге не возбраня­ется, современное моделирование бизнес-процессов обычно осуществляется с использованием CASE–средств. Эта аббревиатура означает Computer Aided System Engineering, что переводится как «проектирование систем с помощью компьютера». На современном рынке программного обеспечения CASE–средств не одна сотня. В такой ситуации имеет смысл обсудить их классификацию и задачи, кото­рые можно решить с их помощью (применительно к процессному подходу).

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

Особенностью современных CASE-средств являются:

а) наглядные графические средства для создания моделей;

б) использование средств их хранения в виде файлов или в виде данных в специальном репозитарии;

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

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

CASE–средства можно классифицировать по типам:

а) средства анализа и моделирования, пред­назначенные для создания описаний про­цессов и иных предметных областей;

б) средства анализа и проектирования, ис­пользуемые для управления требования­ми и документирования IT–проектов;

в) средства проектирования дан­ных, обеспечивающие модели­рование данных и генерацию структуры СУБД;

г)  средства моделирования приложений (се­годня наиболее распространенной катего­рией таких средств является семейство средств UML–моделирования).

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

–  Together Architect фирмы Borland (Приложение, рис. 1);

–  семейство AllFusion Business Process Modeler (фирма BPwin) для описания бизнес-про­цессов с помощью методологии IDEF0 (Computer Associates) и организации коллективной рабо­ты над единым репозитарием моделей (Приложение, рис. 2);

–  ARIS Bisiness Architect (фирма IDS Scheer) – инструмент коллектив­ной работы над совокупностью взаимосвязанных моделей раз­личных типов (Приложение, рис. 3), предназна­ченных для описания бизнес-про­цессов, данных и информацион­ных систем, деятельности компа­ний;

–  Visio (фирма Microsoft) – средство создания моде­лей бизнес-процессов и данных с применением раз­личных методологий (Приложение, рис. 4).

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

Реализация процессного подхода при моделировании

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

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

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

В качестве примера приве­дем иерархию процессов, представленную в учебном курсе «Методы и средства управле­ния бизнес-процессами» компании «IDS Scheer»:

• процессы верхнего уровня;

• подпроцессы;

• сценарии процессов;

• процедуры;

• функции исполнителей.

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

Состав процессов верхнего уровня может быть различным, но во многих случаях при моделировании придерживаются так называ­емой тринадцатипроцессной модели (Приложение, рис. 5) Международной бенчмаркинговой палаты (International Benchmarking Clearing house – IBCH).

Основные процессы:

1. Изучение рынков и потребителей.

2. Разработка видения и стратегии (стратегический маркетинг).

3. Разработка продуктов и услуг.

4. Маркетинг и продажи.

5. Производство и поставка продуктов производственными компаниями.

6. Оказание услуг сервисными компаниями.

7. Выставление потребителям платежных требований и сервис.

Вспомогательные процессы:

8) Профессиональное и карьерное развитие кадров и управление персоналом.

9) Управление информационными ресурсами и технологиями.

10) Управление финансовыми и матриальными ресурсами.

11) Управление охраной окружающей среды.

12) Управление внешними связями.

13) Управление совершенствованием бизнес-процессов.

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

Такой подход, в частности, поддержи­вается продуктами семейства ARIS и инструментом AllFusion. Пример детализации основного процесса «Разработка видения и стратегии» в модели последующего уровня (рис. 6 Приложения):

Стратегический маркетинг:

а) разработка видения и стратегии;

б) учет и контроль достижения стратегических целей;

в) анализ стратегических планов;

г) корректировка стратегии.

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

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

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

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

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

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

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

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

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

Из доступных на рынке решений к таким инструмен­там относятся средства моделирования ARIS, Visio и более дорогой набор инструмен­тов AllFusion Modelling Suite, включающий ин­струмент ModelMart для коллективной работы над моде­лями.

Идентификация объектов

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

Идентичные объекты – это объекты одного типа, отображаемые одинаковыми символами, которые обладают одина­ковыми названиями и одинаковым набором атрибутов.

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

Но, к примеру, являет­ся ли одним и тем же объект «служебная записка» на разных моделях? Авторы разных моделей вполне могут назвать одним и тем же словосочетанием «служебная записка» такие разные объекты, как служебная записка на вы­дачу денег на командировочные расходы и служебная записка на предоставление отпуска – ведь они мыслят в ограничен­ных рамках моделируемого процесса, в кото­ром вполне может фигурировать один-един­ственный тип служебной записки.

А если вер­нуться к примеру с объектом «главный бухгалтер», но моделировать деятельность не от­дельного предприятия, а холдинга? Очевидно, что главных бухгалтеров в холдинге будет как минимум столько же, сколько предприятий.

Пример использования одного и того же объекта в разных моделях приведен на рис. 8 Приложения.

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

Поэтому есть и еще одно решение: хранить описа­ния объектов как бизнес–сущностей отдельно от моделей, в то время как в самих моделях помещать только ссылки на эти описания.

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

Выбор средства моделирования зависит от его целей и задач. Если нужна одна модель – ее можно нарисовать карандашом на бумаге. Если нужно пять моделей – подойдет любое средство моделирования, поддерживающее нужную для решения поставлен­ной задачи нотацию (например, самая дешевая версия Visio или какой-нибудь бесплатный инструмент типа Borland Together Designer).

A вот если моделей несколько сотен – выбор инст­румента моделирования должен быть тщатель­ным, поскольку последствия неправильного решения обходятся компаниям слишком дорого.