Создание схемы IDEF0
IDEF0 обозначает определение интеграции для моделирования процессов — методологию создания общедоступных доменов, которая используется для моделирования предприятий и их процессов, чтобы их можно было понять и улучшить. Это тип схемы.
Схемы IDEF0 обычно включают следующие компоненты:
- Контекстная схема — самая верхняя схема в модели IDEF0.
- Иерархия декомпозиции IDEF0 с использованием родительских и детских связей.
- Дерева узлов — структуры узлов в виде дерева, корневые на выбранном узле и используемые для представления полного декомпозиции IDEF0 в одной схеме.
Создание контекстной схемы
- Откройте Visio.
- В Visio 2013 и более новых версиях: щелкните категорию «Диаграммы», выберите IDEF0 Diagram (Схема IDEF0) и нажмите кнопку Create (Создать). In Visio 2010: Under Template Categories, click Flowchart >IDEF0 Diagram >Create. В Office Visio 2007: в меню Файл найдите пункты Новые ,Навести указатель мыши на пункт«Схема» и выберите пункт Схема IDEF0.
- Добавьте блок заголовка, чтобы уложить имя узла, заголовок и номер для схемы.
- Перетащите фигуру Блок заголовка из фигур схемы IDEF0на страницу.
- В диалоговом окне Данные фигуры введите имя узла, например A-0 (минус ноль) или более полное имя, например QA/A-0, где qa — это сокращение имени модели. Вы также можете ввести название и номер схемы. Выберите расстояние от внешнего края страницы до границы блока заголовка и нажмите кнопку ОК.
- Из фигур схемы IDEF0перетащите фигуру «Действие» внутри блока заголовка.
- В диалоговом окне Данные фигуры введите имя процесса. В качестве ИД процессаиспользуйте по умолчанию A0, чтобы представить процесс верхнего уровня. В качестве ИД под-схемывведите ИД схемы декомпозиции, если этот процесс является декомпозицией.
- Из фигур схемы IDEF0перетащите на страницу схемы одну разборную фигуру соединителевой схемы и перетащите конечные точки к точкам соединения в полях действий.
- Чтобы добавить текст с описанием соединителю, вы выберите ее и введите текст.
- Из фигур схемы IDEF0перетащите фигуру Блок текста 8 пт на страницу документа внутри блока заголовка.
- Перетащите боковой лад, чтобы растянуть блок текста по ширине блока заголовка.
- Выделив фигуру, введите текст, чтобы описать, для какой модели она предназначена.
Создание родительской или детской схемы
- Откройте Visio.
- В Visio 2013 и более новых версиях: щелкните категорию «Диаграммы», выберите IDEF0 Diagram (Схема IDEF0) и нажмите кнопку Create (Создать). In Visio 2010: Under Template Categories, click Flowchart >IDEF0 Diagram >Create. В Visio 2007: в меню Файл найдите пункты Новые ,Навести указатель мыши на пункт«Схема» и выберите пункт Схема IDEF0.
- Добавьте блок заголовка, чтобы уложить имя узла, заголовок и номер для схемы.
- Из фигур схемы IDEF0перетащите фигуру Блок заголовка на страницу.
- В диалоговом окне Данные фигуры введите имя узла, например A0 (для самой верхней родительской схемы), или номер узла родительской функции (например, A3 или A112), если родительская схема также является родительской схемой. Вы также можете ввести заголовок и номер. Выберите расстояние от внешнего края страницы до границы блока заголовка и нажмите кнопку ОК.
- Из фигур схемы IDEF0перетащите фигуру «Действие» в блок заголовка.
- В диалоговом окне Данные фигуры введите имя процесса, который представляет поле. (Имя должно быть активным глаголом или глагольным словосочетанием.) Введите ИД процесса (число от 1 до 6) и подстраховую схему. В под-схеме (также известной как выражение подробных ссылок или DRE) находится номер подчиненной схемы этого окна действия, если он будет иметь такой. В под-схеме может быть номер узла, например A42, либо номер страницы или имя подчиненной схемы.
- Продолжайте перетаскивание, присвоение имен и нумингу полей, пока в блоке заголовка не будет от трех до шести полей.
- Из фигур схемы IDEF0перетащите соединителон IDEF0 на страницу, а затем перетащите его конечные точки к точкам соединения в полях действий. Когда конечные точки поворачиваться красным цветом, фигуры соединены.
- Перетащите второй соединителка IDEF0 на страницу и перетащите его точки к точке соединения в другом поле действия.
- Поместите стрелку второго соединитела непосредственно на стрелку первого соединитела, чтобы две стрелки были соединены друг с другом.
Создание стрелок для висячай
- Из фигур схемы IDEF0перетащите соединителон IDEF0 на страницу, а затем перетащите его конечные точки к точкам соединения в полях действий. Когда конечные точки поворачиваться красным цветом, фигуры соединены.
- Перетащите на страницу второй соединителся IDEF0 и выровняте его точки с первой.
- Перетащите конечную вверх или вниз, пока стрелки не разорвятся нужным образом.
- Повторяйте шаги 1—3, пока не у вас будет нужное количество вилок.
Создание стрелок, которые раздувайте в ветви
- Перетащите соединителку IDEF0 на страницу, а затем перетащите точки к точке соединения в поле действия. Когда начальная точка становится красной, фигуры соединены.
- Перетаскивать стрелку, пока соединитектор не будет изгибаться нужным образом.
- Выбрав соединитель, перетащите копию соединителя в то место, куда нужно ввести первую ветвь, удерживая на клавише CTRL.
- Нажмите клавишу F4, чтобы создать нужное количество дополнительных ветвей.
- Подключение конечные точки в соответствующие поля действий.
Совет: Чтобы лучше выровнять ветви, соедините точки начала дубликаты ветвей с точки начала исходной ветви. Если ваши ветви имеют два изгиба, можно также использовать для положение центрального отгона соединителения.
Создание стрелок для этого канала
- Из фигур схемы IDEF0перетащите соединителон IDEF0 на страницу, а затем перетащите его конечные точки к точкам соединения соответствующим полям действий. Когда конечные точки поворачиваться красным цветом, фигуры соединены.
- Чтобы добавить канал, щелкните соединителю правой кнопкой мыши и выберите Tunnel В или Tunnel Выход. Чтобы удалить соединителку, щелкните его правой кнопкой мыши и выберите Tunnel В или Tunnel выход, чтобы снять его.
Примечание: Используйте фигуру соединителю с разборкой в виде разборки, чтобы добавить стрелки прямой линии на схему IDEF0.
Создание дерева узлов
- Откройте Visio.
- В Visio 2013 и более новых версиях: щелкните категорию «Диаграммы», выберите IDEF0 Diagram (Схема IDEF0) и нажмите кнопку Create (Создать). In Visio 2010: Under Template Categories, click Flowchart >IDEF0 Diagram >Create. В Visio 2007: в меню Файл найдите пункты Новые ,Навести указатель мыши на пункт«Схема» и выберите пункт Схема IDEF0.
- Добавьте узел на схему.
- Перетащите фигуру Узел на страницу чертежа.
- В диалоговом окне Данные фигуры введите A0 либо номер узла или имя узла, для которого нужно корневое дерево, и нажмите кнопку ОК.
- Чтобы добавить текстовую метку на узел, перетащите на страницу документа фигуру Блок текста 8 пт. Выбирая блок текста, введите метку.
- На схеме дерева узла IDEF0 щелкните правой кнопкой мыши узел, который вы хотите изменить,и выберите установить номер узла .
- В диалоговом окне Данные фигуры введите нужное число и нажмите кнопку ОК.
- Чтобы изменить положение номера узла, перетащите связанный с ним лад.
Совет: Если вы хотите прямо с узла перейти к подробной схеме, в которую он входит, добавьте гиперссылки на узел, а затем привяжете ее на страницу схемы, содержаную подробную схему.
Нотации моделирования бизнес-процессов
Наиболее популярная нотация моделирования бизнес-процессов, основанная на методологии структурного анализа SADT. Методология IDEF0 — это методология моделирования, позволяющая создать функциональную модель, отображающую структуру и функции системы, а также потоки информации и материальных объектов, связывающие эти функции (на рисунке представлена графическая диаграмма в нотации IDEF0 — пример реализован в системе Business Studio, которая включает в себя функции программы для построения IDEF0). Бизнес-процессы в нотации IDEF0 представляются в форме прямоугольника, а стрелки отражают связь с другими процессами и внешней средой. Особенностью нотации является:
- Возможность декомпозировать процессы на подпроцессы и, таким образом, строить иерархические модели бизнес-процессов;
- Выделение четыре типов стрелок: три типа входов — вход, управление и механизм (это позволяет более гибко описывать логику использования входов в процессе в целях последующего анализа), и выход.
Нотация IDEF0 используется для создания верхнего уровня модели бизнес-процессов. Построение IDEF0-диаграммы верхнего уровня обеспечивает наиболее общее или абстрактное описание объекта моделирования. На нижнем уровне для описания алгоритма (сценария) выполнения процесса допустимо сменить стандарт IDEF0 на нотацию Процесс, Процедура, EPC или BPMN 2.0.
Подробнее о нотации IDEF0
С методологией SADT можно подробно ознакомиться в монографии Дэвида А. Марка и Клемента МакГоуэна «Методология структурного анализа и проектирования SADT».
Нотация Процесс (Basic Flowchart в Visio)
Данная нотация используется для представления алгоритма выполнения процесса (нотация класса workflow). Используются графические элементы: событие, процесс, решение, два типа стрелок — стрелки предшествования и стрелки «Поток объектов».
Нотация Процесс поддерживает декомпозицию на подпроцессы.
Нотацию Процесс можно применять для моделирования отдельных процессов компании, а также на нижнем уровне модели бизнес-процессов, созданной в нотации IDEF0.
Нотация Процедура (Cross-Functional Flowchart в Visio)
Данная нотация используется для представления алгоритма выполнения процесса (нотация класса workflow). Дополнительно к графическим элементам, применяемым в нотации Процесс, используются дорожки (Swim Lanes), обозначающие организационные единицы — исполнителей действий процесса.
Нотация Процедура поддерживает декомпозицию на подпроцессы.
Нотацию Процедура можно применять для моделирования отдельных процессов компании, а также на нижнем уровне модели бизнес-процессов, созданной в нотации IDEF0.
Нотация BPMN 2.0
Данная нотация используется для представления алгоритма выполнения процесса (нотация класса workflow). Особенностью нотации BPMN 2.0, появившейся в качестве стандарта моделирования в 2011 году, является то, что она предназначена как для моделирования бизнес-процессов, так и для их исполнения. Она доступна для понимания и удобна как бизнес-аналитикам, так и разработчикам, которые занимаются автоматизацией исполнения процессов. Для экспорта схемы процесса в BPMS-систему в Business Studio используется стандарт XPDL.
В Business Studio представлено 2 типа диаграмм BPMN 2.0 — диаграммы процессов и диаграммы взаимодействия процессов. Используются следующие графические элементы: процессы, события, шлюзы; 3 типа стрелок: поток управления, поток сообщений, ассоциации; объекты: документы, информация, сообщения, базы данных. Важно, что в Business Studio все элементы диаграмм BPMN являются объектами репозитория.
В Business Studio в нотации BPMN можно строить иерархическое дерево процессов, т.е. поддерживается декомпозиция.
Для процесса BPMN можно автоматически сформировать регламент и другие отчеты, эта нотация применяется преимущественно для описания процессов нижнего уровня, особенно со сложной логикой исполнения.
Нотация BPMN 2.0
Нотация EPC (Event-Driven Process Chain)
Данная нотация используется для представления алгоритма выполнения процесса (нотация класса workflow). Диаграмма, описанная в нотации EPC (событийная цепочка процессов), представляет собой упорядоченную комбинацию событий и функций. Для каждой функции могут быть определены начальные и конечные события, участники, исполнители, материальные и документальные потоки, сопровождающие её. В нотации EPC ветвление стрелок осуществляется с использованием операторов.
Нотация EPC поддерживает декомпозицию на более низкие уровни. Диаграмма декомпозируемой функции EPC может быть описана только в нотациях EPC или BPMN 2.0.
Нотацию EPC можно применять для моделирования отдельных процессов компании, а также на нижнем уровне модели бизнес-процессов, созданной в нотации IDEF0.
Почему я не люблю нотацию IDEF0
Уж не знаю почему, но меня всегда больше тянуло писать заметки про то, что мне не нравится, чем восторженные статьи о какой-то новой разработке. Сегодня под удар попал IDEF0. Я уже не один раз высказывал своё мнение о данной нотации, однако, постоянные вопросы от потенциальных покупателей Fox Manager, а так же опыт общения с консультантами заставляет возвращаться к этой теме вновь и вновь.
Я не хочу обсуждать общеизвестные факты, а также углубляться в историю создания нотации IDEF0, если вам интересно – почитайте данный материал из википедии. Сегодня я предлагаю сосредоточиться на сути самой методологии и нотации IDEF0.
Давайте начнём с самого главного вопроса, какие задачи можно решить при помощи моделирования бизнес-процессов? Большинство руководителей ответят, что хотели бы распределить ответственность за выполняемые работы между персоналом, устранить дублирование некоторых функций и зоны безответственности, сбалансировать загрузку персонала, уменьшить время адаптации новых сотрудников, избавится от «незаменимых» сотрудников и сделать систему управления более прозрачной.
Спешу вас разочаровать, нотация IDEF0 не сможет справиться с большинством описанных выше задач, хотя бы потому, что она позволяет отобразить лишь логические связи между работами, а не их временную последовательность. Таким образом, графическая схема позволит нам увидеть взаимодействие между нашими работами, но не ответит на вопросы, как именно выполняется та или иная задача и кто несёт ответственность за её выполнение. В силу данной особенности грамотные консультанты и специалисты по моделированию бизнес-процессов используют нотацию IDEF0 лишь для отображения верхнего уровня процессов, а затем декомпозируют схему на более нижний уровень, где строят процессы выполнения работ в какой-либо другой нотации.
Хорошо, допустим, IDEF0 не подходит для построения бизнес-процессов нижнего уровня, но ведь верхний уровень тоже нужно строить? На самом деле, не всё так очевидно. Действительно существует популярный метод построения бизнес-процессов «сверху вниз», который подразумевает поэтапное детализирование деятельности предприятия. Именно для построения таких укрупненных схем нам и предлагают воспользоваться нотацией IDEF0.
Итак, давайте разберёмся, какие же инструменты предоставляет нам данная нотация для моделирования. Схема процесса IDEF0 состоит из таких вот блоков:
- Под входом процесса (стрелка слева) понимают, как правило, необходимые данные (документ, информация, ТМЦ и т.д.) для выполнения процесса.
- Выход процесса (стрелка справа) – это то, что мы получим после выполнения данного процесса (документ, ТМЦ и т.д.
- Управление (стрелка сверху) – данные (регламент, приказ и т.д.), которые определяют, как необходимо выполнять данный процесс.
- Механизм (стрелка снизу) – то, что нам необходимо для выполнения процесса (например, инструмент или оборудование).
Стоит обратить внимание на то, что выходы одного процесса могут служить как входом для другого процесса, так, например, и управлением. Что ж, теперь мы знаем, как строить процессы верхнего уровня, давайте попробуем нарисовать схему. Необходимо заметить, что все диаграммы IDEF0 имеют один и тот же недостаток, а именно ограничение на количество блоков на одной диаграмме (обычно не более 8). Вы, конечно, можете проигнорировать данное ограничение, однако из-за особенности построения блок схемы, а именно размещения блоков по диагонали, вряд ли кто-то сможет разобрать диаграмму из более чем 10 элементов.
Итак, я попытался построить упрощенную схему работы своего предприятия в MS Visio, вот что у меня вышло:
Как видите, за короткое время невозможно построить схему достаточно красиво, но, тем не менее, основную суть она отражает. Что именно мы видим на этой схеме? Руководство компании формирует стратегию развития программы на основании пожеланий клиентов и информации о конкурирующих разработках, при этом формируется ценовая политика, техническое задание на разработку, а также планируется финансирование деятельности. Под предстоящие работы набирается персонал (в случае, если своих сотрудников не хватает). На основании ценовой политики осуществляются продажи программы, при помощи поискового продвижения сайта, часть полученных денег уходит на закупку необходимого ПО, и на оплату труда персонала. Ну и так далее…
Зачем я рассказываю такие очевидные вещи? Не знаю, а зачем вы их рисуете? Кому вообще нужна такая схема? Неужели без этой схемы вы не знали, что для разработки программного обеспечения нужен компьютер и персонал? На самом деле персонал нужен практически для любого процесса, однако, в такой паутине стрелочек схемы станут вовсе нечитаемые, поэтому их сознательно упрощают. Руководитель и так всё это знает, а персоналу знать это, во-первых не нужно, а во вторых, схемы в формате IDEF0 недостаточно подробны и не описывают, как именно осуществляется поисковое продвижение, кто за него отвечает, как взаимодействует команда программистов и т. д.
Кстати, если вы считаете, что я специальное извратил схему, то поищите в гугле примеры других диаграмм IDEF0.
Итак, какой же вывод? Мне кажется роль нотации IDEF0 в бизнес-моделировании сильно преувеличена. Я считаю, что имеет смысл строить диаграммы верхнего уровня только в том случае, если они будут отображать реальное взаимодействие между укрупненными процессами компании. Например, в системе Fox Manager мы генерируем такие схемы автоматически на базе данных и связей бизнес-процессов нижнего уровня. Построить всю процессную модель в нотации IDEF0 в принципе невозможно, а зачастую, для мелких и средних предприятий можно и вовсе обойтись без моделирования бизнес-процессов верхнего уровня.
Опубликовано в Бизнес моделирование
quality .eup.ru
Вероятно, самый старый в рунете сайт о менеджменте качества
Усилия — это не ответ. Стараться больше — неэффективно. Старайтесь умнее. (Джек Траут)
Проблемы описания бизнес-процессов в виде потоков работ (IDEF3, ARIS eEPC)
Обзор посвящен вопросам формирования моделей бизнес-процессов, используемых для регламентации и управления. Рассматривают проблемы, связанные с описанием бизнес-процессов в виде потоков работ ( Work flow ). При построении таких моделей особенно остро встает вопрос описания деятельности руководителя (владельца процесса).
Модели потоков работ ( ARIS eEPC , IDEF3, блок схемы в Visio ) предназначены для подробного описания операций (работ), выполняемых последовательно во времени по определенной технологии. Эти модели (нотации), особенно ARIS eEPC , активно используются в настоящее время на практике. Крупнейшие российские компании приобрели систему ARIS Toolset и занимаются описанием бизнес-процессов, в основном, в нотации eEPC . Другие компании ориентируются на IDEF 3 и систему BPWin . На практике возникает ряд проблем, связанных с применение указанных моделей, которые целесообразно разделить на две группы:
1) проблемы, связанные с отсутствием понимания сути процесса и процессного подхода и, как следствие, некорректная постановка задачи описания процессов с использованием потоковых диаграмм;
2) неумение эффективно использовать сами модели при описании бизнес-процессов.
Когда в организации бизнес-процесс понимается как плоская графическая схема, дело внедрения процессного подхода (описания, реорганизации и управления процессами), без сомнения, обречено на неудачу. В своей практике процессного консалтинга мы наблюдаем много таких примеров. В чем же основная проблема, как эффективно описывать и регламентировать бизнес-процесс, как отобразить в модели деятельность руководителей? В этом обзоре мы коснемся только одного аспекта, связанного с созданием моделей процессов, учитывающих деятельность руководителей. В последующих статьях будет подробно раскрыт комплексный подход к описанию, регламентации и управлению процессами.
Что значит фраза «описать бизнес-процесс», что кроется за этой краткой формулировкой? Прежде чем дать ответ на этот вопрос, отметим, что схемы процессов рассматриваются нами в качестве одного из необходимых элементов описания процессов, но далеко на самого важного. Для целей дальнейшего изложения сделаем несколько необходимых определений.
Бизнес-процесс — устойчивая, целенаправленная совокупность взаимосвязанных видов деятельности (последовательность работ), которая по определенной технологии преобразует входы в выходы, представляющие ценность для потребителя.
Владелец бизнес-процесса – должностное лицо, которое имеет в своем распоряжении персонал, инфраструктуру, программное и аппаратное обеспечение, информацию о бизнес-п роцессе, управляет ходом бизнес- процесса и несет ответственность за результаты и эффективность бизнес- процесса.
Вход бизнес- процесса – ресурс, необходимый для выполнения бизнес-процесса.
Выход бизнес- процесса – результат (продукт, услуга) выполнения бизнес-процесса.
Модель – графическое, табличное, текстовое, символьное описание бизнес-процесса либо их взаимосвязанная совокупность.
Поставщик — субъект, предоставляющий ресурсы.
Потребитель (клиент) – субъект, получающий результат бизнес-процесса. Потребитель может быть:
а) внутренний – то есть находящийся в организации и, в ходе своей деятельности, использующий результаты (выходы) предыдущего бизнес- процесса;
б) внешний – то есть находящийся за пределами организации и использующий или потребляющий результат деятельности (выход) организации.
Операция (работа) – часть бизнес-процесса.
Регламент бизнес-процесса – документ, описывающий последовательность операций, ответственность, порядок взаимодействия исполнителей и порядок принятия решений по улучшениям.
Ресурсы – информация (документы, файлы), финансы, материалы, персонал, оборудование, инфраструктура, среда, программное обеспечение, необходимые для выполнения бизнес-процесса.
Функция – направление деятельности элемента организационной структуры, представляющие собой совокупность однородных операций, выполняемых на постоянной основе.
IDEF 0 – – FIPS 183 США « Integration definition for function modeling ( IDEF 0)» – «Интеграционное определение для моделирования функций»
IDEF 3 – ( workflow modeling , Р rocess Description Capture Method ) методология описания бизнес-процессов (потоков работ).
Наше определение бизнес-процесса основано на определении, сформулированном в стандарте ISO -9001:2000. Мы считаем, что это наиболее адекватное, практически важное определение. Из него вытекают требования к описанию бизнес-процесса и подходы к его управлению. В нашем понимании описать бизнес-процесса означает:
1) определить владельца бизнес-процесса;
2) определить границы бизнес-процесса (границы ответственности и полномочий владельца процесса по управлению процессом);
3) определить клиентов и выходы бизнес-процесса;
4) определить поставщиков и входы бизнес-процесса;
5) определить ресурсы, необходимые для выполнения бизнес-процесса (- находятся в распоряжении владельца процесса);
6) описать технологию выполнения бизнес-процесса (например, с использованием графических схем в выбранных нотациях);
7) разработать показатели, по которым оценивается бизнес-процесс, его результаты и удовлетворенность клиентов бизнес-процесса;
8) описать работу владельца по анализу и улучшению бизнес-процесса, а так же его отчетность перед вышестоящим руководителем.
Управление бизнес-процессом осуществляется по определенным технологиям и с использованием определенных документов, в число которых входят: регламент выполнения бизнес-процесса, положение о подразделении, должностные и рабочие инструкции, методические документы по измерению показателей бизнес-процессов, отчетные формы, спецификации входов/выходов и т.д. (см. рисунок 1).
Рисунок 1. Документы, используемые при управлении бизнес-процессом.
Таким образом, задача регламентации и эффективного управления бизнес-процессом не сводится к разработке только графических схем процессов. Графические схемы (модели) бизнес-процессов являются только частью документации, как правило, несущей информацию по пошаговой технологии выполнения процесса. Важно понимать, что помимо разработки графических схем необходимо выполнить много другой, важной работы по описанию и регламентации процесса.
Обратимся собственно к графическим схемам или, другими словами, моделям бизнес-процессов. В настоящее время для целей описания бизнес-процессов часто используют схемы потоков работ ( Work Flow ): ARIS eEPC , IDEF 3, блок-схемы в Visio или MS Word . В основе указанных подходов лежит принцип построения бизнес-процесса в виде последовательно выполняемых во времени операций (работ), как показано на рисунке 2.
Рисунок 2. Пример схемы потока работ.
Модель потока работ состоит из операций (работ), символов логики , стрелок. Логические символы или, как их принято называть в IDEF 3, перекрестки представляют собой логическое «И», логическое «ИЛИ», исключающее «ИЛИ». Они служат для отображения ветвления и слияния процесса. Стрелки могут использоваться для отображения последовательности выполнения операций во времени или потока объектов (документы, ресурсы). В различных подходах (нотациях) в модели потока работ могут отображаться исполнители, документы, используемое оборудование, программные средства и т.д. Суть схем процессов от этого не изменяется – модели остаются плоскими и показывают поток работ, переходящий от одного рабочего места к другому.
При построении моделей потоков работ можно использовать декомпозицию, когда каждая операция описывается более подробно на отдельном листе в виде модели в той же (или другой) нотации. При проведении декомпозиции возникает ряд проблем с увязкой моделей на разных уровнях и моделей в рамках одного уровня. Так как они являются преимущественно техническими, то рассматриваться в нашем обзоре не будут.
Остановимся на следующем вопросе. Если мы хотим использовать схему бизнес-процесса для регламентации (например, в документе «Регламент выполнения бизнес-процесса»), то эта схема должна удовлетворять следующим требованиям:
1) все отображенные на схеме операции бизнес-процесса должны существовать реально и быть закрепленными за конкретными исполнителями;
2) на схеме должны отображаться реальные документы, файлы, ресурсы;
3) схема процесса должна быть проста и понятна для визуального восприятия;
4) схема процесса должна иметь компактный размер.
Эти требования означают, что строить потоковую диаграмму имеет смысл при описании операций уровня рабочего места исполнителя, в крайнем случае – для –операций небольшого (3-4 человека) подразделения. На более крупном уровне модели потоков работ могут дать общую информацию о процессе, но использовать такие модели для регламентации затруднительно вследствие размывания ответственности между исполнителями процесса.
Если мы описываем бизнес-процесс на детальном уровне, то на выходе этой работы получаем схемы, содержащие поток операций и их исполнителей. Именно при формировании таких моделей и возникает важнейшая, на наш взгляд, проблема: из рассмотрения полностью исключаются руководители. Возникает следующая ситуация. Группа аналитиков (или внутренних экспертов) приходит в подразделение, получает разрешение руководителя, начинает работать с исполнителями процесса, переходя от одного рабочего места к другому в соответствии с ходом движения бизнес-процесса.
Формируется модель бизнес-процесса, включающая операции всех рядовых исполнителей, но лишенная даже намека на руководителей, владельцев бизнес-процесса. Кроме того, такие модели чаще всего описывают нормальный ход бизнес-процесса. Возможные отклонения очень часто остаются вне рассмотрения. Так же часто опускают такие важные моменты, как: действия при получении не соответствующих входов (например, документ из соседнего подразделения), получение несоответствующих требованиям выходов (брак, недоработка), регистрацию параметров процесса (измерения), контроль и т.д. Нужен ли такой результат работы руководителю? Ответ очевиден. Полученные схемы бизнес-процесса являются плоскими, неполными, не могут эффективно использоваться для внедрения системы процессного управления. Тем не менее, многие компании, особенно крупные, выполняют отдельные проекты по созданию внутренних стандартов моделирования «плоских» бизнес-процессов, «создания баз знаний компании по бизнес-процессам» и т.п. В итоге, полученные «горы» четко структурированной, но «однобокой», неполной информации оказываются практически бесполезными для целей реального управления.
На рисунке 3 показан «объемный» бизнес-процесс. Он состоит из нескольких моделей потоков работ, сформированных для каждого уровня: исполнители, зам. руководителя, руководитель (владелец) бизнес-процесса
Рисунок 3. «Объемный бизнес-процесс».
На рисунке 3 видно, что руководитель и его заместитель активно участвуют в процессе. Существует постоянный, цикличный поток информации по ходу процесса от исполнителей — вверх, и управленческих решений от руководителей — вниз. Даже если (в предельном случае) мы полностью делегируем все права на принятие управленческих решений по процессу исполнителям, у руководителя останется ключевая функция – анализ эффективности бизнес-процесса и его улучшение с ориентиром на стратегические цели компании (если таковые имеются). Улучшение процесса руководитель осуществляет за счет управления ресурсами: персонал, финансы, материалы, оборудование, программное обеспечение, информация и т.д.
Каким же образом увязать деятельность руководителей и исполнителей при построении моделей потоков работ ( ARIS eEPC , IDEF 3)? Очевидно, что сделать это можно несколькими способами. Первый и самый простой способ состоит в следующем: отдельно описываются потоки работ, выполняемых как руководителями, так и исполнителями. Такой простейший подход имеет несколько недостатков, основной их которых состоит в том, что взаимодействие руководителя и исполнителя становится в модели неявным, а опосредованным при помощи обратных связей по информации. Другой способ состоит в том, что при описании работ исполнителей можно указать прямые ссылки на процессы, выполняемые руководителями, или прямо отобразить их вмешательство в работу. Сказанное иллюстрирует рисунок 4.
Рисунок 4. От «плоского» процесса к «объемному».
На рисунке 4, вверху показана простейшая цепочка бизнес-процесса, состоящая из двух операций. Представим себе, что эти операции выполняются исполнителем и требуют управления со стороны руководителя. Как мы можем отобразить этот факт на модели? Согласно первому предложенному выше способу, мы указываем на модели процесса обратную связь по информации. В данном примере, нотация ARIS eEPC позволяет показать входящий и исходящий документ А, содержащий некоторую информацию. Документ А попадает от исполнителя руководителю после выполнения функции 2, и затем может быть возвращен на доработку при выполнении функции 1. При этом, «где-то в другом месте» мы должны описать работу руководителя по проверке этого документа и принятию решения. Это означает, что мы должны создать модель, описывающую деятельность руководителя.
На рисунке 4 приводится еще два способа «встраивания» руководителя в бизнес-процесс. Первый из них предполагает прямое включение в процесс «Функции управления», второй – в виде дополнительного события «Принято управленческое решение».
Какой способ для отображения участия руководителя в бизнес-процессе выбрать? Это определяет сама организация. Можно составить схему бизнес-процесса уровня исполнителей, а деятельность руководителя расписать в виде подробной таблицы с указанием операций, входящих и исходящих документов, принимаемых решений. Можно сформировать схемы процесса для работы самого руководителя. Можно пытаться отобразить участие руководителя на одной плоской схеме, увеличивая количество возможных ветвлений и слияний процесса. Мы считаем, что нужно выбирать тот способ, который наилучшим образом подходит для последующей регламентации и управления бизнес-процессом. Моделируя, главное не забыть про руководителя, поскольку именно он отвечает за управление и улучшение бизнес-процесса и, в конечном счете, модели бизнес-процессов создаются именно для него.