Суть проблемы заключается в том, что у сложных систем больше условий, которые, в свою очередь, приводят к повышению вероятности возникновения ошибок. И каждое условие может иметь множество предпосылок. Система управления активами включает в себя три основные области, которые требуют постоянного внимания: программное обеспечение/данные, процесс/методика и роли/ответственность. У прогрессивных технологических процессов больше всего таких предпосылок. Наличие слабых мест в любой из этих областей может привести к ошибке в работе системы.
Ошибка системы обнаружена
С точки зрения шкалы зрелости ошибка в системе управления активами может означать, что ваша система просто находится на уровне ниже среднего. Симптомами этого могут стать плохое качество данных, недостаточность долевого участия, недостаточная подготовка пользователя и/или отчеты о минимальном размере добавленной стоимости. Это даже может означать, что ключевые показатели работоспособности разработаны плохо. В случае абсолютного провала переломный момент достигается сообществом потребителей тогда, когда они больше не считают, что система обладает какой-либо ценностью. Если руководитель высшего звена когда-либо делал такие заявления, как «Я не вижу ценности в этой системе. Я не могу получить желаемые отчеты. Это слишком дорого», — это и есть ключ.
Давайте обратимся к истории. При каждом внедрении чего-либо имеет место волнение на начальном этапе. Руководящий состав оплатил программное обеспечение и сейчас надеется на этом заработать. Менеджмент надеется использовать данные для принятия более взвешенных решений. ИТ-администрация требует более усовершенствованных технологий, для того чтобы они помогли ей в конфигурации системы, загрузке данных, и упрощения процесса интеграции. Опытные пользователи (например, сотрудники по планированию, начальники службы ТО) хотят использовать продукт с целью увеличения КПД трудовых ресурсов, получения оперативных отчетов и автоматизации ключевых функций. Рабочий персонал лишь хочет выполнять свою работу и документировать изменения интенсивности отказов во времени.
Все они хотят делать больше за счет меньших затрат. Итог: система не должна усложнять их работу, если только это не приносит выгоду.
Необходимо принятие решений
Но будут ли принятые решения верными? Во время подготовительных работ по запуску системы управления активами очень легко принять неверное решение. Сложные системы требуют экспертизы во время наладочных работ. Вы можете спросить членов ключевой группы об условиях, целях и возможностях, но они не всегда могут знать, что хотят. Они, может быть, купили лучший в своем роде продукт, потому что, видимо, надеялись, что он предоставит гибкие возможности, которые они хотели бы получить. Систему можно легко настроить после запуска, но некоторые решения бывает сложно отменить. Экспертиза часто нужна для того, чтобы помочь проектной группе определить конечную цель, спроектировать аналитические отчеты и разработать ряд действий для достижения этой цели.
Давайте поговорим об истории ошибок
Как мы уже говорили, специалисты по обслуживанию хотят записывать изменения интенсивности отказов во время работы. Это делается в интересах техников, и если актив опять даст сбой, они могут быстро обратиться к предыдущим событиям. Для техника хорошо записывать текстовую информацию (например, проводимые мероприятия, появившиеся проблемы и вышедший из строя элемент), но эти данные неприменимы на практике. Те сотрудники, которые хотят тщательно собрать информацию системы управления активами в рамках периодически возникающих проблем и злостных нарушителей, должны быть в состоянии выполнить команды на языке структурированных запросов (SQL). Рабочие данные — это подтвержденные данные, которые обеспечивают быструю работу аналитических отчетов и помогают принимать решения в индивидуальном порядке. Таким образом, в зависимости от того человека, с которым вы говорите, есть два определения «картины изменения интенсивности отказов во времени» – одно описывает текстовую информацию, второе основано на имеющих большое практическое значение данных.
У вас очень мало времени
Некоторые говорят, что рабочий персонал решает в течение первых пяти минут во время подготовки, будет ли система иметь ценность или нет. И когда система запущена, могут начаться жалобы, и если возражения не услышаны, не обсуждаются и не решаются ключевой группой, может появиться разочарование. Кроме того, если не придерживаться процедур обновления, база данных может быстро стать недействительной. И наконец, если руководству говорят, что аналитические отчеты невозможно подготовить, программное обеспечение нужно признать неоптимальным и слабым.
Эксперт КСУТО и бизнес. Роль аналитика
Эксперт компьютеризированной системы управления техническим обслуживанием (КСУТО) в значительной степени знаком с управлением рабочими заказами (например, определение очередности работы, распределение видов работ по категориям, управление запасами и планирование), надежностью работы активов (например, ошибка кодирования, неверный анализ; режим отказа работы, эффекты и критический анализ; установка программ профилактического/предупредительного технического обслуживания) и комплексным снабжением. Эксперт КСУТО в состоянии обсудить все вышеперечисленное, вне зависимости от марки программного обеспечения, и может говорить об индустрии в деталях.
Бизнес-аналитик составляет расписание регулярных встреч с рабочим персоналом для определения проблем, вопросов, жалоб, запросов и внесения предложений. Аналитик может их изучать при помощи системы и запрашивать необходимые отчеты. Бизнес-аналитик работает с вопросами по подготовке или проблемами скорости работы системы и может также проводить краткие тематические тренинги. Во время встречи аналитик может искать данные, хранящиеся за пределами системы управления активами предприятия, например, отчеты, висящие на стенах, сравнительные таблицы или информацию на бумажных носителях, находящуюся в кабинетах. В общем, бизнес-аналитик ищет ранние предупреждающие факторы возникновения проблем.
Каждая из вышеперечисленных ролей может иметь задачу составления аналитических отчетов и построения обучения. Плюс они могут быть вовлечены в периодический сопоставительный анализ. Часто эти две позиции признаются как позиции ценности в рамках зрелых организаций.
Руководство против ключевой группы
Слишком легко винить во всем высшее руководство. В этом случае ключевой группе следует принять полную ответственность за систему управления активами. Руководство должно давать полномочия в выборе программного обеспечения, предоставлять денежные средства и принимать решения по интеграции систем.
Однако ключевая группа должна быть вовлечена в процесс реализации и работы, включая пятилетний план КСУТО. Может понадобиться периодическое участие юриста организационной группы для разового решения возникающих проблем. Ключевой группе нужно, чтобы система соответствовала заявкам на расширение, изменениям в документации КСУТО, контролировала вопросы по управлению изменениями через бизнес-аналитика и отслеживанию необходимости в проведении обучения. На основании оценки вашей системы данные, которые вы прилежно заполняли в течение последних 15 лет, не представляют никакой ценности.
Есть и хорошие новости. Следующая модернизация займет у нас лишь время на консультацию для загрузки новой версии, конфигурации новых изображений и проведение обучения.
Типичная хронология
На рисунке изображен ряд событий и проблем, которые возникают после роспуска группы исполнения. Внутри пунктирной линии размещены позиции и роли, которые часто не принимают во внимание. Не каждая организация в состоянии соблюдать эти роли, но помните, что предметом данной статьи является «Почему после запуска системы не имеют успеха».
Смена кадров и коллективные знания
В каждой организации присутствуют кадровые ротации. Эта текучесть может иметь место среди персонала технического обслуживания, руководителей среднего звена и даже среди акционеров управления активами. Другими словами, эта война никогда не заканчивается. Для поддержания совершенства и использования оптимизированной КСУТО особое внимание необходимо уделить созданию истинной базы знаний для хранения порядка действия в случае необходимости ремонтных процедур, перечня запасных частей, договоров с продавцами и картины изменения интенсивности отказов во времени. Другие, более продвинутые техники включают в себя критерии ремонта/замены, обратную связь по заказ-нарядам, нивелирование состояния активов и определение отказавших элементов, наряду с кодами ошибок.
Анализ прошлых ошибок
Вы внедряете программное обеспечение или систему управления активами? Группы исполнения часто тяготеют к программному обеспечению, так как на рабочих совещаниях не все четко имеют представление о вопросах, касающихся определения концепций процесса управления активами, его целей и толкования. Проектные группы могут тратить дни на обсуждение иерархии кодов ошибок, но так и не определить параметры аналитического отчета или кому этот отчет нужно передать. Дополнительно к этому на этапе определения требований можно пропустить возможность усовершенствования. Не нужно полагать, что будет происходить непрерывный процесс модернизации.
После роспуска группы исполнения и ухода консультантов огромная нагрузка ложится на плечи оставшегося персонала. Возможно, фундаментальные данные все еще отсутствуют (например, спектр планов по организации работ). Или еще хуже, может быть, группа обеспечения надежности все еще изучает режимы работы при отказах для определения идеальной стратегии технического обслуживания (например, профилактическое техническое обслуживание, предупредительное техническое обслуживание и т.д.). Возможно, такие процедуры, как принятие решения по заказ-нарядам, не доведены до конца.
Поэтому именно в первые месяцы после запуска часто выявляется необходимость более тщательной подготовки специалистов. Вероятно, четырех часовых тренингов оказалось недостаточно. Некоторым для того, чтобы запомнить материал, требуется больше времени, но как только все получится и у этих сотрудников, они станут более вовлеченными в процесс, в том числе начнут требовать перемен.
Следует заметить, что может потребоваться целый год, пока организация не вступит в фазу спокойного рутинного процесса.
Как остановить ложные данные
Ключевая группа должна предвидеть возможность появления ложных данных на момент запуска. Это может произойти — и произойдет. В этом отношении можно составить план по профилактике, чтобы сказать:
- Используйте проверенные области. Устанавливайте обязательные к исполнению параметры, где это приемлемо.
- Определите роль «охранника» для оказания содействия стандартизированным обзорам поступающей работы.
- Убедитесь, что бизнес-правила понятны. Узнайте, кто отвечает за точность записей порядка работы при завершении задания. Создайте чарт ответственности и обязанностей сопутствующих ролей для обновления сведений по управлению активами.
- Определите слабые места в рабочем процессе. Это вопросы по подготовке, данные или изменение дизайна системы? Тесно сотрудничайте со службой эксплуатации. Выявите их потребности или обеспокоенность в рамках взаимодействия процесса управления активами.
- Проведите смешанный тренинг, на котором покажите программное обеспечение и объясните, почему эти данные необходимы. Это можно сделать в виде повторного инструктажа.
- Запустите проверку на ошибки для упреждения появления ложных данных. Даже в проверенных областях возможно появление ложных данных.
- Осуществляйте периодический технологический аудит с бизнес-аналитиком.
- Проводите регулярный обзор очереди работ по техническому обслуживанию. Выявляйте просроченные задания или повторяющиеся виды работ.
- Ключевая группа должна обрабатывать запросы на изменения и присваивать номера для отслеживания по авторам этих запросов в форме дефектной ведомости.
- Ложными данными могут также быть недостающие данные. Данные о неисправностях в качестве поля ввода данных могут просто отсутствовать на экране.
У разных групп разные потребности
Система управления активами не работает сама по себе. Ключевая группа должна отвечать за оптимизацию ценности системы и соответствовать запросам каждого акционера. ИТ-организация управляет всеми приложениями программного обеспечения и интеграцией в нем. ИТ-специалисты, однако, не должны отвечать за содержимое этих данных или процессы, происходящие вокруг.
Члены высшего руководящего состава должны получать информацию при помощи аналитических отчетов для принятия более выгодных решений. Для сохранения непрерывной модернизации они также должны развивать и поддерживать пятилетний план. Без имеющейся «дорожной карты» могут быть приняты неверные решения.
Акционеры, с точки зрения функционала, включая бизнес-аналитиков и экспертов КСУТО, отвечают за понимание текущего процесса и развитие прогрессивных технологических процессов. Без последних сложно получить реальный доход от инвестиций.
Значимость ключевой группы
Отсутствие ключевой группы всегда является индикатором №1 системы в сложном положении. Если в организации нет соответствующей ключевой группы, тогда кто представит все группы потребителей в нужном виде? Кто должным образом расставит приоритеты между запросами о внесении изменений? Кто задокументирует все эти изменения? Если у вас нет ключевой группы и вы полагаетесь только на одного человека, который управляет системой, то вы подвергаете базу данных риску. Очень редко ключевая группа реализует в полном объеме концепции при запуске, но все же ключевая группа также отвечает за ее сохранность в поле своего зрения. Ключевая группа предполагает звено, связывающее все разногласия воедино.
Вы не знаете того, чего не знаете
Лучший совет для любой организации, занимающейся внедрением системы управления активами, — тщательно отслеживайте данные, поступающие в течение первых 12 месяцев со дня запуска системы. Эта стратегия может помочь вам увеличить знания о запросах системы и потребителей. Второй совет — осуществляйте агрессивный сопоставительный анализ. Например, что делают другие организации для планирования работ? Какие приемы они используют для того, чтобы уменьшить оперативное техническое обслуживание? Как они составляют аналитические отчеты? Как они отслеживают уровень затрат на техническое обслуживание? Каким образом вы можете применить знания лучших практик? Сопоставительный анализ возможно сделать несколькими способами:
- самообучение при помощи книг, журналов и онлайн-форумов;
- посещение различных сайтов;
- общение с другими пользователями, например, на собраниях групп пользователей;
- консультационные службы.
Не позволяйте этому с вами случиться!
Если руководство постоянно запрашивает полный отчет, могут возникнуть проблемы. Если персонал технического обслуживания рассматривает систему управления активами только как временный инструмент внедрения, может возникнуть проблема. Если запасы материальных средств не подлежат планированию, между ними неверно расставляются приоритеты или им присваиваются некорректные статусы, может возникнуть проблема. Если в базе данных хотя бы раз будет допущена ошибка, ее будет чрезвычайно сложно наладить.
Таким образом, что вы в первую очередь станете восстанавливать — данные или процесс? Очевидно, вопрос чрезвычайно сложный и, бесспорно, уменьшит уверенность в системе. И когда данные искажаются, случается одно из двух:
- Руководство скажет, что продукт не работает, и может предложить отказаться от этого программного обеспечения.
- Руководство потребует обновить сервис и попросит команду по обновлению данных оставаться в стороне от мигрирующей информации.
Резюме
Итак, теперь вы знаете, почему системы терпят неудачи. Не позволяйте этому случиться с вами! Предугадывайте возможные проблемы и анализируйте, что произошло. Ищите истинную причину. Ошибка может появиться в организации на любом уровне или на любом этапе процесса. И здесь может быть много критических моментов. Но при наличии устойчивой системы управления активами вы можете предотвратить или, по крайней мере, подготовиться к ситуации «такое случается».
Журнал Prostoev.NET № 1(22) 2020
По материалам зарубежных публикаций
