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

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

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

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

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

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

Для бизнеса главное – решить указанные проблемы, хоть с помощью проектов, хоть с помощью процессов. А еще есть документооборот, есть управление инцидентами, есть контроль поручений, есть 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
Комментарии
Нач. отдела, зам. руководителя, Москва
Виталий Елиферов пишет: Почему проект отнесен у ''уникальным работам''? Результат проекта - уникален. Сам проект - не уникален.
В частном случае проект может быть не уникальным (типовым), но вообще-то методы проектного управления на это не рассчитывают и свободно справляются с проектами, у которых уникален и результат, и ход работ. В отличие от процесса.
Слушатель MBA, EMBA, Москва
Коллеги, тема статьи уже довольно давно остается важной и обсуждаемой... Опираясь на свой (20-ти лений) опыт управления проектами в разных отраслях экономики я делаю вывод, что любой проект содержит в себе, в каких-то долях, процессное управление, управление инцидентами, контроль поручений, кейс-менеджмент. Т.е. проектное управление охватывает все другие бизнес-дисциплины, с оторыми автор пытается сравнить проектное управлние. Я недавно был приглашен на вебинар, который демонстрировал инструментальное решение этого вывода. Первое впечатление очень положительное. Запись вебинара здесь [COLOR=gray=gray](ссылка удалена модератором)[/COLOR] Удивлен, что в этом вопросе так далеко продвинулась команда из Ижевска [COLOR=gray=gray](ссылка удалена модератором)[/COLOR], а не из Москвы или Питера... Структура статьи замечательная, термины и определения, последовательность изложения... Но, к сожалению, не выдержана академическая чистота фраз. Упомяну только некоторые. Например, ''процессы и инциденты представляют собой два полюса''... Определения Инцидента и Процесса автором даны правильно, цитата же противоречит определениям. Что бы противоречие устранить нужно пользоваться шаблоном: Инцидент - Процесс - Результат. Этот шаблон вытекает из определений Инцидента и Процесса. Из этого шаблона сразу становится видно, что Инциденты и Процессы не могут быть полюсами... Или: ''физики предпочитают иметь дело с «нерастяжимой нитью» и «точечной массой», хотя в природе не бывает ни того, ни другого.'' Это не верное утрверждение. Физики не ''предпочитают иметь дело''. Физики на моделях ''нерастяжимой нити'' и ''точечной массы'' разрабатывают математический аппарат и методы решений, чтобы их применить для ''элластичной нити'' и ''распределенной массы''. Или ''Обратный пример: представить как процесс лечение больного, поступившего в приемный покой, вряд ли удастся.'' В моем послужном списке один проект разработки и внедрения Медицинской Информационной Системы (МИС), и один портфель проектов той же предметной области. В обоих случаях (а это две разные МИС) лечение больного (от приемного покоя, через выписку под диспансерное наблюдение и до полного выздоровления или летального исхода) представлены в виде стройного процесса с определенными промежуточными и итоговыми результатами. С интересом прочту завершающую часть. [COLOR=gray=gray]***Сообщение было отредактировано модератором. Нарушение пункта 7.1 Декларации Сообщества: ''Участникам Сообщества настоятельно рекомендуется: 1) воздерживаться от открытой саморекламы и рекламы своего бизнеса (в том числе недопустимо размещение на общих форумах или в блогах информации о вакансиях/мероприятиях компаний); ''***[/COLOR]
Менеджер, Санкт-Петербург
Сергей Левицкий пишет: любой проект содержит в себе, в каких-то долях, процессное управление, управление инцидентами, контроль поручений, кейс-менеджмент. Т.е. проектное управление охватывает все другие бизнес-дисциплины, с оторыми автор пытается сравнить проектное управлние.
По аналогии можно ли рассматривать некий портфель проектов как кейс? можно ли рассматривать некий поток проектов как процесс?
Анатолий Белайчук пишет: В частном случае проект может быть не уникальным (типовым), но вообще-то методы проектного управления на это не рассчитывают и свободно справляются с проектами, у которых уникален и результат, и ход работ. В отличие от процесса.
Well Проектно-изыскательский институт -- одновременно ведутся около 600 проектов, ежегодно открывается около 200, сотрудников около 800, свободно управляется с проектами, управляя в рамках управления процессом проектирования... У дочки этого института только в одном из кейсов тысячи проектов газификации домов населенного пункта... Причем как бы вы критично не относились к документообороту, именно он формирует уникальный результат проекта в проектно-изыскательной деятельности
Анатолий Белайчук пишет: Документооборот - это действительно ''лженаука'' и действительно имеющая хождение в основном в России.
Нет регулярного налогового, кадрового, бухгалтерского, страхового, медицинского и т.п. документооборота за пределами России -- не верю... ''Вы просто не имеете их готовить'' (с)
Слушатель MBA, EMBA, Москва
Александр Воробьев пишет: По аналогии 1. можно ли рассматривать некий портфель проектов как кейс? 2. можно ли рассматривать некий поток проектов как процесс?
1. Давайте определим, в начале, что такое кейс. 2. Поток проектов можно представить как процесс в том случае, когда результат одного проекта используется (потребляется) в следующем проекте. Т.е. последовательных проектах. Я делать этого не советую т.к. PMBoK предлагает для такого случая (связанных, последовательных проектов) термин - ''Программа Проектов''. При том, что тот же PMBoK вводит понятие и процесса, и проекта, и много чего еще... Если мы согласимся на предлагаемую подмену терминов, то очень скоро запутаемся в терминологии.
Менеджер, Санкт-Петербург
Уважаемый Сергей Николаевич
Сергей Левицкий пишет: Давайте определим, в начале, что такое кейс.
Давайте подождем определения термина «кейс» от автора статьи
Сергей Левицкий пишет: Поток проектов можно представить как процесс в том случае, когда результат одного проекта используется (потребляется) в следующем проекте. Т.е. последовательных проектах. Я делать этого не советую т.к. PMBoK предлагает для такого случая (связанных, последовательных проектов) термин - ''Программа Проектов''. При том, что тот же PMBoK вводит понятие и процесса, и проекта, и много чего еще... Если мы согласимся на предлагаемую подмену терминов, то очень скоро запутаемся в терминологии.
ИМХО 1) в статье использованы термины «проект» и «процесс» не согласно PMPoK … 2) не уверен, что согласно PMPoK возможен подход, изложенный в статье… 3) пока понятен контекст применения терминов «проект» vs «процесс», обсуждать статью можно, в тоже время переход на терминологию согласно PMPoK лишит заданного смысла и статью, и дискуссию по ней…
Сергей Левицкий пишет: Поток проектов можно представить как процесс в том случае, когда результат одного проекта используется (потребляется) в следующем проекте. Т.е. последовательных проектах.
В строительном проектировании в т.ч. именно так и происходит – проект (project ) на каждую стадию проектирования объекта строительства…
Сергей Левицкий пишет: 1. … 2. …
Мои почти риторические вопросы были об отностительности вложенностизаданной в статье : Проект ->процесс->кейс… Есть и процесс->проект Есть и кейс->проект… Все зависит только от точки зрения…
Менеджер, Москва
Анатолий Белайчук пишет: В частном случае проект может быть не уникальным (типовым), но вообще-то методы проектного управления на это не рассчитывают и свободно справляются с проектами, у которых уникален и результат, и ход работ.
По определению РМВоК 5.0
Проект – это временное предприятие, предназначенное для создания уникальных продуктов, услуг или результатов.
Самый старый РМВоК нашел у себя 1996 г., в нем определение аналогичное. Еще раз: Проект не является уникальным. Уникальным является: Результат проекта (продукт или услуга). Читайте документы внимательно.
Преподаватель, Саратов

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

