Модель idef0 ошибки - Решение и исправление самых разных ошибок на TopOshibok.ru

Характерные ошибки построения IDEF0 диаграмм(Прочитано 11805 раз)

Коллеги,
кто активно использует и даже любит IDEF0, предлагаю поучаствовать в анализе диаграмм студентов, чтобы выявить характерные ошибки и постараться (мне) написать некое пособие или некую экспертную систему, которая бы помогала студенту самому выявлять и устранять ошибки моделирования.

Ниже представлено извлечение из описания в виде списка объектов и функций, и контекстная диаграмма.
Какие Вы видите замечания, чтобы Вы посоветовали, чтобы их исправить, какие правила Вы обычно используете?

Спасибо!

Записан

Вход
1. Не очень понятна разница между «Заказами» и «Запросами потребителей». Если «запросы потребителей» — то, о чем я подумал, не лучше ли будет разместить их в Контроле?

Выход
2. «Продукция» и «Прибыль» на этом уровне абстракции — суть две стороны одной медали. «Прибыль», наверное, даже правильнее, поскольку название процесса завершается «и продажей».
3. «Реклама» точно не является результатом производства и продажи мебели. С бОльшими на то основаниями ее можно включить в «механизмы». В качестве «двигателя торговли».

Контроль
4. «Политика» в целом неплохо применима к продажной части процесса. Желательно иметь что-то и для производственной.

Механизмы
5. «Сотрудники» — безусловно, а почему отсутствует «оборудование»?

P.S. по «цель»
1. Я бы не стал начинать формулировку цели с «Понять».
2. Эта цель имеет отношение к изображенной модели? Судя по ее содержанию — она относится к более крупной деятельности, частью (артефактом) которой может являться модель. Соответственно, размещение такой цели рядом с моделью может вводить в заблуждение.

« Последнее редактирование: 10 Октября 2014, 12:18:02 от Леонид »

Записан

P.S. по «цель»
1. Я бы не стал начинать формулировку цели с «Понять».
2. Эта цель имеет отношение к изображенной модели? Судя по ее содержанию — она относится к более крупной деятельности, частью (артефактом) которой может являться модель. Соответственно, размещение такой цели рядом с моделью может вводить в заблуждение.

Леонид, спасибо за анализ. А Вы как бы сформулировали данную цель (итог по сути сформулировать требования к информационной системе)?

Записан

А Вы как бы сформулировали данную цель (итог по сути сформулировать требования к информационной системе)?

Например, «разработка исчерпывающей системы требований на создание информационной системы».

Но на мой взгляд, правильнее было бы назвать ее «задачей». Чтобы получилось примерно так: Цель — это улучшение жизнедеятельности отдельно взятого мебельного бизнеса. Цель, в нашем случае, достигается посредством автоматизации процессов. Для чего решается большая задача создания конкретной информационной системы (и еще несколько сопутствующих). А уже в рамках этой большой задачи есть подзадача разработки требований к создаваемой системе.

Записан

Например, «разработка исчерпывающей системы требований на создание информационной системы».

Но на мой взгляд, правильнее было бы назвать ее «задачей». Чтобы получилось примерно так: Цель — это улучшение жизнедеятельности отдельно взятого мебельного бизнеса. Цель, в нашем случае, достигается посредством автоматизации процессов. Для чего решается большая задача создания конкретной информационной системы (и еще несколько сопутствующих). А уже в рамках этой большой задачи есть подзадача разработки требований к создаваемой системе.

Леонид, но мы формулируем не вообще цель проекта, а цель моделирования, цель модели. Основное назначение модели — ответить на вопросы, исходя из этого. Как бы Вы уточнили цель модели(моделирования) и соответственно точку зрения?

Записан

Леонид, но мы формулируем не вообще цель проекта, а цель моделирования, цель модели. Основное назначение модели — ответить на вопросы, исходя из этого. Как бы Вы уточнили цель модели(моделирования) и соответственно точку зрения?

Да, я просто предложил дать понять, что эта «цель» не нечто самоценное, а лишь звено в цепочке, которое ведет к полезному в жизни результату.

Если же ограничиться только моделью, то мне не очень понятно, что за цель может быть у модели (это же просто инструмент, довольно универсальный). У нее может быть назначение: «для демонстрации бигбоссу, что мы не зря получаем зарплату», «для создания представления о предметной области у программистов», «для заполнения обязательного раздела технической документации», «в качестве основы для дальнейшего моделирования», «для обозначения границы создаваемой системы» и т.п.

Цель, наверное, может быть у процесса моделирования. «Показать. что мы освоили нотацию», «Систематизировать собранные во время обследования данные», «Зафиксировать имеющуюся информацию для передачи дальше» и т.п.

С «точкой зрения» скачать что-то затрудняюсь. Если она действительно нужна, то и так неплохо.

Записан

урок 2

Ужас-ужас:
1. Составьте множество вопросов, на которые должна отвечать модель.
2. С помощью этого набора вопросов определите, как будет использоваться модель.
3. Если вы не можете сформулировать, как она будет использоваться, попробуйте записать еще вопросы…

Все, финиш. Терзания на тему «куда бы пристроить эту модель?».

Я не знаю, как и почему так получилось у Марка и МакГоуэна, но у меня примерно так (применительно к нашему случаю):
1. Подумай, что и зачем ты собираешься делать.
2. Определись, какая модель и чем именно поможет осуществить задуманное.
3. Подумай, какая информация тебе нужна для того, чтобы разработать нужную модель.
4. Придумай вопросы, при помощи которых намерен получить нужную информацию.

То есть, ровно наоборот. Видимо, я совершенно безнадежен.

Что касается точек зрения, то ничего не имею против моделей, описывающих объект с разных сторон. Мы все этим занимаемся, как минимум, «в уме». Кроме того, их было бы прикольно сравнивать («слон сбоку» vs «слон сзади» vs «слон глазами блохи» vs «слон глазами охотника»). Но во-первых, достоверность (либо детализация) таких моделей будет невелика, а во-вторых, есть более дешевые способы учета интересов «заинтересованных лиц».

Записан

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

Было бы интересно обсудить но не в этой теме.

Записан

Кстати, в той же книге сказано:

«1.3. Модель имеет единственный субъект
Модель является некоторым толкованием системы. Поэтому субъектом моделирования служит сама система … SADT-модель всегда ограничивает свой субъект, т.е. модель устанавливает точно, что является и что не является субъектом моделирования,»

Обычно, «субъект» — это тот, кто выполняет действия над объектом. «Объект», соответственно, то, над чем выполняются действия.
В книге эти понятия применяются несколько странно — я так и не понял из приведенного раздела, кто там кого моделирует и кто кому задает границы.
Тут вариантов несколько: или переводчик чего-то сильно напортачил, или авторы были где-то глубоко в себе, или с 86 года что-то сильно изменилось.

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

