В техническом руководстве к таким практикам

Ремонтировать, когда поломается

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

В те дни промышленность была не слишком сложной или механизированной. Простои не были серьезной проблемой, а предотвращение отказов не вызывало большой озабоченности. В то же время большая часть используемого оборудования была простой и, что более важно, оборудование было с большим запасом прочности. Это делало его безотказным и легко ремонтируемым. И большинство заводов работали без какого-либо превентивного технического обслуживания оборудования. Может быть, какая-то очистка, небольшое обслуживание и смазка, но это все.

Этот простой подход к техническому обслуживанию – «ремонтировать, когда сломается», часто называют техническим обслуживанием «первого поколения».

Все изменилось во время Второй мировой войны

Военное время повысило спрос на самую разнообразную продукцию. Однако в то же время предложение объема рабочей силы в промышленности сократилось. В центре внимания оказалась производительность. Также выросла механизация работ. К пятидесятым годам прошлого столетия все более сложные машины использовались практически во всех отраслях промышленности. Промышленность в целом стала зависима от машин.

И по мере роста этой зависимости все более важным становился вопрос сокращения простоев оборудования. Подход «ремонтировать, когда сломается» уже больше не устраивал промышленность. Возник акцент на предотвращении отказов оборудования. Умами стала овладевать идея, что отказы могут быть предотвращены с помощью правильного технического обслуживания в правильное время. Иными словами, промышленность двинулась от ремонтов по факту поломки (отказа) к превентивному календарному техническому обслуживанию. Ремонты и замены, выполняемые через фиксированные временные интервалы, стали нормой.

Этот подход к превентивному техническому обслуживанию известен как «второе поколение» технического обслуживания.

Больше технического обслуживания – больше отказов

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

После Второй мировой войны авиаперелеты стали широко доступными. Количество пассажиров быстро росло. К 1958 году Федеральное авиационное управление США (FAA) стало беспокоиться о надежности летательных аппаратов. А также о безопасности пассажиров.

В те годы преобладало мнение, что компоненты имеют конкретный фиксированный срок службы. И что эти компоненты выйдут из строя по достижении ими определенного «возраста». Замена компонентов до достижения ими этого «возраста», таким образом, предотвратит отказ. Именно так обеспечивали безотказность летательных аппаратов и безопасность пассажиров.

В пятидесятые-шестидесятые годы прошлого века обычный ремонт авиационного двигателя производился каждые 8000 часов налета. Поэтому, когда отрасль столкнулась с растущим числом отказов, вывод был простым. Очевидно, что срок службы компонента должен быть меньше 8000 часов – меньше, чем полагали ранее. Таким образом, техническое обслуживание стали выполнять чаще. Время между плановыми ремонтами было сокращено.

Просто, не правда ли?

Однако увеличение объема превентивных работ привело к трем весьма неожиданным результатам, которые в конечном счете перевернули мир технического обслуживания с ног на голову.

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

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

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

Рождение технического обслуживания, ориентированного на безотказность (Reliability Centered Maintenance – RCM)

Сказать, что результаты просто разочаровали как Федеральное управление гражданской авиации США (УГА), так и авиакомпании, было бы преуменьшением. Управление было обеспокоено, что безотказность не повысилась. А авиакомпании были обеспокоены постоянно растущими затратами на техническое обслуживание.

Поэтому в шестидесятые годы авиакомпании и УГА создали совместную целевую группу, чтобы выяснить, что же происходит на самом деле. После анализа данных за 12 лет целевая группа пришла к выводу, что плановые ремонты практически не влияют на общую безотказность или безопасность.

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

Более того, целевая группа выявила 6 моделей, описывающих взаимосвязь срока службы оборудования и отказа. И обнаружила, что большинство отказов происходят случайно и не связаны со сроком службы (возрастом) оборудования.

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

Первое руководство вышло в 1968 году под названием «Оценка технического обслуживания и разработка программ» (Maintenance Evaluation and Program Development). Это руководство часто упоминается под названием MSG-1 (Maintenance Steering Group – MSG, Координационная группа по техническому обслуживанию) и было специально создано для самолета Boeing 747-100.

График ТО самолета 747-100 был первым, в котором, используя MSG-1, были применены принципы технического обслуживания, ориентированного на безотказность. Было достигнуто сокращение затрат на техническое обслуживание на 25–35% по сравнению с предыдущими практиками.

Вскоре авиакомпании стали настаивать на удалении конкретного указания самолета 747-100 из документа MSG-1. Они хотели, чтобы графики обслуживания всех новых коммерческих самолетов разрабатывались с использованием того же процесса.

