Вы – Заказчик и хотите внедрять 1С:ERP у себя в компании

Меня зовут Екатерина Линцова, я руковожу проектами автоматизации бизнеса на стороне заказчика. Сегодня я поделюсь своим опытом:

• в чем заключается работа руководителя проекта от заказчика;

• как выбрать подрядчика;

• как подготовиться к проекту внутри компании;

• и как минимизировать риски при запуске проекта.

За последние пару лет я запустила два завода и торговый дом в компании Cersanit.

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

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

• ЗУП;

• WMS;

• 1С:Документооборот с бесшовной интеграцией – это требование бизнеса;

• контур МСФО на БИТ.Финансе;

• и база данных для кубов и BI.

Так как проект большой, мы реализовывали его в несколько этапов:

• первым у нас запустился торговый дом;

• далее – две площадки;

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

Основные шаги перехода на новое ПО

Как компания в целом представляет себе запуск нового ПО:

• Назначить руководителя проекта – лучше всего, выбрать кого-нибудь подходящего из штата.

• Определиться с целями проекта – хорошо, если мы с самого начала понимаем, зачем нам это.

• Выбрать подрядчика.

• Выбрать само ПО.

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

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

Кто такой РПЗ и что его ждет

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

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

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

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

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

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

Также РПЗ должен:

• Контролировать сроки – здесь не буду отдельно останавливаться.

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

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

Из перечня функциональности вытекают требования.

• Этот человек должен выделять на проект от 70 до 100 процентов своего рабочего времени.

• Знание продукта – позволит более компетентно консультировать ваших же специалистов и иметь при общении с подрядчиком какие-то аргументы.

• Знание технологий внедрения – помогает держать руку на пульсе и контролировать подрядчика.

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

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

• И РПЗ должен быть модератором-переговорщиком, потому что возникает множество конфликтных ситуаций, и вы должны уметь взаимодействовать с различными людьми.

Я считаю, что человека с компетенцией РПЗ нужно либо вдумчиво растить внутри компании, либо покупать на рынке. Просто так назначить руководителем проекта какого-нибудь ИТ директора неразумно – спорный вопрос, обладает ли он нужными компетенциями, есть ли у него все эти скилы. Или он только продукт знает.

А там, где тонко – там и рвется. Хорошо, если РПЗ поддержит команда подрядчика. А если нет, в любом из этих пунктов будут проблемы.

Как выбрать подрядчика. На что обратить внимание

Перейдем к выбору подрядчика.

Когда мы запускали производственную площадку, был соблазн запускаться собственными силами:

• во-первых, это способ сэкономить бюджет;

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

Но на другой чаше весов отразились риски:

• если один из членов команды выбывает, весь проект оказывается под угрозой – у нас нет такого штата, чтобы людей менять;

• непонятно, кто будет поддерживать текущую работу, на ком будет оперативка – и то и то совмещать невозможно;

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

Если вы в 1С неофиты и, например, переходите с SAP в 1С как в незнакомую среду, то хороший кейс – это посмотреть на «1С:Проекте года» релевантные профильные проекты по подходящим вам критериям и обратить внимание, кто их делал. Собрать такой пул, собственно, подрядчиков, к которому вы бы хотели там обратиться.

Когда мы запускали производственную площадку, мы начали с предпроектного обследования (ППО).

Я знаю, что многие франчайзи скептически относятся к тендерам после ППО. Они считают, что тот, кто ППО делает, тот и будет внедрять. Тендер – формальность.

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

Покажу, как выбирали.

Изначально было 10 компаний. Я сформировала опросный лист – это тоже задача РПЗ.

Если обобщить критерии, то это:

• чистота юридического лица;

• наличие в штате компании сертифицированных сотрудников;

• наличие релевантного опыта;

• стоимость и срок, в которые подрядчик готов реализовать проект по нашим требованиям;

• и готовность принять в договор те требования, о которых я позже скажу.

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

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

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

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

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

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

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

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

• Часть вознаграждения (10-20%, как сторгуемся) по каждому акту мы переносим на запуск. Тем самым мы мотивируем подрядчика именно запуститься.

• Прописываем в договоре состав проектной команды с ФИО и штраф за замену – об этом уже сказала,

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

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

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

Как подготовиться к проекту внутри компании

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

Он классно отображает идею, что запуск нового ПО потребует времени сотрудников компании.

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

Задача РПЗ – зная, на каких этапах какое количество людей потребуется, заранее доносить эту информацию до руководителей подразделений и бронировать время людей, чтобы процесс запуска и работы по ERP не был вторичным, по остаточному принципу.

Мы должны планировать также время команды на стороне заказчика.

Обучение команды.

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

• обучаем пользователей на курсах 1С;

• приглашаем специалистов, которым мы можем задать вопрос;

• делаем тестовые примеры сами.

Это обучение готовит команду к переходу, и они привыкают к новой системе.

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

Это – задача РПЗ.

На слайде перечислила некоторые инструменты контроля за ходом проекта, сюда входит:

• План-график

• Статус отчет по спискам доработок

• Управляющий комитет

• Контроль поручений и открытых вопросов

• Проектная библиотека

Какие риски есть по ходу выполнения проекта и как с ними работать

Когда мы говорим про риски, то каждый участник проекта риски видит по-своему.

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

