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

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

Будет 3 темы:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вы видите что довольно обыденный процесс, всем понятный уже без детализации и всех альтернативных путей может из 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).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ограничения

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

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

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

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

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

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

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

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