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