Существует достаточный разброс мнений в понимании и определении бизнес-архитектуры и бизнес-модели. Одна из трактовок предусматривает определение бизнес-архитектуры как области, которая определяется высшими руководителями, отвечающими за основные функции (бизнес) организации [10]. Такая трактовка, как правило, включает в себя утверждения по поводу миссии и целей организации, критические факторы успеха, бизнес-стратегии, описания функций, а также структуры и процессы, необходимые для реализации функций.

Ключом к построению хорошей бизнес-архитектуры является определение бизнес-процессов, их функций и характеристик. Это становится основой для построения архитектуры ИТ-приложений, которые обеспечивают автоматизированную поддержку этих процессов. Хотелось бы в связи с этим привести следующую цитату из книги Unleashing the Killer Арр [11]: «Вы тогда достигаете цели, когда становится невозможно определить, где заканчиваются бизнес-аспекты и где начинаются технологии».

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

♦ используемые данные (что?);

♦ процессы и функции (как?);

♦ места выполнения этих процессов (где?);

♦ организации, персоналии-участники, системы (кто?);

♦ управляющие события (когда?);

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

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

1) бизнес-процессы / цели и стратегия построения бизнеса;

2) организационная компонента / организационное окружение;

3) информация / информационное окружение;

4) приложения / обеспечивающее окружение.

В данном случае авторы не претендуют на полноту и «стандартизацию» предлагаемого варианта описания бизнес-архитектуры. Более важным является отображение «интеграционных» аспектов.

Проблемы и подходы, связанные с проектированием «окружения» бизнес-процессов, отображены в главе 3 книги.

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

Можно привести следующие определения по целевым постановкам задач для бизнес-архитектуры: «Если архитектура ИТ-предприятия описывает то, как компоненты ИТ объединяются вместе для достижения нужного результата, то точно так же бизнес-архитектура описывает, как элементы бизнеса соединены вместе» [12].

Бизнес-архитектура включает в себя, как правило, следующие аспекты:

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

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

♦ показатели результативности. Этот аспект состоит в определении ключевых показателей результативности (КПР) работы организации, их текущих и желаемых уровней. Модель КПР используется как средство мониторинга исполнения бизнес-процессов. Для определения показателей результативности работы организации применяются различные методики, например широкую популярность завоевала методика Роберта Каплана и Дейвида Нортона «Balanced Score Card (BSC)». BSC представляет собой систему, основанную на причинно-следственных связях между стратегическими целями, отражающими их параметрами и факторами получения планируемых результатов. Она рассматривает четыре проекции: финансовую, взаимоотношения с потребителями, операционной эффективности и человеческого потенциала организации, цели и задачи которых взаимосвязаны и отражены финансовыми и нефинансовыми показателями.

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

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

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

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

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

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

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

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

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

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

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

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

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

Определение по ISO-15704 Моделирование – абстрактное представление реальности в какой-либо форме (например, в математической, физической, символической, графической или дескриптивной), предназначенное для представления определенных аспектов этой реальности и позволяющее отвечать на рассматриваемые вопросы.

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

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

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

♦ описательные – предназначенные только для восприятия человеком, или исполняемые – позволяющие исследовать их поведение и использовать полученные результаты для выводов об исходном объекте.

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

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

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

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

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

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

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

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

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

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

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

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

Этот прием используется при определении границ области моделирования и при расстановке приоритетов внутри нее, он позволяет сократить объем и продолжительность моделирования, однако может негативно сказаться на адекватности модели.

В качестве общих элементов определений, связанных с архитектурой, можно использовать следующий перечень [7]:

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

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

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

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

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

♦ архитектура содержит объяснения и обоснования по поводу своих компонент и структуры;

♦ определения архитектуры не содержат описания самих компонент.

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

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

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

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

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

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

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

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

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

Процессный анализ предполагает исследование одного или множества бизнес-процессов организации в целом.

Варианты определения процесса следующие.

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

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

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

♦ Процесс – это взаимонезависимый компонент производственной системы, преобразующий вход в один или несколько выходов в соответствии с предварительно установленными правилами.

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

Процессный подход к моделированию позволяет:

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

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

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

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

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

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

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

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

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

Для задания процесса необходимо определить:

♦ название (определение) процесса;

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

