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

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

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

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

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

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

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

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

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

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

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

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

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

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