Хватит платить за все! Снижение издержек в компании - [57]

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

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

Третьим основным понятием стандарта IDEFo является декомпозиция(Decomposition). Принцип декомпозиции применяется при разбиении сложного процесса на составляющие его функции. При этом уровень детализации процесса определяется непосредственно разработчиком модели.

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

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

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

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

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

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

Очень важно при построении модели четко обозначить цель (purpose) и точку зрения (viewpoint)модели.

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

Необходимо понимать, что модель БП с точки зрения главного инженера и с точки зрения главного бухгалтера будут существенно различаться. Точка зрения – это своего рода «фильтр» для процесса.

Основы DFD

В основе нотации DFD лежат следующие понятия:

• работа;

• дуга;

• внешняя ссылка;

• хранилище данных.

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

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

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

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

Рис. III.7

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

Основы кроссфункциональной нотации

Схема бизнес-процесса (далее – схема БП) предназначена для:

• возможности проверки регламентируемого бизнес-процесса до написания текста рабочего регламента;

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

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

Лист схемы (рабочее поле схемы) должен быть оформлен следующим образом. Рабочее поле разделяется на четыре зоны:

• «Исполнители»;

• «Действия»;

• «Условия»;

• «Результаты».

Рис. III.8. Рабочее поле схемы

Требования к оформлению полей схемы

В зоне «Исполнители» должен быть указан субъект, который выполняет ту или иную процедуру (или субъекты, выполняющие процедуру).

В зоне «Процедура» должны быть указаны процедура и укрупненный перечень действия, которые выполняет субъект (субъекты).