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