4. Моделирование бизнес-процессов

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

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

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

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

По отношению к получению добавленной ценности выделяют два класса процессов:

• Основные (увеличивают ценность)

• Обеспечивающие (увеличивают стоимость, но не увеличивают ценность)

Основные бизнес-процессы:

• Планирование деятельности

• Осуществление деятельности

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

• Контроль и анализ исполнения плана

• Принятие управленческих решений

Потоки информации в организации с линейной (функционально-иерархической) структурой:

• Плановая информация (сверху вниз)

• Контроль (по всем уровням организации)

• Оперативная и периодическая отчетность (снизу вверх)

• Анализ и прогнозирование

Основные функции управления:

• Планирование это выбор желаемого поведения процесса на период планирования.

• Учет это определение фактического состояния процесса в заданные моменты времени.

• Контроль позволяет определить отклонение фактического состояния от планируемого.

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

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

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

В начале 70-х годов Д. Росс в США предложил метод структурного проектирования и анализа систем SADT (Structured Analysis and Design Techniques) [3]. В основе этого подхода лежит графический язык описания (моделирования) систем.

В середине 70-х ВВС США реализовало программу интегрированной компьютеризации производства ICAM (Integrated Computer Aided Manufacturing).

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

Частные методологии IDEF:

• IDEF0 – функциональное моделирования;

• IDEF1 – информационное моделирование;

• IDEF1X – моделирование данных (он же ERWin);

• IDEF3 – моделирование «потока» процессов;

• IDEF4 – объектно-ориентированное проектирование и анализ;

• IDEF5 – определение онтологий (словарей);

• IDEF9 – моделирование требований;

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

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

Функциями в IDEF0 принято называть все, что происходит в системе и ее подсистемах.

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

Для описания блоков и стрелок используются метки на естественном языке

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

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

Функциональный блок.

Input (Вход) описывает то, что потребляется процессом

Control (Управление) задает ограничения на процесс

Output (Выход) это результаты процесса

Mechanism (Механизм) -- то, что выполняет процесс

Стрелка “Вызов” считается как бы не вполне стандартной

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

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

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

1. Зачем мы моделируем эти процессы?

2. На какие вопросы должна ответить модель?

3. Как можно применить модель?

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

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

Что есть в диаграмме IDEF0:

• Боксы деятельностей с 4-мя выделенными сторонами (вход, выход, управление, механизм, вызов)

• Наименования деятельностей

• Связи между деятельностями

• Туннели

Нет в диаграмме IDEF0 таких свойств деятельностей и связей между деятельностями, как:

• Порядок действий

• Временные соотношения

• Условия перехода

• Группирование действий

Что можно добавить:

• Свойства, определенные пользователем

Диаграммы DFD (Data Flow Diagram) в нотации Гейна – Сарсона используют четыре элемента:

• Процессы. Функции, которые обрабатывают информацию. Изображаются прямоугольниками со скругленными углами. Стороны блока не выделены.

• Стрелки. Обозначают потоки данных. Соединяют выход объекта/процесса с входом другого объекта/процесса.

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

• Хранилища данных. Содержат данные, которые могут выбираться в любом порядке. Имя хранилища должно определять его содержимое и быть существительным.

Отличие DFD от IDEF0:

• Модели DFD работают только с информационными потоками

• Кроме блоков действий введены накопители и внешние источники/приемники. Действия изображаются прямоугольниками со скругленными краями

• Нет специализации сторон блока. Нет ограничения на топологию связей

• Доминирование функций на диаграмме не отражается

• Управляющие воздействия могут быть только информационными (в IDEF0 они могут быть еще материальными и энергетическими)

• Внешние сущности и хранилища могут повторяться по нескольку раз, если это упрощает диаграмму

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

Стандарт IDEF3 предназначен для моделирования сценариев технологических процессов. Сценарий (Scenario) это описание последовательности изменений свойств материального или информационного объекта (например, описание этапов обработки детали и изменения её свойств после каждого этапа).

Существуют два типа диаграмм IDEF3, представляющие два аспекта одного сценария:

• Диаграммы описания потоков процесса (Process Flow Description Diagrams, PFDD) или схемы процессов. Это собственно сценарий (сеть процессов).

• Диаграммы сети трансформаций состояний объекта (Object State Transition Network, OSTN) или схемы перехо-дов. Их можно было бы назвать диаграммами состояний.

Диаграммы PFDD рассматривают процесс “с точки зрения наблюдателя", а диаграмм OSTN “с точки зрения объекта".

Исполнение каждого сценария может поддерживаться потоком документов.

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

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

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

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

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

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

В IDEF3 есть следующие виды связей:

1. временное предшествование

2. отношение

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

4. ссылки

Три типа диаграмм:

Всю информацию для построения диаграммы “as-is” можно получить при обследовании организации. Остальные диаграммы требуют хорошего знания предметной области и опыта реинжиниринга

Модель “to-do” определяет техническое задание (ТЗ), оно же техническая спецификация (ТС) на реинжиниринг организации. Одновременно выбирается методика и готовятся документы для проведения детального предпроектного исследования. Анализируются последствия вносимых изменений. Разрабатывается технико - экономическое обоснование эффективности реинжиниринга.

Модель “to-be” описывает тот вариант организации бизнес-процессов, к которому переходят в результате реинжиниринга.