♦ участников процесса;

♦ ответственное лицо – владельца процесса;

♦ границы процесса;

♦ входные и выходные потоки, а также их поставщиков (или потребителей);

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

♦ определяющую цель (цели) процесса;

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

♦ возможные риски и влияния процесса на субъекты процесса.

Входные потоки – материалы, услуги и/или информация, преобразуемые процессом для создания выходных потоков.

Выходные потоки – результат преобразования входных потоков.

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

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

Исходя из вышеизложенного, выделяются основные составляющие модели бизнес-процесса, участвующие в ее построении:

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

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

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

♦ участники процесса (трудовые ресурсы);

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

Для анализа процессов рекомендуется использовать опыт консультантов, эталонные и референтные модели, «check-листы» и другие статистические методы, применяемые в менеджменте качества. Аспекты анализа процесса:

♦ анализ топологии процесса;

♦ анализ характеристик процесса;

♦ анализ ошибок процесса;

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

♦ анализ рисков процесса;

♦ анализ ресурсного окружения процесса;

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

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

Этапы анализа характеристик:

1) определение основных характеристик (показателей) процесса;

2) определение метрик характеристик для их оценки;

3) мониторинг метрик характеристик процесса.

Основными характеристиками процесса являются следующие показатели:

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

♦ определенность – отражает степень, с которой реальный процесс соответствует описанию;

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

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

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

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

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

Примеры метрик характеристик процесса:

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

♦ степень автоматизации по количеству функций (количество функций с возможностью автоматизации / общее количество функций процесса);

♦ степень автоматизации по времени (суммарное время автоматизированных работ / суммарное время выполнения всех работ);

♦ отношение суммарного времени выполнения функций процесса к суммарному времени ожидания;

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

Этапы анализа ошибок процесса:

1) классификация возможных ошибок процесса;

2) описание ошибок процесса;

3) выявление ошибок в процессе.

Возможные ошибки, которые могут возникать при моделировании бизнес-процессов:

♦ незавершенность. Наличие пробелов в описании процесса, например отсутствие подпроцесса, процедуры или информационного ресурса;

♦ несоответствие. Неадекватное использование информационных ресурсов в различных частях процесса. Это приводит к искаженному восприятию информации или к неясности указаний;

♦ иерархическая несовместимость. Несовместимость процесса с подпроцессами, его составляющими;

♦ «наследственная» несовместимость. Наличие конфликта между основными и последующими процессами.

Динамика процессов исследуется с помощью динамической (имитационной) модели.

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

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

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

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

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

♦ значимостью для деятельности организации в целом;

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

♦ сложной системой технической поддержки.

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

Этапы анализа рисков процесса:

1) структуризация рисков;

2) описание рисков и процессов, их предотвращающих;

3) определение рисков в бизнес-процессах.

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

♦ людские – участники процесса (кто выполняет);

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

♦ материальные – материалы, комплектующие, энергетические ресурсы (с использованием чего выполняет);

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

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

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

Например, операционное окружение таможенных процессов включает:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

♦ динамическое состояние ресурса – текущая доступность и текущий остаток.

В конечном итоге получаемая информация должна позволить сделать выводы и подготовить предложения по:

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

♦ изменению структуры и характеристик ресурсов;

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

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

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

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

♦ состава должностей;

♦ бизнес-роли;

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

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

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

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

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

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

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

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

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

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

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

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

По данным Министерства экономического развития и торговли России, опубликованным в августе 2004 года, объем всего рынка ИТ, включая государственный, корпоративный и частный секторы, в 2003 году составил $6–7 млрд и вырос по сравнению с предыдущим годом на 23 %, а к 2007 году объем рынка ИТ составит $11,5 млрд. Близкие оценки давали аналитики CNews и IDC. Наибольшие объемы затрат на ИТ в России сейчас сосредоточены в правительственном, транспортном и добывающем секторах.

А общемировой рост расходов на ИТ в 2004–2008 годах, по оценкам IDC, будет находиться в пределах от 5,2 % до 6,6 %, опережая рост валового национального продукта.

Достаточно репрезентативным является зависимость капитальных расходов на ИТ, отнесенных к общим капитальным расходам компании. Эта зависимость имеет явную тенденцию к увеличению, так что прогнозируемая доля расходов на ИТ достигнет к 2015 году почти половины совокупных капитальных затрат, как показано на рис. 5.

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

