Требования к внедрению 1С: от интервью с заказчиком до приёмки

Требования клиента к автоматизации в 1С описывают через процессы и проверяемые результаты, а не через пожелания. Каждое требование отвечает на четыре вопроса: кто делает, что делает, на каких данных и как проверить, что сделано. Формулировка «нужен удобный учёт склада» в ТЗ не годится. Годится такая: «кладовщик проводит приёмку по штрихкоду ТСД, расхождение с заказом больше 2% блокирует проведение до решения закупщика».

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

Обследование: как собрать бизнес-процессы заказчика

Начинают не с 1С, а с работы людей. Задача обследования — понять, как деньги, товар и документы движутся в компании сейчас.

С кем разговаривать

• 👤 Владелец или директор — цели автоматизации и бюджет. Без него не понять, что важнее: скорость отгрузки или точная себестоимость.
• 🧾 Главный бухгалтер — учётная политика, налоговый режим, отчётность.
• 📦 Руководители подразделений — закупка, склад, продажи, производство, кадры.
• ⌨️ Рядовые исполнители — те, кто будет вводить документы. Только они знают про «вот этот файлик в Excel, который мы ведём параллельно».

Что собирать на встречах

1. Схему процесса «как есть»: кто начинает, какие документы появляются, где согласования.
2. Образцы всех бумаг и файлов: счета, накладные, внутренние таблицы, отчёты руководству.
3. Объёмы: сколько документов в день, сколько позиций номенклатуры, сколько складов и юрлиц.
4. Узкие места: где теряется время, где ошибаются, что пересчитывают вручную.
5. Внешние участники: банк, маркетплейсы, сайт, операторы ЭДО, транспортные компании.

Объёмы — не формальность. Компания с 50 документами в день и компания с 5 000 документами в день — это разные решения: файловая или клиент-серверная база , нужны ли регламентные задания, как настраивать блокировки.

Как перевести пожелания заказчика в проверяемые требования

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

Шаблон формулировки

Каждое требование записывают в одном формате. Удобно вести реестр в таблице:

Поле «Как проверить» — главное. Если для требования нельзя придумать проверку, требования нет, есть пожелание.

Слова-ловушки

Эти слова в ТЗ всегда заменяют числами или правилами:

• ❌ «удобно», «быстро», «наглядно» → ✅ «отчёт формируется не дольше 10 секунд за месяц по одному складу»;
• ❌ «автоматически» → ✅ «регламентное задание каждую ночь в 02:00 загружает курсы валют»;
• ❌ «контролировать остатки» → ✅ «запрет отрицательных остатков по складам “Основной” и “Розница”»;
• ❌ «как в старой программе» → ✅ описание конкретного поведения с примером.

Типовая конфигурация и отраслевые решения: что брать из коробки

Ошибка большинства ТЗ — их пишут так, будто 1С создаётся с нуля. На деле сначала выбирают типовую или отраслевую конфигурацию, а потом описывают только разрывы.

Fit-gap анализ

Приём простой: каждое требование из реестра проверяют на демобазе выбранной конфигурации и ставят одну из отметок.

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

Как выбрать основу

• 🏢 Бухгалтерия и налоги для небольшой компании — 1С:Бухгалтерия предприятия.
• 🛒 Оптовая торговля, склад, закупки — 1С:Управление торговлей.
• 👥 Зарплата и кадры — 1С:Зарплата и управление персоналом.
• 🏭 Производство и сквозной учёт нескольких направлений — 1С:ERP или 1С:Комплексная автоматизация.
• 🧩 Узкая отрасль (общепит, медицина, строительство, аптеки) — отраслевое решение партнёров на базе типовых.

Роли пользователей и права доступа в ТЗ на 1С

Раздел про права часто пишут одной строкой «настроить права пользователям». Потом на приёмке выясняется, что менеджер видит чужих клиентов, а кладовщик может менять цены.

Что описать

1. Список ролей — не людей, а должностей: менеджер, кладовщик, бухгалтер по зарплате, руководитель отдела.
2. Матрицу «роль → объект → действие»: чтение, создание, изменение, проведение, удаление.
3. Ограничения по данным: менеджер видит только своих контрагентов, бухгалтер — только свою организацию, кладовщик — только свой склад.
4. Запреты по датам: закрытый период не редактируется после сдачи отчётности.
5. Кто администрирует права после запуска: ИТ-отдел или подрядчик.

