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

Більшість обслуговуючих компаній вирішують перейти з електронних таблиць не тому, що прочитали статтю про цифрову трансформацію. Вони вирішують, тому що щось пішло не так. Клієнт зателефонував щодо порушеного SLA, і менеджер з обслуговування не міг знайти робочий наряд. Інспектор прийшов на аудит відповідності, а половина записів технічного обслуговування знаходилася в таблиці, яку хтось востаннє оновлював у жовтні. Технік проїхав 45 хвилин до роботи лише щоб виявити, що деталі знаходяться в іншому фургоні.

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

Цей посібник охоплює перехід від початку до кінця: що коштує вам залишатися там, де ви є, як підготувати дані, як проводити фактичну міграцію та як змусити своїх техніків дійсно використовувати нову систему.

Ознаки того, що ви переросли електронні таблиці

Електронні таблиці перестають бути достатніми раніше, ніж більшість людей думає. Двоє або троє техніків і 30–40 об'єктів за договором, вже достатньо, щоб з'явилися прогалини, що коштують грошей: порушені терміни SLA, документація обслуговування, яка не витримає перевірки, диспетчеризація по телефону і на інтуїції. І навіть менше того, ліфтова компанія з двома людьми та 15 будівлями несе такі самі нормативні зобов'язання, як компанія з двадцятьма. Аргумент на користь переходу: не кількість персоналу. Коли платформа автоматично визначає, з якої ліфтової шахти телефонують, ще до того як хтось підніме слухавку, веде диспетчеризацію з підтримкою ШІ і формує документацію, готову до перевірки, без ручного введення даних, таблиця не є практичною альтернативою в жодному масштабі. Це різниця поколінь у можливостях інструментів, а не питання кількості службових автомобілів на маршруті.

Ви диспетчеруєте за телефоном та інтуїцією. Хтось дзвонить технікові, якого вважає близьким. Цей технік може бути або не бути доступним. Ніхто не знає, де хто насправді. Двоє техніків опиняються на одному об'єкті. Один об'єкт взагалі пропускається.

Ваша відповідність SLA, це здогадка. Ви думаєте, що досягаєте 94% відповідності часу реагування. Але це число виникло від підрахунку рядків в електронній таблиці, яку оновлюють не всі послідовно. Реальне число може бути гіршим, а штрафні санкції за ваш контракт засновані на реальному числі.

Паперові робочі наряди зникають. Технік виконує роботу, залишає паперовий бланк на приладовій панелі, він прикривається іншими паперами. Клієнт дзвонить три тижні потому, просячи запис технічного обслуговування. Він зник.

Підготовка до аудиту займає дні. Клієнт або регулятор запитує останні 12 місяців записів обслуговування для конкретного активу. Комусь доводиться вручну шукати через кілька електронних таблиць, можливо перехресно посилатися на паперові файли, можливо дзвонити технікові, який може щось пам'ятати.

Ви не бачите, що відбувається прямо зараз. У будь-який момент ваш менеджер з обслуговування не має надійної відповіді на «де мої техніки і над чим вони працюють». У них є приблизні відповіді на основі того, коли вони востаннє комусь телефонували.

Подвійне введення даних з'їдає ваші адміністративні години. Завдання реєструються в одній електронній таблиці, рахунки виставляються з іншої, звіти готуються в третій. Кожна передача вносить помилки. Одна компанія, з якою я працював, мала невідповідність номера деталі між таблицею запасів і таблицею виставлення рахунків, яка тихо була неправильною чотири місяці.

Що насправді коштують вам електронні таблиці

Прямі витрати легше розрахувати, ніж думають більшість менеджерів з обслуговування.

Штрафи за порушення SLA. Типовий комерційний контракт на обслуговування HVAC або ліфта передбачає штраф у розмірі 1–3% від річної вартості контракту за порушення SLA, що перевищує поріг (часто 5 порушень на квартал). Компанія, що управляє контрактами на £400 000 на рік, може поглинати £12 000–£24 000 штрафів на рік, більша частина яких уникається з кращою видимістю диспетчеризації.

Витрати на невдалі аудити. В обслуговуванні пожежної безпеки та ліфтів, невдалий огляд через неповні записи може означати втрату сертифікації, що означає втрату контракту. Один середній контракт, втрачений конкуренту, що мав чистіші записи, зазвичай коштує в 3–5 разів більше, ніж будь-яке програмне забезпечення FSM коштує на рік.