Менеджер, Санкт-Петербург
Виталий Елиферов пишет: По определению РМВоК 5.0 Цитата Проект – это временное предприятие, предназначенное для создания уникальных продуктов, услуг или результатов. Самый старый РМВоК нашел у себя 1996 г., в нем определение аналогичное. Еще раз: Проект не является уникальным. Уникальным является: Результат проекта (продукт или услуга). Читайте документы внимательно.
Виталий! Вы правы по букве РМВоК… А по сути любое предприятие, в т.ч и временное, уникально… но РМВоК не пишет, что абсолютно любой проект уникален … правда и уникльность как таковая тоже очень относительная категория, тем более применительно к статье... уникальны и проекты и процессы и кейсы, только каждый уникален по своему...
Анатолий Белайчук пишет: В частном случае проект может быть не уникальным (типовым)
Типовой проект по РМВоК не возможен, Типовой проект возможен только с совершенно другим определением термина «проект»
Анатолий Белайчук пишет: методы проектного управления …свободно справляются с проектами, у которых уникален и результат, и ход работ.
т.е. методы проектного управления собственно проектами, а это уже проектно-ориентированная организация, о которой в статье ни слова… или другое определение термина «проект» Из контекста статьи следует, что Анатолий Белайчук местами использует определение термина «проект» не совсем по РМВоК, Естественная для РМВоК вложенность задачи в процесс, а процесса в проект не предполагает альтернативы между целым со своей частью, предложенной в статье... Суважением Александр
Адм. директор, Москва

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

Строительство дороги (прмер процесса) может рассматриваться и как проект, и как кейс. Что такое документооборот вообще непонятно. А инциденты - это вообще непременный ''атрибут'' управления.

Статью прочитали, но зачем она написана так и не поняли. Разве что запутать.

Нач. отдела, зам. руководителя, Москва
Виталий Елиферов пишет: Еще раз: Проект не является уникальным. Уникальным является: Результат проекта (продукт или услуга).
Результат проекта уникален, ход проекта уникален, состав участников уникален, но сам проект не уникален! Эта казуистика выше моего понимания. На всякий случай замечу, что уникальность в статье используется просто как противоположность повторяемости.
Оставлять комментарии могут только зарегистрированные пользователи
Статью прочитали
Обсуждение статей
Все комментарии
Дискуссии
Все дискуссии