Реинжиниринговый подход к управлению бизнес-процессами в организации

служить основой для формирования нового процесса и при этом не могут

служить обособлено, как часть структурного анализа. Функциональная

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

Метод IDEF0 хорошо подходит в качестве инструмента анализа и

моделирования функциональной системы организации. Чаще всего стандарт IDEF0

используется на ранних стадиях проекта, возможно предшествующий методу

IDEF3 для сбора данных, и моделирования процесса «как есть». Анализ,

использующий метод IDEF0, может также использовать данные метода IDEF3 и

DFD.

К компонентам стандарта IDEF 0 следует отнести следующие:

18. функции (действия);

19. связи;

20. диаграммы;

Метод IDEF0 комбинирует графическую ограниченность (в модели

присутствуют только два символа: прямоугольник и интерфейсная стрелка) со

строгим и хорошо определенным процессом, которыми создается модель для

улучшения качества законченности процесса.

В первую очередь при построении IDEF0 модели нужно определить цель

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

Эти вопросы должны быть составлены как часть документации к модели.

Масштаб модели состоит из широты и глубины детализации.

1. Функция (Activity).

Функция (действие) обрабатывает или перерабатывает входы в выходы.

IDEF0 моделирует систему как иерархию действий. Начальное действие – это

действие, описывающее саму систему, так называемое контекстное (базовое)

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

Имя действия в модели IDEF0 обычно состоит из одного глагола и

существительного, которое характеризует объект функции. Также в имя функции

может добавляться прилагательное для дополнительной информативности

наименования. Важно, чтобы название действия точно характеризовало бизнес-

систему.

Раннее мы отмечали, что метод IDEF0 моделирует систему как иерархию

действий. Действие может быть декомпозировано на его составные части. Если

мы изображаем модель IDEF0 как прямоугольник, то мы можем, как бы, увидеть

декомпозицию действия, заглянув внутрь его прямоугольника, обозревая

одновременно те действия, из которых рассматриваемое действие состоит.

Декомпозиция обычно сравнивается с моделированием «сверху вниз». Однако это

заблуждение.

2. Границы и интерфейс (интерфейсные стрелки) (Boundary & Interface).

Для того, чтобы модель была используема, описание действия должно по

минимуму содержать описание объекта, которое оно создает также как и

объекты, которые действие использует и трансформирует в дальнейшем.

В модели IDEF0 мы также моделируем контроль и механизмы. Контроль

является объектами, которые управляют методами, в которых входы

трансформированы, но не трансформированы действиями. Механизмы – это такие

объекты, которые осуществляют трансформацию входов в выходы не

самостоятельно, а действием.

ИКОМ – это аббревиатура для категорий информации, которая заложена в

основу диаграммы метода IDEF0.

Она представляет из себя четыре типа стрелок:

И (input) – Вход – то, что потребляет процесс.

К (control) – Управление – влияние на операцию процесса.

О (output) – Выход – результат процесса.

М (mechanism) – Ресурс – то, что используется для осуществления процесса,

но не употребляется процессом.

Рис. 3 Описание действия в стандарте IDEF0

Название действия всегда сформировано из глагола или отглагольной

фразы (например, «Подготовка технического задания»), а в названии

интерфейсной интерфейсные стрелки присутствует только слово в форме

существительного. Интерфейсной интерфейсные стрелки могут описывать людей,

места, вещи, концепции или события.

Интерфейсная стрелка «вход» (Input).

Интерфейсные стрелки «вход» характеризуют собой сырье, материалы или

информацию, которые трансформируются действием для создания выхода

(продукта действия). Интерфейсная стрелка «вход» расположена в левой части

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

«вход» необязательна в случаях, когда действие ничего не трансформирует и

не изменяет.

Интерфейсная стрелка «управление» (Control).

Интерфейсная стрелка «управление» управляет или/и регулирует как,

когда будет осуществлено действие, а если действие уже было осуществлено,

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

«управление» управляет действием в целях создания требуемого выхода

(результата), то в таком случае каждое действие должно иметь по крайней

мере одну управляющую интерфейсную стрелку. Интерфейсная стрелка

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

него. «Управление» осуществляется в форме правил, принципов, процедур или

стандартов. Они влияют на действие без прямого участия в трансформации

входов в выходы. Однако существуют случаи, когда цель действия является

изменением правил, принципов, процедур или стандартов. В таком случае нужно

иметь в виду то, что интерфейсная стрелка, содержащая такую цель будет

являться входом. «Управление» – специальный тип входа в действие. Если

неясно, как должна быть смоделирована интерфейсная стрелка: как вход или

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

подобной двусмысленности. Модели, интегрирующие данные и процесс являются

технологией разрешения указанной выше двусмысленности.

Интерфейсная стрелка «ресурс» (Mechanism).

Интерфейсная стрелка «Ресурсы» – обозначает те ресурсы, которые

способствуют осуществлению действия (функции). Ресурсами могут являться,

например, люди, машины и оборудование. Интерфейсная стрелка «ресурс» может

не изображаться на диаграмме, если она не требуется для осуществления

какого-либо действия (функции).

