Про компанію JUDU
JUDU — муніципальна компанія міста Вільнюс, що відповідає за організацію та управління міською мобільністю. Компанія забезпечує роботу, цілісність і якість міської дорожньої інфраструктури включно з інфраструктурою громадського транспорту, адмініструє паркування та платні зони парковки, управляє міським трафіком і розвиває інфраструктуру для велосипедів та пішоходів.
Під опікою компанії перебуває майже вся дорожня інфраструктура міста:
світлофори і вузли контролю перехресть, камери контролю трафіку, шлагбауми і паркомати, дорожні знаки, відбійники, зупинки громадського транспорту (разом з навісами, лавочками, смітниками), муніципальні сітілайт борди, велопарковки, транспортні та паркувальні картки та інш.
Щодня міською інфраструктурою користуються сотні тисяч жителів та гостей міста, тому ефективність внутрішніх процесів та управління сервісними запитами є критично важливою для стабільної роботи міської транспортної системи.
Потреба в проекті
Компанія JUDU потребувала сучасної системи управління сервісними запитами. В першу чергу, налаштування бізнес-процесу прийому та реєстрації тисяч щоденних звернень жителів та гостей міста по питаннях дорожньої та транспортної інфраструктури, транспортних та паркувальних карток. Для цього необхідна координації роботи внутрішніх команд. Другим важливим питанням залишається організація взаємодії з підрядниками. По всіх напрямках був необхідний контроль строків вирішення проблем, відповідей на запити, виконання робіт, тобто централізоване управління сервісними процесами.
Для реалізації цього завдання було обрано платформу Odoo, а основою сервісної архітектури став модуль Yodoo Service Desk від компанії CR&D.
Проект тривав 1 рік активного впровадження та 3,5 роки розширення та розвитку. Проєкт включав глибоку конфігурацію системи під операційні процеси компанії.
Архітектура рішення
Для вирішення задач, що стояли перед командою автоматизації, недостатньо було просто впровадити тікетну систему реєстрації і обробки звернень (HelpDesk) або систему управління задачами (Tasks & Projects).
Потрібно було побудувати одночасно жорстко регламентовану систему (вимоги, процедури, регламенти, нормативи) і систему, що легко модифікується (постійні зміни, вдосконалення, постійні нові процеси, заміна підрядників і внутрішніх виконавців).
Методологія управління сервісами для установ, організацій і сервісних підрозділів (на базі ITIL4) та програмні модулі Yodoo Service Desk (на платформі Odoo Community Edition) дозволили побудувати комплексне, гнучке та універсальне рішення.
В процесі бізнес-аналізу було виділено три рівні операційної діяльності компанії: Взаємодія с Замовниками - Городяни, Муніципалітет, Контролюючі органи; Внутрішня взаємодія - Служби і підрозділи компанії: Колл центр, Фінанси, Юристи, IT; Взаємодія з Виконавцями - власні технічні спеціалісти, інженерні групи, до сотні профільних підрядників.
Вони перетворились у каталог з трьома групами описаних сервісів з виділенням відповідальних менеджерів й відповідних команд спеціалістів.
Функціонал системи дозволяє поєднувати Запити у ланцюжки виконання чи структури Батьківський Запит - Дочірні Підзапити (Subrequests). Це дає можливість вибудовувати складні, але гнучкі процеси. Запити від городян (INCIDENT MANAGEMENT) після аналізу, класифікації та групування в проблеми (PROBLEM MANAGEMENT) в подальшому пов’язується з запитами на ремонт та обслуговування інфраструктурних об'єктів (SERVICE & FACILITY MANAGEMENT) або с запитами до відповідних проектних і будівельних підрозділів (CHANGE MANAGEMENT & PROJECT MANAGEMENT). Вибрана архітектура дає системі можливості для розширення згідно подальших вимог компанії.
Функціональна можливість платформи публікувати і контролювати кілька WEB сторінок з однієї бази даних дозволила розробити 3 окремі сайти: публічний інформаційний сайт компанії для звернень і відгуків; внутрішній операційний портал для роботи співробітників компанії; закритий портал для підрядників для отримання і контроля завдань та планування робіт.
На кожному сайті були опубліковані відповідні сервіси для створення запитів, а також документація з Бази Знань для ознайомлення.
Ключові функції системи
Рішення було побудовано на базі модульної платформи Odoo ERP / CRM та включало:
Автоматизована “з нуля” роботиколл-центра з підтримки користувачів транспортних та паркувальних карток, а також інфраструктури міста, що обслуговує компанія. Реалізовані прості легкі спеціалізовані інтерфейси та багато шаблонів і підказок.
Впроваджена автоматизація процесів взаємодії зі сторонніми підрядниками на сервісні роботи включно з інтеграцією сторонніх сервісів і систем.
Автоматизовано контроль дотримання строків (SLA, OLA, DeadLine)
Побудована система звітності як статистичної, накопичувальної для керівництва, так і системи оперативних ДашБордів, для лінійних керівників - власників і контролерів сервісів.
Розроблена підсистема GDPR - правил і документи по обробці персональних даних.
Проведена розробка додаткового функціоналу включно з інтеграцією систем моніторингу та керування інфраструктури.
У системі реалізовано структуровану модель сервісних запитів, що включає типи запитів, категорії та підкатегорії, маршрути обробки, відповідальні команди. Це дозволило стандартизувати процес обробки запитів та зменшити час їх виконання.
Для управління операційною ефективністю було реалізовано систему аналітики, яка дозволяє аналізувати дотримання SLA, контролювати навантаження підрядників, формувати статистику виконання запитів, експортувати дані для фінансового контролю.
Управління взаємодією з підрядниками
Як тільки надходить сигнал про поломку (дзвінок мешканця, онлайн-заявка або внутрішня фіксація компанією), система автоматично створює тікет. Завдяки налаштованим правилам, запит миттєво потрапляє саме до того підрядника, який відповідає за конкретну ділянку або тип обладнання.
Завдяки системі звітів замовник отримав «скляне» управління: повну картину інцидентів по кожному ресурсу; рейтинг ефективності підрядників; штрафні санкції: оскільки в договорах прописані штрафи за порушення SLA, дані з Yodoo Service Desk стали юридичною підставою для виставлення претензій.
Важливий нюанс: Фото Верифікація. Усі виявлені несправності та результати їх усунення обов’язково фіксувалися підрядниками на фото. Ці знімки додавалися до тикета в Yodoo Service Desk, що дозволяло замовнику бачити реальний стан справ у режимі реального часу, не виїжджаючи на об'єкт.
Комплексний SLA та контроль виконання
SLA - Угода про рівень сервісу, що була встановлена договором для кожного підрядника окремо, забезпечувала контроль дотримання гарантованих термінів виконання послуг.
Швидко стало зрозуміло, що простий SLA не забезпечує необхідну систему контролю та не гарантує адекватну оцінку якості робіт команди підрядника.
Яскравим прикладом критичної за значенням і складною за обслуговуванням є інфраструктура міської мережі світлофорів і контролерів керування перетином перехресть. На відміну від інших об’єктів, що обслуговуються (парковок, зупинок, велодоріжок, навіть камер спостереження за трафіком, … ) проблеми з світлофорами ускладнюють життя містян. А на критичних перехрестях можуть взагалі призвести до колапсу руху.
Перегоріла “лампочка” (насправді сучасний LED масив) якогось кольору на світлофорі вимагає реакції впродовж робочої зміни. А на критичних перехрестях впродовж години навіть у нічний час.
Система здатна не просто виставляти різні SLA на різних процесах. Система дозволяє налаштувати його в залежності від пріоритету запиту, сервісу, зони обслуговування, від тегів, критичності на об’єктах обслуговування та від будь яких інших умов.
Але вирішенням певної проблеми як правило займається не одна людина. І навіть не одна установа.
В випадку нашого клієнта типовий інцидент вирішувався ланцюжком комунікації та відповідних дій: Оператор гарячої лінії зовнішнього кол центру - Черговий аналітик підтримки - Сервісний інженер по типу інфраструктури - Координатор робіт підрядної організації - Майстер з обслуговування.
Для контролю загального SLA, який організація бере на себе перед міською радою і через неї перед жителями та гостями міста, він повинен складатись із суми окремих OLA - Операційних угод всіх учасників (команд і персон) ланцюжка в процесі.
Організаційно: Сума всіх OLA на найдовшому шляху процесса обслуговування не повинна перевищувати базовий SLA по сервісу.
Система правил обліку часу на стадіях процесу за умовами дозволяє налаштувати цю аналітику без додаткової розробки і ефективно контролювати за допомогою Алярмів,
Але це тільки верхівка “айсберга” якісного і відповідального сервісу.
Гілка, зламана вітром, може пошкодити кабель живлення чи керування світлофором. І це привід для негайної реакції відповідних служб. Дерево, повалене буревієм, може зламати стовп, на якому закріплена група світлофорів важливого перехрестя.
Це може вимагати повної заміни (виготовлення, доставки, демонтажу, монтажу) залучення додаткової техніки та персоналу, значного часу. Об’єктивні причини не повинні стати предметом санкцій щодо підрядника по провалу SLA,коли потрібно залучити додаткові процеси та ресурси, для вирішення проблеми.
Що було зроблено в проекті:
Якщо підрядник на місці оцінив ситуацію як більш складну та розумів, що не вкладається в SLA, він пропонує новий термін + додає докази (фото, опис). Все фіксується в лозі запиту. Рішення приймає тільки замовник (співробітник перевіряє дані, надані виконавцем робіт).
Далі можливі два сценарії. Якщо зміни, що пропонує підрядник, не прийняли, то працює звичайний SLA, а час на перевірку не впливає на раніше встановлені терміни. Якщо зміни прийняті, то запускається інший функціонал, встановлюється Deadline, на нього перемикається контроль, нотифікації, правила ескалації. Також до нього додається час на оцінку. Правила SLA при цьому не змінюється, але просто слугує інформативним полем.
Якщо Deadline порушено — вмикається стандартна логіка прострочення.
Це забезпечило гнучкість системи без хаосу дзвінків та складних перепогоджень. Підрядник може пропонувати перенесення навіть кілька разів, але прийняти його можна тільки обгрунтовано і до закінчення поточного терміну виконання завдання.
Також система дозволяє контролювати якість виконання робіт через перевірку клієнта. Коли підрядник позначає завдання як виконане, замовник перевіряє результат і якщо все гаразд запит буде закрито без впливу на встановлений SLA. Якщо ні — SLA продовжується, включаючи час перевірки.
Управління ресурсами міста
На балансі компанії перебуває величезна кількість різнопланових об’єктів: від зупинок громадського транспорту, парковок, шлагбаумів, камер спостереження трафіку, світлофорів та цілих перехресть до інфраструктури транспортних карток містян. Кожен тип об’єкта має унікальні параметри, обслуговується різними підрядниками та потребує індивідуального графіка ремонтів і перевірок.
Головним завданням було систематизувати великі обсяги розрізнених даних у єдину екосистему. Це мало дозволити компанії ефективно управляти активами та отримувати глибоку аналітику для прийняття рішень.
Ми вирішили створити гнучкий та універсальний конструктор ресурсів, який дозволив клієнту самостійно створювати каталоги обладнання будь-якого типу. Для кожного ресурсу налаштовуються специфічні реквізити. Параметри для світлофора кардинально відрізняються від характеристик транспортної картки.
Крім базових функцій довідника (класифікація, групування, тегування), система може швидко масштабуватись. Якщо місто передає підприємству на обслуговування нові типи об’єктів (наприклад, сітілайти), менеджери за лічені хвилини створюють новий довідник у Yodoo Service Desk, додаючи всі необхідні поля: місцезнаходження, розмір, дату встановлення тощо, а також відповідальних по рольовій моделі, властивий саме цьому типу обладнання.
Каталог ресурсів тісно пов’язаний із моделлю запитів. У разі аварії чи сервісного випадку, в запиті вказується відповідний об’єкт та тикет автоматично направляється відповідальному підряднику на виконання. У запиті виконавець відразу бачить точну локацію та повну історію обслуговування ресурсу: хто, коли і які саме роботи виконував.
Завдяки інтеграції з Google Maps, кожен об’єкт можна знайти за адресою або геоданими прямо на мапі. Функція map view відкрила додаткові можливості для планування маршрутів підрядників та розподілу зон відповідальності між сервісними командами.
Впровадження Yodoo Service Desk дозволило перетворити хаотичні дані (інколи просто таблиці Ексель) на структурований актив, значно підвищивши швидкість реакції на інциденти та ефективність управління міською інфраструктурою.
Результати впровадження
Побудована автоматизована система обробки сервісних запитів компанії: 98 % запитів закриваються протягом трьох днів. І це в потоці до 4000 запитів на добу. З автоматизацією роботи колл-центру Компанія отримала не просто «програму для заявок», а інструмент фінансового контролю та підвищення якості міського сервісу.
З Yodoo Service Desk керівництво компанії отримало інструмент для повної прозорості активів: миттєве розуміння кількості та стану всіх об’єктів на балансі й детальна статистика інцидентів, швидкості та якості роботи підрядників. Відбувся перехід від статичних списків до динамічних об’єктів, що накопичують історію обслуговування.
Побудовано автоматизовану систему роботи з підрядниками: систему було кастомізовано під унікальні бізнес-процеси замовника та інтегровано з декількома Service Desk системами підрядників для створення єдиного безшовного середовища управління інцидентами
Налаштування комплексного SLA для роботи з підрядниками дозволило побудувати чесну модель штрафів, захист від маніпуляцій, прозору аналітику та керовані винятки замість конфліктів.
В межах проекту також було реалізовано комплексну політику відповідності стандартам GDPR, що включає розробку спеціалізованих правил та шаблонів документів для веб порталів компанії.
Система стала центральною платформою управління сервісними процесами компанії.