С точки зрения управления организацией процессный подход представляет собой систематическую идентификацию применяемых организацией процессов и их взаимодействия и управление ими. Он позволяет перейти от текстового описания деятельности (содержащегося в нормативных документах организации, таких как положения о подразделениях, должностные инструкции, технологические карты производственных процессов) к полному формализованному графическому описанию деятельности.
Описание деятельности организации (в том числе и процессов), сделанное с достаточной степенью полноты, исключительно трудоемко. Поэтому подобная работа обычно осуществляется постепенно - с описания наиболее значимых процессов верхнего уровня с их детализацией, при этом основное внимание уделяется критически важным для компании предметным областям.
Различные поставщики средств моделирования и консалтинговые компании используют разную терминологию, описывающую совокупность моделей процессов в рамках процессного подхода; различная терминология применяется и в разных проектах по описанию бизнес-процессов. В качестве примера приведем иерархию процессов, представленную в учебном курсе "Методы и средства управления бизнес-процессами" компании "IDS Scheer Россия и страны СНГ":
- процессы верхнего уровня;
- подпроцессы;
- сценарии процессов;
- процедуры;
- функции.
При этом корректным считается такой подход к моделированию, когда модель любого уровня (кроме верхнего) является детализацией объекта какой-либо модели предыдущего уровня (такой подход, в частности, поддерживается продуктами семейства ARIS компании IDS Scheer и инструментом AllFusion Process Modeler (BPwin) компании Computer Associates). Детализация - это условный прием, позволяющий представить систему в виде, удобном для восприятия и анализа, и сделать модели более читаемыми и понятными (рис. 1).
Рис. 1. Детализация объекта на модель последующего уровня
При выделении процессов верхнего уровня, как правило, выбирают наиболее значимые для организации (их называют основными процессами), а также процессы, создающие инфраструктуру организации и обеспечивающие выполнение основных процессов (пример процессов верхнего уровня приведен на рис. 2).
Рис. 2. Пример модели процессов верхнего уровня
Состав процессов верхнего уровня может быть различным, но во многих случаях при моделировании придерживаются так называемой 13-процессной модели, созданной по данным Международной бенчмаркинговой палаты (International Benchmarking Clearinghouse), - см. рис. 2. Впрочем, существуют и другие подходы к моделированию, в основе которых лежит иной способ определения процессов верхнего уровня.
Разные типы моделей и их взаимосвязи
Отметим, что помимо процессов моделируются и иные аспекты деятельности организации. Так, одной из традиционно используемых является модель организационной структуры (подобные модели, начерченные тушью на листах ватмана, можно было увидеть еще в 1970-80-х годах во многих советских государственных организациях; современный вид модели организационной структуры представлен на рис. 3).
Рис. 3. Примеры моделей организационной структуры
Нередко при описании деятельности компаний применяются модели документов, знаний, полномочий, целей, информационных систем, материальных и производственных ресурсов и многие другие.
Нередко одни и те же объекты могут использоваться в разных моделях. Так, на модели процесса и на модели оргструктуры могут присутствовать одни и те же объекты (например, исполнители функций, выполняемых в течение процесса, - рис. 4).
Рис. 4. Пример использования одного и того же объекта на разных моделях
Общие объекты могут быть на модели процесса и на модели документов, на модели информационных систем и на модели процесса, на модели оргструктуры и на модели полномочий и т.д.
Иными словами, описание деятельности организации представляет собой совокупность взаимосвязанных и взаимодополняющих графических моделей различных типов, каждая из которых описывает ситуацию в конкретной предметной области деятельности.
Технические аспекты реализации взаимосвязей моделей
Когда мы рассматриваем взаимосвязи между моделями с помощью детализации объекта на другую модель с логической точки зрения, то не должны забывать о том, как реализовать подобную взаимосвязь технически. К примеру, если мы применяем средство моделирования, которое хранит каждую модель в виде отдельного файла, то следует отдавать себе отчет в том, что при детализации объекта на модель нужно где-то хранить ссылку на файл (например, в каком-то атрибуте объекта). Это означает, что средство моделирования должно как минимум поддерживать атрибуты, позволяющие хранить подобные данные, а еще лучше - предоставлять настолько дружественный интерфейс, чтобы по щелчку мыши на подобном атрибуте средство моделирования открывало соответствующий файл. Кроме того, следует помнить, что при переносе файлов с моделями в другой каталог ссылки на файлы в атрибутах моделей могут оказаться недействительными. А ведь при подробном описании деятельности предприятий число моделей вполне может быть четырехзначным… Иными словами, проблема технической поддержки в работоспособном состоянии совокупности связанных между собой подобным образом моделей может оказаться весьма серьезной.
Решить ее позволяет применение средства моделирования, которое дает возможность хранить совокупность моделей как минимум в едином файле, а еще лучше - в какой-нибудь серверной СУБД с реализацией многопользовательского доступа и разграничением доступа к данным (ведь четырехзначное число моделей, как правило, создает не один человек). Из доступных на рынке и распространенных в России решений к таким инструментам относятся средства моделирования семейства ARIS и более дорогой набор инструментов AllFusion Modelling Suite (включающий инструмент для коллективной работы над моделями ModelMart). Предлагаются также решения на основе Visio, реализующие подобную функциональность, но созданы они не столь известными партнерами Microsoft, а потому не факт, что стоит их искать, - по причине отсутствия в России услуг по их технической поддержке и обучению работе с ними.
Что такое "один и тот же объект"?
Еще одна проблема реализации взаимосвязей заключается в четком определении, что такое "один и тот же объект" при наличии одних и тех же объектов на разных моделях. Эта проблема намного более серьезна, нежели организация ссылок на файлы в предыдущем случае. Первое приходящее в голову определение понятия "один и тот же объект" выглядит примерно так: это объекты того же типа (к примеру, отображаемые одинаковыми символами или символами, принадлежащими к одной группе, - это зависит от того, как именно поддерживается концепция типа объекта в средстве моделирования), обладающие одинаковыми названиями или, в случае поддержки средством моделирования множества атрибутов, с одинаковым набором атрибутов.
Если мы моделируем деятельность одного предприятия, то объект "главный бухгалтер" вполне может быть одним и тем же на разных моделях - как правило, главный бухгалтер на предприятии один. Но, к примеру, является ли одним и тем же объект "служебная записка" на разных моделях? Авторы разных моделей вполне могут назвать одним и тем же словосочетанием "служебная записка" такие разные объекты, как служебная записка на выдачу денег на командировочные расходы и служебная записка на предоставление автотранспорта, - ведь они мыслят в ограниченных рамках моделируемого процесса, в котором вполне может фигурировать один-единственный тип служебной записки. А если вернуться к примеру с объектом "главный бухгалтер", но моделировать деятельность не отдельного предприятия, а холдинга? Очевидно, что главных бухгалтеров в холдинге будет как минимум столько же, сколько предприятий входит в его состав.
Данная проблема, конечно же, может быть решена путем установки строгих правил именования объектов и ограничений на значения их атрибутов, а также строгого определения, что такое "один и тот же объект", - то есть организационных, а не технических решений. Но есть и еще одно решение: хранить описания объектов как бизнес-сущностей отдельно от моделей, в то время как на сами модели помещать ссылки на эти описания. Из доступных на российском рынке средств моделирования, пожалуй, подобной особенностью хранения данных сегодня обладает только ARIS (под словосочетанием "доступный" я подразумеваю продукт, обеспеченный в России предпродажными консультациями, технической поддержкой и обучением на русском языке) - это решение поддерживает концепцию определения объектов и связей как элементов данных, содержащих сведения о типе объекта, названии, атрибутах, и экземпляров объектов, содержащих сведения о символе, его цвете, размере, местоположении, толщине линий, шрифте надписей - то есть о визуальных характеристиках отображения на модели.
Впрочем, из вышеизложенного отнюдь не следует, что ARIS - это панацея от всех бед и именно то средство моделирования, которое нужно всем и всегда. Еще раз повторю: выбор средства моделирования зависит от его целей и задач. Если нужна одна модель - ее можно нарисовать ручкой на бумаге; если нужно пять моделей (даже связанных между собой) - подойдет любое средство моделирования, поддерживающее нужную для решения поставленной задачи нотацию (например, самая дешевая версия Visio или какой-нибудь бесплатный инструмент типа Borland Together Designer). А вот если моделей несколько сотен - выбор инструмента моделирования должен быть тщательным, поскольку последствия неправильного решения, как показывает практика, обходятся компаниям слишком дорого.