Замовлення не повинно жити між чатами, таблицями і пам’яттю людей
Я б не починала з екрана "Замовлення". Спочатку я б взяла одне реальне замовлення і пройшла його разом із людьми, які працюють із ним сьогодні.
Звідки воно приходить? Сайт, телефон, месенджер, електронна пошта або менеджер створює його сам? Які дані вже відомі? Що потрібно уточнити? Хто перевіряє наявність? Коли ціна вважається остаточною? Чи потрібно чекати оплату? Хто дає складу команду комплектувати?
Саме між цими питаннями зазвичай і ховається більша частина ручної роботи.
Тому для мене замовлення - це не просто запис у таблиці. Це процес, який поступово переходить із одного зрозумілого стану в інший.
Що я хотіла б знати про замовлення одразу
Не всі ці дані обов’язково вводяться вручну. Частину система вже може знати з клієнта, товару або попередніх домовленостей.
Хто клієнт
Контакти, реквізити, умови роботи, адреса доставки та важливий контекст попередніх замовлень.
Що він замовляє
Товар, кількість, варіант, одиниця виміру та інші параметри, які впливають на виконання.
За якою ціною
Ціна, знижка, індивідуальні умови та момент, після якого домовленість уже не повинна змінюватися непомітно.
Що з наявністю
Чи є товар зараз, чи його вже зарезервовано для іншого клієнта, чи очікується надходження.
Що з оплатою
Чи потрібна передоплата, відстрочка, часткова оплата або інше правило до початку відвантаження.
Що має статися далі
Хто зараз відповідає за наступну дію і що саме має перевести замовлення на наступний етап.
Як я б побудувала основний шлях замовлення
Конкретні назви статусів можуть відрізнятися між підприємствами. Для мене важливіше, щоб кожен етап мав зрозумілий зміст.
Замовлення отримано
Система фіксує сам факт звернення і початкові дані. Замовлення вже не повинно існувати тільки в чаті або записнику менеджера.
Дані перевірено
Контакти, позиції, кількість, ціна, доставка та інші обов’язкові умови достатні для подальшої роботи.
Наявність підтверджено
Зрозуміло, що можна відвантажити зараз, що потрібно зарезервувати і де потрібна закупівля або очікування.
Умови погоджено
Клієнт і компанія мають однакове розуміння ціни, кількості, терміну, доставки та оплати.
Фінансова умова виконана
Якщо процес вимагає передоплати або іншої фінансової перевірки, вона підтверджена до наступного критичного кроку.
Замовлення передано на комплектацію
Склад отримує не повідомлення "десь у чаті", а чітке завдання з актуальними позиціями та кількістю.
Комплектацію підтверджено
Фактично підготовлена кількість перевірена. Якщо чогось не вистачає, проблема стає видимою до відвантаження.
Документи підготовлено
Потрібні документи формуються з тих самих даних замовлення, а не вводяться повторно в кожному наступному місці.
Відвантажено
Фіксується фактична передача товару, дата, кількість і відповідальна операція.
Замовлення завершено
Компанія має зрозумілий фінальний стан, а історія всіх важливих змін залишається доступною.
| Етап | Хто діє | Що переводить далі |
|---|---|---|
| Отримано | Менеджер або автоматичний канал | Достатньо даних для перевірки |
| Перевірка | Менеджер | Умови замовлення підтверджені |
| Наявність | Система / склад / менеджер | Товар доступний або визначено інший сценарій |
| Оплата | Фінанси / система | Виконано потрібну фінансову умову |
| Комплектація | Склад | Фактична кількість підготовлена |
| Документи | Система / відповідальна роль | Документи готові |
| Відвантаження | Склад / логістика | Факт передачі підтверджено |
Найпростіший сценарій майже ніколи не є найцікавішим.
Набагато важливіше ще до розробки запитати: що робимо, якщо товару не вистачає? Якщо клієнт змінив кількість після погодження? Якщо оплатив лише частину? Якщо одну позицію можна відвантажити зараз, а іншу через тиждень? Якщо склад під час комплектації знайшов розбіжність?
Я б не намагалася заховати такі ситуації в коментарях до замовлення.
Якщо виняток повторюється, він уже є частиною бізнес-процесу і повинен мати зрозумілий сценарій.
Після цього керівнику вже не обов’язково переглядати кожне замовлення.
Набагато корисніше бачити винятки: замовлення без підтвердженої наявності, прострочену оплату, комплектацію, яка триває довше звичайного, замовлення з частковим відвантаженням або ті, що повернулися на попередній етап.
Тобто хороша система не просто зберігає статус. Вона допомагає відповісти на питання: де зараз потрібна увага людини?
Коротко про процес від замовлення до відвантаження
Конкретний процес у кожного підприємства свій, але кілька принципів повторюються дуже часто.
Чи потрібні всі ці статуси кожному бізнесу?
Чи повинна система автоматично резервувати товар?
Що робити з частковим відвантаженням?
Чи потрібно прив’язувати оплату до замовлення?
Що робити, якщо менеджер має право зробити виняток?
З чого почати автоматизацію такого процесу?
Як я б побудувала цей процес
У цій серії я беру один реальний бізнес-процес і розбираю його крок за кроком: які дані потрібні, хто приймає рішення, де виникають винятки і що можна прибрати з ручної роботи.
Є процес, який тримається на таблицях, чатах і пам’яті людей?
Його не обов’язково одразу замінювати великою системою. Спочатку можна розкласти процес крок за кроком: де починається робота, хто приймає рішення, де дублюються дані і які операції створюють найбільше зайвої роботи.
