Как проектировать архитектуру модели бизнес-процессов организации: методические рекомендации и подходы по разработке 3 страница

♦ тактическую, определяющую результаты операционной деятельности;

♦ стратегическую, определяющую обобщенные цели и показатели.

В рамках проектирования общей модели результатов необходимо обеспечить взаимосвязь всех ее составляющих:

♦ целевых установок различного уровня;

♦ выходных результатов процессов;

♦ критериев оценки качества бизнес-процесса.

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

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

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

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

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

♦ какова структура выходного результата, то есть какой состав промежуточных результатов он включает;

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

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

♦ шаблон;

♦ новый документ;

♦ изменен (вариант: в разработке);

♦ согласован (вариант: завизирован);

♦ утвержден;

♦ зарегистрирован;

♦ передан в архив.

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

Например: при работе с договором у него могут быть дополнительные статусы, такие как «частично оплачен», «оплачен», при работе с платежными документами через систему Интернет-клиент возможно использование дополнительных статусов, таких как «отправлен в банк», «получен банком», «отказан банком» и т. п.

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

♦ отношения вхождения (включения) между объектами целеполагания;

♦ процедуры (алгоритмы) оценки их достижения;

♦ качественно-количественные показатели;

♦ основные параметры, влияющие на значение качественно-количественных показателей;

♦ связи с бизнес-процессами на согласованном уровне.

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

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

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

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

Построение модели управления

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

В ходе проектирования должна быть обеспечена возможность устранения фрагментарности отдельных «самостоятельных» бизнес-процессов (подпроцессов) за счет:

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

♦ определения интерфейсов для взаимосвязи;

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

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

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

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

♦ наглядном отображении на общей модели соответствующих самостоятельных фрагментов и «точек» входа в основные модели;

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

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

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

Разумным дополнением базового классификатора бизнес-процессов могут быть следующие поддерживаемые моделью управления (и соответствующими классификаторами) группировки бизнес-процессов:

♦ по основным сценариям;

♦ по основным этапам прохождения «стержневых» бизнес-процессов;

♦ по основным типам входных условий (бизнес-событий).

Сценарий – это один из возможных вариантов реализации бизнес-процесса в зависимости от определенных условий, причем в большей степени связанных с возможными объектами выполнения. Учитывая высокоуровневый характер систематизации группировки (систематизации) бизнес-процессов/подпроцессов/процедур по этапам и входным условиям, данное мероприятие должно осуществляться в основном на основе экспертных рекомендаций.

Разработка прикладных приложений для работы с моделями

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

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

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

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

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

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

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

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

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

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

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

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

6. Получение отчета по загрузке (доступности) ресурсов.

7. Анализ пропускной способности организационно-технологической архитектуры предприятия.

Общим концептуальным требованием к проектированию общесистемных сервисов («общесистемной» функциональности) является минимизация обязанности пользователя:

♦ по «прониканию» внутрь общесистемной платформы модели и тем более ее корректировке;

♦ по вниканию в общесистемные настройки;

♦ по вниканию в разветвленный стандартный «некастомизированный» функционал в рамках поиска нужного приложения.

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

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

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

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

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

♦ возможность многопользовательской работы;

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

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

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

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

♦ входные события для модели (внешняя среда);

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

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

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

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

Разработка Соглашения о моделировании

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

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

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

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

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

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

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

При создании иерархии папок возможно использование нескольких критериев:

♦ согласно этапам проведения проекта;

♦ согласно процессно-ориентированной структуре;

♦ согласно функциональной структуре компании;

♦ согласно описываемым предметным областям;

♦ комбинации указанных выше критериев.

В данном разделе указываются выбранные критерии построения и непосредственно общая структура папок.

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

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

– каждый тип объекта несет свое определенное значение в методологии и имеет специфические характеристики, определяющие конкретный объект данного типа;

– каждый тип объекта может использоваться в одном или нескольких типах моделей;

– каждый тип объекта может быть представлен одним или несколькими символами.

