Склад повідомляє про пошкоджену палету. Перевізник отримує фотографії. Команда обслуговування клієнтів запитує, чи потрібно організувати заміну. Операційна команда з’ясовує, хто може її погодити.
Усі бачать проблему. Клієнт досі не може отримати рішення.
В Allmatics ми розглядали б це як завдання з розробки програмного забезпечення, що охоплює складські, транспортні системи, системи управління замовленнями та обслуговування клієнтів. Потрібно об’єднати їхні дані, дати працівникам спільний інтерфейс для перегляду й виконання дій та забезпечити виконання погоджених рішень до підтвердженого результату.
Нижче наведено детальний приклад проєктування, а не історію клієнта Allmatics. Розглянемо ситуацію, коли команда приймання повідомляє про пошкоджений товар. Правила погодження, строки та подальші дії мають відповідати реальному робочому процесу й комерційним домовленостям.
Почніть із рішення, потрібного клієнту
Ми почали б аналіз процесу разом із тими, хто приймає товар, погоджує рішення та виконує роботу. Яке рішення потрібне клієнту: продовжити виконання замовлення, замінити товар чи погодити інший варіант? Хто має право це дозволити та яка система фіксує рішення? Відповіді визначають робочий процес ще до вибору інтеграцій.
Відокремте фактичне вирішення проблеми з товаром від претензії до перевізника. Заміну можуть погодити, поки претензія ще на розгляді. І навпаки: номер зареєстрованої претензії не доводить, що клієнт отримав товар на заміну.
У цьому прикладі варто створити основну справу про пошкодження та два пов’язані напрями роботи: вирішення проблеми з товаром і розгляд претензії. Для кожного потрібні окремий відповідальний та критерій завершення. Обидва напрями мають бути видимі в картці справи, щоб поступ в одному не сприймали як завершення іншого.
Перетворіть повідомлення на справу, з якою можна працювати
Система має пов’язувати складські матеріали з відповідним замовленням і відправленням. Ми визначили б джерело кожного факту та ідентифікатори, які поєднують записи, а потім налаштували б фіксацію пошкоджених позицій і кількості, місця, автора повідомлення, часу події, системи-джерела, фотографій і приміток під час приймання. Відсутні дані мають залишатися помітними. Їх не можна замінювати припущеннями.
Опублікований кейс Allmatics зі сканування штрихкодів показує, як операційні дані стають основою корисного продукту: Android-застосунок збирає дані про роботу сканерів, а вебзастосунок дає змогу аналізувати їх і керувати користувачами через дашборд. У сценарії з пошкодженим вантажем ми розширили б цей підхід: від відображення даних до роботи зі справою. Матеріали мають стосуватися правильного відправлення та товарних позицій. Якщо фотографію прикріплено до іншої доставки, її потрібно передати на перевірку.
Надайте справі власний ідентифікатор. Подальші повідомлення мають приєднуватися до відповідної справи, а окремий інцидент має залишатися окремим. Не використовуйте лише ідентифікатор відправлення як універсальний ключ для виявлення дублів: з одним відправленням може виникнути кілька різних проблем.
Для інтеграцій зі стандартними чергами Amazon SQS документація AWS зазначає, що повідомлення може бути отримане більше одного разу, і рекомендує ідемпотентну обробку. На практиці це означає, що повторні спроби мають бути безпечними: повторна обробка тієї самої події не повинна створювати ще одну справу, повторне погодження чи додаткове повідомлення клієнту.
Призначайте відповідального за наступне рішення, а не лише відділ
Черга з назвою «Операційний відділ» допомагає спрямувати звернення. Але коли справа потребує дії, цього недостатньо для визначення відповідальності.
Для кожного активного етапу фіксуйте відповідальну людину або роль із визначеним чергуванням, потрібне від неї рішення чи завдання, строк виконання та того, хто підхопить роботу, якщо вона недоступна. Зміна робочої зміни не повинна залишати справу без відповідального.
Передачу справи потрібно підтвердити. Поки новий відповідальний її не прийняв, за неї відповідає поточний. Якщо ніхто не приймає справу, передайте її за заздалегідь визначеним резервним маршрутом, а не залишайте між двома чергами.
Очікування фотографій та очікування погодження потребують різних відліків часу. Починайте відлік під час переходу на відповідний етап. Повторна подія або ще одне нагадування не повинні непомітно запускати його заново. Якщо відлік дозволено призупинити, зафіксуйте причину й залиште видимою загальну тривалість справи.
Опишіть процес так, щоб його можна було реалізувати
Повідомлення отримано: створіть справу або знайдіть відповідну, додайте матеріали та направте на первинний розгляд. Перехід до наступного стану відбувається, коли відповідальний приймає справу.
Потрібні матеріали: запросіть відсутні дані у конкретного джерела. Перехід далі можливий після перевірки матеріалів або після рішення уповноваженої особи, яка зафіксувала, чому процес може продовжитися без них.
Потрібне рішення: покажіть відповідне замовлення, матеріали та дозволені варіанти дій уповноваженій особі. Перехід далі відбувається, коли вона фіксує рішення та його обґрунтування.
Очікується виконання: передайте погоджену вказівку відповідній системі або людині. Перехід далі можливий після підтвердження виконання. Самого успішного надсилання запиту недостатньо.
Результат підтверджено: перевірте погоджений результат щодо товару, зафіксуйте повідомлення клієнту та завершіть цей напрям роботи. Невирішена претензія до перевізника має залишатися видимою.
Передача на вищий рівень не повинна приховувати причину затримки. Прострочене погодження залишається у стані «Потрібне рішення» з позначкою про ескалацію, щоб команда бачила, що саме потрібно зробити далі.
Будуйте дашборд навколо рішень і дій
Для такого процесу ми створили б інтерфейс роботи зі справою, пов’язаний із системами-джерелами. Колега, який підхоплює роботу, має бачити матеріали, поточну перешкоду та дозволену наступну дію в одному місці, без відновлення історії з листування.
У прикладі з пошкодженою палетою покажіть: відправлення та замовлення; кількість пошкодженого товару; повноту матеріалів; стан вирішення проблеми з товаром; стан претензії; поточного відповідального; наступну дію; строк; причину затримки; час останнього оновлення кожного джерела.
Додайте дії відповідно до ролі користувача: запросити матеріали, прийняти справу, погодити дозволений варіант вирішення або підтвердити виконання. Збережіть доступ до історії рішень, попередніх значень і посилань на джерела.
Інтеграції мають передавати рішення в системи, які виконують роботу. У нашому прикладі повідомлення під час приймання створює справу. Якщо система це підтримує й є відповідний дозвіл, вказівка в системі управління запасами блокує використання пошкоджених позицій. Команда обслуговування клієнтів фіксує погоджений варіант вирішення, вказівка про затверджену заміну надходить у систему управління замовленнями, а дані про виконання повертаються до справи. Дашборд показує, чи кожна дія очікує виконання, підтверджена або завершилася помилкою, і дає можливість повторити її чи передати на перевірку.
Доступність даних у реальному часі залежить від джерела. Якщо система передає події, оновлюйте відображення на їхній основі. Якщо перевізник або застаріла система підтримують лише періодичні перевірки, чесно показуйте цю частоту. Стара відповідь не повинна виглядати як актуальний факт.
Окрім обробки подій, передбачте звіряння: порівнюйте дані в картці справи з записами в системах, які є першоджерелами. Це допоможе виявляти та виправляти пропущені оновлення, невиконані команди й застарілі стани.
Визначте, що можна автоматизувати, а де потрібне погодження
Саме тут доречні компетенції Allmatics в інтеграції систем та автоматизації процесів. Ми реалізували б погоджені правила через перевірку матеріалів, розподіл завдань, запити відсутньої інформації, контроль строків і виконання затверджених дій у пов’язаних системах. Команда отримує актуальний операційний дашборд там, де джерела це дозволяють, і процес, який продовжується після перегляду даних. Для дій із суттєвими наслідками зберігаються погоджені з бізнесом права доступу та правила перевірки.
Повідомлення про пошкодження не означає автоматичного встановлення відповідальності перевізника. Так само мовна модель не повинна погоджувати повернення коштів або визначати, чи безпечно дозволити використання товару, лише тому, що сформувала переконливе пояснення.
Якщо AI допомагає читати примітки чи узагальнювати матеріали, зберігайте оригінали та можливість перевірити результат. У процесі все одно потрібні визначений відповідальний за рішення й явний дозвіл перед діями, що мають суттєві наслідки.
Перевірте складні ситуації до запуску
Надішліть ту саму подію двічі: система має зберегти один інцидент і не надсилати повторну вказівку.
Завантажте матеріали щодо іншого відправлення: система має позначити невідповідність, а не продовжити процес.
Передайте справу недоступному колезі: відповідальність має залишатися визначеною, а завдання має надійти резервному відповідальному.
Зімітуйте помилку запиту на заміну після погодження: справа має залишатися відкритою, а невиконана дія видимою.
Завершіть заміну, поки претензія ще не вирішена: напрям роботи з товаром можна закрити лише на підставі власних підтверджень, а претензія має залишитися відкритою.
Вимірюйте час очікування, а не лише кількість завершених справ
Відстежуйте час від повідомлення до прийняття справи відповідальним, від прийняття до погодженого рішення та від рішення до підтвердженого результату. Показуйте медіану й тривалість найбільш затяжних справ, наприклад 90-й перцентиль, щоб незвично повільні випадки не губилися в середніх значеннях.
Також відстежуйте прострочені етапи, справи без відповідального, який підтвердив прийняття, невиконані дії в зовнішніх системах і повторно відкриті справи щодо товару. Визначте, які типи інцидентів порівнюєте та чи відлік ведеться в календарних або робочих годинах. Зберігайте можливість перевірити час призупинення та його причину.
Окремо вимірюйте строк розгляду претензії до перевізника. Інакше тривале з’ясування обставин може приховати, чи вчасно клієнти отримують рішення щодо свого товару.
Почніть з одного типу інциденту та об’єднайте весь процес
Рішення Allmatics для логістики охоплюють відстеження, аналітику та інтеграцію з наявними транспортними системами й IoT-пристроями. У такому проєкті ми об’єднали б ці програмні компоненти навколо одного погодженого операційного результату: аналіз процесу, пов’язані дані, інтерфейс справи, правила роботи, дії в системах і перевірка виконання.
Кейс зі сканування штрихкодів демонструє збирання та аналіз операційних даних. Описаний тут процес роботи з пошкодженим вантажем є пропозицією щодо проєктування, а не твердженням, що Allmatics уже розробила систему управління претензіями за пошкодження.
Перша реалізація має охоплювати один тип інциденту до підтвердженого результату. Погодьте правила ухвалення рішень, визначте системи-першоджерела для кожного факту, створіть інтерфейс та інтеграції, а потім перевірте повторні спроби, невиконані дії та передачу справ між змінами. Це дасть операційній та інженерній командам повноцінний процес для оцінки перед додаванням інших типів нестандартних ситуацій.
Щоб оцінити потрібні програмні компоненти, перегляньте логістичні рішення Allmatics. Почніть аналіз процесу з одного запитання: якщо людина, яка повідомила про інцидент, завершує зміну, чи бачить наступний колега, що потрібно зробити, хто за це відповідає та чим буде підтверджено виконання?