Как организовать учет обслуживания более 100 тыс. единиц подъемно-погрузочной техники в единой ERP-системе, если типовая функциональность не учитывает все особенности сервисного бизнеса? С таким вопросом столкнулась команда Axenix при замене зарубежной ERP для федеральной сервисной сети. Почему компания отказалась от внедрения отдельной системы ТОиР, какие механизмы пришлось разработать внутри «1С» и каких результатов удалось добиться, рассказывают Борис Пучков, руководитель направления по внедрению программных решений Axenix и Константин Овчинников, руководитель направления ТОиР, Корпоративные проекты, ГК «Софт-юнити».

Замена зарубежной ERP-системы для федеральной сети сервисного обслуживания подъемно-погрузочной техники помимо масштабов бизнеса и ограниченных сроков перехода осложнялась еще несколькими обстоятельствами.

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

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

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

Ключевым архитектурным вопросом проекта стал выбор: внедрять отдельную специализированную систему технического обслуживания и ремонта (ТОиР) или строить весь сервисный контур непосредственно внутри «1С:ERP». В результате мы остановились на втором варианте.

Логика выбора

  • Бизнес заказчика строится вокруг постпродажного обслуживания парка собственной и клиентской подъемно-погрузочной техники в рамках четырех моделей: плановое ТО по договору;
  • интервальный сервис;
  • подписка с фиксированной ежемесячной оплатой (поддержание в рабочем состоянии);
  • разовый ремонт (выезд механика с выставлением счета по факту выполненных работ).
Константин Овчинников
Константин Овчинников, руководитель направления ТОиР, Корпоративные проекты, ГК «Софт-юнити»

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

На этапе обследования рассматривалась возможность использования специализированного решения «1С:ТОИР». Однако от этого варианта отказались по двум причинам.

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

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

Поэтому было принято решение развивать сервисный контур непосредственно внутри «1С», объединив планирование обслуживания, выполнение работ и их финансовое отражение в одной системе.

Границы типового функционала ERP

Типовая «1С:ERP» уверенно решает задачи коммерческого, складского, производственного и финансового учета. Однако сервисное обслуживание представляет собой не набор независимых операций, а единый сквозной процесс, который объединяет все эти контуры.

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

Приведем пример. В процессах заказчика утвержденное КП должно становиться основой для документа «Заказ на ремонт» — своеобразного плана выезда инженера, где зафиксированы клиент, конкретная единица техники, плановый объем материалов и работ, а также сроки обслуживания.

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

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

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

Как был построен сервисный контур внутри «1С:ERP»

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

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

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

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

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

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

Вид обслуживания техники Коммерческое предложение Заказ на ремонт Сервисный отчет Продажа внутреннему клиенту Заказ клиента Комментарий
Плановое ТО по договору   + +   + Отслеживание межремонтного интервала техники, согласование с клиентом даты ремонта (возможен перенос), оплата ТО по фиксированной стоимости в договоре
Сервис по ежемесячной подписке     + +   Ремонт техники по заявке клиента, ежемесячная оплата услуг полного сервиса, получение оплаты за полный сервис сторонним подразделению, выставление затрат на ремонт стороннему подразделению
Ремонт по согласованной стоимости + + +   + Согласованная стоимость на дату коммерческого предложения
Ремонт по фактической стоимости     +   +  

 

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

Было – стало

Практика показывает — замена глобальной системы управления предприятием с большим объемом автоматизации занимает от года до полутора. Нашей команде из более чем 35 специалистов удалось выполнить проект за 4,5 месяца — от старта до запуска, затем ещё 2,5 месяца мы обеспечивали интенсивную поддержку и донастройку системы.

При этом на формирование критичных требований совместно с заказчиком ушло свыше 1100 человеко‑дней, а общие трудозатраты на разработку составили около 4000 человеко‑дней.

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

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

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

Выводы

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

Если обслуживание клиентской техники тесно связано с договорной работой, продажами, управлением запасами и финансовым учетом, использование отдельной системы может усложнить ИТ-ландшафт и потребовать дополнительных интеграций. В данном случае развитие сервисного контура непосредственно внутри «1С» позволило объединить эти процессы без создания самостоятельной системы ТОиР.

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