Новое - это хорошо забытое старое: IDEF0 и IGOE для анализа контекста

- знакома ли вам такая техника?

- да, мы про нее слышали.

- а почему не используете?

- так она же слишком простая

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

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

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

Речь пойдет о таких форматах описания границ процесса и верхнеуровневого контекста как IDEF0 и его реинкарнации IGOE.

Немного теории...

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

Процесс или активность в рамках процесса представляется в виде «чёрного ящика» со входами, выходами, управлением и механизмом, который постепенно детализируется до необходимого уровня. Стандарт предусматривает определенные правила отображения соответствующих потоков-стрелок:

• стрелка входа всегда приходит в левую сторону блока процесса/активности и отражает задачи или ресурсы, которые необходимо переработать в рамках процесса/активности;

• стрелка управления приходит в верхнюю сторону, под потоком управления подразумевается любое управляющее воздействие, необходимое для выполнения данногопроцесса и/или данной активности - положения, инструкции и т.д.;

• стрелка механизма приходит в нижнюю сторону и отражает те ресурсы или механизмы, с помощью которых будет выполняться в рамках данного процесса/активности;

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

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

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

IGOE - является своеобразной реинкарнацией диаграммы IDEF0, которая также используется для описания контекста функционирования того или иного процесса. Аббревиатура IGOE представляет собой сокращение от основных элементов:

• Input (вход) - информация, материалы, люди;

• Guides (управление) - политики, законы, регламенты, инструкции и т.д.;

• Outputs (выходы) - результаты выполнения процесса, продукты, информация, люди т.д.;

• Enablers (исполнители, механизмы и т.д.) - системы, оборудование, инструменты и т.д.

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

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

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

Ниже пример модели IGOE для банкомата:

Более подробно про модель IGOE можно почитать, например, тут.

Переходим к практике...

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

Как это работает? Обычно на своих семинарах я предлагаю такую задачу "на разогрев":

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

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

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

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

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

1. Определим сам процесс или функцию исходя из поставляемого результата - ответив на вопрос, "Что и зачем мы делаем?", формулируем название - "Выдать кредит". Дальше мы сможем уточнить, какие виды кредитов мы выдаем, но для начала анализа вполне достаточно определить на верхнем уровне.

2. Собственно, ожидаемым результатом будет "Выданный кредит". Отражаем на схеме.

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

4. Определим входы - "Что нам необходимо получить, чтобы можно было принять решение о выдаче кредита?". Исходя из обычного житейского опыта (кредиты так или иначе брали все за редким исключением) - как минимум, анкета клиента, заявка на получение кредита, информация о залоге. Уверены ли мы в том, что знаем все входы? Если нет, то у нас появляется вопрос, который мы можем потом задать

5. Теперь попробуем определить "механизмы и исполнителей". Знаю ли я, кто будет выполнять данную функцию? Допустим, что нет. Я могу только предположить, что это будут какие-то подразделения банка. Поэтому позволю себе оставить стрелку не подписанной, но со знаком вопроса, чтобы потом не забыть об этом спросить.

6. Последний штрих - "управление". Опять же житейский опыт подсказывает, что здесь будут какие-нибудь правила, регламенты, положения, инструкции Центрального Банка (ЦБ). Кто их разрабатывает и является источником? ЦБ мы уже выявили, отмечаем на схеме. По остальному - снова вопросы: какие регламенты? какие правила? кто источник? Их фиксируем.

Таким образом мы получаем первый вариант схемы.

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

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

Можно привести разные критерии того, когда "уже хватит". Я обычно определяю этот момент следующим образом:

- схема все еще помещается на лист формата А4

- количество стрелок с каждой из сторон не превышает 5-6 штук (если требуется больше, то, скорее всего, вы уже начинаете уходить в детали, т.е. спускаетесь с "высоты полета птиц")

- элементы на схеме и надписи легко идентифицируются и читаются

И самое главное - я понимаю, что у меня появилось общее представление о том, что мне предстоит анализировать.

И пара слов в заключение

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

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

Техники довольно просты и наглядны, схему можно набрасывать непосредственно общаясь с заинтересованными сторонами, т.к.не требуется наличие специальных инструментов и программного обеспечения, достаточно иметь под рукой лист бумаги и карандаш. Если же есть время и необходимо использовать программное обеспечение, то для IDEF0 вполне подойдет Visio, Draw.io. К сожалению, я пока не встречал программного обеспечения, в котором бы поддерживался формат IGOE. Возможно, это идея для небольшого стартапа.

Отдельно отмечу, что модели IDEF0 и IGOE не являются единственными для определения границ процессов или деятельности и описания существующего окружения на верхнем уровне.

Предлагаю поделиться вашими размышлениями на эту тему в комментариях, и мы продолжим изучать инструменты для анализа контекста. Расписание тренингов от Art of Business Analysis Новости и статьи по бизнес-анализу - https://t.me/artofba