Проблемы реинжиниринга бизнес-процессов
Введение
Бизнес-процесс.
В последнее время такие термины, как «бизнес-процесс», «реинжиниринг бизнес-процессов», и т.п., постоянно находятся на слуху. И, к сожалению, не всегда к месту. Поэтому прежде всего хотелось бы разобраться с терминологией. Эти понятия можно попробовать разобрать по составляющим их словам.
Итак, что же такое процесс? Откроем любой толковый словарь и прочтем, что процесс (от лат. processus - продвижение) – это совокупность последовательных действий для достижения какого-либо результата.
А что такое бизнес? Бизнес - предпринимательская деятельность, осуществляемая за счет собственных или заемных средств на свой риск и под свою ответственность, ставящая главными целями получение прибыли и развитие собственного дела.
Когда мы говорим о бизнес-процессах, то подразумеваем процессы, происходящие в организации или на предприятии в ходе осуществления предпринимательской деятельности.
Деятельность любой организации можно классифицировать по двум признакам: повторяющаяся-уникальная деятельность, и простая-сложная деятельность. Повторяющаяся деятельность выполняется регулярно, уникальная – единовременно. Простой деятельностью назовем такую, которую выполняет один человек в течение непродолжительного времени, а сложной – такую деятельность, которой занимается несколько человек в течение длительного отрезка времени. Тогда классификацию видов деятельности можно представить следующим образом.
Таким образом, исходя из этой схемы, бизнес-процесс – это повторяющийся, последовательный, взаимоувязанный набор мероприятий (операций, действий), который потребляет некие ресурсы, создает некую ценность и выдает результат потребителю.
Причем сразу стоит отметить, что потребитель может быть как внешним, так и внутренним по отношению к организации. Внешний потребитель – это потребитель, который не входит в состав данной организации, а внутренний – тот потребитель, который находится в рамках данной организации.
Если мы рассматриваем в качестве примера предприятие, производящее шины, то производство шин – это бизнес-процесс, причем основной для данного предприятия. Почему? Потому что полностью соответствует данному выше определению. Производство шин (как процесс) включает в себя множество взаимоувязанных операций, потребляет определенные ресурсы (сырье и материалы, электроэнергию, труд персонала и т.п.) и выдает определенный результат – готовую шину потребителю. Потребителем для этого процесса будет одна или несколько оптовых торговых фирм, которые организуют распределение товара до конечных потребителей.
Другой пример бизнес-процесса – закупка сырья для производства тех же шин. Такой процесс также соответствует данному выше определению, но потребитель конечного результата процесса будет внутренним – это производственные цеха предприятия, в которых готовят резиновую смесь, обрезинивают металлокорд и т.д.
Итак, с внешними и внутренними потребителями результатов бизнес-процессов разобрались. А как можно классифицировать бизнес-процессы?
Бизнес-процессы разделяются на следующие классы:
· Основные процессы;
· Сопутствующие процессы;
· Вспомогательные процессы;
· Обеспечивающие процессы;
· Процессы управления;
· Процессы развития.
Основными бизнес-процессами являются процессы, ориентированные на производство товара или оказание услуги, являющиеся целевыми объектами создания предприятия и обеспечивающие получение дохода. Так, для завода ДСП и Д основным бизнес процессом является производство ламинированной древесно-стружечной плиты.
Сопутствующие процессы – процессы, ориентированные на производство товара или оказание услуги, являющиеся результатами сопутствующей основному производству производственной деятельности и также обеспечивающие получение дохода. Так, для автотранспортного предприятия процесс ремонта стороннего транспорта на собственной ремонтной базе является сопутствующим процессом.
Вспомогательные бизнес-процессы – процессы, предназначенные для обеспечения выполнения основных БП и поддержания их специфических черт. Так, для ТЭЦ или ГЭС вспомогательным бизнес-процессом является процесс ремонта производственного оборудования.
Обеспечивающие бизнес-процессы – процессы, предназначенные для жизнеобеспечения всех остальных бизнес-процессов и ориентированные на поддержку их универсальных черт. На предприятиях любой отрасли это процесс финансового обеспечения деятельности, процесс кадрового обеспечения, IT обеспечения и т.п.
Бизнес-процессы управления – это процессы, охватывающие весь комплекс функций управления на уровне каждого БП и бизнес-системы в целом. Это процессы стратегического, оперативного и текущего планирования, формирования и осуществления управленческих воздействий.
Бизнес-процессы развития – это процессы совершенствования производимого товара или услуги, технологий, модификации оборудования. Например, это проведение НИОКР в машиностроении, процесс технического перевооружения в электроэнергетике и т.п.
Логично задаться вопросом: существуют ли типовые бизнес-процессы, и если да, то какие они? И ответ будет – нет. Каждая организация имеет свою специфику деятельности, свою продукцию и услуги, взаимодействует с определенным набором поставщиков и покупателей, действует на определенной территории, в определенном правовом поле и т.п. Поэтому говорить об типовых бизнес-процессах нельзя. На любой набор типовых бизнес-процессов можно привести контрпример, показывающий, что такой типовой набор будет неприменим к какому либо определенному предприятию.
С другой стороны (и многие консультанты по реинжинирингу бизнес-процессов об этом знают), можно говорить об определенном типовом наборе бизнес-процессов применительно к определенной отрасли, в определенном регионе, в определенном временном промежутке. Причем все равно конкретная реализация бизнес-процессов будет несколько отличаться от типового набора.
Говоря о бизнес-процессах, следует обязательно отметить весьма важный момент. Бизнес-процесс, как совокупность последовательного набора процедур и операций, может быть представлен как иерархическое дерево подпроцессов. Каждая из операций в процессе представляет собой также определенную последовательность действий, и так далее. Глубина (количество уровней) бизнес-процессов определяется только целью исследования и точкой зрения исследователя. Поэтому часто в специальной литературе бизнес-процессом называют и процесс более низкого уровня, который с точки зрения «родительского» БП является лишь операцией в нем. И это не ошибка, а действительно взгляд исследователя, имеющий полное право на существование.
Методологии
Реинжиниринг бизнес-процессов - методология, разработанная для проведения усовершенствования бизнес-процессов организации, а также сам процесс проведения такого усовершенствования.
Формально термин «реинжиниринг» определен Хаммером, Давенпортом и Шортом в двух статьях в 1990 году. Термин получил широкую известность в 1993 году после публикации книги Хаммера и Чампи «Реинжиниринг корпораций – манифест революции в бизнесе».
Фактически же реинжиниринг использовался задолго до этого, в том числе и в Советском союзе, но не осознавался как таковой, и имел отличные от современных формы своего осуществления.
В специальной литераторе до сих пор существует некоторая путаница в терминологии. Одни говорят о реинжиниринге БП, другие – об оптимизации БП, третьи – об их улучшении, понимая под этим примерно одно и то же. Следует внести некоторую ясность. Под реинжинирингом в «узком» смысле мы будем понимать революционное изменение БП организации, направленное на глобальные улучшения. Под усовершенствованием будем понимать эволюционный процесс постепенных локальных улучшений в БП. Но в обоих случаях речь идет о преобразовании бизнес-процессов организации с целью их улучшения. Поэтому, применяя термин «реорганизация» либо «реинжиниринг» в его широком смысле, будем говорить о процессе преобразования БП вне зависимости от подхода, который мы к такому преобразованию применяем.
Управление бизнес-процессами - BPMS (Business Process Management System) – система управления бизнес-процессами. Используются также термины BPM-система и просто BPM.
BPM предлагает следующее решение - описать бизнес-процессы на языке, который может исполняться специализированной программой.
Рассмотрим чуть подробнее отличия реинжиниринга от усовершенствования с точки зрения их характеристик, сведенные в таблицу.
| Реинжиниринг |
| · Редко повторяющаяся операция |
| · Фундаментальные, качественные улучшения |
| · Глобальные улучшения |
| · Революционный процесс |
| Усовершенствование |
| · Постоянный процесс |
| · Небольшие количественные улучшения |
| · Локальные улучшения |
| · Эволюционный процесс |
Определения системного анализа.
Как мы видим, такой подход очень похож на решение задач в области системного анализа. Более того, так оно и есть. Проблема оптимизации бизнес-процессов решается с использованием методологии системного анализа.
Необходимо напомнить некоторые определения из этой области знаний.
Система - совокупность взаимосвязанных элементов, отграниченная от внешней среды, функционирующая для достижения определенной цели, и обладающая свойством интегративности. Свойство интегративности заключается в том, что каждый элемент системы по отдельности не способен достигнуть цели функционирования системы, но только система в целом.
Иерархическая система - система, элементы которой являются системами (системы низшего ранга).
Декомпозиция- это разбиение сложного объекта (системы) на составляющие, свойства и функции которых объяснить проще.
Цель - желаемое состояние системы или желаемый результат ее поведения. Цель может быть сформулирована только с точки зрения вышестоящей системы.
Дерево целей- графическая схема, показывающая разбивку общих целей на подцели, последних - на подцели следующего уровня и т.д.
Цели низшей системы в условиях дефицита ресурсов обычно не совпадают с целями высшей системы - конфликт целей систем разного ранга.
Критерий - количественная или качественная характеристика состояния системы, позволяющая оценить степень достижения цели и сформулировать решающие правила выбора средств (способов, технологий) достижения цели.
Анализ - логический прием, метод исследования, состоящий в том, что изучаемый объект мысленно (или практически) расчленяется на составные элементы (признаки, свойства, отношения), каждый из которых исследуется в отдельности как часть расчлененного целого.
Синтез - логический прием, с помощью которого отдельные элементы соединяются в целое
Разнообразие системы - количество возможных её состояний.
Сложная система - система, разнообразие которой велико, но ещё позволяет описать её детерминированной моделью.
Большая система - система, разнообразие которой позволяет использовать уже только вероятностные модели в силу неопределенного состояния элементов (в составе системы рассматриваются люди).
Все это было бы отвлеченной теорией, если бы не тот факт, что предприятие и совокупность его бизнес-процессов является системой. И только рассматривая предприятие как систему, можно достичь хороших результатов при реорганизации его бизнес-процессов.
Критерии
Для того, чтобы оценить достижение результатов проведения реинжиниринга, необходимо каждой из задач и подзадач реорганизации поставить в соответствие определенный количественный либо качественный критерий, который бы позволил оценить степень достижения результата.
Однако на практике это сделать бывает весьма затруднительно. Далеко не всегда мы сможем выбрать релевантный критерий достижения той или иной задачи, если речь идет о социальной системе, каковой является организация. И даже выбрав критерий, мы далеко не всегда сможем достоверно его измерить, тем более - спрогнозировать. Поэтому вопрос о выборе критериев остается открытым.
Многие задаются вполне закономерным вопросом: а какой эффект получит организация от проведения реорганизации своих бизнес-процессов? Спрогнозировать такой эффект на практике бывает довольно затруднительно. Можно воспользоваться сравнительным анализом: рассмотреть аналогичный проект на предприятии той же отрасли, соразмерить его со своим проектом и сделать выводы о полученном эффекте. Но не всегда такой вариант бывет возможен по вполне понятным причинам. Второй вариант: еще на этапе создания технического задания попытаться установить контрольные показатели, которых желательно достигнуть. Таким образом, будет от чего отталкиваться при оценке эффективности проекта. Наконец, можно использовать экспертные оценки независимых специалистов.
Методы обследования
Методы обследования, то есть способ получения необходимых данных, определяется целями и задачами изучения бизнес-процессов и системы управления предприятием. В зависимости от объекта исследования выделяют следующие методы обследования:
· Процедурно-ориентированный метод – объектом исследования являются процедуры обработки информации.
· Предметно-ориентированный метод изучает элементы информации на предприятии.
· Метод анализа по структурным элементам системы управления изучает структуру подразделений и функции, выполняемые ими по управлению финансово-хозяйственной деятельностью.
· Метод анализа выходов изучает зависимость управленческих решений от начальных условий.
· Метод реакций на воздействие изучает реакцию системы на какие-либо воздействия.
В ходе практического проведения обследования бизнес-процессов предприятия применяются, как правило, все эти методы в комплексе.
Анкетирование.
Анкетирование представляет собой сбор информации посредством заполнения специально разработанных для этого форм документов со структурированными вопросами. Ответы на данные вопросы должны содержать сведения, которые и необходимо получить в ходе обследования. Анкеты могут заполняться либо бизнес-аналитиком со слов должностного лица предприятия, компетентного в данных вопросах, либо непосредственно должностным лицом предприятия, и затем передаваться бизнес-аналитику для изучения. Во втором случае рекомендуется приложить к анкете инструкцию по ее заполнению. Это необходимо для того, чтобы избежать неверного толкования вопросов анкеты и достичь высокой точности ее заполнения. Кроме того, настоятельно рекомендуется заверять анкету подписью лица, его заполняющего. Это необходимо для того, чтобы избежать в будущем каких-либо проблем, связанных с отказом от предоставленной информации.
Анкета должна быть составлена таким образом, чтобы ее заполнение заняло не более 1 часа у анкетируемого лица, в противном случае внимание рассеивается и человек отвечает на вопросы анкеты по принципу «лишь бы отписаться», либо вообще игнорирует многие вопросы. Вопросы анкеты должны быть таковы, чтобы:
· Вопросы соответствовали цели получения необходимой и достаточной информации. При этом вопросы не должны нарушать общепринятую этику и условия конфиденциальности;
· Вопрос был однозначно понятен анкетируемому лицу, и находиться в сфере его профессиональной компетенции;
· Предполагаемый ответ на вопрос был кратким по объему, но достаточно полным по содержанию;
· По возможности, в зависимости от специфики вопроса, следует предлагать выбрать один или несколько заранее подготовленных вариантов ответа.
Как правило, анкетирование используется при получении общих представлений о деятельности предприятия в целом, и его подразделений в отдельности. Для более глубокого изучения необходимо использование иных методов.
Интервьюирование
Интервьюирование представляет собой опрос бизнес-аналитиком должностного лица предприятия в личной беседе. Интервью следует назначать заранее на удобное для интервьюируемого время. Рекомендуется проводить интервью продолжительностью не более часа. Интервью, как правило, проводят либо в форме относительно свободной беседы, либо в форме структурированного опроса. И в том, и в другом случае вопросы для интервью следует подготовить заранее. Ответы фиксируются либо письменно, либо на диктофон. Последнее удобнее, но требует больше времени на расшифровку записи.
Прежде чем начинать интервью, бизнес-аналитик должен представиться и коротко охарактеризовать цель беседы. Очень важно уметь расположить к себе собеседника, потому что в противном случае
Типичными ошибками являются:
· Переход беседы на темы, не относящиеся к цели опроса;
· Навязывание собственных вариантов ответа собеседнику;
· «Жонглирование терминами» и иная демонстрация собственных познаний бизнес-аналитика, вместо того, чтобы внимательно слушать собеседника.
В некоторых случаях анкетирование и интервьюирование совмещаются, то есть бизнес-аналитик самостоятельно заполняет заранее подготовленную анкету со слов интервьюируемого, и по ходу заполнения задает уточняющие дополнительные вопросы.
Сбор документов
Сбор документов – это весьма важный, хотя и не самый главный метод сбора данных о бизнес-процессах. Бизнес-процессы, так или иначе, связаны с передачей и обработкой информации, которая представлена, как правило, в виде документов. Таким образом, заполненные формы документов представляют большую ценность для иллюстрации того, как реально протекают бизнес-процессы на предприятии. В частности, по наличию подписей должностных лиц на документе можно представить и маршрут документа, и разграничение полномочий на предприятии. Кроме того, по заполнению полей документа можно понять, какие данные фиксируются и измеряются, а какие нет. Так, например, в стандартной форме путевого листа присутствует более сотни полей данных, однако, реально заполняется только около двадцати из них.
В некоторых случаях опытный аналитик по одним только образцам документов может восстановить реальный бизнес-процесс, но все же эффективнее использовать сбор документов в сочетании с интервьюированием и анкетированием.
Наблюдение
Наблюдение представляет собой непосредственное присутствие бизнес-аналитика на рабочем месте сотрудников подразделений с регистрацией событий и действий, происходящих в ходе рабочего дня. Сведения о действиях заносятся в специальную учетную форму для дальнейшей обработки и анализа. Наблюдение является весьма трудоемким процессом, поэтому на практике применяется не очень часто.
К достоинствам этого метода относится то, именно он дает наиболее полное представление о деятельности подразделений предприятия. Однако при проведении наблюдения непродолжительное время есть вероятность того, что под наблюдение попадет только небольшая часть функций и процедур, совершаемых в подразделении. При длительном же проведении наблюдения, как уже было сказано выше, существенно возрастает трудоемкость такой процедуры. Кроме того, зачастую исполнитель может работать с отличающейся от обычной интенсивностью, для того, чтобы было отмечено его трудовое рвение.
Поэтому наблюдение, являясь мощным инструментом сбора информации, применяется реже, чем предыдущие три метода.
IDEF
Стандарт моделирования бизнес-процессов IDEF0 был принят в качестве такового в 1981 году. Исторически он возник из стандарта SADT (Structured Analysis and Design Teqnique), активно применявшегося с конца 60-х годов, в частности, Министерством обороны США. IDEF является аббревиатурой от ICAM DEFinition. ICAM - Integrated Computer Aided Manufacturing.
Семейство стандартов IDEF включает в себя ряд графических нотаций, которые могут быть использованы для моделирования бизнес-процессов:
· IDEF0 – стандарт описания бизнес-процессов;
· DFD – диаграмма потока данных (DataFlow Diagram);
· IDEF3 – стандарт моделирования потока работ (workflow).
ARIS
ARIS расшифровывается как Arhitecture of Integrated Information Systems (архитектура интегрированных информационных систем). В методологию ARIS входит пять типов представлений моделей:
· Организационные модели, описывающие иерархическую структуру системы: иерархию организационных подразделений, должностей, полномочий конкретных лиц и т.д.;
· Функциональные модели, описывающие функции (процессы, операции), выполняемые в организации;
· Информационные модели (модели данных), отражающие структуру информации, необходимой для реализации всей совокупности функций системы;
· Модели процессов/управления, представляющие комплексный взгляд на реализацию деловых процессов в рамках системы и объединяющие вместе другие модели;
· Модели входов и выходов, описывающие потоки материальных и нематериальных входов и выходов процедур, включая, в частности, потоки денежных средств.
В каждом из этих типов моделей есть ряд нотаций, отличающихся методами моделирования, и число этих нотаций довольно велико. В частности, ARIS Toolset поддерживает ряд нотаций языка моделирования UML (Unified Modeling Language).
Число поддерживаемых ARIS нотаций довольно велико, и описывать каждую из них не целесообразно. Имеет смысл дать основы нотации eEPC, как наиболее, на наш взгляд, применимой для моделирования бизнес-процессов.
Нотация ARIS eEPC расшифровывается следующим образом: Extended Event Driven Process Chain – расширенная нотация описания цепочки процесса, управляемого событиями. Нотация разработана специалистами компании IDS Scheer AG (Германия), в частности профессором Шеером. В таблице ниже приводятся основные используемые в рамках нотации графические объекты.
| Наименование | Описание | Графическое представление |
| Функция | Объект «Функция» служит для описания функций (процедур, работ), выполняемых подразделениями/сотрудниками предприятия. |  |
| Событие | Объект «Событие» служит для описания реальных состояний системы, влияющих и управляющих выполнением функций |  |
| Организационная единица | Объект, отражающий различные организационные звенья предприятия (например, управление или отдел) |  |
| Документ | Объект, отражающий реальные носители информации, например бумажный документ |  |
| Прикладная система | Объект отражает реальную прикладную систему, используемую в рамках технологии выполнения функции |  |
| Кластер информации | Объект характеризует данные, как набор сущностей и связей между ними. Используется для создания моделей данных |  |
| Стрелка связи между объектами | Объект описывает тип отношений между другими объектами, например – активацию выполнения функции некоторым событием |  |
| Логическое «И» | Логический оператор, определяющий связи между событиями и функциями в рамках процесса. Позволяет описать ветвление процесса |  |
| Логическое «ИЛИ» | Логический оператор, определяющий связи между событиями и функциями в рамках процесса. Позволяет описать ветвление процесса |  |
| Логическое исключающее «ИЛИ» | Логический оператор, определяющий связи между событиями и функциями в рамках процесса. Позволяет описать ветвление процесса |  |
В таблице указаны только основные виды пиктограмм, применяемые в данной нотации. Использование большего числа элементов допустимо, но делает модель плохо читаемой.
На рисунке представлена простейшая модель eEPC, описывающая фрагмент бизнес-процесса предприятия.
На рисунке видно, что связи между объектами имеют определенный смысл и отражают последовательность выполнения функций в рамках процесса. Стрелка, соединяющая Событие 1 и Функцию 1 «активирует» или инициирует выполнение Функции 1. Функция 1 «создает» Событие 2, за которым следует символ логического «И», «запускающий» выполнение Функций 2 и 3. Нотация eEPC построена на определенных семантических правилах описания:
· Каждая функция должна быть инициирована событием и должна завершаться событием;
· В каждую функцию не может входить более одной стрелки, «запускающей» выполнение функции, и выходить не более одной стрелки, описывающей завершение выполнения функции.
Кроме этих правил, существуют и другие важные правила формирования моделей в ARIS. Эти правила можно изучить при помощи методического материала «Методы ARIS», который устанавливается на компьютер одновременно с демо-версией продукта.
На рисунке ниже показано применение различных объектов ARIS при создании модели бизнес-процесса.
Каждый объект в системе ARIS Toolset, которая поддерживает метод описания бизнес-процессов ARIS, имеет определенный набор атрибутов. Пользователю предлагается воспользоваться стандартными атрибутами для описания объектов или ограниченным количество т.н. пользовательских атрибутов.
Из рисунка видно, что бизнес-процесс в нотации eEPC представляет собой последовательность процедур, расположенных в порядке их выполнения. Следует отметить, что реальная длительность выполнения процедур в eEPC визуально отражена быть не может. Это приводит к тому, что при создании моделей возможны ситуации, когда на одного исполнителя будет возложено выполнение двух задач одновременно. Используемые при построении модели символы логики позволяют отразить ветвление и слияние бизнес-процесса. Для получения информации о реальной длительности процессов необходимо использовать другие инструменты описания, например графики Ганта в системе MS Project.
Таким образом, при помощи нотации eEPC ARIS можно описывать бизнес-процесс в виде потока последовательно выполняемых работ (процедур, функций).
UML
Аббревиатура UML расшифровывается как Unified Modeling Language (унифицированный язык моделирования).
UML предназначен в первую очередь для быстрого проектирования и разработки программных продуктов, и описание бизнес-процессов с его использованием целесообразно делать, если в конечном итоге требуется разработать корпоративную информационную систему, которая бы отражала особенности протекания бизнес-процессов на предприятии заказчика.
Язык UML был создан в компании Rational одним из ведущих идеологов объектно - ориентированного подхода к программированию Гради Бучем (Grady Booch), совместно с Джимом Рамбо (Jim Rumbaugh) и Иваром Джекобсоном (lvar Jacobson) в 1994 году.
UML включает в себя ряд типов диаграмм, некоторые из которых могут быть использованы для моделирования бизнес-процессов. В частности, это диаграмма прецедентов (Use-case diagram) и диаграмма действий (Activity Diagram).
Диаграмма прецедентов служит для моделирования типичных сценариев работы с системой.
Диаграмма прецедентов состоит из прецедентов (use-case) - типичных взаимодействий между пользователем и компьютерной системой - и субъектов (actor) - ролей, которые пользователи играют относительно системы. Также на ней могут быть указаны отношения между прецедентами: связь расширения (extends) и связь использования (uses).
Диаграмма действий имеет много общего с блок-схемой, но на ней можно также показывать параллельные процессы. Диаграмма состоит из действий, - некоторых задач, которые должны быть выполнены человеком или компьютером - условных и безусловных переходов, и распараллеливания.
Выбор нотации моделирования
Среди специалистов в области моделирования бизнес-процессов часто возникают споры – какую методологию лучше использовать для создания моделей? Каждая из этих методологий имеет свои достоинства и недостатки, какие-то моменты удобнее и эффективнее отражать в той или иной нотации. Однако на наш взгляд однозначного ответа на этот вопрос нет. Выбор той или иной методологии зависит в первую очередь от целей и задач проекта реинжиниринга БП. При этом надо учитывать также степень владения командой аналитиков той или иной методологией, наличие соответствующего ПО, да и просто личные предпочтения руководства проекта.
В любом случае важно, чтобы каждый специалист понимал основные принципы каждой из методологий и умел читать диаграммы, подготовленные с ее использованием.
IDEF0.
В основе методологии IDEF0 лежат три основных понятия:
· Функциональный блок (Activity Box);
· Интерфейсная дуга (Arrow);
· Декомпозиция (Decomposition);
Функциональный блок графически изображается в виде прямоугольника (см. рис.) и олицетворяет собой некоторую конкретную функцию в рамках рассматриваемой системы. По требованиям стандарта название каждого функционального блока должно быть сформулировано в глагольном наклонении (например, “производить услуги”, а не “производство услуг”).
Каждая из четырех сторон функционального блока имеет своё определенное значение (роль), при этом:
· Верхняя сторона имеет значение “Управление” (Control);
· Левая сторона имеет значение “Вход” (Input);
· Правая сторона имеет значение “Выход” (Output);
· Нижняя сторона имеет значение “Механизм” (Mechanism).
Каждый функциональный блок в рамках единой рассматриваемой системы должен иметь свой уникальный идентификационный номер.
Интерфейсная дуга – второе важное понятие методологии IDEF0. Также интерфейсные дуги часто называют потоками или стрелками. Интерфейсная дуга отображает элемент системы, который обрабатывается функциональным блоком или оказывает иное влияние на функцию, отображенную данным функциональным блоком.
Графическим отображением интерфейсной дуги является однонаправленная стрелка. Каждая интерфейсная дуга должна иметь свое уникальное наименование (Arrow Label). По требованию стандарта, наименование должно быть оборотом существительного.
С помощью интерфейсных дуг отображают различные объекты, в той или иной степени определяющие процессы, происходящие в системе. Такими объектами могут быть элементы реального мира (детали, вагоны, сотрудники и т.д.) или потоки данных и информации (документы, данные, инструкции и т.д.).
В зависимости от того, к какой из сторон подходит данная интерфейсная дуга, она носит название “входящей”, “исходящей” или “управляющей”. Кроме того, “источником” (началом) и “приемником” (концом) каждой функциональной дуги могут быть только функциональные блоки, при этом “источником” может быть только выходная сторона блока, а “приемником” любая из трех оставшихся.
Необходимо отметить, что любой функциональный блок по требованиям стандарта должен иметь по крайней мере одну управляющую интерфейсную дугу и одну исходящую. Это и понятно – каждый процесс должен происходить по каким-то правилам (отображаемым управляющей дугой) и должен выдавать некоторый результат (выходящая дуга), иначе его рассмотрение не имеет никакого смысла.
При построении IDEF0 – диаграмм важно правильно отделять входящие интерфейсные дуги от управляющих, что часто бывает непросто. К примеру, на рисунке ниже изображен функциональный блок “Обработать заготовку”.
В реальном процессе рабочему, производящему обработку, выдают заготовку и технологические указания по обработке (или правила техники безопасности при работе со станком). Ошибочно может показаться, что и заготовка и документ с технологическими указаниями являются входящими объектами, однако это не так. На самом деле в этом процессе заготовка обрабатывается по правилам отраженным в технологических указаниях, которые должны соответственно изображаться управляющей интерфейсной дугой.
Другое дело, когда технологические указания обрабатываются главным технологом и в них вносятся изменения (рис. 3). В этом случае они отображаются уже входящей интерфейсной дугой, а управляющим объектом являются, например, новые промышленные стандарты, исходя из которых производятся данные изменения.
Приведенные выше примеры подчеркивают внешне схожую природу входящих и управляющих интерфейсных дуг, однако для систем одного класса всегда есть определенные разграничения. Например, в случае рассмотрения предприятий и организаций существуют пять основных видов объектов: материальные потоки (детали, товары, сырье и т.д.), финансовые потоки (наличные и безналичные, инвестиции и т.д.), потоки документов (коммерческие, финансовые и организационные документы), потоки информации (информация, данные о намерениях, устные распоряжения и т.д.) и ресурсы (сотрудники, станки, машины и т.д.). При этом в различных случаях входящими и исходящими интерфейсными дугами могут отображаться все виды объектов, управляющими только относящиеся к потокам документов и информации, а дугами-механизмами только ресурсы.
Обязательное наличие управляющих интерфейсных дуг является одним из главных отличий стандарта IDEF0 от других методологий классов DFD (Data Flow Diagram) и WFD (Work Flow Diagram).
Часто бывают случаи, когда отдельные интерфейсные дуги не имеет смысла продолжать рассматривать в дочерних диаграммах ниже какого-то определенного уровня в иерархии, или наоборот - отдельные дуги не имеют практического смысла выше какого-то уровня. Например, интерфейсную дугу, изображающую “деталь” на входе в функциональный блок “Обработать на токарном станке” не имеет смысла отражать на диаграммах более высоких уровней – это будет только перегружать диаграммы и делать их сложными для восприятия. С другой стороны, случается необходимость избавиться от отдельных “концептуальных” интерфейсных дуг и не детализировать их глубже некоторого уровня. Для решения подобных задач в стандарте IDEF0 предусмотрено понятие туннелирования. Обозначение “туннеля” (Arrow Tunnel) в виде двух круглых скобок вокруг начала интерфейсной дуги обозначает, что эта дуга не была унаследована от функционального родительского блока и появилась (из “туннеля”) только на этой диаграмме. В свою очередь, такое же обозначение вокруг конца (стрелки) интерфейсной дуги в непосредственной близи от блока – приёмника означает тот факт, что в дочерней по отношению к этому блоку диаграмме эта дуга отображаться и рассматриваться не будет. Чаще всего бывает, что отдельные объекты и соответствующие им интерфейсные дуги не рассматриваются на некоторых промежуточных уровнях иерархии – в таком случае, они сначала “погружаются в туннель”, а затем, при необходимости “возвращаются из туннеля”.
Третьим основным понятием стандарта IDEF0 является декомпозиция (Decomposition). Принцип декомпозиции применяется при разбиении сложного процесса на составляющие его функции. При этом уровень детализации процесса определяется непосредственно разработчиком модели.
Декомпозиция позволяет постепенно и структурированно представлять модель системы в виде иерархической структуры отдельных диаграмм, что делает ее менее перегруженной и легко усваиваемой.
Модель IDEF0 всегда начинается с представления системы как единого целого – одного функционального блока с интерфейсными дугами, простирающимися за пределы рассматриваемой области. Такая диаграмма с