¦ определение оптимальной для задачи моделирования бизнес-процесса системы классификации и кодирования для каждой из компонент модели.
Вопрос соответствия (возможности сопряжения) систем классификации и кодирования является крайне важным для возможностей активного использования, снижения затрат на поддержку и развитие разработанной модели бизнес-архитектуры. Природа возникновения данной проблемы связана с тем, что в большинстве случаев система классификации и кодирования, ранее созданная в организации, не ориентировалась на процессную поддержку деятельности организации. Как правило, эта система создавалась спонтанно под частные задачи, которые не связаны друг с другом и с процессом в целом. Ситуация усложняется еще и тем, что на основе подобных внутрикорпоративных систем реализованы многие информационные системы, разработана документация и т. д.
Исходя из изложенного, становится понятным, что в ранее созданную систему классификации и кодирования вложены значительные инвестиции, с которыми безусловно необходимо считаться. Поэтому при создании аналогичной системы для модели бизнес-архитектуры необходимо предусмотреть соответствующие модули сопряжения, которые обеспечивают однозначную идентификацию по-разному классифицируемых объектов и таким образом исключают конфликтность модели и действующих систем. Использование модулей сопряжения создает методологическую и технологическую базу для поэтапной «безболезненной» замены в перспективе устаревшей системы классификации и кодирования.
Проблематика оптимальности выбора системы классификации и кодирования для основных компонент модели вытекает из изначальной конфликтности процессного и объектного подхода. То, что удобно для процесса, не всегда удобно для объекта, и наоборот. Кроме того, даже в рамках объектного подхода каждая из заинтересованных сторон хочет видеть в своем («монопольном») ракурсе тот или иной объект. При этом каждой точке зрения, по сути дела, должна соответствовать «удобная» система классификации и кодирования.
Выход из подобных сложных ситуаций, связанных с разработкой систем классификации и кодирования основных компонент модели, состоит в выполнении трех ключевых моментов:
¦ формирование «первичного» классификатора, отражающего смысловую природу объекта, не связанную с задачей процессного отображения бизнеса;
¦ формирование перечня «вторичных» классификаторов, ориентированных на решение задач:
а) моделирования процессов;
б) специализированного анализа по задачам пользователей;
¦ введение ряда специализированных атрибутов и связей, через которые есть возможность путем генерации отчетов реализовать различные «пользовательские» классификаторы.
Построение информационной модели
Одной из первых компонент модели бизнес-архитектуры организации, которая должна быть проанализирована, является информационная составляющая. Можно выделить следующие основные компоненты информационной модели:
¦ правовые документы – нормативная и правовая база;
¦ операционные документы;
¦ операционные сведения (данные).
Значимость данной компоненты трудно переоценить. Именно в ней содержится документированный порядок основных регламентов деятельности организации. В случаях если это не так, исполнитель совместно с заказчиком должен в обязательном порядке до начала процесса моделирования восполнить данный пробел и в традиционной форме (приказ, инструкция и т. д.) задокументировать реально действующий регламент на предприятии.
При проектировании информационной модели необходимо учитывать целевые задачи, которые должны быть достигнуты в рамках оптимизации деятельности организации. В рамках данной модели наиболее часто встречаемыми являются такие проблемные вопросы, как:
1) актуализация и обеспечение непротиворечивости и полноты нормативной правовой базы;
2) устранение избыточности в операционных документах;
3) устранение избыточности в операционных данных и существенное сокращение операций по идентификации и проверке их достоверности.
Применительно к задаче улучшения качества нормативной правовой базы необходимо обеспечить:
¦ построение классификаторов и кодификаторов для нормативных правовых документов, ориентированных на решение задачи «сквозной» регламентации всего бизнес-процесса;
¦ в рамках проектирования структуры для объекта «нормативный правовой» документ предусмотреть состав атрибутов и связей, которые позволяют:
– отразить точки использования в бизнес-процессе каждого документа (в том числе на уровне отдельных его разделов);
– отразить связь документа с составом объектов, которые подпадают под его регламентацию (например, операционные документы, сведения, информационные системы и т. д.);
– отразить связь с другими правовыми документами.
Благодаря такой форме описания правовой базы появляется возможность точно ответить на вопросы:
¦ насколько активно и где используется конкретный документ (либо отдельные его положения);
¦ как должны учитываться изменения при редакции, отмене конкретного документа, с точки зрения возможной передачи под юрисдикцию другим нормативным документам ранее регламентируемых им объектов;
¦ как правовые документы опосредованно связаны друг с другом через регламентируемые процессы;
¦ какие процессно-значимые моменты должны быть учтены при разработке нормативных правовых документов;
¦ есть ли логические противоречия в регламентируемом порядке деятельности организации (в первую очередь действий должностных лиц);
¦ какие правовые акты устарели и в реальности не используются и т. д.
Кроме того, такая формализация представления нормативной правовой базы позволяет осуществить упорядочивание и повышение качества процесса развития и поддержки нормативной правовой базы за счет четкого отслеживания «поля» действия каждого нормативного правового документа и его взаимосвязи с другими правовыми документами.
Проблема устранения избыточности и обеспечения непротиворечивости в используемых операционных документах и сведений (данных) является одним из основных резервов оптимизации бизнес-процессов. Ее решение связано с реализацией принципа обеспечения единого источника информации данных (сведений), которые в дальнейшем используются либо в документах, либо в информационных системах. При этом необходимо отметить, что элементарной единицей операционного информационного потока могут быть либо конкретные данные (сведения), либо документ.
В контексте данного подхода тот или иной операционный документ может рассматриваться либо как первичный источник определенных сведений, либо как вторичный источник, то есть получатель (носитель) данных, поступивших из первичного источника (источников), например первичных документов или информационных (технических) систем, либо как самостоятельная элементарная единица операционного информационного потока.
Поэтому при проектировании компоненты информационной модели, касающейся операционных информационных потоков, необходимо предусмотреть обязательное выполнение следующих шагов:
¦ инвентаризация всех операционных данных (сведений), задействуемых в операционном процессе;
¦ установление источников по каждому данному (сведению) без категорирования источников на первичные и вторичные;
¦ категорирование источников по каждому данному (сведению);
¦ создание отдельных категорий объектов в информационной модели – источник,
