Как повысить культуру управления активами? Развиваем экосистему 1С:ТОИР. Монитор KPI, блок МТО, новое приложение для паспортизации

На партнерском семинаре в конце февраля был представлен доклад Андрея Серикова, руководителя направления разработки «Деснол Софт». Наша компания является идеологом, методологом и создателем экосистемы решений на платформе 1С для управления ремонтами и обслуживанием оборудования — 1С:ТОИР. О развитии этой экосистемы в 2021-м и о планах на 2022 год и пойдет наш рассказ. 

Вы можете прямо сейчас посмотреть видеодоклад или прочитать статью ниже. Вам решать. Слово — Андрею Серикову.

Баланс гибкости и простоты 

Общая цель нашей компании «Деснол Софт» — «Улучшить культуру принятия эффективных управленческих решений в бизнесе». Эта общая цель и формирует направление всей нашей работы, задает рамки и помогает определять приоритеты. Это прямо влияет и на то, как мы разрабатываем наши продукты.

Я уделю внимание одному аспекту, важному в нашей деятельности. Этот аспект — баланс гибкости и простоты в программном решении при равных возможностях.

image.jpg

У этого вопроса есть две крайности.

  • На одной стороне — назовем это «голый Excel» — таблицы с возможностью вводить формулы. Вы можете говорить: «Это решение может всё». Только тогда клиенту (пользователю) самому нужно придумать таблицы, заполнить их, написать формулы для расчета. При этом это почти бесконечная гибкость.
  • На другой стороне — конкретная реализация методики в программе, не допускающая ни одного шага в сторону. Примерно так, как сейчас устроены мобильные приложения — вам нужно делать одним «правильным» путем. Не нравится — ищем другое приложение.

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

Калькулятор KPI для повышения культуры управления активами

В 1С:ТОИР 2 КОРП есть достаточно мощная подсистема мониторинга показателей (KPI) для быстрого и наглядного просмотра важных показателей, характеризующих работу ремонтной службы.

Она состоит из трех больших элементов:

  • системы хранения внешних показателей,
  • конструктора показателей,
  • монитора показателей.

image.jpg

Этот инструмент решает более широкую задачу, чем просто отображение значений на дашборде. И сейчас я расскажу почему.

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

1. Механизм внешних показателей

Многие показатели, рекомендуемые консультантами в этой области для расчета, требуют данные, которые не хранятся в 1С:ТОИР 2 КОРП — например, общие затраты на производство, выручка от продукции, общее количество производственного персонала и даже количество бумажных документов. Часто это данные из бухгалтерской или ERP-системы. Причем из всех компонентов, нужных для расчета показателя, часть хранится в 1С:ТОИР, часть — во внешних системах. В итоге нет одного места, где можно было бы удобно рассчитывать эти KPI.

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

image.jpg

2. Всемогущий конструктор

Вторая проблема частично следует из первой. Нужна возможность создавать собственные показатели, которые могут получать данные из 1С:ТОИР, других внешних систем и даже из той информации, которую пользователи добавили сами, — в виде дополнительных полей или доработок конфигурации. 

Поэтому мы сделали всемогущий конструктор — он может брать любые данные из базы, внешние показатели, создавать показатели по формулам от других показателей. Может создавать показатели объектов ремонта, подразделений или целых организаций. Может создать анализ динамики, покомпонентного сравнения, сравнения с прошлым периодом или просто измерение состояния.

Мы готовились говорить, как в рекламе: «Теперь вы можете создавать свои показатели и совершенно «без программирования»! Мы предполагали, что достаточно будет предоставить мощный инструмент, с помощью которого каждый сможет настроить и отслеживать любые показатели…

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

image.jpg

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

3. Набор универсальных показателей

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

цели автоматизации процессов ТОиР.jpg

