Проектные решения по модели должны охватывать не только выходные (производственные) результаты, но и целевые (стратегические) установки организации, равно как и критерии оценки их достижения. В этом смысле архитектура модели должна предусматривать две компоненты:
♦ тактическую, определяющую результаты операционной деятельности;
♦ стратегическую, определяющую обобщенные цели и показатели.
В рамках проектирования общей модели результатов необходимо обеспечить взаимосвязь всех ее составляющих:
♦ целевых установок различного уровня;
♦ выходных результатов процессов;
♦ критериев оценки качества бизнес-процесса.
Применительно к проектированию тактической компоненты модели можно высказать следующие рекомендации по проектированию. По своей сути бизнес-процесс направлен на получение определенных выходных результатов. Все оценки качества бизнес-процесса, равно как и планируемые изменения по улучшению его характеристик, должны так или иначе проецироваться на выходные результаты.
По этой причине нужно четко установить и формализовать то, какое – прямое или опосредованное – влияние оказывают процессы, подпроцессы и процедуры на выходные результаты соответствующего уровня. Для этого в модели должно быть предусмотрено формирование определенного окружения и атрибутов выходных результатов, в рамках которых может быть установлено:
♦ в рамках каких процессов, подпроцессов и процедур обеспечивается получение конкретного выходного результата;
♦ какие ресурсы (организационные, информационные и технологические) необходимы для их получения;
♦ какова обобщенная временная и стоимостная оценка получения выходного результата;
♦ какова структура выходного результата, то есть какой состав промежуточных результатов он включает;
♦ частью какого более высокого уровня выходного результата является моделируемый промежуточный результат.
Применительно к выходным документам целесообразно использовать следующее категорирование по мере движения по процессной цепочке:
♦ шаблон;
♦ новый документ;
♦ изменен (вариант: в разработке);
♦ согласован (вариант: завизирован);
♦ утвержден;
♦ зарегистрирован;
♦ передан в архив.
Каждый статус указывает на текущее состояние документа в бизнес-процессе. Смена статуса документа происходит при выполнении определенных действий с документом и характеризует прохождение этим документом определенного этапа документооборота. В любом случае, конкретный список статусов выходных документов и их смысл определяются при решении конкретной задачи.
Например: при работе с договором у него могут быть дополнительные статусы, такие как «частично оплачен», «оплачен», при работе с платежными документами через систему Интернет-клиент возможно использование дополнительных статусов, таких как «отправлен в банк», «получен банком», «отказан банком» и т. п.
Применительно к стратегической компоненте модели выходных результатов проектные решения должны быть направлены на отражение иерархии объектов целеполагания организации. Каждый из объектов должен иметь перечень атрибутов и соответствующее окружение, при которых могут быть определены:
♦ отношения вхождения (включения) между объектами целеполагания;
♦ процедуры (алгоритмы) оценки их достижения;
♦ качественно-количественные показатели;
♦ основные параметры, влияющие на значение качественно-количественных показателей;
♦ связи с бизнес-процессами на согласованном уровне.
Учитывая многопользовательский характер разрабатываемой модели бизнес-архитектуры, при формировании перечня объектов целеполагания необходимо учитывать и отражать интересы различных участников: производственников, правовиков, финансистов, кадровиков, информационщиков и т. д.
В условиях большого количества объектов целеполагания, заинтересованных лиц, производящих оценку их достижения, следует ожидать большого количества методических подходов и соответственно программных решений по оценке эффективности. При этом в современных условиях динамичного изменения внешней среды функционирования организации следует предполагать аналогичную высокую динамику в развитии методики оценки эффективности бизнес-процессов. Для этого целесообразно предусмотреть в рамках проектных решений создание специальной библиотеки процедур по расчету качественно-количественных показателей достижения целей организаций.
Необходимо себе отдавать отчет, что на этом этапе целеполагания по сути дела закладывается масштабность модели и соответственно затраты на ее создание, равно как определяются базовые требования к функционалу, который должен быть ей реализован.
Также необходимо осознавать, что методологические и проектные ошибки в определении взаимосвязи процессных и объектных компонент бизнес-модели с выходными результатами могут свести на нет качественную работу по всем предыдущим этапам, поскольку будут предоставлять необъективную информацию в отношении текущих и прогнозных оценок по состоянию и улучшению бизнес-процесса.
Построение модели управления
В рамках проектирования данной компоненты необходимо обеспечить эффективную взаимосвязь всех «автономных» составляющих модели бизнес-архитектуры в единый процесс, который в дальнейшем может быть соответствующим образом оценен, «обсчитан» и оптимизирован.
В ходе проектирования должна быть обеспечена возможность устранения фрагментарности отдельных «самостоятельных» бизнес-процессов (подпроцессов) за счет:
♦ использования общей базы составных моделей (информационной, организационной, функциональной);
♦ определения интерфейсов для взаимосвязи;
♦ определения механизма учета «вклада» в общие интегральные показатели эффективности бизнес-процесса.
Особенно решение данной задачи актуально при формализации качественно-количественного взаимоотношения основных и обеспечивающих процессов. Модель должна давать аргументированные ответы на вопросы, каковы роль и место конкретного бизнес-процесса в рамках целевого функционирования предприятия, какой вклад вносится подпроцессом в достижение целевых показателей (задач) организации, то есть решение «глобальной» задачи оптимизации.
При этом необходимо отметить сохранение актуальности проблематики «локальной» оптимизации, когда рассматриваемый отдельный процесс, подпроцесс (процедура) являются самостоятельной целью оптимизации. Такая ситуация возникает, когда при зафиксированных требованиях к основному бизнес-процессу (в рамках фиксированных интегральных требований к оптимальной архитектуре) необходимо понизить иерархический уровень оптимизации и провести его на уровне (внутри) составных компонент основного процесса.
Ответы на вопросы о роли и месте претендующих на самостоятельное значение подпроцессов и процедур в общем бизнес-процессе должны носить как качественный, так и количественный характер. В рамках создаваемых проектных решений по процессной модели качественный характер оценок должен проявляться в:
♦ наглядном отображении на общей модели соответствующих самостоятельных фрагментов и «точек» входа в основные модели;
♦ создании специализированных атрибутов и технологий отображения, отражающих окружение связей процесса/подпроцесса/процедуры с другими процессами/подпроцессами/процедурами.
Проектные решения по получению количественных оценок процесса/ подпроцесса/процедуры во многом являются аналогичными тем решениям, которые предлагались для оценки временных и стоимостных затрат для бизнес-функции.
Несмотря на то что моделирование бизнес-архитектуры предприятия происходит по определенным критериям систематизации бизнес-процессов, реализуемых в рамках деятельности предприятия, получение какой-либо одной жесткой структуры (иерархической, сетевой, графовой и т. д.) является не всегда достижимым и целесообразным. Разумеется, это не исключает поиска и реализации оптимального классификатора и кодификатора для бизнес-процессов, который может снять основной пласт проблем, связанных с отсутствием либо плохой оптимизацией процессов.
Разумным дополнением базового классификатора бизнес-процессов могут быть следующие поддерживаемые моделью управления (и соответствующими классификаторами) группировки бизнес-процессов:
♦ по основным сценариям;
♦ по основным этапам прохождения «стержневых» бизнес-процессов;
♦ по основным типам входных условий (бизнес-событий).