Наиболее часто встречаемая проблематика использования АИС, которая значима для последующей оптимизации бизнес-процесса и которая должна отображаться в рамках выбранных проектных решений по архитектуре организационной модели, связана со следующими обстоятельствами:

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

♦ одни и те же данные хранятся в разных информационных системах;

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

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

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

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

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

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

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

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

♦ временные и стоимостные показатели использования перспективной АИС (отдельных ее подсистем) в рамках бизнес-процесса предприятия.

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

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

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

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

Расчеты этих временных и стоимостных затрат по участию АИС в бизнес-процессе могут осуществляться на основе специализированных методик, а именно ТСО (Total cost of Ownership).

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

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

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

♦ отражение взаимосвязи со всеми компонентами модели, являющимися чувствительными к обрабатываемым бизнес-событиям (например, изменения в составе входных/выходных документов, составе используемых АИС, составе должностных лиц и т. д.) в рамках формирования «окружения» функции;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

♦ шаблон;

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

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

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

♦ утвержден;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пример:

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

Пример:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Gartner рекомендует 15 % усилий и внимания уделять существующей сегодня в организации бизнес-архитектуре, 70 % – бизнес-архитектуре, которую предполагается реализовать в ближайшем будущем, и еще 15 % усилий – бизнес-архитектуре, как она видится в отдаленной перспективе.

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

Если говорить про распределение усилий на различных фазах построения бизнес-архитектуры, то 40 % всей усилий должны занимать управление и надзор над процессом создания, порядка 30 % усилий – собственно разработка моделей, решений и их документирование. И примерно по 15 % усилий рекомендуется сосредоточить на обеспечении восприятия предложенных решений со стороны руководства и бизнес-подразделений и на проведении оценки и сравнительного анализа с лучшими мировыми практиками или доступными аналогами.

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

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

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

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

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

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

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

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

На этапе Gap-анализа осуществляются:

♦ идентификация и категорирование несоответствий между текущим и целевым состояниями;

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

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

Выявляемые в рамках Gap-анализа несоответствия могут быть связаны с вопросами культуры организации, структурными проблемами, функциональными или же процедурными вопросами [14].

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

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

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

В обобщенном виде процесс Gap-анализа предусматривает выполнение следующих шагов [4].

1. Идентификация различий между существующей и целевой бизнес-архитектурами.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

♦ проведение финансового, стоимостного, временного и других видов анализа «маршрута»;

♦ отслеживание последовательности этапов прохождения маршрута и т. д.

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

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

♦ стандартные процедуры финансового, стоимостного, временного и других видов анализа «маршрута».

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

♦ «выделить» из среды ARIS уникальный маршрут;

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

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

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

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

♦ цветовое выделение «маршрута» на фоне общей модели;

♦ сохранение маршрута модели в виде отдельной модели, связанной с общей базой модели бизнес-архитектуры;

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

Группа прикладных функций аналитической обработки «маршрута»:

♦ технологическая карта;

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

Группа прикладных функций выделения «маршрута»:

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

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

На модели верхнего уровня формируется функция, с ней ассоциируется набор подмоделей, реализующих специфический функционал (рис. 10).

Рис. 10

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

Например: на модели (рис. 11) с функцией высокого уровня, выделенной черными квадратами, связан список подмоделей типа eEPC, каждая из которых реализует специфический функционал, определенный типом транспорта. Атрибут Identifier каждой подмодели имеет свое значение, разное в зависимости от, например, типа транспорта. Перед началом обхода модели высокого уровня при помощи скрипта последний формирует диалоговое окно, из которого пользователь может выбрать нужное значение, например вида транспорта, в зависимости от анализируемой версии бизнес-процесса. Выбранное значение запоминается в переменной. Значение переменной используется при выборе из списка ассоциированных с функцией подмоделей.

Рис. 11

В приложении 1 приведен пример кода функции seltrans (выбор вида транспорта).

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

В приложении 1 приведен пример кода функции getassmodpar (получить ассоциированную с текущей функцией подмодель с нужным видом транспорта).

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

