Единый канал заявок OT/IT: классификация и маршрутизация

Зачем производству единый канал заявок OT и IT

На производстве проблемы редко приходят по регламенту. Оператор говорит мастеру, мастер пишет в чат, кто-то звонит знакомому айтишнику, а автоматчик видит просьбу только в конце смены. В итоге часть обращений не оставляет следа: нет номера, времени, понятного "кто принял" и "что сделали". Когда точек входа много, даже простая неисправность превращается в цепочку догадок.

OT и IT отличаются не только технологиями, но и ценой ошибки. Для IT чаще важны доступ и данные. Для OT - безопасность людей и оборудования, качество продукта и остановка линии. Там, где в офисе можно "подождать до утра", в цеху час простоя может стоить сменного плана, сырья и нервов.

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

Единый канал заявок OT/IT решает проблему не тем, что "всех загоняем в одну очередь", а тем, что дает одну понятную точку входа для цеха и офиса. Дальше работает маршрутизация: кому уходит задача, какие вопросы задать при регистрации, какой уровень срочности поставить.

На практике это означает одно место для обращений (без звонков в обход), единый минимальный набор данных (участок, оборудование, симптомы, время) и понятный статус, чтобы смена видела, что происходит. При этом правила обработки могут быть разными: отдельные очереди для IT, АСУ ТП и эксплуатации.

Пример: "на участке упаковки не печатает этикетки". Через единый канал фиксируют, что отказ начался после замены рулона и одновременно пропала сеть на одном порту. По маршруту задача уходит и в IT (сеть/принтер), и в OT/эксплуатацию (питание/подключение). Вместо двух несвязанных звонков появляется одна история с понятным итогом.

Роли и зоны ответственности: кто пишет, кто делает, кто решает

Чтобы единый канал заявок OT/IT работал, нужна простая карта ролей: кто подает заявку, кто исполняет и кто принимает решения, если задача спорная или затрагивает производство.

Заявки должны уметь создавать не только IT. Чаще всего первым проблему видит оператор на линии или сменный мастер. У них должно быть право завести обращение и заполнить минимум: где, что случилось, с какого времени, что уже пробовали.

Исполняют разные команды, и это нормально. Важно, чтобы заявка не прыгала между отделами без владельца. Для старта достаточно закрепить базовые роли:

• Заявитель: оператор, мастер смены, инженер участка, офисный пользователь.
• Исполнитель: IT (рабочие места, сеть, учетные системы), АСУ ТП (SCADA, PLC, промышленная сеть), КИПиА (датчики, приводы), эксплуатация (питание, климат, механика), подрядчик (по договору).
• Решающий: дежурный координатор, руководитель смены, владелец сервиса (например, владелец MES или линии).

Ключевая роль - дежурный координатор (диспетчер/Service Desk). Он не обязан разбираться в контроллерах, но обязан принять обращение, уточнить симптомы, назначить первичного исполнителя и следить, чтобы заявка не зависла.

Чтобы не было "это не к нам", заранее зафиксируйте границы ответственности. Удобный принцип: кто отвечает за сервис, тот и владелец заявки, даже если часть работ делает другая команда. В регламенте стоит прописать владельцев сервисов и контакты для эскалации, правило передачи (кто и за сколько времени может перекинуть), что считается восстановлением (временный обход или полное решение), а также кто имеет право остановить работы, если есть риск для безопасности и качества.

Пример: оператор пишет: "терминал на посту не печатает этикетки, линия стоит". Координатор назначает первичным IT (печать и ПК), но сразу добавляет АСУ ТП в наблюдатели, если этикетка идет из SCADA/MES. Если выясняется, что датчик на принтере показывает ошибку, владелец заявки остается у IT до восстановления, а КИПиА делает свою часть по факту. Приоритет и допуск к оборудованию подтверждает руководитель смены.

Инцидент или запрос: простые правила и примеры формулировок

Инцидент - это когда что-то работало и перестало работать (или стало заметно хуже). В производстве это часто означает простои, брак, риск для людей или оборудования. Запрос - это когда нужно новое действие: настроить, выдать доступ, установить, изменить или объяснить.

Чтобы меньше спорить, достаточно двух вопросов:

1. Процесс остановился или может остановиться в ближайшее время?
2. Есть риск для безопасности, качества, экологии, потери данных или повреждения оборудования?

Если на любой вопрос ответ "да" или "не уверен" - оформляйте как инцидент. Проще начать с инцидента и потом перевести в запрос, чем наоборот и потерять время.

Примеры формулировок

Инцидент (сбой или деградация): "На линии упаковки с 10:15 не обновляются значения с датчика температуры, HMI показывает прочерки, линия работает вслепую". Или: "SCADA периодически теряет связь с контроллером участка, каждые 5-10 минут пропадает тренд, оператор не может держать режим". Всегда указывайте участок, время, симптомы и что уже пробовали (перезапуск, смена кабеля, проверка питания).

Запрос (новое или изменение): "Нужен доступ оператору Петрову в систему учета простоев на участке 3, роль - просмотр и ввод причин". Или: "Поставьте принтер в диспетчерской и настройте печать сменных отчетов". Хороший запрос отвечает на вопросы: кому, что именно, к какому сроку, кто согласовал.

Пограничные случаи и как их оформлять

Частые серые зоны - "медленно", "периодически", "не уверен". Если "медленно" влияет на выпуск (например, задержки на сканере, терминале, MES), это инцидент с деградацией. Если "периодически" повторяется и мешает смене, это тоже инцидент, даже если прямо сейчас "вроде работает". Если не уверены, ставьте инцидент и в описании пишите честно: "не уверен, похоже на деградацию, прошу проверить".

Классификация: как разбить заявки, не усложняя жизнь

Классификатор нужен не ради красоты в системе. Он помогает быстро понять, куда отправить заявку и кто отвечает за решение. В едином канале заявок OT/IT важно, чтобы оператор на смене мог выбрать категорию за 10-15 секунд. Иначе начнут писать "просто не работает" и звонить напрямую.

Практичный подход - два верхних уровня: "где" и "что ломается/нужно". Для OT удобно начинать с места и оборудования: линия или участок, дальше конкретика (ПЛК/контроллер, SCADA/HMI, датчик, сеть цеха). Для IT чаще стартуют с объекта поддержки: ПК, учетная запись, сервер, приложение, офисная сеть, печать.

Чтобы не плодить сотни пунктов, держите общий набор типов проблемы и добавляйте OT/IT детали на следующем шаге. Обычно хватает 5-6 типов:

• доступ (не входит, нет прав, не видит ресурс)
• сбой (остановка, ошибка, не запускается)
• производительность (тормозит, задержки, пропуски данных)
• замена (узел, ПК, датчик, кабель)
• настройка/изменение (параметры, рецепт, печатные формы)

Дальше система помогает маршрутизации: "участок + ПЛК + сбой" уйдет автоматчикам, "офисная сеть + доступ" - IT, а "датчик + замена" может сразу уйти в эксплуатацию, если это их зона.

Минимальные поля в заявке лучше сделать обязательными, но короткими. Если полей много, их будут обходить.

• где: площадка, цех, линия/станок (или кабинет для IT)
• что: короткое описание и выбранные категории
• когда: время начала и повторяемость
• влияние: остановка/замедление/один пользователь
• контакт: кто на месте и как связаться

Пример: "Линия 3, участок упаковки. SCADA не показывает веса, данные стоят с 10:20. Линия работает в ручном, риск брака. На месте Иван, смена B, есть фото экрана". По такой заявке не нужно угадывать ни тип, ни адрес, ни срочность.

Приоритеты: как назначать срочность без споров

Срочность в производстве легко превращается в конфликт: "у нас горит" против "это плановая работа". Чтобы единый канал заявок OT/IT не стал площадкой для перепалок, зафиксируйте простую формулу приоритета: влияние на производство + срочность по времени + риск (безопасность людей, качества, данных, оборудования).

Сначала оцените влияние: остановка линии, снижение выпуска, ухудшение качества, риск простоя в ближайшие часы или просто неудобство для одного пользователя. Затем добавьте срочность: есть ли дедлайн смены, окно запуска, приемка, отгрузка. И отдельно отметьте риск: даже небольшая проблема может быть опасной, если затрагивает защиту, блокировки, архивы или кибербезопасность.

Простая шкала P1-P4

Четырех уровней обычно достаточно:

• P1 - остановка производства или критический риск (HSE, качество, безопасность объекта). Нужна немедленная реакция и регулярные обновления статуса.
• P2 - производство работает, но заметно деградирует: снижен выпуск, часть линии стоит, обходные решения ограничены, риск перейти в P1 высокий.
• P3 - локальная проблема без влияния на выпуск: одно рабочее место, отдельный терминал, отчет, печать, доступ. Решается планово.
• P4 - улучшение или "как сделать": консультация, настройка, изменение, запрос на доступ без срочности.

Примеры: остановка линии из-за отказа PLC или сети на участке - P1. Система маркировки работает через раз, часть партии уходит в ручной режим - P2. Не открывается SCADA на одном операторском ПК, но смена может работать на соседнем - P3.

Сменность, окна обслуживания и повышение приоритета

В правилах укажите, как учитывать смены и окна обслуживания. Если работа возможна только ночью или в технологический простой, это влияет не на приоритет, а на план и согласование времени. При этом P1 не ждет окна.

Право повысить приоритет лучше ограничить и фиксировать в заявке: кто, когда, почему. Обычно это начальник смены/участка (по влиянию на выпуск), дежурный инженер АСУ ТП или IT (по техническому риску), ответственный за безопасность/качество (по риску HSE/QA), руководитель производства или IT/OT (в спорных случаях).

Если приоритет повысили, добавьте короткий комментарий: что изменилось (остановка, рост брака, потеря связи, риск) и какой срок реакции ожидается.

Маршрутизация между IT, АСУ ТП и эксплуатацией: кто берет и когда

Начинайте с одной точки входа для людей в цехе: телефон дежурному, портал или почта - формат может быть разным. Принцип один: любая заявка регистрируется в одной очереди с единым номером. Тогда не будет параллельных переписок и потерянных просьб.

Маршрутизацию лучше строить по простым признакам, которые оператор выберет за полминуты: локация (участок, линия, шкаф, серверная), оборудование (PLC/SCADA/HMI, промышленная сеть, сервер, рабочее место, датчик, привод), класс (инцидент или запрос), приоритет, владелец сервиса (IT, АСУ ТП, эксплуатация).

Не гоняйте такие случаи "по цепочке" (сначала одному, потом другому). Подключайте совместно IT + АСУ ТП + эксплуатацию сразу, если есть хотя бы один признак: проблема на границе сетей (SCADA не видит PLC), непонятно, где первопричина, есть влияние на безопасность или уже начался простой. Так вы экономите время на догадках.

Эскалация должна быть формальной и короткой: сколько ждем реакцию и что фиксируем в карточке. Практичный вариант:

• нет ответа от назначенного в X минут - назначаем дежурного OT/АСУ ТП или дежурного IT (по признакам)
• еще X минут - подключаем руководителя смены/старшего инженера и ставим пометку "простой/риск"
• в комментарии пишем: что наблюдаем, что уже проверили, что нужно от следующей роли

Удобно заранее завести шаблоны назначений: "дежурный OT", "сетевик", "сервисный инженер", "админ серверов". Например, если оператор пишет: "На линии 3 HMI не показывает параметры, станок стоит", заявка сразу уходит дежурному OT и сетевику, а эксплуатация подключается, чтобы параллельно проверить питание и кабели на месте.

SLA и коммуникации: чтобы смена понимала, что происходит

