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

♦ одни и те же данные хранятся в разных информационных системах;

♦ информационные системы, поддерживающие частично пересекающийся функционал, не являются взаимозаменяемыми по составу решаемых задач;

♦ при наличии избыточности в составе автоматизируемых функций существование большого количества «не покрываемых» автоматизацией значимых бизнес-функций;

♦ отсутствие достоверной информации о том, насколько активно и в каких бизнес-процессах используется АИС (либо отдельная ее подсистема);

♦ отсутствие достоверной информации по стоимостным и временным показателям задействования АИС (либо отдельной ее подсистеме, поддерживаемой автоматизированной функцией) в бизнес-процессах.

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

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

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

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

♦ временные и стоимостные показатели использования перспективной АИС (отдельных ее подсистем) в рамках бизнес-процесса предприятия.

С учетом вышеизложенного исходными данными для разработки процессно-ориентированной модели АИС может служить табл. 3.

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

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

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

Расчеты этих временных и стоимостных затрат по участию АИС в бизнес-процессе могут осуществляться на основе специализированных методик, а именно ТСО (Total cost of Ownership).

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

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

Построение функциональной модели

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

♦ отражение взаимосвязи со всеми компонентами модели, являющимися чувствительными к обрабатываемым бизнес-событиям (например, изменения в составе входных/выходных документов, составе используемых АИС, составе должностных лиц и т. д.) в рамках формирования «окружения» функции;

♦ порядок учета основных компонент модели (люди, системы) на временные и стоимостные затраты реализации бизнес-функции;

♦ отражение временных и стоимостных затрат на выполнение бизнес-функции;

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

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

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

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

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

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

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

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

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

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

Построение модели выходов (результатов)

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