Управление проектами, процессами и кейсами – в чем разница?

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

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

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

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

В конечном итоге, проектное и процессное управление – это разные методы решения одного и того же набора проблем, с которым сталкивается любая компания масштаба от среднего и выше: разрыв между интересами подразделений и интересами организации в целом, приводящий к несогласованности действий и отражающийся на клиенте и как следствие – на благосостоянии компании. Эти проблемы проистекают из разделения труда и потому объективны.

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

Написание данной статьи преследовало несколько целей:

1) Помочь сориентироваться и выбрать оптимальный подход (или их сочетание) в зависимости от специфики деятельности организации.

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

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

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

1. Существующие формы коллективной работы и области их применения

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

Определения:

• Проект – это последовательность работ, совершаемых по определенному плану и направленных на создание определенного уникального результата, продукции или услуги. Пример: строительство дороги.

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

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

Примечание: термин «процесс» в данной статье используется как синоним «бизнес-процесса», а «действие» – как синоним «работы».

• Кейс – это некоторая последовательность работ, направленная на достижение определенной цели. Примеры: пациент в приемном покое больницы, дело в суде.

Примечание: термин «кейс» пришел вместе с концепцией адаптивного кейс-менеджмента (ACM, Adaptive Case Management).

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

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

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

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

2. Классификация коллективной работы

Тем не менее, разница между подходами есть, и проявляется она в следующих аспектах:

1) Повторяемость. Можно ли типизировать последовательность работ, дать нескольким экземплярам общее название? В случае проекта и инцидента, в общем случае, – нет. Хотя как частные случаи, типовые проекты и типовые инциденты, безусловно, бывают, но мы не можем отказаться от работы над проектом или инцидентом из-за того, что он не вписывается в шаблон. В случае процесса, кейса, документа повторяемость явно присутствует.

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

3) Структурированность. Можно ли структурировать данные, являющиеся входами и выходами работ? Процессы и кейсы работают со структурированными данными – числами, денежными суммами, датами, справочниками и т.д. В проектах, документах, инцидентах информация не структурирована: текстовые описания, прикрепленные электронные таблицы и другой контент.

Сведем эти характеристики в таблицу:

Таб. 1. Атрибуты коллективной работы

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

3. Систематизация коллективной работы

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

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

Рис. 1. Классификация работы по повторяемости и структурированности.

Как видим, между структурированностью и повторяемостью наблюдается корреляция. И в самом деле, если мы имеем дело с повторяющейся, типизируемой работой (пусть даже непредсказуемой, как в случае кейса), то можно ожидать, что она выполняется над однотипными бизнес-объектами, а значит, такая работа может оперировать структурированными данными, а не просто документами.

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

Работа с данными имеет ряд преимуществ:

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

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

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

Теперь посмотрим на сочетание повторяемости и предсказуемости:

Рис. 2. Классификация работы по повторяемости и предсказуемости.

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

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

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

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

Исключив из рассмотрения комбинации «уникальная + структурированная» и «повторяющаяся + неструктурированная», получим полную матрицу следующего вида:

Рис. 3. Матрица коллективной работы.

4. Абстракции и реалии

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

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

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

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

Фото: pixabay.com