Обычное тестирование внедрения проверяет, что система работает: документы проводятся, отчёты формируются, права разграничены. Для планирования этого мало. Настроенный прогноз может работать безупречно технически и при этом давать цифры хуже, чем интуиция планировщика. Поэтому к функциональной проверке добавляется валидация — оценка того, насколько результат расчёта соответствует реальности.
Два разных вида проверки
| Тестирование | Валидация | |
|---|---|---|
| Вопрос | Работает ли как задумано | Даёт ли осмысленный результат |
| Данные | Тестовые или реальные | Только реальные исторические |
| Критерий | Соответствие требованиям | Точность относительно факта |
| Кто выполняет | Проектная команда | Планировщик и руководитель направления |
Пропуск валидации — самая частая причина того, что после запуска планировщик продолжает вести параллельный файл: он не доверяет расчёту, и оснований доверять ему никто не дал.
Функциональное тестирование: что проверять
- Расчёт по каждому методу прогноза на контрольном наборе позиций с проверяемым вручную результатом.
- Расчёт потребности с учётом остатков, заказов в пути, резервов, минимальных партий и кратности.
- Проверка загрузки мощностей для производственного контура.
- Трансляция в бюджет и корректность сценариев.
- Маршрут согласования — все переходы статусов, включая отклонение и возврат.
- Права по срезам — под учётной записью каждой роли, а не администратора.
- Блокировка утверждённой версии — попытка изменить должна быть отклонена.
- Регламентные задания — запуск по расписанию и поведение при сбое.
- Обмены — полнота загрузки, повторная загрузка без дублирования.
- Отчётность — сходимость показателей с первичными данными.
Валидация на исторических данных
Основной метод — ретроспективная проверка. Логика проста: система ставится в положение прошлого, строит прогноз, а результат сравнивается с тем, что произошло на самом деле.
- Выбирается контрольный период — например, последние шесть месяцев.
- Прогноз строится по данным, доступным на начало каждого месяца контрольного периода. Критично: использовать только те данные, которые были известны на тот момент.
- Прогноз сравнивается с фактом.
- Считается точность по группам номенклатуры, отдельно смотрится смещение.
- Результат сравнивается с тем, как планировали раньше.
Пятый шаг обязателен. Точность нового прогноза сама по себе ничего не говорит: важно, лучше он прежнего способа или нет. Если прошлые версии планов сохранились, сравнение делается напрямую.
Типичная ошибка ретроспективы
Построить прогноз на прошлый период, используя всю доступную сегодня историю, включая сам этот период. Результат получается прекрасным и не имеет отношения к реальности. Данные должны быть отсечены датой, на которую делается прогноз.
Валидация плана обеспечения
- Проверка на разумность. Расчёт закупки сравнивается с тем, что закупалось фактически. Расхождение в разы — повод разобраться, а не радоваться экономии.
- Проверка на исполнимость. Не превышает ли расчётный заказ возможностей поставщика и вместимости склада.
- Проверка граничных случаев. Позиции с нулевой историей, с единичными продажами, с очень длинным сроком поставки.
- Проверка мощностей. Расчётная загрузка сравнивается с фактической за прошлый период — расхождение обычно означает устаревшие нормативы времени.
Пилотный цикл как финальная проверка
Последний этап проверки — полный цикл на ограниченном контуре при сохранении старого процесса. Проверяется не система, а регламент:
- успевают ли участники к срокам этапов;
- понятны ли им результаты расчётов;
- хватает ли данных для принятия решений на совещании;
- сколько ручных правок вносится в расчёт и почему;
- что участники делают в обход системы — это самый информативный вопрос.
Минимальная длительность пилота — два-три полных цикла. Один цикл не даёт статистики и не показывает, воспроизводим ли процесс.
Критерии готовности к запуску
- Точность прогноза на ретроспективе не хуже прежнего способа планирования.
- Нет систематического смещения по значимым группам.
- Расчёт потребности не требует массовых ручных правок.
- Все роли прошли свои сценарии под своими учётными записями.
- Регламентные задания отработали несколько циклов без сбоев.
- Проведено не менее двух полных пилотных циклов.
- Назначена дата отказа от старого инструмента.
Итог
Проверка планирования состоит из двух частей: функциональное тестирование отвечает на вопрос, работает ли система, ретроспективная валидация — на вопрос, стоит ли доверять её результату. Вторая часть важнее и чаще пропускается, а без неё пользователи справедливо продолжают вести параллельные файлы. Ключевое методическое требование — при проверке на истории использовать только данные, известные на момент прогноза.
Запуск и начальная поддержка — завершающий шаг внедрения решения «1С:S&OP», на котором проверяются первые реальные циклы.
Компания «Сайфилд» проводит настройку, ретроспективную проверку и пилотный запуск планирования в «1С». Опишите свою ситуацию, и мы оценим объём работ.