Опыт руководителя проекта со стороны заказчика. Ищем баланс. Достигаем результата

Меня зовут Екатерина, я руковожу проектами автоматизации на стороне заказчика. На примере перехода на 1С:ERP производственной компании Cersanit я поделюсь своим опытом: как мы переходили, с какими проблемами сталкивались, и как мы их преодолевали.

В докладе мы рассмотрим вопросы:

• Как уложиться в срок и в бюджет – это самый важный вопрос.

• Как мы работаем с рисками – нужно ли с ними работать, кто должен с ними работать.

• Разберем ошибки, которые мы совершили – это приходит только с опытом, заранее никто не расскажет, как правильно все сделать.

• Как мы выбирали исполнителя – это важно для подрядчиков, чтобы они понимали, из кого и на основе чего выбирает крупная компания.

• Какую проектную технологию мы для себя определили. И какая проектная технология для какой компании больше подойдет, на мой взгляд.

Пару слов о компании Cersanit. Мы производим керамическую плитку и мебель для ванных комнат и акриловых ванн. У компании 12 собственных заводов, она продает в 44 страны мира.

В России у компании Cersanit три производственных площадки и торговый дом.

Суть проекта

Перед нами стояла задача перевести с УПП на ERP учет на этих трех производственных площадках и в торговом доме. Плюс к этому у торгового дома был огромный блок интеграции с различными системами:

• ЗУП;

• WMS;

• EDI;

• 1С:Документооборот – бизнес требовал, чтобы с ним была бесшовная интеграция;

• БИТ.ФИНАНС, блок МСФО;

• отчетность в BI – кубы для отчетности;

• интеграция с Salesforce – это CRM-система.

Проект поделился на три этапа.

• Первый этап – это перевод на ERP торгового дома и интеграция со всеми системами. Это то, что мы уже сделали.

• Сейчас (прим. ред. доклад от 11.11.2021) мы находимся на втором этапе – с 1 января 2022 года мы планируем перевести две производственные площадки.

• И в середине 2022 года – третью.

На картинке – контур проекта, и где мы сейчас находимся.

Несколько цифр по первому этапу проекта:

• Он длился два года.

• Было автоматизировано 300 рабочих мест.

• Команда менялась более трех раз.

• Запуск осуществлялся в условиях удаленной работы

• Мы запускались в середине года. Про запуск в середине года – отдельная история. Нам это предстоит еще раз, но если у вас такого опыта не было – лучше так не делать. Если удается бизнес убедить, что не надо переходить в середине года, то не надо переходить. Это сложно, это большая нагрузка и большой стресс как для бухгалтерии, так и для ИТ-службы.

Как работать, если команды меняются

Мне кажется, что нестабильность команды – это один из основных рисков таких длинных проектов, как у нас (у нас только первый этап длился 2 года).

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

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

• протоколы всех встреч: кто был, какие решения принимали;

• все ЧТЗ;

• вся финальная документация и т.д.

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

И сейчас, уже на второй стадии проекта, мы обращаемся к этим документам. Потому что идейных вдохновителей решений уже нет, но система как-то настроена.

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

Можно ли запускаться на удаленке

Запуск на удаленке для нас был вынужденным решением. Так произошло из-за того, что нас настиг ковид. И изначально мы вообще хотели отложить проект на неопределенный срок – запуск был под угрозой, было непонятно, когда все закончится. Но в результате мы были вынуждены перейти на формат удаленной работы.

• Мы организовали удаленную работу в Teams, который интегрирован с Outlook. Это очень удобно – при назначении встреч мы видим рабочий календарь сотрудников и есть возможность кинуть ссылку коллеге, чтобы он присоединился к совещанию.

• Даже сейчас, уже имея возможность встречаться офлайн, мы все совещания всегда проводим онлайн. К разработке проектных решений и демонстрации функциональности мы иногда подключаем очень большое количество участников – таким образом все заинтересованные лица погружаются в контекст. Так удается избежать ситуации, когда кто-то обсуждает какую-то задачу, а ее исполнителю об этом не сказали. Когда мы решаем какие-то вопросы, мы имеем возможность онлайн подключать человека. Сотрудники компании лояльно относятся к таким совещаниям, подключаются на 5-10 минут, отвечают на вопросы, и все – задача закрыта.

• Все встречи мы записываем. Мы демонстрируем экран, сотрудники компании демонстрируют рабочие места, все это записывается.

• А затем вся документация и все записи совещаний в структурированном виде выкладываются на SharePoint, куда есть доступ и у заказчика, и у подрядчика. Это очень удобно. Допустим, по ходу уже второго этапа у нас сменился один из ключевых директоров, он быстро посмотрел интервью по всем своим блокам и сразу погрузился в контекст. Теперь он полностью понимает все, что обсуждали, кто что говорил, откуда такой протокол.

