В статье рассмотрены основные принципы моделирования бизнес-процессов предметной области при разработке программного обеспечения с IBM Rational Software Architect . Умный в гору не пойдет, умный гору обойдет… (Почему необходимо выполнять моделирование бизнес-процессов)
Под влиянием различного рода причин (от желания не отставать от модных тенденций до решимости действительно повысить эффективность функционирования), руководством отечественных предприятий все чаще принимается решение о необходимости автоматизации деятельности посредством внедрения информационной системы и/или систем (ИС). При этом не важно, будь то корпоративная ИС (КИС), покрывающая большинство ключевых процессов предприятия либо "коробочный" программный продукт, созданный для решения узких специфических задач, таких как управление взаимоотношениями с клиентами либо ведение бухгалтерского учета. Более того, в последние годы наблюдается значительный перевес в сторону случаев обращения за подобного рода услугами к сторонним организациям, специализирующимся на разработке программного обеспечения (ПО), нежели попыток осуществить разработку очередной программной системы (ПС) собственными силами "с нуля". Тем не менее, сам факт передачи на аутсорсинг работ по разработке и/или поставке необходимого ПО, к сожалению, не исключает полностью те риски, которые присущи проектам по автоматизации деятельности предприятия за счет усилий внутренних специалистов ИТ-подразделений. К таким рискам можно отнести следующие.
- Отсутствие у разработчиков полномочий, необходимых для принятия взвешенных проектных решений относительно целесообразности, технической возможности, необходимости и т.д. реализации требований, поступающих от сотрудников автоматизируемых подразделений и других так называемых внутренних заказчиков (в роли которых могут выступать и представители топ-менеджмента организации). Ярким наглядным примером описанной проблемы может являться ситуация, при которой у руководителя проекта по автоматизации "связаны руки" в буквальном смысле этого слова - т.е. он, являясь лицом, ответственным за успех проекта, не имеет возможности принимать решения о том, что, как и в какие сроки должно быть реализовано.
- Ситуация, когда одной лишь автоматизацией добиться ожидаемого эффекта невозможно просто потому, что нелепо автоматизировать то, что само по себе неэффективно и, тем более, не формализовано в виде четкой документированной последовательности шагов или действий, выполняемых сотрудниками автоматизируемых подразделений. Другими словами, в результате попытки автоматизировать беспорядок рискуем получить не более чем автоматизированный беспорядок. Причем еще неизвестно, что хуже! В качестве небольшого лирического отступления приведем не совсем точную цитату из достаточно известной книги "Камень программиста": "...говоря, что сложность по своей внутренней сути необъяснима, <…> мы вынуждены создавать все более сложные процедуры, чтобы избежать ответственности". В случае, если мы приступаем к автоматизации прежде, чем ключевые моменты предметной области представлены в виде строгого формализованного описания, мы с большой долей вероятности получим вместо хорошо структурированного программного продукта нечто до такой степени запутанное, что при первых же попытках внести в это "нечто" какие-либо изменения (будь то исправление ошибок либо расширение существующей функциональности) решим, что проще бросить это "гиблое дело" и все переделать!
Одним из ключевых факторов, позволяющих избежать подобных негативных эффектов, является наличие документально подтвержденной возможности у руководителя проекта по автоматизации оказывать влияние на принятие решений о необходимости и способах перестройки бизнес-процессов организации (а также, возможно, и организационной структуры).
Безусловно, перечень рисков, которые могут помешать достижению целей программного проекта, таких как повышение эффективности деятельности предприятия за счет внедрения информационной системы, может быть продолжен. Тем не менее, здесь мы позволим себе ограничиться описанными выше ситуациями, так как далее мы предполагаем сосредоточиться на методах, позволяющих данные ситуации избегать.
Итак, описанные выше ситуации встречаются, к сожалению, сплошь и рядом, кочуя из одного программного проекта в другой и приводя с завидным постоянством к одним и тем же негативным последствиям. Рассмотрим такие последствия более подробно.
- Разработанная и внедренная ИС не решает и половины тех проблем, для решения которых она была предназначена. Положительным моментом в данном случае будет являться то, что информационная система, тем не менее, разработана, более того, внедрена, возможно, используется сотрудниками автоматизируемого предприятия и, в лучшем случае, в чем-то упрощает выполнение ими служебных обязанностей, повышая тем самым эффективность работы всего предприятия.
- Информационная система содержит около половины запланированных к реализации функциональных возможностей, т.е. проект находится где-то на середине. Ситуацию можно охарактеризовать следующей фразой: дошли до середины пути и поняли, что всё нужно переделать, так как на самом деле нужно не то, что реализовано, а что-то другое, причем это "что-то другое" никаким образом не вписывается в уже существующую структуру. Такая ситуация, хотя и выглядит удручающе, на самом деле является очень распространенной. Она возникает в тех случаях, когда вместо того чтобы составить четкое представление о том, что есть, какие существуют проблемы и какие из них могут и должны быть решены посредством автоматизации, лица, задействованные в разработке, стремятся как можно скорее реализовать хоть что-нибудь и представить на суд заказчика. Плюс здесь только один - путем неимоверных и излишних усилий, возможно, все-таки в конце-концов будет достигнуто понимание того, что действительно должно быть сделано для решения существующих проблем, а также получено представление о том, какие на предприятии существуют проблемы.
Какой же вывод может быть сделан на основе всего сказанного выше? Прежде чем приступать к автоматизации, необходимо поработать с самой предметной областью: описать существующие бизнес-процессы, организационную структуру автоматизируемого предприятия, идентифицировать существующие проблемы, продумать пути их решения, выявить те из них, которые могут быть решены прямо или косвенно за счет автоматизации. Если эффективность рассматриваемого процесса может быть повышена в случае передачи его исполнения информационной системе, то данная проблема может быть решена прямо посредством автоматизации. Если же эффективность рассматриваемого процесса может быть повышена в случае его предварительной модификации с целью последующей автоматизации, то автоматизация будет косвенно способствовать решению данной проблемы.
Всё, возможно, могло быть иначе… (Правила описания бизнес-процессов. Обоснование возможности применения Activity diagram для описания бизнес-процессов в IBM Rational Software Architect )
Реинжиниринг всех бизнес-процессов предприятия, сопровождаемый существенными изменениями организационной структуры, - процесс трудоемкий и, как правило, не осуществимый в рамках среднестатистического проекта по внедрению ИС, призванной решить какие-то отдельные задачи, стоящие перед сотрудниками автоматизируемых подразделений, взаимодействующих в ходе осуществления своей деятельности. Но в то же время локальные изменения процессов, подлежащих автоматизации, как правило, возможны и даже необходимы. Здесь действует простое правило: автоматизировать можно лишь то, что поддается формализации (при этом под формализацией принято понимать процесс представления информации об объектах, явлениях реального мира и мыслительной деятельности человека в формализованном виде, форме, т.е. в знаково-символьном выражении).
Итак, каков же должен быть порядок наших действий, чтобы уже на начальных стадиях выполнения проекта по автоматизации избежать описанных выше негативных последствий? Для того чтобы ответить на этот вопрос, обратимся к стандарту ГОСТ Р ИСО 9001-2001, представляющему собой аутентичный текст стандарта ИСО 9001-2000 "Системы менеджмента качества. Рекомендации по улучшению деятельности". Данный стандарт "направлен на применение "процессного подхода" при разработке, внедрении и улучшении результативности системы менеджмента качества с целью повышения удовлетворенности потребителей путем выполнения их требований". Стандарт ГОСТ Р ИСО 9001-2001 говорит о необходимости определения и управления системой взаимосвязанных процессов с целью повышения эффективности деятельности организации. Общим требованием данного стандарта является то, что организация "должна разработать, задокументировать, внедрить и поддерживать в рабочем состоянии систему менеджмента качества", постоянно улучшая ее результативность в соответствии с требованиями стандарта ГОСТ Р ИСО 9001-2001. В рамках системы менеджмента качества организация должна выполнять следующие действия.
- Определять процессы, необходимые для системы менеджмента качества, и их применение во всей организации.
- Определять последовательность и взаимодействие этих процессов.
- Определять критерии и методы, необходимые для обеспечения результативности как при осуществлении, так и при управлении этими процессами.
- Обеспечивать наличие ресурсов и информации, необходимых для поддержки этих процессов и их мониторинга.
- Осуществлять мониторинг, измерение и анализ этих процессов.
- Принимать меры, необходимые для достижения запланированных результатов и постоянного улучшения этих процессов.
При этом стандарт утверждает, что в процессы, необходимые для системы менеджмента качества, следует включать процессы управленческой деятельности руководства, обеспечения ресурсами, процессы жизненного цикла продукции и измерения. Процессы считаются включенными в систему менеджмента качества в том случае, если они представлены в виде документированной процедуры, что означает, что процедура выполнения процессов разработана, документально оформлена, внедрена и поддерживается в рабочем состоянии.
Если распространить требования данного стандарта на процесс автоматизации деятельности предприятия, в ходе которого так или иначе, как правило, существующие на предприятии процессы изменяются, становится понятным, что прежде всего необходимо определить существующие на предприятии бизнес-процессы. Причем процессы считаются определенными в том и только в том случае, если они описаны, т.е. задокументированы. Итак, приведем определение бизнес-процесса с точки зрения стандарта ГОСТ Р ИСО 9001-2001, а также перечислим основные его атрибуты.
Бизнес-процесс - это устойчивая, целенаправленная совокупность взаимосвязанных видов деятельности (последовательность работ), которая по определенной технологии с использованием ресурсов преобразует входы в выходы, представляющие ценность для потребителя. Часто выход одного процесса образует непосредственно вход следующего.
Атрибутами бизнес-процесса являются:
- владелец бизнес-процесса - должностное лицо, которое имеет в своем распоряжении персонал, инфраструктуру, программное и аппаратное обеспечение, информацию о бизнес-процессе, управляет его выполнением и несет ответственность за его результаты и эффективность;
- потребитель бизнес-процесса :
- внутренний, т.е. находящийся внутри организации и, в ходе своей деятельности использующий результаты (выходы) предыдущего бизнес-процесса;
- внешний, т.е. находящийся за пределами организации и использующий или потребляющий результат деятельности (выход) организации;
- регламент бизнес-процесса - документ, описывающий последовательность операций, ответственность, порядок взаимодействия исполнителей и порядок принятия решений по его улучшениям.
- модель бизнес-процесса - графическое, табличное, текстовое, символьное описание бизнес-процесса либо их взаимосвязанная совокупность.
Определение для каждого бизнес-процесса всех перечисленных составляющих называется описанием бизнес-процесса.
Таким образом, прежде чем приступить к разработке информационной системы и даже к формированию требований к ней, необходимо выполнить обследование автоматизируемого предприятия и последующий анализ результатов обследования с целью получения описания существующих на предприятии бизнес-процессов и разработки рекомендаций по их улучшению. Здесь мы не будем касаться вопросов относительно того, кто этот анализ должен выполнять - специалисты со стороны заказчика, сторонние консультанты или представители компании-разработчика. Сосредоточимся лишь на том, что определенные работы должны быть выполнены и определенные результаты должны быть получены. Также не будем рассматривать ситуации, в которых по тем или иным причинам детальный анализ предметной области проведен быть не может, и не будем концентрировать наше внимание на решении вопроса о том, что делать в этом случае. Рассмотрим лишь достаточно подробно порядок действий, подлежащих выполнению, цели и задачи, решаемые в ходе проведения предпроектного анализа, а также способы оформления получаемых результатов.
Исходной предпосылкой является достаточно банальное и, наверное, уже набившее оскомину утверждение о том, что любое предприятие и любую предметную область можно представить в виде системы, обладающей некоторой структурой и поведением. Если говорить о предприятии, то оно имеет организационную структуру, включающую в себя набор подразделений, связанных тем или иным образом друг с другом. Если сосредоточить свое внимание на предметной области, то она состоит из множества объектов и взаимосвязей между ними. Как объекты предметной области, так и подразделения предприятия являются участниками либо даже непосредственно исполнителями некоторых процессов. Объекты могут сами обладать некоторым поведением либо могут изменяться под воздействием других объектов в ходе того или иного процесса. Что касается подразделений предприятия, то применительно к процессу автоматизации его деятельности подразделения могут либо осуществлять какие-то процессы или отдельные действия в рамках процессов (т.е. быть ответственными за их выполнение), либо могут играть роль вспомогательных единиц, предоставляющих необходимые для осуществления рассматриваемого процесса ресурсы, либо они могут являться потребителями результатов выполнения процесса. Заметим, что те же роли могут играть и внешние по отношению к данному предприятию субъекты (другие организации или физические лица) и объекты (например, информационные системы). Часть осуществляемых процессов может быть автоматизирована. В таком случае можно говорить о том, что данный процесс выполняется данным подразделением с использованием некоторой информационной системы или программно-инструментального средства.
Принято считать, что за счет автоматизации того или иного процесса должна повышаться его эффективность, причем пути повышения эффективности могут быть различны в зависимости от конкретной ситуации. Иногда достаточно всего лишь передать выполнение части каких-то действий той или иной информационной системе. В некоторых случаях ИС позволяет значительно сократить набор выполняемых действий за счет исключения лишних или ненужных. Не редки ситуации, когда необходимо существенным образом модифицировать весь процесс, прежде чем передать все входящие в его состав действия либо необходимую их часть информационной системе. Здесь мы не будем подробно останавливаться ни на способах оценки эффективности существующих процессов, ни на способах их модификации с целью повышения эффективности. Тем более нас не будут интересовать ситуации, которые можно охарактеризовать фразой "хотели как лучше, а получилось как всегда", т.е. ситуации, когда по тем или иным причинам не был достигнут желаемый эффект в результате внедрения информационной системы, хотя и были выполнены все предписываемые действия. В фокусе нашего внимания будет технология, обеспечивающая выполнение всех необходимых действий по описанию бизнес-процессов с целью последующей их автоматизации.
Основными компонентами любой технологии, как известно, являются следующие.
- Процесс, определяющий набор осуществляемых действий и их последовательность.
- Получаемые на выходе результаты.
- Средства и ресурсы, необходимые для выполнения указанных действий и получения нужных результатов (в том числе инструментальные средства).
- Состав исполнителей.
Предлагается такая последовательность действий по описанию и моделированию бизнес-процессов автоматизируемой предметной области.
- Составляется описание существующих на предприятии процессов, выполняется построение модели процессов "Как есть".
- На основе определенных критериев выявляются "проблемные" процессы и/или действия или, иначе, "проблемы".
- Намечаются пути решения выявленных проблем, отдельно выделяются те, которые могут быть решены посредством автоматизации.
- Строятся модели процессов "Как будет", отмечаются те, которые будут (должны быть) автоматизированы.
Описание существующих бизнес-процессов должно удовлетворять следующим требованиям.
- Описание выполняется в виде набора действий и входов/выходов.
- Должны быть указаны исполнители (сотрудники конкретных подразделений, программные средства, другие механизмы и т.д.)
- Определенные в процессе описания действия, составляющие процесс, должны быть классифицированы в соответствии с необходимыми критериями.
- Описание желательно выполнять с использованием специализированного инструментального средства, позволяющего отобразить все необходимые атрибуты бизнес-процесса.
- Результатами деятельности по описанию бизнес-процессов должны являться модели бизнес-процессов автоматизируемой предметной области.
Выявление "проблемных" процессов может быть выполнено посредством использования специализированного инструментального средства либо проблемы могут быть просто перечислены в отдельном документе. Безусловно, желательно, чтобы выявленные проблемы были явным образом связаны с вызывающими их действиями и/или процессами. Еще лучше, чтобы тут же была продемонстрирована связь от проблем к путям их решения.
Что касается модели процесса "Как будет", то его описание должно удовлетворять тем же самым требованиям, что и описание существующих бизнес-процессов. Единственным дополнительным атрибутом является четкое разделение всех действий, входящих в состав процесса, на те, которые будут подлежать автоматизации и те, которые разрабатываемой информационной системой покрыты не будут.
Важным моментом, упрощающим задачу выявления и последующего описания бизнес-процессов, является тот факт, что большинство процессов для большинства предметных областей являются "стандартными" в определенном смысле этого слова. Т.е. можно утверждать, что существует некоторая достаточно общая концептуальная схема, в которую можно "уложить" практически любой процесс. Наглядным примером такой схемы является следующая: "Инициация (возникновение) - Развитие (становление) - Существование (стадия "жизни") - Исчезновение (гибель)". Если говорить о процессе управления, то для него общераспространенной является схема "Планировать - Делать - Контролировать (проверять) - Действовать", положенная в основу стандарта ГОСТ Р ИСО 9001-2001. При этом, если мы хотим применить описанную схему процесса управления к тому или иному объекту или процессу, нам необходимо обеспечить выполнение следующего набора действий: сохранение информации о планируемых показателях, учет информации о текущем состоянии объекта, анализ плановой информации и информации о текущем состоянии управляемого объекта и регулирование. Нетрудно заметить, что своего рода стандартные процессы или, иначе, так называемые шаблоны процессов присутствуют в любой предметной области. Например, если говорить о деятельности любого магазина, то ее можно уложить в следующую схему: "Обеспечение необходимого товара в наличии - Продажа товара". Если говорить о строительстве зданий, то схема будет выглядеть приблизительно следующим образом: "Выбор и оформление места строительства - Строительство - Сдача готового объекта". И, наконец, всем нам хорошо известно, что процесс разработки программного обеспечения также укладывается в соответствующую концептуальную схему.
Такая общая схема какого-либо процесса играет роль своего рода шаблона или каркаса. При выполнении анализа предметной области понимание такой общей схемы аналитиком (и вообще ее наличие) существенно упрощает стоящую перед ним задачу, которая сводится к необходимости определить детали конкретной реализации данного схематичного процесса на данном предприятии. Другими словами, в большинстве случаев мы не просто выявляем процессы на том или ином предприятии, а пытаемся идентифицировать, т.е. определить технологию выполнения процесса.
Диаграммы деятельности (Activity Diagram) унифицированного языка моделирования UML в IBM Rational Software Architect как раз и позволяют отобразить не только сам процесс, но и каркас, в который его можно "уложить", позволяя создать так называемые контейнеры для составляющих процесс действий. Кроме того, действия, составляющие анализируемый процесс, могут быть классифицированы на диаграмме деятельности в соответствии с другими критериями, набор которых может зависеть как от специфики анализируемой предметной области, так и целей, преследуемых аналитиком. К наиболее общим критериям, тем не менее, можно отнести следующие:
- диапазон себестоимости/затрат на выполнение;
- частота выполнения/периодичность;
- диапазон эффективности (низкая, средняя, высокая);
- исполнители:
- задействованные подразделения, организации;
- пользователи, информационная система/системы;
- многие другие…