Аннотация

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

1. связывающие по данным — модели логической структуры данных,

2. связывающие по пользовательским интерфейсам — модели переходов между интерфейсами.

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

В статье разбирается методика формирования вопросов для обнаружения задач или проблем, возникающих тогда, когда одновременно протекают множество процессов с множеством используемых в процессах ресурсов. Методика — это микс концептуального анализа и ресурсного анализа ТРИЗ.

Методика была подготовлена и презентована на Летнем Аналитическом Фестивале (отличные выступления/мастер-классы и общение со своими), в записи доступна по ссылке.  

Введение

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

1. модель состояний,

2. модели «исполняемых» бизнес-процессов BPMN,

3. usecase диаграммы,

4. и другими моделями.

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

Рассмотрим пример: нам нужно загрузить из системы А в систему Б клиентов и их продажи (данные выгружаются файлами). Причем продажи строго после клиентов (нельзя загрузить продажи неизвестного для системы Б клиента, по какой-то причине). У нас есть два реализованных процесса: загрузка клиентов, загрузка продаж. Нужно как то организовать порядок исполнения этих двух процессов.

Эту задачу можно решить разными способами.

Вариант 1. Через дополнительный статус загрузки и связанную с ним логику обработки. 

Логика обработки:

1. Система ожидает новых файлов.

2. При получении пачки файлов, смотрим на их состав.

3. Если есть файлы с клиентами, то загружаем клиентов, и далее, если есть файлы продаж продолжаем загружать их. Когда продажи загружены, опять входим в ожидание.

4. Если файлов с клиентами нет, то загружаем файлы с продажами, входим в ожидание.

Вариант 2. Разведение загрузки через время.

Можно выгружать и загружать клиентов с 00:00 по 01:00, а потом продажи с 2:00 по 3:00.

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

Решение первой задачи записано в нотации UML State + Use case сценарий, решение второй — в диаграмме Ганта, и для описания каждого из вариантов, этих моделей достаточно.

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

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

Поэтому ставить задачи(task) проектировщику «нарисуй модель в такой‑то нотации», не разобравшись в том, какая задача(problem) решается — не разумно. Разумно ставить задачи(task) по решению задач (problem), находить это решение, описывая решение в подходящей под это решение нотации. 

P.S. Дополнительно отмечу, что какое-то время назад мне казалось, что изучив нотации UML, BPMN, Ганта, EER мне будет достаточно инструментов для моделирования. Но решая задачи на практике, внезапно оказалось, что этих нотаций недостаточно и приходится придумывать новые, для решения указанных задач. Если не хватает инструментов — придумывайте свои, в конце концов, наша цель — решить задачи(problem), а не нарисовать модели (что есть средство, а не цель). Ниже будет пример такой нотации.

Продолжаем введение

Откуда берутся задачи, которые нам нужно решить? 

Бизнес и системный аналитик скажут — от стейкхолдеров. Стейкхолдеры формулируют «требования», по которым аналитик проектирует модели.

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

1. какой то топ-менеджер, которому нужно улучшить бизнес-процесс за счет ИТ,

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

Откуда менеджер «на месте» берет «требования» к ИТ системе? «Требования» стейкхолдеров чаще всего имеют объективную природу и вытекают из спроектированных им решения каких‑то задач или проблем (ссылка). А откуда он берет эти задачи? Из своего опыта, которых хранится в памяти и решений видимых ему проблем. Достаточно часто он забывает или не видит какие-то задачи или проблемы, менеджеры редко изучают системный/бизнес анализ и, в конце концов, они тоже люди.

Что же делать?

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

Каким образом обнаруживать эти задачи? 

Автор обнаружил, что при автоматизации/цифровизации бизнес-процессов очень большое число задач возникают из нескольких источников:

1. задачи как обеспечить требуемые качества или достигнуть баланса качеств бизнес-процесса, чему посвящены масса методик: экономический анализ, ФСА, ТОС, Теория массового обслуживания, TQM и пр. Отдельно упомяну проектирование баланса качества ИТ системы и ее использования: ссылка

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

Вступление

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

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

1. ИТ систем, не ИТ систем, 

2. людей, 

3. информации, 

4. материи, энергии, 

5. денег 

6. и внешних сервисов. 

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

