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