Сергей Грачев: как сформировать проектную команду цифровизации ТОиР

Наш проектный опыт

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

За весь период существования продукта 1С:ТОИР «Деснол Софт» выполнил более 250 проектов повышения эффективности управления активами. Проекты реализуются в самых разных отраслях. Поэтому мы приобрели значительный опыт, отработали целый ряд навыков и развили у своих сотрудников соответствующие компетенции. Создали собственную проектную технологию, которая помогает не терять время и, соответственно, деньги заказчиков на «изобретение велосипеда».

На что обратить внимание

На что же надо обратить внимание? Чего стараться избегать на проектах? А что — неизбежно, и надо просто принять это и научиться с этим жить?

Попробуем разобраться, как же сделать так, чтобы, приступая к проекту цифровой трансформации в области ТОиР, не оказаться в составе «отряда самоубийц», а сформировать «команду мечты».

1. Проститесь с иллюзиями

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

Ставьте перед собой реальные цели и фиксируйте, как вы измерите их достижение. Если вы занимаетесь бизнесом, вы это умеете.

2. Проект и процесс — это не одно и то же

У нас есть пример, когда проектная команда крупного заказчика — предприятия химической промышленности — недостаточно успешна лишь потому, что ее участники не понимают сути проектной деятельности. И путают ее с процессной. В такой ситуации горстка энтузиастов, даже преследуя высокие цели и имея компетенции в ТОиР, может слить инвестиции в трубу. Поэтому, начиная цифровую трансформацию, и вам, и вовлеченным в проект сотрудникам нужно четко понимать, что такое проектные технологии.

Проект — это однократная нецикличная деятельность. У проекта всегда есть начало и есть конец. Всегда есть заранее установленная цель. Участники проекта строго взаимозависимы. В их распоряжении — ограниченное время и ограниченные ресурсы.

Руководитель проекта — интегратор, а не администратор, его задача — объединить членов команды для достижения цели.

Участники проекта — узкие специалисты, они обладают уникальными компетенциями и не взаимозаменяемы. При этом — важно! — они не могут достичь результата проекта поодиночке. Именно поэтому им требуется объединиться на определенный промежуток времени.

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

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

3.  Чем более сложно функционально структурирована организация, тем сложнее управлять проектами

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

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

4. Внешняя команда + внутренняя команда = успех!

И тут кроется один интересный момент. А что если для выполнения цифровой трансформации обратиться к внешней команде, для которой выполнение проектов само по себе является функцией? То есть к команде, которая специализируется на выполнении проектов?

Будет ли разница в подходах? Несомненно, да. Назовем несколько плюсов внешней команды. Проект выполняет независимая бизнес-единица, которая сконцентрирована на проекте, имеет опыт подобных проектов и хорошо разбирается в доменной области — в нашем случае, в ТОиР. Менеджер занимается только проектом. Как результат — высокая скорость выполнения проекта, быстрая реакция на решения. Плюс высокий уровень вовлеченности и качества распределения обязанностей на проекте.

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

Что же гарантирует команде успех?

• Четкое понимание всеми общей цели.
• Ясная постановка задач (что необходимо сделать, как это можно сделать, когда необходимо закончить работу, приоритет задач).
• Закрепление за каждым зоны и степени ответственности.
• Использование подходящего метода контроля.

5. Проблемы — это нормально

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

Проектные риски — это вообще отдельная тема для разговора. На каждый план А должен быть план Б, а на каждый план Б — план В.

У себя в департаменте производства 1С:ТОИР мы ведем реестры рисков, описываем нестандартные ситуации, чтобы не повторить или предвосхитить их на новых проектах. А также разрабатываем универсальные регламенты, инструкции и шаблоны, которые можно использовать в готовом виде или адаптировать под нужды клиентов, что упрощает нашим заказчикам выполнение задач на каждом этапе проекта.

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

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

