Текст книги "Практика и проблематика моделирования бизнес-процессов"

Анализ и оптимизация моделей

Задачи по анализу и оптимизации (включая методы их решения) группируются по двум основным направлениям – объектный подход и процессный подход.

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

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

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

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

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

«Глобальная» оптимизация решается на основе процессного подхода, а «локальная» – на основе объектного.

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

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

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

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

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

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

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

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

♦ механизмы задания входных условий и инициализации бизнес-процесса.

Типичным примером практически значимого отчета, получаемого на основе динамической модели средствами процессного анализа, являются:

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

♦ карта временной загрузки персонала под заданные входные условия;

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

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

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

Этапность создания модели

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

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

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

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

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

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

Поэтапная детализация каждой из компонент модели имеет своей целью:

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

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

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

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

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

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

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

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

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

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

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

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

Для описания организационной компоненты (персонала), задействуемой для участия в процессе, можно предложить следующую этапность детализации:

♦ указывается наименование подразделения/подразделений, задействуемого для выполнения подпроцесса/процедуры;

♦ указывается должностное лицо/лица, задействуемое для выполнения функции;

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

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

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

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

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

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

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

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

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

♦ разработка общих возможных сценариев протекания процессов;

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

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

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

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

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

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

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

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

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

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

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

♦ формирование перечня «вторичных» классификаторов, ориентированных на решение задач:

а) моделирования процессов;

б) специализированного анализа по задачам пользователей;

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

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

♦ правовые документы – нормативная и правовая база;

♦ операционные документы;

♦ операционные сведения (данные).

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

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

1) актуализация и обеспечение непротиворечивости и полноты нормативной правовой базы;

2) устранение избыточности в операционных документах;

3) устранение избыточности в операционных данных и существенное сокращение операций по идентификации и проверке их достоверности.

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

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

♦ в рамках проектирования структуры для объекта «нормативный правовой» документ предусмотреть состав атрибутов и связей, которые позволяют:

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

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

– отразить связь с другими правовыми документами.

Благодаря такой форме описания правовой базы появляется возможность точно ответить на вопросы:

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

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

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

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

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

♦ какие правовые акты устарели и в реальности не используются и т. д.

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

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

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

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

♦ инвентаризация всех операционных данных (сведений), задействуемых в операционном процессе;

♦ установление источников по каждому данному (сведению) без категорирования источников на первичные и вторичные;

♦ категорирование источников по каждому данному (сведению);

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

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

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

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

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

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

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

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