Процесс использования, как правило, декомпозируется на несколько частей (при самой детальной декомпозиции — на базовые атомарные процессы взаимодействия — описанные во введении). Будем называть эти части подпроцессами. Каждый подпроцесс проектируется в разных аспектах (в общем случае, в аспекте последовательности действий, аспекте структур передаваемых данных, аспекте UI/API и аспектах обеспечения качеств — безопасность, удобство и понятность интерфейсов, доступность, производительность, актуальность и пр.) с помощью каких-то методик.

Например, по трем подпроцессам спроектировали use case сценарии:

Далее, в общем случае, возникает задача функциональной композиции = объединения подпроцессов в общий процесс так, чтобы этот общий процесс был системой — выполнял какую-то задачу. Моделирование композиции зачастую производится с помощью каких-то методик, например, более общий use case сценарий, UML и/или BPMN.

Достаточно ли этого? Эти схемы можно прочитать так: 

Один клиент делает один заказ, который один менеджер в одно время обрабатывает (звонит клиенту, чтобы убедиться в благонадежности клиента) и далее один кладовщик отгружает с одного склада.

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

Почему это важно? А представьте себе ситуацию:

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

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

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

Есть два пути решения этой проблемы.

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

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

Каким путем вы пойдете — выбирать вам, но по опыту, специалисты, владеющие методикой, ценятся выше.

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

Итак, в этой статье представлена методика поиска задач и проблем, применимая к случаям:

1. Множественности процессов и участвующих в этих процессах ресурсов (что такое ресурс – объясним чуть позже),

2. Декомпозиции и композиции процессов и ресурсов,

3. Несинхронизированной активации и движении подпроцессов, 

4. Изменчивости процессов и ресурсов,

5. Разнообразия вариантов дизайна процесса (универсализация / специализация) при логической типизации физических процессов.

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

Универсализация/специализация дизайна при формировании процесса

Откуда вообще берется множественность процесса?

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

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

При систематизации возникает задача «группировки по одинаковости» (более точно — универсализации/специализации дизайна) с определением того, что должно работать одинаково. Но это можно сделать по-разному.

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

1. выбора товара, покупки товара на кассе,

2. выбора готовой еды, покупки готовой еды на кассе.

Вообще говоря, их можно скомпоновать разным образом.

1. Можно идти в духе SOA — делать едиными одинаковые по функции процессы. В этом случае у нас выбор еды и товаров, и покупка еды и товаров будет единообразным, еда и товары будут на одних полках, обслуживание будет на одних кассах.

2. Можно идти в духе MSA — делать разными процессы с разными продуктами. В этом случае у нас будет отдельные процессы выбора и покупки еды и процессы выбора и покупки товаров. Грубо говоря, формат — кафетерий внутри магазина.

3. Возможны и промежуточные или миксованные варианты. 

Таким образом, первая задача, которая решается при работе с процессами — это задача их систематизации = получения в чем-то одинаковых моделей процессов.

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

Оказалось, что для решения задач поиска задачи/проблем, удобно рассматривать процесс так, как это делается в ТРИЗ, при котором процесс представляется как взаимодействие ресурсов, где ресурсом может быть: 

1. Люди, компетенции людей,

2. Материя или энергия,

3. Информация,

4. ИТ системы,

5. Не ИТ системы и инструменты,

6. Деньги,

7. Внешний сервис (внешний процесс, который запускается и обеспечивает каким-то ресурсом наш процесс при его протекании).

Ресурс в процессе

1. Создается,

2. Потребляется/уничтожается, 

3. Используется,

4. Изменяется. 

На примере процесса кассового обслуживания, это можно представить на схеме:

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

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

Детерминированные/недетерминированные траектории при композиции процессов

Возникает вопрос — а всегда ли после первого подпроцесса выполняется второй? На самом деле нет. Можно выделить три случая:

1. Есть какой-то алгоритм, который детерминировано запускает второй процесс после первого. И тогда задача — определить алгоритм.

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

3. Нет ни алгоритма, ни человека. Дальнейшая траектория идет в случайном порядке.

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

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

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

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

Множественность процесса одного типа

Мы переходим к рассмотрению аспекта множественности. И прежде всего — множественности ресурсов и процессов одного типа.

Какие проблемы или задачи могут возникнуть?

(Далее, для простоты, два разных экземпляра процесса мы будем называть двумя процессами одного типа, два разных экземпляра ресурса — двумя ресурсами одного типа).

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

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

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

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

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

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

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

В первом случае, один клиент обслуживается на двух кассах одновременно в разных покупках. Если это происходит по разным товарам, то это вполне допустимые случаи (почему бы и нет).

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

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

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