При написании и отладке скриптов применялся встроенный в среду ARIS интерпретатор языка программирования Sax Basic, окно экранного редактора которого приведено на рис. 12.

Рис. 12

Для доступа к специфическим средствам языка – компонентам объектовой среды ARIS – применялись стандартные библиотеки ATARep.dll и ATDRepDb.dll среды ARIS (рис. 13).

Рис. 13

При помощи диалогового окна «ActiveX Automation Members» можно получить доступ как к средствам языка Sax Basic, так и к типам данных – объектам среды ARIS, информацию обо всех их свойствах (Properties) и методах, реализованных через процедуры (Sub) и функции (Function), о типе возвращаемого значения, количестве и типах параметров методов (рис. 14).

Рис. 14

При необходимости можно подключить другие библиотеки из опубликованного в системном реестре набора dll-ресурсов. Доступ к этой возможности предоставляется через опцию Tools/Referenses… окна экранного редактора среды ARIS (рис. 15).

Рис. 15

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

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

♦ произвести фиксацию «следа», «тропы», по которой происходил обход моделей;

♦ получить возможность интерактивного режима принятия бизнес-решений;

♦ получить подробный протокол обхода;

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

Список сервисного функционала может быть значительно расширен в зависимости от бизнес-потребностей заказчика и возможностей разработчика.

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

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

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

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

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

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

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

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

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

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

Рис. 16

Если в процессе обхода модели встречается правило, то сначала анализируется его тип.

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

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

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

Дисциплина доступа к стеку: последним вошел – первым вышел (LIFO).

Стек может быть организован несколькими способами.

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

Если надо хранить один параметр для каждого объекта, может подойти или одномерный массив вариантного типа, или список. Список в этом случае более предпочтителен.

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

На рис. 17 приведен пример выбора альтернативной ветви процесса для правила XOR.

Рис. 17

В приложении 1 приведен пример кода, реализующего этот функционал. Это процедура XOROpen. Строки диалогового окна формируются при помощи функции Getname(), код которой также приведен в приложении 1.

В стандартном режиме ARIS позволяет просматривать модели любой группы, свойства модели и любого из ее объектов, менять свойства модели и любого из ее объектов. Журнал посещений моделей не ведется, поэтому запомнить путь, повторить просмотр, пометить как-то просмотренные модели и т. п. невозможно.

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

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

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

На рис. 18 приведен пример использования описанного скрипта, под ним – список моделей, пройденных скриптом за последний сеанс работы.

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

Подобное копирование можно производить или вручную, или при помощи механизма Variants. Однако если модели копируются как Copies occunrence, то любые изменения объектов этих новых моделей автоматически приводят к изменениям occurences этих объектов на моделях-источниках, что далеко не всегда то, что нужно пользователю.

Как правило, модели копируются пользователями как Copies definitions, но в этом случае пропадают все связи объектов этих моделей и на новых моделях все связи приходится восстанавливать вручную, что очень затратно по времени и чревато ошибками.

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

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

В итоге получалось нечто, похожее на приведенное на рис. 19.

Стандартная конфигурация ARIS предоставляет в распоряжение пользователя очень богатый и функционально полный набор специализированных опций экономического анализа. Это ABC – Activity Based Cost Calculation, Balanced Scoreboard и Simulation. Правда, надо признать, что ожидаемый эффект достигается лишь при условии, что исследуемые модели соответствующим образом подготовлены к анализу. Имеются в виду такие действия, как:

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

♦ удовлетворение условиям по количеству уровней вложенности моделей;

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

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

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

Был создан скрипт, при помощи которого на базе многоуровневой модели создавались наборы «плоских» моделей.

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

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

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

♦ решения по визуализации и настройкам;

♦ проектные решения;

♦ тестирование.

В рамках каждого из выделенных направлений рассмотрим следующие основные решения.

ARIS предлагает пользователю свой проводник (ARIS Explorer), дающий возможность доступа ко всем своим возможностям. Если баз в системе много и базы сложны по структуре, то только или разработчик, или высококвалифицированный эксперт сможет быстро сориентироваться в том объеме информации, который представлен на экране. Конечному пользователю, работающему с ограниченным, узко специализированным набором средств, такой объем информации не нужен (рис. 20, 21).

Рис. 20

Рис. 21

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

