Описываемый раздел входит в пакет сервисов проектных элементов БП наряду с разделами «Процессы» и «Статистика», описанных в предыдущих публикациях.

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

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

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

Описанная аналогия хотя и выдумана, но отнюдь не надумана. Даже в функциях некоторых бизнес-процессов изначально заложена изрядная доля неопределённости. Представьте, сколько хлопот может доставить процесс с таким невинным названием, как «Торги». В любой момент торгов может возникнуть непредвиденная ситуация, которая должна в корне поменять не только дальнейшие наши действия, но и заставить переделать и то, что уже было пройдено! Простейший пример: клиент сперва согласился, а потом передумал. Причём передумал тогда, когда двигаясь по стандартной схеме уже завизирован договор и даже, может быть, подписан одной из сторон. Создавать доп. соглашение? Отказаться от работ? Перенести сроки, изменить стоимость? А если «урезаем осетра», то надо менять и техническое задание, которое было написано (и подписано) по предшествовавшему процессу гораздо ранее, пересчитывать часы… О куче возникающих согласовательных процедур даже говорить не стоит, их может быть бесконечно много.

Но важнее всего – что делать со схемой БП? Изменить согласно возникшим реалиям? Или эта ситуация исключительна, и больше никогда не повторится?

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

Как видно на скриншоте, типовое решение суть ситуативный запуск некоего бизнес-процесса, права на использование которого разграничиваются тут же. Например, такое типовое решение, как «Согласовать решение с ген. директором» могут добавить многие участники процесса, но удалить (фактически, отменить запуск) может только ген. директор. Обратите внимание, что права на добавление/удаление типовых решений в ситуацию раздаются не определённым пользователям или их группам, а ролям в бизнес процессе (в предыдущей публикации описана логика работы ролей в БП и трансляции роли в определённого пользователя). По факту это означает следующее: один и тот же пользователь системы в одном процессе может являться менеджером по продажам, а в другом – менеджером по повторным продажам, и в зависимости от своей роли иметь различные права на добавление типовых решений.

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

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

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

Категории объединяют в себе несколько типов ситуаций:

К примеру, в категорию «Торги» входят типы ситуаций, где требуется «Изменить стоимость» и «Изменить сроки», а в категорию – «Доп. соглашение к договору» - типы «Порядок подписания договора» и «Изменение сроков».

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

Автоматическое добавление типового решения регулируется в этом же справочнике, на детали «Типовые решения в категории»:

Выбор типового решения осуществляется из справочника типовых решений. Если указать, что типовое решение добавляется автоматически, система сразу после создания ситуации данной категории добавит такое решение в ситуацию. Иначе добавление такого решения будет возможно вручную (только для пользователей, чьи роли в процессе позволяют его добавлять). Галочка «Добавлять в начало очереди» управляет приоритетом выполнения типовых решений (скажем, что сделать раньше, когда решение по ситуации принято: согласовать решение с руководством или сперва сообщить решение клиенту?). Состояние ситуации указывает, когда следует начинать выполнение типового решения (оба упомянутых случая – для состояния «Решение принято», ведь пока у ситуации состояние «Поиск решения», к примеру, ещё нечего согласовывать и нечего сообщать клиенту).

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

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

Здесь же следует указать, кто (по мнению пользователя, вводящего ситуацию) может принять решение:

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

Изначально состояние ситуации устанавливается в «Поиск решения». Переходы между состояниями осуществляются автоматически по следующей схеме:

Согласно настройке типовых решений в справочнике категорий, сами типовые решения могут менять состояния ситуаций (например, если решение не устраивает клиента, система переведёт его из состояние «Решение принято» в состояние «Решение отменено», а затем, при выполнении типовых решений для данного состояния – опять в состояние «Поиск решения», и.т.д.). Сам процесс, управляющий обработкой ситуаций контролирует состояния. При изменении состояния запускаются типовые решения согласно их очереди, и после выполнения каждого из типовых решений  процесс проверяет, не изменилось ли состояние (и не требуется ли запустить другое типовое решение). В нашем тестовом примере после нажатия на ОК в разделе «Ситуации» появилась новая запись, а на деталь «Типовые решения» были добавлены решения, которые соледует добавлять автоматически согласно настройками справочника категорий:

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

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

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

При нажатии «ОК» производится проверка, является ли текущий пользователь тем, кто принимает решение согласно указанной роли. Если это так – нажатие на «ОК» рассматривается, как согласие с описанным в комментариях решением. Иначе окно ситуации передаётся пользователю с ролью, которую укажет текущий пользователь. То есть, принятие решения по ситуации может выглядеть, например, так: менеджер указал в качестве принимающего решения куратора проекта, тот, в свою очередь, передал эту роль зав. отдела,  тот тоже колеблется и для полной уверенности передал ген. директору, который сказал: «разбирайтесь сами» и вернул ситуацию куратору проекта. А куратор, посмотрев обсуждение, решил, что надо спросить в финансовом отделе, можно ли «урезать осетра», и передал ситуацию главному бухгалтеру… и т.д., пока, наконец, главный бухгалтер не сказал: да, согласен, делаем именно так. На всякий случай система переспрашивает, точно ли пользователь берёт на себя ответственность за принятие решения:

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

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

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

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

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