В результате был создан документ MSG-2, выпущенный в 1970 году под названием «Планирование программы технического обслуживания авиакомпаний/производителей» (Airline/Manufacturer Maintenance Program Planning).

Потрясающие результаты первых применений технического обслуживания, ориентированного на безотказность (RCM)

Переход к «третьему поколению», или на техническое обслуживание, ориентированное на безотказность, как указывалось в MSG-1 и MSG-2, был крайне важным.

Календарный график технического обслуживания самолета DC-8 использовал традиционные концепции «второго поколения» технического обслуживания. Он требовал ремонта 339 компонентов и устанавливал более 4000000 часов трудозатрат до достижения 20000 часов эксплуатации.

Сравните его с графиком технического обслуживания для самолета Boeing 747-100, разработанного с использованием MSG-1. Он требовал только 66000 часов трудозатрат до достижения тех же 20000 часов
эксплуатации!

Еще одно интересное сравнение – количество компонентов, требующих ремонта в заданное время. Техническое обслуживание самолета DC-10, разработанное на основе MSG2, требовало ремонта только 7 позиций против 339 позиций для DC-8.

И оба самолета, как DC10, так и Boeing 747-100, были больше и гораздо сложнее самолета DC-8.

Впечатляющие результаты. И министерство обороны США тогда думало так же.

Министерство обороны США включается в процесс

В 1974 году министерство обороны попросило компанию United Airlines написать отчет о процессах, используемых для создания программ безотказного технического обслуживания гражданских самолетов. И в 1978 году Стенли Нолан (Stanley Nowlan) и Ховард Хип (Howard Heap) опубликовали свой отчет. Он именовался «Reliability Centered Maintenance» – согласно ГОСТ-53480-2009 по-русски это звучит как «Техническое обслуживание, ориентированное на безотказность».

C тех пор было сделано очень многое для продвижения этой стратегии технического обслуживания. Авиационная отрасль перешла на MSG-3. В 90-х годах Джон Моубрей (John Moubray) опубликовал свою книгу RCM2, представляя концепции обслуживания, ориентированного на безотказность, для промышленности в целом.

В настоящее время техническое обслуживание, ориентированное на безотказность (RCM), определяется международными стандартами. Это была работа, проделанная в 60-х и 70-х годах, и она достигла своей высшей точки в докладе Нолана и Хипа в 1978-м, в котором можно проследить все современные подходы к техническому обслуживанию RCM.

Это было более 40 лет назад. Поэтому любой специалист по техническому обслуживанию и надежности должен быть знаком с этими работами. Это продолжалось достаточно долго. Это хорошо задокументировано. И широко доступно.

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

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

Одно из лучших изложений этих принципов можно найти в руководстве «NAVSEA RCM Handbook», опубликованном Управлением по разработке морских систем ВМФ США. Оно хорошо написано и доступно для понимания. И следующие принципы передового технического обслуживания в значительной степени построены на «Основах инженерного обеспечения технического обслуживания», описанных в руководстве Управления по разработке морских систем ВМФ США (NAVSEA).

Как профессионал в области технического обслуживания и безотказности вы должны понимать эти принципы. Вы должны использовать их на практике. Вы должны жить в соответствии с ними.

Принципы передового технического обслуживания

Принцип №1. Допускать возможность отказов
Принцип №2. Большая часть отказов не связана с возрастом оборудования
Принцип №3. Некоторые отказы имеют большее значение, чем другие
Принцип №4. Части не изношены, но оборудование ломается
Принцип №5. Скрытые отказы должны быть выявлены
Принцип №6. Одинаковое оборудование не означает одинаковое техническое обслуживание
Принцип №7. Вы не можете сделать больше, чем заложено производителем
Принцип №8. Хорошая программа технического обслуживания не тратит ваши ресурсы впустую
Принцип №9. Хорошие программы технического обслуживания становятся лучшими программами

1. Допускать возможность отказов

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

В других случаях влияние отказов невысокое, последствия незначительны, поэтому вы просто принимаете отказ.

Таким образом, хорошие программы технического обслуживания не пытаются предотвратить все отказы. Хорошие планы и программы технического обслуживания допускают некоторый уровень отказов и готовы иметь дело с отказами, которые они допускают (и считают вероятными).

2. Большая часть отказов не связана с возрастом оборудования

