«Ахиллесова пята» процесса
Говорят, что надежность цепи определяется слабейшим звеном. Предлагаю посмотреть, насколько это верно в отношении процесса, как последовательности операций.
Говорят, что надежность цепи определяется слабейшим звеном. Предлагаю посмотреть, насколько это верно в отношении процесса, как последовательности операций. Процесс можно считать успешно завершенным, если каждая операция процесса также завершена успешно. Или с другой стороны: если хотя бы одна операция даст сбой – процесс можно считать завершившимся неудачно.
Пусть каждый шаг процесса имеет некоторую вероятность успешного завершения. Тогда вероятность успешного завершения всего процесса определяется, как произведение вероятностей шагов. Скажем, если есть процесс из пяти шагов, каждый шаг успешен в 80% случаев, то весь процесс будет успешно завершен в 33% случаев. Если шагов будет 10, а не 5 – шанс сокращается до 11%. Повторюсь (да простят мне злоупотребление болдом) – почти 9 из 10 попыток запуска процесса обернутся неудачей. Таким образом, надежность цепи зависит не только от слабости звеньев, но и их количества.
Классический выход из ситуации – рассматривать шаги по устранению ошибок как часть процесса. Но тогда появляется другая проблема – описание процесса может превратиться в разветвленное описание всевозможных исключительных ситуаций, за которым самого процесса уже не видно.
Если слабая устойчивость к ошибкам «длинных» процессов выводится из теории вероятности, то слабая устойчивость к изменениям – из самой что ни на есть практики. Изменение порядка исполнения процесса ставит вопрос – а что делать с уже запущенными работами по старому порядку? Переходный период и связанные с ним накладные расходы прямо пропорциональны периоду исполнения процесса. Здесь уже важно не столько количество шагов, сколько их длительность.
И напоследок предлагаю посмотреть на устойчивость процесса с точки зрения автоматизации. Из вышесказанного следует, что имеет смысл, по мере возможности, стремиться к простым схемам и держать под жестким контролем такие параметры, как количество и надежность операций процесса и суммарная длительность исполнения процесса. Не ахти как глубоко, но все же…
Для более детального охвата проблемы устойчивости процессов рекомендую статью Анатолия Белайчука Избранные паттерны BPM. Хотя там «устойчивость» и не упоминается, предлагаемые паттерны нацелены именно на нее.
Комментарии 11
Процесс - это закрытая система.
Для повышения надежности закрытых систем применяются методы: распараллеливание, дублирование и т.п.
Представим себе, как это д.б. реализовано - для гарантированного оформления документа нужно одновременно запускать три экземпляра, каждая согласующая должность или организация, как минимум должны быть продублированы, тогда на выходе с близкой к заданной вероятности можно получить необходимый документ.
Если перейти на личности, то у каждого исполнителя должен быть двойник. Этот двойник не только обрабатывает документы, но ему нужно как-то жить семья, дети и т.п.
Жизнь уже давно решила этот вопрос. В жизни применяются открытые системы. Открытые системы обладают несоизмеримо большим разнообразием нежели закрытые. Одно из основных свойств - изменчивость, т.е открытая система должна легко перестраиваться в рамках существующих свойств, так и легко приобретать новые, при этом структура системы не должна меняться.
Хм. Думаю, это весьма утрировано. Все-таки нельзя отнести к ошибкам результаты выполнения "На доработку", которые и приводят к циклам. Именно ради таких реакций и проводится согласование.
К ошибочным действиям, думаю, стоит относить события внешние относительно процесса, мало им контролируемые, разве нет?
Елена, согласен. Здесь я как раз попытался привлечь внимание к устойчивости автоматизируемого процесса - как первому признаку, что процессный подход может дать сбой.
Насколько мне известно, на сегодняшний день нет хороших решений по автоматизации неустойчивых процессов, только очень-очень частные реализации типа ServiceDesk и персональных органайзеров. Есть еще, например, теория хаотического управления, но и она, насколько мне известно, тоже пока только теория.
Мы обсуждаем процесс в общем виде. Нам не важно сколько раз нужно пересогласовывать документ - сколько определено в процессе, столько и надо.
Вопрос в другом: все делается по правилам, а результатат не получается, что делать? В грамотных системах автоматизации это понимается и все спорные позиции передаются на пользователя. Т.е. разрабатывается такой многофункциональный калькулятор, хорошим примером таких разработок является 1С. Меня поначалу всегда удивляло, почему при регистрации какой-либо операции не делаются в общем-то понятные последующие действия. Как оказалось упорядочить, изготовить алгоритм таких действий не стоит затрат, всегда найдется умник которому будет все не так.
Вывод из этого такой: процесс должен быть до безобразия простым, процессы могут быть разного уровня, например, жизненный цикл - самый высокий уровень, действия при приеме документов - самый низкий.
Привлечение пользователя в спорной ситуации даже не обсуждается - это само собой разумеется.
"Калькуляторы" типа 1С тут так же слабы, как и BPM-системы. Настройка бизнес-правил вида "Документ такого-то вида после подготовки может попасть к юристу только после руководителя исполнителя, а к коммерческому - только после юриста" в 1С приведет к программированию, а то и к перепроектированию. В BPM же такие вещи могут быть описаны бизнес-аналитиком, а не программистом, пусть хоть и с упомянутыми выше трудностями.
Проблема в том, что мы (участники этого обсуждения) пока не нашли подходящего формального языка, на котором можно было бы эффективно (т.е. лаконично и достаточно полно) описывать устойчивые правила, действующие в неустойчивых процессах. Формальный язык нужен именно для возможности автоматической поддержки правил. IDEFx, BPMN, EPC, BPEL, XPDL и иже с ними для этого не годятся, да и не предназначались никогда.
Проблема в том, что (участники этого обсуждения) находятся в поиске подходящего формального языка, на котором можно было бы эффективно (т.е. лаконично и достаточно полно) описывать систему деятельности людей. Такое занятие называется поиск философского камня.
Поясню. 1. Деятельность людей, есть открытая система, формальный язык - закрытая система. Описать открытую систему средствами формального языка невозможно, по определению. Деятельность людей можно описать только языком людей.
2. Вместе с этим существуют примеры "успешного" (в хорошем смысле этого слова) использования процессного подхода к моделированию деятельности. Например, "ситуационная комната" (где-то видел описание) в ней создано специальное подразделение в составе специалистов по формальному языку и специалистов по ситуациям для быстрой разработки схем процессов. Ограничение в этой ситуации - после разработки процесса он становится закрытым для изменений. Поэтому в случае возникновения изменений нужно перепроектировать оставшуюся (не исполненную) часть. Хорошо, если процессы достаточно медленные, скорость перепроектирования выше скорости изменения процесса. В общем случае новый процесс становится старым после поступления первого сообщения о выполнении какого-либо действия по нему. Как это не прискорбно заявить!
Александр, как Вы верно заметили, формализацией неформализуемого заниматься нам все равно приходится. Поэтому предлагаю оставаться в конструктивном русле и не слишком сильно увлекаться обобщениями.
Конечно же, полностью описать систему деятельности человека нельзя и в общем случае такие попытки будут провальными. Поэтому и предлагаю сконцентрироваться только на устойчивых компонентах. Процессный подход чрезвычайно эффективен, когда речь идет об устойчивых процессах - об этом писано море статей. Процессный подход неэффективен, когда речь идет о неустойчивых процессах, даже если в них имеются устойчивые и вполне прилично описываемые компоненты. Об этом обычно вслух не говорят, потому что полноценной альтернативы процессному подходу пока нет.
Говорю "пока", т.к. частные решения все же существуют (например, упомянутые ранее ServiceDesk и персональные органайзеры, возможно есть и другие примеры, которые я не заметил) и природный оптимизм заставляет надеяться, что когда-нибудь решение таки будет найдено.