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

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

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

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

1. Бюджет считают по красивой формуле, которая в реальности не работает

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

Почему? Потому что у разных ролей – разная трудоемкость. Где-то на проработку, обучение и настройку уйдет в три раза больше времени, чем казалось в начале. Где-то, наоборот, меньше. А еще такая формула обычно вообще не учитывает разработку, а сегодня именно она часто становится одной из самых заметных статей расходов.

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

Если заказчик пытается оценить проект самостоятельно именно таким способом, безопаснее сразу смотреть на цифру трезво: в реальной жизни ее нередко приходится умножать как минимум на два. Это не попытка «раздуть» смету, а способ заранее увидеть масштаб задачи без лишних иллюзий.

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

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

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

Когда внутри компании не согласован MVP – минимально жизнеспособный результат, – в проект начинают складывать вообще все. И нужное. И полезное. И просто желаемое. Кто-то хочет сохранить старый отчет. Кто-то просит сразу добавить новую аналитику. Кто-то говорит: «Раз уж внедряем, давайте еще вот это автоматизируем». На этом этапе границы проекта становятся размытыми почти незаметно. Всем кажется, что каждая отдельная просьба разумна. Но в сумме проект начинает пухнуть, сроки растягиваются, бюджет – тоже.

Иногда в этом месте и подрядчик идет по опасному пути: чтобы не спорить с клиентом, начинает принимать все запросы. Формально это может выглядеть корректно – «да, сделаем, но за отдельный бюджет». Но для бизнеса итог один: стоимость проекта растет, а управляемость падает.

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

Все, что нужно для запуска и получения первого результата, должно идти в ядро проекта. Все остальное – в бэклог и в постпроектное развитие. Это не про «урезать мечты». Это про взрослый подход: сначала запустить то, что нужно бизнесу сейчас, а потом спокойно улучшать систему дальше. Тем более что доработки после запуска часто обходятся дешевле: стоимость часа на сопровождении обычно ниже, чем в проектной фазе.

3. Требования меняются по ходу проекта – и это нормально. Ненормально, когда ими никто не управляет

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

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

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

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

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

4. Новую систему пытаются переделать под логику старой

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

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

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

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

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

5. Справочники и данные оставляют «на потом», а потом именно они и взрывают проект

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

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

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

Именно поэтому управление НСИ нельзя оставлять бесхозным. Внутри компании должны быть понятные правила: кто имеет право создавать новую номенклатуру, кто отвечает за справочники, кто может их менять, а кто – только подавать заявку. Если доступ к этому есть у всех подряд, порядка не будет никогда.

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

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

6. Изменений по-настоящему хочет не руководство, а только команда «снизу»

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

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

Пока все идет относительно гладко, проблема не так заметна. Но как только появляются сложности – а они появляются на любом живом проекте, – слабая вовлеченность руководства становится очень заметной. Начинаются сомнения, раздражение, попытки дистанцироваться. Иногда даже звучит знакомое многим: «Ну, мы так и думали, что это все будет тяжело. Может, вообще зря начали».

Для проекта это опасный момент.

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

7. Проект слишком торопят и пытаются запуститься любой ценой

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

На практике это работает наоборот.

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

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

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

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

Как команда Проектного офиса Инфостарт помогает не допускать таких сценариев

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

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

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

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

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

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

В итоге

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

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

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