Как объяснялось выше, исследования, проведенные в авиационной промышленности, показали, что 70–90% видов отказов не связаны с возрастом оборудования. Более того, для большинства видов отказов вероятность их возникновения случайна. Более поздние исследования, проведенные ВМС США и другими организациями, показали очень похожие результаты.

Эти исследования суммированы в шести различных моделях отказов (см. табл.).

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

Не интерпретируйте кривые D, E, и F таким образом, будто некоторые изделия никогда не деградируют или не изнашиваются. Всё деградирует и изнашивается с течением времени, это жизнь. Но многие изделия деградируют настолько медленно, что износ не является реальной проблемой. Эти изделия просто не достигают зоны полного износа в стандартном эксплуатационном сроке службы.

Итак, что же эти модели рассказывают о программах безотказного технического обслуживания?

Исторически техническое обслуживание выполнялось исходя из того, что вероятность отказов увеличивается с течением времени (понимание технического обслуживания 1-ого поколения). Считалось, что своевременное техническое обслуживание может снизить вероятность отказов. Но оказалось, что для по крайней мере 70% оборудования это просто не соответствует действительности.

Для 70% оборудования, которое имеет постоянную вероятность отказов, нет смысла выполнять периодически задачи по продлению срока службы, такие как техническое обслуживание или замены.

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

На практике это означает, что от 70 до 90% оборудования выиграли бы от той или иной формы мониторинга состояния. И только 10–30% могут эффективно управляться с помощью периодических календарных замен или ремонтов.

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

3. Некоторые отказы имеют большее значение, чем другие

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

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

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

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

Точно так же, как не все отказы имеют одинаковую вероятность, не все отказы имеют одинаковые последствия.

Даже если это относится к одному типу оборудования.

Рассмотрим негерметичный (протекающий) резервуар. Последствия негерметичности (протечки) резервуара могут быть очень серьезными, если он содержит легковоспламеняющуюся жидкость. Но если резервуар наполнен питьевой водой, последствия могут быть не очень серьезны.

Просто, не правда ли?

Но что, если вода требуется для борьбы с огнем?

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

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

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

Программа технического обслуживания должна учитывать как последствия, так и вероятность отказов. И поскольку Риск = Вероятность x Последствия, мы можем сделать вывод, что хорошие программы технического обслуживания основаны на оценке рисков.

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

4. Части не изношены, но оборудование ломается

Часть изделия, или деталь, обычно представляет собой простой компонент, который имеет относительно малое количество отказов. Некоторые примеры – это зубчатый ремень в автомобиле, роликовый подшипник приводного вала, трос подъемного крана.

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

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

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

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

Большинство современных машин и механизмов состоит из многих компонентов, и их следует рассматривать как сложные изделия. Это означает отсутствие четко определенного срока службы до полного износа. А без четко определенного срока службы до полного износа выполнение привязанных по времени календарных ремонтов является неэффективной и бесполезной тратой ограниченных ресурсов.

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

5. Скрытые отказы должны быть выявлены

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

Скрытые отказы чаще всего связаны с оборудованием с функциями защиты. Чтонибудь вроде блокирующего устройства сверхвысокого давления. Защитные функции, подобные этим, обычно неактивны. Они должны срабатывать только в исключительных случаях для защиты людей от серьезного поражения или гибели и для защиты окружающей среды от серьезного воздействия или защиты активов организации от серьезного ущерба. Это означает, что на оборудовании с защитными функциями мы практически всегда выполняем задачи выявления отказов.

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

Нам необходимо выявить скрытые отказы и устранить их до того, как потребуется запуск оборудования в эксплуатацию.

6. Одинаковое оборудование не означает одинаковое техническое обслуживание

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

Классическим примером являются два насоса в компоновке «рабочий – резервный». Один производитель, одна модель. Оба насоса перекачивают совершенно одинаковую жидкость в одинаковых условиях эксплуатации. Но насос A – это рабочий насос, а насос B – резервный. Обычно эксплуатируется насос A. Насос B используется только тогда, когда насос A выходит из строя.

Когда дело доходит до видов отказов, насос B имеет важный вид скрытого отказа: он может не запуститься по запросу. Другими словами, когда насос A выходит из строя или же просто находится в процессе технического обслуживания, вы вдруг обнаруживаете, что насос B не запускается. Незадача.

Насос B обычно не эксплуатируется, так что вы не можете знать, что он не запустится, пока не попробуете это сделать. Это классическое определение вида скрытого отказа. И подобные виды скрытых отказов требуют задач выявления отказов, то есть вы идете и проверяете, запустится ли насос B. Но вам нет необходимости делать то же самое для насоса A, так как он всегда работает (если только он не выключен или не вышел из строя).

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

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

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

