Проектирование процессов

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

Будет 3 темы:

• Процесс, модели процесса и методы сбора информации. Формализация процессов, в текстовом, табличном и графическом форматах.
• Графические нотации, детально разберём нотацию BPMN. Основные паттерны проектирования GRASP.
• Методы анализа процессов, способы оптимизации процессов, контроль процессов.

Более детально про эту публикацию:

• Узнаем что такое процесс.
• Какие бывают процессы
• Модели AS IS и TO BE
• Методы сбора данных
• Зачем описывать процессы
• Какие формы описания процесса бывают
• Как работать с текстовым и табличным описаниям процессов

Ну что начнём?

Слово процесс произошло от латинского слова processus обозначающее течение, ход, продвижение.

Слово процесс используется во многих сферах, например.

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

Как видно все определения что-то объединяет, если их совместить получится:

Процесс – это воспроизводимая последовательность действий для преобразования входящего явления в исходящее явление.

Процессы вокруг нас.

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

Рассмотрим простой пример процесса похода в магазин за продуктами для приготовления блинов.

Цель процесса - обеспечить Вас продуктами для приготовления блинов.

Инициирующие события. Дома недостаточно продуктов для приготовления блинов.

Процесс покупки ингредиентов.

1. Составить список недостающих продуктов
   
2. На улице холодно?
3. Одеть верхнюю одежду.
4. Дойти до магазина.
5. Взять корзинку.
6. Найти недостающий ингредиент для блинов.
7. Положить его в корзинку.
8. Вычеркнуть ингредиент из списка.
9. Остались ещё ингредиенты не вычеркнутые из списка?
10. Пойти на кассу
11. Выложить товары на прилавок
12. Дождаться когда кассир пробьёт товары
13. Оплатить товары
14. Собрать товары в пакет
15. Вернуться с продуктами домой

Завершающее событие. Вы дома с продуктами.

Задание на дом. Попробуйте описать какой-то привычный для вас процесс.

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

Вернёмся к процессу выше.

На самом деле мы рассмотрели не все альтернативные сценарии этого процесса. У Вас может быть недостаточно средств на оплату продуктов, магазин может быть закрыт, не будет продуктов в магазине…

Или вы просто не захотите идти в магазин и закажите продукты домой, а это уже совсем другая история…

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

Любое проектирование процессов начинается с их исследования, сбора требований.

На самом деле есть две модели процессов.

Первая - это AS IS. Модель существующего состояния.

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

Вторая модель - TO BE. Это модель будущего состояния.

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

В итоге, мы получаем начальное состояние процессов из модели AS IS и то как они должны выглядеть из модели TO BE. Различие между ними и есть дельта изменений для достижения целевой картины процессов.

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

Чтобы разобраться в причинах длительных согласований, снимается картина, как процессы работают сейчас. В это входит процессы:

• как происходит подготовка договора,
• какой маршрут согласования,
• что происходит при необходимости внести изменения,
• и т.п. всё что касается этого целикового процесса.

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

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

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

При построении модели AS IS, модели текущего состояния, работы этой функции, вы увидите, что на самом деле эта функция состоит из некоторого количества более простых операций, которые можно разделить, убрать дублирующие и восстановить функционал работы БОЛЬШОЙ функции, с помощью нескольких поменьше, более простых, но исключающих дублирование. Это позволит снизить стоимость изменений и упростить понимание работы этого системного процесса.

Но как понять как устроен процесс? Для этого на Вам помогут методы сбора данных.

Какие методы сбора данных бывают:

• Работа с документацией (положения, регламенты, приказы, технические задания, спецификации на разработку и прочая регламентная документация описывающая процессы, включая нормативную документацию)
• Интервьюирование (интервью, опросы, анкетирование)
• Данные из учётных систем (статистика из по уже существующим, оцифрованным процессам, данные логов)
• Наблюдение (исследование как работает специалист или отслеживать процесс изменения данных при работе программы, в том числе данные логов)
• Эксперименты - самостоятельное изучение процессов. В случае недостаточности данных, можно самостоятельно пройти процесс, добавить в него изменения и посмотреть как они повлияют на него. Это позволяет увидеть как всё происходит от первого лица.

При построении модели AS IS важно отразить реальное положение дел. Получить именно то как процесс работает именно сейчас.

Для этого наиболее подходят методы сбора данных позволяющие собрать информацию о процессе из первоисточников:

• Это интервьюирование.

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

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

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

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

• Данные из учётных систем.

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

Способ позволяет получить информацию о процессе о которой не скажут пользователи, например, о своих ошибках.

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

• Наблюдение.

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

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

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

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

Для отображения модели можно использовать текстовое описание, таблично или использовать специализированные нотации. Для описание бизнес-процессов подойдёт текстовое описание по шагам или нотации BPMN, EPC. Для системных процессов наиболее подходят нотации UML activity, sequence, state machine, data flow.

