Тимур Василенко (timur0) wrote,
Тимур Василенко
timur0

Бизнес-процессы с большой долей неопределенности: диаграммы состояний

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

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

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

Свойство разнообразия позволяет нам отвлечься от содержания задач. Задумаемся, а что вообще мы можем сказать о таких задачах? Кое-что можем:
- задача должна быть сформулирована
- в каждый момент времени задача может находиться только у одного исполнителя (свойство простоты задачи) или вообще ни у кого - сформулированные задачи не обязательно передана на исполнение (к примеру, если задача зависит от внешних условий - "как снег сойдет")
- задача предполагает исполнение, т.е. в некоторый момент времени она будет завершена. Исполнение задачи должно быть проконтролировано - это, по сути, процедура признания ее выполненной

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

Для управления всем этим есть хорошая модель - диаграммы состояний. Помните детскую настольную игру, типа этой:

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

Диаграмма состояний у нас будет такая (скриншот диаграммы базового бизнес-процесса из системы управления задачами Notal System):
17.54 КБ

Необходимые пояснения:
1. Состояния изображены прямоугольниками с закругленными краями, каждое состояние имеет свое название.
2. Состояния бывают нескольких типов (цвет рамки):
* Накопитель (желтая рамка) - задача не имеет исполнителя и не является завершенной. Обычное использование - сформулированные, но не переданные в работу задачи.
* Активное состояние (сине-фиолетовая рамка) - задача имеет исполнителя. Обычное использование - задача в работе.
* Финальные состояния (бордовая и зеленая рамки) - задача завершена; такие состояния имеют только входящие переходы (в отличие от настольных игр мы не снимаем фишки с поля, они остаются в этих финальных состояниях). Различаются положительные финальные состояния (зеленая рамка) и отрицательные (бордовая) - данное различие нужно только для удобства анализа.
* Начальное состояние (серая рамка) - техническое, в нем задачи возникают и не могут оставаться - сразу должны перейти в какое-либо связанное с ним состояние. Данное состояние не может иметь входящих переходов.
3. Все состояния связаны переходами, которые и определяют карту, на которой может двигаться задача.
4. Переходы "по умолчанию" обозначены жирной стрелкой - т.е. это рекомендованный переход из данного состояния.

Теперь посмотрим, как выглядит обычное движение задачи по этой диаграмме состояний (задача - фишка, которая стоит на карте):
1. Сначала задача поставлена, т.е. сформулирована. Она сразу переходит в состояние "Накопитель задач" (у нас очень простая диаграмма состояний, без выбора).
2. Когда менеджер решает, что задачу пора отдать на исполнение, он переводит ее в состояние "В работе", назначая ей исполнителя.
3. Исполнитель выполняет задачу и отчитывается о ее выполнении, передавая ее менеджеру (или иному уполномоченному лицу) в состояние "Контроль".
4. Если задача выполнена успешно, то менеджер (или иной контролер) переводит ее в финальное состояние "Выполнено", и на этом все завершено с данной задачей.

Мы рассмотрели очень простой четырехшаговый маршрут задачи в данном бизнес-процессе. Это если все идет хорошо, но возможны разные отклонения:
2'. Задача. которую еще не начали выполнять, может "прокиснуть", потерять актуальность. Работа менеджера - увидеть это и перевести данную задачу в финальное состояние "Отменено".
4'. Задача на контроле может быть признана не выполненной и возвращена на доработку в состояние "В работе" (возможно, со сменой исполнителя). По такому циклу 4-4' задача может ходить несколько раз.
3'. Исполнитель во время выполнения задачи может столкнуться с какими-либо трудностями, для него непосильными. К примеру, может выявиться нечеткость формулировки задачи, необходимость принятия решения, на которое у исполнителя нет прав, и т.п. В этом случае он должен незамедлительно передать задачу менеджеру (или иному эксперту) в состояние "Нужна помощь".

Кстати, обращаю внимание на состояние "Нужна помощь". Именно это состояние агрегирует в себе многие проблемы, которые несет в себе неопределенность задач данного бизнес-процесса. Это и нечеткость исходных формулировок задач, это и потребность сделать выбор (за пределом прав исполнителя), это и выявление того, что задача оказалась совсем не такой простой, как казалось вначале. За этим состоянием менеджер должен следить особо внимательно и наиболее быстро разрешать возникающие проблемы. А возможности у него такие:
- Оказать необходимую помощь (прояснить формулировку, сделать выбор и т.п.) и вернуть задачу на исполнение в состояние "В работе". Отметим, что одно из решений - передать задачу другому исполнителю, более компетентному. Это - желательный переход.
- Есть вариант снять задачу с исполнения, переведя ее в финальное состояние "Снята с исполнения". Это применяется в тех случаях, когда задача оказалась нечетко сформулированной, а при прояснении формулировки с учетом новой информации, выявленной исполнителем по ходу решения, выясняется, что задача вообще поставлена некорректно. Проще отменить эту задачу и сформулировать одну или несколько новых, уже точно более простых и беспроблемных. Другой вариант применения этого перехода - когда по мере решения задачи выясняется, что это не маленькая простая задача, а серьезная проблема. К примеру, типовое претензионное письмо может вылиться в судебный процесс, т.е. в данном бизнес-процессе мы эту задачу закрываем и инициируем проектный бизнес-процесс (как я отмечал в предыдущей статье, все судебные процессы являются типичными проектами).
- Аналогичное закрытие задачи - снятие с исполнения - возможно и для задач в состоянии "Контроль". Это ситуация, когда задача не выполнена, но исполнитель даже не понял, что есть проблема. Редко, но бывает.

Вот, вкратце, описание типового бизнес-процесса "текучка" - неспецифицированного потока случайных простых (иногда не очень) задач. Для реального управления нам надо чуть больше, чем просто карта состояний со стоящими на ней фишками задач - нам надо эти фишки видеть:
* Единично - история движения каждой задачи, когда у кого и в каком состоянии она побывала;
* Группой - какие задачи и сколько их находятся в данном состоянии, у данного исполнителя, и т.п.;
* Во временном разрезе - сколько времени и какие задачи находятся без движения.
Все это и многое другое реализовано в системе управления задачами и документооборотом Notal System, но более подробно мы рассмотрим в следующей статье. Здесь остановимся только на том, что видно из диаграмм состояний.

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

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

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

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

На сегодня все. в следующих статьях мы рассмотрим бизнес-процессы на примерах, а также подумаем, что можно сделать с бизнес-процессами смешанного типа.
Tags: notal system, Профессия
Subscribe

  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

  • 0 comments