Как внедрение "квадрата требований" спасло проект интеграции 1С:ERP и внешнего WMS
1. Контекст: "Ад" из 300 накладных и ручных правок
Два года назад я пришел в крупный дистрибуторский центр. Картина была типичной для многих: бухгалтерия на 1С:Бухгалтерии 3.0, склад на старой самописной WMS, а менеджеры вели заказы в Excel+CRM. Данные синхронизировались через "кривые" выгрузки по FTP.
Цифры для масштаба трагедии:
-
300+ накладных в день оформлялись дважды.
-
40% ошибок — из-за расхождения остатков.
-
Среднее время закрытия месяца — 14 дней.
Задача проекта: внедрить 1С:ERP и интеграцию с новой WMS за 8 месяцев.
2. Ошибка №1: "Слепое" управление по плану
Сначала я действовал как классический PM: составил диаграмму Ганта, назначил ответственных и начал "давить" на команду 1С-разработчиков (3 человека) и аналитика. Через месяц мы сорвали первый спринт.
Почему: План был красив, но требования от бизнеса менялись каждый день. Коммерческий директор требовал "отчет по валовой прибыли по каждой ячейке", а логист — "учитывать серийные номера на приемке".
Что я изменил: Ввел еженедельные сессии "Замораживания требований" каждую среду. С понедельника по вторник — сбор требований через форму в Битрикс24. В среду в 10:00 — комитет с заказчиками. То, что не утверждено до 12:00, переносится на следующую неделю. Это снизило поток "хотелок" на 70%.
3. Инструмент, который спас: "Квадрат требований"
Для каждой задачи (даже маленькой) мы завели чек-лист из 4 вопросов. Это наш "Квадрат требований":
-
Бизнес-ценность (цифра: "сократит ручной ввод на 2 часа в день").
-
Юридическая чистота (не нарушает ли 54-ФЗ, ФСБУ и т.д.).
-
Техническая реализуемость (оценка архитектора 1С: срок, ресурсы).
-
UX-простота (может ли кладовщик с 2 классами образования выполнить за 3 клика).
Пример из практики: Пришла задача "сделать динамическую подсветку ячеек при сборке". Бизнес-ценность — высокая, но UX-простота провалилась — тестовый кладовщик не понял логику цветов. Мы отложили задачу на 2 недели, упростили до "зеленый — бери, красный — не бери".
4. Управление командой через "Безопасный диалог"
В проекте был кризис: разработчик 1С (Алексей) перестал комментировать код и начал срывать сроки. Стандартные "летучки" не помогали.
Я применил технику "Безопасный диалог" (из раздела "Управление командой" на Infostart):
-
Вместо публичного разбора — встреча 1-на-1 в нейтральной кофейне.
-
Вопросы без обвинений: "Что в текущем процессе мешает тебе комментировать код?"
-
Результат: оказалось, он "задолбался" править базу каждый вечер из-за кривого мержа. Ввели правило "каждый пулл-реквест проверяют два человека" — и конфликты ушли.
Главный урок: технические проблемы почти всегда маскируются под человеческие.
5. Как мы "взрывали" инциденты (и сократили их в 2 раза)
К моменту запуска (6-й месяц) в боевой базе 1С:ERP было 120 критических ошибок. Обычный подход "чиним по приоритету" не работал — бизнес стонал.
Мы применили метод "5 почему" для ТОП-10 инцидентов:
| Инцидент | Почему? | Коренная причина |
|---|---|---|
| Дубль заказа в ERP | Плохая фильтрация в интеграции | Нет схемы "источник истины" |
| Падение обмена каждую ночь | Переполнение очереди | Нет мониторинга размера очереди |
Исправили 10 коренных причин — исчезли 80% инцидентов.
6. Результаты (цифры и эмоции)
Через 8 месяцев мы сдали проект с задержкой всего на 3 недели (в ИТ это успех). Цифры:
-
Инцидентов на складе: с 40 до 5 в неделю.
-
Закрытие месяца: с 14 до 3 дней.
-
Команда: 0 увольнений за полгода после запуска.
Самый ценный отзыв — от кладовщика дяди Васи: "Раньше я на 1С ругался, а теперь она мне зарплату не портит".
7. Что я вынес в "базу знаний" (вам в копилку)
-
Управление проектом в 1С не про "как сделать отчет", а про то, почему его перестанут открывать через неделю.
-
Аналитика — это мост между матом логиста и молчанием разработчика. Ваша задача — перевести эмоции в требования.
-
Главный риск в ИТ — не сгоревший сервер, а сгоревший сотрудник. Инвестируйте в "безопасные диалоги".
-
Для сложной интеграции обязателен артефакт "Словарь данных" (как поле "Номер заказа" маппится из CRM → 1С → WMS).
Вместо заключения: Зачем я пишу это на Infostart
Потому что на форумах 1С часто спрашивают "как запрограммировать", но почти не учат как не провалить проект. А разделы "Анализ & Управление" (ссылка на sc2) как раз про это. Каждая моя следующая статья будет про конкретный инструмент: "Чек-лист аудита интеграции", "Как за hour снять боль бизнеса", "Антикризисная коммуникация в проекте".
P.S. Если у вас есть вопросы по этой статье или хотите шаблоны документов ("Квадрат требований", "Протокол безопасного диалога") — пишите в комментариях. Я выложу их в Базу знаний через неделю, если наберется 50+ плюсов.