http://thedifference.ru/chem-otlichaetsya-obekt-ot-subekta/

Записан

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

Записан

«1.3. Модель имеет единственный субъект
Модель является некоторым толкованием системы. Поэтому субъектом моделирования служит сама система … SADT-модель всегда ограничивает свой субъект, т.е. модель устанавливает точно, что является и что не является субъектом моделирования,»

английский subject — это субъект и предмет и объект и тема

Записан

английский subject — это субъект и предмет и объект и тема

Да, есть такое. Особенно в «просторечии». Однако у нас это разные вещи, особенно в методологической литературе. Вполне вероятно, путаницу внес переводчик, не разобравшись. Соответственно, я бы не стал предлагать ее студентам. Мало ли, где он там еще не разобрался.
Жаль, не удалось посмотреть, как там в оригинале.

Это не к разбору методологии, а развитие темы «помогала студенту самому выявлять и устранять ошибки моделирования».

Что же касается разработки пособия или экспертной системы, которая позволяла бы в произвольной модели находить ошибки… Можно выявлять ошибки нотации (вводы-выводы не туда-оттуда, «висящие» стрелки и т.п.). Наверняка это уже делает куча инструментов. Но вот формализованным способом разобраться в смысле нарисованного и сделать выводы о корректности — по-моему, эта малореалистичная задача.

Записан

Что же касается разработки пособия или экспертной системы, которая позволяла бы в произвольной модели находить ошибки… Можно выявлять ошибки нотации (вводы-выводы не туда-оттуда, «висящие» стрелки и т.п.). Наверняка это уже делает куча инструментов. Но вот формализованным способом разобраться в смысле нарисованного и сделать выводы о корректности — по-моему, эта малореалистичная задача.

Я имел в виду некий чек лист (экспертная система — это скорее развитие чек листа), по которому студент может себя проверить перед тем, как сдавать работу.

Записан

Я имел в виду некий чек лист (экспертная система — это скорее развитие чек листа), по которому студент может себя проверить перед тем, как сдавать работу.

Аналог «ЧАВО» сделать вполне реалистично. Был бы достаточной объем работ студентов и начинающих аналитиков для систематизации и анализа ошибок. Вопрос — где их взять и где взять на них время.

Записан

Источник

1

Типичные ошибки в моделях структурного подхода Дополнение к лекциям по функциональному моделированию IDEF0, информационному моделированию IDEF1X

2

Вернемся к IDEF0… Типичный вопрос: Третий уровень декомпозиции – это как? Ответ: Нет! Это дерево функциональной модели (Node Tree), т.е. все функциональные блоки модели, представленные в виде древовидной структуры. Дерево наглядно показывает, что представленная на рисунке функциональная модель содержит 2 уровня: контекстную диаграмму и ее декомпозицию. Вопрос: Это он?

3

И снова о декомпозиции А0 Цель: Т.зрения: А-0 А1 А3 А2 А0 А11 А13 А12 А1 А31 А33 А32 А3 Контекстная диаграмма Декомпозиция контекстной диаграммы Декомпозиция блока А1Декомпозиция блока А3 1-й уровень 2-й уровень 3-й уровень

4

Пример модели процесса постройки садового домика Материалы Строители Дом Проект дома Цель: Цель: Определить действия, необходимые для постройки дачного домика Точка зрения: Точка зрения: владельца дачного участка 1. Строим контекстную диаграмму (А-0). Построить дом А0

5

Пример модели процесса постройки садового домика 2. Декомпозируем контекстную диаграмму (2-й уровень) Строители Дом КаменщикиПлотникиКровельщики Мастера по отделке Фундамент Стены Крыша Заложить фундамент А1 Возвести стены А2 Положить крышу А3 O1O1 M1M1 Проект дома C1C1 Выполнить отделку А4 Материалы I1I1

6

Пример модели процесса постройки садового домика Декомпозируем блок А4 (Выполнить отделку) Выполнить отделку потолка А4.1 Наклеить обои А4.2 Покрасить пол А4.3 Дом О1 Крыша I1I1 I2I2 Материалы М1М1Мастера по отделке С1С1Проект дома Отделанный потолок Отделанные стены

7

Тогда… Дерево нашей функциональной модели примет следующий вид:

8

Список типичных ошибок при построении ФМ IDFE0 Неверное именование функциональных блоков и интерфейсных дуг (часто путают друг с другом) Нарушение принципа декомпозиции (не используются граничные стрелки с верхнего уровня или берутся другие) Некорректное изображение интерфейсных дуг (подведение к «не той» стороне функционального блока) Неверная нумерация функциональных блоков и диаграмм Включение декомпозируемого блока в диаграмму декомпозиции

9

Вернемся к ИМ IDEF1X… Типичная проблема: непонимание терминов «сущность» и «атрибут». Отождествление сущности с экземпляром сущности, атрибута – с его конкретным значением!

10

Сущность и экземпляр сущности Студент зачетной книжки ФИО Пол Группа Дата рождения Адрес Вася Иванов Ваня Петров Лена Сидорова Это экземпляры сущности! признаки Это сущность! Она содержит признаки, по которым можно различать экземпляры

11

Что же такое сущность? Студент зачетной книжки ФИО Пол Группа Дата рождения Адрес = Таблица — Студент Сущность Таблица в базе данных! Атрибут – Заголовок соответствующего столбца таблицы! Конкретные значения в строках таблицы – экземпляр сущности!

12

Типичные ошибки при построении ИМ IDEF1X Непонимание понятия сущности, а следовательно, выделение в виде сущности абстрактных и непонятных вещей (например, Идея, Желание) Непонимание понятия атрибута, а следовательно, неверное их определение (часто путают сам атрибут и его значение) Неверное установление связей между сущностями Некорректное именование сущностей (часто глаголом или существительным во множественном числе)

13

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

14

От информационной модели к базе данных физической модели 2. Построение физической модели на основе логической (определение типов данных, при необходимости, переименование атрибутов)

15

От информационной модели к базе данных схемы БД 3. Автоматическая генерация схемы БД на основе физической модели. Сущности становятся таблицами, атрибуты – полями. Таблицы связываются между собой ключевых полей. Далее базу данных нужно просто заполнить

Источник

П А Р У С — Д О Н

СозданиеотчетоввBPwin

BPwin имеет мощный инструмент генерации. Отчеты по модели вызываются из пункта меню Report. Всего имеется семь типов отчетов:

1.Model Report. Этот отчет уже упоминался в 1.2.1. Он включает информацию о контексте модели — имя модели, точку зрения, область, цель, имя автора, дату создания и др.

2.Diagram Report. Отчет по конкретной диаграмме. Включает список объектов (работ, стрелок, хранилищ данных, внешних ссылок и т. д.).

3.Diagram Object Report. Наиболее полный отчет по модели. Может включать полный список объектов модели (работ, стрелок с указанием их типа и др.) и свойства, определяемые пользователем.

4.Activity Cost Report. Отчет о результатах стоимостного анализа. Будет рассмотрен ниже.

5.Arrow Report. Отчет по стрелкам. Может содержать информацию из словаря стрелок, информацию о работе-источнике, работе-назначении стрелки и информацию о разветвлении и слиянии стрелок.

6.DataUsage Report. Отчет о результатах связывания модели процессов и модели данных. (Будет рассмотрен ниже.)

7.Model Consistency Report. Отчет, содержащий список синтаксических ошибок модели.

Синтаксические ошибки IDEF0 с точки зрения BPwin разделяются на три типа:

oВо-первых, это ошибки, которые BPwin выявить не в состоянии. Например, синтаксис IDEF0 требует, чтобы имя работы было выражено отглагольным существительным или глагольной формой, выражающей действие («Занесение звонка клиента», «Обслуживание клиента», «Выписка счета» и т.

д.), а имя стрелки также должно быть выражено существительным. BPwin не позволяет анализировать синтаксис естественного языка (английского и русского) и смысл имен объектов и поэтому игнорирует ошибки этого типа. Выявление таких ошибок — ручная работа, которая ложится на плечи аналитиков и должна контролироваться руководителем проекта.

oОшибки второго типа BPwin просто не допускает. Например, каждая грань работы предназначена для определенного типа стрелок. BPwin просто не позволит создать на диаграмме IDEF0 внутреннюю стрелку, выходящую из левой грани работы и входящую в правую грань.

oТретий тип ошибок BPwin позволяет допустить, но детектирует их. Полный их список можно получить в отчете Model Consistency Report. Это единственный неопциональный отчет в BPwin. Список ошибок может содержать, например, неименованные работы и стрелки (unnamed arrow, unnamed activity), несвязанные стрелки (unconnected border arrow), неразрешенные стрелки (unresolved (square tunneled) arrow connections), работы, не имеющие по крайней мере одной

П А Р У С — Д О Н

стрелки выхода и одной стрелки управления (Activity «Сборка блоков» has no Control, Activity «Сборка блоков» has no Output), и

т. д. Пример отчета Model Consistency Report приведен на рис. 1.38.

Р И С . 1 . 3 8 . О Т Ч Е Т M O D E L C O N S I S T E N C Y R E P O R T

При выборе пункта меню, который соответствует какому-либо отчету, появляется диалог настройки отчета. Для каждого из семи типов отчетов он выглядит по-своему. Рассмотрим типичный диалог Arrow Report (рис. 1.39).

П А Р У С — Д О Н

Р И С . 1 . 3 9 . Д И А Л О Г A R R O W R E P O R T

Раскрывающийся список Standart Reports позволяет выбрать один из стандартных отчетов. Стандартный отчет — это запоминаемая комбинация переключателей, флажков и других элементов управления диалога. Для создания собственного стандартного отчета необходимо задать опции отчета, ввести имя отчета в поле списка выбора и щелкнуть по кнопке New. BPwin сохраняет информацию о стандартном отчете в файле BPWINRPT.INI. Все определения этого файла доступны из любой модели. Единственное ограничение — свойства, определяемые пользователем (User-Defined Properties). Они сохраняются в виде указателя и поэтому доступны только из «родной» модели. Стандартный отчет можно изменить (кнопка Update) или удалить(кнопка Delete).

В правом верхнем углу диалога находится группа управляющих элементов для выбора формата отчета. Доступны следующие форматы:

oLabeled — отчеты включают метку поля, затем, в следующей строке, печатается содержимое поля;

o Fixed Column — каждое поле печатается ,в собственной колонке;

oTab-Comma Delimited — каждое поле печатается в собственной колонке. Колонки разделяются знаком табуляции или запятыми;

oDDE Table — данные передаются по DDE приложению,

например MS Word или Excel;

oRPTwin — отчет создается в формате Platinum RPTwin —

специализированного генератора отчетов, который входит в поставку BPwin.

Опция Ordering (на отчете по стрелкам отсутствует) сортирует данные по какому-либо значению.

Опция Multi-Valued Format регулирует вывод полей в отчете при группировке данных:

oRepeating Group — детальные данные объединяются в одно поле, между значениями вставляется +.

o Filled — дублирование данных для каждого заголовка группы;

oHeader (опция по умолчанию) — печатается заголовок группы, затем -детальная информация.

Стоимостныйанализ(ЛВС) исвойства, определяемыепользователем(UDP)

Как было указано ранее, обычно сначала строится функциональная модель существующей организации работы — AS-IS (как есть). После построения модели AS-IS проводится анализ бизнес-процессов, потоки данных и объектов перенаправляются и улучшаются, в результате строится модель ТО-ВЕ. Как правило, строится несколько моделей ТО-ВЕ, из которых по какому-либо критерию выбирается наилучшая. Проблема состоит в том, что таких

П А Р У С — Д О Н

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

BPwin предоставляет аналитику два инструмента для оценки модели — стоимостный анализ, основанный на работах (Activity Based Costing, ABC), и свойства, определяемые пользователем (User Defined Properties, UDP). ABC является широко распространенной методикой, используемой международными корпорациями и государственными организациями (в том числе Департаментом обороны США) для идентификации истинных движителей затрат в организации.

Стоимостный анализ представляет собой соглашение об учете, используемое для сбора затрат, связанных с работами, с целью определить общую стоимость процесса. Стоимостный анализ основан на модели работ, потому что количественная оценка невозможна без детального понимания функциональности предприятия. Обычно ABC применяется для того, чтобы понять происхождение выходных затрат и облегчить выбор нужной модели работ при реорганизации деятельности предприятия (Business Process Reengineering, BPR). С помощью стоимостного анализа можно решить такие задачи, как определение действительной стоимости производства продукта, определение действительной стоимости поддержки клиента, идентификация работ, которые стоят больше всего (те, которые должны быть улучшены в первую очередь), обеспечение менеджеров финансовой мерой предлагаемых изменений т. д.

ABC может проводиться только тогда, когда модель работы последовательная (следует синтаксическим правилам IDEF0), корректная (отражает бизнес), полная (охватывает всю рассматриваемую область) и стабильная (проходит цикл экспертизы без изменений), другими словами, создание модели работы закончено.

