Культура, що служить клієнтові

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

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

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

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

Щоб отримати своє замовлення вчасно, клієнту часто доводиться «боротися з компанією». Хоча організації роками намагаються покращити процеси, більшість з них все ще працює через окремі відділи та розрізнені перспективи. Коли клієнт дзвонить у кол-центр, його постійно перекидають від одного спеціаліста до іншого. На зустрічах часто можна почути: «Я зробив свою частину – запитайте когось іншого». 

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

Завдяки цим підходам – від «3D-камери» до спеціальних Lean-заходів – ми створили унікальний і стабільний досвід для клієнтів. У цій статті я розповім про деякі з наших експериментів. 

Як дійсно слухати клієнта? 

У Clariant у сервісному управлінні розробили два підходи, які допомагають повністю зрозуміти потреби клієнта – 3D-камера та 3-рівнева записна стрічка. 

Модель 3D-камери працює в три етапи: 

1. Аналіз даних – спершу ми переглядаємо всю наявну інформацію у системах, шукаємо закономірності та повторювані ситуації. Наприкінці цього етапу складаємо список питань для співробітників, які безпосередньо спілкуються з клієнтами. 

1. Опитування співробітників – далі ставимо ці питання людям з першої лінії підтримки, щоб зрозуміти, що вони бачать і чого потребують клієнти. 

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

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

Ця модель нагадує роботу детектива на місці злочину (у Lean це називають гемба). Спершу детектив аналізує всі наявні дані та висновки експертів – це етап дослідження інформації (перша «камера»). Потім він порівнює докази з показами свідків (друга «камера»). І нарешті, відвідавши саме місце події, детектив отримує повну картину того, що сталося (третя «камера»). 

Чотири роки тому команда Opex/Lean у GBS Clariant впровадила підхід 3D-камери для вирішення проблем на будь-якому рівні. Під час роботи вони завжди ставлять собі три ключові питання: що показують дані? що кажуть люди? що показує процес? 

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

Друга практика – 3-рівневе записування – допомагає навчитися слухати клієнта. Вона фіксує його голос на трьох рівнях: що клієнт говорить прямо, що він каже між рядками, і що він не говорить, але ми очікували почути. 

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

Нижче наведено приклад 3-рівневого записування під час розробки нового Клієнтського порталу. Очевидно, що між записами існують деякі невідповідності. 

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

Щоб точно «розшифрувати голос клієнта» і створити процес, який дійсно відповідає його потребам, команда Service Management у Clariant використала відому методику Lean Six Sigma – Critical to Quality (CTQ). 

Наприклад, під час розробки факторів успіху, критичних для виконання очікувань клієнта, звучало так: 

«Я хочу спілкуватися з кваліфікованим фахівцем через систему Ticketing Tool [платформа для комунікації з клієнтами, пов’язана з SAP], а не з оператором кол-центру». 

Ми почали з того, що визначили, що клієнт розуміє під професійністю та компетентністю. Іншими словами, ми перейшли від загального до конкретного. Інтерв’ю  з клієнтами дозволили сформулювати наступне: кваліфікований фахівець може вислухати вас до кінця без зайвих переривань (я був почутий); він знає правильні запитання після того, як вислухав вас (я був зрозумілий); і він вміє вирішити вашу проблему без непотрібних затримок і без необхідності відразу консультуватися з іншими. 

Ми використали CTQ Tree (Дерево критичних факторів якості), щоб детально розібрати очікування клієнта, зрозуміти їхню специфіку та перевести у ключові драйвери процесу. На завершальному етапі ми створили метрики для оцінки цих драйверів. 

На наступному етапі, коли система TT почала отримувати дані у вигляді вимірювань, був створений TT Dashboard – популярна система візуалізації з щоденними оновленнями. Завдяки цьому у нас з’явилися стандартизовані процеси взаємодії з клієнтом. 

Наступним кроком стало створення системи вирішення проблем, що виникають у клієнтів. Раніше проблеми вирішувалися тимчасово, клієнт повідомляв про проблему або залишав запит, система TT фіксувала його, агент створював запит і категоризував його, а далі намагався самостійно знайти рішення. Іноді це було просто: запит типовий, відповідь легка. Але іноді запит був складний і нетиповий. У таких випадках кожен агент шукав рішення по-своєму – іноді знаходив, іноді ні. І не завжди це працювало. Тож результати на TT Dashboard відображалися зеленим або жовто/червоним кольором, залежно від обставин. 

Щоб вирішити цю проблему, у 2019 році GBS Clariant запустила глобальну програму вирішення проблем на основі принципів Lean. Її назвали Structured Problem Solving (SPS) – «Структуроване вирішення проблем», з метою знаходження корінних причин. Для цього почали використовувати A3, лише у нас їх назвали SPS OnePagers. Під час спостережень у трьох центрах – у Польщі, Індії та Китаї – ми описали поточну ситуацію. 

Потім ми розробили різні навчання, практики та моделі симуляцій. Спершу ми додали коучинговий модуль – SPS Coaching Academy – до навчальної програми. Пізніше був створений SPS Mentoring Program. Усі ініціативи з вирішення проблем, так звані SPS кейси, зберігаються в центральній базі даних, до якої має доступ кожен співробітник. 

