Почему ПО для обслуживания часто проваливается — 4 экспертно подтвержденные причины

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

ПО для обслуживания и производства может быть так же раздражающим. Когда Брайан Сапот, CEO SensrTrx, спросил своих фолловеров в LinkedIn, почему отраслевое ПО может быть так раздражающим, ответ был недвусмысленным. Это зажгло более глубокий разговор о корневых причинах разочарования в ПО.

Мы сели с Брайаном Сапотом, Скоттом Декерами (директор по успеху клиентов Fiix) и Робом Калваровским (хост подкаста Rob's Reliability Project), чтобы разобрать проблему. Вы можете посмотреть полное видео ниже или скачать как подкаст. Ниже мы дистиллируем их топ-4 причины, почему ПО для обслуживания и производства может не оправдать ожиданий — и как избежать этих ям при выборе решения.

#1. Цель не определена

Что это значит

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

Что говорят эксперты

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

— Скотт Декера

Как исправить

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

1. Соберите кросс-функциональную команду и спросите их, какие вызовы они сталкиваются. ПО будет принято только если оно решает реальные болевые точки.
2. Примените анализ первопричин — продолжайте спрашивать «почему», пока не раскроете скрытую проблему.
3. Приоритизируйте проблемы, которые доставят наибольшее воздействие на людей и процессы.

Хотите пошаговый блупринт для поиска правильного CMMS для вашей команды? Скачайте наш глубокий гайд.

#2. Данные проблематичны

Что это значит

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

Что говорят эксперты

«Меньше — больше... Если вам приходится просеивать все эти разные метрики и все эти разные данные, чтобы попытаться найти что-то значимое, то у вас нет никаких значимых данных».

— Брайан Сапот

«Если вы не действуете над работой, не действуете над проектами улучшения, не используете данные для лучшей эксплуатации оборудования, то зачем беспокоиться? Как это улучшит ваши процессы? Что вы сделаете с этой информацией?»

— Роб Калваровский

Как исправить

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

1. Собираю ли я правильные данные? Дает ли это действенные инсайты?
2. Собираю ли я слишком много? Могу ли я найти то, что мне нужно за секунды?
3. Точны ли мои данные? Соответствует ли то, что я записываю, реальности, или это искажено плохими методами сбора?

#3. Buy-in отсутствует

Что это значит

Проект ПО проваливается, если энд-пользователи не на борту. Без вовлечения система либо используется неправильно, либо игнорируется.

Что говорят эксперты

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

— Скотт Декера

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

— Брайан Сапот

Как исправить

• Коммуницируйте личные выгоды: идентифицируйте болевые точки пользователя, покажите, как ПО их адресует, и подкрепите конкретными цифрами.
• Назначьте чемпиона: опытного пользователя, который может адвокатировать, troubleshoot и вести по примеру.
• Разработайте детальный план внедрения, уточняющий роли, таймлайны и ожидания.
• Инвестируйте в повторное обучение: люди забывают 75% того, чему научились, через шесть дней, поэтому планируйте постоянные рефрешер-сессии.
• Празднуйте победы: отслеживайте и делитесь каждой историей успеха для усиления ценности системы.

Посмотрите наш полный чек-лист пред- и пост-внедрения CMMS для построения вашего плана.

#4. Процессы с дефектами

Что это значит

Даже лучшее ПО может недоставить, если базовые процессы слабы. Например, CMMS может автоматизировать профилактическое обслуживание, но без follow-up процесса для проваленных задач программа рушится.

Что говорят эксперты

«Технология так же хороша, как системы под ней. Молоток не качает себя».

— Скотт Декера

«Вам нужно беспокоиться о том, делаете ли вы правильные процессы правильным способом, прежде чем беспокоиться об измерении их с ПО».

— Роб Калваровский

Как исправить

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

Готовы презентовать CMMS боссу? Используйте этот шаблон, чтобы сделать убедительный кейс.

Получите шаблон

Итог: ПО для обслуживания — не серебряная пуля

ПО — не проблема; отсутствие четких целей, слабые данные, недостаточный buy-in и дефектные процессы — это проблемы. Когда вы строите надежную систему поддержки вокруг технологии — четкие цели, твердая гигиена данных, вовлеченные пользователи и хорошо определенные процессы — вы раскрываете истинный потенциал ПО для обслуживания и производства для поднятия ваших операций.