Есо-Автотехнікс, трейдер автозапчастин

"Есо-автотехнікс" - один з найбільших трейдерів автозапчастин в Україні, що спеціалізується на оптових поставках автомобільних запчастин магазинам, СТО, партнерам і дилерам у регіонах. На початку літа 2002 року компанія набрала "критичну вагу" проблем, достатню для проведення радикальних змін. По-перше, до цього часу вона істотно збільшила асортимент, оскільки тільки декілька місяців тому освоїла шість нових напрямків бізнесу, кожен з яких допускав у середньому від 2 до 5 тис. нових товарних позицій. У свою чергу, ефективна робота кожного напрямку стала неможлива без низки аналітичних звітів, як консолідованих, так і тих, що відображають ефективність по окремих позиціях. По-друге, приблизно в цей час компанія вийшла на рівень національного оператора (ще три роки тому її сприймали як локального постачальника з досить непоганим асортиментом).

Звичайно, такий рівень організації бізнес-процесів, а також програмне забезпечення, що застосовувалось, вже не дозволяли працювати достатньо гнучко, щоб використовувати всі наявні на ринку можливості. І оскільки необхідність докорінних змін була відчутна у всіх структурних підрозділах одночасно, топ-менеджери вирішили, що найбільш правильним кроком у даній ситуації буде зміна бізнес-процесів і об'єднання їх у єдине ціле за допомогою ERP-системи. Затвердженню остаточного рішення передувало спільне засідання вищого керівництва та інвесторів із презентацією спеціально розробленого бізнес-плану. При цьому ефект від впровадження оцінювався за рівнем росту обсягів продажів.

Для вибору постачальника ERP-рішення "Есо-автотехнікс" провела тендер. Крім пошуку найкращого співвідношення ціна/якість, метою тендера було налагодження особистого контакту з менеджментом кожної з консалтингових компаній. Основним критерієм відбору був "якісний продукт за гроші, на які розраховувала компанія". В результаті тендер виграла компанія Іnnoware, що запропонувала рішення на основі Mіcrosoft Busіness Solutіons Navіsіon (зараз Mіcrosoft Dynamіcs NAV).

Для уточнення та пріоритизації завдань проекту впровадження консультанти компанії Іnnoware спочатку провели діагностику існуючих в "Есо-автотехнікс" процесів. На це, а також на формалізацію бачення цілей впровадження і визначення проектних ризиків пішло в цілому 10 робочих днів. Першочерговими завданнями були встановлені:
* комплексний фінансовий облік;
* мінімізація невиправдано великого складу;
* розробка цілісної методики роботи компанії.
За результатами діагностики на початку серпня 2002 р. був підписаний договір і проект з впровадження ERP-системи стартував. Разом з тим топ-менеджмент "Есо-автотехнікс" поставив чітку умову запустити систему в січні 2003 року. Прив'язку саме на початок року зробили з таким розрахунком, що, крім достатньої кількості вихідних днів і мінімальної ділової активності в перших числах січня, цей варіант був оптимальним для перенесення даних бухгалтерського і фінансового обліку.

Особливо важливо те, що проект одержав максимальний рівень пріоритету відносно поточних бізнес-завдань.

Розробка нових бізнес-процесів

Коли визначена мета, наступним кроком стає створення концептуального дизайну нової системи, інакше кажучи, розробка бажаних бізнес-процесів. Для цього консультанти запропонували використати типову для більшості впроваджень у середніх компаніях схему. Спочатку були визначені ключові користувачі, найчастіше це керівники відділів або напрямків і топ-менеджмент, у цьому випадку генеральний директор, фінансовий директор, директор з продажів і маркетингу та керівники підрозділів. Потім були описані бізнес-процеси, "які існують" і "якими вони повинні бути". Описом займалися консультанти Іnnoware на основі даних, одержуваних від ключових користувачів, які в майбутньому будуть супроводжувати ці процеси (провідні спеціалісти напрямків). Такий варіант був обраний через досить високу кваліфікацію персоналу і його високу мотивацію. Відповідно до стандарту основні критерії для затвердження певного процесу – це (1) бачення ключових користувачів, (2) досвід реалізації подібних рішень консалтинговою компанією і, нарешті, (3) можливості системи. Останні не безмежні, крім того, кожен продукт звичайно має кілька попередньо налаштованих варіантів організації того або іншого процесу. Тому якщо серед них є хоча б один, що дозволяє уникнути змін у системі, варто зупинитися на ньому. Це мінімізує кількість помилок на первинних етапах експлуатації і дозволяє залишитися в рамках запланованого бюджету проекту впровадження.

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

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

По-друге, виявилося, що через недостатньо ефективну комунікацію в компанії, розуміння цілей впровадження відрізнялося на різних рівнях. У підсумку близько 30% змін було внесено вже "по живому" під час розробки дизайну і модифікації системи. Частину підходів запропонувала консалтингова компанія (широко застосовувана практика). Крім того, менеджмент переглядав свої погляди на різні процеси в міру еволюції власного сприйняття зовнішнього середовища і можливостей продукту. Таким чином, кінцевий результат не міг збігтися з початковим баченням.

Тестування системи почалося тільки в грудні, паралельно тривали доробки, але запуск все-таки відбувся 9 січня (перший тиждень місяця був вихідний, але підготовчі роботи велися вже з другого числа). Наступні два місяці були дійсно важкими, але, як не парадоксально, зменшення продажів не відбулося. Компанія не зупинилася, однак виникали непорозуміння з клієнтами у зв'язку з неправильним оформленням документів і цілою низкою технічних помилок. Більше половини з них з'являлися через недостатню підготовку персоналу. Про це особливо важливо пам'ятати тим, у кого в системі одночасно працює кілька десятків користувачів, тому що в таких випадках кількість помилок зростає в геометричній прогресії і в найкоротший термін досягає критичного для роботи системи рівня. У цьому випадку проблеми виникли через нестачу часу: на навчання персоналу було витрачено всього три дні (більше часу просто не було).