Практика и проблематика моделирования бизнес-процессов
Шрифт:
Разработка прикладных приложений для работы с моделями
Одним из следующих важных этапов после определения проектных решений, касающихся составных компонент модели, является разработка прикладных приложений поддержки работы пользователя с моделями и связанных с ней общесистемных сервисов.
Общим требованием к «прикладной» функциональности является необходимость реализации принятых подходов по формализации, анализу и оптимизации бизнес-процессов. Подходы к формализации во многом базируются на стандартных средствах инструментальной среды и фиксируются в соглашении о моделировании.
Экспертные методы анализа и оптимизации основываются на визуальном изучении специалистами представленного в удобном графическом виде бизнес-процесса и проведении по своим методикам качественно-количественных оценок. Характерной особенностью экспертного подхода является сложность формализации знаний и опыта эксперта и соответственно их «отторжения» для обезличенного использования широким кругом пользователей, не имеющих столь высокой, как у эксперта, компетенции. Экспертные методы особенно важны, а в отдельных случаях являются единственно возможными при высокой новизне и соответственно неопределенности в решаемой оптимизационной задаче.
Существует расхожее утверждение, что зачастую у эксперта сложно или вообще невозможно получить объяснение по интуитивно полученным им оценкам. Поэтому при экспертном подходе необходимо выводы и рекомендации эксперта воспринимать как некоторую данность. При экспертном подходе прикладная функциональность модели в первую очередь ориентируется на обеспечение удобной для эксперта формы визуализации информации.
Расчетные, в том числе аналитические, методы предусматривают программную реализацию в виде готовых модулей различных алгоритмов качественной и количественной оценки модели бизнес-процессов и ее компонент. Значительная часть функциональных возможностей для численных расчетов временных и стоимостных затрат процессов реализуется в рамках стандартных возможностей инструментальной среды, а дополнительные специализированные методы расчета могут быть осуществлены на основе заказной разработки.
Следует отметить, что многие проектные решения, разработанные для функциональной модели, вполне могут быть применимы и для модели управления (процессной модели). Это касается в том числе задания состава атрибутов для описания объекта «процесс» и перечня значимых связей.
Не останавливаясь на подробном описании всех пользовательских приложений, которые стандартны в большинстве инструментальных средств моделирования, целесообразно указать следующие практически значимые функциональные возможности, которые должны быть представлены в системе «Модель бизнес-архитектуры» предприятия.
1. Интерактивный режим прохождения по модели бизнес-процесса с учетом заданных параметров входных условий и принятия бизнес-решений. Данный функционал необходим для выделения из всего множества спроектированных моделей процессов только той, которая требуется для рассмотрения и последующего анализа либо для протоколирования действий сотрудников в той или иной ситуации. Пользователь в диалоговом режиме определяет те значения из типового набора входных параметров, которые будут влиять на формирование специфичной под данный выбор итоговой модели процесса. В процессе обхода модели/моделей пользователь также должен иметь возможность произвести осознанный выбор альтернатив обхода в «точках принятия
2. Цветовое выделение «маршрута» на фоне общей модели и его сохранение. При прохождении по модели рекомендуется маркировать получаемый «уникальный» маршрут посредством цветового выделения объектов модели, чтобы визуально зафиксировать этот путь и затем иметь возможность заново пройти по нему.
3. Интерактивный режим навигации по сохраненной модели маршрута. Для целей углубленного анализа, экспертизы, контроля правильности принятия решений необходима организация интерактивной работы в режиме пошагового повторного обхода помеченной цветом модели/моделей.
4. Построение технологической карты процесса. Технологическая карта будет являться документальным подтверждением пройденного маршрута, построенного на основе заданных входных данных и принятых в процессе прохождения бизнес-решений. Она должна содержать состав входных данных, список итоговых операций, используемых и получаемых при выполнении этих операций документов (операционных, нормативно-справочных), бизнес-роли, возможные информационные системы и другие данные.
Пример:
5. Получение должностных инструкций. Под построением должностной инструкции понимается формирование отчета, в котором выбранной должности ставятся в соответствие определенные роли и составляется полный список всех функций, выполняемых должностным лицом безотносительно к какому-либо процессу, в котором оно (лицо) участвует в конкретный момент.
Пример:
6. Получение отчета по загрузке (доступности) ресурсов.
7. Анализ пропускной способности организационно-технологической архитектуры предприятия.
Общим концептуальным требованием к проектированию общесистемных сервисов («общесистемной» функциональности) является минимизация обязанности пользователя:
по «прониканию» внутрь общесистемной платформы модели и тем более ее корректировке;
по вниканию в общесистемные настройки;
по вниканию в разветвленный стандартный «некастомизированный» функционал в рамках поиска нужного приложения.
Поэтому общим направлением проектирования общесистемных сервисов является максимальный вынос всех пользовательских настроек – задание условий работы модели в интерфейсную часть. К числу пользовательских настроек, которые целесообразно вынести «наружу» в интерфейсную часть, следует отнести:
задание входных условий – бизнес-событий, которые должны инициализировать анализируемый бизнес-процесс, в рамках предварительно сформированного набора (меню) возможных параметров;