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