Быстрые победы реформирования функции ТОиР (технического обслуживания и ремонта)

Размещено на http://www.allbest.ru/

Быстрые победы реформирования функции ТОиР

Алексей Сулин

простой ремонт контроль экспертный

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

Вы спросите, почему попадает под сомнение вполне правильное и логичное начинание по «борьбе» с тем, что болит, с техническими простоями?

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

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

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

Вы спросите, почему я ставлю под сомнение вполне правильное и логичное начинание по «борьбе» с тем, что болит, с техническими простоями?

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

Реализовывая, участвуя, наблюдая за различными проектами повышения эффективности функции ТОиР, я был по обе стороны баррикад. С одной стороны, когда целей было много, причем все они правильные и достижимые в отдельности, система не взлетала. Не взлетала, потому что, когда система показывает более скромный эффект, чем ожидаемый, в нее перестают верить, и начинаются необдуманные шаги. Судорожное изменение подхода, стратегии, а порой и руководителя проекта… Я думаю, многие читатели понимают, о чем я. Хотя на самом деле необходимо лишь время, чтобы система «притерлась» и показала достойный эффект. С другой стороны, когда понятной цели нет вообще, показывать эффект от изменений просто бессмысленно. А что показывать? Чего хотели-то? Что-то происходит, что-то меняется, а хорошо это или плохо? Второй пример присущ большим компаниям либо компаниям с неправильной (с точки зрения лучших практик) структурой управления, когда у одного человека и производство, и логистика, и продажи, и юристы, и закупки -- и где-то там среди всего этого техническая служба. О каких четких целях можно говорить?

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

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

В правильно выстроенной системе учета простоев, организованной ручным способом, участвует не только техническая служба, но и операторы или мастера производства. Только производственный персонал всегда находится у единиц оборудования, только он может правильно зафиксировать время начала простоя и время появления ремонтного персонала. Если говорить об идеальной системе регистрации простоев, то она должна быть выстроена без участия человека в принципе, т.е. должна быть автоматизирована. Автоматизация системы учета простоев начинается с построения карты Шухарта для каждой единицы оборудования предприятия (рис. 1).

После того как мы разобрались с метрикой начального состояния функции ТОиР, с метрикой эффективности, мы должны определиться со стратегией реформирования функции. У нас традиционно два пути. Первый: мы можем глубоко погрузиться в теорию надежности, начать рассчитывать вероятность отказов, оценивать критичность оборудования, проводить различные анализы видов и последствий отказов критичного оборудования с целью определения стратегии ТОиР для каждого вида отказа, формировать технические карты обслуживания, выбирать для всего этого ERP/EAM систему, менять структуру управления функции ТОиР, подбирать квалифицированный персонал, обучать большую часть сотрудников предприятия и т.д. По сути, мы проходим такой же путь, который проходили специалисты, проектирующие это оборудование или производственную систему, ведь именно надежность определяет конструкторские решения. И это абсолютно правильный подход для достижения поставленной цели, но сколько стоит такой подход? А сколько он занимает времени? Сколько людей нужно вовлечь в этот процесс?

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

Рис.1. Пример карты Шухарта для анализа отклонений.

Дальше предприятие несет затраты на поиск этих самых создателей, нанимает их, т.е. также несет дополнительные затраты. Новые люди -- руководители, участники проекта -- измеряют начальную точку изменений, текущий уровень надежности при текущих затратах. А дальше уверенно уходят в теорию надежности. Что происходит с функцией ТОиР с точки зрения высшего руководства? Пока прорабатывается вся методологическая база, уровень надежности не меняется, точнее, меняется как в плюс, так и в минус, но средний тренд остается на прежнем уровне. А что с затратами? Нанять команду реформаторов -- затраты, автоматизировать систему простоев оборудования -- затраты, изменить структуру -- затраты, подобрать и внедрить ERP/EAM систему -- затраты, обучить текущий состав предприятия -- опять затраты. Т.е. спустя какое-то время (допустим, год) после начала реформирования функции ТОиР высшее руководство видит, что уровень надежности значительно не изменился, а уровень затрат на функцию ТОиР существенно возрос. Как долго будет продолжаться такой «эффективный» проект?

Конечно же мы с вами знаем, что все эти затраты в будущем окупятся многократно, но вряд ли удастся передать эту уверенность высшему руководству. Поэтому выбираем второй путь: мы должны разработать такой продукт, такую систему, которая в краткосрочной перспективе повысит надежность оборудования, пусть и с ростом затрат. Если говорить более подробно, формирование системного подхода, исходя из теории надежности, в краткосрочной перспективе приведет к росту затрат, а что же должно и способно повысить надежность в краткосрочной перспективе для соблюдения баланса? За свою практику я сформировал вполне понятный список простейших изменений функции ТОиР, приводящих к неплохим эффектам при правильном внедрении. Этот перечень можно назвать «Quick wins» или «Быстрые победы реформирования функции ТОиР».

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