В матрице перебираются варианты:

1. процесс — один или несколько (разные),

2. для каждого типа ресурса – один или разные.

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

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

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

1. строка 2: может ли быть задача или проблема, если одновременно в разных процессах покупки, разные кассиры обслуживают разных клиентов на разных кассах, пробивая в одном чеке разные товары с оплатами разными деньгами? Да, если случайно два кассира работают с одним чеком. Это нужно предотвратить, потому что иначе будет хаос в учете. Вариант решения — связывать чек с кассой в процессе, когда он вводится/пробивается.

2. строка 3: может ли быть задача или проблема, если одновременно в разных процессах покупки, разные кассиры обслуживают одного клиента на разных кассах, пробивая в одном чеке разные товары с оплатами разными деньгами? Проблема/задача сходу не видна, может быть осознание придет позже.

3. строка 4: может ли быть задача или проблема, если одновременно в одном процессе покупки, разные кассиры обслуживают одного клиента на одной кассе, пробивая в одном чеке один товар с оплатой одними деньгами? Да, например, если кассиру‑стажеру помогает какой‑то кассир‑наставник. В этом случае, возможно, нужно запомнить для разбора полетов или для дополнительной мотивации, не только какой кассир‑стажер работал, но и какой наставник ему помогал.

4. строка 5: может ли быть задача или проблема, если одновременно в одном процессе покупки, один кассир обслуживает разных клиентов на одной кассе, пробивая в одном чеке разные товары с оплатой одними деньгами? Да, например, в случае покупки вскладчину. Нужно это обеспечить, с одной стороны, с другой — нам для этого ничего делать не нужно, с взаиморасчетами между клиентами они разберутся сами.

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

1. (положительный) в этом кейсе что-то должно быть обеспечено = возникает задача обеспечения,

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

3. (никакой) этот кейс не значим = ничего делать не нужно,

4. (серая зона) этот кейс непонятен, возможно, когда-то потом появятся какие-то инсайты.

В случае если в кейсе что‑то должно быть обеспечено или предотвращено, то, разумеется, нужно понять «чтобы что» = какие выгоды или потери будут для бизнеса, если этого не сделать. 

Быстрый отсев случаев

Разумеется, если мы будем рассматривать все сочетания, то мы потратим очень большие усилия. Для 9 ресурсов мы получим 1024 строки, для 19 ресурсов — миллион. Как делать быстрее?

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

Для этого составляем такие матрицы

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

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

1. это один клиент, так ли это?

2. это один кассир, так ли это?

3. это один товар, так ли это?

4. это одна касса, так ли это?

5. это одни деньги клиента, так ли это?

Если на все вопросы мы не получаем исключение, то наше решение о обеспечении/недопущении можно считать верным, иначе нужно дальше «раскрутить» исключение, добавив новые ресурсы в рассмотрение.

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

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

Изменчивость ресурса

Следующий крупный аспект — это изменчивость. 

В процессе выполнения ресурс может измениться (к примеру, временно или постоянно выходить из строя по внутреннему жизненному циклу). Для анализа таких кейсов мы составляем матрицу анализа изменения ресурса, перебирая разные ресурсы. Для каждой строки мы также ищем физические смыслы кейсов и ищем задачи обеспечения/недопущения.

Каждая строка читается так: 

1. Может ли в процессе измениться кассир? Ну вообще говоря, кассир тоже человек. Может ли он довести процесс до конца? Много ли случаев, когда не может? Неясно…

2. Может ли в процессе измениться касса? Да. Например, касса вышла из строя. Нам нужно решить задачу — как перенести обслуживание на новый кассовый аппарат. 

3. Может ли в процессе измениться товар? Да, например, если оказывается, что он бракованный. Что делать? Либо отправить клиента/кассира заменить товар, заморозив его процесс на время поиска (заморозка-разморозка) либо отправить дополнительного сотрудника (и у нас появляется новый ресурс в процессе = нужно рассмотреть матрицу анализа множественности для него).

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

Изменчивость процесса

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

Внутреннее время в процессе

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

Для начала, выделим в процессе шаги:

1. Активация,

2. Обычное протекание шагов процесса, уже спроектированное перед композицией, поэтому не интересное.

Несоответствия времен разных процессов, несинхронность процессов

Подпроцессы могут завершатся не синхронно

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