Интерфейсная стрелка «выход» (Output).

Выход – это материалы или информация, производимая действием. Каждое

действие должно по крайней мере иметь одну интерфейсную стрелку «выход».

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

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

В непроизводственной сфере выходы чаще всего являются данными,

которые обрабатывались каким-либо образом действием. Важно использовать

надписи над интерфейсными стрелками для определения того, как данные выходы

отличаются от данных входа.

Комбинации стрелок интерфейса (Arrows Combinations).

Существует пять основных комбинаций стрелок интерфейса:

«выход --- вход», «выход – управление», «выход – ресурс», «выход –

управление с обратной связью», «выход – вход с обратной связью».

Интерфейсная стрелка «выход – вход» описывает действие, которое

предшествует другому действию и является первоочередным.

Интерфейсная стрелка «выход --- управление» описывает подчинение

одного действия другому, так как оно контролирует то, как это действие

трансформирует входы в выходы.

Интерфейсная стрелка «выход – ресурс» используется реже и

представляет ситуацию, в которой выход одного действия становится ресурсом

для осуществления другого.

Интерфейсная стрелка «выход – управление с обратной связью» описывает

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

связь действиям с большей предпочтительностью.

Интерфейсная стрелка «выход – вход с обратной связью» обычно

используется для описания цикла переработки. В других случаях интерфейсные

стрелки «выход – вход с обратной связью» используются для описания событий,

при которых остатки материалов могут быть заново использованы параллельно с

новым сырьем (брак и т.д.).

Разветвление и соединение (Branching & Joining).

«Выходы» какого –либо действия могут быть использованы более, чем

одним другим действием. Метод IDEF0 позволяет визуализировать зависимости

между собой действий внутри системы. Интерфейсные стрелки метода IDEF0

могут разветвляться и соединяться.

Значение разветвляющейся или соединяющейся интерфейсной стрелки

определяется надписью на сегменте интерфейсной стрелки, которая разветвляет

или соединяет. Если интерфейсная стрелка разветвляется и ветвь

переименована, то новое имя должно отражать название основной интерфейсной

стрелки. Ветвление стрелок представляет собой декомпозицию данных (также

как и иерархия действий представляет собой функциональную декомпозицию).

Линии в форме молний (squiggle) часто используются в диаграммах

метода IDEF0 для более ясной связи между стрелкой и ее названием.

Интерфейсные стрелки ссылки (Call Arrow).

Интерфейсные стрелки ссылки используются для указания на другие

модели или диаграммы внутри модели, которые могут помочь изучающему лучше

понять существующую модель. Интерфейсная стрелка ссылки может ссылаться на

другую диаграмму (правильно говорить - «базовое действие диаграммы») внутри

самой модели и может также ссылаться к специфическому дочернему действию

другой модели. Это способ, в котором функциональное дублирование может быть

удобнее задокументировано в модели.

Туннели (Tunnels).

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

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

стрелка не возникает на базовой диаграмме, но и не связана с другими

интерфейсными стрелками, туннель используется для указания того, что

интерфейсная стрелка входит или выходит из системы. Туннель используется,

чтобы не загромождать базовую диаграмму. В других случаях туннель может

быть использован в интерфейсной стрелке, ведущей в (или из) базового

действия. Это указывает на то, что взаимоотношения интерфейсной стрелки с

дочерними действиями не определены.

Действия и активация действий (Activities & Activities Activation).

Мы можем декомпозировать модель для анализа отдельных действий. Мы

также можем изначально создать отдельные IDEF3 диаграммы для каждого из

этих действий. Эта методика требуется в случае, если мы хотим оценить

действия, используя симуляторы.

В качестве простейшей альтернативы к указанным выше двум подходам -

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

управления, выходов и ресурсов для каждой активации действия.

Активация --- это уникальная конфигурация «входа» и «управления», а

также требуемых ресурсов. Т.е. результат (выход) действия получается в

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

информации и т.д.), управления над трансформацией и наличия ресурсов

(персонал, оборудование и т.д.). Нижеприведенная таблица является примером

таблицы активации. Каждой активации присвоено уникальное имя внутри

действия и дана стоимость различных стрелок. Комбинация стоимости стрелок

должна быть уникальна для каждой активации, т. е. две активации не должны

иметь одинаковую стоимость всех своих стрелок.

Таблица активации

|Имя активации |Имя интерфейсной |Стоимость |

| |стрелки |интерфейсной стрелки |

|Ровная стена |Обои |< 1000 долл. |

| |Шпатлевка |Не требуется |

|Неровная стена |Обои |> 1000 долл. |

| |Шпатлевка |Требуется 10 кг |

Информация по активации в таблице мало говорит нам о содержании

интерфейсной стрелки управления для данного действия.

2.4. Компоненты диаграммы стандарта IDEF0.

Границы диаграммы строго очерчены вверху и внизу. Верхние элементы

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

Нижние элементы границы отражают особенности диаграммы и ее место в

иерархии.

Верхние элементы границы следующие:

|Поле |Значение |

|Использовано |Обычно используется в |

| |документах, где эта диаграмма |

| |указывается стрелкой ссылкой. |