Также необходимо указать, на какие типы моделей могут быть детализированы те или иные типы объектов.

♦ Спецификация используемых типов связей. Типы связей определяют возможные взаимоотношения между объектами. В данном разделе необходимо указать, какие типы связей и между какими объектами будут использоваться в проекте.

Данный выбор типов связей осуществляется на основе поставленных целей моделирования и знаний таких основ, как:

– один и тот же тип связей между типами объектов может присутствовать в нескольких типах моделей;

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

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

Выбор типов атрибутов основывается на знании того, что:

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

– есть набор атрибутов, существующий у каждого типа модели, объекта или связи, например: Имя, Полное имя, Описание, Автор и др.;

– другие атрибуты могут существовать только для определенных типов модели, объекта или связи, например «Количество сотрудников» для объекта Подразделение.

♦ Определение соглашений по присвоению имен. В рамках проекта объекты зачастую идентифицируются при помощи их имен. Строгие правила присвоения имен объектам повышают целостность проекта, увеличивают удобство чтения моделей, облегчают поиск объектов в базе. Правила именования должны стать стандартом проекта и быть доведены до сведения каждого участника. Правила именования должны быть определены для каждого используемого типа объектов. Различают синтаксический и семантический аспекты задания правил именования. Пример синтаксического аспекта наименования функции: «Проверка документов» – имя должно состоять из двух обязательных частей – отглагольного существительного, описывающего выполняемую функцию, и существительного, показывающего объект, над которым она выполняется.

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

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

– расположение последовательности событий и функций сверху вниз, то есть входящие стрелки в функцию должны быть расположены сверху, а исходящие стрелки из функции – снизу;

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

– оргединицы и роли отображаются справа от функции.

Для повышения информативности модели определяется набор атрибутов объектов, значения которых выносятся непосредственно на графику моделей.

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

Кроме того, определяется ориентировочное количество объектов, которые должна содержать диаграмма, для того чтобы она легко читалась при ее распечатке на листе формата А4 или A3. Также определяется внешний вид элементов используемой нотации (цвет, форма, толщина линий, размеры объекта, формат и наклон текста).

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

1) адекватность модели – соответствие модели моделируемому объекту или процессу. Модель адекватна, если все ее элементы (объекты и связи) имеют прообраз в моделируемой предметной области. Если в модели отображены не все нужные объекты, а «лишних» элементов нет, то считаем, что модель адекватна, но не полна;

2) корректность модели – соответствие исполнения модели бизнес-процесса установленным для конкретной методологии или нотации семантическим и синтаксическим правилам. Модель корректна, если создана в соответствии с правилами оформления, установленными методологией моделирования и другими требованиями;

3) полнота модели – присутствие в модели всех необходимых объектов и связей предметной области (выделенного бизнес-процесса). Модель полна, если она содержит все допустимые заданной методологией элементы предметной области, которые должны быть отображены для достижения целей моделирования и т. д.

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

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

Основные этапы по проектированию

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

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

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

а) классификация и кодирование;

б) детализация;

в) взаимосвязь с входными условиями.

3. Проектирование описательной процессной модели (модели управления).

4. Проектирование форм отчетов.

5. Проектирование интерактивной модели.

6. Проектирование имитационной модели.

7. Тестирование разработанной модели

Проектирование моделей «как должно быть» и GAP-анализ

Общая методология построения бизнес-моделей требует рассмотрения трех промежутков времени:

♦ текущего (модели «как есть»);

♦ ближайшего будущего на среднесрочную перспективу (модели «как должно быть» – вариант 1);

♦ отдаленного будущего на долгосрочную перспективу (модели «как должно быть» – вариант 2).

Под среднесрочной перспективой компания Gartner рекомендует рассматривать временной горизонт от 9 до 18 месяцев, а под долгосрочной перспективой – в 30 месяцев. Такие сроки обусловлены влиянием глобального ускорения бизнес-процессов и постоянного развития информационных технологий.