Адміністративні накладні витрати. Підрахуйте, скільки годин на тиждень ваш офісний персонал витрачає на введення даних, переслідування техніків за оновленнями завдань, підготовку звітів та звірення записів у кількох таблицях. При 15 годинах на тиждень по £20/год це £15 600 на рік у адміністративній праці, якої не повинно існувати.

Витрачені поїздки техніків. Незапланований повторний візит через те, що на об'єкт привезли не ті деталі, коштує приблизно 2–4 години часу техніка плюс паливо. Якщо це відбувається двічі на тиждень у вашій команді, це коштує £20 000–£40 000 на рік у витраченій потужності.

Жодне з цих чисел не є теоретичним. Це діапазони, взяті від реальних обслуговуючих компаній у галузях ліфтів, пожежної безпеки та кондиціонування. Загальна сума майже завжди суттєво вища за вартість програмного забезпечення.

5-кроковий план переходу

Крок 1: Перевірте, що у вас є насправді

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

• Електронні таблиці (кілька, підтримуються непослідовно)
• Голови людей (старший диспетчер, що знає особливості кожного клієнта)
• Папір (робочі наряди, інспекційні сертифікати, рукописні нотатки)
• Ланцюги електронної пошти (інструкції по завданнях, запити клієнтів, оновлення техніків)

Витратьте 2–3 дні на проведення належного аудиту. Створіть простий перелік:

Цей перелік говорить вам, що ви насправді переносите та де є прогалини. Деякі прогалини ви заповните під час міграції і прийміть, що інші (наприклад, історичні робочі наряди 2019 р.) не варті зусиль.

Крок 2: Очистіть та підготуйте дані

Єдине, що ви повинні перенести: ваш активний список клієнтів, ваш реєстр активів та ваші поточні контракти. Все інше вторинне.

Список клієнтів. Витягніть його звідки він є. Мінімально вам потрібні: назва компанії, адреса об'єкта, ім'я основного контакту, контактний телефон. Видаліть дублікати. Перевірте повноту адрес. Ці дані вводяться першими, і все інше пов'язується з ними.

Реєстр активів. Тут обслуговуючі компанії, як правило, виявляють, що їхні дані гірші, ніж вони думали. Реєстр активів повинен включати: тип активу (ліфт, пожежна панель, чилер), виробника, модель, серійний номер, дату встановлення, місцезнаходження об'єкта та будь-який пов'язаний аварійний номер контакту (важливо для ліфтів із переговорними пристроями EN 81-28). Можливо, вам потрібно буде провести вдень зі старшим техніком, заповнюючи прогалини з пам'яті та фотографій.

Умови контракту. Для кожного активного контракту: клієнт, охоплені активи, часи реагування SLA (стандартний та аварійний), частота обслуговування, вартість контракту, дата поновлення. Ці дані керують вашим плануванням та відстеженням SLA, тому вони мають бути правильними.

Запаси деталей. Якщо у вас є система обліку запасів, експортуйте її. Якщо ні, приблизний підрахунок за категорією деталей є розумною відправною точкою. Програмне забезпечення будуватиме точність з часом, коли деталі споживаються та поповнюються при реальних роботах.

Вам не потрібно очищувати історичні робочі наряди. Вам, мабуть, ніколи не потрібно імпортувати більше 6 місяців історії, і для більшості компаній навіть це не є необхідним. Ваші техніки знають активи, які вони обслуговують. Історичний контекст живе в їхніх головах набагато корисніше, ніж у 3-річних електронних таблицях.

Крок 3: Виберіть правильну платформу

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

Офлайн-можливості мобільного пристрою. Ваші техніки працюють у підвалах, машинних відділеннях та підземних автостоянках. Мобільний додаток, що потребує Інтернету для функціонування, марний у цих середовищах. Архітектура з пріоритетом офлайн є обов'язковою.

Орієнтований на актив, а не на завдання. Деякі платформи FSM організовують все навколо робочих нарядів. Кращий підхід для технічного обслуговування, організовувати навколо активів, кожна шахта ліфта, кожна пожежна панель, кожен чилер має свою історію обслуговування, записи відповідності та пов'язані робочі наряди. Це надзвичайно важливо під час аудиту.

Управління SLA, що дійсно працює. Не просто поле, де ви можете ввести години SLA. Фактичне автоматизоване відстеження, що попереджає, коли завдання наближається до порушення, реєструє часи реагування відповідно до умов контракту та видає звіти, яких хочуть ваші клієнти.