• Финальная документация у нас тоже формализована в виде протоколов.

Как получить результат в срок и уложиться в бюджет?

Для соблюдения сроков и бюджета важно отметить четыре основных пункта:

• границы проекта;

• ответственные;

• альтернатива;

• и секретный ингредиент.

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

Когда мы разговариваем с заинтересованными лицами, демонстрируем им какую-то функциональность, конечно, появляется соблазн что-то еще добавить, что нам хотелось бы или было бы удобно. Мы это называем nice to have.

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

Второй момент – ответственные. Мы этим активно пользуемся.

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

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

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

Альтернатива. Здесь я подразумеваю некий хозяйский подход к бюджету.

Например, у нас в результате верификации функциональных требований по проекту прилетело 20% к стоимости. Потенциальный подрядчик посмотрел, верифицировал, оценил – говорит: плюс 20%.

Что мы сделали? Мы прошли по реестру с каждым функциональным заказчиком, с каждым потенциальным исполнителем и проговорили, зачем ему задача, проговорили, кто конкретно будет ее принимать из исполнителей. В итоге часть задач просто отвалилась, потому что некоторые решения уже устарели, некоторые – трансформировались.

• Допустим, нам говорили, что нужно 3 отчета, а в итоге мы делаем один, но другой.

• Или, например, у нас был в УПП целый блок по СИЗ, он был полностью написан, и подрядчик предложил его воссоздать в ERP. Но мы для этого блока нашли хорошее решение на 1С, нашли людей, которые имеют опыт его внедрения. И его интеграция вместе с покупкой ПО обошлась дешевле в 2 раза, чем если бы это пришлось написать в ERP.

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

Если подходить к бюджету проекта, как к собственным деньгам, конечно, можно найти больше альтернативных вариантов. Но это – наши реальные кейсы.

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

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

Ты им кидаешь протокол, пункты, решения, сроки. Но никто ничего не делает. Или решения не готовы, или документ не читали и т.д.

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

Работа с рисками

Расскажу про риски, которые связаны для бизнеса с переходом на ERP.

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

Мы подошли к вопросу рисков основательно:

• На первых итерациях проекта мы составили карту, где по цепочке перечислили все бизнес-процессы, которые затрагивает ERP.

• По каждому процессу прописали возможные риски – что будет, если какая-то часть процесса не отработает.

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

  • Или не печатается штрих-код на паллете. Все, мы не можем это оприходовать, это ужас.

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

• По каждому риску оценили критичность на горизонте в неделю.

• Прописали вероятность возникновения риска.

• И предусмотрели меры по снижению риска.

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

  • Если какие-то процессы можно перетащить с первых чисел после перехода, их надо перетаскивать. Мы для себя определили, что можем не оприходовать сырье в январские праздники с 1 по 10 января. Нам бизнес-процесс позволяет закупиться заранее, и этот приход не ставить. Так что хотя бы какие-то риски из этого списка точно не случатся в первые праздники года.

Когда мы так расписываем каждую задачу, кажется, что переход не такой уж и страшный.

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

Такая детальная проработка очень полезна. Не знаю, многие ли ее делают, многие ли про это знают. Ни один подрядчик нам про это не говорил. Это мы сами делаем.

Работа над ошибками

Хочу поделиться с вами своими ошибками. Может быть, кто-то с ними тоже сталкивался.

Нормативно-справочная информация. Работа с нормативно-справочной информации – огромный блок, его нельзя недооценивать. Нормализация НСИ лежит на стороне заказчика. Подрядчик говорит, что перенесет все, что есть. А нам не нужно все: у нас мусора полно, старая номенклатура, и так далее.

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

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

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

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

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

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

• Здесь надо сразу понимать, может ли это быть, допустим, финансовый директор. Может ли он 100% рабочего времени отдать проекту? Большой вопрос.

• Зачастую есть соблазн назначить руководителем проекта специалиста ИТ-службы. Допустим, у нас есть классный программист, который отлично знает программу. Но сможет ли он быть руководителем проекта, если у него нет таких скилов, как договариваться и решать вопросы? Он классный программист, но вести проект, драйвить его, он не сможет. Работа на проекте – это бесконечная работа с людьми. Здесь нужны разные подходы для решения разных вопросов, вам нужно создавать комфортную среду командам и программистам, двигать проект. Это вообще другой навык, тут не нужно программировать. Это совсем другой скил. Такая ошибка может быть для проекта фатальной.

Выбор подрядчика

