Почему инженеры ненавидят простои (и как мы это исправляем)

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

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

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

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

Ссылки Международная организация по стандартизации, 2018 г., ISO 55000. Обзор принципов и терминологии управления активами. Международная организация по стандартизации, 2014 г., ISO 55001. Требования к системам управления активами. Министерство энергетики США, 2010 г., Руководство по передовому опыту эксплуатации и технического обслуживания, выпуск 3.0. Джон Д. Кэмпбелл, Эндрю К.С. Джардин и Джоэл МакГлинн, 2011 г., Оборудование для оптимизации управления активами Решения жизненного цикла Джон Мубрей, 1997 г., Техническое обслуживание, ориентированное на надежность, Национальный институт стандартов и технологий, 2018 г., Структура улучшения кибербезопасности критической инфраструктуры, версия 1.1