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

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

Главный инженер не может доказать необходимость останова: истории отказов по объекту нет, значит нет аргумента. Останов не дают - отказ происходит сам, в худший момент и дороже. Цех уходит в тушение пожаров. Аварийный ремонт вытесняет плановый, плановый переносится, от переноса растёт аварийность. Это контур с положительной обратной связью: сам он не стабилизируется, а раскручивается. Персонал выводят в выходные. Выгорают не от объёма - объём выдерживается, если известен заранее. Выгорают от непредсказуемости, когда план работ живёт одну смену. И замыкается главное: люди уходят и уносят неформальное знание об оборудовании, то самое, которое подменяло систему. Текучка здесь не расход на подбор, а разрушение единственного работавшего механизма.

Почему не решается. У этих потерь нет владельца. Сверхурочные лежат в ФОТ, срочные закупки - в снабжении, недовыработка - в производстве, простой - в экономике. Строки «стоимость того, что система не управляет ремонтами» нет ни в одном бюджете. Расход не виден целиком никому и не является ничьей задачей. Дальше проблему переводят в проект - с бюджетом и вендором. Получается прототип без результата и ещё одна база, живущая отдельно от предыдущих. Через пару итераций у актива несколько неполных учётных систем и общая имитация управленческого контура. Проект при этом закрыт успешно, по акту.

Пять проверок. Полдня, стандартные отчёты, без консультантов. Доля заказов, не вышедших из статуса «создан». Пока заказ не деблокирован, резервирования и заявки на закуп из него не формируются - системной материальной потребности не существует. Распределение дат начала по дням месяца. Пик на первом числе - это не план, а месячная формальность. Процент заполнения трудоёмкости в заголовках. Около нуля - система не отвечает, сколько людей нужно на период, и разговор о дефиците ресурса идёт без доказательств. Доля сообщений об отказах со ссылкой на заказ. Единицы процентов - отказы и работы в разных вселенных: наработка на отказ не считается, критичность не ранжируется. Уровень списания против глубины дерева техмест. Дерево на восемь уровней при списании на цех - дерево декоративное, история по оборудованию не накапливается годами. Контрольный вопрос: плановые затраты по всем заказам за год поделить на фактический ремонтный бюджет. Если система видит меньшую часть денег - она не управляет ремонтами, а протоколирует их.

Принцип решения. Порядок обратный привычному: сначала дерево объектов реальной глубины, эталонные перечни операций и нормированная трудоёмкость - база, из которой план выводится расчётом. Система отражает это, а не заменяет. Последовательность «сначала внедрение, потом наполнение» не сходится никогда: наполнять некому и незачем, проект уже закрыт, а данные нужны сменному механику, которого в проект не звали. Денег это почти не требует. Требует нескольких месяцев методической работы, которую нельзя предъявить как результат до дня, когда бюджет впервые защищается составом работ, а не индексацией. — Строю системы ТОиР на непрерывных производствах и провожу диагностику уже внедрённого. Открыт к предложениям уровня главного инженера, начальника управления ТОиР, руководителя направления надёжности. #ТОиР #EAM #надёжность_оборудования