Методология описания бизнес-процессов

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

· теоретическая база;

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

· рекомендации по использованию как отдельно, так и в составе группы методик.

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

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

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

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

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

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

· проверить, что материалы и изделия доступны для производства или доставки заказчикам;

· управлять наименьшим возможным уровнем инвентаризации;

· планировать производственные процессы, поставки и закупки.

Американское общество по контролю над производством и запасами (American Production and Inventory Control Society, APICS) разработало стандарт MRP II (Manufacturing Resource Planning) – управление производственными ресурсами. Метод эффективного планирования всех ресурсов предприятия-производителя. Позволяет осуществлять операционное планирование (в единицах продукции), финансовое планирование (в долларах) и моделировать различные ситуации, отвечая на вопросы "что если".

MRP II состоит из набора взаимосвязанных функций, основными из которых являются:

· бизнес-планирование;

· планирование производства и продаж;

· планирование выпуска продукции;

· составление основного производственного плана – MPS (Master Production Schedule). Комбинация всех известных и ожидаемых потребностей в определенном продукте. Производственный план простирается до горизонта планирования – несколько месяцев или лет в будущее - и содержит в себе только данные о потребности в конечных изделиях во времени. Уровень компонент (потребностей в компонентах) обрабатывается системами планирования потребности в материалах (см. MRP);

· планирование потребности в материалах (см. MRP);

· планирование потребности в производственных мощностях –CRP (Capacity Requirements Planning). Технология планирования загрузки трудовых и технических ресурсов в соответствии с заданным планом потребностей в материалах (см. MRP). Загрузка рабочих мест рассчитывается на основе технологического маршрута изготовления изделия – набора шагов (операций), которые необходимо совершить для изготовления изделия или его части. Каждая операция совершается на каком-то рабочем месте, которое может состоять из одного или нескольких человек и/или оборудования;

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

MRP II включает в себя детальное описание 16 групп основных функций. Интегрированные финансовые отчеты, получаемые с помощью систем класса MRP II, содержат следующую информацию:

· бизнес-план;

· отчет обязательств по заказам;

· экспедиторский бюджет;

· цена запасов в долларах.

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

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

Таблица 1 Элементы заголовка диаграммы IDEF0

Поле	Назначение
USED AT	Используется для отражения внешних ссылок на данную диаграмму (заполняется на печатном документе вручную
Author, date, project	Содержит ФИО автора диаграммы, дату создания, дату последнего внесения изменений, наименование проекта, в рамках которого она создавалась.
Notes 1…10	При ручном редактировании диаграмм пользователи могут зачеркивать цифры каждый раз, когда они вносят очередное исправление
Status	Статус отражает состояние разработки или утверждения данной диаграммы. Это поле используется для реализации формального процесса публикации с шагами пересмотра и утверждения.
Working	Новая диаграмма, глобальные изменения или новый автор для существующей диаграммы
Draft	Диаграмма достигла некоторого приемлемого для читателей уровня и готова для представления на утверждение.
Recommended	Диаграмма одобрена и утверждена. Какие-либо изменения не предвидятся.
Publication	Диаграмма готова для окончательной печати и публикации.
Reader	ФИО читателя
Date	Дата знакомства читателя с диаграммой
Context	Набросок расположения функциональных блоков на родительской диаграмме, на котором подсвечен декомпозируемый данной диаграммой блок. Для диаграммы самого верхнего уровня (контекстной диаграммы) в поле помещается контекст ТОР

Таблица 2 Элементы «подвала» диаграммыIDEF0

Поле	Назначение
Node	Номер диаграммы, совпадающий с номером родительского функционального блока
Title	Имя родительского функционального блока
Number (еще называют C- Number)	Уникальный идентификатор данной версии данной программы. Таким образом, каждая новая версия данной программы будет иметь новое значение в этом поле. Как правило, C- Number состоит из инициалов автора (которые предполагаются уникальными среди всех аналитиков проекта) и последовательного уникального идентификатора, например SDO005. При публикации эти номера могут быть заменены стандартными номерами страниц. если диаграмма замещает другую диаграмму, номер заменяемой диаграммы может быть заключен в скобки – SDO005 (SDO004). Это обеспечивает хранение истории изменений всех диаграмм модели

Каждая модель должна иметь контекстную диаграмму верхнего уровня, на которой объект моделирования представлен единственным блоком с граничными стрелками. Эта диаграмма называется А-0 (А минус ноль). На контекстной диаграмме указываются связи системы с внешним миром.

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

1. Объявляет общую функцию моделируемой системы.

2. Дает множество основных типов или наборов данных, которые использует и производит система.

3. Указывает взаимоотношение между основными типами данных, проводя их разграничение.

Потоки делятся на:

· входные (то, что перерабатывается системой);

· выходные (результат работы системы);

· управления (регламентирующая и управляющая информации или правила) механизма (ресурсы выполняющие работы).

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

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

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

Рис. 1.5. Пример диаграммы А-0

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

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

Диаграммы А-0 и АО должны подвергаться автором, а затем и экспертами тщательному контролю. Главными позициями контроля является:

· Адекватно ли название блока на диаграмме А-0 отражает то, что делает система.

· На сколько правильно произведено разделение между основными типами или наборами данных.

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

· Точность описания потока данных, наличие обратных связей.

· Осуществляют ли дуги управления управляющее воздействие на процесс преобразования входных данных в выходные.

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

Диаграммы А-0 и АО с заполненным глоссарием, необходимыми пояснениями на текстовых и FEO станицах проходят необходимое количество циклов рецензирования до приобретения ими статуса "публикация".

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

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

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

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

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

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