Как своевременно определить результативность проекта внедрения процессного управления? Как выявить проблемы и обеспечить их понимание руководителями компании? В статье В.В. Репина предлагается модель для оценки ситуации с проектом внедрения процессного подхода. Особенностью модели является использование практически измеримых пар критериев, таких как: «количество принятых решений/степень детальности описания бизнес-процессов», «степень вовлеченности руководителей/качество графических схем бизнес-процессов» и проч. Так же предлагается использовать лепестковую диаграмму для одновременной оценки и анализа восьми критериев.

Введение

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

К сожалению, частенько проекты заходят в тупик, а ожидаемые организационные изменения не осуществляются. Каким образом, не дожидаясь провала проекта, своевременно определить, всё ли идет как надо? Как вовремя выявить проблемы и довести их до руководства? В статье приводится ряд критериев (показателей), сгруппированных по парам. Их расчет и анализ помогут определить текущий статус проекта внедрения процессного управления в компании. Стоит подчеркнуть, что эти критерии требуют «калибровки» в зависимости от ситуации в конкретной организации. 
 

Количество принятых решений/степень детальности описания бизнес-процессов

Рассмотрим первую пару критериев - «Количество принятых решений/Степень детальности описания бизнес-процессов», представленную на рис. 1.

В первую очередь определимся, что понимается под степенью детальности описания бизнес-процессов. Предполагается, что схемы создаются для процессов операционного уровня в формате WorkFlow («поток работ»), а не на верхнем, структурном уровне (например, в IDEF0). Для формирования таких схем, как правило, используют соответствующие нотации: CFFC (Cross Functional Flow Chart), eEPC, BPMN. 

Например, необходимо описать процесс формирования оперативного плана производства. Если полученная схема содержит всего 2-3 шага, то очевидно, что она не достаточно проработана. Ее невозможно использовать для анализа и принятия решений по реорганизации процесса. С другой стороны, если бы мы расписали процесс оперативного планирования в виде группы связанных подпроцессов, каждый из которых содержит 12-15 операций (шагов), подробное и четкое описание событий и входов/выходов, то можно было бы говорить о детальном описании (вопрос качества схемы и ее соответствия реальности будет рассмотрен в статье чуть ниже). Детальность описания процесса является достаточно объективным критерием. Можно предложить следующую шкалу и формулу для его измерения:

 

Таблица 1.

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

Пример. В процессе моделирования сформированы 6 схем процессов, каждый из которых содержит по 2-4 шага. Возможные причины: 

a) мы имеем дело со сквозным процессом, но искусственно раздробили его по подразделениям. Стоит пересмотреть систему процессов компании, выделив в ней соответствующий сквозной процесс; 

b) процесс вышестоящего уровня был некорректно декомпозирован. Целесообразно перейти на уровень вверх и пересмотреть логику декомпозиции;

c) сотрудник не справился с задачей описания процессов («профанация»). Придется описывать процессы повторно. 

Теперь поговорим о количестве управленческих решений. Откуда они берутся? Представим себе ситуацию, когда бизнес-аналитики молчаливо описывают процессы, сидя в удаленном от основной жизни компании офисе, редко бывают «в полях», формально согласовывают схемы (см. ситуацию «Аналитики в собственном соку» на рис. 1). В этом случае, можно ожидать, что никаких управленческих решений не последует. Будет консенсус и замыливание. По ходу проекта будет создано множество никому не нужных графических схем процессов. 

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

Бывает и так, что ни совещаний, ни детальных схем. Просто руководитель проекта ставит галочки по выполнению пунктов плана, а через какое-то время у компании появляются регламенты, «соответствующие» требованиям международных стандартов («исотизированные»). Но практическая ценность таких стандартов нулевая, если не отрицательная. На рис. 1. такая ситуация характеризуется термином «профанация». Результата для бизнеса, конечно же, нет.

 Рис. 1. Оценка ситуации по паре критериев I.

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

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

* - нормо-процесс – термин, предложенный Репиным В.В. Нормо-процесс представляет собой схему в формате А4, содержащую 12-15 операций.

Таблица 2.

На рис. 1 получилось четыре характерные ситуации:

• Профанация;
• Политика;
• Имитация;
• Эффективность.

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

Степень вовлеченности руководителей/качество графических схем бизнес-процессов

Рассмотрим вторую пару критериев - «Степень вовлеченности руководителей/качество графических схем бизнес-процессов», представленную на рис. 2. 

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

Оценку степени вовлеченности руководителей можно выполнить на основании следующей шкалы:
 

Таблица 3.

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

Рис. 2. Оценка ситуации по паре критериев II.

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

• соответствие нотации моделирования, утвержденной во внутреннем стандарте компании, в т.ч.:

• • наличие и корректность формулировки событий;
  • отсутствие логических ошибок (корректность использования шлюзов);
  • отсутствие входов/выходов, которые «повисли в воздухе»;
  • наименование операций, документов, событий;
  • шрифты, цвета, форма объектов;

• содержательный анализ:

• • пропущенные операции;
  • некорректное агрегирование/детализация;
  • возвраты «в прошлое»;
  • % операций, связанных с согласованием/контролем;
  • отсутствие бессодержательных (бессмысленных) операций (например, «отправить документ» и т.п.);

• визуальная наглядность для пользователя;
• «красота» схемы;
• прочие. 

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

