Чтобы развеять предубеждения, о том современному бизнес-аналитику нужны только UML и BPMN для моделирования процессов, сегодня рассмотрим, где и зачем вам пригодится старый добрый IDEF0. В этой статье мы приготовили для вас краткий обзор методологии функционального моделирования IDEF0: история возникновения, особенности применения и примеры практического использования в реальных кейсах бизнес-анализа.
Заговор ООП c Agile или почему структурное проектирование больше не в моде
Чтобы показать многообразие инструментов для описания бизнес-процессов с различных точек зрения, здесь мы привели краткий обзор наиболее распространенных на настоящий момент нотаций моделирования. Повторяя основную идею той статьи, подчеркнем, что для каждой цели следует выбирать подходящий способ ее достижения. К примеру, объектно-ориентированный UML позволяет представить, как пользователь будет взаимодействовать с продуктом и детализировать поведение экземпляров классов будущей системы. Нотация BPMN также пользуется активным спросом благодаря возможности автоматизированного превращения диаграмм в работающие системы с помощью BPM-движков.
В чём различия нотаций IDEF0, DFD и BPMN2.0☝
Поэтому на практике часто можно столкнуться с мнением, что нотация функционального моделирования IDEF0 устарела и встречается только в ВУЗовских курсах, что лишний раз демонстрирует ее отсталость от реалий современного бизнес-анализа. Однако, подобное высказывание, в основном, характерно для junior-аналитиков и свидетельствует лишь об ограниченном опыте человека, который так считает. Да, нотация IDEF0 не слишком популярна среди современных бизнес- и системных аналитиков, по сравнению с UML и BPMN. Но этот факт обусловлен спецификой наиболее распространенных сегодня кейсов, а не ограничением инструмента.
Методы описания бизнес-процессов (IDEF, DFD, BPMN, EPC, UML)
Код курса
MODP
Ближайшая дата курса
14 июня, 2023
Длительность обучения
8 ак.часов
Стоимость обучения
15 000 руб.
Разработанный в 1981 году американским департаментом ВВС стандарт IDEF0, в первую очередь, позиционировался как метод функционального описания системы в виде иерархического набора взаимосвязанных процессов. За прошедшие 40 лет эта графическая нотация почти не изменилась: она до сих пор отлично описывает структуру и взаимосвязь (не логику!) бизнес-процессов одного уровня абстракции с возможностью их последующей детализации.
Понятия | IDEF0 блоки
IDEF0 часто критикуют за тяжеловесность из-за чрезмерной вложенности уровней и невозможность описать логику выполнения бизнес-процесса, что отлично реализуется с помощью XOR-, OR-, AND-операторов, шлюзов, таймеров, ветвлений/объединений и прочих логических инструментов, которые есть в EPC, BPMN и UML activity diagram.
В основе этой критики лежит справедливое замечание о том, что в настоящее время моделирование бизнес-процессов чаще всего выполняется в рамках разработки и/или внедрения информационных систем. Когда вездесущий Agile требует как можно скорее предоставить продукт потребителю, сократив TTM (Time to Market, время выхода на рынок) до минимума, заниматься структурным проектированием процессов «сверху вниз» становится непозволительной роскошью. Впрочем, в большинстве случаев это и не нужно: UML и BPMN позволяют аналитику детально описать функциональные требования и процессы работы с решением на уровне, достаточном для реализации.
Однако, вся мощь развитого инструментария EPC, BPMN и UML не поможет вам структурировать деятельность предприятия, описав состав процессов и объектов, связывающих их между собой. Например, с помощью IDEF0 можно наглядно показать процессы-генераторы дохода или источники затрат как на операционном, так и на тактическом уровнях корпоративного управления. Также в этой нотации удобно отображать управляющие воздействия и вспомогательные ресурсы в виде механизмов, таких как оборудование и люди. Благодаря этому можно визуально разграничить зоны ответственности организационных единиц (роль, должность или отдел/департамент) за отдельные функциональные блоки.
Когда вам пригодится IDEF0: 3 практических примерах
На практике аналитик не часто решает задачи комплексного проектирования модели бизнес процессов в виде единой системы «сверху вниз», как это принято в IDEF0. Однако, подобное описание системы высокоуровневых бизнес-процессов с их последующей детализаций в EPC или BPMN, как это возможно в Business Studio, имеет место в следующих случаях:
- тотальный реинжиниринг (перепроектирование) корпоративной деятельности в связи с приходом нового ТОП-менеджмента и/или слиянием/поглощением с другим предприятием;
- появление нового направления в структуре корпоративной деятельности, например, оказание консалтинговых услуг в дополнение к обучению бизнес-анализу – основной работе, которая приносит доход. Сюда же можно отнести переход от аутсорса к внутренним ресурсам, к примеру, если компания приняла решение иметь и обслуживать самостоятельно собственный автопарк вместо аренды машин или лизинга оборудования.
- подготовка к процедуре сертификации системы менеджмента качества (СМК), одним из ключевых принципов которой является процессный подход, что требует представления корпоративной деятельности в виде системы взаимосвязанных процессов.
В реальной жизни подобные случаи встречаются не так часто, как типовые проекты разработки программного обеспечения. Поэтому неудивительно, что многие junior и middle-аналитики просто не испытывают потребности в IDEF0, успешно пользуясь UML, EPC и BPMN для формализованного описания функциональных требований к проектируемым решениям.
Источник: babok-school.ru
IDEF0
IDEF0 (Integration Definition for Function Modeling) — нотация описания бизнес-процессов. IDEF0 – это метод и язык, являющийся вариантом метода структурного анализа и проектирования (Structural Analysis and Design Technique, SADT). IDEF0 отражает логические отношения между работами, но не позволяет рассматривать временную последовательность. Основными потребителями нотации IDEF0 являются руководители, которым необходимо видеть и понимать взаимосвязь процессов, не вникая в мелочи.
Позже появился IDEF3, документирующий технологические процессы. В нем предоставлена возможность описывать различные сценарии выполнения работы и описывать состояния объектов и переход между ними. IDEF0/IDEF3 успешно дополняют друг друга и широко использовались системными инженерами.
Основные концепции
Идея IDEF0 лежит в том, что бизнес-процесс отображается в виде прямоугольника, в которой входят и выходят стрелки.
Для IDEF0 имеет значение сторона процесса и связанная с ней стрелка:
- слева вход бизнес-процесса – информация (документ) или ТМЦ, который будет преобразован в ходе выполнения процесса;
- справа выход бизнес-процесса – преобразованная информация (документ) или ТМЦ;
- сверху управление бизнес-процесса – информация или документ, который определяет как должен выполняться бизнес-процесс, как должно происходить преобразование входа в выход;
- снизу механизм бизнес-процесса – то, что преобразовывает вход в выход: сотрудники или техника. Считается, что за один цикл процесса не происходит изменения механизма.
Внутри прямоугольника иногда помещаются детали, например список функций, выполняемых данным объектом.
Выход одного бизнес-процесса является входом/управлением/механизмом другого бизнес-процесса. На диаграмме процессы принято располагать по диагонали с верхнего левого угла в нижний правый. Количество процессов не более 6-8.
Преимущества
- показывает взаимодействие процессов в общем виде, без лишних подробностей.
Недостатки
- нельзя увидеть алгоритм выполнения бизнес-процессов.
- требует определенной подготовки для разработки и чтения нотации.
- ввиду ряда ограничений, прежде всего отсутствие формальной теоретической модели, а также отсутствия средств для описания артефактов и потоков информации, IDEF0/IDEF3 теряют свою популярность.
Пример
Литература
- «Методология структурного анализа и проектирования SADT» Дэвид А. Марка и Клемент МакГоуэн
- РД IDEF 0 — 2000: МЕТОДОЛОГИЯ ФУНКЦИОНАЛЬНОГО МОДЕЛИРОВАНИЯ IDEF0. Руководящий документ
- Методика. Проектирование системы управления
Источник: sewiki.ru
Бизнес процессов idef0 это
На сегодняшний день можно констатировать тот факт, что моделирование бизнес-процессов стало неотъемлемой составляющей реализации любого проекта, связанного с модернизацией и развитием деятельности компании. Любое обследование предприятия начинается с анализа бизнес-процессов, их соответствия стратегии развития бизнеса в целом.
Особую значимость приобретает наличие общего языка восприятия текущих и окончательных результатов такой работы для принятия взвешенного управленческого решения. В рамках настоящей статьи авторы представляют краткие результаты исследования по описанию управления бизнес-процессами предприятия на основе методологии IDEF0. Рассмотрены трудности разработки, рекомендации по совершенствованию построения диаграммы IDEF0, которые подробно представлены в учебном пособии «IDEF0, DFD, IDEF3, FISHBONE, FTA: теория и практика бизнес-моделирования». А также приведен пример разработки диаграммы IDEF0.
методология
1. Гаврилова И.В. Свободное программное обеспечение для управления бизнес-процессами // Теория и практика применения свободного программного обеспечения: сб. тр. участников Всеросс. молодёж. конф. с элементами науч. школы. – Магнитогорск: МаГУ, 2011. – С. 144-147
2. Гаврилова И.В. Система управления бизнес-процессами AtivitiBPM //Теория и практика применения свободного программного обеспечения: Сб. тр. участников Всеросс. молодёж. конф. с элементами науч. школы. – Магнитогорск: МаГУ, 2011. – С. 147–154.
3. Лактионова Ю.С. Разработка проекта на модернизацию сайта организации «Комплексный центр социального обслуживания населения» // Ю.С. Лактионова, Ю.В. Путинина. -Современные тенденции развития науки и технологий. – 2015. – № 1–2. – С. 76–78.
4. Лактионова Ю.С. Разработка системы расчёта динамики твёрдых тел в реальном времени // Научные труды SWorld. м 2015. – Т. 4. – № 1 (38). – С. 104–108.
5. Махмутова М.В., Махмутов Г.Р. Создание схемы данных для сервера Oracle с помощью Allfusion Erwin Data Modeler // Научные труды SWorld. – 2010. – Т. 3. – № 2. – С. 58a–61.
6. Махмутова М.В., Давлеткиреева Л.З. Инновационный подход к технологии подготовки ИТ-специалиста в университете // Вестник Московского университета. Серия 20: Педагогическое образование. – 2013. – № 2. – С. 103–116.
7. Назарова О.Б., Давлеткиреева Л.З. Интеграция автоматизированных информационных систем в сфере продаж холдинговой компании // Актуальные вопросы научной и научно-педагогической деятельности молодых учёных: сборник научных трудов всероссийской заочной научно-практической конференции / под ред. Е.С. Ефремовой; редколл.: Е.А. Куренкова и др. – М.: ИИУ МГОУ, 2015. – 240 с. – C. 86–96.
8. Назарова О.Б., Масленникова О.Е., Давлеткиреева Л.З. Формирование компетенций специалиста в области информационных систем с привлечением вендоров / О.Б. Назарова, О.Е. Масленникова, Л.З. Давлеткиреева // Прикладная информатика. – 2013. – № 2(44). – С. 49–56. – Библиогр.: С. 56, ISSN 1993-8314.
9. Назарова О.Б. Сопровождение корпоративных информационных систем: учебник / О.Б. Назарова, Л.З. Давлеткиреева, О.Е. Масленникова, Н.О. Пролозова. – Магнитогорск: МаГУ, 2013. – 220 с.
10. Назарова О.Б., Давлеткиреева Л.З., Малахова, И.В. Аудит информационной инфраструктуры компании и разработка ИТ-стратегии: монография / О.Б. Назарова, Л.З. Давлеткиреева, И.В. Малахова. – Магнитогорск: Изд-во Магнитогорск.гос. ун-та, 2012. – 224 с. Библиогр.: С. 181–188.– 1000 экз. – ISBN 978-5-86781-967-5.
11. Овчинникова И.Г. Мониторинг образовательного процесса вуза / И.Г. Овчинникова, Л.В. Курзаева, И.В. Полякова // Современные проблемы науки и образования. – М., 2009. – № 11. – С. 82–85.
12. Пролозова Н.О., Назарова О.Б., Давлеткиреева Л.З. Анализ стандартов в области сопровождения автоматизированных информационных систем / Н.О. Пролозова, О.Б. Назарова, Л.З. Давлеткиреева // Современные научные исследования и инновации. – 2012. –№ 11 (19). – С. 7. – Режим доступа: http://web.snauka.ru/issues/2012/11/18571.
13. Сильвестрова О.В., Новикова Т.Б. Автоматизация бизнес-процессов медицинского учреждения в рамках проекта «Электронная Россия» // Современные научные исследования и инновации. – 2012. – № 11 [Электронный ресурс]. URL: http://web.snauka.ru/issues/2012/11/18353 (дата обращения: 25.06.2015).
14. Сильвестрова О.В., Новикова Т.Б., Давлеткиреева Л.З. Развитие технической инфраструктуры ЛПУ // Современные научные исследования и инновации. – 2013. – № 3 [Электронный ресурс]. – URL: http://web.snauka.ru/issues/2013/03/22907 (дата обращения: 24.06.2015).
15. Назарова О.Б., Масленникова О.Е., Махмутова М.В., Белоусова, И.Д. Давлеткиреева, Л.З., Попова И.В., Новикова Т.Б., Удотов А.С. Требования к выпускной квалификационной работе студентов специальности 080801 «Прикладная информатика (в экономике)» (методические рекомендации) // Международный журнал экспериментального образования. – 2010. – № 3. – С. 13–14.
Любое обследование компании начинается с анализа бизнес-процессов, их соответствия стратегии развития бизнеса в целом. Особую значимость приобретает наличие общего языка восприятия текущих и окончательных результатов такой работы для принятия взвешенного управленческого решения [1, 2, 4, 7].
Многие годы для аналитиков, проектировщиков, постановщиков задач таким языком являются методологии моделирования бизнес-процессов IDEF0, IDEF3, DFD, диаграммы К. Исикавы, Дерево отказов. В данной статье мы подробнее остановимся на метрологии IDEF0 (Integration Definition for Function Modeling).
IDEF0 – методология создания функциональной модели, которая является структурированным изображением функций производственной системы или среды, а также информации и объектов, связывающих эти функции [5, 14, 15]. Часто при разработке данной модели возникают трудности в указании ресурсов на дугах диаграммы, а именно что можно указывать, а что нельзя, ведь в стандарте это не чётко прописано.
А загромождение диаграммы приводит к плохой читабельности информации на ней. Как формировать цель и точку зрения? Что можно указывать в функциональном блоке? Может ли человек, обозначенный в точке зрения, находиться в механизме и др.?
В рамках исследования данных вопросов нами были разработаны рекомендации по совершенствованию построения модели IDEF0, подробно рассмотренные в пособии «IDEF0, DFD, IDEF3, FISHBONE, FTA: теория и практика бизнес-моделирования». В данной статье мы остановимся на рекомендациях по совершенствованию построения контекстной диаграммы (рис. 1). Рассмотрим подробнее.
1. Функциональный блок, прямоугольник, в котором отображаются описываемый моделью процесс, бизнес-процесс или функция, имеет уникальный идентификационный номер (значение должно быть выражено в отглагольном существительном). Функция – это задача, которую решает компания для собственного выживания и для достижения поставленных целей. Функция отвечает на вопрос «что делать».
Бизнес-процесс – это просто реализация функции во времени, способ решения бизнес-задачи, отвечает на вопрос «как делать». Поэтому функции и процессы не являются противоположностями, а представляют лишь различные уровни абстракции. То есть процесс включает в себя «подпроцессы», а «подпроцессы» – функции (первично – процесс, вторично – функция).
Например: организация деятельности бухгалтера, продажа товара, учет сырья и материалов, подготовка бухгалтерской отчетности, организация работы предприятия ООО «М» и др. [3, 9, 12]. Процесс (ISO 9000:2000): «совокупность взаимосвязанных или взаимодействующих видов деятельности, которые преобразуют входы в выходы» и т.д. Например: приготовление блюда, организация дня рождения, подготовка к выпускному и др.
2. Интерфейсная дуга, стрелка (имеет уникальное наименование, которое должно быть оборотом существительного; началом и концом дуги могут быть только функциональные блоки; источником может быть только выходная сторона блока, а приемником – любая из трех оставшихся). Рассмотрим виды дуг на диаграмме:
2.1. Входная стрелка (Input) – это все то, что используется для преобразования процесса, бизнес-процесса или функции: субъекты, объекты, данные, информация, документы, программное обеспечение (автоматизированная система (АС), автоматизированная информационная система (АИС), корпоративная информационная система (КИС), автоматизированная система управления (АСУ), автоматизированное рабочее место (АРМ), модуль и т.д.).
Так как на входе может быть все то, что используется для преобразования процесса, субъекты на входе будут только в том случае, когда их используют для преобразования этого процесса, т.е. субъект выступает в качестве ресурса. Пример № 1: процесс на контекстной диаграмме – организация работы парикмахера.
Субъект (клиент до услуги) будет находиться на входе, на выходе – субъект (клиент после услуги), а парикмахер будет выступать в качестве исполнителя и находиться в «механизме». Пример № 2: процесс на контекстной диаграмме – поступление абитуриента в вуз. Абитуриент будет находиться на входе, на выходе – студент, а технический секретарь приемной комиссии и экзаменатор – в механизме. Значения АС, АИС, КИС, АСУ, АРМ, модуль будут на входе только в том случае, если их модернизируют, сопровождают, утилизируют… В остальных случаях они будут выступать в качестве средства, с помощью которого обрабатывают информацию, а сама информация из АИС будет располагаться на входе.
2.2. Выходные дуги (Output) – изображают значения, полученные в результате выполнения процесса, бизнес-процесса или функции: субъекты, объекты, данные, информация, документы, ПО (АС, АИС, КИС, АСУ, АРМ, модуль и т.д.). Например, бизнес-процесс на контекстной диаграмме – учет готовой продукции (ГП). Так как в отделе для постоянного учета ГП кладовщик ведет книгу ГП, в которой учитывается поступление и выбытие ГП, книга ГП будет отображаться на контекстной диаграмме на входе, а на выходе – книга ГП с информацией о поступлении или выбытии ГП за период с __ и по__.
2.3. В качестве управляющей информации (Control) используются правила преобразования входной информации в выходную: данные, информация, документы. Субъекты, объекты и ПО (АС, АИС, КИС, АСУ, АРМ), модуль не могут находиться в управлении, потому что нельзя управлять человеком, столом или программным средством. Вместо перечисленного будут: положение о деятельности сотрудника, приказы и распоряжения начальника, инструкция по сборке стола, инструкция по работе с программным средством и т.д.
2.4. Дуги механизмов (Mechanism) должны отражать ресурсы и людей, с помощью которых будет происходить реализация процесса: субъекты, объекты, данные, информация, документы, ПО (АС, АИС, КИС, АСУ, АРМ, модуль и т.д.). Стрелки механизма, направленные вниз, являются стрелками вызова.
3. Цель модели – это то, для чего строится модель. Степень точности модели зависит от поставленной цели, которая отражает причину создания модели и определяет ее назначение; цель является получением ответов на совокупность вопросов, которые неявно присутствуют (подразумеваются) в процессе анализа.
Четко определенная цель становится критерием окончания моделирования. Таким образом, цель модели – это набор вопросов, на которые должна ответить модель. Например, бизнес-процесс на контекстной диаграмме – учет готовой продукции (ГП) на складе. Тогда цель может звучать так: сократить временные, трудовые и финансовые затраты по учету ГП на складе; описать бизнес-процесс учета ГП на складе; описать бизнес-процесс учета ГП на складе с целью выявления «узких мест» и др. [6, 8, 13].
Рис. 1. Рекомендации по построению контекстной диаграммы IDEF0
Рис. 2. Пример диаграммы IDEF0. Контекстная диаграмма «Ведение заказов в ОС»
Рис. 3. Пример диаграммы IDEF0. Декомп. контекст. диаграммы «Ведение заказов в ОС»
4. В точке зрения указывается не тот субъект, который разрабатывает данную модель (например, системный аналитик), а тот, который описывает её и «видит сверху» весь процесс, а не выполняет какую-то часть из функций данного процесса. Следовательно, на дуге «механизм» данного субъекта указывать нежелательно. При выборе точки зрения можно фиксировать дополнительные/альтернативные точки зрения.
5. В примечании прописывается дополнительная информация к аналитику модели. Сокращения на модели – это часто встречающиеся слова на диаграммах. Например: И – информация, ОС – отдел сбыта, ГБ – главный бухгалтер, ГП – готовая продукция и др. [10, 11].
Теперь обобщим выше рассмотренные рекомендации в одну сводную схему, представленную на рис. 1, а также на рис. 2 и 3 представлен пример диаграммы IDEF0.
Рецензенты:
Шепелёв С.Д., д.т.н., доцент, декан инженерно-технологического факультета, Челябинская государственная агроинженерная академия, г. Челябинск;
Дмитриев М.С., д.т.н., профессор кафедры автомобильного транспорта, информационных технологий и методики обучения техническим дисциплинам, Профессионально-педагогический институт, Челябинский государственный педагогический университет, г. Челябинск.
Источник: fundamental-research.ru