Когда эти цели были детализированы до задач и метрик, оказалось, что большинство из них удобнее анализировать не с помощью отчетов, а путем наблюдения показателей на дашбордах. Вот тут-то нам самим очень помогло наличие нашего инструмента для создания и мониторинга таких показателей!

По результатам этой работы были добавлены 22 новых показателя (всего их стало 29, поставляемых в коробке) и 5 новых отчетов.

показатели KPI.jpg

Этот инструмент помогает не столько при принятии решений, сколько при анализе последствий решений и наблюдении прогресса. Тем не менее, это прямо относится к нашей главной цели — улучшению культуры принятия управленческий решений.

Это нововведение позволило устранить перекос и найти баланс путем «комбинированного решения» — есть мощный конструктор и есть созданный на нем «стандартный набор» показателей.

МТО

Самым крупным нововведением 2021 года в 1С:ТОИР 2 КОРП стала переработка блока МТО.

Материально-техническое обеспечение занимает одно из важнейших мест в жизни ремонтной службы:

  • большую часть бюджета составляют именно запчасти и материалы;
  • отсутствие к сроку ремонта нужных материалов может нарушить все планы;
  • хранение материалов и запчастей требует финансов, человеческих ресурсов и помещений.

image.jpg

Всю деятельность по материально-техническому обеспечению можно разделить на несколько укрупненных процессов. Эти процессы МТО предназначены для обеспечения наличия требуемых ТМЦ для выполнения ремонтных работ хозспособом в нужное время в нужном месте.

Различные процессы могут выполняться как сотрудниками ремонтной службы, так и отдельной службой снабжения.

процессы МТО.jpg

Проблема баланса гибкости и простоты раскрылась в полной мере в этом вопросе.

  • С одной стороны, в блоке МТО нужны богатые возможности, которые могут потребоваться в работе реальных крупных предприятий.
  • С другой стороны, для конкретного предприятия блок не должен быть переусложнен. Он должен быть простым в использовании.

Чтобы найти правильный баланс, мы решили предложить два разных способа ведения МТО в 1С:ТОИР 2 КОРП:

  • блок внутри системы 1С:ТОИР;
  • обмен с 1С:ERP / 1С:УТ / 1С:КА2.
2 способа ведения МТО.jpg

Подчеркну, что внутренний блок реализует все основные процессы МТО и ограничен только тем, что использует исключительно внутренние данные системы 1С:ТОИР 2 КОРП. Те, кому нужно больше — например, использовать данные производства, закупок, бюджетирования и планирования, — могут использовать второй способ.

Внутренний блок МТО 

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

image.jpg

Слой 1. Функциональные возможности внутреннего блока

  • Фиксация плановой потребности в заказах на внутреннее потребление
  • Заказы поставщикам
  • Резервирование
  • Поддержание минимального складского запаса
  • Учет ТМЦ на складах и на руках
  • Инвентаризация

Это самый «низкий», технический слой. Он обеспечивает работу всех остальных.

Фиксация плановой потребности в заказах на внутреннее потребление

Что такое потребность? Как ее зафиксировать? Откуда вообще возникает потребность в материалах и запчастях?

Потребность характеризуется двумя составляющими:

  • что нужно;
  • когда нужно.

В системе ТОИР 2 КОРП часть «что» определяется:

  • в технологических картах в виде материальных затрат;
  • в объектах ремонта и типовых объектах ремонта в виде списка запчастей входящих в конструкцию.

Часть «когда» определяется размещением мероприятий в календарном графике. На нее влияют:

  • графики ППР;
  • графики регламентных мероприятий;
  • общий план работ подразделения;
  • остановочные ремонты;
  • закрытие заявок.

image.jpg

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

Нужно помнить еще, что все эти данные могут в любой момент измениться (если это не запрещено регламентами и не закрыто в системе). Да еще очевидно, что вручную собрать их не представляется возможным никак.

смета ремонта.jpg

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

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

заказ не внутреннее потребление.jpg