Щоб контролювати дотримання нового підходу до вирішення проблем, ми ввели два показники: In Full (повне виконання) та On Time (вчасне виконання). Програма SPS працює вже чотири роки і має на меті перетворити кожного співробітника GBS Clariant на ефективного вирішувача проблем. 

До цього часу операційна модель програми SPS зосереджувалася на формуванні концепції, розвитку навичок, популяризації культури вирішення проблем і створенні SPS Framework. Цю мету було досягнуто наприкінці 2021 року. 

Цього року ми поставили нове завдання: використати технологію TT для створення моделі, у якій: 

• проблеми системно ідентифікуються; 

• проблеми відокремлюються від інцидентів; 

• визначені проблеми описуються за трьома атрибутами: масштаб, вплив, ціль. 

• базові вимірювання розраховуються правильно та системно; 

• кожна проблема отримує відповідального за її вирішення; 

• передбачена підтримка у вигляді коучингу та менторингу від Service Management; 

• всі дані системно фіксуються у базі CPTT; 

• старт і завершення циклу DMAIC активуються автоматично. 

Команда Service Management оновлює базу даних інцидентів і проблем з двома цілями: 

1. Повторювані інциденти перетворюються на проблему.
   Коли певний інцидент трапляється регулярно, Service Management створює SPS-кейс, часто пов’язаний із IT-відділом, який відповідає за роботу платформи TT, і вирішує проблему. У довгостроковій перспективі мета – щоб більшість типів інцидентів взагалі не повторювалася. Проблема, вирішена, не повертається, як бумеранг. 

1. Виявлені проблеми часто повторюються за певними шаблонами. Маючи базу таких проблем та ефективні інструменти бізнес-аналізу, команда Service Management може розпізнавати ці повторювані схеми. Знаючи шаблон, легко визначити типові причини та застосувати перевірені рішення. Так команда формує каталог коучингу та менторингу для майбутніх кейсів з аналогічними проблемами 

Нижче наведено приклад липневого звіту команди Accounts Payables. 

Нова операційна модель програми SPS має на меті підняти культуру вирішення проблем у GBS Clariant на новий рівень, поєднавши Lean-компетенції з технологіями. 

Завдяки цьому: 

• завдання не відкладаються, 

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

• чітко визначені відповідальні – лідери команди, у якій виникла проблема, відповідає за її вирішення. 

У Clariant GBS ми створили два напрямки у Service Management: 

• один розвиває культуру постійного вдосконалення; 

• другий займається робототехнікою та автоматизацією (RPA). 

З самого початку ми розуміли, що між ними потрібна синергія. На практиці це були спільні дзвінки, навчання ключовим методам та спільні проєкти. Але раніше співпраця Lean і RPA була радше випадковою, а не системною. 

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

Коли Чотиривимірний метод (4-D) допомагає оптимізувати процес, ми перевіряємо, чи можна його вигідно автоматизувати. Для цього процес має відповідати чотирьом критеріям: 

1. Вхідні дані цифрові або їх можна оцифрувати.
   Робот має «розуміти» ці дані. Сьогодні, завдяки штучному інтелекту чи Machine Learning, вони не обов’язково мають бути ідеально цифровими. 

1. Процес стандартизований і повторюваний.
   Робот не зможе автоматизувати те, що виконується по-різному кожного разу. 

1. Всі розгалуження процесу підпорядковані логічним правилам.
   Наприклад, умови «якщо OK – тоді…», «якщо  НЕ OK – тоді…» повинні бути чіткими і передбачуваними, без суб’єктивного рішення. 

1. Автоматизація має бути економічно вигідною (ROI).
   Створення та підтримка робота має приносити реальний ефект. 

Модель співпраці Lean та RPA у пілотних проєктах працює так: 

• спершу – Lean Stream (4 кроки Чотиривимірного методу); 

• потім – RPA Stream (перевірка 4 критеріїв автоматизації). 

Щоб краще орієнтуватися на клієнта, Service Management змінила структуру команд та спосіб їх роботи. Було повністю об’єднано команди Technology (CIP), Opex/Lean та RPA. 

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

2022 рік став останнім, коли ми використовували традиційні методи управління проектами. 

Як перевірити, чи орієнтовані ми на клієнта 

Без вимірювання неможливо знати, наскільки ми успішні. Ми можемо покращувати проекти, змінювати структури, впроваджувати нові методи та розвивати компетенції, але як переконатися, що клієнт дійсно в центрі нашої роботи? 

Вимірювання орієнтації на клієнта дає чітке уявлення про досвід клієнта. Для цього достатньо трьох простих критеріїв: 

1. Чи почутий клієнт? 

1. Чи зрозуміли його потреби? 

1. Чи професійно вирішується його запит? 

Якщо клієнти підтверджують, що ці три умови дотримані, стає очевидним: клієнт дійсно в центрі всього, що ми робимо. 

Джерело статті: https://www.planet-lean.com/articles/customer-centricity-clariant

Хочете так само підвищити якість сервісу та зробити обслуговування клієнтів ефективним і приємним?

Приєднуйся до курсу «Клієнтський сервіс: Lean та TQM на практиці» та дізнайся, як застосовувати Lean-підходи, цифрові інструменти та методи TQM на реальних кейсах.

https://lean.org.ua/education/online-courses/client-service/