Коротко расскажу о выборе подрядчика. Мы выбираем подрядчика по двум критериям.

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

И второй критерий – это адекватность коммерческого предложения, заявленная подрядчиком на тендер.

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

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

Поэтому, если у вас стоит задача провести тендер, делайте его на основе предпроектного обследования.

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

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

Проектные технологии – Waterfall или Agile?

Я считаю, что Waterfall хорош для забюрократизированных компаний, у которых все давно устоялось, ничего не меняется.

Для таких компаний как наша, у которых за период поменялась куча руководителей и множество видений, как все должно быть реализовано, Waterfall не подойдет.

Но и Agile в чистом виде нам тоже не подошел.

Когда я пришла на проект, подрядчик работал по ЛУРВ-ам. Было ощущение, что он как самурай – у него нет цели, есть только путь. По проекту что-то делалось, но проектная команда не очень стремилась запуститься.

Только когда мы поменяли с подрядчиком договор на фиксированный, тогда начали идти к запуску с двух сторон.

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

Итоги проекта

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

Хотя в процессе реализации очень часто было ощущение, что мы, может быть, и не запустимся, но все получилось:

• Данные нормализованы.

• Документооборот работает.

• Сократились трудозатраты на поддержание огромного количества систем – в частности, у нас часть работы с нормализацией данных отвалилась.

• Теперь мы можем анализировать аналитику обычными отчетами и не обрабатывать данные через кубы огромными массивами – избавились от хаоса на входе, теперь все четко.

Вопросы

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

Это формальные цифры, которые характеризуют объемы компании. В реальности специалистов с таким сертификатом в компании может быть 4 или 6. Здесь какого-то глубокого анализа или статистики не было. Поэтому решили, пусть их будет 5.

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

Мы в любом случае беседуем с людьми. На мой взгляд, ориентироваться на чутье в этом вопросе – очень правильно. Если вам кажется, что оно не пойдет, то оно не пойдет. Так и с людьми. Если вы понимаете, что с человеком сложно, то вы будете в течение всего проекта об него спотыкаться. Чудес не бывает, к сожалению. Поэтому мы с руководителем проекта должны понравиться друг другу.

Очень понравился слайд про управление рисками. Это какой-то типовой реестр рисков или вы его под конкретный проект сделали?

Мы сделали его с ИТ-директором, чтобы обезопасить себя. Был, конечно, соблазн пошариться в интернете, но мы поняли, что сами классные, и так подготовились к возможным проблемам.

На слайде с рисками было две колонки – вероятность и критичность. Как вы рассчитывали эти критерии, по какой-то методике?

Критичность мы рассчитывали экспертно, смотрели с исполнителями на местах. Я рассказывала, что мы в Teams вызваниваем специалистов по цепочке и со всеми прорабатываем риск того, что этот бизнес-процесс не запустится.

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

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

В итоге мы теперь даже лучше, чем многие руководители понимаем, что делать, если бизнес-процесс вдруг не пойдет – есть ли у нас альтернативные пути. Так что мы по каждому пункту отрабатывали с исполнителями, они нам очень многое рассказали.

И критерий вероятности – тоже экспертная штука.

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

А не было такого, что все риски критичные?

Критерий критичности зависит от влияния на остановку производства.

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

А какой-то бухгалтерский документ с ошибками – это не так критично, потому что есть период закрытия. Такой подход.

Вы сказали, что перешли с подрядчиком на фикс, но при этом работали по спринтам. Как у вас происходило актирование подрядчиков, как добавляли исправление ошибок в бэклог на спринты?

Немного не так. На фикс мы перешли уже тогда, когда оставалось несколько месяцев до запуска. В этот период уже все было понятно – все много раз уже описано, много раз продемонстрировано.

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

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

Это у вас один такой крупный проект или вы уже имели опыт выстраивания процессов внедрения? Можете ли вы посоветовать, с чего начать, чем продолжить, какие основные этапы выделить, чтобы переложить полученный опыт на другие проекты?

Такой проект у меня не один. И мне кажется, что это обычная структура хода проекта – обследование, автоматизация, программирование, тестирование, обучение. Вы это имели в виду?

Вы говорили про выявление рисков – вы же их выявили на каком-то определенном этапе? Может, что-то можно предусмотреть заранее.

Конечно, можно, если опыт уже есть.

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

Все свои кейсы мы сохраняем в документации: и то, что нам присылали подрядчики, и свои какие-то фишки.

Чем больше опыта, тем больше классных штук. Вы их прячете в коробочку, а потом достаете.

И чем хороша конференция – это обменом мнениями, идеями. Можете использовать YouTube-канал Инфостарта как базу знаний.

*************

Статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event.