Перебудова управління закупівлями. Секрети польового консалтингу від першої особи

Пролог

Роздуми про те, чим відрізняється ERP від системи автоматизації на тлі одного показового проекту впровадження.

1.ВСТУП

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

«Стара система» створювалась під користувача. Шляхом невпиної «кастомізації», як це було модно, і декими фахівцями вважається правильним і досі. Тобто є, наприклад, менеджери з закупівель, ми припускаємо, що вони знають, як працювати, ми їх питаємо: чого Вам треба, щоб вчасно закупати товари в потрібній кількості. Вони нам кажуть - «нам потрібно щоб була можливість подивитись на продажі за якийсь період, на складський залишок, і з цього ми самі вже визначимо скільки чого потрібно купити, і от тут щоб була можливість ввести цю цифру, і щоб автоматично постачальник підтягнувся, і закази створились». Ну, ми - ок. Все ясно, зробимо таку форму. Зробили, працюйте. Як користувачі усим цим користуються, і що це дало, нас взагалі-то і не обходило. Товарів було 10000 приблизно.

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

Але ось на що я звернув увагу. Під час цієї трансформації було витрачено десятки годин на якусь безглузду полеміку з менеджерами з закупівель про те, що «так воно працювати не буде». Це було дуже дивно тому, що менеджери дискутували зі мною про якість підходів до проектування, коли обидва з цих підходів були моїми. І я чітко бачив, що так, як вони працюють зараз, фізично неможливо ефективно обробляти такі великі обсяги даних в потрібні терміни. Все одно, що копати маленькою лопатою велику яму. А я ж сержант ЗСУ, чорт забирай, я знаю, що аби зробити капонір під пушку, наприклад САУ 2С3, потрібно 10 солтатиків на 10 днів (чи ночей, якщо вдень копати неможна), або 1 екскаватор на 10 годин. Тобто, що тут порівнювати. Але все одно зі мною сперечались, та так запекло, що все це нагадувало якийсь химерний баттл «копачі проти бульдозериста».

2. БАЗОВІ ІДЕІ

З початку невеликий коментар, аби був зрозумілим загальний контекст. Компанія, для якої ми виконували цей проект, на мій погляд, особлива. Парадигма така, що вони не торгують під замовлення, не працюють на корпоративному ринку (тендери і таке інше), а забезпечують замовлення тільки зі складу. Товар, який замовлений сьогодні, сьогодні і буде відправлений. Тобто такий максималістський, безкомпромісний підхід. Самураї дистрибуції.

ТОписаний вище підхід клієнта до ведення справ ставив дуже специфічні вимоги перед всіма схемами забезпечення складу (а мова далі піде саме про управління закупівлями). Довелося ретельно вивчати матчасть. Дуже допоміг семінар «Управління ланцюжками постачань», який, свого часу, проводив Гаврилов. Як це завжди буває, з самого семінару я не виніс майже нічого, окрім загального позитивного враження, і методички. Але саме це , в підсумку, і знадобилось.

Я детально розповідав про цю методологію в січні 2022 року тут же на CIO JAZZ, але для тих хто не в курсі коротко повторю базові тезіси.

Вся ідея базується на тому, що в кожній точці часу потрібно визначати потребу в закупівлі відносно показника Рекомендований страховий запас, а, власне, наука в тому, як саме цей «Рекомендований страховий запас» вираховувати. Цікаво, що розробники всіх ERP, які мені довелося вивчати, пишуть у своїх прес-релізах просто:

Тобто, ніхто з розробників не заморочується – визначте рекомендований запас і керуйте. Тож як же його визначити ? Формула із згаданої методички виглядає так :

Тут
P - прогноз продаж на 1 день по каналу (наразі у клієнта є 4 канали продажів)
S - стандартное відхилення прогноза по каналу
K - коеффіцієнт рівня обслуговування
D - періодичність постачання

P – прогноз продажів на день. Беремо середньозважені продажі в кількості за 28 днів (4 минулих тижня), насправді трохи складніше тому, що для товарів, яких не було на складі, використовуються ще показники відвідин користувачами сторінок товара на сайті, але для спрощення приймемо так.

S – стандартне відхилення прогноза. Це в штуках. Тобто, наприклад, прогноз був 10, по факту продали 12, відхилення 2. Є математична формула розрахунку стандартного відхилення, і є функція STDEV в Excel. З практичної точки зору, щоби розрахувати цей показник потрібно мати прогнози, які ми давали, наприклад, на минулий тиждень, і на позаминулий, і далі. І, звісно, факти цих тижнів. Природно виглядає писати прогноз в регістр і потім порівнювати. Додали регістр.

D – періодичність постачання. В BAS ERP цей показник записаний прямо в довіднику «Способи забезпечення потреб». Тобто тут, начебто, і додавати нічого не потрібно було. Хоча особисто я вважаю це хибним рішенням, бо періодичність постачання номенклатури не може не збігатися з періодичністю роботи Постачальника. Адже номенклатур 50000, а постачальників, скажімо 250. Тож ми трохи підкорегували типову конфігурацію і додали регістр з періодичністю, який заповнювався автоматично шляхом аналізу графіків роботи всіх постачальників, де цей товар колись закуповувася.

K – коеффіцієнт рівня обслуговування. Не всі товари заслуговують на однакову увагу. В типовій конфігурації є чудові механізми ABC/XYZ классифікації. Прийнявши ці механізми за основу, ми визначили коефіцієнт як таблицю (додали регістр):

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

І от далі почалося найцікавіше – оранізаційні зміни. Ось останній слайд презентації з CIO JAZZ січня 2022 року.

З цього місця і продовжуємо.

