Без мозгов никуда: как классификация проектов помогает наладить процессы

Проблемы в операционке. Или нет?

В большинстве проблем, которые возникают в компании, принято винить операционку. Давайте разберемся, что это вообще такое.

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

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

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

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

Чтобы решить проблему, в первую очередь нужно разобраться с понятиями: что такое проект, продукт, процесс и чем они различаются.

Что такое процесс, проект и продукт

Рассмотрим на примере банка и банковского продукта. 

• Процесс. Например, выдача кредитов. Процесс налажен: понятно, куда поступают кредитные заявки и как с ними работать. 
• Проект. Допустим, мы решили выпустить новую кредитную карту. У нас нет ничего, кроме идеи, задача — с нуля что-то разработать, собрать фокус-группу, понять, как это работает на практике. А затем на выходе провести серию тестов, по которым будет понятно: проект удачный или неудачный. 
• Продукт. Если проект, описанный в предыдущем пункте, окажется удачным, он перейдет в другую категорию — станет продуктом, готовым к продаже на рынке. И в этот момент появляется новый процесс — процесс поддержания продукта. Со временем он так же станет отлаженным: мы понимаем, как и что работает, измеряем определенные метрики и пр. 

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

Классификация проектов

Как понятно из примера выше, проект — временная деятельность, необходимая для создания продукта или услуги. При этом и продукт, и процесс его создания могут быть как типовыми, так и уникальными. Для наглядности рассмотрим шкалу координат, где с одной стороны — продукт, разрабатываемый в ходе проекта, с другой — процесс его создания.

Приведем примеры по каждой категории: 

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

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

Как управлять разными типами проектов

1. «Мозги». Если мы впервые работаем с проектом, основная задача — снизить уровень риска, сделать его управляемым и предсказуемым, т. е. перевести в категорию «Седина». 

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

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

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

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

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

Ошибки на разных этапах реализации проектов

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

1. Инициация проекта (появление идеи). На этом этапе прописывается техническое задание, определяются заинтересованные лица, формируется логическая структура проекта. Например, вам в голову пришла идея написать статью на конкретную тему.
2. Планирование. Создание проектной команды, планирование, управление рисками, организация работ по проекту. Вы обдумываете, кто будет писать статью, о чем вы хотите рассказать и пр.
3. Выполнение. Реализация проекта, мониторинг и контроль. Вы собираете контент, пишете материал, вносите правки.
4. Завершение. Закрытие проекта. Например, публикация статьи в блоге.

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

1. Управление рамками проекта. Например, вы запланировали выложить статью в среду утром, но произошел технический сбой. Если такие сбои будут регулярно, вы столкнетесь с проблемой управления рамками проекта — не сможете вовремя выкладывать материалы. 
2. Управление сроками проекта. У любого проекта есть начало и конец. Если вы регулярно не укладываетесь в сроки, эту проблему нужно решать.
3. Управление стоимостью. Здесь можно рассматривать проекты не только с точки зрения потраченных денег, но и времени. Например, вы готовы потратить на написание статьи 7 часов, но не готовы потратить 107 часов. 
4. Управление рисками проекта. Допустим, спикер, который предоставил информацию для статьи, в последний момент отказался от публикации. А вы уже пообещали материал другой площадке. В любом проекте есть риски, и нужно заранее продумывать варианты действий в разных ситуациях.
5. Управление коммуникациями проекта. Работая практически над любым проектом, вы коммуницируете с людьми. И в процессе коммуникации также могут возникать проблемы. Например, для статьи нужно отрисовать иллюстрацию, но дизайнеры говорят, что у них нет времени. Что делать в этом случае, куда бежать?
6. Управление людьми. Это могут быть ошибки, связанные с мотивацией, вовлечением, оценкой эффективности персонала. Они часто возникают при работе с крупными проектами, где задействовано большое количество сотрудников. Например, разработка коммерческого предложения для тендера.
7. Управление качеством проекта. Если вернуться к примеру со статьей, какие вы формируете критерии качества? Вы хотите получить 100 лайков или не менее 50 переходов? Как вы оцениваете качество статьи, в чем оно измеряется?
8. Управление поставками. С проблемами на этом этапе можно столкнуться, например, при организации конференции. Важно проследить, чтобы все пришло вовремя: звуковая аппаратура, кейтеринг.  
9. Интеграция управления проектом. Если вы провели конференцию, то как будете использовать наработанные практики при проведении дальнейших мероприятий? Допустим, вы разработали регламент по работе со спикерами: где он будет лежать, как часто его нужно обновлять, как понять, актуальные ли данные, пользуются ли ими другие сотрудники и т. д. Такие регламенты могут возникать на разных этапах внедрения проекта: от инициации до завершения. Задача — определить, как вы сможете их применять в рамках конкретного проекта или как их интегрировать в целом в жизнь предприятия. 

Итак, вы выявили, на каком этапе реализации проекта возникает сбой и с чем он связан. Что дальше? А дальше проблему нужно решать. И здесь основная ошибка — пытаться измерить все проблемы одной линейкой или наладить процессы за счет разработки регламента. Но так это не работает. У каждого типа проектов своя проблематика и свои пути решения. Да и регламенты нужны не всегда и не везде.

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

Как наладить бизнес-процессы? Чек-лист

Вы узнали о наличии определенной проблемы. Ваши действия:

1. Правильно классифицируйте проект. К какому типу он относится: «Седина», «Мозги» или «Процедура». 
2. Исходя из типа проекта определите основную задачу. Что вам нужно сделать в рамках проекта: упростить управление, все стандартизировать или снизить уровень рисков.
3. Используйте способ отрисовки бизнес-процесса «AS IS» (так, как есть) и матрицу ответственности для визуализации текущего процесса с указанием этапов проекта. 
4. Определите, на каком этапе возникает проблема: инициация проекта, планирование, выполнение или завершение. Для этого подробно распишите процесс его реализации, кто и за что отвечает. 
5. Определите причину возникновения проблемы. Сбой произошел из-за плохо обозначенных сроков, проблема в управлении людьми, качестве, поставщиках или в чем-то еще?
6. Найдите пути решения проблемы. Определите, что нужно для устранения сбоя и как сделать так, чтобы он больше не возник. 
7. Отрисуйте процесс еще раз, превратив его в «TO BE» (так, как должно быть), и обновленную матрицу ответственности для визуализации решения. 
8. Обсудите результаты с теми, кто будет пользоваться данным решением, все ли вводные вы учли?
9. Внедряйте изменения.