Как заказчику взаимодействовать с 1С-франчайзи и интегратором

Внедрение 1С редко срывается из-за самой платформы. Чаще — из-за того, как заказчик и подрядчик договорились (или не договорились) о совместной работе. Ниже — рабочая рамка: кто за что отвечает, где заказчик действительно необходим, какие ошибки затягивают проект и по каким признакам видно, что пора вмешиваться.

Внедрение — это не покупка программы

Когда автоматизацию воспринимают как покупку софта, а подрядчика — как исполнителя «настроить пару отчётов», проект почти обречён. Формально система запускается, но отчёты продолжают считать в Excel, а сотрудники воспринимают 1С как дополнительную нагрузку к работе.

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

Аналогия с врачом

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

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

Кто за что отвечает

Роль	Сторона	Ответственность
Владелец проекта	заказчик	Цель и границы, приоритеты, решения по спорным вопросам, эскалация, приёмка результата
Владелец процесса	заказчик	Знает, как процесс работает сейчас и как должен работать после внедрения; принимает конкретный контур
Рабочая группа	заказчик	Отвечает на вопросы, тестирует, обучает коллег, вводит и сверяет данные
Руководитель проекта	подрядчик	План, ресурсы, сроки, риски, единая точка входа для заказчика
Архитектор / аналитик	подрядчик	Обследование, модель процессов, требования, границы доработок
Разработчик	подрядчик	Реализация, тесты, передача изменений, документация

Главное в этой таблице — у каждой строки есть имя и фамилия. «Команда заказчика» и «команда подрядчика» без персональной ответственности — это не роли, а способ размыть решение.

Где заказчик обязателен

• Цель и метрика результата. «Оптимизировать учёт» — не цель. Цель — «закрывать месяц за 3 дня вместо 10» или «видеть остатки по складу в реальном времени».
• Приоритеты. Что запускаем первым, что можно отложить. Это решение бизнеса, подрядчик его не примет за вас.
• Доступ к процессам и людям. Интервью, наблюдение за работой, реальные документы, а не пересказ.
• Данные. Ответственный за подготовку и сверку справочников, остатков, истории. Мусор на входе даст мусор в системе.
• Приёмка. По заранее написанным сценариям, а не по факту подписания актов.
• Решения по спорным местам. Если два подразделения хотят разного — решает владелец проекта, а не подрядчик.

Где заказчик мешает

• Диктует технические решения. «Сделайте цикл по регистру в этом месте» — это зона подрядчика; заказчику нужно описать требуемое поведение.
• Требует переписать типовой документ под старую бумажку. Классический способ получить хрупкую систему, которую через год не сможет поддерживать никто.
• Соглашается на всё сразу. «Учтём все исключения, все частные случаи, все исторические привычки» — проект превращается в конструктор, а управляемости не прибавляется.
• Обходит руководителя проекта. Прямые задачи «своему» программисту в обход приоритетов и оценки — способ одновременно сорвать сроки и испортить отношения внутри команды подрядчика.
• Приносит новое требование как «мелочь». Любая доработка имеет стоимость и влияние на сроки. Нормальный процесс — не отказ, а оценка и решение.

Ошибки заказчика, которые тормозят проект

1. Нет сформулированной бизнес-цели. Проект инициирован «потому что надо», сотрудники относятся к нему формально, результат не совпадает с ожиданиями.
2. У внутреннего руководителя проекта нет полномочий. Он не может принять решение и не знает, к кому эскалировать — команда подрядчика стоит в ожидании.
3. Нет регламентов согласования. Вопрос уходит внутрь компании на недели, документ, который аналитики готовили месяцами, ещё месяцы согласуется.
4. Ключевые сотрудники не выделяют время. Проект идёт «между делами»: интервью переносятся, данные не готовы, тестирование некому проводить.
5. Расползание границ. Требования растут по ходу моделирования, бюджет заканчивается, а базовый контур не запущен.
6. Недооценка двойного ввода и сверки. Период параллельной работы требует рук: кто-то должен вносить данные в две системы и сверять расхождения.
7. Экономия на обучении и опытной эксплуатации. Пользователи не понимают систему, продолжают работать по-старому и саботируют запуск.

Красные флаги подрядчика

• «Сделаем всё, как скажете» — без встречных вопросов о процессах и целях.
• «ТЗ не нужно, мы и так всё знаем» или «смета потом».
• Обещание внедрения «за пару месяцев» без обследования и оценки объёма.
• Нет демонстраций: о ходе работ узнаёте из актов, а не из работающих сценариев.
• Смета растёт без оценок и согласований — «так сложилось».
• Нет одного ответственного: на вопрос отвечают четверо, и каждый про своё.
• «Это не наша зона» на стыке двух подсистем.

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

Признаки, что проект в тупике

• Внедрение идёт заметно дольше плана, а бизнес-эффекта нет.
• Система формально запущена, но ключевые операции по-прежнему в Excel и переписках.
• Цифрам в отчётах не верят, их приходится регулярно сверять вручную.
• Никто не может объяснить, почему система устроена именно так.
• Доработки растут, а прозрачности и управляемости не прибавляется.

Если пошло не так: пауза вместо «дожимать»

Самая дорогая ошибка на этом этапе — продолжать вкладываться в то, что не работает. Порядок действий обычно такой:

1. Пауза и аудит. Зафиксировать текущее состояние: что реально работает, что нет, сколько это стоит, где границы.
2. Разбор причин. Не «кто виноват», а «какое решение привело сюда»: цели, требования, данные, коммуникация.
3. Третий вариант. Не «всё с нуля» и не «дожать как есть», а пересборка контура: что запускаем минимально, что переносим, что отменяем.
4. Новая рамка работы. Роли, приоритеты, этапы, приёмка. Иногда менять подрядчика не требуется — требуется изменить способ взаимодействия.

Правила, которые мы применяем

1. Цель = измеримый результат. Не «внедрить 1С», а «закрывать месяц за 3 дня».
2. Один владелец проекта со стороны заказчика — с правом решения и выделенным временем, а не «между делами».
3. Владелец каждого процесса принимает свой контур. Отвечает за результат, а не только за список пожеланий.
4. Обследование до кода. Сначала модель процессов и границы, потом доработки.
5. Любая новая хотелка — через оценку. Change request с влиянием на сроки и стоимость, а не «заодно».
6. Этапность и минимальный работающий контур. Сначала базовый запуск, потом расширение.
7. Данные — отдельный этап. Миграция, очистка и сверка с критериями приёмки, а не «перенесём как-нибудь».
8. Демонстрации каждые 1–2 недели. Показываем работающие сценарии, а не отчёт о количестве часов.
9. Обучение и опытная эксплуатация до полного запуска. Пользователь, который боится системы, вернётся в Excel.
10. Приёмка по сценариям заказчика. Критерии пишем до начала работ, а не после.
11. Версии, бэкапы и регламент обновлений. Обновление — управляемая процедура с окном и откатом.
12. Слепое согласие — красный флаг для обеих сторон. Если подрядчик соглашается со всем, а заказчик не задаёт вопросов — проект уже буксует.

Чек-лист перед стартом

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

Полезно по теме

• Зачем мы ведём блог о 1С — что здесь будет и как устроены материалы.
• Услуги ВЦ «Система» — внедрение, доработка и сопровождение 1С.
• Бесплатный аудит — 30 минут и дорожная карта из 3 шагов.