3. ОРГАНІЗАЦІЙНІ ЗМІНИ

У підсумку, за час від початку до завершення проекту всіх менеджерів поміняли 3 рази, і, врешті решт, система запрацювала так, як було задумано, хоч проект і розтягнувся на додаткових 2 роки. І все сталося так, як сталося, це мене особливо тішить, завдяки тому, що всі ідеї, які було закладено в цю роботу, були добре описані, сприйняті власником бізнесу і великий шлях організаційних змін вони подолали самі, поки мене не було поруч (я пішов на війну), маючи ці ідеї за дороговказ.

Так от. Коли запрацювали всі ті роботи, яких ми наробили, і ті, які вже були в типовій конфігурації, виникло питання, а що повинні робити люди в цих нових умовах ?

Тут, знов таки, знадобилась теорія. А саме, довелося згадати про PDCA цикл. Зубрам консалтингу пояснювати не треба, для всіх інших - мова про так званий цикл Демінга:

• PLAN - встановлення цілей та процесів, необхідних для досягнення цілей, планування робіт з досягнення цілей процесу, планування виділення та розподілу необхідних ресурсів;
•  DO - виконання запланованих робіт;
•  CHECK - збирання інформації та контроль результату на основі ключових показників ефективності (KPI), що вийшов у ході виконання процесу, виявлення та аналізу відхилень, встановлення причин відхилень;
•  ACT - вжиття заходів щодо усунення причин відхилень від запланованого результату, змін у плануванні та розподілі ресурсів.

З точки зору архітектури інформаційних систем класу ERP (англійська абревіатура, яка перекладається як «планування ресурсів підприємства») термін «управління» буквально означає виділення об'єктів, які фіксують прийняті рішення (PLAN), та об'єктів, які фіксують виконання прийнятого рішення (DO), а також наявність механізмів, які як підтримують процес прийняття рішень, так і дають можливість оцінити наслідки виконання цих рішень (CHECK).

Але це тільки половина справи. Інша половина в тому, що у кожного процесу має бути власник, і йому дуже важливо розуміти, що 4 елементи циклу Демінга вкупі є своєрідною «таблицею Мєндєлєєва» в якій кожний крок має знайти своє місце.

Але це тільки половина справи. Інша половина в тому, що у кожного процесу має бути власник, і йому дуже важливо розуміти, що 4 елементи циклу Демінга вкупі є своєрідною «таблицею Мєндєлєєва» в якій кожний крок має знайти своє місце.

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

А ось так має виглядати схема процеса в парадигмі PDCA:

Чим корисний такий підхід до візуалізації ? На мій погляд тим, що показує:

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

2. Визначати потребу, проводити саму закупівлю, та аналізувати якість, повинні різні люди (або підрозділи), які, вочевидь, не мають підпорядковуватись прямо один одному.

Відповідно в структурі підприємства на одному ієрархічному щаблі з керівником відділу закупівель повинна з’явитись окрема посада «Аналітик» (це функція PLAN), і, логічно припустити, що у них повинен бути загальний керівник, який і є власником цього бізнес-процесу (функція АСT). Саме так і зробили.

При цьому загальна кількість учасників процесу трохи скоротилася, про фонд заробітної плати не скажу, бо не знаю. Але як були розподілені повноваження ?

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

Менеджери відділу закупівель (DO) – розсилають замовлення постачальникам, збирають відповіді (можливо постачальник не взмозі поставити потрібну кількість), уточнюють особливості постачання (кількість місць, час приходу машини, та ін).

Керівник відділу постачання (CHECK) – забезпечення безперервності поставок - для кожної позиції групи “A” повинно бути знайдено щонайменше 2 постачальники, так щоби їхні графіки поставки сукупно закривали 4 дні тижня. Домовляється про зміну графіків з постачальниками.

Заступник директора з виробництва (ACT) - власник бізнес-процесу, аналізує зміни показника якості роботи відділу постачання за тиждень (про це далі), приймає рішення, щодо заходів покращення їх роботи.

4. ФУНКЦІЯ CHECK. ОЦІНКА ЯКОСТІ

Коли всі учасники процесу зайняли свої місця, постало питання, як визначити KPІ роботи відділу закупівель ? Це непересічне питання. Я наведу власний ланцюжок міркувань :

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

Ця ідея була прийнята, але ось, що відбувалось на практиці.

Графік за 16 тижнів. Цікаво, що лівіше і правіше від жовтої смужки той самий програмний код і ті самі люди, але добре видно, що на 9 тижні (жовта смужка) щось раптово почало відбуватись. Бульдозер нарешті завели ?

5. РОЛЬ ВЛАСНИКУ ПРОЦЕСУ

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

Частина проблеми дійсно була в тому, що ми, свого часу, не встигли описати в регламентах і інструкціях, як все має працювати. Тобто користувачів ми начебто навчили, але люди мінялись, їм передавали якісь інструкції, котрі, як потім виявилось, писали для себе їх попередники зі слів своїх попередників. На додаток все це обросло легендами і міфами. Жах. Тиждень ми разом займались відновленням істини. Далі вони самі. Далі знову тиждень разом. Далі 2 тижні самостійно. І от, нарешті, з 3-ї ітерації, процес став приносити стабільний результат, на який я і розраховував з самого початку. Тоді ж з’явився і регламент, який це все описував.

ВИСНОВОК

ERP це не коли є гарний програмний код, а це коли гарний програмний код + побудований процес з ясним прозорим KPІ + написаний регламент + навчені користувачі + навчений і свідомий власник процесу. І чарівний пєндєль, звісно
А інакше це все просто автоматизація…

Сергій Бутенко, ТОВ «ПРОКОМ»

Січень 2024 р.