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

правило, включает в себя:

¦ описание методов проектирования архитектуры в терминах использования определенных «строительных блоков»;

¦ описание того, как эти «строительные блоки» связаны между собой;

¦ набор инструментов для описания элементов архитектуры;

¦ общий словарь используемых терминов.

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

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

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

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

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

Определение модели согласно Захману (Zachman Framework for Enterprise Architecture). Модель представляет собой общий словарь, набор перспектив или структур для описания современных сложных, корпоративных систем и преследует две основные цели: с одной стороны, логическое разбиение поставленной задачи на отдельные блоки для упрощения формирования и восприятия итогового решения, с другой – обеспечение возможности рассмотрения целостной архитектуры решения с выделенных точек зрения или соответствующих уровней абстракции.

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

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

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

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

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

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

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

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

¦ порядок следования колонок несуществен;

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

¦ базовые модели для каждой из колонок являются уникальными;

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

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

Модель Gartner выделяет четыре связанных, взаимозависимых и усложняющихся уровня:

¦ Среда бизнес-взаимодействия (Business Relationship Grid);

¦ Бизнес-процессы и стили бизнес-процессов;

¦ Шаблоны;

¦ Технологические строительные блоки (кирпичики – bricks).

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

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

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

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

IDEF-технологии

Первые методы семейства стандартов IDEF (Integrated DEFinition) были разработаны в США в середине 70-х годов по программе Integrated Computer-Aided Manufacturing. В настоящее время данный комплекс стандартов включает в себя методы функционального, информационного, поведенческого моделирования и проектирования, приведенные ниже.

¦ IDEFO (Function Modeling Method) – стандарт функционального моделирования, позволяющий описать бизнес-процесс в виде иерархической системы взаимосвязанных функций (функциональных блоков – в терминах IDEF0).

¦ IDEF1 (Information and Data Modeling Method) – стандарт описания информационных потоков внутри системы, позволяющий отображать и анализировать их структуру и взаимосвязи.

¦ IDEF1X (IDEF1 Extended) – стандарт проектирования реляционных структур, основанный на концепции «сущность – связь» (ER – Entity-Relationship), предложенной в 1976 году