Команда заказчика: половину внедрения делают ваши люди
На пресейле изучают команду подрядчика. Про вторую команду проекта - вашу собственную - не спрашивает почти никто, а от неё зависит не меньше.
Когда завод выбирает подрядчика на «1С:ERP», он изучает чужую команду: кто придёт, сколько у этих людей проектов за плечами, не подменят ли звёзд с пресейла на студентов после подписания. Вопросы правильные - про эту подмену я писал в статье про выбор подрядчика, там это признак номер один.
Про вторую команду проекта на пресейле не спрашивает почти никто. А она есть на каждом внедрении, и от неё зависит не меньше, чем от подрядчика. Это команда самого заказчика: ваш финансовый директор, ваш главбух, ваши производственники. В бюджете проекта их время обычно не стОит ни рубля, в приказе о старте их нет - и всплывает это уже на моделировании, когда у подрядчика всё готово к работе, а с вашей стороны «всем некогда».
Кто входит в команду
Состав от завода к заводу почти не меняется. Руководитель проекта со стороны предприятия и пять-шесть ключевых специалистов: финансовый директор, главный бухгалтер, руководитель планово-экономического отдела, директор по производству, ИТ-директор. Я перечислял их в статье про стоимость внедрения - там это была строка бюджета. Теперь смотрим на них как на рабочую группу проекта.
Главное слово тут - «ключевые». В рабочей группе должны быть владельцы автоматизируемых процессов: люди, которые вправе сказать «здесь будет так», каждый по своему участку. Главбух может решить про учёт, директор по производству - про планирование. Зам так не может: спорный вопрос он понесёт наверх, подождёт ответа, потом понесёт уточнение. Процесс, у которого в группе нет владельца, виснет - решать по нему некому.
Соблазн отправить в проект замов понятен. Ключевые люди потому и ключевые, что заняты сильнее всех, - и выделить хочется тех, кого не жалко оторвать от работы. Это зеркальная версия болезни подрядчика: у него на проект ставят «кого посвободнее», у вас - «кого не жалко». Кончается одинаково.
Что значит «включить в команду»
Включить человека в команду проекта - это высвободить ему время и решить, кто на эти месяцы заберёт его текучку. Строчка в приказе сама по себе времени не высвобождает.
Сколько времени нужно - от 20% до трети рабочего дня, и так на протяжении большей части проекта. Пик приходится на функциональное моделирование: там владельцы процессов нужны постоянно - рассказывать, как устроен завод, смотреть модель, говорить, что в ней не так. Если на моделировании они появляются раз в две недели на час, вы получите систему по мотивам рассказов их подчинённых. Совпадёт ли она с тем, как предприятие работает на самом деле и как нужно, чтобы оно работало, - лотерея.
Треть времени финдира и главбуха не лежит в их календарях свободным окном. Её приходится отбирать у текучки: часть задач передать замам, часть отложить, где-то согласовать сверхурочные и доплату. По сути, под проект перестраивается работа нескольких подразделений. За неделю такое не делается - поэтому думать об этом надо до подписания договора, а не после старта.
Вариант «пусть участвует в свободное время» не работает по простой причине: свободного времени у главбуха не бывает. Проект в этой схеме получает остатки - и живёт на остатках до первого закрытия периода.
Чем это кончается
Историю я уже рассказывал в статье про стоимость внедрения, но там она была про деньги. Сейчас - про время.
На одном из проектов мы с заказчиком договорились: в ноябре-декабре тестовая эксплуатация, с 1 января предприятие самостоятельно переходит в промышленную. Всё сделали, запустились. Акт подписан, отзыв об удовлетворённости подписан. А в апреле выясняется, что главный бухгалтер ни один месяц нового года так и не закрыл - не разобрался в системе до конца. Три месяца предприятие работало без закрытия периода. Три месяца по минному полю.
Почему главный бухгалтер не разобрался в системе за проект и тестовую эксплуатацию? Моя версия простая: его время под проект никто не высвобождал (и в первую очередь - он сам). Ноябрь и декабрь у главбуха - подготовка к закрытию года, новая система в его календаре шла после всего остального. Протоколы подписаны, а часов, просиженных в системе своими руками, за ними не стояло. Дальше арифметика: чего не вложили до запуска, то доплатили после - тремя месяцами без закрытия.
Я не снимаю ответственность с нас как с подрядчика: дожимать вовлечение заказчика - тоже наша работа. Но у неё есть предел. Высвободить главному бухгалтеру время может только его директор. Подрядчик может об этом просить - распорядиться не может.
Кто что подписывает: матрица
Чтобы вовлечение не держалось на честном слове, в нашей методике под него есть отдельный документ - матрица ответственности и согласования. Составляется на старте проекта, вместе с уставом, и подписывается заказчиком. Внутри - фамилии: кто согласует функциональную модель по каждому блоку, кто принимает тестирование, кто подписывает протоколы, кто решает спорные вопросы.
Документ на вид скучный. Работает он в двух местах. Первое: в середине проекта не бывает разговора «а кто у вас принимает вот это» - вопрос закрыт до старта. Второе, и это полезнее: матрица вскрывает дыры заранее. Если в строку «согласует модель по производству» некого вписать, у производственного контура нет владельца. Лучше узнать об этом в начале договора, чем посреди моделирования.
Выше рабочей группы в этой конструкции два уровня: руководители проекта с обеих сторон и кураторы. Куратор со стороны заказчика - топ-менеджер или собственник, чья власть накрывает все подразделения, которые цепляет проект. Он держит приоритет проекта и разбирает споры, не решившиеся ниже. Кого привлекать руководителем проекта, каких людей искать на эту роль и почему ИТ-директор в ней срабатывает редко - отдельный большой разговор, в книге под него отведена целая глава. Здесь зафиксирую минимум: РП со стороны заказчика нужен, и это роль со временем и полномочиями, а не почётная нагрузка к основной должности.
Что сделать до подписания договора
Сведу в короткий список - он же повестка на одно совещание с будущим руководителем проекта.
- Выпишите процессы, которые попадают в проект, и рядом - владельца каждого. Пустые клетки в этом списке разберите до старта: это главный риск проекта.
- Назначьте руководителя проекта и честно ответьте себе, есть ли у него время и вес на предприятии. Если РП выбран по принципу «посвободнее» - перечитайте абзац про замов.
- Посчитайте время команды в деньгах и внесите в бюджет проекта. Ориентир: 20% - треть времени пяти-шести человек на протяжении большей части проекта; в статье про стоимость я оценивал эту строку в 4-6 миллионов для среднего завода. Цифра в бюджете дисциплинирует лучше любых слов.
- Под каждого ключевого решите, кто заберёт его текучку. Без этого пункт 3 останется декларацией.
- Попросите у подрядчика матрицу ответственности и подпишите её до старта. Если такого документа у него нет - это тоже информация о подрядчике.
И один вопрос себе, самый неприятный. Готов ли я к тому, что мои лучшие люди на год погрузятся в проект, а их подразделения поживут на замах? Если ответ «нет» - честнее отложить внедрение, чем стартовать с командой из тех, кого не жалко. Проект на людях по остаточному принципу стоит тех же денег, что нормальный. Результат - другой.
Подрядчика на проекте можно заменить: неприятно, дорого, но лечится. Команду заказчика заменить не на кого - других владельцев ваших процессов не существует. Система после запуска останется у вас, и работать в ней будут те самые люди из списка. Сколько их времени вы вложите до запуска, настолько она и станет вашей.