Пример матрицы для торговли:

В типовых конфигурациях права раздают через группы доступа и профили. Ограничение «только свои записи» реализуется ограничением доступа на уровне записей (RLS). Оно влияет на скорость работы, поэтому в ТЗ укажите, где оно действительно нужно, а где хватит запрета на уровне объекта.

Перенос данных и интеграции: что зафиксировать заранее

Это раздел, на котором срываются сроки. Требование «перенести данные из старой системы» без деталей означает неделю споров после запуска.

Миграция данных

Для каждого объекта переноса укажите:

• 📁 источник — старая 1С (какая конфигурация и версия), другая программа, Excel;
• 📅 глубину — только остатки на дату начала или документы за период;
• 🧹 правила очистки — дубли контрагентов, неактивная номенклатура, закрытые договоры;
• ✅ способ сверки — какие отчёты в старой и новой системе должны совпасть.

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

Интеграции

Каждую внешнюю систему описывают отдельной карточкой:

Строка «ведущая система» снимает половину будущих конфликтов. Если контрагента можно править и в 1С, и в CRM, через месяц данные разойдутся. В ТЗ сразу пишут, где справочник создаётся, а где только читается.

Отдельно перечислите типовые обмены: банк, ЭДО, маркетплейсы, ЕГАИС или Честный знак, если они есть у заказчика. Часть из них подключается настройкой, без доработок, и это тоже стоит отметить.

Критерии приёмки: когда внедрение считается успешным

Приёмка без критериев превращается в бесконечный список «а ещё сделайте». Критерии согласуют до начала работ и подписывают вместе с ТЗ.

Из чего состоят критерии

1. Тестовые сценарии — по одному на каждое обязательное требование. Сценарий берут из поля «Как проверить» реестра.
2. Сверка данных — остатки по счетам, складам и взаиморасчётам совпадают со старой системой на дату переноса.
3. Показатели работы — время проведения типовых документов и формирования ключевых отчётов при реальном объёме данных.
4. Опытная эксплуатация — срок, обычно 2–4 недели, в течение которого исправляются ошибки без новых требований.
5. Обучение — сколько пользователей и по каким ролям обучены, есть ли инструкции.

Пример тестового сценария

Новые пожелания, которые появились в опытной эксплуатации, оформляют отдельным запросом на изменение с оценкой. Так проект закрывается, а развитие идёт следующим этапом.

Из каких разделов состоит готовое ТЗ

Когда реестр требований собран и прошёл fit-gap, его оформляют в документ. Рабочая структура для коммерческого внедрения 1С выглядит так:

1. Цели и границы проекта — что автоматизируем, что точно нет. Строка «вне рамок проекта» защищает обе стороны.
2. Используемая конфигурация — название, редакция, вариант поставки, количество пользователей.
3. Учётная политика и нормативно-справочная информация — организации, склады, виды цен, статьи затрат.
4. Описание процессов «как должно быть» — по каждому процессу схема и связанные требования из реестра.
5. Доработки — только разрывы из fit-gap, с постановкой для программиста.
6. Права доступа — матрица ролей.
7. Перенос данных и интеграции — карточки объектов и обменов.
8. Критерии приёмки и план опытной эксплуатации.

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

Ошибки при составлении технического задания на 1С

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

• 🚫 ТЗ пишет только исполнитель. Заказчик подписывает, не читая, а на приёмке выясняется, что ожидал другого. Ключевые пользователи должны вычитать свои разделы.
• 🚫 Описание интерфейса вместо логики. «Кнопка справа сверху, зелёная» — это не требование к учёту. Сначала правила и данные, внешний вид потом.
• 🚫 Все требования «обязательные». Без приоритетов бюджет уходит на мелочи. Разделите на «без этого не запускаемся» и «доделаем вторым этапом».
• 🚫 Нет учётной политики. Метод оценки запасов, распределение косвенных расходов, налоговый режим — без них нельзя настроить даже типовую.
• 🚫 Копирование старой программы один в один. Процессы, сложившиеся из-за ограничений прежней системы, переносят в новую вместе с костылями.
• 🚫 Нет владельца решений. Когда отдел продаж и бухгалтерия спорят, кто-то со стороны заказчика должен иметь право сказать окончательно.

Частые вопросы