Аварійні ремонти

Причини:

Ремонт коштував 15 000 грн.; Коли сталася аварія?; Тоді аварійний ремонт стає не пожежним хаосом, а частиною системного керування надійністю.; Якщо критична запчастина коштує 500 грн, а простій без неї — 50 000 грн на годину, економія на складі запчастин виглядає дуже творчо.; |- | Найкраща практика | ERP, історичний розвиток обладнання, складський облік запчастин, SLA, Power BI, MTTR, MTBF і аналіз кореневих причин.; !; Плановий ремонт

Діагностика аварії

],

!; |- | Що це?; Критерій Power BI сприяє аналізувати аварійні ремонти.; Якщо ремонт не записаний, для аналітики його не існує.; # Коренева причина проаналізована.; # Об’єкт ремонту вказано.; Чому?; Приклад:

Об’єкти аварійного ремонту

Аварійний ремонт і підрядники

|- | P1 Критичний | Повна зупинка критичного процесу або ризик безпеці | Зупинка виробничої лінії | Негайно |- | P2 Високий | Значний вплив на роботу | Не функціонує один із ключових верстатів | оперативно |- | P3 Середній | бізнес-процес функціонує з обмеженнями | Обладнання функціонує повільніше | За чергою |- | P4 Низький | Немає критичного впливу | Пошкоджений корпус, але функція функціонує | Планово |}

</syntaxhighlight>

3.; Хоча гроші й час він з’їв цілком реально.; Виконавець

 ↓

Запчастини резервуються зі складу
[[Категорія:Сервісні заявки]]
Чим нижчий MTTR, тим швидше організація відновлює обладнання.; Списання на ремонт

== Помилка: не рахують вартість простою ==

Краще:

* об’єкт;
* серійний номер;
* місце;
* характеристика дефекту;
* причину;
* фото;
* потрібні роботи;
* потрібні запчастини;
* відповідального;
* рішення для бізнесу;
* дату.; характеристика
Поганий бізнес-процес:
Скільки коштує ремонт?;<syntaxhighlight lang="text">

!; Сума

Аварійний ремонт відповідає на питання:

== MTTR ==

Скільки триває простій?;<syntaxhighlight lang="text">

== Запчастини для аварійного ремонту ==

== Причини аварійних ремонтів ==

* ремонт спеціалізованого обладнання;
* гарантійний ремонт;
* складні електромонтажні роботи;
* сервіс холодильного обладнання;
* ремонт транспорту;
* ремонт серверного обладнання;
* калібрування;
* сертифіковані роботи.; ↓
{| class="wikitable" style="width:100%;"

Причина: зламалося.; Чому подавали більше?;== Повторні аварії ==
[[Категорія:Підрядники]]
Типовий бізнес-процес:
 "reported_by": "operator_01",
Акт має змогу містити:
== KPI аварійних ремонтів ==
Приклад:

організація має змогу бачити тільки вартість запчастин і робіт.; Пріоритет
Потім обладнання.; Аварійні ремонти можуть стосуватися:

<div style="border:3px solid #2e7d32; background:#e8f5e9; padding:14px; margin:16px 0;">

'''SLA''' — це узгоджений рівень сервісу: за який час потрібно відреагувати і відновити роботу.; Плановий ремонт або ТО виконується за графіком, щоб запобігти таким поломкам.; !; Регламент запуску не передбачав перевірку швидкості подачі.; Для ремонтника — після кави.; * підрядника;
* договір;
* SLA;
* заявку;
* акт виконаних робіт;
* вартість;
* гарантію;
* строк реакції;
* результат;
* повторні звернення.; Приклад:

* роботу працівників;
* запчастини;
* матеріали;
* послуги підрядників;
* термінову доставку;
* простій;
* втрачений випуск;
* штрафи;
* оренду техніки;
* додаткову логістику;
* повторний запуск;
* утилізацію пошкоджених матеріалів.;== Чек-лист аварійного ремонту ==
Результат: зменшення перегрівів.; Краще:
|-
| Оператор
| Створити аварійну заявку
|-
| Майстер зміни
| Підтвердити аварію, визначити пріоритет
|-
| Ремонтник
| Бачити призначені заявки, фіксувати роботи
|-
| Керівник сервісу
| Призначати виконавців, закривати критичні заявки
|-
| Комірник
| Видавати запчастини
|-
| Фінансист
| Бачити витрати
|-
| Керівник виробництва
| Бачити простої і критичні аварії
|-
| Адміністратор
| Налаштовувати довідники, SLA і права
|}

'''Простій''' — це час, коли обладнання або бізнес-процес не функціонує через аварію.; # Діагностика проведена.; Реакція
</div>
[[Категорія:MTTR]]
'''Аварійні ремонти''' — це критичний бізнес-процес для виробництва, складу, логістики, сервісу, IT, інженерної інфраструктури та будь-якого бізнесу, де поломка обладнання має змогу зупинити роботу.; !; * тип обладнання;
* локація;
* пріоритет;
* спеціалізація;
* доступність;
* графік;
* рівень допуску;
* історичний розвиток ремонтів;
* складність;
* SLA.; * кількість аварій;
* аварії по обладнанню;
* аварії по цехах;
* аварії по причинах;
* аварії по виконавцях;
* середній час реакції;
* середній час ремонту;
* простої;
* вартість ремонтів;
* використання запчастин;
* повторні аварії;
* порушення SLA;
* топ проблемного обладнання;
* тренд аварій;
* ефективність ремонтних бригад;
* вплив на виробництво.; 09:15 — створено заявку

== Роботи в аварійному ремонті ==

{| class="wikitable" style="width:100%;"

[[Категорія:Сервісна служба]]

</syntaxhighlight> ERP надає можливість бачити не тільки факт ремонту, а повну історію: ↓

Загальний час ремонтів: 40 год Чи можна тимчасово відновити роботу?; Аварійний ремонт не має бути хаотичним “подзвонили майстру — він щось зробив”.; * оперативно створювати заявки;

призначати виконавців;
контролювати SLA;
вести історію обладнання;
резервувати запчастини;
списувати матеріали;
рахувати витрати;
рахувати простої;
аналізувати повторні аварії;
планувати профілактику;
контролювати підрядників;
формувати акти;
будувати Power BI-аналітику;
зменшувати ручний хаос.; Бо; додатково реалізовано як простій стане дорожчим за ремонт.; MTBF = 200 год

Для аварійного ремонту істотно фіксувати час.; У таких випадках пріоритетом є собою не швидкість запуску, а безпека.; Аварійний ремонт — це коли зуб уже болить так, що ви готові підписати будь-яку заявку, лише б хтось це полагодив.; # Простій зафіксовано.; {| class="wikitable" style="width:100%;" Поламався датчик.; # Роботи виконані.; # Документи додано.; Коментар Ремонт за 20 000 грн має змогу здаватися дорогим, доки не порахувати простій.; Кількість аварій за місяць Поганий характеристика причини: Акт дефектації — це документ, який описує виявлену несправність і попереднє рішення для бізнесу щодо ремонту.; Діагностика — це визначення причини несправності.; Приклад аварії Головне. Аварійний ремонт — це не “колись подивимось”.; 10:10 — почато ремонт

Акт виконаних ремонтних робіт

Аварійна заявка

"downtime_minutes": 140,

Він має змогу містити:

; Стаття Див.; додатково === Що таке SLA аварійного ремонту? === '''MTBF''' — Mean Time Between Failures, середній час між відмовами.;<syntaxhighlight lang="text"> Де зламалося?; Для бізнесу — до того забезпечується через SLA користувачі можуть не сперечатися кожного разу, що означає “терміново”.; Питання == Аварійні ремонти і планове ТО == Як не допустити повторення?; Аварійний ремонт — це термінове усунення несправності, яка раптово порушила роботу обладнання, техніки, інженерної системи або іншого критичного об’єкта.; \|- \| Основні об’єкти \| Обладнання, транспорт, складська техніка, інженерні системи, IT, виробничі лінії.; !; # Локація вказана.; 09:25 — прийнято в роботу Потрібно контролювати: Лінія виробляє продукції на 30 000 грн валового прибутку за годину.; Вартість аварійного ремонту має змогу включати: Без обліку аварійних ремонтів організація часто знає тільки одне: “воно знову зламалося”.; Критичність Висновок Заявку створено.; Роль Які запчастини потрібні?; ↓ ERP має змогу зберігати: Проблема: верстат не запускається.;== SLA аварійного ремонту == * обладнання; * серійні номери; * місця експлуатації; * аварійні заявки; * пріоритети; * SLA; * виконавців; * запчастини; * складський облік; * роботи; * витрати; * документи; * історію ремонтів; * причини; * простої; * підрядників; * гарантії; * аналітику.; 3.; Що означає <syntaxhighlight lang="text"> [[Категорія:Акти виконаних робіт]] == Аналіз кореневої причини == Потім виробничий план.;<syntaxhighlight lang="text"> Виконується ремонт '''Аварійна заявка''' — це документ або запис у системі, який фіксує факт аварії та запускає бізнес-процес ремонту.; Залишок [[Категорія:Технічне обслуговування]] ↓ Краще: !; 4.; Приклад: !; * [https://erp.kyiv.ua Сайт K2 ERP] * [https://wiki.erp.kyiv.ua Wiki K2 ERP] * [https://cloud.corp2.eu K2 Cloud ERP] !; Робота Погана ситуація: !; На лінію подавали більше продукції, ніж норма.; # Заявку закрито.; Цільовий час відновлення ↓ === Як зменшити кількість аварійних ремонтів? === Визначено пріоритет <syntaxhighlight lang="text"> \|- \| Конвеєр №2 \| 5 \| Потрібен аналіз кореневої причини \|- \| Навантажувач №4 \| 3 \| Можлива заміна вузла \|} !; Об’єкт !; \|} [[Категорія:Права доступу в ERP]]	; Поле Обладнання на гарантії.; {\| class="wikitable" style="width:100%;" Обладнання стоїть.; Чому перегорів?; Документи потрібні для: ↓ "created_at": "2026-05-16T09:15:00", "spare_parts": [ Що таке аварійний ремонт "asset_id": "LINE-PACK-002", Обладнання → Аварії → Ремонти → Запчастини → Витрати → Простої → Причини → Профілактика Що таке аварійний ремонт? Призначення виконавця не усунули кореневу причину; поставили неякісну запчастину; виконали тимчасовий ремонт; порушують експлуатацію; обладнання зношене; неправильна діагностика; немає профілактики; ремонт виконаний неякісно.; Якщо обладнання стало, бізнес-середовище часто теж частково став.; !;== Для чого контролювати аварійні ремонти == Пріоритет потрібен, щоб ремонтна служба не лагодила ручку дверей, поки виробнича лінія стоїть і тихо спалює гроші.; це термінові ремонтні роботи.; ERP має контролювати: 2.; Це не причина.;== Акт дефектації == !; {\| class="wikitable" style="width:100%;" ↓ складський облік запчастин Відновлення роботи	;== Аварійна заявка == ↓ Коренева причина: не виконано планове ТО.; # Профілактичні дії визначені, якщо потрібно.; Поле </syntaxhighlight> Приклад: реєстрація аварійних заявок; довідник обладнання; критичність обладнання; пріоритети; SLA; ремонтні бригади; призначення виконавців; складський облік запчастин; резервування запчастин; списання матеріалів; акти дефектації; акти виконаних робіт; контроль простоїв; історичний розвиток ремонтів; підрядники; гарантійні ремонти; витрати; Power BI-аналітика; права доступу; audit log; API.; * запасні частини; SLA; резервні варіанти; планове ТО; моніторинг; відповідальні; інструкції аварійного реагування.; Методи: 09:40 — почато діагностику	;</syntaxhighlight> Аварійний ремонт і плановий ремонт Аварійні ремонти виконують: Призначається ремонтна бригада Ніхто нічого не записує.; Час реакції Проста аналогія. Планове обслуговування — це похід до стоматолога на профілактику.;== Audit log аварійних ремонтів == 11:30 — обладнання відновлено "works_done": [ Аварійний ремонт часто залежить від наявності запчастин.; Працював із перевантаженням.; Якісне керування аварійними ремонтами надає можливість оперативно реагувати, зменшувати простої, контролювати витрати, забезпечувати наявність запчастин і знижувати кількість повторних аварій.; Не все обладнання однаково важливе.; Для критичного обладнання потрібні: "closed_at": "2026-05-16T11:30:00", Корисні KPI: Після аварій: очищення раз на тиждень.; Значення Створено аварійну заявку Приклад: Аналіз аварій має впливати на планове технічне обслуговування.; Якщо один і той самий вузол ламається щотижня, це вже не ремонт.; # Пріоритет визначено.;== MTBF == { Аварійний ремонт — це термінове усунення несправності, яка порушує нормальну роботу обладнання, процесу або об’єкта.; Через тиждень поломка повторюється.; \| Терміновий ремонт після раптової поломки.; Чому було перевантаження?;=== Чому потрібно реєструвати аварійні ремонти в ERP? ===
Нова	Заявку створено
Прийнята	Відповідальний прийняв у роботу
Діагностика	Визначається причина
Очікує запчастини	Потрібна деталь або матеріал
У ремонті	Роботи виконуються
Очікує підрядника	Потрібен зовнішній сервіс
Тестування	Перевірка після ремонту
Відновлено	Об’єкт функціонує
Закрито	Заявку завершено
Скасовано	Заявка неактуальна або дубль

Після ремонту потрібно зафіксувати результат.;== Життєвий цикл аварійного ремонту == </syntaxhighlight> Схема:

Аварійні ремонти і Power BI

Не всі аварії однаково критичні.; !; Наслідок </syntaxhighlight> {{SEO

Правило:

== Аварійний ремонт і документи ==

* визначити критичні запчастини;
* встановити мінімальні залишки;
* налаштувати поповнення;
* мати аналоги;
* мати список постачальників;
* контролювати строки поставки.;

Іноді потрібен зовнішній сервіс.; {| class="wikitable" style="width:100%;"

огляд обладнання;
опитування оператора;
перевірку журналів;
аналіз датчиків;
перевірку електроживлення;
перевірку механіки;
перевірку програмного забезпечення;
тестовий запуск;
перевірку витратних матеріалів;
аналіз останніх ремонтів;
перевірку історії поломок.; Корисні дашборди:

Пріоритети аварійних ремонтів

</syntaxhighlight>

Вартість аварійного ремонту

Наскільки це критично?; Основні причини аварій:

; автоматизація процесів сприяє:

[[Категорія:API]]
|-
| P1
| 15 хв
| 2 год
|-
| P2
| 30 хв
| 4 год
|-
| P3
| 2 год
| 1 робочий день
|-
| P4
| 1 робочий день
| За планом
|}

 "quantity": 1

Фіксація причини

Причина аварії: перегрів двигуна.; Проводиться діагностика
MTTR = 4 год
{| class="wikitable" style="width:100%;"
<syntaxhighlight lang="text">
 ↓
Power BI показує причини, витрати і повторні аварії

SLA — це погоджений строк реакції та відновлення.;=== Що таке MTBF? === Простій має змогу коштувати:

Запчастини 12 000 грн Роботи 5 000 грн Термінова доставка 2 000 грн Простій 80 000 грн Разом 99 000 грн

Приклад:

Приклад JSON аварійної заявки

Деякі аварії створюють ризик для людей.; 4.;

Потрібно аналізувати причини, виконувати планове ТО, мати критичні запчастини, навчати операторів, контролювати умови експлуатації і використовувати аналітику по повторних аваріях.; має змогу робити

MTBF — це середній час між відмовами.; Окремо варто відзначити які виконуються після раптової поломки обладнання, техніки, інженерної системи, транспортного засобу, виробничої лінії, складського обладнання або іншого критичного об’єкта виступає ключовою рисою Аварійні ремонти.; Це філософське спостереження.; - проведено тестовий запуск;

графік;
навички;
доступність;
спеціалізацію;
інструменти;
допуски;
виконані роботи;
час реакції;
час ремонту;
завантаження;
якість виконання.; характеристика

ERP має показувати повторні аварії.; * заявку;

об’єкт;
виконавця;
перелік робіт;
використані матеріали;
використані запчастини;
дату початку;
дату завершення;
результат;
гарантію на роботи;
підпис відповідального;
коментарі;

фото після ремонту.;

Планове обслуговування коштує грошей.; * електрична несправність;
* витік газу;
* перегрів;
* механічне руйнування;
* нестабільна конструкція;
* аварія підйомного обладнання;
* витік хімічної речовини;
* небезпечна температура;
* задимлення;
* несправність систем безпеки.; }
Потрібно перевірити:
Пріоритет: P1

[[Категорія:Інтеграція]]

 "проведено тестовий запуск"

Підбір запчастин

Гарантійний аварійний ремонт

1.; |- | Об’єкт | Конвеєрна лінія №2 |- | Дефект | Не функціонує приводний мотор |- | Причина | Перегрів і пошкодження обмотки |- | рішення для бізнесу | Заміна мотора |- | Запчастина | Мотор MTR-220 |}

обліковий облік часу ремонту

Коренева причина — не тільки мотор, а неправильний бізнес-процес експлуатації.; Запчастина
 "repair_cost": 14000,
<syntaxhighlight lang="text">
Приклад процесу в K2 ERP:
Audit log має фіксувати:
- обладнання функціонує стабільно.; Об’єкт
Кількість ремонтів: 10
Перевірка:
Дія: змінити графік ТО і додати контроль мастила.; # Причина зафіксована.; # Запчастини зарезервовані або замовлені.; Показник
завдяки наявності користувача “терміново” — це зараз.; Причина

Критерії:

Якщо аварії повторюються, потрібно:

Тип аварії: температура вище норми
Спочатку безпека людей.;[[Категорія:Power BI]]
{| class="wikitable" style="width:100%;"

Потрібна запчастина

Хто має реагувати?;<syntaxhighlight lang="text">
{{DISPLAYTITLE:Аварійні ремонти}}

Заявка закривається

Було 5 аварій

* внутрішня ремонтна служба;
* механіки;
* електрики;
* інженери;
* IT-спеціалісти;
* сервісні інженери;
* чергова бригада;
* зовнішній підрядник;
* виробник обладнання.;== Аварійні ремонти в K2 ERP ==
'''MTTR''' — Mean Time To Repair, середній час ремонту.;

Аварійний ремонт і безпека

актуалізація залишків {

Приклад JSON закриття ремонту

Типові помилки аварійних ремонтів

↓

↓

Приклади:

Ремонт: 15 000 грн.; !; # Відповідальний призначений.; Самостійний ремонт має змогу скасувати гарантію.; Приклад Хороше керування аварійними ремонтами — це коли поломку оперативно фіксують, правильно пріоритезують, ремонтують, документують, аналізують і не дають їй повертатися щоп’ятниці о 17:45, як дуже неприємна традиція.

Помилка: ремонти “по телефону”

"request_id": "AR-2026-00045",

; Вона має змогу включати:	; ↓ Аварійний ремонт відрізняється від планового технічного обслуговування тим, що він виникає не за графіком, а через несподівану проблему: зламався верстат, стала лінія, не функціонує холодильна камера, вийшов з ладу сервер, зупинився автомобіль, протікає платформа, не запускається обладнання або сталася інша подія, яка потребує швидкої реакції.; * обліку витрат; підтвердження робіт; гарантії; аналізу причин; аудиту; списання матеріалів; розрахунку простою; претензій до постачальника або підрядника.; !;</syntaxhighlight> дату купівлі; гарантійний строк; умови гарантії; серійний номер; історію ремонтів; чи не порушено правила експлуатації; чи можна ремонтувати власними силами; чи потрібне погодження виробника.; Оператор дзвонить ремонтнику.; Приклад: Формула:
Причина	Раптова поломка	Заплановане обслуговування
Час виконання	Терміново	За графіком
Вплив	Часто зупиняє бізнес-процес	Планується з мінімальним впливом
Вартість	Часто вища	Зазвичай контрольована
Запчастини	Можуть бути потрібні негайно	Можна підготувати заздалегідь
Ризик	Високий	Нижчий
Приклад	Зламався двигун виробничої лінії	Заміна фільтрів за графіком

Коротко

</syntaxhighlight>

зношення обладнання;
відсутність планового технічного обслуговування;
порушення правил експлуатації;
перевантаження;
неякісні запчастини;
помилки оператора;
неправильні конфігурація;
перегрів;
забруднення;
вібрація;
відсутність мастила;
збій електроживлення;
зовнішні пошкодження;
неправильний монтаж;
заводський дефект;
несвоєчасна діагностика;

природне старіння обладнання.; Він показує, як оперативно організація відновлює обладнання після аварії.;

Якщо обладнання на гарантії, аварійний ремонт має змогу виконувати виробник або сервісний партнерська сторона.; # Тестування проведено.; Перегорів мотор.; "status": "closed"

{| class="wikitable" style="width:100%;"

!; Приклад:

Об’єкт: холодильна камера

Приклад:

Загальна втрата: 215 000 грн.; Це ситуація, де час простою коштує грошей, нервів і репутації.; # SLA визначено.; !; |- | Ремінь приводу | 2 шт | 0 шт | Ризик |- | Датчик температури | 3 шт | 5 шт | OK |- | Підшипник | 4 шт | 1 шт | Поповнити |}

Погано:

"очищено вентиляційний блок",

↓

* що є собою в наявності;
* де лежить;
* під яке обладнання підходить;
* хто взяв;
* на яку заявку списано;
* залишок;
* мінімальний запас;
* потребу в закупівельна діяльність;
* історію використання;
* вартість ремонту.; Причина: недостатнє очищення фільтрів.; !;== Ремонтні бригади ==

[[Категорія:Аварійний ремонт]]

Заявка має змогу містити:

* змінити графік ТО;
* додати перевірку вузла;
* замінити тип запчастини;
* навчити операторів;
* змінити регламент;
* модернізувати обладнання;
* додати датчики;
* збільшити запас критичних деталей;
* переглянути умови експлуатації.; Що означає

<syntaxhighlight lang="text">

* аварійна заявка;
* акт дефектації;
* акт виконаних робіт;
* акт списання запчастин;
* акт простою;
* акт передачі обладнання в ремонт;
* рахунок підрядника;
* гарантійний талон;
* сервісний звіт;
* фотофіксація;
* технічний висновок;
* акт введення в експлуатацію після ремонту.; рішення для бізнесу: створити сервісну заявку виробнику.; Потрібен виконавець: інженер холодильного обладнання

 "downtime_started_at": "2026-05-16T09:10:00"
 "замінено датчик температури",
== Статуси аварійного ремонту ==
 "problem": "Не запускається конвеєр",
 ↓
 ↓
!; Показники:
{| class="wikitable" style="width:100%;"
{| class="wikitable" style="width:100%;"
 "location": "Цех пакування",
 ↓
Приклад:
!; Простій 4 години.;== Тимчасове і повне відновлення ==
|-
| Критичне
| Зупинка блокує ключовий бізнес-процес
| Основна виробнича лінія
|-
| Важливе
| Впливає на продуктивність
| Додатковий верстат
|-
| Звичайне
| Має обхідний варіант
| Допоміжне обладнання
|-
| Низьке
| Не впливає на ключовий бізнес-процес
| Некритичний інструмент
|}

Ремонтник приходить.; Помилка

!; Він показує надійність обладнання: чим більший показник, тим рідше обладнання ламається.; У бізнесі “тимчасово” часто живе довше за директора, який це погодив.; * хто створив заявку;
* хто змінив пріоритет;
* хто прийняв у роботу;
* хто призначив виконавця;
* хто змінив SLA;
* хто списав запчастини;
* хто змінив причину;
* хто закрив заявку;
* хто змінив час простою;
* хто додав або видалив фото;
* хто змінив вартість робіт;
* хто скасував заявку.; * 5 Why;
* діаграма Ішікави;
* аналіз історії ремонтів;
* аналіз умов експлуатації;
* аналіз запчастин;
* аналіз роботи операторів;
* аналіз планового ТО;
* аналіз датчиків;
* аналіз простоїв.; "priority": "P1",
Приклад:

!; !; }
 "request_id": "AR-2026-00045",

 ↓

 "assigned_team": "repair_team_01",

MTBF = Час роботи обладнання / Кількість відмов

* діагностика;
* демонтаж;
* заміна деталі;
* очищення;
* конфігурація;
* калібрування;
* змащення;
* прошивка;
* тестовий запуск;
* ремонт проводки;
* заміна вузла;
* відновлення живлення;
* перевірка безпеки.; ↓
У заявці потрібно фіксувати виконані роботи.; як ілюстрація, для критичної аварії реакція має бути за 15 хвилин, а відновлення — до 2 годин.; Значення
|-
| Тимчасове відновлення
| Швидке рішення для бізнесу, щоб запустити бізнес-процес
| Обхідний режим, тимчасова деталь
|-
| Повне відновлення
| Повноцінний ремонт із усуненням причини
| Заміна вузла, конфігурація, тестування
|}

Причина: перегрів підшипника через відсутність мастила.; Audit log потрібен, щоб аварійна заявка не “сама закрилася”, поки обладнання ще стоїть і сумно дивиться на виробничий план.; Час

ERP або WMS має показувати:
Обладнання працювало 1 000 год
== Помилка: причина “зламалося” ==
Чим вищий MTBF, тим надійніше обладнання.; MTTR — це середній час ремонту.; Не було обмеження в налаштуваннях.; Щось лагодить.; Це має бути керований бізнес-процес: заявка, пріоритет, SLA, діагностика, виконавець, запчастини, роботи, простій, витрати, причина, закриття і профілактичні дії.; Оператор створює аварійну заявку

MTTR = Загальний час ремонтів / Кількість ремонтів

Проблема: зупинився конвеєр.; У сучасній ERP, зокрема в [[K2 ERP]], аварійні ремонти мають бути пов’язані з обладнанням, заявками, SLA, ремонтними бригадами, складом запчастин, закупівлями, актами робіт, витратами, простоями, Power BI, API, audit log і правами доступу.; Іноді аварійний ремонт має змогу мати два етапи.;[[Категорія:SLA]]

Аналіз і профілактичні дії

Для бригади потрібно контролювати:

ERP сприяє керувати аварійними ремонтами як процесом.; ERP має змогу автономно або вручну призначати виконавця.; Приклад 5 Why:

2.; Головна мета аварійного ремонту — якнайшвидше відновити працездатність і мінімізувати простій, збитки і ризики для бізнесу.; Чому не було обмеження?; Помилка на панелі: перегрів.; Це абонемент на проблему.; * втрачений випуск продукції;
* зрив відвантажень;
* понаднормові роботи;
* штрафи;
* втрату клієнтів;
* псування товару;
* простій працівників;
* додаткову логістику;
* термінові закупівельна діяльність;
* репутаційні втрати.; А треба знати: чому, як часто, скільки коштувало, хто ремонтував і чому профілактика знову була “не на часі”.;<syntaxhighlight lang="text">
 ↓
!; # Витрати зафіксовано.; Тип
<syntaxhighlight lang="json">

|- | Виробничий верстат | Не запускається шпиндель | Зупинка виробництва |- | Складський навантажувач | Відмова гідравліки | Повільне відвантаження |- | Холодильна камера | Температура вище норми | Ризик псування товару |- | Сервер | Відмова диска або живлення | Недоступність системи |- | Автомобіль | Поломка в дорозі | Зрив доставки |- | Електрощитова | Вибило автомат | Зупинка дільниці |- | Касове обладнання | Не друкує чек | Неможливість продажів |}

Приклад:

Простій обладнання

Виконано:

номер;
дату і час створення;
ініціатора;
об’єкт ремонту;
місце аварії;
характеристика проблеми;
фото або відео;
пріоритет;
критичність;
відповідального;
сервісну бригаду;
статус;
SLA;
запчастини;
роботи;
витрати;
причину;
результат;
час простою.; Відповідь

Тестування |- | Аварій за місяць | 48 |- | Середній час реакції | 22 хв |- | Середній час ремонту | 3,4 год |- | Простої | 126 год |- | Вартість ремонтів | 420 000 грн |- | Найпроблемніше обладнання | Лінія пакування №2 |}

Підрядники можуть виконувати:

</syntaxhighlight>

кількість аварій;
кількість критичних аварій;
середній час реакції;
середній час відновлення;
час простою;
виконання SLA;
вартість аварійних ремонтів;
кількість повторних аварій;
MTTR;
MTBF;
частка аварійних ремонтів у загальних ремонтах;
витрати на запчастини;
аварії по обладнанню;
аварії по причинах;
завантаження ремонтних бригад;
кількість заявок в очікуванні запчастин.; "sla_response_min": 15,

Контроль аварійних ремонтів потрібен для: Призначено відповідального

автоматизація процесів аварійних ремонтів

!; У K2 ERP аварійні ремонти можуть бути частиною сервісного, виробничого, складського, фінансового і технічного контуру.; Аварійний ремонт має змогу супроводжуватися документами: рішення для бізнесу:

"status": "in_progress",

платформа визначає пріоритет і SLA

"item": "TEMP-SENSOR-01",

- очищено вентиляційний блок;

;

</syntaxhighlight>

"sla_restore_hours": 2,

</syntaxhighlight> Права доступу мають залежати від ролі.; Приклад Коренева причина: не виконували регулярне очищення вентиляційних каналів.;</syntaxhighlight>

складський облік запчастин;
мінімальні залишки;
критичні деталі;
аналоги;
постачальників;
строки поставки;
вартість;
серійні номери;
сумісність;
гарантію;
списання;
резервування під ремонт.; Наслідок

Діагностика Що зламалося?;== Критичність обладнання ==

Орієнтовна втрата: 120 000 грн.; Повторна аварія — це поломка, яка виникає знову після ремонту.;

[[Категорія:Аварійні ремонти]]
функціональні можливості:
Фіксується час простою і витрати

{| class="wikitable" style="width:100%;"

* виробничого обладнання;
* складської техніки;
* транспорту;
* холодильного обладнання;
* електромереж;
* серверів;
* IT-інфраструктури;
* систем водопостачання;
* систем опалення;
* систем вентиляції;
* касового обладнання;
* торгового обладнання;
* будівель і приміщень;
* інженерних мереж;
* спеціального обладнання.; Приклади:

Приклад:
Простій: 5 год × 40 000 грн = 200 000 грн.; !; !; Закриття заявки

5.; Приклад
Приклад:
 "root_cause": "Перегрів двигуна через забруднення вентиляції",
Аварія → заявка → пріоритет → виконавець → роботи → запчастини → причина → простій → закриття → аналітичні інструменти.; |-
| Ключові елементи
| Заявка, пріоритет, SLA, виконавець, запчастини, роботи, простій, причина.; Яка причина аварії?; Значення

== Права доступу в аварійних ремонтах ==

[[Категорія:MTBF]]
!; Приклад:
1.; Статус
== Аварійні ремонти в ERP ==
<syntaxhighlight lang="text">
Виконання ремонту
|-
| Діагностика
| Інженер 1
| 30 хв
|-
| Заміна датчика
| Інженер 1
| 45 хв
|-
| Тестування
| Інженер 2
| 20 хв
|}

[[Категорія:Audit log]]

</syntaxhighlight>

час створення заявки;
час прийняття в роботу;
час початку діагностики;
час початку ремонту;
час завершення ремонту;
час простою;
час очікування запчастин;
час очікування підрядника;
час тестування;
загальний час відновлення.; Аварійне — теж коштує грошей, тільки ще й приходить у найгірший момент, з друзями: простоєм, панікою і терміновою доставкою запчастин.;== Помилка: немає критичних запчастин ==

Аналіз витрат Загальний простій: 2 год 15 хв

Щоб бачити історію обладнання, причини поломок, витрати, простої, використані запчастини, виконавців, SLA і повторні аварії.; |-

Головна мета	оперативно відновити роботу і зменшити простій.; ↓ Було: очищення фільтрів раз на місяць.; !; Живлення є собою.; \|- \| ключовий ризик \| Ремонти виконують без обліку, з цієї причини аварії повторюються.; Після такого профілактика вже не здається “дорогою”.; Датчика на складі немає.; - замінено датчик температури; !; !; Аварійний ремонт виконується після несподіваної поломки.; ↓ \|- \| Заявка \| AR-2026-00045 \|- \| Об’єкт \| Лінія пакування №2 \|- \| Проблема \| Не запускається конвеєр \|- \| Пріоритет \| Критичний \|- \| Створено \| 16.05.2026 09:15 \|- \| Відповідальний \| Сервісна бригада 1 \|- \| Статус \| У роботі \|} Виявлено аварію Приклад: складський облік запчастин має бути пов’язаний із ремонтами.; Статус Формула: <syntaxhighlight lang="text"> ↓ ↓ Технічне обслуговування Планові ремонти Ремонт обладнання Сервісна заявка SLA Обладнання Запчастини Складський облік Адресне зберігання Штрихкодування Виробництво Контроль браку Управління доставкою Архів документів ERP K2 ERP K2 Cloud ERP Power BI BI система API Інтеграція через JSON Audit log Права доступу в ERP Українське програмне забезпечення Поставка 5 днів.; } <syntaxhighlight lang="text"> Усі дивуються.;== Типові питання ==	; Мінімум Чим аварійний ремонт відрізняється від планового? Тимчасове рішення для бізнесу не має ставати постійним.; !; Пріоритет ],	; * швидкого реагування на поломки; зменшення простоїв; контролю ремонтних бригад; обліку витрат на ремонт; контролю запчастин; аналізу причин аварій; планування профілактики; контролю SLA; підвищення надійності обладнання; зменшення повторних поломок; контролю підрядників; керування сервісними заявками; оцінки критичності обладнання; контролю безпеки; аналітики в Power BI; прийняття рішень про заміну обладнання.; \|-	Аварії не реєструють	Ремонтують “по дзвінку”	Немає історії і аналітики
Немає пріоритетів	Усі заявки однаково “термінові”	Критичні ремонти губляться
Немає SLA	Не визначені строки реакції	Важко контролювати сервіс
Немає складу запчастин	Критичні деталі не контролюються	Простій через очікування
Не фіксують причини	Закривають тільки факт ремонту	Аварії повторюються
Не рахують простій	Аналізують тільки вартість ремонту	Не видно реальних втрат
Немає історії обладнання	інформаційні дані розкидані	Неможливо оцінити надійність
Тимчасовий ремонт стає постійним	Немає контролю доробок	Ризик повторної аварії

; Охолодження забруднене.; Після критичних аварій потрібно знаходити не тільки симптом, а й причину.;== Зовнішні посилання ==

; Аварійний ремонт

Приклад SLA: Резерв зі складу

=== Що таке MTTR? ===

Діагностика аварії

Об’єкти аварійного ремонту

Аварійний ремонт і підрядники

Акт виконаних ремонтних робіт

Див.; додатково

Висновок

Що таке аварійний ремонт

Що таке аварійний ремонт?

Призначення виконавця

складський облік запчастин

Аварійний ремонт і плановий ремонт

Аварійні ремонти і Power BI

Пріоритети аварійних ремонтів

Вартість аварійного ремонту

Приклад JSON аварійної заявки

Гарантійний аварійний ремонт

обліковий облік часу ремонту

Аварійний ремонт і безпека

Приклад JSON закриття ремонту

Типові помилки аварійних ремонтів

Помилка: ремонти “по телефону”

Коротко

Простій обладнання

автоматизація процесів аварійних ремонтів

Чим аварійний ремонт відрізняється від планового?