7. Вы не можете сделать больше, чем заложено производителем

Техническое обслуживание может только сохранять и поддерживать изначальную конструкционную (проектную) безотказность и эксплуатационные показатели вашего оборудования.

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

Чтобы повысить недостаточную по причине недоработок в конструкции безотказность или производительность, необходимо изменить конструкцию. Все просто.

Когда вы сталкиваетесь с отказами и дефектами, связанными с проблемами конструкции, то вам необходимо их устранить.

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

8. Хорошая программа технического обслуживания не тратит ваши ресурсы впустую

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

Очень часто мы можем услышать: «Пока сделаем это, давай проверим вот это… Это займет всего 5 минут».

Но 5 минут там, 5 минут здесь, каждую неделю, каждый месяц… И мы внезапно понимаем, что бесполезно потратили кучу времени. И не исключено, что заложили ряд дефектов, которые могут в конечном итоге повлиять на безотказность оборудования.

Другой источник ненужных трат ресурсов в наших программах – попытка поддерживать уровень производительности и функциональности, которые нам на самом деле не нужны.

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

Точно так же избегайте присвоения нескольких задач ТО одному виду отказа. Это нерационально и затрудняет определение действительно эффективной задачи технического обслуживания. Придерживайтесь правила одной эффективной задачи ТО для вида отказа.

Большинство организаций имеют больший объем работ ТОиР, чем они могут выполнить в связи с ограниченностью ресурсов. Используя ресурсы на ненужное техническое обслуживание, вы рискуете не выполнить необходимое. А невыполнение требуемого технического обслуживания или его выполнение позже требуемого срока увеличивает риск отказов.

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

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

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

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

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

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

В-третьих, увеличьте интервалы между задачами технического обслуживания. Делайте это на основе анализа данных, знаний и опыта операторовэксплуатантов и специалистов по ТОиР. Или просто на основании хорошей инженерной оценки. Не забывайте отслеживать результаты.

Чем короче существующий интервал, тем больше эффект при увеличении этого интервала. Например, при преобразовании ежедневной задачи в еженедельную требуемый объем работ по ТОиР для этой задачи уменьшается более чем на 80%.

Часто это самое простое и одно из самых эффективных улучшений, которое вы можете внедрить.

---

Журнал Prostoev.NET № 3(16) 2018

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

Руководство по эксплуатации помогает потребителю ознакомиться с техническими характеристиками приобретенного изделия и понять, как его правильно использовать. Вот почему любая компания – производитель технического оборудования разрабатывает данный документ в обязательном порядке. Целевой аудиторией документа являются не только активные потребители, но и сотрудники компании, в которой используется конкретное оборудование и др.

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

Рассмотрим, в каких случаях производитель использует вышеописанные документы:

• В случае необходимости отправить документ заказчику;
• Когда на подходе производство нового оборудования;
• Обеспечение сертификата, который необходим для оборудования;
• Для того чтобы ввозить оборудование или для таможенных процедур.

Принципы разработки руководства по эксплуатации (РЭ)

Руководство по эксплуатации в большинстве случаях разрабатывается на основе положений Государственного стандарта Р 2.601-2019. В ГОСТе представлено подробное описание документа, а также особенности его разработки и правильного оформления.

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

Руководство должно быть настолько информативным, чтобы максимально ясно ответить на любой интересующий вопрос потребителя. Кроме правил эксплуатации должны быть представлены условия хранения, нюансы по транспортировке и установке оборудования, а также особенности ремонта и обслуживания. Что касается планового обслуживания или ремонта, то они проводятся специальными сотрудниками, которые берут за основу руководство по эксплуатации.

В ГОСТе указано, что РЭ может быть доступно в электронном варианте. А это в свою очередь даёт возможность производителям добавить документ на сайт, дополнив его анимацией для более лёгкого восприятия пользователями. Согласно ГОСТу технический паспорт можно объединить с руководством по эксплуатации. А всё по причине минимальных отличий в содержаниях. Если компания-изготовитель  объединяет эти два документа в один, то и названием соответственно меняется на «Паспорт и руководство по эксплуатации».

Какие правила используются для разработки документа

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

 Инструкция должна быть составлена на языках стран, которые входят в состав ЕАЭС. Составляют такой документ либо изготовитель (по совместительству поставщик), либо специальные сотрудники сертифицированного центра.

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

Инструкция по эксплуатации