Таблица 4.

Обобщенные характеристики квадрантов, представленные на рис.1, годятся так же и для ситуации на рис. 2. Так что вторая пара критериев, по сути, служит для подтверждения аналитических выводов, сделанных по первой паре. 

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

Степень вовлеченности специалистов/«межфункциональность» описываемых бизнес-процессов

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

Таблица 5.

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

Почему критерий «межфункциональности» важен? Дело в том, что процессное управление – это, в первую очередь, оптимизация деятельности на межфункциональном уровне, ломка так называемых «функциональных барьеров», обеспечение синергии при взаимодействии участников сквозных процессов. Если при выполнении проекта будет сделан крен в сторону определения и описания мелких процессов структурных подразделений, вместо выявления, описания и оптимизации сквозных процессов, то по данному критерию это сразу станет очевидно. Конечно, в любой организации существует множество процессов, которые вполне корректно описывать в рамках структурных подразделений. Но если общая степень межфункциональности при описании будет приближаться к нулю, то это повод задуматься. Вполне возможно, что в рамках проекта не удалось выявить ключевые сквозные процессы организации. 

Рис. 3. Оценка ситуации по паре критериев III.

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

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

Третий квадрант «Имитация» не претерпел существенных изменений. Всё те же «бизнес-аналитики в собственном соку». 

Наконец, в случае, если вам удалось вовлечь сотрудников подразделений в обсуждение и решение проблем на межфункциональном уровне (четвертый квадрант «Эффективность»), вы не далеки от практически важного для бизнеса результата. 

Степень вовлеченности собственников/ экономический эффект от внедрения изменений

Рассмотрим четвертую пару критериев – «Степень вовлеченности собственников/ экономический эффект от внедрения изменений», представленную на рис. 4. 

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

Рис. 4. Оценка ситуации по паре критериев IV.

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

Таблица 6.

Предлагается оценивать затраты рабочего времени участников проекта, связанные с описанием, анализом, обсуждением и выполнением мероприятий по реорганизации/оптимизации процессов. Далее суммарные затраты соотнести с подтвержденным экономическим эффектом, рассчитанным на период работы длительностью один год. Метод подтверждения эффекта должен быть четко сформулирован и документально закреплен в стандарте (методической инструкции) компании. В ряде случаев, можно допустить использование расчетного прогнозного эффекта по факту выполнения «пилотного» проекта. 

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

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

Бывают ситуации, когда собственник тратит заметное личное время на участие в проекте, а экономический результат нулевой. Возможная причина кроется в низком качестве управления. Это означает, что своевременно не принимаются критически важные для проекта решения, не осуществляется вовлечение руководителей и т.п. Собственник может «играть в проект» пока ему интересно. Но, как показывает практика, через какое-то время (1-3 месяца) ему становится скучно, и интерес к проекту ослабевает, уступая место другим увлечениям. 

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

Лепестковая диаграмма критериев

Возможно, будет удобнее использовать не квадранты рис. 1-4 с парами критериев, а лепестковую диаграмму. Для ее построения воспользуемся следующим перечнем критериев:

1. Степень детальности описания.
2. Качество графических схем.
3. Степень межфункциональности процессов.
4. Количество управленческих решений.
5. Степень вовлеченности собственников.
6. Степень вовлеченности руководителей.
7. Степень вовлеченности специалистов.
8. Экономический эффект от внедрения изменений. 

На рис. 5. показаны четыре ситуации: «Эффективность», «Профанация», «Имитация» и «Политика». Границы значений критериев для каждой ситуации определены субъективно, экспертным образом. Видно, что для ситуации «Эффективность» экономический эффект больше, а количество управленческих решений меньше, чем в ситуации «Политики». Предполагается, что в ситуации «Эффективность» управленческие решения более глубокие, продуманные и эффективные. Кроме того, они выполняются, в отличие от ситуации «Политика», когда решений принимается много, они фиксируются протоколами а потом… успешно забываются. (Напомним, что ситуация «Политика» характеризуется низким качеством управления в организации).

Рис. 5. Сводная лепестковая диаграмма.

На рис. 6 показана ситуация с одним из проектов в крупной компании (экспертная оценка автора статьи). Процессное управление в ней внедряется уже третий год. В целом, ситуацию можно охарактеризовать как положительную. Разработано много детальных и качественных схем, которые использованы для анализа и регламентации деятельности сотрудников, в том числе при помощи web-портала (моделирования осуществляется в среде моделирования Business Studio 4.0). Стоит обратить внимание, что в данной организации собственник и руководители были активно вовлечены в работу с бизнес-процессами. Существует отдел организационного развития, укомплектованный бизнес-аналитиками высокой квалификации.

Рис. 6. Пример проекта в компании «А».

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

Рис. 7. Пример проекта в компании «Б».

Наконец, на рис. 8 показана ситуация в небольшой компании на начальной стадии проекта. График достаточно красноречив, и не нуждается в комментариях. Если собственник компании хочет получить эффект от проекта, то он должен принять соответствующие решения и показать интерес к проекту личным примером. 


Рис. 8. Пример проекта в компании «С».

Резюме 

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

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

Анатолий Белайчук, Евангелист BPM Comindware, Inc., к.т.н., CBPP

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

То есть не «и», а «или» – обычно это разные люди.

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

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

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

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

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

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

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