Как построить правильные измерители успешности бизнес-процессов в сфере ТОиР?
Программное обеспечение Программное обеспечение

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

Главная>Программное обеспечение>Как построить правильные измерители успешности бизнес-процессов в сфере ТОиР?
Программное обеспечение Тема номера

Как построить правильные измерители успешности бизнес-процессов в сфере ТОиР?

Дата публикации:
04.10.2011
Посетителей:
312
Просмотров:
273
Время просмотра:
2.3

Авторы

Автор
Дмитрий Казанский В прошлом - начальник отдела решений EAM компании «Инфосистемы Джет»
Эта статья содержит некоторое число дискуссионных моментов, поэтому мы будем рады возможности их разностороннего обсуждения в будущем.

 

 

Сначала поговорим о базовых вещах. Нам часто необходимо приводить абсолютно разные понятия или ситуации к такому виду, чтобы их можно было сравнивать. То есть мы вынуждены подбирать для них общий измеритель. Обычно таким универсальным измерителем является термин «хорошо»: какая из сравниваемых ситуаций лучше, ту и выбираем. В свое время был популярен шуточный вопрос, не исключено, что многие его еще помнят: каких раков лучше брать – мелких, но по 3 рубля, или крупных, но по 5? Мучениям выбирающего, как я помню, не было конца…

 

Когда несравнимое в ТОиР станет сравнимым, можно будет начинать менеджерскую деятельность».

 

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

«Дешевле, но похуже» – это только один из многих случаев. «Быстрее, но дороже», «помедленнее, но побольше», «дешевле, но без гарантии», «хорошо, но медленно» – в реальной жизни мы на каждом шагу сталкиваемся с проблемой правильной свёртки. Мы размышляем, что будет лучше: одно (с соответствующими обременениями) или другое (тоже с сопутствующими проблемами)? При этом сравниваемые свойства не получается разумным образом оцифровать, можно лишь интуитивно наделить их степенью «хорошести».

 

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

 

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

 

Управленческое решение – это чаще всего ответ на некую ситуацию выбора, которая имеет сложные, часто противоположные квалифицирующие признаки (уже упомянутые «дешево, но без гарантии» против «долго, нудно, зато навечно»).

 

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

 

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

 

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

 

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

 

Собственно, о KPI** для ТОиР

 

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

 

«Для измерения качества управленческого решения очень важна фиксация конкретного контекста, в котором происходило его принятие».

 

Мы, «по-менеджерски» размышляя о возможных путях развития ТОиР, сталкиваемся с двумя подходами:

 

  1. Проведение планово-предупредительных ремонтов (ППР), что, тем не менее, не застраховывает предприятие от возникновения аварий на 100%. Это особенно очевидно на примере электросетевых компаний. ППР иногда считают не самым лучшим способом действия, поскольку недопущение – это «несуществующие» деньги для руководства предприятия. Многие полагают: для чего тратить средства на недопущение того, что может случиться, а может – нет. При этом вариант ППР хорош для экономистов по причине формирования прогнозируемых бюджетов.
  2. Создание аварийного запаса (АЗ) деталей и запчастей на складах. С применением подобной практики процесс ТОиР сильно упрощается: в случае необходимости взял деталь со склада и поставил ее на объект. При этом деньги, вложенные в АЗ, «замораживаются», но появляется возможность быстрого реагирования на аварию. Подход «ждем аварии, потом ее быстренько устраняем» делает жизнь проще, хотя бы не нужно обосновывать бюджет: в том году израсходовали «Х», и в этом будет та же сумма плюс коэффициент инфляции. Но подобная «система реагирования» несколько ухудшает экономические параметры предприятия и печалит экономистов.

 

Здесь остро встает проблема выбора стратегии, схематично озвученная выше: «быстро, но дорого» или «хорошо, но медленно». Лишь после принятия этого решения можно начать размышлять о KPI. При этом нужно понимать, что правильные измерители невозможно построить в реальности, в которой «быстрое реагирование» считается лучшим способом действия, чем «недопущение».

 

ТОиР как определенный вид деятельности управляется людьми гораздо в большей степени, чем формальными алгоритмами. Это может нравиться или не нравиться, но специалистам, которые проектируют и продают ИТ-сервисы для ТОиР, лучше признать этот факт. Поэтому мы и описываем стандартную управленческую ТОиР-дилемму «делаем выбор "X", но при этом возникает проблема "Y"».

 

Учет возможных позитивных и негативных последствий принимаемых решений – вот на что должны быть направлены ИТ-сервисы, и тогда они будут реально востребованы людьми. При этом ни одна ЕАМ-система не может предложить внятного ИТ-сервиса для учета таких последствий. Включать или не включать конкретный актив в план – подобное решение всегда остается вне системы. Правильно ли это? Способствует ли широкому продвижению ЕАМ-систем? Согласитесь, момент явно спорный.

 

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

 