Благодаря тому, что вся сложность «спрятана» за фасадом простого заказа, в системе МТО правильно поддерживаются даже самые вычурные случаи. Например, в результате корректировки общего плана работ смещается срок одного из ремонтов с марта на апрель. А для этого вида ремонта с апреля должна действовать другая версия техкарты с другими летними материалами. Система правильно это учтет и поменяет потребности. При этом всё останется прозрачным и прослеживаемым. 

Коротко про остальные возможности 1-го слоя.

  • Заказы поставщикам позволяют учесть, что уже заказано и когда прибудет к нам.
  • Резервирование позволяет заблокировать материалы на складе под конкретный ремонт. Резервирование у нас тоже «умное» — нет необходимости вручную размещать и привязывать каждое поступление. «Программа сделает сама» — зарезервирует по потребностям по хронологии или с учетом критичности ремонтов.
  • Поддержание минимального складского запаса позволяет отслеживать и поддерживать наличие некоего постоянного уровня определенных материалов — например, для аварийных работ, или тех, чей расход достаточно регулярный.
  • Инвентаризация позволяет напечатать форму инвентаризационная описи ИНВ-3, отразить излишки и недостачи.

Слой 2. Процессные возможности

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

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

image.jpg

Слой 3. Инструментальные возможности

Третий слой — это материализованное решение задач предыдущего слоя с разбивкой по ролям. Именно здесь мы больше всего пытаемся «помочь» пользователям принимать решения эффективно.

Инструментальные возможности внутреннего блока (слой 3):

  • Рабочее место специалиста по обеспечению. Единое рабочее место для всех задач специалиста по обеспечению (иногда их называют инженерами по ТМЦ). Специалист видит: что, куда, когда нужно, сколько заказано, успеет ли приехать, может заказать то, чего не хватает. Может проверить, где еще лежит то что требуется и заказать перемещение. Видит хронологическую ленту ремонтов и отметки в ней, что уже обеспечено, а что нет.
  • Рабочее место «Передача на руки / возврат на склад». Единое рабочее место кладовщика. Видит и понимает, что есть, что отдано, что нужно и что можно отдать. Видит, что «осталось на руках». Система подсказывает, какие материалы нужно забрать, потому что они не списаны по акту.
  • СОЗ («Состояние обеспечения заказов»). Отчет и внутренний механизм, затрагивающий разные части системы. Показывает, какие заказы уже обеспечены (под них есть резервы). Нужен техническим специалистам. Подсказывает им состояние обеспечения и в их рабочем месте, и в конкретной смете.
  • Контрольная отчетность необходима для анализа и документального подтверждения. Здесь — разные отчеты и ведомости по наличию на складах и на руках.

Развитие блока не останавливается, в нем регулярно появляются новые возможности: последние изменения, которые вышли — учет сроков поставки материалов или резервирование с учетом критичности дефектов и объектов ремонта. 

Работа блока МТО совместно с 1С:ERP/1С:УТ/1С:КА2

Несколько слов о том, как работает блок МТО в 1С:ТОИР совместно с «1С:ERP Управление предприятием 2»/«1С:Управление торговлей»/«1С:Комплексная автоматизация 2».

image.jpg

Никакие рабочие места внутреннего блока при этом не используются. «Умные» заказы на внутреннее потребление передаются из 1С:ТОИР 2 КОРП в одну из систем и там фиксируют потребность в материалах и запчастях. Обеспечение потребностей и оперативный складской учет осуществляются целиком на стороне этих систем. Кроме этого, из 1С:ТОИР 2 КОРП передаются документы «Внутреннее потребление». В 1С:ТОИР 2 КОРП из 1С:ERP/1С:УТ/1С:КА2 загружаются только актуальные остатки по складам.

Мобильное приложение для паспортизации

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