SLA в производстве работает только тогда, когда он понятен смене. Не "выполним за 8 часов", а простые ответы на три вопроса: когда начнем, когда станет стабильно и что делать прямо сейчас, пока проблема не закрыта.

Для начала договоритесь, что вы измеряете. В практике OT/IT обычно хватает трех метрик: время реакции (когда исполнитель взял в работу), время восстановления (когда процесс снова работает) и время выполнения запросов (когда сделано изменение или выдан доступ).

Базовый набор договоренностей:

• время реакции: как быстро команда подтверждает, что заявка принята, и кто ответственный
• время восстановления: к какому моменту линия или участок должны вернуться в работу
• время на запрос: сколько занимает плановое изменение без аварии
• окна работ: когда допустимы перезагрузки, обновления, переключения
• канал эскалации: кого подключаем, если время уходит

Ожидания для OT и IT лучше разделять. Для OT при остановке участка реакция часто должна быть быстрее, потому что каждая минута стоит денег и влияет на безопасность. Для IT многие запросы терпят планирование, но критичные сервисы (например, учет выпуска или сеть на участке) по факту приближаются к требованиям OT.

Правило коммуникации должно быть таким же четким, как сроки. Для P1-P2 задайте ритм обновлений, чтобы смена не "додумывала":

• P1: статус каждые 15-30 минут до стабилизации
• P2: статус раз в 60 минут
• после стабилизации: одно сообщение с итогом и следующими шагами

Отдельно фиксируйте временные меры. Если нашли обходной путь (перевели на резервный канал, перезапустили сервис, переключили рабочее место), это записывается в заявке: что сделали, какие риски, сколько может работать и к какому времени нужно постоянное решение. В организациях с 24/7 поддержкой и дежурствами это особенно важно, чтобы передача между сменами проходила без потерь.

Частые ошибки при внедрении единого канала заявок

Процесс ломается, когда его делают "как в офисе", а потом удивляются, что смена обходит систему. Единый канал заявок OT/IT начинает работать, когда он экономит время на месте и снижает риск простоя.

Самая частая проблема - неполные заявки. Пишут "линия не работает", но не указывают участок, номер шкафа или оборудования, симптомы, время начала и кто рядом может показать проблему. В итоге специалисты тратят время на уточнения вместо восстановления.

Вторая крайность - перегруженная форма. Когда в заявке десятки категорий и слишком много обязательных полей, люди выбирают случайные пункты или уходят в звонки "напрямую". Оставьте минимум, который помогает быстро направить работу, остальное добирайте уточняющими вопросами.

Еще одна боль - "у всех P1". Если любой запрос становится критическим, приоритет перестает что-то значить. Помогает простое правило: P1 - это риск простоя, травмы или нарушения качества здесь и сейчас, а не "мне нужно к концу смены".

Маршрутизация "по людям" тоже ломает процесс. Когда все знают, что "это к Сергею", система превращается в записную книжку, а при отпуске или ночной смене все стопорится.

Проверьте, нет ли у вас этих симптомов:

• заявки без места, времени, контакта и признаков ошибки
• слишком много категорий и обязательных полей
• массовые P1 без понятного критерия
• назначение по фамилиям вместо правил
• инциденты и плановые работы в одной очереди без отметок

Есть и более тонкая ошибка: смешивать инциденты и плановые задачи так, что они выглядят одинаково. Тогда срочные восстановления теряются среди "поставить обновление", а плановые работы постоянно сдвигаются из-за авралов.

Короткий чек-лист: готов ли ваш процесс заявок OT и IT

Единый канал заявок OT/IT работает, когда человеку на линии просто им пользоваться, а исполнителям хватает данных, чтобы начать без лишних звонков.

5 быстрых проверок

