Реєстрація дефекту, замовлення на ремонт і облік використаних запчастин не були пов’язані одним документообігом, тому було важко відповісти на просте питання: на якому етапі перебуває конкретний автомобіль і скільки коштує його утримання наростаючим підсумком.
Управління автопарком • Впровадження ERP
Управління ремонтами власного автопарку в ERP-системі
У компанії з власним вантажним автопарком ремонт транспорту, технічне обслуговування, облік запчастин і трудовитрати механіків велися розрізнено, без зв'язку між зафіксованою несправністю, поточним ремонтом і майбутнім плановим ТО. Наша команда впровадила підсистему управління ремонтами на базі ERP-системи, яка об'єднала весь цикл і доповнила стандартну функціональність власною розробкою, відсутньою в типовій конфігурації: модулем «Рекомендації для автомобіля», що не дає загубитися жодній рекомендації механіка до наступного ремонту.
📋 Виявлені під час ТО дефекти
більше не губляться
🔧 3 моделі ремонту
в одній системі
💰 Витрати на ремонт
коректно накопичуються на об'єкт експлуатації
Ситуація замовника до проєкту
Ремонт вантажного транспорту охоплював кілька підрозділів одночасно: дефект фіксував механік, деталь замовляв інший відділ, ремонт іноді виконував сторонній підрозділ підприємства або підрядник, а витрати згодом потрапляли у фінансовий облік. Без єдиної системи кожен із цих етапів вівся окремо, без зв'язку між собою.
Без автоматичного розрахунку графіка ТО на основі пробігу та дати останнього обслуговування ремонт залишався реактивним процесом: підприємство реагувало на відмову вузла, а не запобігало їй плановим обслуговуванням.
Під час ТО чи поточного ремонту механік нерідко помічав дефект, який ще не був критичним, але вимагав уваги найближчим часом. Без окремого механізму фіксації такі спостереження або записувалися «на пам’ять», або губилися до моменту, коли проблема ставала серйознішою.
Оскільки облік ремонтних робіт не був інтегрований із фінансовим модулем, витрати на обслуговування транспорту було складно коректно розподілити по періодах і включити у вартість основних засобів для цілей амортизації.
Одне замовлення на ремонт зачіпало щонайменше чотири зони відповідальності: облік дефектів і об’єктів експлуатації, складський облік запчастин, виробничі потужності ремонтних підрозділів і фінансовий облік витрат. Кожна з них мала стати частиною одного документообігу, а не окремою ділянкою обліку.
Завдання та критичні вимоги
Запит передбачав побудову підсистеми управління ремонтами на базі BAS ERP, яка охоплює повний цикл — від фіксації несправності до розподілу витрат, — а також розробку власного механізму, що дозволяє не втрачати інформацію про рекомендовані, але ще не виконані роботи.
1. Наскрізний облік від дефекту до закритого ремонту
Кожна несправність має або закриватися на місці без залучення додаткових ресурсів, або перетворюватися на повноцінне замовлення на ремонт із трудовитратами, запчастинами і виконавцями — без розриву між цими двома сценаріями.
2. Розмежування власних і залучених виконавців
Система мала окремо враховувати роботи, виконані силами експлуатуючого підрозділу, і роботи, замовлені в інших ремонтних підрозділах підприємства або в сторонніх організаціях, з коректним розрахунком собівартості в обох випадках.
3. Нормування за типом транспорту і видом ремонту
Потрібен був єдиний довідник нормативів трудовитрат і запчастин, що враховує відмінність між регламентним ремонтом, ремонтом за технічним станом вузла і позаплановим ремонтом за потребою.
4. Автоматичне планування ТО за пробігом і часом
Графік технічного обслуговування мав формуватися розрахунково — на основі поточного пробігу, дати останнього ТО і середнього щоденного пробігу, — а не вестися вручну в календарі.
5. Збереження і повторне використання рекомендацій
Дефекти, виявлені під час ТО, але не усунуті одразу, мали фіксуватися в окремому механізмі й автоматично пропонуватися при формуванні наступного замовлення на ремонт того самого автомобіля.
6. Коректний облік витрат незалежно від тривалості ремонту
Оскільки ремонт вантажної техніки може тривати довше одного звітного періоду, витрати мали накопичуватися на об’єкт експлуатації наростаючим підсумком і потрапляти у фінансовий облік у момент їх фактичного списання.
Що і як наша команда зробила
Нормування трьох моделей ремонту в одному довіднику
Види ремонту в системі описуються не як довільний текстовий список, а в розрізі класів об’єктів експлуатації — у картці елемента довідника “Класи об’єктів експлуатації”.
Для кожного виду задається загальний тип ремонту (капітальний, поточний, ТО), нормативна тривалість, періодичність формування планів (щомісяця, щотижня, щодня) з горизонтом планування, необхідні матеріали й роботи, а також планова трудомісткість для робіт, виконуваних безпосередньо експлуатуючим підрозділом.
Це дало змогу закрити в одній моделі три принципово різні логіки ремонту:
◻ регламентний ремонт, що виконується з періодичністю, встановленою в експлуатаційній документації;
◻ ремонт за технічним станом, коли початок робіт визначається фактичним станом вузла;
◻ і ремонт за потребою — позаплановий ремонт після зафіксованої відмови.
Кожен клас техніки отримав власний набір нормативів, замість того щоб підганяти всі типи ремонту під один усереднений шаблон.
Планування технічного обслуговування: від пробігу до готового замовлення
Ми реалізували розрахунковий графік ТО: система визначає дату й пробіг наступного обслуговування на основі поточного пробігу, дати останнього ТО і фактичного середнього щоденного пробігу, залишаючи можливість ручного коригування.
Графік узгоджено з логістикою та виробничими потребами, а при настанні запланованої дати ТО замовлення на ремонт формується автоматично — з роботами з графіка, ще не усуненими дефектами і потрібними запчастинами. Ми також додали сповіщення про наближення дати ТО та календарну візуалізацію графіка, щоб відповідальні особи бачили завантаження ремонтних зон наперед.
Кастомний модуль «Рекомендації для автомобіля»
Ми розробили функціональність, якої немає в базовій конфігурації ERP-системи: механік під час ТО чи поточного ремонту нерідко помічає дефект, що ще не критичний, але вартий уваги, — і без окремого механізму фіксації ця інформація ризикувала загубитися до наступної, вже серйознішої, поломки.
Рішення складається з трьох пов’язаних об’єктів:
◻ форми внесення рекомендацій, що відкривається при підборі автомобіля в «Замовлення на ремонт» з візуальною позначкою наявних записів і можливістю одразу перенести їх у роботи й матеріали;
◻ регістру відомостей для зберігання даних — рекомендація, кількість, коментар, пов’язане замовлення, причина відмови, дата актуальності й виконання, автор, статус;
◻ та звіту з усіма актуальними рекомендаціями в розрізі автомобілів і термінів їхньої актуальності.
Ключове рішення для кастомного модуля
Система нагадує про рекомендації двічі: при підборі автомобіля в нове замовлення на ремонт і при закритті поточного. Це вбудувало рекомендації в щоденний робочий процес замість окремого архіву, про який потрібно згадувати самостійно.
Інтеграція з логістикою, виробництвом і фінансовим обліком
Замикає цикл рішення обміну даними між підсистемою ремонтів і трьома суміжними контурами. Саме ця інтеграція перетворює підсистему ремонтів із локального інструменту ремонтної служби на частину єдиного інформаційного контуру підприємства: дані про стан і вартість утримання кожної одиниці техніки доступні тим підрозділам, яким вони справді потрібні, без ручного перенесення між системами.
З логістикою
Інформація про час простою автомобіля на ремонті враховується при плануванні маршрутів і доступності транспорту, щоб ремонт не ставав несподіванкою для операційної діяльності.
З виробництвом
Потреба в специфічних деталях чи напівфабрикатах для ремонту автоматично перетворюється на замовлення виробничим підрозділам, з контролем стану виконання і готовності.
З фінансовим обліком
Витрати на обслуговування автоматично розподіляються за автомобілями, підрозділами і періодами та включаються у вартість основних засобів для цілей амортизації.
Результати
Дефект → рекомендація → план
Виявлені під час ТО дефекти більше не губляться: система автоматично переносить невиконані рекомендації в наступне замовлення на ремонт
3 моделі ремонту в одній системі
Регламентний, за технічним станом і за потребою ремонт нормуються за єдиними правилами в розрізі класів об’єктів експлуатації
Собівартість без розривів
Витрати на ремонт коректно накопичуються на об’єкт експлуатації наростаючим підсумком, навіть якщо робота триває довше одного звітного періоду
Рекомендації механіків
Спостереження, зроблені під час одного ремонту, більше не залежать від пам’яті конкретної людини — вони автоматично зринають при формуванні наступного замовлення на ремонт того самого автомобіля, з видимим індикатором прямо в документі.
Технічне обслуговування
Графік ТО більше не веде людина вручну в календарі — система розраховує наступну дату на основі пробігу й часу, узгоджує її з логістикою та виробництвом і автоматично формує замовлення на ремонт із потрібними роботами й запчастинами в момент настання дати.
Реєстрація та обробка дефектів
Замість єдиного сценарію “будь-який дефект — це ремонт” з’явилося розмежування на дефекти, що закриваються на місці, і дефекти, що вимагають повноцінного замовлення на ремонт — з можливістю аналізувати стан обробки дефектів у розрізі автомобілів і надсилати цю аналітику відповідальним особам на email.
Взаємодія підрозділів
Ремонт, що вимагає залучення інших підрозділів або підрядників, більше не “випадає” з-під контролю експлуатуючого підрозділу — собівартість таких робіт розраховується за загальними правилами й повертається в замовлення на ремонт автоматично.
Облік витрат
Витрати на ремонт коректно накопичуються на об’єкт експлуатації наростаючим підсумком незалежно від того, скільки звітних періодів триває робота, і включаються у вартість основних засобів — замість розрізненого обліку, прив’язаного лише до дати списання.
