Журнал о системах электронного документооборота (СЭД)
Моделирование и регламентация бизнес-процессов

«Ахиллесова пята» процесса

  11 комментариев Добавить в закладки

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

Пусть каждый шаг процесса имеет некоторую вероятность успешного завершения. Тогда вероятность успешного завершения всего процесса определяется, как произведение вероятностей шагов. Скажем, если есть процесс из пяти шагов, каждый шаг успешен в 80% случаев, то весь процесс будет успешно завершен в 33% случаев. Если шагов будет 10, а не 5 – шанс сокращается до 11%. Повторюсь (да простят мне злоупотребление болдом) – почти 9 из 10 попыток запуска процесса обернутся неудачей. Таким образом, надежность цепи зависит не только от слабости звеньев, но и их количества.

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

Если слабая устойчивость к ошибкам «длинных» процессов выводится из теории вероятности, то слабая устойчивость к изменениям – из самой что ни на есть практики. Изменение порядка исполнения процесса ставит вопрос – а что делать с уже запущенными работами по старому порядку? Переходный период и связанные с ним накладные расходы прямо пропорциональны периоду исполнения процесса. Здесь уже важно не столько количество шагов, сколько их длительность.

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

Для более детального охвата проблемы устойчивости процессов рекомендую статью Анатолия Белайчука Избранные паттерны BPM. Хотя там «устойчивость» и не упоминается, предлагаемые паттерны нацелены именно на нее.

Ещё материалы автора
Похожие записи
Комментарии (11)
Головко Александр 18 августа 2009 г. 11:25  

Процесс - это закрытая система.

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

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

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

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

 

Евгений Кочуров 18 августа 2009 г. 12:16  

Процесс - это закрытая система.

Это кто такое сказал? Процессы разными бывают, и открытыми, и закрытыми. :) Даже если сузить понятие "процесса" до "бизнес-процесса".
Для повышения надежности закрытых систем применяются методы: распараллеливание, дублирование и т.п.
Эти методы успешно применяются и в открытых системах
Представим себе, как это д.б. реализовано ...

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

Одно из основных свойств - изменчивость, т.е открытая система должна легко перестраиваться в рамках существующих свойств, так и легко приобретать новые, при этом структура системы не должна меняться.
Изменчивость и легкость в приобретении новых свойств  - это хорошо. Но разве этого достаточно, чтобы избавить от низкой устойчивости к ошибкам?
Евгений Кочуров 18 августа 2009 г. 14:07  
Кстати, самый распространенный пример, когда действия по устранению ошибок возведены в ранг операций процесса - согласование документа. Уберите из реальной схемы согласования документа все циклы, добавленные для устойчивости схемы, и схема перестанет работать в подавляющем большинстве случаев.
Максим Галимов 18 августа 2009 г. 14:27  
когда действия по устранению ошибок возведены в ранг операций процесса

Хм. Думаю, это весьма утрировано. Все-таки нельзя отнести к ошибкам результаты выполнения "На доработку", которые и приводят к циклам. Именно ради таких реакций и проводится согласование.

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

Евгений Кочуров 18 августа 2009 г. 15:40  
Все-таки нельзя отнести к ошибкам результаты выполнения "На доработку", которые и приводят к циклам. Именно ради таких реакций и проводится согласование.

Я бы не стал ставить на один уровень реакции вида "вернуть документ на доработку, т.к. оформлен с ошибками", "вернуть на доработку, т.к. предложения не вписываются в бюджет", "отложить, т.к. сейчас другие приоритеты". Первая реакция связана с ошибками выполнения предыдущего шага. Последние две - это управленческие решения, которые могут быть приняты, даже если документ оформлен по всем правилам. Важно различать эти два случая, чтобы правильно оценить, куда отнести стоимость каждой итерации - на низкую квалификацию исполнителя или издержки системы управления!
 
Второй аргумент: возможность у ответственного лица вернуть "на доработку" - это действительно и есть одна из задач согласования, но порядок действий по исправлению - это отдельная песня. Если пятый рецензент развернул документ, надо ли повторно согласовывать с предыдущими четырьмя? Или только с первым и третьим? Ответ будет сильно зависеть от сути замечания к документу. И если мы на схеме попытаемся учесть все случаи, то простая по смыслу задача (получить согласие от пяти рецензентов) выливается в нетривиальную схему.
 
Беда еще в том, что для улучшения прозрачности схемы шаги по исправлению ошибок редко могут быть спрятаны в подпроцессы.
Евгений Кочуров 18 августа 2009 г. 17:26  

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

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

Головко Александр 19 августа 2009 г. 10:41  

Мы обсуждаем процесс в общем виде. Нам не важно сколько раз нужно пересогласовывать документ - сколько определено в процессе, столько и надо.

Вопрос в другом: все делается по правилам, а результатат не получается, что делать? В грамотных системах автоматизации это понимается и все спорные позиции передаются на пользователя. Т.е. разрабатывается такой многофункциональный калькулятор, хорошим примером таких разработок является 1С. Меня поначалу всегда удивляло, почему при регистрации какой-либо операции не делаются в общем-то понятные последующие действия. Как оказалось упорядочить, изготовить алгоритм таких действий не стоит затрат, всегда найдется умник которому будет все не так.

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

 

Евгений Кочуров 19 августа 2009 г. 11:46  

Привлечение пользователя в спорной ситуации даже не обсуждается - это само собой разумеется.

"Калькуляторы" типа 1С тут так же слабы, как и BPM-системы. Настройка бизнес-правил вида "Документ такого-то вида после подготовки может попасть к юристу только после руководителя исполнителя, а к коммерческому - только после юриста" в 1С приведет к программированию, а то и к перепроектированию. В BPM же такие вещи могут быть описаны бизнес-аналитиком, а не программистом, пусть хоть и с упомянутыми выше трудностями.

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

Головко Александр 19 августа 2009 г. 14:40  

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

Поясню.  1. Деятельность людей, есть открытая система, формальный язык - закрытая система. Описать открытую систему средствами формального языка невозможно, по определению. Деятельность людей можно описать только языком людей.

 2. Вместе с этим существуют примеры "успешного" (в хорошем смысле этого слова) использования процессного подхода к моделированию деятельности. Например, "ситуационная комната" (где-то видел описание) в ней создано специальное подразделение в составе специалистов по формальному языку и специалистов по ситуациям для быстрой разработки схем процессов. Ограничение в этой ситуации - после разработки процесса он становится закрытым для изменений. Поэтому в случае возникновения изменений нужно перепроектировать оставшуюся (не исполненную) часть. Хорошо, если процессы достаточно медленные, скорость перепроектирования выше скорости изменения процесса. В общем случае новый процесс становится старым после поступления первого сообщения о выполнении какого-либо действия по нему. Как это не прискорбно заявить!

Евгений Кочуров 19 августа 2009 г. 17:06  

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

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

Говорю "пока", т.к. частные решения все же существуют (например, упомянутые ранее ServiceDesk и персональные органайзеры, возможно есть и другие примеры, которые я не заметил) и природный оптимизм заставляет надеяться, что когда-нибудь решение таки будет найдено.

Сейчас обсуждают
Больше комментариев