Модель ТО BE должна отображать как должен быть процесс после изменений. Для этого используются:

• Интервьюирование заинтересованных лиц в процессе, для сбора требований и ожиданий от изменений.

Правила интервьюирования все те же самые. Но особенное внимание стоит уделить подбору респондентов.

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

Далее надо найти всех участников процесса для опроса произвести опрос с точки зрения выгодополучателя. Как изменения повлияют на участника. как с точки зрения участника должны произойти изменения.

Основываясь на этих данных приступать к преобразованию процесса.

• Методы оптимизации, с которыми познакомимся на шестой лекции.

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

• Данные из учётных систем помогут получить данные для анализа и оптимизации процессов.

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

Целевой процесс (TO BE) отображается аналогично модели AS IS для упрощения определения дельты изменений.

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

Частая ошибка такого подхода — это выдавать желаемое за действительное. Описание модели AS IS только по регламентам или иной документации, описывающей процессы, или переход сразу к модели TO BE может не принести результатов, так как не будет отражать действительность.

Но что же дают правильно описанные процессы?

• Снижение зависимости от субъектов, участников процессов.

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

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

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

• Снижение вероятности ошибок

Уже затронул тему ошибок выше. Развернём её подробнее.

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

Нужно инициировать проект по созданию продукта? Нужно провести исследование, нужен ли этот продукт? Нужно построить PnL нового продукта?

Допустим, разобрались с последовательностью, PnL сходится.

А модели нужно учитывать затраты на закупку оборудования? И как понять нужно ли будет его закупать или есть необходимые мощности? А учитывать их использование?

Если что-то будет потеряно, это может быть ошибкой в миллионы рублей.

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

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

• Упрощение внедрения изменений

Исследовав процессы и имея актуальную модель AS IS (как есть), для формирования плана изменений достаточно наложить её на модель TO BE (как будет).

Это позволит увидеть все фактические различия между моделями и составить план изменений чтобы TO BE стало AS IS *тут будет смайлик*

Возможно, вас смутило, модель AS IS должна прийти в состояние TO BE. Но в идеале, в этот момент модель TO BE станет AS IS.

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

Описанные процессы позволяют измерять их и подвергать контролю. Например, с помощью учётных систем и систем класса work flow которые помогают следовать процессам.

Ил с помощью систем логирования и «моделями здоровья» (health check model).

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

Есть несколько форматов описания процессов, глобально они делятся на:

• Тестовое описание.
• Табличное описание.
• Графическое описание.

Почему важно придерживаться единых форматов описания процессов.

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

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

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

Какие же общепринятые способы описания процессов есть.

Самый простой и универсальный способ писать процессы - это текстовый способ описания. Все кто могут читать на выбранном вами языке смогут понять описание процесса.

Описывая процесс текстом главное помнить:

• Описание процесса должно быть непротиворечиво.
• Описание процесса должно быть однозначно.
• Процесс не существует в вакууме.

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

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

Текстовое описание подходит для простых процессов, преимущественно бизнес-процессов.

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

Частный случай текстового описания, но достаточно распространённый это для выделения в отдельный тип.

Это табличное описание, в нём также важны:

• непротиворечивость,
• однозначность.

Отличие табличного описания от текстового, это явное выделение блоков процессов в виде таблицы.

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

Это позволяет описывать преимущественно не только бизнес-процессы но и системные. При этом по такому описанию можно легко писать тест кейсы или производить ПСИ.

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

Более явно можно будет увидеть моделируя процесс в одной из графических нотаций. Кстати о них…

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

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

Ограничения

• Заказать книгу может только аутентифицированный пользователь.
• Заказ книги может происходить только в библиотеках в которых она есть в наличии.
• Заказ может быть оформлен пользователем без задолженностей.
• и т.п.

Графический тип диаграмм подходит для описания сложных процессов. Особенно если мы говорим про системные процессы.

Сегодня вы прочитали:

• Зачем описывать процессы.
• Как их правильно описывать.
• Что процесс - это воспроизводимая последовательность действий для преобразования входящего явления в исходящее явление.
• Процессы окружают нас, биологические, физические, бизнес-процессы, информационные и не только.
• Познакомились с моделями AS IS и TO BE.
• А также с методами сбора данных.

• Зачем описывать процесс
• Какие формы описания процесса бывают

В следующей публикации расскажу:

• Зачем нужны нотации
• Какие нотации бывают
• Архитектурная база (паттерны grasp)
• BPMN
• Различия между проектированием процессов

До новых встреч.

Хотите узнать больше, подписываетесь на мой канал в Телеграм Analog.

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

Разработка требований к программному обеспечению. Карл Вигерс и Джой Битти.

Аналитическая культура. Карл Андерсон.