Рис. 22

Разработчики применили для этого концептуально понятный графический образ «домика ARIS», нагрузив его узнаваемые разделы специальным функционалом. Функционал связан с названием раздела – «комнаты» «домика ARIS». Способ доступа прост и применяем в любой модели ARIS – клик мышкой на пирамидке справа внизу от объекта или выбор в окне «Object Windows» на закладке «Assignments».

Задание ролей и определение связи «должность – роль», исходя из штатной структуры подразделения, реализующего бизнес-процесс

Разработчики проекта исходили из того соображения, что конкретная бизнес-функция реализуется не конкретным исполнителем Иванов – Петров – Сидоров, находящимся на конкретной должности, а некоторой организационной единицей, которая в одной организации – техник, в другой – инженер, в третьей – менеджер или еще кто-то. По мнению разработчиков, модель на этапе разработки не должна быть привязана к конкретной штатно-должностной структуре. По этой причине функционал, реализованный в модели, выполняет некую РОЛЬ, с которой может быть связана в последующем любая совокупность исполнителей и штатных структур. Связывание РОЛЬ – ДОЛЖНОСТЬ – ИСПОЛНИТЕЛЬ должно происходить отдельно от модели и никак не влиять на ее (модели) структуру и состав.

Подключение библиотек настроек организационно-технологической структуры

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

Рис. 23

Для связывания ролей с должностями и конкретными исполнителями применяется механизм создания организационной модели. Создается модель типа Organization Charts. Элементами ее становятся объекты типа Person Type (роли). Далее создается еще одна модель типа Organization Charts, на ней располагаются иерархически организованные объекты типа Organization Unit (подразделение) и Position (должность) (рис. 24).

Рис. 24

И наконец, последний этап – формируется модель типа Organization Charts, на которой располагаются объект Position (должность) и связанный с ним набор объектов типа Person Type (роль). Мы получаем модель, определяющую зависимость подразделение – его должностной состав, а для каждой должности – ее исполнителя и список обязанностей (ролей), которые исполнитель по решению или кадровых органов, или менеджера по прикладному функционалу должен выполнять.

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

Для представления структуры информационных систем применяются модели типа Application System Type, элементами которых являются выстроенные в иерархическом порядке объекты типа Application System Class (класс прикладной системы), Application System Type (прикладная система), классы информационных сервисов, информационные сервисы, ИТ-функции, классы модулей и модули. Пример модели типа Application System Type приведен на рис. 25. Объекты этой модели имеют многоуровневую детализацию – ассоциации, позволяющие в конечном итоге получить подробное представление об информационной среде функции на модели.

Рис. 25

Создание и подключение библиотек специализированных расчетных алгоритмов (модулей) затрат

Стандартная конфигурация ARIS позволяет производить многие виды стоимостных и прочих затратных (время, ресурсы) расчетов. Опции ABC и Simulation рассчитывают минимальные, максимальные и средние значения затрат многих видов ресурсов. Как уже упоминалось, для того чтобы получить коррелированные данные, надо долго и тщательно готовить модели. Получаемые отчеты очень подробны, содержат много ценной информации, но чтобы из нее выделить нужное, требуется дополнительная обработка отчетов при помощи дополнительных инструментов – как правило, статистического анализа. Однако далеко не всегда пользователь располагает знанием, временем, навыками, необходимыми для выполнения всего комплекса подготовительных и прочих мероприятий. Часто пользователей или интересуют очень специальные данные, которые нерационально долго извлекать, пользуясь стандартным вычислительным аппаратом, или данные выдаются не в том разрезе, который нужен. Для решения узких, специальных задач более рациональным может оказаться создание специализированных расчетных модулей, дающих результат много быстрее и с меньшими издержками. Например, создан скрипт, который выполняет:

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

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

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

Запуск прохождения по модели с указанными атрибутами и расчет с выдачей протокола затрат времени, средств по пройденному «маршруту»

Пример кода, реализующего некоторые из этих действий, приведен в приложении 2. Это функции Function secs(ss As Variant) As Long, Function time_count(sss As Double) As String и процедура Sub Count.

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

Связь между моделью «как есть» и «как должно быть» (независимая база, варианты)

