Практика и проблематика моделирования бизнес-процессов

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

обеспечение высоких требований по актуализации модели и т. д.

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

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

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

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

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

а) не в полной мере удовлетворяются требования модели к объему исходных данных;

б) отдельные положения имеют неоднозначную трактовку;

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

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

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

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

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

Критично важным для проекта является обеспечение сбалансированного подхода по набору линейки компетенций, задействуемых в процессе построения модели. По сути, формализация и оптимизации (реинжиринг) бизнес-процессов с привлечением моделей предусматривают две обязательные составляющие – аудит организации и формализация результатов аудита. При правильном «разделении» труда в проекте аудит должен выполняться специализированной в соответствующей сфере бизнеса консалтинговой компанией, а формализация результатов аудита с последующей их трансформацией в модели (в рамках используемой инструментальной среды) – ИТ-компанией. При этом между разнопрофильными группами исполнителей проекта должны согласовываться содержание и форматы результатов аудита, равно как и целевые установки создаваемой модели.

В этой части риски по проекту могут быть связаны с тем, что одна из сторон – ИТ-компания или бизнес-консалтинговая компания – может «потянуть» одеяло на себя и попытаться без помощи другой постараться решить «не свои» задачи. Равно как и заказчик, исходя из экономии либо недостаточного понимания специфики реализации подобного рода проектов, может проигнорировать необходимость обязательного привлечения и бизнес-, и ИТ-компании и в результате выбрать только одного исполнителя.

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

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

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

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

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

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

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

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

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