1. Вводная часть;
2. Отличительные особенности функционирования;
3. Использование по назначению;
4. Техническое обслуживание;
5. Работы по ремонту в текущее время;
6. Правила хранения;
7. Транспортировка;
8. Особенности утилизации.

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

Документы, необходимые для руководства

При разработке руководства по технической эксплуатации для документа предусматривается название и обозначение в буквенном или числовом виде. Пересматривается РЭ  примерно один раз в пять лет. Ведь документ считается действительным сроком до пяти лет. В случае, если в функционировании и использовании продукции не было никаких изменений, то срок действия руководства продлевается на такой же срок.

Руководство по использованию состоит из следующей документации:

• Технические документы рабочего плана;
• Схемы;
• Чертежи;
• Информация о техническом состоянии;
• Протоколы приёмки с итогами испытаний, которые были проведены;
• Сведения об уровнях мощности производства.
• Документы, необходимые для определённой техники в зависимости от особенностей.

Согласно требованиям государственного стандарта 2.601-2006 составление руководства по эксплуатации не является обязательным критерием для всех видов продукции. Нужна ли разработка документа определяет сам производитель изделий исходя из особенностей технического применения, наличия дополнительной информации для правильной настройки и других критериев. Однако в ГОСТе оговаривается, что в случае, если составление руководства по эксплуатации заказано со стороны Министерства обороны Российской Федерации, то именно данный орган и будет решать, необходимо ли разрабатывать соответствующий документ.

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

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

Более того, документ пригодится для того чтобы получить некоторые разрешительные документы:

• Руководство по эксплуатации может пригодиться для того, чтобы Ростехнадзор одобрил применение опасного и сложного оборудования. Речь идёт о тех случаях, когда наличие соответствующего разрешения является обязательным для выполнения определенных работ;
• Кроме того, данный документ может быть запрошен со стороны исполнителей с целью провести процедуру сертификации, которая необходима для конкретного вида оборудования.

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

Эффективное техническое руководство

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

Все компании разные, но между лучшими техническими руководителями, с которыми мне довелось работать, существует кое-что общее. Снимаю шляпу перед Брайаном Столером, Натаном Хантом, Эваном Гилбертом и Ричем Бердоном за то, что послужили мне хорошим примером.

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

Качества

Вы всегда должны улучшать три своих качества: компетентность, скорость и осведомленность.

1. Компетентность
Технические знания дают вам понимание и уверенность для принятия правильных обоснованных решений. Сильный технический руководитель обладает широкими и глубокими знаниями. Если какой-либо член команды спрашивает, как работает определенный компонент или система, вы должны уметь объяснить это достаточно подробно или направить к тому, кто может это сделать.

Чтобы оставаться компетентным, я делаю три вещи в следующем порядке:

1. Оцениваю код
2. Читаю проектную документацию
3. Пишу код (см. статью ABC: Always Be Coding)

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

Технический руководитель должен владеть несколькими технологиями. Например: Java, JavaScript, C++, распределенные системы хранения данных и веб-разработка на стороне клиента позволяют занять должность технического руководителя серьезного веб-приложения (подробнее о том, кто такой Full Stack специалист)

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

Я лично горжусь своей способностью быстро отвечать. Цель – казаться вездесущим своей команде. Мое секретное оружие – мои входящие письма, поэтому я предпочитаю использовать инструменты, которые тесно интегрируются с электронной почтой.

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

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

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

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

Функции

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

1. Блокировка
Блокировка требует высокого уровня осведомленности и распространяется как на принятие стратегических решений, так и на тактические задачи разработки. Технический руководитель должен всегда знать, что происходит в проекте, и всегда быть готов включиться и блокировать плохие решения до того, как они будут приняты, обычно путем предложения лучшего решения.

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

Блокировка не должна останавливать прогресс, она корректирует процесс, чтобы он не останавливался. Думайте о том, как сделать правильно изначально, а не как потом исправить.

2. Разблокировка
Противоположная блокировке разблокировка не менее важна. Дорога в ад выстлана бездействующими разработчиками. Если у кого-то есть вопрос, вы должны быть в состоянии или дать ответ или привести для этого правильного человека.
Мне помогло развить этот навык наличие практикантов. Лучшие практиканты задают очень много вопросов. И если они не получают ответы, они часто могут застрять или, еще хуже, опустить руки. Мне пришлось научиться давать правильные ответы или приводить их к людям, которые будут вести их вперед.