Правда, они немного просчитались. Это не остановило внедрение приложения. Потому что начальство выдало им служебные мобильные телефоны с уже установленным приложением.

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

Конечно, снизить эффективность использования приложения им не удалось. В ходе проекта мы воспитали в специалистах новые привычки, они научились пользоваться приложением. И их производительность увеличилась на 35%, а оперативность реагирования на заявки выросла в два с половиной раза!

Как не стать отрядом самоубийц?

Представьте. Корабль следует ночью в сплошном тумане. На мостике — седой суровый капитан. Вдруг прямо по курсу — огни. Капитан строго говорит в рупор:

— Я адмирал Джонсон и крейсер «Непобедимый»! Немедленно возьмите вправо!
 В ответ он слышит:
 — Я рядовой Смит. Немедленно сами возьмите влево!

— Вы что, Смит, не в своем уме? — кричит капитан. — Я адмирал Джонсон!

— А я, — отвечает Смит, — смотритель маяка!

Мораль этой короткой истории заставляет нас размышлять о том, что важнее: формальное соответствие званию или то, что каждый из нас представляет?

Эти же мысли приходят к нам на каждом проекте.

Сбалансированная команда

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

В этой связи вспоминается такой пример. В проект среди прочих включили заместителя генерального директора по технической части — человека властного, но не очень современных взглядов. Во время одного из первых совещаний на проекте, которое было посвящено формированию иерархии объектов ремонта в 1С:ТОИР, он перебивает нашего методолога и начинает говорить то, что считает нужным. К сожалению, он не знает ни нашей системы, ни методологических подходов и не стремится в них разобраться. Команда заказчика парализована. Никто не понимает, кого слушать.

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

Распределение ролей

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

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

А вот каким образом обычно формируется команда проекта со стороны заказчика? Есть несколько вариантов.

1. Самый распространенный — когда инициатором проекта является бизнес-заказчик — то есть служба главного механика или служба технического директора. Они инициируют проект и сами же участвуют в нем. Кто-то из этой службы — чаще всего главный механик — выступает в роли руководителя проекта.
2. Когда инициатором проекта выступает IT-служба. Грамотный IT-директор убеждает руководство, что необходима цифровая трансформация. Однако начальники IT-служб реже выдвигаются на роль руководителей проектов ТОиР, т.к. недостаточно хорошо знают все нюансы бизнес-процессов, связанных с ремонтами и обслуживанием оборудования. При этом участие IT-специалиста в качестве активного стейкхолдера на проекте — обязательно.
3. В крупных холдингах перед проектом проводится тендер, отбором претендентов занимаются одни люди, а проект потом ведут совершенно другие. Как правило, в таком случае со стороны управляющей компании холдинга выделяется куратор, который отслеживает ход проекта.

Мы сейчас не будем перечислять всех стейкхолдеров — то есть заинтересованных лиц — проекта. Но скажем несколько слов о кураторе.

Роль куратора

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

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

Далее наша коммуникация с куратором может строиться по двум принципам:

• либо по календарю (например, назначается отчетный период — месяц, по истечении которого мы информируем куратора о ходе проекта),
• либо по мере прохождения этапов проекта (в таком случае отчет сдается за каждый этап).

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

Заинтересованность и мотивация членов команды

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

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

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

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

Коней на переправе не меняют

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

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

Что в итоге? Нам пришлось откатиться на несколько этапов назад, чтобы еще раз попытаться взять высоту. Каков эффект? Потеря скорости, времени, в итоге — конечно, же, денег.

Критерии успеха проекта

Итак, подытожим. Каковы критерии успеха проекта?

• Заинтересованность стейкхолдеров.
• Поддержка со стороны высшего руководства (куратора).
• Четкое формулирование требований.
• Реалистичность ожиданий и правильное планирование.
• Профессиональная внешняя команда внедрения.
• Заинтересованная и квалифицированная внутренняя команда проекта.
• Четкое понимание командой задач и целей, а также действий, которые приведут к их реализации.