Цели модернизации, актуализации базы, оптимизации процессов предполагают действия по изменению структуры базы, составляющих ее моделей, связанных с моделями объектов и т. п. Базу моделей из состояния «как есть» стремятся перевести в состояние «как будет», «как должно быть» – путем оптимизации процессов по структуре, времени выполнения, порядку распределения ресурсов и т. д. Этого эффекта достигают путем введения дополнительных типов ресурсов, информационных систем и т. п. Оптимизации осуществляются путем применения модуля Simulation. Изменения моделей проводятся, как правило, путем создания копий моделей и последующих их (моделей) модификаций. Копирование моделей производится или вручную, или через механизм «вариантов». Для сохранения унаследованных от моделей-источников связей применяют копирование или «варианты» через использование occurrences моделей и объектов на них. Это сохраняет унаследованные связи. Правда, сразу возникает проблема – изменение объектов модели-приемника сразу же изменяет и модель-источник, что далеко не всегда устраивает разработчика. Приходится копировать модели как Copy

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

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

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

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

♦ в автоматическом режиме копирует модели группы как Copy Occurrences;

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

♦ при наличии таких функций:

– создается новое definition (определение) функции;

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

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

– создается новое occurrence (представление) новой функции;

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

– удаляется «старое» occurrence функции на модели.

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

Такие группы моделей после соответствующей подготовки (назначения вероятностей событиям или формирования диаграмм событий, формирования дополнительных моделей, например графиков смен) можно оптимизировать Simulation или анализировать другими стандартными средствами ARIS (ABC или Balanced Scoreboard).

Формирование чувствительности документов

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

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

Например, значение атрибута документа Identifier= «DOC_NP_*» «делает» документ нормативным, а «DOC_OP_*» – оперативным. Добавление постфикса вместо символа «*» позволяет ввести дополнительную градацию. Например, «PSM» – это письма, а «LAW» – законы и т. д. На рис. 26, 27 приведены примеры применения такой практики к документам.

Рис. 26

Рис. 27

Для задания чувствительности документов к, например, типу товара, некоему режиму и типу транспорта происходит присвоение атрибутам документа «User attribute Text 1», «User attribute Text 2» и «User attribute Text 3» специальных значений, определенных в «Соглашении о моделировании» в соответствующей, также согласованной нотации. Пример применения этих соглашений приведен на рис. 28.

Рис. 28

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

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

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

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

♦ форматов загрузки, выгрузки информации;

♦ использования специализированного функционала.

Стандартно ARIS предоставляет средства взаимодействия с другими CASE-средствами разработки и поддержки моделирования бизнес-процессов. Назначение этих средств – обмен отдельными моделями с другими программными CASE-системами посредством файлов, записанных в XML-кодах. Этот обмен осуществляется при помощи специальных программ-интерфейсов сторонних производителей, например компании Reischmann Informatik GmbH (RI) (www.reischmann.com). В настоящее время интерфейсы TOOLBUS компании RI поддерживают больше чем 30 инструментальных CASE-средств. Посредством этих интерфейсов можно произвести обмен данными между ARIS и такими CASE-си-стемами, как ErWin от СА, PowerDesigner от Sybase и OracleDesigner. Обмен может быть произведен в обоих направлениях.

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

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

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

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

♦ из ARIS «выгрузить» в формате Excel информацию по ресурсам для MSProject;

♦ загрузить в MSProject информацию по ресурсам в формате Excel;

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

♦ преобразовать результаты, полученные в MSProject, в форматы, совместимые с ARIS (как правило, это формат Excel);

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

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

♦ скрипт выполняет формирования в формате Excel четырех рабочих листов специальной структуры, «понятной» программе-приемнику. Для формирования 1-го листа скрипт «проходит» по модели, формируя для каждой посещенной функции данные в следующем формате – «ID», «Функция», «Длительность», «Предшественник», «Уровень структуры». На 2-м листе должны формироваться данные по исполнителям. На 3-м листе должны формироваться данные по загрузке исполнителей. На 4-листе должна присутствовать идентификационная информация MSProject. Она формируется предварительно и добавляется в выходной файл, созданный скриптом «вручную»;

♦ ассоциированные модели преобразуются в «вехи» MSProject (веха не имеет длительности и ресурсов).

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

♦ определение критического пути;

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

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