18 января 2023
В этой публикации мы делимся инсайтами авторской проектной технологии и опыта автоматизации ТОиР, которые «Деснол Софт» развивает и аккумулирует вот уже более 17 лет. В проекте всегда участвуют две стороны: заказчик и интегратор. Мы, выступая в роли интегратора, делимся с новыми заказчиками своим опытом организации проектных работ, чтобы, формируя проектную команду мечты, не превратиться в «Отряд самоубийц».
Вы можете посмотреть видео или прочитать статью ниже — как вам комфортнее.
Вот уже 17 лет с небольшим мы внедряем 1С:ТОИР в России и за ее пределами. Каждый год — это несколько завершенных проектов. В 2020, несмотря на пандемию, таких было 8. В настоящий момент под контролем наших команд — более 20 проектов с разным разбегом по временной шкале от старта до финиша.
Экосистема 1С:ТОИР
За весь период существования продукта 1С:ТОИР «Деснол Софт» выполнил более 250 проектов повышения эффективности управления активами. Проекты мы реализуем в самых разных отраслях. Поэтому приобрели значительный опыт, отработали целый ряд навыков и развили у своих сотрудников соответствующие компетенции. Создали собственную проектную технологию, которая помогает не терять время и, соответственно, деньги заказчиков на «изобретение велосипеда».
Целый ряд наших проектов удостоен наград различных профессиональных конкурсов. Одним из ключевых критериев на этих конкурсах является экономический эффект, которого достигают наши клиенты в результате цифровизации процессов управления активами. Чтобы понять эффективность внедрения, мы замеряем показатели на старте проекта. И можем оценить результат на финише.
Победы наших клиентов в различных профессиональных конкурсах
Правда, если для нас как для интеграторов финиш (то есть завершение проекта) — это запуск системы в промышленную эксплуатацию, то для наших заказчиков с этого момента, по сути, всё только начинается. Проект окончен, но впереди — каждодневная работа в 1С:ТОИР, планирование, анализ отчетности, принятие решений, которые помогут оптимизировать процессы и повысить эффективность. То есть всё то, ради чего внедряется система.
Экономический эффект
По нашему опыту, если проект прошел успешно, первые результаты от внедрения заказчик видит уже на этапе опытно-промышленной эксплуатации. Они касаются, в первую очередь, ускорения получения доступа к данным, более оперативного формирования отчетности и повышения скорости реагирования на инциденты.
А вот более серьезные показатели эффективности, которые влияют на экономику предприятия, проявляются позже. Обычно их начинают фиксировать через полгода — год после начала работы системы в промышленных условиях. Это такие показатели, как снижение простоев, повышение коэффициента готовности оборудования, рост оборачиваемости складских запасов, сокращение себестоимости ремонтов и другие.
То же самое касается возврата инвестиций. Рассчитав пользу, полученную от внедрения, заказчик оценивает скорость возврата инвестиций. Как правило, инвестиции окупаются в течение полугода — полутора лет после завершения проекта автоматизации ТОиР.
Но! Есть одно большое но. Чтобы заработала не только система, но и люди в системе, необходимо правильно настроить не только алгоритмы внутри программы, но и... процессы на предприятии.
Проект цифровизации — это сложная штука. Он означает, что в компании началась трансформация, т.е. перестройка процессов, перераспределение сил, появление новых зон ответственности, сокращение рутинных операций, которые заменяются чем-то новым, неизведанным.
Задумываясь о цифровизации процессов, управленцу нелишне учесть несколько моментов, которые мы сформулировали в виде парадоксов.
Поэтому любое дело, пущенное на самотек, постепенно превратит даже самую стройную организацию в хаос. То же самое с проектами. Проекты, пущенные на самотек, никогда не бывают успешными.
Вы сильны не в том, в чем вы сильны. Вы сильны настолько, насколько крепко выдерживает натиск обстоятельств ваш самый слабый элемент производственной цепи. Если ваша сильная сторона — качество производимой продукции, но вы уделяете недостаточно внимания процессу обслуживания оборудования, на котором она производится, вывод очевиден. Рано или поздно качество снизится, и ваше конкурентное преимущество пропадет. В современном мире цифровая трансформация — уже неизбежность. И чем раньше вы усилите свое самое слабое звено, тем меньше рисков оно принесет вам в будущем.
Поэтому прямо на старте проекта необходимо уделить внимание постановке цели и метрикам для ее измерения, сформировать четкие ожидания. На основании целей будет ясно, что делать, для достижения цели будет составлен план. Проект будет успешным не в том случае, если вы подпишете акт. И не в том случае, если вам установят систему и отчитаются об этом. Проект считается успешным, если его результат соответствует ожиданиям.
Ответьте для себя на вопрос, чего вы хотите: успевать или опаздывать? На что вы готовы потратить деньги: на то, чтобы предотвратить ошибки или на то, чтобы их исправлять? При ответе на этот вопрос сразу же задайте себе другой: а что выйдет дороже?
Все без исключения наши успешные заказчики (вне зависимости от размера их бизнеса) — это компании, выбором которых было: инвестировать в «действие».
На что же надо обратить внимание? Чего стараться избегать на проектах? А что — неизбежно, и надо просто принять это и научиться с этим жить?
Сейчас мы с вами попробуем разобраться, как же сделать так, чтобы, приступая к проекту цифровой трансформации в области ТОиР, вы не оказались в составе «отряда самоубийц», а сформировали «команду мечты».
Первое, что надо сделать, это — проститься с иллюзиями. И вместо них сформировать трезвые ожидания. Это чрезвычайно важно. Именно по этим ожиданиям вы будете оценивать результат и решать: успешен проект или нет.
Ставьте перед собой реальные цели и фиксируйте, как вы измерите их достижение. Если вы занимаетесь бизнесом, вы это умеете.
Посмотрите на стандартный «проектный треугольник глазами практика» на картинке ниже. Изучив его, вы уже начинаете понимать, каких иллюзий следует избегать.
Расстановка приоритетов
У нас есть пример, когда проектная команда крупного заказчика — предприятия химической промышленности — недостаточно успешна лишь потому, что ее участники не понимают сути проектной деятельности. И путают ее с процессной. В такой ситуации горстка энтузиастов, даже преследуя высокие цели и имея компетенции в ТОиР, может слить инвестиции в трубу. Поэтому, начиная цифровую трансформацию, и вам, и вовлеченным в проект сотрудникам нужно четко понимать, что такое проектные технологии.
Проект — это однократная нецикличная деятельность. У проекта всегда есть начало и есть конец. Всегда есть заранее установленная цель. Участники проекта строго взаимозависимы. В их распоряжении — ограниченное время и ограниченные ресурсы.
Руководитель проекта — интегратор, а не администратор, его задача — объединить членов команды для достижения цели.
Участники проекта — узкие специалисты, они обладают уникальными компетенциями и не взаимозаменяемы. При этом — важно! — они не могут достичь результата проекта поодиночке. Именно поэтому им требуется объединиться на определенный промежуток времени.
Достижение цели проекта возможно только при совместной работе. Для реализации проекта создается временная структура. При этом вся картина цифровой трансформации находится в голове у руководителя проекта. От остальных — важен вклад, который они вносят в соответствии со своими компетенциями.
Как вы видите, эта картина сильно отличается от любого из распространенных принципов функционального менеджмента. Поэтому и подход к реализации проекта должен быть особым.
Проект и процесс
Одна из причин — в том, что в бюрократических (даже в хорошем смысле) структурах проект всегда будет на втором месте по отношению к основным задачам специалистов. Слишком сильна в таких организациях приверженность правилам и требованиям соответствия установленным стандартам.
На картинке ниже — различия в подходах к управлению функцией и проектом.
Чем более сложно функционально структурирована организация, тем сложнее управлять проектами
Ключевые различия в том, что в основе проекта лежат управление изменениями и управление рисками. Проект происходит в условиях неопределенности. В основе же функциональной деятельности — четкое следование успешным технологиям и обеспечение стабильного результата за счет полного понимания промежуточных шагов к достигаемой цели.
И тут кроется один интересный момент. А что если для выполнения цифровой трансформации обратиться к внешней команде, для которой выполнение проектов само по себе является функцией? То есть к команде, которая специализируется на выполнении проектов?
Будет ли разница в подходах? Несомненно, да. Назовем несколько плюсов внешней команды. Проект выполняет независимая бизнес-единица, которая сконцентрирована на проекте, имеет опыт подобных проектов и хорошо разбирается в доменной области — в нашем случае, в ТОиР. Менеджер занимается только проектом. Как результат — высокая скорость выполнения проекта, быстрая реакция на решения. Плюс высокий уровень вовлеченности и качества распределения обязанностей на проекте.
Внешняя команда
Так, мы пришли к выводу, что для выполнения проекта цифровой трансформации наиболее успешна комбинированная команда, в которую входит как внешняя команда (интегратор, разработчик IT-решения), так и специалисты заказчика.
Что же гарантирует команде успех?
Команда мечты
Возникновение проблем в ходе выполнения проекта — это нормально. Ведь проект — это рисковое предприятие, требующее учета множества различных факторов.
Проектные риски — это вообще отдельная тема для разговора. На каждый план А должен быть план Б, а на каждый план Б — план В.
У себя в департаменте производства 1С:ТОИР мы ведем реестры рисков, описываем нестандартные ситуации, чтобы не повторить или предвосхитить их на новых проектах. А также разрабатываем универсальные регламенты, инструкции и шаблоны, которые можно использовать в готовом виде или адаптировать под нужды клиентов, что упрощает нашим заказчикам выполнение задач на каждом этапе проекта.
Правда, конечно, бывают ситуации, которые сложно предугадать. Вот, например, на одном из наших проектов мы столкнулись с такой проблемой, как саботаж сотрудников. Вообще саботаж — весьма распространенное явление, которое возникает в том случае, если люди не понимают или по какой-то причине не принимают изменения, связанные с цифровой трансформацией. Чаще всего потому, что им толком не разъяснили ни цели, ни причины изменений, ни их место в новой реальности.
На этот раз саботаж удивил нас, потому что принял причудливую форму. В одной крупной розничной сети, где мы делали проект, рабочим объявили, что теперь для ремонтов в торговых точках будет использоваться разработанное нами мобильное приложение. Приложение устанавливается, само собой, на бескнопочные смартфоны. Чтобы насолить начальству, на следующий день все сотрудники явились на работу с... кнопочными телефонами.
Правда, они немного просчитались. Это не остановило внедрение приложения. Потому что начальство выдало им служебные мобильные телефоны с уже установленным приложением.
Но история на этом не закончилась. Сопротивление продолжалось. Просочилась информация, что телефоны будут использоваться не только для передачи заявок на ремонты, но и для контроля пребывания сотрудников на объектах. (Это на самом деле правда, местоположение пользователя отслеживается по геокоординатам, а геокоординаты передаются в 1С:ТОИР). И тогда рабочие стали обматывать телефоны... фольгой и прятать их в кастрюли, если задерживались дома перед работой.
Конечно, снизить эффективность использования приложения им не удалось. В ходе проекта мы воспитали в специалистах новые привычки, они научились пользоваться приложением. И их производительность увеличилась на 35%, а оперативность реагирования на заявки выросла в два с половиной раза!
А теперь поговорим о том, как же не стать «отрядом самоубийц», а превратиться в проектную команду мечты.
Представьте. Корабль следует ночью в сплошном тумане. На мостике — седой суровый капитан. Вдруг прямо по курсу — огни. Капитан строго говорит в рупор:
— Я адмирал Джонсон и крейсер «Непобедимый»! Немедленно возьмите вправо!
В ответ он слышит:
— Я рядовой Смит. Немедленно сами возьмите влево!
— Вы что, Смит, не в своем уме? — кричит капитан. — Я адмирал Джонсон!!!
— А я, — отвечает Смит, — смотритель маяка!
Мораль этой короткой истории заставляет нас размышлять о том, что важнее: формальное соответствие званию или то, что каждый из нас представляет?
Эти же мысли приходят к нам на каждом проекте.
Когда стартует проект, становится важным не формальное соответствие человека должности, не звание и не чин, а вклад, который вносит участник проекта для достижения цели. Эту идею очень важно донести до каждого участника команды. Поэтому подбор членов команды проекта должен быть сделан тщательно: важно, чтобы все ключевые роли были сбалансированы. А уровень компетенций каждого из участников соответствовал целям проекта.
В этой связи вспоминается такой пример. В проект среди прочих включили заместителя генерального директора по технической части — человека властного, но не очень современных взглядов. Во время одного из первых совещаний на проекте, которое было посвящено формированию иерархии объектов ремонта в 1С:ТОИР, он перебивает нашего методолога и начинает говорить то, что считает нужным. К сожалению, он не знает ни нашей системы, ни методологических подходов и не стремится в них разобраться. Команда заказчика парализована. Никто не понимает, кого слушать.
В чем тут проблема? В первую очередь, в том, что в проект необдуманно включили стейкхолдера, компетенции которого ни организационно, ни технически не соответствуют масштабам цифровой трансформации. И получается, что именно он тянет свою команду вниз.
Чтобы сбалансировать команду, распределение ролей, обязанностей и ответственности между участниками должно быть сделано в самом начале — в момент инициации проекта.
С нашей стороны (со стороны интегратора) команда проекта понятна. В зависимости от сложности и масштаба внедрения в ней участвуют: руководитель проекта, консультант, программист, если необходимо — методолог и архитектор.
А вот каким образом обычно формируется команда проекта со стороны заказчика? Есть несколько вариантов.
Распределение ролей
Мы сейчас не будем перечислять всех стейкхолдеров — то есть заинтересованных лиц — проекта. Но скажем несколько слов о кураторе.
Роль куратора на проекте огромна. При том, что он не должен появляться на проекте ни каждый день, ни каждую неделю, ни даже каждый месяц. Важно, чтобы ощущался эффект его присутствия, внимания к проекту, и чтобы он возникал в определенные решающие моменты.
И, как правило, первый решающий момент — это как раз инициация проекта. Успешная практика: когда мы проводим первое установочное совещание, куратор собирает всю проектную команду, говорит о важности проекта, ответственности, целях, представляет подрядчика (то есть нас) и говорит о распределении ролей.
Далее наша коммуникация с куратором может строиться по двум принципам:
В качестве куратора часто может выступать технический директор или заместитель генерального директора, курирующий производство. Или же представитель управляющей компании, если мы имеем дело с холдингом.
При распределении ролей на старте проекта очень важно никого не упустить. В противном случае это может создать проблемы при реализации.
Вспоминается случай, когда при проведении тендера в контур проекта забыли включить руководителя службы безопасности. И потом он всем своим видом на протяжении проекта демонстрировал, будто участие в проекте ему навязали.
Вообще включение в проектную команду незаинтересованных лиц, которые не разделяют цели проекта, — очень опасная штука. В лучшем случае такой человек будет пассивен, в худшем — будет вставлять палки в колеса. Таких людей лучше сразу выводить за рамки проекта.
Максимальная польза достигается лишь в том случае, когда ключевые участники мотивированы, в том числе за счет установленных KPI. Например, сейчас на одном из проектов с нами работает главный механик, у которого в KPI «зашито», что он до конца года должен запустить систему. Это влияет на его квартальную и годовую премию. Поэтому он и сам старается, и всеми силами толкает своих товарищей, и нас держит в жестких рамках.
Серьезная проблема может возникнуть, если команда проекта разваливается по частям.
Мы были свидетелями такого опыта, причем на крупном предприятии, где нетиповой, сложный проект продолжается уже не один год. Эта компания, к сожалению, не смогла удержать свою «команду мечты», не удержала ключевых методологов. Как результат, утеряна общая идея, основная концепция. Новый сотрудник, который курирует проект, хорош как специалист, но имеет свой взгляд и ставит под сомнение решения предшественников. Проблема в том, что у новой команды нет общего видения, каждый из ее участников пытается доказать, что его мнение — единственно верное.
Что в итоге? Нам пришлось откатиться на несколько этапов назад, чтобы еще раз попытаться взять высоту. Каков эффект? Потеря скорости, времени, в итоге — конечно, же, денег.
Система + компетенции
А теперь — о дополнительном положительном эффекте, который дает качественный подход к работе с командой проекта.
Вот несколько примеров.
Ну и в завершении — история про повышение по службе. Совсем недавно в крупном холдинге ведущий инженер по ТОиР отлично показал себя как менеджер проекта на пилотном внедрении. Система перешла в промышленную эксплуатацию, сейчас успешно работает и развивается. После завершения проекта ему позвонили из управляющей компании холдинга и предложили должность главного инженера филиала.
Подобные истории — не единичны. Практически каждый второй успешно выполненный проект означает движение по карьерной лестнице участников этого проекта. Специалист отдела по цифровой трансформации становится заместителем CIO. Главные механики идут на повышение. Создаются отделы ТОиР.
Те знания, тот опыт, компетенции, навыки, которыми мы обмениваемся на проектах, значительно обогащают всех участников. Они дают возможности и стимул для роста. Успех проекта — несомненно, общая заслуга. И мы рады вносить свой вклад.
Критерии успеха проекта
Итак, подытожим. Каковы критерии успеха проекта?
Если вам нужно больше консультаций по поводу того, как в оптимальные сроки и с необходимым качеством выполнить проект цифровой трансформации ТОиР, обращайтесь в «Деснол Софт».
Поделиться:
