«Сужая границы»: как внедрить 1С дешевле и быстрее

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

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

Подход «всё и сразу»

Почему компании вообще приходят к необходимости менять учётную систему? Причины могут быть разными, но их объединяет одно: работать по-старому больше нельзя.

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

Есть и внешние причины. Например, переход с УПП на ERP становится неизбежным: поддержка УПП заканчивается в 2026 году, из-за чего компании больше не смогут передавать регламентированную отчётность.

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

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

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

В результате рождается документ с требованиями:

• Автоматизировать все виды учёта: регламентированный, зарплатный, управленческий, оперативный, производственный.

• Интегрировать, всё, чем сейчас пользуемся отдельно: CRM, интернет-магазин, маркетплейсы, сервисы документооборота.

• Сохранить всю удобную часть текущего функционала – «нам это нравится, хотим оставить».

• Добавить то, чего в компании даже не было – например, казначейство или бюджетирование, «раз уж в ERP есть такой функционал».

Логика понятная и на первый взгляд даже здравая. Ведь идея автоматизации – это единое информационное пространство. Хочется сделать всё сразу и идеально.

На практике всё иначе. Компания отправляет свой список пожеланий потенциальному подрядчику – и получает оценку:

• Заказчик выделил бюджет, а оценку получил в 3–5, а то и 10 раз выше.

• Хотелось бы уложиться в 6 месяцев, а в ответ пишут про 2 года.

В итоге заказчик оказывается в тупике. Проект объективно нужен, и откладывать его нельзя. Но бюджет кажется неподъёмным, а сроки неприемлемыми.

Почему это происходит

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

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

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

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

Поэтому он закладывает все эти риски в стоимость: требования в ходе проекта будут уточняться, меняться, что-то придётся переделывать. А на это нужны деньги и время. В результате получается долгий, дорогой и рискованный проект. Слишком дорогой и слишком долгий для заказчика. Оцененный потенциальными подрядчиками по принципу «если мы в этот проект зайдем, хотя бы не в убыток сработать».

Что делать? Сужаем границы через MVP-подход

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

Эта идея давно известна в разработке цифровых продуктов – так называемый MVP (Minimum Viable Product) – минимально жизнеспособный продукт. В стартапах это базовый принцип: выпустить не всё и сразу, а ровно столько, чтобы начать работать, проверить гипотезы и начать получать пользу.

Нужно задать себе (или обсудить с подрядчиком) главный вопрос: какой минимальный функционал нам нужен, чтобы начать работать не хуже, чем сейчас? Это ключевой фильтр. Всё, что не критично – откладываем на потом.

Принципы отбора для MVP:

• Если чего-то в компании сейчас нет – например, автоматизированного планирования закупок или интеграции с CRM – не добавляем это в проект. Пусть и дальше работает «вручную».

• Если что-то уже автоматизировано в другой системе – оставляем там. Например, если оперативный, управленческий, производственный и регламентированный учёт ведутся в УПП – переносим только регламентированный (потому что он перестанет поддерживаться в этой конфигурации), а остальное пока оставляем в УПП.

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

Варианты MVP для 1С-проекта (как на практике реализовать MVP-подход):

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

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

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

Только типовой функционал. Договариваемся с подрядчиком: внедрять только то, что уже есть в типовом решении (например, в ERP, КА, УТ и т.д.) + добавляем минимальные доработки. Выбираем конфигурацию, которая наиболее полно покрывает бизнес-процессы компании. Определяем минимальные доработки: заранее обсуждаем, какие из них действительно критичны – и оставляем всё остальное за пределами проекта.

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

Именно эту стратегию мы рекомендуем обсуждать с подрядчиком. 

Почему подход MVP выгоден бизнесу

На встречах с клиентами, после предложения использовать MVP-подход, можно услышать резонный вопрос: «Ну хорошо. Но ведь общий бюджет всё равно останется таким же? Мы просто потратим 5 миллионов сейчас, а 15 – через год. Что от этого меняется?».

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

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

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

2. Развивать систему на работающей базе проще и дешевле. Дорабатывать уже запущенную и протестированную систему проще и надёжнее, чем пытаться спроектировать идеальную систему с нуля и целиком.

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

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

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

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

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

• Сделано то, что действительно нужно бизнесу.

• Не реализовано то, чем компания не будет пользоваться.

• Система соответствует реальным процессам.

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

1. Вы определяете минимум функционала, без которого бизнес не сможет работать.

2. Находите подрядчика и внедряете первую очередь MVP проекта.

3. Получаете быструю отдачу, начинаете работать в новой системе.

4. А потом развиваете систему так, как действительно нужно вашему бизнесу.

Что в итоге

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

И если вы сейчас занимаетесь планированием внедрения 1С – не бойтесь задать себе главный вопрос:

«Что действительно нельзя оставить без автоматизации?»

А всё остальное оставьте на потом. Именно этот фильтр позволяет сделать проект не только дешевле и быстрее – но полезнее для бизнеса.

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