Час налаштування. Деякі корпоративні платформи вимагають місяців налаштування та консультантів з введення в експлуатацію. Для обслуговуючої компанії з 10–30 техніками це не правильне рішення. Ви повинні бути готові до роботи за дні.

Для повного порівняння платформ за галузями, дивіться наш Посібник покупця програмного забезпечення для управління польовим сервісом.

Крок 4: Два тижні паралельної роботи

Найбільший ризик під час переходу технічний, це розрив довіри між «ми думаємо, що дані є в новій системі» та «ми знаємо, що вони є». Два тижні паралельних операцій усувають цей ризик.

Під час паралельної роботи:

• Створюйте всі нові робочі наряди як у старій електронній таблиці, так і в новому програмному забезпеченні
• Диспетчеруйте з нового програмного забезпечення, але тримайте таблицю як резервний запис
• Забезпечте, щоб техніки виконували завдання через мобільний застосунок, але тримайте паперові робочі наряди як резерв
• Після кожного дня вибірково перевіряйте, що записи збігаються

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

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

Крок 5: Перехід та навчання команди

Офіційний перехід, це конкретна дата, заздалегідь повідомлена. Із цієї дати таблиця є архівом лише для читання. Всі операції проходять через програмне забезпечення.

Навчання повинне відбутися до переходу, а не після. Навчання, що має значення, це не «ось як використовувати кожну функцію», а «ось як виконувати п'ять речей, які ви робите щодня». Для диспетчерів: як створити робочий наряд, призначити його технікові та бачити, де всі перебувають. Для техніків: як прийняти завдання, відкрити деталі завдання на мобільному та закрити завдання з фотографією та підписом. Всього іншого можна навчитися в ході роботи.

Більшість обслуговуючих компаній повністю готові до роботи за 3–5 днів фактичного використання, а не за тижні або місяці. Міграція даних та налаштування займає день-два. Паралельний період будує впевненість. Після двох тижнів команда разом використала систему достатньо, щоб вона перестала відчуватися як нова.

Залучення техніків

Це заслуговує власного розділу, тому що саме тут переходи досягають успіху або зазнають невдачі.

Менеджер з обслуговування та диспетчер зазвичай швидко підтримують нове програмне забезпечення, вони ті, хто найбільш безпосередньо стикається з болем від електронних таблиць. Техніки, інша аудиторія. Їх не цікавлять слідчі записи або інформаційні панелі SLA. Їх цікавить, чи їхній телефон говорить їм, куди йти, чи можуть вони бачити деталі завдання без дзвінка в офіс, і чи закриття завдання займає 30 секунд або 5 хвилин.

Якщо мобільний застосунок хороший, прийняття відбувається природно. Якщо він громіздкий, занадто багато торкань, заплутані екрани, скрізь потрібен Інтернет, команда тихо повертається до дзвінків в офіс за інструкціями, і програмне забезпечення стає дорогими накладними витратами.

Кілька речей, що покращують прийняття техніками:

Залучайте їх до покупки. Дозвольте двом-трьом технікам спробувати мобільний застосунок під час оцінки. Їхній відгук цінніший за будь-яку демонстрацію, яку ви побачите від команди продажів. Якщо вони знизують плечима або скаржаться на нього, боротьба за прийняття вже програна.

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

Не намагайтеся змінити процеси в перший день. Якщо ваші техніки зараз отримують ранкові інструктажі та роздрукований список завдань, продовжуйте це, поки вони також використовують застосунок. Усуньте паперовий список на другому тижні, а не на першому.

Що переносити першим, і останнім

Переносите першим:

1. Активних клієнтів (з адресами об'єктів)
2. Активні активи (пов'язані з клієнтами, з базовими специфікаціями)
3. Активні контракти на обслуговування (з умовами SLA та графіками)
4. Поточні запаси деталей (навіть якщо приблизні)

Переносите другим: 5. Відкриті робочі наряди (завдання, що виконуються на дату переходу) 6. Заплановане профілактичне технічне обслуговування (майбутній календар обслуговування)

Переносите останнім (або не переносите взагалі): 7. Історичні робочі наряди, імпортуйте лише останні 6 місяців, і лише якщо ваш контракт вимагає демонстрації історії обслуговування. Для більшості компаній паперовий архів служить записом відповідності і не повинен бути в новій системі.

Спроба перенести все одразу є найпоширенішою причиною, через яку переходи FSM займають місяці замість днів. Історичні дані є найменш цінними у системі та найбільш часозатратними для очищення та імпорту. Спочатку зосередьтеся на чистому запуску живих операцій.

Імпорт даних за допомогою штучного інтелекту

Одна річ, що дійсно прискорює міграцію для компаній з розумними даними в таблицях: завантажте свою таблицю клієнтів або активів, і система читає стовпці та автоматично зіставляє їх з правильними полями. Якщо ваша таблиця має стовпець «Адреса об'єкта» та інший «Поштовий індекс», імпорт відповідає їх полям адреси без ручного зіставлення.

Це не магія, якщо ваші дані мають непослідовне форматування або об'єднані клітинки, їх все ще потрібно очистити спочатку. Але для добре підтриманого списку клієнтів або реєстру активів крок зіставлення стовпців, що раніше займав вдень, займає кілька хвилин.

Поширені помилки при переході

Спроба перенести все одразу. Дивіться вище. Обмежте міграцію тим, що вам дійсно потрібно для живих операцій. Історичні дані можуть почекати або ніколи не перейти.

Незалучення техніків до рішення. Платформа, що підходить для диспетчерів і менеджерів з обслуговування, але яку ненавидять техніки, зазнає невдачі протягом трьох місяців. Отримайте мобільний відгук до того, як зобов'яжетеся.

Вибір платформи, що вимагає постійного Інтернету на мобільному. Задайте це питання явно під час будь-якої демонстрації: «Що відбувається, коли технік немає сигналу?» Відповідь має бути «вони все ще мають доступ до деталей завдання та можуть заповнити контрольний список, він синхронізується, коли відновиться з'єднання».

Запуск під час вашого найбільш завантаженого часу. Не починайте перехід у листопаді, якщо грудень, ваш пік для аварійних виїздів. Виберіть відносно тихий місяць.

Пропуск паралельного операційного часу. Два тижні здаються накладними витратами. Це не так. Це страховий поліс, що дозволяє перейти з впевненістю, а не паніки.

Реалістичний часовий графік

Саме програмне забезпечення є готовим набагато швидше, більшість команд виконують живі завдання через нього до 3-го або 4-го дня. Паралельний період стосується впевненості, а не можливостей.

Часті запитання

Чи потрібно нам переносити всі історичні робочі наряди?

Ні. Історичні робочі наряди корисні для аудитів відповідності для конкретних активів, але для більшості обслуговуючих компаній вони не варті зусиль на міграцію. Тримайте свої паперові записи або скановані архіви як запис відповідності та зосередьте міграцію на активних клієнтах, активах та контрактах.

Скільки часу потрібно технікам, щоб освоїтися з мобільним застосунком?

Більшість техніків освоюють базовий процес, прийняти завдання, переглянути деталі, заповнити контрольний список, закрити завдання, за 3–5 використань. Це зазвичай відбувається в перші два-три дні паралельної роботи.

Що якщо наші дані в дуже поганому стані?

Зосередьтеся лише на клієнтах та активах. Вам потрібна назва компанії, адреса та тип активу, щоб почати. Серійні номери, дати встановлення та умови контракту можна заповнювати протягом перших кількох тижнів, коли техніки відвідують об'єкти.

Чи можемо ми постійно запускати програмне забезпечення разом з електронними таблицями?

Технічно так, але це зводить нанівець мету. Цінність програмного забезпечення FSM виходить з наявності одного місця, де кожен може бачити, що відбувається. Як тільки деяка інформація знаходиться в таблиці, а деяка в програмному забезпеченні, ви повертаєтеся до проблеми звірення, з якої почали.

А як щодо записів відповідності, які аудитори повинні побачити?

Записи відповідності, створені після дати переходу, будуть у програмному забезпеченні та легко надаватися для аудитів. Записи до переходу мають залишатися у вашому існуючому архіві (паперовому або відсканованому PDF). Вам не потрібно все в одній системі, вам потрібно, щоб все з дати переходу вперед знаходилося в програмному забезпеченні, чисте та доступне.

Якщо ви готові побачити, як виглядає міграція на практиці, включаючи імпорт даних за допомогою ШІ, RemoteOps пропонує процес налаштування, розроблений для обслуговуючих компаній. Більшість команд виконують живі операції протягом першого тижня.