1. Либо он будет ожидать в «буфере», возникают задачи организации буфера (разберем их позднее),

2. Либо обнаруживается задача/проблема обеспечить синхронное завершение процессов для обеспечения ресурсами следующего процесса.

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

Задачи организации буфера

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

При появлении буфера, как объекта проектирования, нужно решать задачи

1. Вхождения ресурса в буфер,

2. Организации ожидания ресурса в буфере,

3. Выход ресурса из буфера,

4. Возврат ресурса в буфер,

5. Изменение ресурса в буфере.

Для организации ожидании ресурса, нужно решать задачи:

1. Людей нужно где‑то как‑то размещать и занимать, клиенты могут выбирать дополнительный товар из прикассовой зоны, а вот что будут делать кассиры, ожидая клиентов с покупками?

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

3. Физику — хранить, как то организовать место хранения.

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

Соответствие множественности буферов и процессов

У одного процесса всегда один буфер? Вообще говоря нет, это может быть организовано по-разному. Рассматривая один тип процесса, нам нужно решить задачу топологии связи буферов и ресурсов.

Решить эту задачу можно по разному. Для процесса одного типа могут быть варианты:

1. Один буфер для одного процесса, например, на каждую кассу — свой буфер клиентов,

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

3. Возможны и смешанные варианты, которые еще и изменяются во времени, например, выделенная очередь VIP обслуживания в аэропорту, но только при наличии VIP клиентов.

Для процессов разного типа могут быть варианты:

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

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

3. Возможны и смешанные варианты, которые изменяются во времени.

Задача активации

В общем виде,

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

1. должны организовать буферы уже готовых ресурсов, 

2. и/или дополнительный процесс поиска ресурсов, но на время поиска — буфер для готовых ресурсов,

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

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

Задача активации при множественности процессов одного типа и общем буфере

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

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

У нас есть 

1. буфер клиентов,

2. буфер операторов.

Процесс запускается при наличии клиента и свободного оператора.

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

1. Для клиентов мы решаем, кого первого обслуживать, если появился свободный оператор,

2. Для операторов мы решаем, какой следующий оператор из свободных будет задействован, если их несколько и поступает звонок.

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

Концептуальное «расслоение» ресурса

Ресурсы в буфере неодинаковы. Но нам не важна неодинаковость типа «это клиента зовут Петя, а этого Татьяна», если мы не решили на Татьянин день всех клиентов с именем Татьяна обслуживать вне очереди (пример расслоения).

Возможно провести концептуальное «расслоение» ресурса, используя сам процесс, его активацию и заморозку/разморозку.

Например, рассматривая общий пул клиентов в буфере и имея активацию и процесс обслуживания, мы можем сделать «расслоить» этот пул клиентов:

1. по активации: каких клиентов мы будем активировать раньше других по другим причинам, нежели время появления их в буфере («без очереди»)? Например, VIP клиентов, клиентов из черного списка.

2. по процессу обслуживания: как мы можем по разному обслуживать? И далее, как разделяются клиенты по этим видам обслуживания? Например, мы можем обслуживать через AI, через общую линию операторов, а можно персональным менеджером.

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

Выявление ресурсов через общность

Возможно провести некоторый анализ общности, задав вопрос «Что общего может быть у клиентов, которые находятся в ожидании обслуживания?» или «Есть ли общие причины обслуживания клиентов?» Можно выделить проблему, с которыми клиент звонит, и рассматривать проблему как связанный с звонком клиента ресурс. 

Имея новый ресурс, можно провести мультиресурсный анализ:

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

Задача активации при множественности процессов разного типа и общем буфере

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

Например,

Если мы процессы возврата и покупки обслуживаем одним буфером связок кассир+касса, то при появлении свободной пары кассир+кассы нужно принять решение — мы запускаем покупку или возврат, какой алгоритм по которому мы выбираем следующий процесс?

Это типовая задача диспетчеризации и маршрутизации.

Заморозка — разморозка и изменение ресурсов

В каких‑то случаях у нас может возникать заморозка/разморозка процесса. Например, клиент обнаружил брак в покупаемом на кассе товаре (или на товаре нет ценника) и клиент ищет замену. Возникает вопрос — что делать с товарами, которые он пробил, которые у него были в корзинке, с деньгами, если была оплата, если мы будем продолжать обслуживание других клиентов?

В общем случае, у нас возникают задачи:

1. как организовать буфер замороженных ресурсов? Какова его топология относительно процессов?

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

