Модель бизнес-процессов. Типовая архитектура модели бизнес-процессов

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

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

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

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

Третий уровень (логическая модель) соответствует рассмотрению с точки зрения системного архитектора. Здесь бизнес-процессы описываются уже в терминах информационных систем, включая различные типы данных, правила их преобразования и обработки для выполнения определенных на уровне 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 году сотрудником корпорации IBM Питером Ченом. Применяется для разработки реляционных баз данных и использует условный синтаксис, специально разработанный для удобного построения концептуальной схемы и обеспечивающий универсальное представление структуры данных в рамках организации, независимое от конечной реализации базы данных и аппаратной платформы.

♦ IDEF2 (Simulation Modeling Method) – стандарт динамического моделирования развития систем. В связи с весьма серьезными сложностями задачи построения модели динамической системы и ее последующего анализа от использования этого стандарта практически отказались, и его развитие приостановилось еще на начальном этапе. IDEF2 использует модели и методы имитационного моделирования систем массового обслуживания, сети Петри, модель конечного автомата, описывающую поведение системы как последовательность смен состояний.

♦ IDEF3 (Process Flow and Object Stale Description Capture Method) – стандарт документирования процессов, происходящих в системе. Применяется при исследовании, например, технологических процессов на предприятиях. С помощью IDEF3 описываются сценарий и последовательность операций для каждого процесса. IDEF3 имеет прямую взаимосвязь с методологией IDEF0 – каждая функция (функциональный блок) может быть представлена в виде отдельного процесса средствами IDEF3.

♦ IDEF4 (Object-oriented Design Method) – стандарт проектирования объектно-ориентированных систем. IDEF4 позволяет наглядно отображать структуру объектов и заложенные принципы их взаимодействия, тем самым давая возможность анализировать и оптимизировать сложные объектно-ориентированные системы.

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

♦ IDEF6 (Designed Rational Capture Method) – назначение стандарта состоит в структурировании «знаний о способе» моделирования, их представления и использования при разработке информационных систем. Под «знаниями о способе» понимаются причины, обстоятельства, другие мотивы, которые обусловливают выбранные методы моделирования. Проще говоря, «знания о способе» интерпретируются как ответ на вопрос: «почему модель выглядит таким образом?». Стандарт IDEF6 акцентирует внимание именно на процессе создания модели.

♦ IDEF8 (Human-System Interaction Design) – стандарт описания интерфейсов взаимодействия оператора и системы (пользовательских интерфейсов). Современные среды разработки пользовательских интерфейсов в большей степени создают внешний вид интерфейса. IDEF8 фокусирует внимание разработчиков интерфейса на программировании желаемого взаимного поведения интерфейса и пользователя на трех уровнях: выполняемой операции (что это за операция); сценарии взаимодействия, определяемом специфической ролью пользователя (по какому сценарию она должна выполняться тем или иным пользователем) и на деталях интерфейса (какие элементы управления предлагает интерфейс для выполнения операции).

♦ IDEF9 (Business Constraint Discovery) – стандарт описания бизнес-ограничений, используется при определении и анализе ограничений, в которых действует организация.

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