Рис. 2 Причинно-следственная диаграмма (схема Исикавы)

А что дальше? А дальше необходимо выделить, согласно классификатору, повторяющиеся простои, выделить длительные простои и провести анализ случившихся отказов. Третья победа, наверное, самая существенная, -- это анализ технических простоев оборудования. Именно простоев, а не отказов, я имею в виду анализ как плановых, так и внеплановых простоев оборудования. Пусть это будет не что-то кардинальное, вроде FMEA-анализа, а анализ с использованием самых простых методов: «5 почему» для определения первопричины, диаграмма Ганта для анализа времени устранения отказа или времени выполнения планового обслуживания, диаграмма Исикавы для анализа ситуации с участием различных производственных служб, принцип Парето для статистического анализа, и т.д. Ведь в конечном итоге любой анализ должен ответить на два вопроса: что есть первопричина отказа и как сократить время устранения этого отказа в будущем. Логическим завершением анализа является формирование плана мероприятий, направленных на решение озвученных вопросов. Реализация этого плана, без сомнения, положительно повлияет на измеряемые показатели.

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

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

Время устранения отказа -- понятие достаточно емкое, начиная от вопроса «как измерить это время». Время устранения отказа начинается с момента остановки оборудования, вызова технической службы или прибытия на поломку сотрудника технической службы? А что считать временем окончания устранения отказа? Момент окончания ремонта или запуска единицы оборудования? А может, момент производства первой единицы качественной продукции? Так вот, на практике временем устранения отказа считают период от момента остановки оборудования до производства первой единицы качественной продукции.

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

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

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

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

Но как поступить, когда персонал, необходимый для устранения отказа, уже задействован на другой единице оборудования? Ему же не разорваться. Шестая победа -- это формирование картографии линии, определение приоритетного или, как в будущей основной системе мы это назовем, критичного оборудования. Единственное отличие от основной методологии определения критичного оборудования -- это критерии оценки. Определять приоритетное оборудование будем только по одному критерию -- производительность. Если произошел отказ линии с производительностью 10 единиц продукта в час, а ремонтный персонал в то же самое время занимается устранением отказа на линии с производительностью 5 единиц, куда нужно бежать? То же самое касается понятия «узкое место завода»: что бы ни случилось, неважно, в какой точке производственного потока, все требуемые ресурсы должны максимально быстро (а точнее -- согласно регламенту) отреагировать на отказ оборудования узкого места.

Хотел бы вернуться к фактам возникновения отказа. Разработать план корректирующих мероприятий и реализовать его -- это только полдела. Нам необходимо (седьмая победа!) стандартизировать процесс предупреждения первопричин отказов. Для этого мы начинаем формировать технические карты не по результатам FMEA анализа, в случае внедрения основной системы, а только по результатам проведенной аналитики, что потребляет гораздо меньше человеческих ресурсов. Технические карты классически разделим на две категории: осмотры и сами ремонтные операции, тем самым сформируем план ППР, подкрепленный четко сформулированным перечнем операций.

У многих главных инженеров, с которыми я взаимодействовал, возникал вопрос: не вызовет ли переход на плановый метод обслуживания (а план ППР, подкрепленный технической картой, это не что иное, как плановый метод обслуживания) увеличения штата технической службы? Нет! Большую часть технических карт из категории осмотров можно и нужно передать производственному персоналу, тем самым соблюдая баланс численности и ФОТ службы. Восьмая победа -- это формирование технических карт для производственного персонала. Всевозможные утечки, показания измерительных приборов, термодиагностика с использованием специальных красок, элементарная чистка оборудования -- все это уровень оператора.

В своей практике этот перечень «быстрых побед» я реализую параллельно с методологической проработкой концепции основной системы ТОиР. Конечный дизайн системы, естественно, различается между предприятиями, а список быстрых эффектов -- практически нет. Это позволяет соблюдать баланс между затратами и эффектами. Учитывая, что на разработку, обучение персонала и внедрение уходит не более 3 месяцев, считаю данный перечень начальной точкой любых реформ в функции ТОиР.

Восемь «быстрых побед» при реформировании системы ТОиР

1. Формирование системы учета простоев.

2. Определение начальной точки изменений по показателям надежности.

3. Анализ технических простоев оборудования.

4. Формирование графика ежедневных, еженедельных совещаний функции ТОиР.

5. Формирование регламента или процедуры информирования об отказе оборудования.

6. Экспертное определение критичного оборудования.

7. Стандартизация процесса предупреждения первопричин отказов.

8. Формирование технических карт для поддержания и контроля оборудования производственным персоналом.

Размещено на Allbest.ru