Графіки пасивні. Сервіс — ось продукт.
Більшість систем моніторингу сонячних станцій зупиняються на графіках. Хтось усе одно має на них дивитися, помітити проблему й вирішити діяти. На кількох майданчиках це нормально. На цілому парку — не масштабується, і саме цю роботу власники радо віддають комусь іншому.
Цей «хтось інший» — сервіс експлуатації й обслуговування (O&M), і це регулярний дохід. Уся суть конвеєра вище — робити це дивлення, помічання й реагування автоматично, щоб інсталятор продавав результат — доглянутий майданчик із гарантією — а не свої вечори перед дашбордами.
Крок 1 — Помітити саме те, що треба
Спершу система перевіряє кожен майданчик за розкладом. Найважливіші два типи несправності:
- Офлайн — майданчик, що просто перестав звітувати.
- Недовиробіток — майданчик працює, але видає менше, ніж мав би за цей день.
Дві дрібниці роблять це надійним, а не гучним:
- Дивіться на годинник, а не лише на лічильник. Сонячний майданчик, що вночі видає нуль ват, не зламаний — він спить. Перевірка стану працює лише у світлий час, тож сутінки не запускають сотню хибних тривог.
- «Немає даних» — це не те саме, що «немає потужності». Сигнал, що справді означає біду, — це «ми давно нічого не чули від цього майданчика» (його час останнього зв'язку застарів), а не «потужність дорівнює нулю». Реагувати на втрату зв'язку, а не на нульову потужність — ось єдина різниця між системою, якій довіряють, і тією, яку вимикають.
І практична примітка про «водопровід»: хмарні API моніторингу, зокрема SolarEdge, не телефонують вам, коли щось ламається. Push-сповіщень немає, а кількість запитів на день обмежена. Тому перевірка стану — це ввічливе опитування за розкладом — рознесене в часі, згруповане по майданчиках і сповільнене, коли API каже «помалу», — а не живий потік.
Крок 2 — Відкрити рівно одну заявку
Коли з'являється нова несправність, система відкриває одну сервісну заявку, прив'язану до майданчика, клієнта та проєкту. Ключове слово — одну. Майданчик, що лежить шість годин, не повинен породити шість годин дублів заявок. Поки несправність відкрита, їй належить одна заявка, і тільки одна: нова несправність створює заявку; та сама несправність, що досі є, не створює нічого.
Крок 3 — Заявка стає нарядом на роботу
Сама по собі заявка — лише нотатка. Вона починає працювати, коли перетворюється на наряд на роботу — завдання, призначене технікові, з уже прикріпленими деталями майданчика, історією та клієнтом. Технік виїжджає, лагодить, підписує. А оскільки все живе в одній системі, ремонт записується до того самого майданчика, який ви моніторили. Без повторного введення, без окремої таблиці, без «а що це була за робота?».
Крок 4 — Відновлення замикає цикл
Коли майданчик знову починає звітувати нормально, система помічає це так само, як помітила несправність, — і закриває заявку сама. Нікому не треба пам'ятати її відмітити. Це і є пунктирна лінія, що повертається на схемі: цикл замикається сам, тож ваш список відкритих заявок завжди показує лише реальні, актуальні проблеми.
Чому це бізнес-кейс, а не просто функція
Звичайна CRM уміє зберегти клієнта. Звичайна ERP уміє виставити рахунок. Жодна з них не стежить за сонячним майданчиком і не відкриває собі завдання на ремонт. Саме ця прогалина — те місце, де інсталятор перетворює разовий продаж на постійний контракт O&M: майданчики під наглядом, гарантована реакція, регулярна оплата. Конвеєр вище — це те, що робить таку обіцянку здійсненною, не наймаючи людину, яка цілий день дивиться в екрани.
Де це в SolarERP
Це і є логіка нашої роботи над моніторингом і сервісом. Ті самі дані, що живлять дашборди, живлять і потік «несправність → заявка» з дорожньої карти, і вони ж — основа історії про сервіс і гарантію. Моніторинг, на який можна дивитися, — це базовий рівень. Моніторинг, що відкриває собі наряди на роботу, — ось частина, за яку варто платити.