ABC включает следующие основные понятия:

oобъект затрат — причина, по которой работа выполняется, обычно, основной выход работы, стоимость работ есть суммарная стоимость объектов затрат («Предоставление ответа», рис. 1.40).

Р И С . 1 . 4 0 . И Л Л Ю С Т Р А Ц И Я Т Е Р М И Н О В A B C

oдвижитель затрат — характеристики входов и управлений работы (рис. 1.40), которые влияют на то, как выполняется и как долго длится работа;

o центры затрат, которые можно трактовать как статьи расхода.

При проведении стоимостного анализа в BPwin сначала задаются единицы измерения времени и денег. Для задания единиц измерения следует вызвать

П А Р У С — Д О Н

диалог Model Properties (меню Edit/Model Properties), закладка ABC Units (рис. 1.41).

Если в списке выбора отсутствует необходимая валюта (например, рубль), ее можно добавить. Символ валюты по умолчанию берется из настроек Windows. Диапазон измерения времени в списке Unit of measurment достаточен для большинства случаев — от секунд до лет.

Р И С . 1 . 4 1 . Н А С Т Р О Й К А Е Д И Н И Ц И З М Е Р Е Н И Я В А Л Ю Т Ы И В Р Е М Е Н И

Затем описываются центры затрат (cost centers). Для внесения центров затрат необходимо вызвать диалог Cost Center Editor (меню Edit/ABC Cost Centers (рис. 1.42).

Каждому центру затрат следует дать подробное описание в окне Definition. Список центров затрат упорядочен. Порядок в списке можно менять при помощи стрелок, расположенных справа от списка. Задание определенной последовательности центров затрат в списке, во-первых, облегчает последующую работу при присвоении стоимости работам, а во-вторых, имеет значение при использовании единых стандартных отчетов в разных моделях. Хотя, как было указано в 1.2.5, BPwin сохраняет информацию о стандартном отчете в файле BPWINRPT.INI, информация о центрах затрат и UDP сохраняется в виде указателей, т. е. хранятся не названия центров затрат, а их номера. Поэтому, если нужно использовать один и тот же стандартный отчет в разных моделях, списки центров затрат должны быть в них одинаковы.

П А Р У С — Д О Н

Р И С . 1 . 4 2 . Д И А Л О Г C O S T C E N T E R E D I T O R

Для задания стоимости работы (для каждой работы на диаграмме декомпозиции) следует щелкнуть правой кнопкой мыши по работе и на всплывающем меню выбрать Cost Editor (рис. 1.43). В диалоге Activity Cost указывается частота проведения данной работы в рамках общего процесса (окно Frequency) и продолжительность (Duration). Затем следует выбрать в списке один из центров затрат и в окне Cost задать его стоимость. Аналогично назначаются суммы по каждому центру затрат, т. е. задается стоимость каждой работы по каждой статье расхода. Если в процессе назначения стоимости возникает необходимость внесения дополнительных центров затрат, диалог Cost Center Editor вызывается прямо из диалога Activity Cost соответствующей кнопкой.

Р И С . 1 . 4 3 . З А Д А Н И Е С Т О И М О С Т И Р А Б О Т В Д И А Л О Г Е A C T I V I T Y C O S T

П А Р У С — Д О Н

Общие затраты по работе рассчитываются как сумма по всем центрам затрат. При вычислении затрат вышестоящей (родительской) работы сначала вычисляется произведение затрат дочерней работы на частоту работы (число раз, которое работа выполняется в рамках проведения родительской работы), затем результаты складываются. Если во всех работах модели включен режим Compute from Decompositions, подобные вычисления автоматически проводятся по всей иерархии работ снизу вверх (рис. 1.44).

Р И С . 1 . 4 4 . В Ы Ч И С Л Е Н И Е З А Т Р А Т Р О Д И Т Е Л Ь С К О Й Р А Б О Т Ы

Этот достаточно упрощенный принцип подсчета справедлив, если работы выполняются последовательно. Встроенные возможности BPwin позволяют разрабатывать упрощенные модели стоимости, которые тем не менее оказываются чрезвычайно полезными при предварительной оценке затрат. Если схема выполнения более сложная (например, работы производятся альтернативно), можно отказаться от подсчета и задать итоговые суммы для каждой работы вручную (Override Decompositions). В этом случае результаты расчетов с нижних уровней декомпозиции будут игнорироваться, при расчетах на верхних уровнях будет учитываться сумма, заданная вручную. На любом уровне результаты расчетов сохраняются независимо от выбранного режима, поэтому при выключении опции Override Decompositions расчет снизу вверх производится обычным образом.

Для проведения более тонкого анализа можно воспользоваться специализированным средством стоимостного анализа EasyABC (ABC Technology, Inc.). BPwin имеет двунаправленный интерфейс с EasyABC. Для экспорта данных в EasyABC следует выбрать пункт меню File/Export/Node Tree , задать в диалоге Export Node Tree необходимые настройки и экспортировать дерево узлов в текстовый файл (.txt). Файл экспорта можно импортировать в EasyABC. После проведения необходимых расчетов результирующие данные можно импортировать из EasyABC в BPwin. Для импорта нужно выбрать меню

File/Import/Costs и в диалоге Import Activity Costs выбрать необходимые установки.

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

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

П А Р У С — Д О Н

Результаты стоимостного анализа наглядно представляются на специальном отчете BPwin — Activity Cost Report (меню Report/Activity Cost Report). Отчет позволяет документировать имя, номер, определение и стоимость работ, как суммарную, так и раздельно по центрам затрат (рис. 1.46).

Р И С . 1 . 4 5 Д И А Л О Г Н А С Т Р О Й К И О Т Ч Е Т А П О С Т О И М О С Т И Р А Б О Т

Результаты отображаются и непосредственно на диаграммах. В левом нижнем углу прямоугольника работы может показываться либо стоимость (по умолчанию), либо продолжительность, либо частота проведения работы. Настройка отображения осуществляется в диалоге Model Properties (меню

Edit/Model Properties), закладка Display, ABC Data, ABC Units.

АВС позволяет оценить стоимостные и временные характеристики системы. Если стоимостных показателей недостаточно, имеется возможность внесения собственных метрик — свойств, определенных пользователем (User Defined Properties, UDP). UDP позволяют провести дополнительный анализ, хотя и без суммирующих подсчетов.

Для описания UDP служит диалог User-Defined Property Name Editor (меню

Edit/UDP Definition) (рис. 1.46) В верхнем окне диалога вносится имя UDP, в списке выбора Datatype описывается тип свойства. Имеется возможность задания 18 различных типов UDP, в том числе управляющих команд и массивов, объединенных по категориям. Для внесения категории следует задать имя категории в окне New Category/Member и щелкнуть по кнопке Add Category. Для присвоения свойства категории необходимо выбрать UDP из списка, затем категорию из списка категорий и щелкнуть по кнопке Update. Одна категория может объединять несколько свойств, в то же время одно свойство может входить в несколько категорий. Свойство типа List может содержать массив предварительно определенных значений. Для определения области значений UDP типа List следует задать значение свойства в окне New Category/Member и щелкнуть по кнопке Add Member. Значения из списка можно редактировать и удалять.

П А Р У С — Д О Н

Р И С . 1 . 4 6 Д И А Л О Г О П И С А Н И Я U D P

Например, категория «Загрязнение окружающей среды» может объединять свойство «загрязнение воды» типа Real Number и свойство «загрязнение воздуха» типа Integer List с предварительно определенной областью значений

(1, 2, 3, 4, 5).

Каждой работе можно поставить в соответствие набор UDP. Для этого следует щелкнуть правой кнопкой мыши по работе и выбрать пункт меню UDP Editor. В закладке UDP Values диалога IDEF0 Activity Properties можно задать значения UDP. Свойства типа List отображаются списком выбора, который заполнен предварительно определенными значениями. Свойства типа Command могут иметь в качестве значения командную строку, которая выполняется при нажатии на кнопку !!!. Например, свойство «Спецификации» категории «Дополнительная документация» может иметь значение

«C:\MSOffice97\Office\WINWORD.EXE sped.doc».

Кнопка Categories служит для задания фильтра по категориям UDP. По умолчанию в списке показываются свойства всех категорий,

Результат задания проанализировать в отчете Diagram Object Report (меню

Report/Diagram Object Report) (рис. 1.47.

П А Р У С — Д О Н

Р И С . 1 . 4 7 Д И А Л О Г Н А С Т Р О Й К И О Т Ч Е Т А D I A G R A M

O B J E C T R E P O R T

В левом нижнем углу диалога настройки отчета показывается список UDP. С помощью кнопки Activity Categories можно установить фильтр по категориям.

Дополнениесозданноймоделипроцессов диаграммамиDFD иWorkflow (IDEF3)

Диаграммы потоков данных (Data Flow Diagramming)

Диаграммы потоков данных (Data flow diagramming, DFD) используются для описания документооборота и обработки информации. Подобно IDEF0, DFD представляет модельную систему как сеть связанных между собой работ. Их можно использовать как дополнение к модели IDEF0 для более наглядного отображения текущих операций документооборота в корпоративных системах обработки информации. DFD описывает:

o функции обработки информации (работы);

oдокументы (стрелки, arrow), объекты, сотрудников или отделы, которые учавствуют в обработке информации;

Соседние файлы в папке ИСУП

Источник

Описание графической нотации IDEF0. Определение стандарта. Особенности функционального моделирования бизнес-процессов. Пример нотации IDEF0 и его подробное описание. Перечень важных ошибок при использовании IDEF0.

“Одна картинка стоит тысячи слов.“

Народная мудрость

Зачастую в моей работе возникает необходимость не просто изучить и решить определенную проблему, но выявить ее местонахождение в общей модели работы компании. Мало понимать, что определенное подразделение работает неправильно, важно понимать, каким образом оно взаимодействует с другими. Иначе невозможно выявить все существующие проблемы и выбрать оптимальный метод решения поставленной задачи.

А для этого требуется изучить работу компании и составить ее функциональную модель.Конечно, в теории функциональная модель работы компании должна быть у руководителя, причем, не важно, идет речь об организации работы склада или об IT системе (от лида до заявки).

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

Несколько слов о преимуществах графики

Как известно, функциональные модели IDEF0 — это всегда графические схемы. У них есть свои особенности и правила составления. Об этом мы поговорим чуть-чуть позже. А сейчас я хотел бы привести пару примеров эффективности графики. Почему я делаю на этом акцент? Скорей всего, после моего утверждения о необходимости функциональной модели работы компании, очень многие подумали, что это все необязательно, можно и на словах пояснить как работает та или иная функция в компании. Вот об этом я и хочу поговорить.

И для начала сделаем небольшой экскурс в историю. Вернемся в далекий 1877 год, в период Русско-Турецкой войны. Именно тогда полиграфист Сытин впервые применил графику при описании военных действий. Сейчас для нас все это привычно, при описании любого сражения у каждого перед глазами возникают карты со стрелками, которые наглядно показывают ход сражения. А в те времена военные действия описывались словами. Для каждого боя — много-много слов. И понять в итоге, что же происходит, было очень сложно. А потому идея Сытина была поистине революционной — он начал печатать литографические копии карт с обозначением укреплений и расположений воинских частей. Назывались эти карты “Для читателей газет. Пособие”. Идея оказалась настолько актуальной, что первый же тираж “Пособий” разошелся мгновенно. И потом такие приложения были очень востребованы.

Причина очевидна. Графика помогала понять то, что при помощи одних слов разобрать было практически невозможно. Аналогичный пример беспомощности словесных описаний я могу привести также из своей практики. Один из моих заказчиков очень просил взяться за внедрение ERM-системы для его компании.

На вопрос, есть ли у них какое-то техническое задание, я получил ответ: “Да, есть. Но в нем 400 страниц”. При этом клиент очень жаловался, что мои коллеги, к которым он обращался ранее, либо отказывались от проекта вообще, либо называли явно завышенные цены.

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

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

Почему это важно для моей работы

Моя работа всегда связана с внесением изменений в существующую КИС. А для того, чтобы внести изменения и получить нужный результат, нужно изучить то, что существует уже сейчас. И не важно, что именно мы делаем – настраиваем или устанавливаем с нуля CRM-систему, создаем эффективную ERP-систему, занимаемся интеграцией различных систем для повышения автоматизации работы в целом. В любом случае, для начала, необходимо получить представление о существующей схеме работы, и только после этого можно предлагать какие-то изменения и продумывать варианты решения поставленной задачи.

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

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

Как известно, одна картинка стоит тысячи слов. И в случае описания бизнес-процессов и вариантов модернизации работы бизнеса – это действительно так. И здесь очень хорошо подходят нотации IDEF0.

Но для начала, давайте разберемся с основными понятиями, что такое нотации, зачем они нужны, что такое IDEF0, в чем особенности и преимущества этого метода

Что такое нотация описания бизнес-процессов

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

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

Что такое IDEF0?

IDEF0 — методология функционального моделирования (англ. function modeling) и графическая нотация, предназначенная для формализации и описания бизнес-процессов. Отличительной особенностью IDEF0 является ее акцент на соподчиненность объектов. В IDEF0 рассматриваются логические отношения между работами, а не их временна́я последовательность (поток работ). Википедия.

Стандарт IDEF0 был разработан в 1981 году в США департаментом Военно-воздушных сил для автоматизации промышленных предприятий. В процессе разработки программного обеспечения разработчики столкнулись с необходимостью разработки новых методов анализа бизнес-процессов. В результате появилась методология функционального моделирования IDEF0, в которой для анализа применяются специальные нотации IDEF0.

Функциональная модель компании

Функциональная модель IDEF0 представляет собой набор блоков, каждый из которых представляет собой «черный ящик» со входами и выходами, управлением и механизмами, которые детализируются (декомпозируются) до необходимого уровня. Наиболее важная функция расположена в верхнем левом углу. А соединяются функции между собой при помощи стрелок и описаний функциональных блоков. При этом каждый вид стрелки или активности имеет собственное значение. Данная модель позволяет описать все основные виды процессов, как административные, так и организационные. Стрелки могут быть:

Входящие – вводящие, которые ставят определенную задачу.
Исходящие – выводящие результат деятельности.
Контроль (сверху вниз) – механизмы управления (положения, инструкции и пр).
Механизмы (снизу вверх) – что используется для того, чтобы произвести необходимую работу.

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

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

Для работы с ним существует множество инструментов, например, VISIO, BPWIN, ERWIN, Business studio и т.д. Кроме того, использование для создания бизнес-моделей IDEF0 — это не только удобно, это еще и правильно. Этот инструмент был разработан для бизнес-аналитики, он прошел длительную и тщательную отладку и шлифовку.

А потому при помощи IDEF0 создать функциональную модель без ошибок намного проще, чем без применения этого стандарта. Как известно, забивать гвозди лучше всего молотком. Конечно, вы можете для этого применять и другие инструменты, но молоток — наиболее функционален и с его помощью проще всего забить гвоздь аккуратно и точно. Так и с применением IDEF0 — этот инструмент был создан для функционального моделирования, и с его помощью вы намного быстрее и точнее сможете получить нужный результат.

Пример создания функциональной модели IDEF0

Для того чтобы понять, как работать с функциональным моделированием, я приведу пример процесса написания статьи. Основной блок – «Написать статью».

Вводящие стрелки – «Опыт», «Информация из сторонних источников». Это те вводные, которые необходимы для начала работы. Управляющие для написания статьи – это «План публикации», «Требования издателя», «Правила русского языка».

А в роли «Механизмов» выступают автор, копирайтер, корректор и программное обеспечение. В данном случае автор создает аудиоматериал, в котором собирает все мысли и идеи, которые должны быть отражены в статье. Копирайтер – это человек, который создает на основе этого материала, руководствуясь требованиями издателя, планом публикации и правилами русского языка, готовый текст статьи.

Корректор проверяет материал на ошибки. А программное обеспечение – это те инструменты, которые используют в работе все участники процесса. Таким образом, я задал основные параметры процесса, его вход, выход, а также все необходимое для успешного проведения процесса.

Но это – только основные рамки функции. Так описывается общая схема работы компании в целом. На самом деле, процесс создания статьи, как и любой бизнес-процесс можно и нужно детализировать. Для этого я декомпозирую общий блок «написать статью» на связанные между собой элементы. В нашем случае работа делится на 4 основных этапа:

Создать аудио запись статьи.
Создать статью
Подготовить текст к публикации.
Разместить статью в издании.

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

При создании функциональной модели ключевыми параметрами являются цель и точка зрения. Исходя из них, моделирование одних и тех же процессов может выглядеть несколько по-разному. Например, в моем случае целью является «рассказать о процессе написания статьи». А точка зрения копирайтера – это «написание и публикация статьи с точки зрения руководителя процесса».

Так, если бы тот же процесс был описан с точки зрения копирайтера, то входящими были бы опыт и аудиофайл от автора. При этом в таком случае под Опытом подразумевался бы опыт копирайтера, но не руководителя или автора. А потому первое, что нужно определить при создании модели бизнес-процесса – это выбрать точку зрения и четко сформулировать цель. Такое моделирование не только наглядно, но и очень удобно для принятия эффективных управленческих решений. Например, в описанном выше бизнес-процессе есть два отдельных специалиста — копирайтер и корректор.

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

А потому при необходимости я могу, скажем, за половину стоимости обязанности корректора предложить копирайтеру. Так я сэкономлю средства и время на взаимодействие разных специалистов. Конечно, я понимаю все заслуги корректоров и почему лучше работать с отдельным специалистам. Но напоминаю — у меня стоит задача: оптимизация затрат. Без такого наглядного инструмента было бы сложнее определить, какие из блоков можно удалить и, таким образом, оптимизировать работу.

Как создавать нотации IDEF0

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

IDEF0

Я лично считаю, что на первом этапе нет ничего лучше, чем обычная бумага, простой карандаш и ластик, чтобы вносить корректировки в случае ошибок. Для того чтобы создать нотацию существующих бизнес-процессов, т.е. описать, как сейчас работает компания, необходимо принципы работы изучить. Сторонний специалист (консультант, разработчик) для этого проводит интервью. На первом этапе на вопросы отвечает руководитель компании, далее в процессе детализации нотации проводятся интервью сотрудников, отвечающих за различные этапы работы.

При этом важно понимать, что в результате потребуется 2 нотации . Первая будет отображать бизнес-процессы в виде «как есть». Ее вы создаете на основе интервью и согласовываете каждую детализацию с сотрудниками компании и руководителем. Очень важно, чтобы ваше видение существующих процессов совпало с реальностью, именно для этого и требуется подтверждение на всех уровнях. Вторая нотация – «как должно быть».

Она создается на основе первой и тех изменений, которые вы предлагаете внести в структуру работы для оптимизации и автоматизации работы компании в рамках выполнения поставленной задачи. Требования стандарта IDEF0 Базовые требования стандарта IDEF0, в принципе, я описал выше и показал на примере.

В левом верхнем углу всегда – главный элемент.
Все элементы должны иметь входящие и исходящие стрелки, так как для выполнения необходимо что-то получить на входе (заказ, поставленную задачу), а после обработки на выходе необходимо передать готовый продукт. Входящие стрелки всегда слева, исходящие – справа.
Сверху – управляющие элементы, снизу – механизмы, необходимые для выполнения процесса.
Если на одном листе (экране) располагается несколько блоков, каждый последующий располагается справа и ниже предыдущего.
Необходимо стремиться создавать схемы таким образом, чтобы пересечение стрелок было сведено к необходимому минимуму.

Сам стандарт IDEF0 описан разработчиками в документе перевод которого вы найдете в статье Перевод стандарта IDEF0 с английского на русский язык.

Точка зрения

2 основополагающих требования к модели.

В требованиях к диаграмме и построению модели в нотации IDEF0 есть требование, которое звучит так: любая диаграмма должна быть построена, исходя из точки зрения (Point of view) и цели (Scop). Именно этот вопрос, скажем так, один из основополагающих — точка зрения и цель. Соответственно, если мы хотим построить правильную диаграмму, нам необходимо выбирать правильно точку зрения.

Если мы заглянем в само описание стандарта, то мы увидим два определения, которые не особо вносят ясность. Первое определение:

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

Второе определение:

Точка зрения определяет, что можно «увидеть „в контексте модели, с какой точки зрения или “под каким углом». В зависимости от поставленной цели могут быть приняты точки зрения, учитывающие различные аспекты объекта. На модель существует только одна точка зрения.

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

Выбор точки зрения.

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

Первое правило: выбор места в иерархии.

Для начала давайте взглянем на простой пример — это склад. Представим себе, что у нас на складе работает 4 человека . Это первый работник склада который отвечает за приемку, второй работник склада который отвечает за хранение, третий работник склада который за отгрузку товара и руководитель склада, тот, кто соответственно руководит и контролирует.

Точка зрения: работник склада.

Если я, допустим, выберу точку зрения работника склада, то, что я увижу? Я увижу товар, требования к товару, требования к документации, свое рабочее место. Если я отвечаю только за приемку, то увижу только зону приема. В этом случае сам склад, место хранения, я могу не увидеть и зону отгрузки тоже могу не увидеть. Соответственно, что мы здесь видим? Мы видим, что наша точка зрения обусловлена тем, где мы находимся в иерархии. Проще говоря, мы видим то, что нам разрешено увидеть. Значит, первое правило — мы должны понимать, кто мы в иерархии предприятия, то есть с какой точки зрения мы смотрим.

Точка зрения: руководитель склада.

Чтобы наглядно продемонстрировать это, давайте посмотрим на точку зрения начальника, руководителя склада. Если мы посмотрим , то увидим, что он видит, как приемку, так и хранение, и отгрузку, и контролирует все эти вещи. То есть он видит больше. Он выше. Значит, с его точки зрения он видит больше. Но, в связи с этим, для него те вещи, которые важны для работника склада, и которые видит работник склада, уже не так важны. Можно сказать, что он видит больше, но видит в большей перспективе и меньшей детализации.

Второе правило: выбор окружения

Отсюда же следует второй вопрос — что конкретно мы видим? Допустим, я работник склада, и я вижу то, что меня окружает: рабочее место, допустим, какой-то компьютер, доступ в какую-то систему учетную и ещё что-то в этом роде. И если я, описываю с точки зрения работника склада, работника приемки, назовём это так, то для меня эти все вещи будут важны.

Но все ли они важны для меня, если я решил автоматизировать это рабочее место? Важна ли для меня с точки зрения автоматизации, например, чистота? Или важно для меня, какой у меня стол, наличие стула и тому подобные вещи? Нет, они не важны! Также не важны для меня и различные инструкции, потому что при автоматизации этот момент я опускаю.

Соответственно, мы приходим ко второму правилу — это выбор окружения. То есть мы должны понимать, что нас окружает и выбирать из этого окружения, то, что мы будем учитывать в нашей модели. Это второе правило.

Третье правило: приоритет.

Третье правило следует из второго — это приоритет. То есть, даже если я смотрю с точки зрения автоматизации, у меня есть документация, документы входящие и исходящие, у меня есть компьютер какой-то, у меня есть сканер — нужно ли мне это отражать с точки зрения автоматизации или не нужно? То есть это есть в окружении, это есть на моей точке иерархии, но мне, допустим, не нужен сканер при работе, если я автоматизирую используя программное обеспечение. Я опускаю именно техническую сторону с точки зрения оборудования. Исходя именно из своих приоритетов, я убираю упоминание оборудования.

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

Цель создания модели.

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

Какие могут быть цели создания модели? Это может быть представление, для примера, организационной структуры отдела предприятия. Может быть создание модуля продажи для отдела продаж. Исходя из той цели, которую преследует наша модель, то есть создание самой модели, мы и выбираем вот эти вещи, которые я упомянул в точке зрения.

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

Типичные ошибки

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

Использование различных цветов

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

Часто при моделировании на бумаге или в различных программах пользователи пытаются повысить наглядность за счет использования разных цветов. Это одна из самых распространенных ошибок. На самом деле, применение разноцветных стрелок и блоков только вносит дополнительную путаницу, а также искажает восприятие схемы.

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

Слишком большое количество блоков

При составлении модели часто стараются отобразить на одном листе все нюансы работы компании со всеми подробностями. В результате получается очень большое количество блоков с большим количеством управляющих стрелок.

Читабельность при этом теряется. Оптимальный вариант – это детализация, достаточная для понимания вопроса, и не более того. Подробная детализация работы каждого подразделения или даже сотрудника может раскрываться при выборе подробного просмотра того или иного процесса. И создается такая структура только если это действительно нужно для работы или принятия решения.

Нарушение структуры при внесении корректировок

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

И если они останутся в общей схеме, то при детализации будут вести непонятно куда и вносить путаницу. Аналогично, если я решу добавить какой-то блок, важно убедиться, чтобы он также имел все необходимые атрибуты. Здесь очень важна внимательность, так как при моделировании сложных бизнес-процессов изменения в одной части модели могут повлечь за собой изменения в другой. Их обязательно нужно внести.

Правила названия управляющих элементов и блоков

Важно запомнить простое правило: управляющие стрелки называют именами существительными, блоки – глаголами. Так принято в стандарте IDEF0, и такой подход помогает избежать путаницы и ошибок. Чаще всего ошибки допускают при названии блоков. Например, вместо «Создать статью» пишут «Создание статьи». Блоки в данном подходе – это действия, а потому они должны быть всегда глаголами.

Выгоды использования IDEF0

Самая первая выгода очевидна – это наглядность. Вы сами начинаете понимать, как работает та или иная система, и можете также наглядно пояснить, где в этой системе «тонкие места» и как ваши решения помогут избавиться от них.
Взаимопонимание и отсутствие разночтений. При обсуждении работы компании с использованием функциональной модели у вас имеются наглядные и понятные интуитивно блоки задач с управляющими элементами. Кроме того, функциональное моделирование предполагает создание в случае необходимости глоссария, в котором раскрываются условные обозначения и термины. В результате вы с клиентом, руководителем, другими сотрудниками при обсуждении проблемы говорите на одном языке.
Простота и высокая скорость создания модели. Конечно, научиться моделированию не так просто, как кажется. Ведь схема — это, по сути, сверхплотная подача информации, что очень хорошо для понимания, но для реализации такой подачи требуется особый подход. Мозг аналитика выступает в данном случае как очень мощный пресс с одной стороны, и фильтр – с другой. Но с опытом этот процесс становится очень быстрым. В результате вы получаете инструмент, который поможет и самому разобраться, что же происходит в той или иной системе, и при помощи созданного в сжатые сроки наглядного пособия проиллюстрировать важные моменты коллегам или заказчикам.
Дисциплина и отсутствие ошибок. Стандарт IDEF0 предполагает строгие рамки и правила. Такой подход дисциплинирует, а привычка действовать в рамках стандарта помогает избежать ошибок по невнимательности. Любые нарушения стандарта становятся сразу заметны.

В чем трудность применения IDEF0

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

При этом я считаю, что бизнес-аналитик — это не совсем профессия, бизнес-аналитикой занимается каждый руководитель бизнеса или разработчик каких-то систем, который анализирует бизнес и стремится выстроить наиболее эффективную систему. Именно для этих людей и для этих целей предназначен инструмент IDEF0. А потому очень важно при составлении функциональной бизнес модели «как есть» постоянно советоваться с руководителем компании, чтобы не совершить ошибки, которая повлечет за собой автоматически ошибки на этапах декомпозиции. Также на последующих этапах могут потребоваться дополнительные согласования с руководителями структурных подразделений и сотрудниками.

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

Как правильно называются стрелки в IDEF0

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

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

Основные стрелки в IDEF0:

Input
Control
Output
Mechanism

Вместе этот тип элементов называют ICOM, т.е. это сокращение от названий всех типов стрелок. Именно так постоянно пишут в самом стандарте. Потому, когда вы видите упоминание ICOM, просто помните, что это значит — «Input, Control, Output, Mechanism».

Как это переводится?

Input — Ввод
Control — Контроль
Output — Вывод
Mechanism — Механизм

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

Input и Output

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

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

Но это неправильно. Input – это не Вход, а Ввод. И точно такая же ситуация со стрелкой Output, которую часто ошибочно переводят как «Выход».

Дело в том, что мы описываем функциональную модель, и наши стрелки граничат с блоком функции (F). И, соответственно, мы должны сконцентрироваться на том, что после ее выполнения мы должны что-то получить и вывести. А для того, чтобы что-то вывести, нужно для начала что-то ввести.

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

Но чтобы функция выдала готовый продукт, нужно для начала ввести необходимые ингредиенты. Они не смогут сами “войти” во вход, их именно нужно подать туда, где будет выполняться производственный процесс (наша функция), т.е. ввести их в цикл производства. Именно ввести.

Далее на выходе мы получим, например, шампунь, моющее средство или любой другой продукт. Но он также не будет сам “выходить”. Более того, нам на самом деле не слишком принципиально, будет ли место выхода находиться в определенной пространственной точке. Где будет удобно реализовать, там и будет выход. С точки зрения функционального анализа это не интересно, это вопрос к монтажникам и инженерам. Нам важно понимать, что наш готовый продукт нужно вывести, а потому их функции должен быть именно вывод, а не выход.

Кроме того, перевод Input – Ввод, а Output – Вывод, наиболее точен. Именно так эти слова переводятся с английского языка.

Control и Mechanism

Далее, ошибки в переводе слова Control также постоянно повторяются, и они столь же некорректны. Часто Control переводят как «Управление». И это неправильно.

Если мы говорим об управлении, то подразумеваем, что есть какая-то воля, что мы напрямую чем-то управляем и принимаем решения. Но если мы занимаемся функциональным анализом предприятия, то управлением здесь занимаются люди. А потому именно об управлении стоит говорить, когда вы применяете стрелки Mechanism, т.к. именно люди в данном случае – те самые инструменты, которые задействованы в вопросах управления. Именно люди занимаются тем, чтобы из ввода получить вывод.

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

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

Таким образом, контроль – это то, на что мы ориентируемся, что нами руководит, а не те решения, которые мы принимаем в процессе работы.

Если в качестве «Механизма» выступает компьютерная программа, то контроль уже заложен в ее коде. И при написании этого кода в том числе используются инструкции, правила и другие документы.

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

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

Как видите, все просто. Если вы правильно переводите термины, а именно:

Input — Ввод
Control — Контроль
Output — Вывод
Mechanism — Механизм

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

Модель работы швейного предприятия

В этом случае компания собиралась внедрять 1С. Управление производственным предприятием, и также нужно было навести порядок, чтобы каким-то образом стандартизировать и автоматизировать работу.

Цель

Поставленная задача: разобраться с тем, как работает производственная компания, предложить решения для автоматизации, стандартизировать работу, повысить ее эффективность.

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

Описание

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

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

Я создал модель, разделил все этапы работы на функции. Далее каждую из них мы с клиентами рассматривали с точки зрения процессов и возможности автоматизации. Например, выбиралась функция «Проектирование производства», и для нее выполнялась автоматизация.

Критика

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

Мы видим 7 блоков. IDEF0 по стандарту требует максимум 6 блоков.
В диаграмме используются такие фразы, как «исследование рынка», «проектирование». Это также ошибки. Если вы ознакомитесь с моим переводом стандарта IDEF0, то там описывается, что функции должны называться глаголом в совершенной форме, т.е. давать ответ на вопрос «что необходимо сделать». В данном случае вместо «Исследование рынка» правильно написать «Исследовать рынок. Не «Проектирование продукции», а «Спроектировать продукцию». Не «Проектирование производства», а «Спроектировать производство» и т.д. Есть и другие ошибки в названиях. Например, при декомпозиции хорошо видно название «Производство и реализация швейных изделий». Здесь не должны объединяться два разных действия союзом «И». Должно быть либо производство, либо реализация, точнее – «произвести» или «реализовать», так как по правилам нотации не должно быть союза «и», каждый блок описывается фразой с одним глаголом, который выражает функцию.

С другой стороны, несмотря на ошибки, диаграмма – рабочая. Проект длился около 2,5 лет, все этапы были автоматизированы успешно. В результате ответ на запрос о возможности выпуска продукции стал приходить не через 2,5 месяца, а в течение 10 дней, что для этого вида бизнеса – очень короткий срок. Были достигнуты и другие цели, в частности, опираясь на эту диаграмму.

Вывод: формально диаграмма неправильная, с точки зрения достижения цели – правильная.

Ещё пример моделирования в IDEF0

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

УФМТП. Универсальная функциональная модель торгового предприятия в нотации IDEF0

Источник