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

Когда ждать результатов проекта?

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

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

То же самое касается возврата инвестиций. Рассчитав пользу, полученную от внедрения, заказчик оценивает скорость возврата инвестиций. Как правило, инвестиции окупаются в течение полугода — полутора лет после завершения проекта автоматизации ТОиР.

Цифровая трансформация: люди и алгоритмы

Но! Есть одно большое но. Чтобы заработала не только система, но и люди в системе, необходимо правильно настроить не только алгоритмы внутри программы, но и… процессы на предприятии.

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

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

Первый парадокс. Любая система неизбежно стремится к энтропии — т.е. саморазрушению

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

Второй парадокс. Система сильна настолько, насколько сильно ее самое слабое звено

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

Парадокс номер три. Ничто не ограничивает действия сильнее, чем фраза: «Делай, что хочешь»

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

Четвертый парадокс. Затраты возникают как при любом действии, так и при бездействии

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

На картинке ниже — различия в подходах к управлению функцией и проектом.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

А теперь поговорим о том, как же не стать «отрядом самоубийц», а превратиться в проектную команду мечты.

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

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

В ответ он слышит:

— Я рядовой Смит. Немедленно сами возьмите влево!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Положительный эффект

А теперь — о дополнительном положительном эффекте, который дает качественный поход к работе с командой проекта.

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

Вот несколько примеров.

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

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

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

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

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

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

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

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