3. Перенаправление
Независимо от того, насколько вы хороши, вы не знаете всего. И вы не можете ответить на любой вопрос. И даже если бы технически вы могли это делать, практически все ваше время уходило бы на ответы на вопросы. Чтобы заполнить эти пробелы (и иметь возможность выполнять собственную работу), вы должны в уме составить список экспертов, чтобы всегда знать, где найти ответ. Изначальное и частое перенаправление – чрезвычайно полезная практика. Технический руководитель часто «человек 302» (или человек-переадресация), который соединяет людей. Если разработчик в вашей команде в чем-то не уверен или задает вопрос, на который вы не знаете точный ответ, понимание, к кому его нужно отправить, чрезвычайно ценно и экономит много времени.

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

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

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

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

1. Уменьшаю количество вариантов до 2. Сложность любой проблемы экспоненциально возрастает с каждым вариантом.
2. Быстро определяю, можно ли сделать оптимальный выбор на основании опыта или данных.
3. Если правильный ответ на этом этапе не является очевидным, можно ли перенаправить вопрос кому-то, кто больше подходит для принятия решения?
4. Если все еще нельзя сделать оптимальный выбор, тогда возможно недостаточно данных или задан неправильный вопрос. Я или блокирую принятие решения или разблокирую его, следуя инстинкту.

Вышеуказанные шаги необходимо мгновенно проходить в уме.

Качество решения подобно налету сокола в удачный момент, позволяющий ему сбить и убить свою жертву. – Сунь-Цзы

5. Демонстрация
Одним из самых важных качеств технического руководителя является способность демонстрировать на примере. Мы все слышали фразу «подавать пример», однако мне больше нравится показывать, а не говорить. Технический руководитель обычно не является менеджером, так как он сосредотачивает свою энергию на коде, а не на людях. Поэтому необходимо добиться уважения и доверия от своей команды, что лучше всего достигается демонстрацией того, что вы знаете свое дело.

Большинству руководителей может быть трудно находить время на написание кода, однако делать это очень важно. Я называю это «создавать время». Даже если я могу уделить совсем немного времени «черной работе» в виде устранения раздражающих ошибок или добавления кое-где по необходимости маленьких полезные кусочков кода, я буду это делать. Это более ценно для вас, чем сам код.

Действия

Ниже список того, что обычно делает технический руководитель для продвижения проекта вперед. Список этот далеко не исчерпывающий.

• Создает и поддерживает планы по разработке, тестированию и выпуску.
• Проводит эффективные совещания команды разработчиков.
• По необходимости обеспечивает полезность и лаконичность совещаний.
• Помогает обозначить и расставить приоритеты по проекту.
• Часто говорит «нет» новым излишним функциям.
• Определяет лучшие способы отслеживания решения проблем.
• Организует хакатоны и исправление ошибок.
• Поддерживает межфункциональные отношения.
• Определяет контрольные сроки.
• Следит за появлением полезных инструментов.
• Инструктирует других разработчиков.
• Нанимает разработчиков из других команд.
• Принимает практикантов, делает их успешными.
• Подробно оценивает код и оставляет полезные комментарии.
• Читает, пишет и комментирует проектную документацию.
• Пишет правильный код в правильное время.
• Защищает разработчиков от руководства, если необходимо.
• Работает с другими командами разработчиков, особенно зависимыми.
• Определяет технический долг.
• Объясняет, почему принимаются решения.
• Борется за правильные решения.
• Находит время на работу с техническим долгом.
• Распределяет нагрузку в команде.
• Принимает новых разработчиков и назначает разработчиков в качестве наставников.
• Корректирует курс и целевые даты по необходимости.
• Поддерживает определение минимальных жизнеспособных продуктов проекта.
• Оценивает архитектурные решения и их последствия.
• Обеспечивает написание тестов для основных функций.
• Поддерживает процессы по требованию и дежурные процессы.
• По необходимости поднимает блокирующие проблемы.
• Изучает проблемы конфиденциальности и безопасности продукта.
• Часто генерирует новые идеи и превосходные решения.
• Решает сложные производственные вопросы.
• … и так далее.

Установки, как стать успешным техническим руководителем, не существует. Лучшие из них являются продуктивными кодерами с огромным реальным опытом разработки продуктов. А теперь вспомните лучших руководителей, с которыми вы работали, и подумайте, насколько то, что вы прочитали выше, применимо к ним.

Будьте уверенны в себе, продолжайте двигаться и постоянно совершенствуйтесь!

Перевод выполнен в рамках летней школы стартапов Tolstoy Summer Camp.