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

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

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

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

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

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

Для бизнеса главное – решить указанные проблемы, хоть с помощью проектов, хоть с помощью процессов. А еще есть документооборот, есть управление инцидентами, есть контроль поручений, есть 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

Эта публикация была размещена на предыдущей версии сайта и перенесена на нынешнюю версию. После переноса некоторые элементы публикации могут отражаться некорректно. Если вы заметили погрешности верстки, сообщите, пожалуйста, по адресу correct@e-xecutive.ru
Комментарии
Нач. отдела, зам. руководителя, Москва
Анатолий Белайчук пишет: Результат проекта уникален, ход проекта уникален, состав участников уникален, но сам проект не уникален! Эта казуистика выше моего понимания.
Такой спор выиграет самый формальный подход, т.к. спор по.сути о формальностях. Всегда можно использовать что-то не по назначению :), и представьте что Вашему оппоненту кажется что ему удалось добиться сделать всё полностью одинаковым ...и вроде соответствует определениям принятым в Управление проектами. Пусть будет отличаться типа номер договора на проект :) Это смешно, но с формальной стороны правильно. Ну, да ладно, забудем номер договора:) Существуют разные определения, что такое Управление проектами и что такое проект Управлении проектами, уверен что при анализе каждого что-то будет точно меняться, несмотря на поставленные жёсткие условия ''Одинаковости''. -> Будут точно меняться Риски, Всё что связано с Удовлетворённостью клиента, Ожидания клиента.... типа того. И в конечном итоге, даже при таких ''формальных ограничениях'' проекты будут разными :)
Нач. отдела, зам. руководителя, Москва
Анатолий Белайчук пишет:На всякий случай замечу, что уникальность в статье используется просто как противоположность повторяемости.
Или иначе ... ''Нельзя войти в одну реку дважды'' ©
Нач. отдела, зам. руководителя, Москва
Александр Воробьев пишет: Виталий! Вы правы по букве РМВоК… А по сути любое предприятие, в т.ч и временное, уникально… но РМВоК не пишет, что абсолютно любой проект уникален … правда и уникльность как таковая тоже очень относительная категория, тем более применительно к статье...
Мне стало интересно насколько соответствует ''букве РМВоК'' :) ... На мой взгляд, и букве тоже не соответствует. Если внимательно почитать текст, то можно найти требование получения обратной связи и многократное! требование уточнений: целей, требований, стоимости, рисков, готовности заинтересованных сторон проекта принимать риски и т.д.. В английской версии можно найти следующее:
Progressive Elaboration [Technique]. Continuously improving and detailing a plan as more detailed and specific information and more accurate estimates become available as the project progresses, and thereby producing more accurate and complete plans that result from the successive iterations of the planning process
Прогрессивная Разработка [Техника]. Постоянное совершенствование и детализация плана, так как получение более подробной и конкретной информации и более точных оценок доступно только по мере развития проекта, таким образом, в результате последовательных итераций процесса планирования, разрабатываются более точные и полные планы.
Слушатель MBA, EMBA, Москва
Уважаемый Александр Евгеньевич, извиняюсь, что ответил не сразу ...
Александр Воробьев пишет: 3) пока понятен контекст применения терминов «проект» vs «процесс»,
как раз против этого ''применения терминов «проект» vs «процесс»'' я и пытаюсь предостеречь. Попробую пояснить: в моем понимании фраза ''«проект» vs «процесс»'' эквивалентна фразе ''«проект» ПРОТИВ «процесс»''. Т.е. автор пытается противопоставить (сравнить) ''проект'' и ''процесс''. Если это так, то я в очередной раз хочу донести соотношение сущностей: ''проект'', ''процесс'', ''инцидент'', ''результат''. Опираясь на определение ''процесса'' и ''инцидента'', я предлагаю пользоваться шаблоном: ''инцидент'' -> ''процесс'' -> ''результат''. Этот шаблон отражает причинно-следственную связь между указанными сущностями. Что бы появился ''результат'' должен завершиться ''процесс''. А ''процесс'' не может запуститься сам-собой. Должен быть ''инцидент'' который запустит ''процесс'' который выдаст ''результат''. Совокупность таких цепочек (''инцидент'' -> ''процесс'' -> ''результат''), разнесенных во времени и в пространстве образуют собой ОДИН ''проект''. (Рассмотрим пока один ''проект'', как поступают физики с моделью ''нерастяжимая нить и точечная масса''. Позднее станет понятно как быть со множеством проектов.) Так вот, ОДИН ''проект'' состоит из МНОЖЕСТВА сущностей ''процесс'', ''инцидент'', ''результат'', согласованных между собой логически - получение общего конечного результата проекта. Т.е. процессное управление является инструментом для проектного управления. Причем, самым главным инструментом. И в относительно небольшом количестве ''проект'' содержит документооборот, контроль поручений и т.д. в качестве вспомогательных инструментов. Осознав это, вернемся к исходной фразе ''«проект» vs «процесс»'', и ... ? Как мы можем противопоставить ОДИН ''проект'' МНОЖЕСТВУ ''процессов''? Даже ОДНОМУ ''процессу'' мы не сможем противопоставить ОДИН ''проект'' т.к. это сущности разных категорий (уровней иерархии). Т.е. проектное управление - это суть процессное управление. Для проектного управления PMI разработал набор ''процессов'', управляя которыми мы управляем проектом в целом. Те парни из Ижевска (ссылка в моем первом посте была удалена модератором) догадались PMBoK реализовать средствами системы управления бизнес-процессами. И у них это получилось... Во всяком случае, тот объем, что они успели отработать, выполняется без ошибок. Периодически в западной профессиональной прессе появляются сообщения об успешных примерах применения принципов проектного управления в операционном управлении предприятием. Видимо это перспективная тема... А какой смысл содержится в фразе ''«проект» vs «процесс»'' мне не понятно...
Менеджер, Москва
Александр Воробьев пишет: Виталий! Вы правы по букве РМВоК… А по сути любое предприятие, в т.ч и временное, уникально… но РМВоК не пишет, что абсолютно любой проект уникален … правда и уникльность как таковая тоже очень относительная категория, тем более применительно к статье... уникальны и проекты и процессы и кейсы, только каждый уникален по своему...
К ''буквам РМВоК'' - у меня есть отдельные претензии. ''Доколе!!!'' - эти ребята будут писать в РМВоК отдельный процесс ''Управление качеством проекта'' - 15 лет я пытаюсь объяснить людям, что такое разделение на ''процессы качества'' и ''процессы количества'' погубило советское ОТК. Точнее, ОТК было основано на том, что одни ''давали каКчестов'', а другие ''колиКчество''. Неужели руководитель проекта может назначать ответственным за сроки - одного участника проекта, за результаты - другого, за качество - третьего. Только с такой точки зрения оправдано выделение ''качества'', как ОТДЕЛЬНОГО ОТ ПРОЕКТА объекта управления. Совеременные требования к менеджменту качества основаны на том, что есть владелец процесса, который отвечает за ВЕСЬ объект и ВСЕ его характеристики. Еще раз напомню определение теримна ''качество'', существующее с 2000 г. ''Качество - это степень выполнения требований, совокупностью собственных характеристик''. То есть, ВСЕХ требований, всеми характеристиками.
Руководитель проекта, Самара
Виталий Елиферов пишет: Совеременные требования к менеджменту качества основаны на том, что есть владелец процесса, который отвечает за ВЕСЬ объект и ВСЕ его характеристики.
Если в данной фразе попытаться определить содержание термина ''объект'', то очевидно, речь идет не о проекте, а о результате проекта. Качество - многогранное понятие, и желательно различать качество проекта и качество результата проекта. К качеству проекта относятся такие сущности, как качество организации работ, качество планирования, качество ресурсов. К качеству результата проекта относятся такие сущности, как качество выполнения требований и качество совокупности характеристик.
Нач. отдела, зам. руководителя, Москва
Иркин Шариев пишет: речь идет не о проекте, а о результате проекта
или продукте проекта. И не думаю, что нужно уделять качеству одинаково внимание на всех фазах проекта. Кроме того, стоимость проекта является ограничением, и подсчёт стоимости управления качеством проекта и продукта - это задача не только облегчается :), но и даже во многих, если не в большинстве случаев! возможна, когда есть отдельный процесс управление качеством проекта. Это связано не только с тем, что требования будут меняться, но и задачами типа улучшения качества по желанию заказчика на одной из заключительных фаз проекта. Деньги нужно уметь считать, чтобы и ожидания заказчика не обмануть и себе не в убыток работать.
Менеджер, Москва
Александр Соловьев пишет: И не думаю, что нужно уделять качеству одинаково внимание на всех фазах проекта. Кроме того, стоимость проекта является ограничением, и подсчёт стоимости управления качеством проекта и продукта - это задача не только облегчается :), но и даже во многих, если не в большинстве случаев! возможна, когда есть отдельный процесс управление качеством проекта. Это связано не только с тем, что требования будут меняться, но и задачами типа улучшения качества по желанию заказчика на одной из заключительных фаз проекта. Деньги нужно уметь считать, чтобы и ожидания заказчика не обмануть и себе не в убыток работать.
К сожелению, опять ''качество'' отделено от проекта и результата. Объясняю еще один раз: ''Качество - степень выполнения требований, совокупностью собственных характеристик'' Собственные характеристики проекта включают: а) Характеристики продукта продукта- функциональные, соответствие резултата/ожиданиям, стоимостные (цена), временные, эргономические, органолептические, надежностные, стоимость владения, обслуживания, постпродажный сервис, гарантии и т.д. Это все характеристики которые видит Заказчик проекта. б) Характеристики проекта - выполнение графика, себестоимость (не путать с ценой), ресурсоемкость, материалоемкость, вероятность получения нужного результата и т.д. Эти характеристики важны для Руководителя проекта. Степень выполнения всей совокупности характеристик и будет являться ''Качеством проекта''. Часть характеристик будет выполнено на 70%, часть - на 80%, что-то на 110% - их совокупность (включая цену, себестоимость, надежность, ресурсоемкость, вероятность отказа, межремонтный интервал и пр.) и даст Заказчику ощущение качества, - как степени выполнения его требований. P.S. Пора расстаться с ''совковым понятием'', что ''качество - это надежность и отсутствие царапин''.
Нач. отдела, зам. руководителя, Москва
Иркин Шариев пишет: К качеству результата проекта относятся такие сущности, как качество выполнения требований и качество совокупности характеристик.
С этим всё достаточно понятно, но Дискуссия сместилась уже на обсуждение другого:
Анатолий Белайчук пишет: Результат проекта уникален, ход проекта уникален, состав участников уникален, но сам проект не уникален! Эта казуистика выше моего понимания. На всякий случай замечу, что уникальность в статье используется просто как противоположность повторяемости.
Здесь стоит обратить внимание на то, что Уникальность продукта проекта предполагает, что этот продукт / и услуга ранее не делались, и управление качеством проекта отличается, например, от управления качеством на производстве, поэтому используются другие подходы.
Александр Соловьев пишет: Прогрессивная Разработка [Техника]. Постоянное совершенствование и детализация плана,
Коммуникации участников проекта и всех заинтересованных сторон ограничены. Ожидания заказчика полностью неизвестны, и даже если известны, могут меняться. Поэтому используется поша­говое уточнение самого содержания и требований к продукту, и управление ожиданиями всех заинтересованных сторон проекта ... много отличий
Менеджер, Москва
Александр Соловьев пишет: Уникальность продукта проекта предполагает, что этот продукт / и услуга ранее не делались, и [COLOR=red=red]управление качеством проекта отличается, например, от управления качеством на производстве, поэтому используются другие подходы[/COLOR] .
Прочитай раздел 8 РМВоК 5.0 ''Управление качеством проекта''. В этом разделе приведено то же самое определение термина качества. В этом разделе перечислены те же самые инструменты: Lean, Six sigma, PDCA, контрольные карты и т.д. Посмотрите на Рис. 8-7 ''7 простых методов'', - те же что и в производстве. [COLOR=blue=blue]Александр! Укажите, пожалуйста, различия в подходах.[/COLOR]
Оставлять комментарии могут только зарегистрированные пользователи
Статью прочитали
Обсуждение статей
Все комментарии
Дискуссии
Все дискуссии