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

Контекст и основные элементы бизнес-архитектуры

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Базовые принципы, методы и определения моделирования бизнес-процессов

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

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

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

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

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

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

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

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

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

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

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

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

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

Общие принципы моделирования

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Объектный анализ

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

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

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

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

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

♦ функций, уровень их типизации, уровень автоматизации;

♦ документооборота;

♦ организационных единиц, должностей, ролей;

♦ информационных и технических средств.

Процессный анализ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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