• Топ-менеджмент видит риск в том, что запуск «уронит» ему бизнес: мы потеряем аналитику, продажи, отчетность либо еще что-то. Он хочет видеть какой-то инструмент, который поможет ему контролировать, что ничего фатального не происходит.

• Задача РПЗ – соблюдать основные договоренности, чтобы помочь подрядчику удержаться в рамках. И подготовить некий план Б, который поможет при запуске, когда у команды максимальный стресс и максимальная нагрузка. У компании и исполнителей должна быть четкая инструкция: что мы делаем, куда мы бежим, кому мы пишем, и на что мы, в общем-то, имеем право.

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

Мы составили свою карту рисков:

• проранжировали все риски на предмет критичности и вероятности того, что они могут случиться;

• подготовили план действий;

• назначили ответственных по каждому плану;

• и все это согласовали на всех уровнях.

Хочу сказать, что часть рисков у нас действительно случилась, но это не стало стрессом:

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

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

Как подстраховаться при запуске

На слайде я привожу схему, как я организовала сквозное тестирование сценариев по каждой производственной площадке.

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

Мы обучаем команду тимлидов – они проходят по этим сценариям, а потом обучают свои команды, и нам не нужно поддерживать там всех этих специалистов.

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

Итоги запуска проекта

Финализируя итоги запуска проекта – мы смогли запустить успешный проект.

Критерии успешности – это:

• мы попали в бюджет;

• мы сделали проект в срок;

• и, самое главное, мы оправдали ожидания.

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

Задача РПЗ – доносить, что это не так. А это в большой вероятности не так, потому что у нас есть генеральная политика партии, какую задачу мы решаем. И многие задачи, которые возникают фоном, мы на первом этапе не реализуем.

По факту компания переживает в ходе внедрения все стадии горя: отрицание, гнев, торг, депрессия и принятие в конце.

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

Вопросы

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

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

Народ сопротивлялся, хотел, жаждал, говорил: «Зачем же нам это все?» Запустились как есть, и сейчас уже год допиливаем и развиваем систему. Те процессы, которые не были автоматизированы ранее или требовали изменения, мы реализуем уже на готовой системе. Например, внедряем качество, блок учета ремонтов и т.д.

При переходе с УПП на ERP вы вели учет параллельно или это был резкий переход?

Резкий переход, прямо по живому.

Когда переводили торговый дом, было очень сложно, потому что у нас непрерывные отгрузки, крупные поставщики типа Леруа, штрафы за недопоставку. И у нас не все гладко пошло.

Но по основным критериям – отгрузки не остановлены, и все в срок – у нас все получилось.

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

Так же и с производственными площадками – сразу всем караваном перешли.

Вы упомянули в качестве одного из факторов успешного перехода наличие собственной экспертизы – у вас это формулировалось как «Знает продукт». Насколько велико влияние этого фактора? Без собственных специалистов мы обречены на провал или будем мучиться, надеяться на подрядчика, но все-таки получится?

Здесь нет однозначного ответа. Конечно, все будет очень сильно зависеть и от подрядчика, и от уровня зрелости команды заказчика, и от РПЗ, в том числе.

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

Я так понял, у вас до этого ERP уже была, и какой-то опыт в ней был?

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

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

Аналитики были?

Не было.

Как вы как руководитель проекта решали проблему, когда при переходе из УПП на ERP увеличивалось количество операций, которые необходимо выполнить пользователю для выполнения той или иной хозоперации? Были ли у вас такие проблемы? Как вы решали этот вопрос?

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

Пользователь заявляет, что раньше он это делал быстрее, и показывает, что на УПП это делается в один клик, на ERP в пять кликов.

Здесь нужно понимать, с кем мы разговариваем и какими аргументами.

Люди обычно просто хотят внимания и побухтеть – это наша новая реальность.

Поступайте в зависимости от персоналий: кого-то просто послушать надо, посочувствовать; кому-то сказать: «Это же теперь ваш новый скил вам в резюме, вы теперь будете знать ERP»

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

Как вы мотивируете? Есть ли какая-то особая мотивация внутренних руководителей проекта заказчика?

Никакой особой мотивации нет.

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

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

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

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

Мы понимаем, что люди в целом хотят, но они заняты, им неохота, некогда. Поэтому входим в их положение и помогаем.

Вы в какой момент переходили? Это были новогодние каникулы? Вот вы перенесли все, а потом год вы как закрывали? В какой программе? В УПП или уже в ERP? Или потом корректировали остатки?

Корректировали, да. В новогодние каникулы перешли. У нас основное было требование, чтобы склады перешли целиком. А взаиморасчеты еще раз перегружали, пока они не были вычищены, скажем так.

То есть год они сдали из УПП?

Да, год сдали из УПП. У нас требование собственника – отчетность должна быть сдана к 10-му числу следующего месяца. Мы полностью должны закрыть период, и его не корректировать. Финансовый результат получить и сформировать пакет отчетности.

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

У вас общий режим налогообложения?

Да.

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

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

Мы не с нуля начинали, а уточняли – встречались с новым подрядчиком, уже имея фактуру.

А с предыдущим подрядчиком мы заключали договор, точнее, доп. соглашение, просто на ППО. Мы с ними запускали торговый дом и хорошо их знаем. Это не какие-то совсем посторонние люди, мы знаем, что люди хорошо работают, качественно.

Получается, что каких-то пунктов или универсальных секретов нет?

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

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

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

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