Качество предложений от интеграторов напрямую зависит от того, насколько точно описана задача. Если запрос сформулирован размыто, интегратор будет работать с допущениями — и его предложение окажется таким же приблизительным. Разбираем, какие данные нужны для первичного запроса, как составить черновик технического задания и что обязательно указать, чтобы получить предметный ответ.
В этой статье
Зачем вообще готовить запрос и ТЗТри уровня описания задачи
Что включить в первичный запрос
Что включить в черновик технического задания
Типовые ошибки при описании задачи
Как использовать шаблон
Зачем вообще готовить запрос и ТЗ
Интегратор не может предложить хорошее решение, если не понимает задачу. Это звучит очевидно, но на практике значительная часть первичных обращений выглядит примерно так: «хотим поставить робота на участок паллетирования, сколько будет стоить?» Ответить на такой вопрос честно невозможно — не потому что интегратор не хочет, а потому что стоимость и состав решения зависят от десятков параметров, которые в таком запросе не указаны.
Чем подробнее исходные данные, тем точнее предложение. И тем меньше вероятность, что в середине проекта всплывут ограничения, которые потребуют переделки компоновки, замены оснастки или пересмотра бюджета.
Хорошая подготовка к разговору с интегратором — это не бюрократия. Это способ получить предметное предложение быстрее и с меньшим числом итераций.
Подготовленный запрос особенно важен при использовании RoboRequest: чем точнее описана задача, тем более предметными будут отклики интеграторов и тем проще их сравнивать между собой.
Три уровня описания задачи
Глубина проработки зависит от стадии проекта. Не нужно сразу писать полноценное техническое задание — это лишняя работа до того, как вообще понятно, реализуем ли проект в нужном бюджете и сроке. Удобнее думать о трех уровнях.
Первый уровень — первичный запрос. Минимальный набор данных, достаточный для того, чтобы интегратор понял, о какой задаче идет речь, и смог дать предварительную оценку применимости и порядок бюджета. Именно этот уровень нужен для RoboRequest.
Второй уровень — черновик технического задания. Более детальное описание задачи, которое позволяет интегратору сформировать конкретное предложение с компоновкой, составом оборудования и ориентировочной стоимостью. Обычно готовится до первой предметной встречи или параллельно с ней.
Третий уровень — полноценное техническое задание. Детальный документ, который фиксирует все требования, критерии приемки и технические условия. Как правило, дорабатывается уже вместе с интегратором после обследования участка. На старте его готовить не нужно.
Начинать стоит с первого уровня. Детализация растет по мере того, как проект переходит от оценки к реализации.
Что включить в первичный запрос
Для первичного запроса достаточно ответить на несколько базовых вопросов. Они позволяют интегратору понять масштаб задачи, тип операции и ключевые ограничения — всё остальное уточняется в рабочем порядке.
Что за операция и какая проблема
Коротко описать, что сейчас происходит на участке и какую проблему нужно решить: снять тяжелую ручную операцию, ускорить цикл, стабилизировать качество, убрать зависимость от дефицитного персонала, загрузить станок без участия оператора. Без понимания цели интегратор не может предложить правильную архитектуру решения.
Что за деталь или продукт
Габариты, масса, материал, состояние поверхности. Если номенклатура широкая — указать диапазон: минимальный и максимальный размер, минимальную и максимальную массу. Если деталь бывает горячей, влажной, острой, хрупкой или пыльной — это тоже нужно указать сразу.
Откуда берется и куда кладется
Как деталь поступает на точку захвата: с конвейера, из тары, из станка, из лотка. В каком положении приходит. Куда нужно ее переместить и в какой ориентации. Нужна ли какая-то обработка в процессе или только перемещение.
Производительность и режим работы
Желаемый такт или производительность в единицах за смену. Количество смен. Планируется ли работа без участия оператора в какое-то время суток.
Ограничения участка
Доступная площадь под ячейку, подвод питания и пневматики, соседнее оборудование, проходы, требования по безопасности. Если есть фото или видео участка — приложить: это часто дает интегратору больше информации, чем подробное текстовое описание.
Бюджетный диапазон и сроки
Хотя бы ориентировочный диапазон бюджета и желаемые сроки запуска. Это помогает интегратору сразу предложить реалистичный формат решения: типовую ячейку или проект под заказ, поэтапный запуск или полный комплекс сразу.
Что включить в черновик технического задания
Черновик ТЗ — это не финальный документ и не юридически обязывающий контракт. Это рабочий инструмент для первой предметной встречи с интегратором. Его цель — дать подрядчику достаточно информации, чтобы он мог предложить конкретную компоновку и ориентировочную стоимость.
Цель и задачи проекта
Что именно должно измениться после внедрения. Какие результаты считаются успешными. Например: обеспечить укладку не менее 500 коробов в час в две смены, снизить долю ручного труда на участке, исключить травмоопасную операцию подъема тяжестей.
Исходные данные по участку и операции
Что сейчас делает оператор, шаг за шагом. Параметры изделий. Текущая производительность. Режим работы. Существующие проблемы: нестабильное качество, брак, простои, нехватка людей, безопасность. Ограничения участка. Какие данные уже есть — фото, видео, планировка, статистика по браку. Каких данных не хватает — это тоже важно указывать честно, а не замалчивать.
Функциональные требования
Что должен выполнять робототехнический комплекс. Что подается на входе. Что должно получаться на выходе. Какие действия остаются за человеком. Как оператор будет взаимодействовать с системой. С каким существующим оборудованием нужна интеграция.
Требования к производительности
Время цикла операции. Производительность в единицах за час или смену. Количество смен. Требуемый коэффициент готовности оборудования. Допустимое время переналадки при смене номенклатуры. Плановый годовой объем.
Требования к качеству
Что считается результатом правильно выполненной операции. Допустимый процент брака. Требования к повторяемости. Что является дефектом. Как будет измеряться качество.
Требования к безопасности
Какие опасные зоны есть на участке. Какие ограждения, блокировки и аварийные остановы нужны. Будет ли оператор находиться рядом с ячейкой во время работы. Какие требования по охране труда нужно учесть.
Конструктивные и инфраструктурные требования
Доступная площадь. Планировка и схема потоков. Электропитание. Пневматика, воздух, газ, вентиляция. Требования к фундаменту и монтажным ограничениям. Подвод и отвод деталей, тары, заготовок. Требования к доступу для обслуживания.
Критерии приемки
Это один из самых важных блоков, который часто пропускают. Критерии приемки нужны для того, чтобы заранее договориться, как именно будет проверяться результат внедрения. Без них невозможно зафиксировать, что проект выполнен успешно.
В этом блоке стоит указать: как будет измеряться производительность и за какой период, какой допустимый процент брака, как проверяется стабильность работы, как подтверждается безопасность ячейки, проводится ли тестовый прогон на типовой номенклатуре, что входит в комплект документации при передаче, кто и в каком объеме обучается.
Если критерии приемки не зафиксированы заранее, в момент завершения проекта у заказчика и интегратора может оказаться разное представление о том, что считается «готово».
Типовые ошибки при описании задачи
Пишут «нужен робот», не описывая операцию
«Хотим роботизировать участок» — это не запрос, а намерение. Интегратору нужно понимать, что именно должен делать робот, с какой деталью, откуда берет, куда кладет, с каким тактом и при каких ограничениях участка.
Не указывают параметры детали
Масса, габариты, материал, состояние поверхности и диапазон номенклатуры — это не второстепенные детали, а исходные данные для выбора типа робота, рабочего органа и компоновки ячейки. Без них любое предложение будет приблизительным.
Описывают идеальный сценарий
Деталь всегда приходит в одном положении, упаковка не меняется, операторы строго соблюдают регламент. Если реальный процесс выглядит иначе, система будет спроектирована под условия, которых в цехе нет. Лучше показывать процесс таким, какой он есть, включая нестабильность, разброс и нестандартные ситуации.
Замалчивают отсутствие данных
Если каких-то данных нет — по статистике брака, по точным габаритам, по нагрузке на участок — честнее написать «нужно уточнить», чем придумывать цифры. Интегратор, который понимает, каких данных не хватает, может помочь их собрать или заложить правильные допущения в расчет.
Не указывают бюджетный диапазон
Без ориентира по бюджету интегратор не знает, предложить типовое решение или проект под заказ, поэтапный запуск или полный комплекс сразу. Бюджетный диапазон — это не обязательство, а рабочий ориентир, который помогает сформировать реалистичное предложение.
Не формулируют критерии приемки
Если в запросе нет ответа на вопрос «как мы поймем, что всё сделано правильно», это рискованная ситуация для обеих сторон. Критерии приемки лучше обсуждать в начале, а не в конце проекта.
А чтобы сравнивать эти отклики не только по цене, но и по зрелости подхода, полезно отдельно посмотреть, как выбирать интегратора для роботизации производства: Как выбрать интегратора для роботизации производства
Хороший запрос — это не длинный документ. Это честное и конкретное описание задачи, детали, ограничений участка и ожидаемого результата.
О том, как выглядит нормальный проектный процесс после того, как запрос отправлен и интегратор выбран, мы рассказываем в статье про этапы внедрения: Как проходит внедрение промышленного робота по этапам
Если участок еще не готов к роботизации или непонятно, с чего начать сбор данных, полезно сначала прочитать статью о подготовке производства: Как подготовить производство к внедрению промышленного робота