При размораживании 

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

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

Как перебирать возникающие при этом задачи?

Рассматриваем процесс: 

И принимаем решения: каким ресурсам мы будем давать возможность замораживать, а каким нет. В нашем примере, мы 

1. замораживаем клиента, пробитые на кассе товары и принятые деньги. Пробитые на кассе товары и деньги нужно как‑то заморозить — организовать для них буфер замороженных ресурсов: какое то место, куда они будут отложены и выданы нужному клиенту/связаны с покупкой, когда он вернется.

2. По оставшимся ресурсам может либо произойти замена. Кассир и кассовый аппарат могут изменится.

3. Какие‑то нам могут быть не важны. Например, оставшиеся в корзинке товары клиента и деньги в его кошельке, клиент забирает с собой при поиске замены брака.

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

Для перебора всех случаев, мы анализируем их при помощи матрицы замен при разморозки:

Каждая строка читается так: 

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

Отмена

В случае отмены нам нужно решить задачу — что делать с замороженными или созданными ресурсами в процессе.

Множественные ресурсы в множественных процессах

Эти кейсы будем разбирать на примере формирования, обработки и отгрузки заказов интернет-магазина.

Процесс выглядит следующим образом:

1. клиент выбирает товар на сайте и оформляет заказ на доставку,

2. менеджер заказа проверяет заказ, не является ли он фейковым и уточняет адрес у клиента (много клиентов вводят адрес не корректно),

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

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

Если в одном процессе ресурс участвует, а во втором — нет, то задач или проблем не возникает.

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

1. клиент создает заказ и одновременно менеджер проверяет его качество,

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

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

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

Кроме того, сама проблема возникает 

1. в момент активации одного процесса, когда второй находится в состоянии выполнения,

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

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

Анализ активации при выполнении

Создаем матрицу анализа активации при выполнении

Перебираем 

1. попарно процессы (в которых возможны общие ресурсы), 

2. для каждой пары смотрим два сочетания: (активируется, выполняется), (выполняется, активируется), 

3. смотрим сочетания общих типов ресурсов, убирая случаи полностью разных ресурсов.

Читаем строки:

1. Может ли быть задача или проблема, если активируется процесс сборки при выполнении процесса контроля качества по тому же самому заказу? Видны три кейса: а) базовый, мы не должны запускать сборку без проверки качества заказа по новому, непроверенному клиенту. На то и существует процесс контроля качества. Организовать это можно, придав статусы заказа, которые будут учитываться при организации процесса. б) Если клиент надежен, но адрес новый, то заказ можно начать собирать, а отгрузку заморозить до момента подтверждения адреса. Это можно организовать путем статусов клиента и адреса. в) Если клиент надежен, адрес проверен, то контроль качества вообще не нужен.

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

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

4. Может ли быть задача или проблема, если активируется процесса поиска и оформления при выполнении процесса контроля качества по разным заказам одного клиента? Да, в случае когда клиент оформил заказ, получил письмо «Спасибо за заказ» с товарными рекомендациями и сразу же воспользоваться этим. В ряде случаев, клиенту нужен дополнительный товар, а в ряде случаев — замена. Чтобы это обеспечить, возможно сделать одновременное совместное редактирование заказа.

5. и т. д.

Анализ активации при связном ресурсе в буфере

Создаем матрицу активации одного процесса, когда тот же ресурс находится в буфере другого процесса (по тем процессам и ресурсам, у которых есть буферы, изолированные от буфера первого процесса)

Перебираем

1. попарные процессы,

2. пары случаев (процесс не запущен, но ресурс в буфере / активация процесса), (активация процесса / процесс не запущен, но ресурс в буфере), если буфер для процесса существует (в нашем случае, для процесса создания заказа нет буфера по клиентам),

3. смотрим сочетания общих типов ресурсов, убирая случаи полностью разных ресурсов.

Читаем строки матрицы

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

2. Может ли быть задача или проблема, если активируется процесс контроля качества по заказу, находящегося в буфере процесса сборки? Да, задача аналогична задаче из случая 1.

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

4. Может ли быть задача или проблема, если активируется процесс создания заказа, если у клиента есть этот же заказ в буфере сборки? Нет, это невозможно, ничего делать дополнительно не нужно.

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

Выявление ресурсов через общность, пример 2

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

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

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

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

2. фильтры и сортировки товара, которые клиент успеет купить с доставкой в том же рейсе.

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

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