|Автор, дата и проект |Говорит о том, кто создал |

| |диаграмму, о дате ее создания и |

| |названии проекта, под эгидой |

| |которого она создана. Название |

| |проекта нужно для поиска |

| |диаграмм внутри проекта. Дата |

| |пересмотра – это дата, |

| |указывающая, когда диаграмма |

| |была последний раз изменена. |

|Заметки 12345678910 |Когда диаграммы редактируются от|

| |руки, эксперты зачеркивают |

| |последовательно число каждый |

| |раз, когда вносят новые элементы|

| |в диаграмму. |

|Статус |Статус определяет уровень |

| |прохождения этапа утверждения |

| |диаграммы. Данное поле |

| |используется для выполнения |

| |формального редакционного |

| |процесса с обзорами и стадиями |

| |утверждения. |

|В работе | |

| |Означает новую диаграмму, важное|

| |изменение либо нового автора для|

| |уже существующей диаграммы |

|Проект | |

| |Диаграмма уже достигла |

| |определенного уровня доработки |

| |исследователем. Она готова для |

| |оценки ее специальным комитетом |

| |(или «хозяином» процесса). |

|Рекомендовано | |

| |Диаграмма и описывающий ее текст|

| |были проанализированы и |

| |утверждены. Не ожидаются |

| |какие-либо их изменения. |

|Публикация | |

| |Диаграмма готова к окончательной|

| |печати и публикации. |

|Читатель |Имя (имена) читателя |

| |(читателей). |

|Дата |Дата прочтения диаграммы. |

|Контекст |Отображение контуров |

| |прямоугольников действий в |

| |родительской диаграмме с |

| |подсвечиванием родительского |

| |действия данной диаграммы. Также|

| |указывается номер родительского |

| |действия. Поле контекста |

| |контекстной диаграммы должно |

| |изображаться словом «главная» |

| |(«top») для указания на то, что |

| |в модели нет родительской |

| |диаграммы. |

Нижние элементы границы диаграммы следующие:

|Поле |Значение |

|Узел |Номер узла данной диаграммы тот |

| |же, что и номер действия данного|

| |родительского действия |

| |диаграммы. |

|Заглавие |Это название родительского |

| |действия. |

|Число |Также называется С–число. Это |

| |число является уникальным |

| |идентификатором для «этой |

| |версии», «этой диаграммы». Таким|

| |образом, любая другая новая |

| |версия диаграммы будет иметь |

| |новое С-число. Обычно С-число |

| |состоит из инициалов автора |

| |(должны быть уникальны) и |

| |последовательного уникального |

| |идентификатора. |

2.5. Некоторые правила построения модели.

Ни одна модель не может быть создана без конкретного объекта или

цели. Формулировка цели должна ответить на следующие вопросы:

почему был смоделирован представленный процесс;

что эта модель собирается показать;

что с ней могут сделать читающие ее.

Формулировка цели позволяет команде экспертов придерживаться ее на

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

моделирование может зайти в тупик.

Модели создаются для получения ответа на ряд вопросов. Данные вопросы

должны подготавливаться заранее и будут служить основой для создания цели

модели. Примерные вопросы могут звучать следующим образом:

-каковы основные задачи сотрудника;

-кто отвечает за произведенную продукцию;

-кто управляет начальной стадией производства;

-какой требуется инструмент для каждого этапа.

Точка зрения (Viewpoint).

Особенно важно включать в процесс разработки модели представителей

различных мнений, однако сама модель должна базироваться на единой точке

зрения. Чаще всего разнообразные точки зрения кратко фиксируют на диаграмме

ФЕО (англ. FEO, For Exposition Only. Русс. --- только для комментариев).

Эти диаграммы используются только в качестве материалов для

презентаций. Точка зрения должна формулироваться с особенной

внимательностью, отталкиваясь от цели.

При построении модели важно придерживаться одной точки зрения. Точка

зрения должна содержать наименование должности, структурного подразделения

или описание должностных обязанностей работника.

Модели могут содержать разнообразные точки зрения с целью детальной

фиксации всех действий (функций).

Границы (Boundary).

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

действия, является прояснение границ всей системы и ее специфических

компонентов действия.

Хотя предполагается, что границы будут слегка модифицированы на

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

направления в процессе разработки модели. К примеру, трудно понять

закончена ли модель, формулируя цели без существования определенной

границы. Граница модели будет иметь склонность расширяться в процессе

совершенствования модели.

Граница имеет два компонента --- широту и глубину. Широту модели

определяют боковые границы процесса. Глубину определяет уровень

декомпозиции действий.

Для простоты определения границы многие процессы разработки модели

IDEF 0 затрачивают большое время на доработку контекстной диаграммы модели.

Диаграмма может быть даже разработана, что само по себе будет представлять

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

внутри которой данная система находится. Эти усилия стоят того, так как

контекстная диаграмма становится точкой отсчета для всего процесса

моделирования. Все изменения в контекстной диаграмме будут становиться

своеобразным каскадом в форме декомпозиции диаграммы.

Когда границы определены, то действия, не вошедшие в модель также

Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10