Пытаться управлять проектами без проектного управления – это как пытаться играть в футбол без плана игры.
Мы должны либо найти путь, либо проложить его.
2.1. Виды процессных проектов
Основные причины срыва планов:
– то одно;
– то другое.
Процессные проекты весьма многообразны по решаемым задачам и содержанию. Поэтому и планы таких проектов различаются в значительной степени. Конечно, есть соблазн иметь на все случаи жизни какой-то один подход (типа метода DMAIC или DMADV24), но на практике они могут служить только некоторой «рыбой», да и то не во всех случаях. Как говорится, «собака порылась в деталях», поэтому нередко приходится разрабатывать варианты/пути решения задачи, используя метод проб и ошибок. Но довольно большой опыт процессных проектов (у меня он составляет четверть века) позволяет обобщить результаты.
Прежде всего проекты можно типировать. Наверное, мой перечень будет не абсолютно исчерпывающим, но, думаю, он охватит весьма значительную долю реализуемых процессных проектов. Итак, в этом разделе мы говорим о процессных проектах:
• аудита;
• аттестации;
• общей диагностики;
• описания и локальной диагностики;
• совершенствования;
• регламентации;
• автоматизации;
• с применением технологии Process Mining;
• трансформации для обеспечения/реализации решения бизнес-задач или организационных изменений (то есть совершенствования системы или подсистем управления);
• совершенствования документооборота;
• инжиниринга;
• реинжиниринга.
Рассмотрим эти проекты детальнее.
Упражнение
В каких проектах из перечисленных вы участвовали? Какие типы процессных проектов отсутствуют в списке? Буду благодарен, если напишете мне о них.
2.2. Проекты аудита, аттестации, общей и локальной диагностики процессов
Ответ одного дурака с улицы никого не волнует. Но ответы сотни дураков называются результатом исследования фокус-группы и продаются за деньги.
2.2.1. Проекты аудита и проекты аттестации процессов
Аудит процессов должен дать оценку процессов организации (всех или их части) типа «зачет/незачет» (или вообще обойтись без оценки) с прилагающимся перечнем замечаний и комментариев.
Как ставится задача на проект? Необходимо:
• разработать критерии аудита/оценки процессов или перечень вопросов о процессах, на которые аудит должен дать ответ;
• выбрать аудируемые процессы.
Например, аудит может понадобиться, чтобы ответить на вопрос: «Соответствуют ли показатели процессов и мотивирование их участников новой стратегии организации?» Ответ позволит понять, какие процессы должны быть изменены.
Другой пример: «Какие процессы охвачены процессным управлением?» – с перечнем критериев:
• наличие владельца и куратора, как формально закрепленных (приказом, например), так и известных участникам процесса (и самим исполнителям этих ролей);
• наличие мотивирования ВП на процессные показатели;
• наличие актуальных моделей процесса;
• наличие регламента (-ов) процесса;
• плановые значения показателей процесса достигаются;
• сбор предложений участников процесса по его совершенствованию организован и т. п.
Или вопрос на аудит может быть поставлен так: «Какие проблемы в процессах являются критическими для клиентов процессов?»
Проектные работы состоят из двух простых этапов.
Этап 1. Сбор необходимой информации.
Этап 2. Формирование заключения в соответствии с критериями аудита (или перечнем вопросов) и (опционально) рекомендаций по его результатам.
Итогом проекта является документ (Заключение по аудиту), в котором процессы оцениваются по критериям аудита, формулируются ответы на вопросы аудита или приводится перечень замечаний и комментариев. Иногда в него включаются предложения по плану действий по результатам проекта или рекомендации по устранению выявленных проблем.
В проектах аттестации процессов они оцениваются на соответствие так называемой аттестационной модели25 по заранее определенным показателям. Целью таких работ обычно является определение места в рейтинге, уровня зрелости или уровня совершенства процессов.
Нередко также проводится аттестация на соответствие стандартам (международным, отраслевым или важного клиента, который, например, разрабатывает специальные требования для своих поставщиков, и т. п.).
План проектов аттестации похож на тот, что используется в проектах аудита. Также есть два этапа: сбора информации и формирования заключения и рекомендаций (если применимо к соответствующей задаче). Но часто есть еще и Предварительный этап. Разработка аттестационной модели. Он отсутствует только в случае, если выбранная в качестве базовой эталонная модель не требует или не допускает доработки для целей проекта (например, аттестация проводится на соответствие процессов требованиям компании Х, предъявляемым к процессам ее поставщиков).
Итоговый документ (Заключение по результатам аттестации) содержит детальные итоги сопоставления процессов с требованиями применяемой аттестационной модели, заключение и рекомендации по поводу дальнейших действий (иногда в форме плана мероприятий).
Упражнение
Если вы принимали участие в проектах аудита или аттестации процессов: какой план проекта использовался? Отличается ли он от описанного? Чем вызваны расхождения, если они есть?
2.2.2. Проекты общей диагностики процессов
Общая диагностика охватывает все процессы организации. Целями ее проведения являются оценка деятельности организации и формирование плана действий. Такие работы могут проводиться регулярно, чтобы сформировать план трансформации процессов, скажем, на год.
Вот типичный план проекта общей диагностики.
Этап 1. Выявление проблем процессов. Как правило, эта работа выполняется путем проведения интервью с кураторами, владельцами и участниками процессов, их смежниками и руководством организации. Обсуждаемый вопрос: проблемы конкретного процесса – в чем они заключаются и чем вызваны? Такие интервью проводятся по всем процессам. Точка зрения клиентов, поставщиков и акционеров на практике почти никогда не принимается во внимание, хотя по смыслу это было бы как минимум очень любопытно, а для интересов дела – весьма полезно. В ходе интервью рекомендуется использовать технику «Пять почему», чтобы выявить первопричины проблем, а не ограничиться борьбой с симптомами (когда за деревьями не видно леса).
Результат этапа 1 можно представить в виде так называемого дерева проблем (рис. 12). Хочу обратить внимание на то, что эти проблемы группируются по проблемным областям, которыми могут быть и сами процессы, и подсистемы управления организации. Это вызвано тем, что причины процессных неурядиц не всегда локализованы в самих процессах, иногда они носят кросс-процессный характер. Например, проблемы процесса «Продажи» могут быть связаны с хаосом в документообороте. Скажем, контрактные документы долго проходят процедуры согласования и подписания, а потом могут быть утеряны, не сохранены в архиве. Это положение дел отражается и на других процессах, например «Закупки сырья и материалов», и на других документах, например регламентах.
Рис. 12. Пример дерева проблем (фрагмент)
Надо отметить, что охват проекта общей диагностики – де-факто почти вся деятельность организации. Чтобы выплыть в этом «море» и увидеть общую картину, важно не уйти в излишние детали. Поэтому ответы на вопросы диагностики требуются довольно общие, необходимые и достаточные для решения задачи проекта.
Этап 2. Сбор информации о способах и приоритетах решения проблем процессов. Сбор информации проводится в виде второго раунда интервью с менеджментом организации. Используя дерево проблем, на этом этапе мы собираем информацию о том:
• какими способами можно решить выявленные проблемы;
• какие задачи на изменение могут быть поставлены в отношении конкретных процессов;
• какие задачи трансформации процессов наиболее актуальны;
• в какой последовательности следует принимать обсуждаемые меры и решать сформулированные задачи.
Для оценки приоритетов можно применять заранее разработанную шкалу, например: А – очень срочно, В – срочно, С – средний приоритет, D – несрочно, E – по возможности.
Результатом этапа являются сформулированные менеджментом организации и привязанные к проблемам процессов меры реагирования в виде проектных активностей (проектов, мероприятий, программ и т. п.), а также информация об их приоритетах и связях. Оформляется эта информация самым различным образом, но чаще всего это либо таблицы, либо модели.
Этап 3.Анализ собранной информации и разработка Плана действий (проектов). На этом этапе Проектная группа проводит собственный анализ и поиск идей решения выявленных проблем. Могут появиться и какие-то собственные соображения по поводу приоритетов, расходящиеся с мнением менеджмента.
Как я упомянул ранее, такой подход приводит к появлению списка мероприятий (проектов) в отношении системы управления в целом, не только локализованных в процессных цепочках. Результирующий план действий может содержать проекты, предполагающие применение всех методов трансформации процессов, а также выходящие за пределы собственно процессных решений.
Результат этапа – План действий (рис. 13), в котором можно видеть и процессы, выбранные для изменения, и приоритеты решения проблем, и выбранные методы трансформации, и мероприятия, «работающие» с системными проблемами. Удобно к такому Плану приложить диаграмму Ганта, дающую наглядную привязку проектов к времени. Увлекаться детальностью здесь не стоит. Если задачей является годовой план проектов трансформации процессов, то все, что существенно выходит за этот срок, можно просто обозначить крупными мазками.
Рис. 13. Шаблон-пример Плана действий (проектов) по результатам общей диагностики
Упражнение
Выполняли ли вы работы по общей диагностике процессов? Какой план проекта использовался? Отличается ли он от описанного? Чем вызваны расхождения, если они есть?
2.2.3. Проекты описания и локальной диагностики процессов
Проекты описания процессов встречаются довольно часто. В то же время просто описание особого смысла не имеет. То есть такие проекты – потеря времени и денег.
Какая задача обычно имеется в виду (и притом толком не формулируется почти никогда – в этом причина бессмысленности таких проектов)? Предполагается, что потом мы напишем регламент как надо. Или автоматизируем процесс. Или решим его проблемы. Но на деле просто берут и строят модели в нотации BPMN 2.0, например! Вот прямо сейчас одна из компаний, с которыми я общаюсь, поступает именно таким образом.
Но если такие задачи ставить, то просто описание – это полдела в лучшем случае. Ведь чтобы решить задачу регламентации, надо выбрать из того, как мы работаем, правильные варианты действий. Нужно устранить накопившиеся в процессе ошибки. Надо в тех местах, где текущий процесс явно работает не так, как мы хотели бы, спроектировать верный вариант. И наконец, чтобы описание строго работало на регламентацию (не моделировать лишнее, но собрать всю необходимую для регламента информацию), следует с самого начала определиться, что именно нам необходимо моделировать (то есть разработать Соглашения по моделированию под проект).
А для совершенствования процесса нужно не только поставить задачу, что именно мы хотим от процесса, но и собрать информацию под нее (и Соглашение по моделированию должно это потребовать), и провести анализ, и выбрать, в каком направлении менять процесс (какие решения реализовывать), и проектировать процесс «как должно быть», и делать План внедрения. И, что особо важно подчеркнуть, всегда одновременно с описанием надо проводить локальную диагностику процесса (то есть собирать ви́дение участниками процесса проблем и способов их решения) – эта информация будет весьма востребована и при анализе, и при проектировании целевых процессов.
Приведенные ранее варианты проектов все-таки предполагают, что описание (с локальной диагностикой в любом случае!) – это только первые этапы проектов совершенствования, автоматизации, регламентации. Но может ли быть смысл в таком проекте, что называется, без немедленного продолжения? Да, такие ситуации встречаются. Например, иногда требуется просто понять ситуацию с тем или иным процессом, чтобы определить, что с ним делать дальше. Или мы в свое время запустили новое направление деятельности и дали возможность специально образованной команде формировать процессы под себя. Но время прошло, направление заработало, и настала пора интегрировать процессы нового направления в соответствующие процессы, работающие с основной номенклатурой бизнеса. Именно с этой целью мы описываем и диагностируем, например, процессы «Производство» и «Производство продукции Х» (два параллельных проекта). А затем с учетом полученной информации реализуем проект «Проектирование целевого процесса “Производство”» с задачей интегрировать в него процесс нового направления, работающего с продукцией Х.
Как же следует планировать такие проекты? Итак, описание и локальная диагностика процесса А.
Прежде всего до начала работ мы формулируем задачу на проект, который начинается с Этапа 1 «Разработка Соглашений по моделированию». В частности, Проектная группа должна определить, на каком уровне детализации следует описывать процесс и какую информацию показывать на моделях для решения задачи проекта.
Основное содержание проекта составляет Этап 2 «Моделирование и локальная диагностика процессов». Эти работы проводятся одновременно. Наиболее частой ошибкой является попытка сначала провести моделирование, а затем – диагностику. Обычно это следствие неопытности моделировщиков. Результаты диагностики в таких проектах весьма убогие, плановые сроки обычно сильно превышены, а эксперты по процессу, которых привлекают для получения информации, измотаны и раздражены.
Результатом проекта будут Соглашения по моделированию и Альбом (и база данных, набор) моделей процесса с результатами локальной диагностики.
Упражнение
Принимали ли вы участие в проектах описания процессов? Какой была их задача? Формулировалась ли она? Проводилась ли локальная диагностика? Одновременно с моделированием или после него? Что представляли собой и как использовались результаты проекта?