При внедрении системы 1С:ТОИР 2 КОРП первым, и от этого наиболее сложным, является этап паспортизации. Чтобы все возможности системы раскрылись в полной мере, нужно, чтобы иерархия объектов ремонта была заполнена качественно, полно и достоверно. При этом крайне желательно, чтобы объекты были классифицированы и для них применялись общие нормативы.

Мы, как могли, старались помочь этому процессу инструментами — делали рабочие места, обработки загрузки из Excel, контрольные отчеты, даже вводили показатели для отслеживания хода и заполненности объектами. Тем не менее, всё равно чувствовали, что этого мало. Важная часть работы оставалась «за кадром», а система ждала уже готового результата, который должны были обеспечить ответственные сотрудники.

image.jpg

Мы занялись исследованием этого вопроса, провели ретроспективы прошедших проектов, изучили типичное положение вещей на предприятиях. Результатом стало видение возможного решения.

Его основные принципы:

  • Четкий, прозрачный и контролируемый процесс паспортизации
  • Помощь в наведении порядка (аудит и маркировка)
  • Мобилизация процесса
  • Интеллектуализация процесса
image.jpg

Весь процесс паспортизации представлен нами в виде четырех этапов:

1. Загрузка начальных данных из Excel. По сути, раньше это был почти единственный шаг, когда разрозненные табличные данные разных подразделений сливались в одно место.

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

3. Нормализация данных. Шаг, на котором проводится корректировка, классификация объектов ремонта. Добавляются нормативы и производится разузловка.

4. Данные передаются в 1С:ТОИР 2 КОРП.

image.jpg

Запуск и администрирование процесса производится в отдельном облачном решении:

  • Распределение выполнения работ между сотрудниками.
  • Еженедельное планирование количества объектов ремонта (ОР) по ответственным.
  • Мониторинг в реальном времени количество паспортизированных ОР.
  • План-фактный анализ ввода объектов ремонта.
image.jpg

Для этапа 2 создано простое в использовании мобильное приложение, которое нацелено на использование работниками даже с низкой компьютерной грамотностью.

Работа выполняется всего в 3 шага. Работнику достаточно:

1. Выбрать место проведения аудита.

2. Сфотографировать штрих-код (если его нет, про приклеить новый), шильдик и объект ремонта.

3. Ввести (если необходимо) 3 реквизита:

  • «Наименование»;
  • «Инвентарный номер»;
  • «Типовой объект ремонта».

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

mobile-1.jpg

mobile-2.jpg

Инструменты для нормализации данных еще активно разрабатываются, но мы уже разыскиваем предприятия или партнеров для пилотных проектов. Мы рассчитываем, что новые инструменты позволят гарантированно получать нужную достоверность и полноту данных паспортизации.

Коротко о важном и планах

Коротко об остальных важных изменениях в экосистеме 1С:ТОИР, если пропустили.

В системе «1С:ТОИР Управление ремонтами и обслуживанием оборудования 2 КОРП»:

  • обновлен интерфейс и появились новые иконки;
  • появился новый механизм скользящего планирования, который позволяет управлять датами ремонтов с разным горизонтом планирования;
  • в системе появилась возможность анализа коренных причин дефектов;
  • стал доступен инструментарий назначения на ремонт с учетом рисков — подбор критичности и дат устранения можно выполнить с помощью матрицы рисков;
  • разработан механизм ресурсного планирования работ подразделения — это дает возможность назначения исполнителей ремонтных работ с учетом их плановой доступности.

В системе «1С:RCM Управление надежностью»:

  • в «коробку» добавлена предиктивная аналитика (подробнее о предиктивной аналитике читайте  здесь).

В планах — выпустить подредакцию 1С:ТОИР 2 КОРП 2.1 со значительной переработкой внутренних механизмов хранения данных по ремонтам (для рабочего места технического специалиста), наследования нормативов, сбора плановых затрат по ППР и графикам регламентных мероприятий. Один из значимых плюсов — повысится производительность этих частей системы. 

Поделиться: