#Environment #Basics
Несмотря на то, что склады автомобильных запчастей в структуре организации чаще всего находятся где-то очень близко к функции сервисного обслуживания, на практике даже здесь не очень часто можно встретить уход за парком складской техники и оборудованием по лучшим стандартам автопроизводителей. Качество работы от площадки к площадке отличается значительно и в основном зависит от персональных качеств конкретного сотрудника, в чьи обязанности входит контроль ремонтов и технического обслуживания (часто координацией этой работы занимается непосредственно начальник склада).
В практике очень немногих организаций принято включать в штат механиков или инженеров, которые имели бы глубокую экспертизу в части устройства грузоподъемных машин и механизмов. В основном обслуживанием техники занимаются сторонние подрядчики (дилеры или просто сервисные партнеры). Зачастую, сотрудничество ограничивается регламентными работами и реагированием на инциденты. Практически никто не озадачивается какими-либо мерами превентивного обслуживания и уж тем более не имеет программ планирования жизненного цикла оборудования.
Не уходя пока в совсем уж продвинутые техники progressive maintenance и лучшие практики, реализуемые в рамках социо-инженерных систем Toyota или P&G, хотелось бы все-таки поговорить о важности формализации процесса работы с дефектами оборудования. Как и с любыми другими повторяющимися операциями на складе, работа с обслуживанием и ремонтом механизмов требует алгоритмичности. Проще говоря, на любой площадке обязательно необходим процесс выявления и работы с дефектами оборудования. И разумнее всего не ограничивать инициативу исключительно одним ответственным, а передать ее непосредственно операторам.
Когда любой оператор может инициировать работу с дефектом оборудования, появляется поток заявок, администрировать которые может быть достаточно трудоемко. На этом этапе обычно возникает желание автоматизировать процесс: внедрить IT-систему, дать к ней доступ всем стейкхолдерам и «упростить» контроль. Поскольку на систему необходим ресурс, а кроме потенциального порядка экономического эффекта за такой системой не просматривается, идея обычно тихо умирает. И в силу приоритетности автоматизации, и в силу сложности обоснования бюджета.
На практике же процесс и автоматизация – это независимые слагаемые. Процесс может абсолютно беспрепятственно функционировать в неавтоматизированном виде, и даже разумнее первоначально выстроить его именно таким, чтобы иметь возможность легко оптимизировать без доработки IT систем. Иногда кажется, что простой процесс можно не описывать и уж тем более нет смысла обучать тривиальным вещам исполнителей. Но практика подсказывает, что делать это нужно обязательно, и даже в самом линейном процессе есть множество разных способов отклониться от логики и получить непрогнозируемые последствия.
Для работы с дефектами можно разработать простую бумажную форму с возможностью вносить туда информацию для всех участников процесса и описав последовательность шагов. Объяснить процесс сотрудникам, назначить администратора и включить отслеживание прогресса по работе с дефектами в KPI смены – это необходимый минимум. Он позволит получить значимый эффект от упорядочивания всех тех действий, которые так или иначе все эти сотрудники выполняют регулярно, хоть, зачастую, и нескоординированно.
Пример процесса по работе с дефектами в общем виде представлен на схеме 1.