• Подать заявку реально за пару минут. Оператор смены может создать обращение с телефона или рабочего ПК, не вспоминая коды цехов и не заполняя десяток полей.
• Из заявки понятно, где и что. Есть место (участок, линия, номер шкафа или станка), симптом (что видит человек), время начала и безопасный способ связаться.
• Срочность назначается по правилам, а не по должности. Приоритет зависит от влияния на безопасность, выпуск и качество, а не от того, кто написал.
• Есть понятная ночная эскалация. Кто дежурит, как быстро реагирует и когда подключается второй уровень, ясно всем.
• Инцидент закрывают только после подтверждения от производства. Исполнитель исправил, но финальное "стало нормально" дает смена или мастер.

Если по двум и более пунктам ответ "нет", начните с простого: сократите форму заявки, добавьте обязательные поля для места и симптома, закрепите одну страницу правил приоритета и эскалации. Это обычно дает больше эффекта, чем попытка сразу перестроить всю маршрутизацию.

Пример сценария: сбой на участке и совместная работа OT и IT

Ночь, участок упаковки. Оператор видит: на HMI вместо текущих параметров - серые поля и сообщение "Нет связи с ПЛК". Линия не встала полностью: конвейер крутится, но часть датчиков не отображается, и смена боится запускать следующую партию.

Мастер смены заводит заявку в единый канал и описывает наблюдаемые симптомы. Достаточный минимум:

• где: цех 2, линия 3, шкаф №7, панель HMI на посту оператора
• что видно: точный текст ошибки, время появления, что менялось перед этим
• влияние: можно ли продолжать, какой риск (брак, останов, безопасность)
• что уже пробовали: перезагрузка HMI, проверка питания, переключение на резерв
• приложение: фото экрана и, если есть, фото индикации на сетевом свитче

Дежурный диспетчер классифицирует это как инцидент (есть сбой и влияние на выпуск), ставит высокий приоритет и фиксирует, что полной остановки пока нет. Первым исполнителем назначают дежурного АСУ ТП для проверки ПЛК и связи на уровне контроллера. Параллельно создается подзадача в IT на сеть: порт коммутатора, VLAN, журнал событий, доступность узла.

АСУ ТП проверяет: ПЛК в RUN, ошибок нет, пинг до HMI не проходит. IT находит на порту свитча ошибки CRC и скачки линка. Меняют патч-корд, переносят порт, связь восстанавливается.

В закрытии заявки фиксируют, что сделали, время восстановления и временный обходной путь (например, работа через соседнюю HMI). Отдельно создают запрос (не инцидент) на улучшение: заменить изношенный кабельный участок на трассе и добавить регулярную проверку портов на ошибки.

Следующие шаги: пилот, закрепление правил и поддержка

Начинайте не с идеального процесса, а с короткого пилота. Выберите один цех или участок и договоритесь, что все обращения идут через единый канал, даже если дальше их будут решать разные команды.

С чего начать: короткий пилот

Возьмите 10-20 самых частых ситуаций и опишите их простыми словами. Это быстро покажет, где люди путаются и какие поля в заявке действительно нужны.

• сделайте короткий классификатор (5-8 категорий) и 2-3 обязательных поля: где, что случилось, когда началось
• утвердите правило "инцидент/запрос" и пару примеров формулировок для смены
• назначьте дежурного на входе (триаж): кто читает и направляет в первые 5-10 минут
• запустите пилот на 2-4 недели и фиксируйте спорные случаи
• по итогам внесите одну правку правил, а не десять

Чтобы пилот не развалился, обычно хватает трех коротких документов на 1-2 страницы: правила "инцидент или запрос", матрица приоритетов и схема эскалации.

Что автоматизировать позже

Сначала важнее дисциплина, чем автоматизация. Когда вход стабилизируется, добавляйте уведомления по сменам, шаблоны для типовых заявок, отчеты по причинам и базу знаний с проверенными действиями.

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

Если не хватает ресурсов или нужна поддержка 24/7, имеет смысл подключать интегратора, который поможет выстроить процесс, роли и инфраструктуру. Для казахстанских предприятий такие задачи по системной интеграции и сервисному сопровождению выполняет GSE.kz (gse.kz).