Диссертация (1152223), страница 21
Текст из файла (страница 21)
Соответственно, надо переводить вСУБП соответствующие подпроцессы. Даже, если основной процесс уже автоматизирован,можно рассматривать деятельность автоматизируемого подразделения как подпроцесс основного процесса. Такой подход позволяет не потерять основную цель процессного подхода – добиться сокращения времени исполнения всего процесса, улучшения его качества.Переход к процессному управлению с использованием СУБП может потребовать существенных усилий, связанных с детальным моделированием и реинжинирингом процесса.
Чтобы затраты окупились, выбираемый процесс должен отвечать определённым требованиям:Иметь высокую ценность для организации, явно или косвенно способствовать достиже-нию стратегических целей организации;Характеризоваться высокой стоимостью принятия ошибочного решения;Являться кросс-функциональным, в нем участвуют различные структурные подразделе-ния организации;Отличаться регулярностью исполнения процесса, создавать большой поток заявок;Иметь жёсткие ограничения по времени обработки;Включать большое число ручных операций;Создать высокую нагрузку на персонал;Характеризоваться разнообразием критериев при принятии решений;Создавать интенсивное взаимодействие с автоматизированными системами;–Логика исполнения процесса может быть формализована.Выбор процесса является первым, но крайне важным шагом, после которого можно переходитьк работам по проектированию СУБППроект по созданию СУБПРассмотрим типовой проект по созданию СУБП, он состоит из следующих этапов, показанных на рисунке 2.9:Выявление процесса имеет целью создание модели «как есть» - проводится комплекс ра-бот по выбору, определению границ, выделению, декомпозиции, выбору архитектуры и моделированию процесса.80Реинжиниринг процесса предполагает анализ узких мест процесса «как есть» и разработкунового процесса «как должно быть»;Разработка технического задания на систему автоматизации предполагает формулирова-ние требований к системе в целом, к её функциям (задачам), к видам обеспечения;Разработка исполняемой модели бизнес-процесса предполагает доработку аналитическоймодели таким образом, чтобы она могла быть исполнена в среде исполнения СУБП;В тех случаях, когда автоматизация не предполагается, так что переход к процессномууправлению осуществляется чисто организационными методами, проводится регламентация,формируются подробные инструкции, на основании которых исполнители должны осуществлять свою работу;Исполнение процесса предполагает сбор информации - показателей продукта и процесса,которая впоследствии используется для расчёта различных показателей качества процесса;На этапе контроля рассчитанные показатели сравниваются с нормативными показателями,что позволяет выявить отклонения процесса.
Оперативное управление предполагает выполнение корректирующего воздействия непосредственно в ходе исполнения экземпляра процесса,стратегическое управление предполагает реинжиниринг процесса.ДокументыЗаконыВыявитьпроцессA1Модель «как есть»Провестиреинжиниринг БПA2Предложения по улучшениюНормативыМодель «как должно быть»Корректирующее воздействиеРазработать ТЗна автоматизациюA3Показатели процессаТЗРазработатьИСA4СоставитьРегламентрегламент процессаA5ВходпроцессаАналитик,АрхитекторТехнологАналитик,Технолог,ВладелецАналитикИТ специалистКонтролироватьисполнениеA7ИСПоказателипродуктаИсполнятьпроцессA6ИсполнителиРезультат процессаМенеджер процесса,ВладелецРисунок 2.9 - Этапы проекта по созданию СУБПИсточник: составлено автором.Временная структура метода моделирования бизнес-процессовЭтапы проекта моделирования бизнес-процессов показаны на рисунке 2.10:Выбор процесса заключается в обосновании, почему аналитик решил обратить вниманиена определённый процесс.
Важно показать, что процесс является критически важным для предприятия. Чтобы обосновать выбор процесса необходимо дать развёрнутый ответ на вопрос: чтопроизойдёт с организацией, если она не станет заниматься анализом и улучшением этого про-81цесса? Если соответствующие доводы отсутствуют, значит все усилии аналитика окажутся бессмысленными, а результаты невостребованными.Выделить (идентифицировать) границы означает определить точку старта и точку завер-шения процесса, определить все события, которые могут привести к старту процесса или оказать существенное влияние на его исполнение.Выявление процесса — это деятельность, направленная на обнаружение логики выполне-ния работ, логической структуры связей между работами, образующими процесс и между объектами, обрабатываемыми в данном процессе.Разработка архитектуры процесса предполагает выделение повторно-используемых ком-понентов процесса, разделение одного монолитного бизнес-процесса на семейство взаимодействующих подпроцессов.
Цель заключается в создании иерархической модели, где верхнийуровень даёт самое общее представление о ходе процесса, а все детали, важные для его исполнения, «спрятаны» на нижних уровнях.Моделирование процесса заключается в создании интегрированной модели бизнес-про-цесса, объединяющей несколько связанных и диаграмм, каждая из которых показывает отдельные аспекты исполнения, а все вместе они описывают динамику его исполнения.Верификация модели бизнес-процесса заключается в проверке соответствия каждой измоделей правилам, задаваемым соответствующей нотацией моделирования;Валидация модели бизнес-процесса проверку соответствия полученной модели бизнес-процесса требованиям, которые предъявляет заказчик моделирования.ВыбратьпроцессВыявитьграницыпроцессаВыявить логикупроцессаРазработатьархитектурупроцессаПостроитьмодельпроцессаВерифицировать Валидироватьмодель бизнес- модель бизнеспроцессапроцессаРисунок 2.10 - Этапы создания исполняемой модели бизнес-процессаИсточник: составлено автором.Некорректные требования к процессной системеРассмотрим типовые проблемы, возникающие при разработке СУБП предприятия.
Оченьчасто заказчики просят реализовать в СУБП возможности, к которым они привыкли, работая сфункциональными системами, но которые не очевидны для процессных систем. Например, хотят вручную раздавать поручения, контролировать их исполнение и т.д. В случае перехода организации к процессному управлению, эти функции не исчезнут, но будут формализованы ипревратятся в автоматические или будут перераспределены между участниками, но принципвзаимодействия сохранится. Однако часто пользователи не доверяют автоматизации и стремятся сохранить за собой автоматизируемые функции. В последнем случае может случиться, чтосильные стороны СУБП не будут использованными.82В правильно спроектированном бизнес-процессе руководители освобождаются от выполнения рутинных операций. Им больше не нужно контролировать каждое проходящее черезподразделение задания, поскольку они уверены, что будут оповещены о любом отклонении отнорматива: отставаниях, нестандартных условиях, исключительных ситуациях, когда их участие действительно необходимо.
Рядовые сотрудники освобождаются от необходимости контролировать исполнение процесса, поскольку они уверенны, что получат оповещения о любых,значимых для данного пользователя, изменениях в процессе или в данных.Некорректное задание на разработку СУБПСоздание корпоративных информационных систем характеризуется высокими рисками,неудивительно, что заказчик хочет переложить большую их часть на исполнителя. Для этого онхочет подписать контракт с фиксированными ценой и функциональностью внедряемого решения, зафиксировав все требования в техническом задании.
Риски разработчика заключается втом, что проектах по созданию СУБП, реализуемых по методологии SCRUM, трудно различитьмомент, когда заканчивается реализации первоначальных требований и начинается реализацииновых, возникших по ходу реализации проекта. Поэтому разработчик хотел бы заключенияконтракта на условиях возмещения затрат. Возникает коллизия интересов сторон. Обе стороныоказываются не готовы к работам по методологии SCRUM. Дело в том, что разработка СУБПначинается с раскрытия бизнес-процесса и предполагает последовательное уточнение модели сцелью добиться её полного соответствия требованиям заказчика.
При этом требования возникают и уточняются прямо по ходу проекта. На каждом этапе для каждого требования устанавливается приоритет, многие пожелания вообще не реализуются.Техническое задание для проекта, реализуемого по методологии SCRUM [24] должномаксимально подробно описывать все требования, за исключением собственно процесса. Последний должен быть описан достаточно общо, без деталей, которые смогут быть выявленытолько по ходу исполнения. Очень важно заранее оговорить границы процесса, чтобы не допустить его последующего расползания.
Следует отметить, что увеличение числа шагов повышаетсебестоимость реализации, но не пропорционально числу шагов. Важно выявить число точекинтеграции и типы подключаемых систем, наличие в них стандартных интерфейсов для подключения. Следует оценить количество документов, участвующих в принятии решения, ихразмер, степень формализации.Недостаточно интегрированная модель бизнес-процессаИсполняемая модель процесса является интегрированной. Она объединяет несколько диаграмм, каждая из которых описывает отдельные аспекты его структуры, а все вместе они обра-83зуют полное и комплексное представление о динамике его исполнения.
Если частные перспективы, образующие интегрированную модель, недостаточно интегрированы между собой, потребуется дополнительное кодирование и программирование, модель станет сложно сопровождать, она потеряет свойство гибкости и адаптивности.Не следует недооценивать трудоёмкость создания информационной модели. ПосколькуСУБП наиболее эффективны при работе со структурированными документами, трудозатраты насоздание информационной модели могут оказаться значительными. Плохо организованная информационная модель может оказать негативное влияние на производительность процесса. Дело в том, что большинство СУБП хранят данные в упакованном формате, причём после выполнения каждой операции процесса записывает данные в постоянную память. При этом, загрузкаи выгрузка большого массива данных с преобразованием в XML может потребовать значительных временных затрат. Если изобразить сквозной процесс как монолитный, скорее всего размеринформационных объектов окажется значительным, так что работа с ними может замедлиться.Выход заключается в разбиении сквозного процесса на подпроцессы, так, чтобы каждый из нихработал с ограниченным набором информационных объектов.