Не гадайте: решения для промышленной автоматизации предоставляют точные данные.

Когда производственные решения основаны на оценках, небольшие ошибки в данных могут распространиться на всю операцию. Может показаться, что машина работает на полную мощность, а короткие остановки снижают фактическую производительность. Команда технического обслуживания может заменить деталь из-за предполагаемой неисправности, даже если реальная проблема связана с неисправным датчиком или задержкой данных. Менеджеры могут сравнивать смены, используя цифры, собранные разными способами. Я видел эту закономерность во многих производственных средах: у людей нет недостатка в данных. Им не хватает данных, которым можно доверять. Промышленная автоматизация может помочь решить эту проблему, собирая производственную информацию непосредственно с машин, датчиков и систем управления. Цель не состоит в том, чтобы собрать больше чисел. Цель состоит в том, чтобы создать четкий путь от машинной деятельности к бизнес-решениям. Начните с вопроса, стоящего за данными Прежде чем добавлять датчики или программное обеспечение, я определяю решение, которое должны поддерживать данные. Руководитель производства может заинтересоваться: - Почему объем производства меняется между сменами? - Какие машины вызывают больше всего простоев? - Сколько времени занимает каждая замена? - Связаны ли проблемы качества со скоростью, температурой, давлением или потоком материала? - Сокращает ли плановое техническое обслуживание незапланированные простои? Каждый вопрос требует разных данных. Панель мониторинга, наполненная несвязанными значениями, может выглядеть подробной, но это может усложнить принятие решений. Полезная система связывает каждое измерение с практическим действием. Создайте надежный путь передачи данных Промышленные данные обычно проходят через несколько уровней: 1. Датчики измеряют такие условия, как температура, давление, скорость, вибрация или положение. 2. ПЛК обрабатывают сигналы и управляют действиями машины. 3. Системы SCADA отображают текущие условия эксплуатации. 4. Историки хранят производственные данные, основанные на времени. 5. MES или программное обеспечение для бизнеса связывает информацию о машине с заказами, материалами, записями о качестве и данными о трудозатратах. Ошибки могут появиться в любой момент. Возможно, датчику потребуется калибровка. Тег ПЛК может использовать неправильную единицу измерения. На экране SCADA может отображаться статус, не соответствующий физическому компьютеру. Историк может зафиксировать время простоя без объяснения причины. Проверяю путь от машины до отчета. Если значение меняется во время этого пути, система должна показать, где и почему. Используйте четкие определения Одно и то же слово может означать разные вещи для разных команд. Для одного оператора простой может начаться при остановке машины. Во-вторых, оно может начаться, когда остановка продлится более пяти минут. В отчете о техническом обслуживании может использоваться одно правило, а в производственном отчете — другое. Это порождает споры о цифрах вместо дискуссий о производительности. Я рекомендую создать небольшой словарь данных для ключевых терминов: - Время выполнения - Плановая остановка - Незапланированная остановка - Количество хороших результатов - Количество бракованных изделий - Время цикла - Время замены - Доступность - Уровень качества В словаре должны быть указаны расчет, единица измерения, источник и частота обновления. Общее определение упрощает сравнение отчетов по машинам и сменам. Отделяйте машинные факты от человеческих объяснений Системы автоматизации хорошо фиксируют события. Людям часто приходится объяснять причину. ПЛК может записать, что двигатель остановился в 10:42. Он может не знать, была ли причина в нехватке материала, блокировке конвейера, защитных воротах или корректировке установки. Вот почему я совмещаю автоматический захват событий с простым вводом данных оператором. Оператору не нужно заполнять длинную форму. Краткий список кодов причин может предоставить полезный контекст, не замедляя работу. Доступные варианты могут включать: - Материал недоступен - Смена инструмента - Проверка качества - Механическая неисправность - Электрическая неисправность - Очистка - Регулировка настройки - Ожидание инструкций. Список следует обсудить с операторами. Если выбор не соответствует работе на полу, данные потеряют ценность. Проверяйте данные в источнике Отчет может выглядеть профессионально, но при этом содержать слабую информацию. Я использую несколько основных проверок: - Сравниваю значения датчиков с надежным портативным прибором. - Сравните количество машин с физическим количеством. - Просмотр меток времени в системах ПЛК, SCADA и MES. - Проверьте, совпадают ли единицы измерения. - Проверьте, что происходит, когда датчик отсоединяется. - Убедитесь, что остановка машины создает правильное событие. - Просмотрите отсутствующие, повторяющиеся или необычные значения. Упаковочная линия представляет собой простой пример. Если ПЛК сообщает о 10 000 единицах, но счетчик смен показывает 9 700, разница требует объяснения. Это может быть связано с отклонением продуктов, сбросом счетчиков, дублированием сигналов или задержкой отчета. Номер не следует принимать только потому, что он появляется на экране. Превратите необработанные данные в полезные представления Разным должностям требуется разный уровень детализации. Оператору может потребоваться текущая скорость, активные сигналы тревоги, состояние материала и следующие действия. Специалисту по техническому обслуживанию может потребоваться история сигналов тревоги, тенденции вибрации, нагрузка на двигатель и записи о ремонте. Руководителю завода может потребоваться производительность, время простоя, качество и ход выполнения заказа. Один экран не может хорошо служить всем целям. Я предпочитаю многоуровневую структуру: - Простое представление в реальном времени для операторов - Представление смены для руководителей - Представление тенденций для технического обслуживания - Представление производства и затрат для менеджеров Каждое представление должно отвечать на ограниченную группу вопросов. Слишком большое количество диаграмм может скрыть необходимую людям информацию. Используйте тенденции вместо отдельных показаний Одно показание может не рассказать всей истории. Температура двигателя 70°C может быть нормой для одной машины и предупреждающим знаком для другой. Время цикла в 12 секунд может быть приемлемым во время одного запуска продукта и неудовлетворительным во время другого. Тенденции добавляют контекст. Я сравниваю данные по: - одинаковым машинам - разным сменам - типам продукции - производственным заказам - плановым и внеплановым остановкам - до и после работ по техническому обслуживанию Рассмотрим завод, на котором происходит повторяющиеся короткие остановки одной разливочной машины. Ежедневный отчет может показывать приемлемые результаты. Почасовой тренд может показать, что количество остановок увеличивается после нескольких часов работы машины. Эта схема может помочь при проверке нагрева, потока материала или износа компонентов. Данные не заменяют техническую оценку. Это помогает команде направить это суждение на более ясную проблему. Защитите качество системы Точные данные зависят от ухода за системой. Калибровка датчика должна проводиться по документированному графику. Доступ пользователей должен соответствовать должностным обязанностям. Резервные копии следует тестировать. Изменения программного обеспечения должны быть зафиксированы. Сетевые соединения должны контролироваться. Старые теги и неиспользуемые отчеты следует удалять, если они создают путаницу. Кибербезопасность также имеет значение. Системы промышленного управления должны использовать контролируемый доступ, разделение сетей, где это возможно, надежные пароли, обновления программного обеспечения и четкие планы реагирования. Эти меры должны соответствовать оборудованию завода и эксплуатационным требованиям. Небольшое улучшение может быть более полезным, чем большой проект без четкого владельца. Например, очистка кодов простоев на одной производственной линии может помочь принять более правильные решения, чем добавление новой информационной панели для всего объекта. Сделайте цифры частью повседневной работы Данные становятся полезными, когда команды регулярно их обсуждают. Краткий ежедневный обзор может сосредоточиться на трех моментах: - Что изменилось по сравнению с ожидаемым результатом? - Какие доказательства подтверждают вероятную причину? - Какое действие будет проверяться в следующую смену? Я избегаю использования данных как способа обвинить операторов. Когда люди ожидают наказания за каждую необычную ценность, они могут перестать сообщать о проблемах. Лучший подход рассматривает неожиданные данные как сигнал, требующий исследования. Промышленная автоматизация работает лучше всего, когда люди доверяют информации и понимают, как она была получена. Точные данные не поступают от одного устройства или пакета программного обеспечения. Это результат четких определений, подходящих датчиков, подключенных систем, регулярных проверок и практического участия человека. Когда я перестаю гадать, я вижу, где теряется время производства, какие сигналы требуют внимания и какие действия заслуживают проверки. Эта ясность дает техническому обслуживанию, производству и управлению общую основу для принятия решений.

Многие команды автоматизируют задачи, чтобы сэкономить время, а затем обнаруживают новую проблему: более быстрая работа не всегда приводит к лучшим решениям. Отчет может обновиться за считанные секунды, но содержать повторяющиеся записи. Панель управления продажами может показывать высокую активность, в то время как некоторые данные о клиентах остаются устаревшими. Когда руководители полагаются на неясные данные, автоматизация может распространить ошибки на большее количество процессов. Я рассматриваю более разумную автоматизацию как баланс между скоростью, качеством данных и человеческим мнением. Цель не в том, чтобы отстранить людей от процесса. Цель состоит в том, чтобы предоставить людям более чистую информацию и больше времени, чтобы сосредоточиться на решениях, требующих опыта. ## Начните с решения Прежде чем выбирать инструмент автоматизации, я определяю решение, которое должен поддерживать процесс. Отдел продаж может захотеть ответить: - Какие потенциальные клиенты сегодня требуют внимания? - На какие аккаунты не получен ответ? - Какие сделки оставались неизменными слишком долго? - Какие записи клиентов требуют проверки? Эти вопросы более полезны, чем общая цель, такая как «автоматизация операций продаж». Они помогают команде выбирать правильные данные, правила, оповещения и точки обзора. Четкое решение также предотвращает ненужную автоматизацию. Если задача не соответствует бизнес-цели, ее автоматизация может увеличить затраты, но не добавить ценности. ## Создайте надежный поток данных. Точные решения зависят от точных исходных данных. Я отображаю, откуда берутся данные, как они изменяются и где хранятся. Базовый поток данных может включать в себя: 1. Клиент отправляет форму. 2. Система проверяет, существует ли уже письмо. 3. Контакт сопоставляется с существующей записью компании. 4. Лиду присваивается категория в зависимости от выбранных потребностей. 5. Отдел продаж получает задание с подробной информацией о клиенте. 6. Система записывает каждое действие для последующего просмотра. Этот процесс уменьшает необходимость ручного копирования между инструментами. Это также создает четкий путь для поиска ошибок. Полезная автоматизация должна включать проверку отсутствующих полей, повторяющихся записей, необычных значений и устаревших записей. Эти проверки не должны быть сложными. Простое правило, требующее от пользователя подтверждения неполного адреса, может предотвратить проблемы на последующих этапах процесса. ## Используйте правила, понятные людям. Правила автоматизации должны быть простыми для чтения и объяснения командой. Такое правило, как «отправлять дополнительное сообщение, если лид не проявляет активности в течение пяти рабочих дней», вполне понятно. Правило, основанное на нескольких скрытых условиях, может давать результаты, которым пользователи не могут доверять. Я предпочитаю писать каждое правило простым языком: - Когда происходит это событие - Проверьте эти точки данных - Примените это условие - Выполните это действие - Запросите человеческую проверку, если результат неопределенен. Этот формат помогает группам продаж, финансов и эксплуатации проверять один и тот же процесс, не полагаясь на одного технического специалиста. ## Обеспечьте человеческий контроль там, где суждение имеет значение. Не каждое решение должно быть автоматическим. Система может пометить учетную запись с высокой стоимостью, обнаружить резкое изменение покупательской активности или выявить возможный дубликат. Затем человек может просмотреть контекст, прежде чем предпринимать действия. Например, автоматизированная система может пометить постоянного клиента как неактивного, поскольку недавнего заказа не было. Торговый представитель может знать, что клиент разместил крупный годовой заказ шесть месяцев назад. Данные не бесполезны, но оповещению нужен контекст. Человеческая проверка работает лучше всего, когда система объясняет, почему она подняла флажок. Короткая заметка, такая как «в течение 90 дней не было зарегистрировано активности», дает рецензенту четкую отправную точку. ## Измеряйте точность, а не только скорость. Сэкономленное время легко отслеживать. Качество решений требует большего внимания. Я использую небольшой набор практических показателей: - Процент записей с заполненными обязательными полями - Уровень дублирования записей - Количество ручных исправлений - Точность оповещений - Время, затраченное на устранение исключения - Процент автоматизированных задач, требующих доработки человеком - Коэффициент конверсии после просмотра данных. Эти показатели показывают, помогает ли автоматизация команде или только быстрее устраняет ошибки. Например, розничная компания может автоматизировать оповещения о наличии товара в нескольких магазинах. Система может избавить персонал от необходимости проверять каждый товар вручную. Если коды продуктов в системах склада и магазина различаются, оповещения все равно могут быть неправильными. Отслеживание коэффициентов коррекции может выявить эту проблему до того, как она повлияет на решения о покупке. ## Тестируйте небольшим процессом Не рекомендую автоматизировать сразу весь отдел. Небольшой пилотный проект дает команде пространство для тестирования рабочего процесса, сбора отзывов и корректировки правил. Практический пилот может пойти по следующему пути: - Выберите один процесс с четкой бизнес-целью. - Запишите, как задача работает сегодня. - Выявление типичных ошибок и задержек. - Автоматизировать одну часть процесса. - Сравните новые результаты со старым методом. - Спросите пользователей, где рабочий процесс кажется неясным. - Обновите правила и задокументируйте изменения. Такой подход облегчает отслеживание проблем. Это также помогает пользователям завоевывать доверие посредством непосредственного опыта, а не обещаний. ## Анализируйте систему по мере изменения бизнеса. Поведение клиентов, линейки продуктов, цены и внутренние процессы со временем меняются. Процесс автоматизации, который хорошо работал в прошлом году, может не соответствовать текущим потребностям. Я планирую регулярные проверки: - Новые поля данных - Измененные этапы продаж - Обновленные правила утверждения - Неиспользуемые оповещения - Неудачные интеграции - Записи, которые не были обновлены - Решения, которые по-прежнему требуют слишком много ручной работы Обзор не должен быть большим. Короткая ежемесячная проверка может выявить неработающие ссылки, устаревшие условия и повторяющиеся исключения. Разумная автоматизация не означает, что все задачи выполняются без участия людей. Речь идет о создании надежного пути от данных к действию. Когда я определяю решение, проверяю данные, пишу четкие правила, проверяю людей и измеряю результаты, автоматизации становится легче доверять. Система выполняет рутинную работу, в то время как люди тратят больше времени на контекст, суждения и потребности клиентов. Этот баланс поддерживает более быструю работу, не рассматривая скорость как замену точности.

Многие команды собирают данные целый день, но все еще с трудом справляются с ними. На информационной панели могут отображаться продажи, посещения веб-сайтов, заявки в службу поддержки или статус доставки, однако цифры не всегда приводят к принятию более правильных решений. Я видел, как это происходит, когда компания проверяет отчеты раз в неделю, а поведение клиентов меняется каждый час. Товар заканчивается на складе до того, как команда это заметит. Кампания продолжает тратить деньги даже после падения результатов. Очередь в поддержку растет, а менеджеры все еще читают вчерашний отчет. Данные в реальном времени могут помочь, но только тогда, когда они связаны с четким бизнес-решением. Начните с решения Я не начинаю со списка инструментов. Начну с одного вопроса: «Какое действие должно измениться при изменении этих данных?» Команда розничной торговли может захотеть повторно заказать продукт, когда запасы достигнут заданного уровня. Маркетинговая команда может приостановить группу объявлений, когда цена за потенциального клиента превысит рабочий диапазон. Менеджер службы поддержки может назначить больше сотрудников, если неотвеченные заявки перейдут на выбранный номер. Этот вопрос держит проект в фокусе. Без этого компания может создать большую информационную панель, наполненную цифрами, которыми никто не пользуется. Выберите небольшую группу полезных сигналов Данные в реальном времени не означают, что каждое доступное число должно обновляться каждую секунду. Слишком большое количество сигналов может затруднить чтение информационной панели и замедлить принятие решений. Обычно я группирую данные по четырем областям: – Спрос: заказы, поисковые запросы, бронирования или посещения. – Эффективность: доход, коэффициент конверсии, время доставки или время ответа. – Риск: невыплаты, низкий уровень запасов, необычный трафик или рост количества жалоб. – Поведение клиентов: повторные посещения, брошенные корзины, запросы в службу поддержки или использование продукта. Каждый сигнал должен иметь четкую цель. Если метрика не поддерживает решение, я не учитываю ее до тех пор, пока не появится причина ее использовать. Например, небольшому интернет-магазину может потребоваться только текущий объем заказов, уровень запасов, ошибки оплаты и статус доставки. Этот набор может поддерживать ежедневные решения без создания перегруженной системы отчетности. Установите полезную частоту обновления Правильная скорость обновления зависит от бизнес-процесса. Платежной системе могут потребоваться данные в течение нескольких секунд. Склад может хорошо работать с обновлениями каждые несколько минут. Контент-команде могут потребоваться только почасовые данные о трафике. Ежемесячный отчет о планировании не становится более полезным только потому, что он обновляется каждую секунду. Я сопоставляю частоту обновления со временем, доступным для действия. Если команда не может ответить в течение пяти минут, пятиминутные обновления могут добавить шума, а не пользы. Соедините данные с действием Прямая трансляция имеет ограниченную ценность, если людям приходится смотреть ее весь день. Я предпочитаю связывать ключевые сигналы с оповещениями, списками задач или простыми рабочими процессами. Полезное оповещение должно объяснять: - Что изменилось - Почему это может иметь значение - Кто должен реагировать - Какие действия доступны - Когда оповещение должно прекратиться Слабое сообщение гласит: «Трафик ограничен». Более сильное сообщение гласит: "Посещения страниц товаров с мобильных устройств упали на 22% за последний час по сравнению с обычным диапазоном будних дней. Проверьте последний выпуск страницы и путь оформления заказа с мобильных устройств". Второе сообщение дает команде возможность начать. Это также сокращает время, затрачиваемое на поиск в нескольких системах. Проверьте качество данных Быстрые данные бесполезны, если они неполные, задерживаются или дублируются. Я проверяю источник каждой метрики и сравниваю его с другой надежной записью. В панели продаж может отображаться больше заказов, чем в платежной системе, если отмененные транзакции учитываются в одном месте, а удаляются в другом. Я также ищу: - Отсутствующие периоды времени - Повторяющиеся события - Различные настройки валюты - Различные часовые пояса - Задержки данных со сторонних платформ - Изменения в кодах отслеживания - Нечеткие определения показателей. Команды должны записать, что означает каждый показатель. «Активный клиент» может означать вход в один отчет и покупку в другом. Оба определения могут быть действительными, но их не следует смешивать. Используйте базовый уровень вместо случайной цели Для реального результата необходим контекст. Объем продаж может показаться низким по сравнению со вчерашним днем, но нормальным для того же дня недели. Коэффициент конверсии веб-сайта может упасть во время кампании, которая привлекает больше новых посетителей. Я сравниваю текущие результаты с соответствующими базовыми показателями, такими как: - Тот же день на прошлой неделе - Тот же час на протяжении последних недель - Нормальный диапазон для этого продукта или канала - Запланированное значение - Предыдущий период кампании. Базовый уровень должен поддерживать суждение, а не заменять его. Внезапное изменение может произойти из-за ошибки отслеживания, сезонной закономерности, обновления системы или искренней реакции клиента. Сохраняйте простоту информационной панели При создании интерактивной информационной панели я размещаю наиболее полезную информацию вверху: 1. Текущий бизнес-результат 2. Изменение по сравнению с выбранным базовым уровнем 3. Основная причина или затронутая область 4. Рекомендуемое действие 5. Владелец и статус Менеджер должен понимать ситуацию, не открывая несколько вкладок. Специалисту может потребоваться более глубокий взгляд, поэтому я создаю отдельную страницу с подробностями, а не размещаю каждое техническое поле на главном экране. Четкие этикетки также помогают. «Выручка сегодня» легче понять, чем «R1». Такое примечание, как «Данные обновляются каждые 10 минут», не позволяет людям воспринимать отчет как мгновенную запись. Пример: группа поддержки Представьте себе, что команда поддержки обрабатывает 2000 запросов каждую неделю. Его старый процесс проверяет размер очереди в конце каждого дня. К тому времени проблема с обновлением продукта могла привести к появлению большой группы похожих заявок. Команда может связать данные текущих заявок с тегами проблем, временем ответа и типом плана клиента. Когда одна проблема выходит за пределы нормального диапазона, система отправляет сообщение руководителю службы поддержки. Руководитель может сгруппировать связанные заявки, подготовить общий ответ и отправить команде продукта четкий отчет. Ценность исходит не только из информационной панели. Это достигается за счет сокращения времени между проблемой клиента и полезным ответом. Защитите данные клиентов и бизнеса Системы реального времени часто обрабатывают конфиденциальную информацию. Я ограничиваю доступ по ролям, удаляю ненужные поля и веду учет того, кто может просматривать или экспортировать данные. Командам следует избегать размещения полных платежных реквизитов, личных сообщений или личных идентификаторов на широкой информационной панели. Правила хранения данных также должны быть ясными. Хорошая отчетность способствует принятию более эффективных решений, не раскрывая больше информации, чем требуется для задачи. Проверяйте систему после запуска Проект с живыми данными требует регулярных проверок. Спрашиваю: - Люди пользуются приборной панелью? - Какие оповещения приводят к действию? - Какие оповещения игнорируются? - Есть ли какие-либо показатели, которые неправильно поняты? - Соответствует ли система бизнес-процессу? - Улучшаются ли решения или команда только следит за цифрами? Если предупреждение игнорируется много раз, возможно, пороговое значение неверно или получатель не является владельцем задачи. Если панель мониторинга открывается редко, информация может не соответствовать текущим потребностям. Я рассматриваю данные в реальном времени как систему поддержки принятия решений, а не украшение встречи. Самая сильная установка использует небольшой набор надежных сигналов, дает каждому сигналу четкого владельца и связывает изменения с практическими действиями. Когда данные точны и рабочий процесс прост, команды могут реагировать меньше догадок и лучше использовать уже собранную информацию. Мы имеем большой опыт работы в сфере промышленности. Свяжитесь с нами для получения профессиональной консультации: xuju: 741680083@qq.com/WhatsApp 13486753181.

1. Дж. Ли, Б. Багери и Х.А. Као — 2015 г. — Архитектура киберфизических систем для производственных систем на базе Индустрии 4.0 2. Х. Ласи, П. Феттке, Х. Кемпер, Т. Фельд и М. Хоффманн — 2014 г. — Индустрия 4.0 3. Международная организация по стандартизации — 2014 г. — Системы автоматизации и интеграция Ключевые показатели эффективности для части управления производственными операциями 2 Определения и описания 4. Национальный институт стандартов и технологий — 2018 г. — Структура улучшения кибербезопасности критической инфраструктуры, версия 1.1 5. У. В. Экерсон — 2010 г. — Панели мониторинга производительности для измерения мониторинга и управления вашим бизнесом 6. М. Д. Желваков и А. В. Сазонов — 2021 г. — Обработка данных в реальном времени и поддержка принятия решений в системах промышленной автоматизации