МАСТЕР-ТЗ НА АСУ ТП: КАК ЗАЩИТИТЬ ЗАВОД ОТ ОШИБОК ПРИ ВЫБОРЕ ИНТЕГРАТОРА
Зачем этот документ
Вы получили три коммерческих предложения от интеграторов. Первое — на 4 млн, второе — на 11 млн, третье — на 7 млн. Все три — «на внедрение системы мониторинга производства». Что именно входит в каждое — непонятно. Сравнить нечего. Выбрать обоснованно — невозможно.
Это стандартная ситуация для предприятий, которые выходят на рынок без технического задания. В отсутствие ТЗ каждый интегратор формулирует объём работ под собственные компетенции и коммерческие интересы. Дешёвое предложение может не включать интеграцию с 1С. Дорогое — содержать функции, которые вам не нужны ещё пять лет.
Мастер-ТЗ решает эту проблему. Это документ, который вы составляете до выхода на рынок и передаёте всем потенциальным исполнителям как единое техническое основание. Все отвечают на одни и те же требования — вы получаете сопоставимые предложения и реальный контроль над тем, что будет сделано.
Документ написан на языке заказчика — без формул и протоколов. Его читает и утверждает главный инженер, а не программист.
Что внутри
Раздел 1. Общая информация о предприятии. Тип производства, количество станков, смен, операторов. Существующая IT-инфраструктура: есть ли сеть в цехах, какая ERP, есть ли 1С и какая конфигурация. Эти данные определяют половину технических решений — интегратор должен знать их до начала работ, а не в процессе.
Раздел 2. Цели и ожидаемые результаты. Что должна делать система через 90 дней после запуска. Формулировки конкретные и измеримые: «Директор получает ежедневный отчёт OEE по каждому цеху до 8:00», «Оператор фиксирует причину простоя не позднее 5 минут после возникновения», «Данные из Atlas PRO передаются в 1С ежесменно».
Раздел 3. Требования к функциональности. Перечень обязательных функций: учёт рабочего времени оборудования, классификация простоев, сменные задания, интеграция с ERP, уведомления, отчёты. Для каждой функции — статус: «Обязательно на старте» или «Перспектива». Это защищает от навязывания ненужного функционала с первого дня.
Раздел 4. Требования к интеграции. Какие системы должны быть связаны с DPA, какие данные передаются в каком направлении, какой метод интеграции предпочтителен (REST API или файловый обмен). Без этого раздела интеграция с 1С превращается в «мы договоримся по ходу» — то есть в источник конфликтов и дополнительных счетов.
Раздел 5. Требования к инфраструктуре. Кто обеспечивает сеть, сервер, терминалы — завод или интегратор. Требования к оборудованию, которое предприятие закупает самостоятельно.
Раздел 6. Требования к обучению и документации. Что интегратор обязан передать по итогам проекта: инструкции, регламенты, видеозаписи, доступ к базе знаний. Без этого раздела предприятие остаётся в зависимости от интегратора на всё время эксплуатации.
Раздел 7. Критерии приёмки. Что должно быть выполнено, чтобы подписать акт. Формулировки измеримые: «Система работает стабильно 30 дней», «Данные верифицированы с бумажными журналами», «Обучено не менее N человек с документально подтверждёнными результатами».
Как применять
Шаг 1. Заполните разделы 1–2 самостоятельно. Описание предприятия и цели проекта — это ваша зона ответственности, не интегратора. На этом этапе привлеките главного инженера и директора по производству: цели должны отражать реальные управленческие потребности, а не технические предпочтения IT-отдела.
Шаг 2. Разделы 3–5 заполняйте совместно с IT-руководителем. Требования к функциональности и интеграции требуют понимания текущей инфраструктуры. Если IT-директор не участвует в составлении ТЗ — он гарантированно найдёт причины не поддерживать проект после его запуска.
Шаг 3. Передайте ТЗ всем претендентам одновременно. С одинаковым дедлайном на ответ. Запросите коммерческое предложение строго по структуре ТЗ: отклонения от структуры означают, что интегратор предлагает то, что удобно ему, а не то, что нужно вам.
Шаг 4. Используйте ТЗ как основу договора. Технические требования из ТЗ включаются в договор как неотъемлемое приложение. Это единственный способ зафиксировать объём работ юридически, а не на словах.
Шаг 5. Обновляйте ТЗ при изменении требований. Если в ходе проекта меняются цели или добавляется функциональность — изменения оформляются как дополнение к ТЗ и к договору. «Это же мелочь, сделайте так» без фиксации — прямой путь к конфликту при приёмке.
Типичные ошибки
ТЗ пишет интегратор. Логика понятна: он «знает, как надо». Результат: ТЗ описывает то, что интегратор умеет делать, а не то, что нужно предприятию. При этом предприятие подписывает документ, не понимая половины требований.
Критерии приёмки не определены. «Система должна работать» — не критерий. Когда подходит дата подписания акта, обе стороны оказываются в ситуации, где каждый понимает «работает» по-своему. Споры затягиваются, отношения портятся, проект формально не завершается.
Требования к обучению не включены. Интегратор провёл однодневный тренинг и считает задачу выполненной. Предприятие через три месяца обнаруживает, что операторы не знают, как классифицировать простои, а IT не умеет делать резервную копию базы данных. Обучение — это не приятный бонус, это обязательное требование с измеримым результатом.
Интеграция с 1С вынесена «за скобки». «Это отдельный проект, потом». Потом оказывается, что архитектура системы мониторинга не рассчитана на интеграцию, и переделка стоит столько же, сколько первоначальное внедрение. Интеграция с ERP должна быть частью исходного ТЗ — даже если её реализация запланирована на второй этап.
🔒 Скачать: Мастер-ТЗ от Атлас ПРО (пример внедрения системы MDC)] →