«Недопущение поломки оборудования – это «несуществующие» деньги. Многие думают: для чего тратить средства на недопущение того, что может случиться,
а может – нет».

 

Грамотно выстроенная система KPI, учитывающая особенности именно этого, а не другого, абстрактного предприятия, позволяет:

 

  • сократить потери продукции, вызванные необходимостью остановки оборудования на период ожидания и выполнения ремонта;
  • сократить отклонения от производственных графиков. Обычное «сокращение простоев» уже мало кого интересует, т. к. существуют производства, располагающие оборудованием, которое используется только для вполне определенных заказов. Поэтому можно неторопливо обслуживать технику, не задействованную в исполнении текущего заказа, но при этом добиваться максимальной готовности для критичного оборудования. Резонно использовать и MTBF, но с ранжированием по видам оборудования;
  • сократить непредвиденные закупки. Это означает переход на ППР и уход от АЗ и реагирования по ситуации;
  • оптимизировать складские запасы. Раньше склады предприятий были забиты товарами народного потребления, сейчас маятник в промышленности качнулся в другую сторону: часто распродают даже то, что реально нужно для производства и его восстановления в случае аварии.

 

Вывод относительно KPI для ТОиР довольно парадоксален. С учетом того, что было сказано в начале этой статьи, получается, что успешность работы менеджера в сфере ТОиР – вещь плохо алгоритмизируемая. Во втором разделе статьи мы показали, что попытки предложить ту или иную характеристику для работы оборудования (например, MTBF – Mean time between failures, среднее время между отказами) также затрагивают только вершину айсберга. В любом случае нужно понимать, какие именно бизнес-процессы создают этот MTBF на конкретном предприятии. Обобщенно декларировать любой параметр KPI – обречь его на существование «в воздухе», когда он не будет опираться на ежедневные бизнес-процессы реального предприятия. Таким образом, единственный способ построить адекватный измеритель – это учет особенностей конкретного предприятия при внедрении системы KPI.

Уведомления об обновлении тем – в вашей почте

Обучение персонала в процессе внедрения

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

Некоторые аспекты внедрения EAM-систем

До настоящего времени нет единого мнения о сути внедрения. Это больше организационный или инженерно-технический процесс (внедрение-как-программирование vs внедрение-как- консалтинг)? Ответа нет.

«Командный зачет»

Для составления полной картины о функционировании системы IBM Maximo необходимо рассмотреть возможность и степень ее совместимости с другими приложениями, которые установлены на предприятии.

EAM-система как эффективный инструмент для работы

На сегодняшний день и производственники, и ИТ-специалисты крупных предприятий уже ориентируются в назначении EAM-систем. Но по-прежнему остается открытым вопрос: как внедрить EAM-систему, чтобы добиться желаемых результатов и сделать ее применение действительно полезным?

Интервью с Иваном Шиловым, ведущим специалистом по развитию бизнеса IBM Maximo компании IBM EE/A

При всех безусловных достоинствах EAM-систем реализованные в этой сфере проекты в России пока исчисляются единицами. Чем обусловлена сложившаяся ситуация, и когда можно ожидать ее кардинального изменения? Как можно охарактеризовать российский рынок EAM-решений? Свое мнение высказывает Иван Шилов, ведущий специалист по развитию бизнеса IBM Maximo компании IBM EE/A.

Работа с системой IBM Maximo: легкость, приносящая результаты

На IT-рынке в области управления ремонтом и техническим обслуживанием производственными активами существует множество ЕАМ-систем, позволяющих решать данные задачи.

Пытаясь взглянуть назад..

Помня о бритве Оккама, компактно обсудим, к чему мы пришли в процессе рассуждений на тему управления активами. Информационное обеспечение для успешного ведения необходимой технологической деятельности индустриальным предприятием зиждется на трех китах - ERP-, EAM-, SCADA-системы (возможны небольшие вариации).

Спасибо!
Вы подписались на обновления наших статей
Предложить
авторский материал





    Спасибо!
    Вы подписались на обновления наших статей
    Подписаться
    на тему







      Спасибо!
      Вы подписались на обновления наших статей
      Оформить
      подписку на журнал







        Спасибо!
        Вы подписались на обновления наших статей
        Оформить
        подписку на новости







          Спасибо!
          Вы подписались на обновления наших статей
          Задать вопрос
          редактору








            Оставить заявку

            Мы всегда рады ответить на любые Ваши вопросы

            * Обязательные поля для заполнения

            Спасибо!

            Благодарим за обращение. Ваша заявка принята

            Наш специалист свяжется с Вами в течение рабочего дня