P. S. Задать правильный вопрос — искусство, так как вопрос фокусирует мышление.

1. Если спросить бизнес как он работает/будет работать, он скажет: «Планирую регулярные рейсы по календарю» (имея в виду основные кейсы его работы).

2. Вопрос «А нужны ли другие схемы работы», ответ будет «Нет».

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

Внутреннее время в процессе, общий случай

Внутри внутреннего времени процесса есть

1. Активация,

2. Обычное протекание шагов процесса, уже спроектированное перед композицией, поэтому не интересное,

3. Может возникнуть заморозка-разморозка,

4. Может возникнуть ситуация, когда в шаге процесса нужно учитывать ресурсы, которые уже созданы/изменены, например, когда идет возврат назад по процессу или когда в другом процессе этот ресурс уже создан/изменен,

5. Может возникнуть отказ,

6. Может возникнуть зависание.

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

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

Например, 

1. клиент выбрал какой-то товар на сайте интернет-магазина, положил его в корзину,

2. клиент выбрал какой-то способ его получения, среди вариантов способов и сроков каждого способа получения,

3. потом внезапно клиент вернулся обратно на выбор товара.

Задача, которую нам нужно решить в данном случае: нужно ли нам учитывать выбранный способ и сроки этого способа получения товара при выборе товара?

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

P.S. Частый кейс возврата — рекомендации докупить товар в письме спасибо за заказ.

Дополнения. Связывания ресурсов

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

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

1. корзинка клиента — это материализованная связка товара и клиента,

2. деньги у клиента — это связка деньги и клиента.

Сам процесс — это связывание и пересвязывание ресурсов.

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

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

Связка физики и информации

Очень частой тактикой является связывание физики и информации

При этом возникают задачи

1. Какие физические ресурсы нужно превратить в информацию и в какой структуре?

2. Как связать ресурсы?

3. Как не допустить/мониторить/уменьшить ущерб развязывания ресурсов?

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

Физические ресурсы имеют собственный «жизненный» цикл — они создаются, изменяются, уничтожаются. Задача поддержания связывания информации о ресурсе включает в себя задачу по поддержанию соответствия информации и физики о собственном статусе ресурса, если это нужно для какого-то процесса.

Другие связки

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

Например, один заказ может быть только у одного клиента

Разумеется, мы также должны решать задачи:

1. Как связать ресурсы?

2. Как не допустить/мониторить/уменьшить ущерб развязывания или появления недопустимой связки ресурсов?

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

Мультиресурно-процессная карта или ресурсно-процессная карта и буферами и связками (пример новой нотации)

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

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

P.S. Эта схема — одна из примеров новых нотаций, которую автор вынужден применять из-за отсутствия этих объектов проектирования в нотациях UML / BPMN и других, известных автору.

Дополнение 2. Декомпозиция и композиция ресурса

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

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

Например, можно начать оформлять покупку по части выбранного клиентом товара (возможно в каких-то случаях в этом есть смысл):

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

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

Итого

Композируя процессы, мы решаем задачи

1. С чем мы работаем: компоновка объектов физического мира в объекты мышления, выбор объектов мышления,

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

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

4. Процесс принятия решения: информация для принятия решений, возможные маршруты и информация по ним,

5. Ресурсы: структура ресурса и процессы его обеспечения (создание, вхождение ресурса в буфер, ожидания и размещение ресурса в буфере, стабильность ресурса в буфере, выход и возврат ресурса из буфера, изменение ресурса в буфере),

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

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

8. Буферы ресурсов и связок ресурсов: структура буфера по траектории (основной, замороженный, возвратный), топология буферов и процессов (один тип процесса – один буфер/много буферов на каждый процесс, разные типы процессов – один буфер, разные буферы),

9. Выполнение процесса: задачи пересечения по ресурсам (один ресурс в разных процессах одного типа, один процесс с разными ресурсами одного типа, дубль ресурса в процессе, дубль процесса), изменение ресурса в процессе, изменение процесса, заморозка/изменение процесса при наличии связных ресурсов в других процессах этого же типа ранее/позже либо другого типа),

10. Заморозка/разморозка процесса: буферы замороженных ресурсов, изменение ресурса при разморозке,

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

12. Отмена: что делать с созданными, измененными ресурсами и замороженными ресурсами,

13. Зависания: как диагностировать выполнение процесса и решать задачи экстренной отмены.