Принцип першого керівника на впровадженні ERP системи

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

Просте правило: хто управляє – той приймає рішення, хто приймає рішення – той і відповідає за результат. У теорії та практиці проєктного менеджменту – це роль керівника проєкту. Проте, хто б не виконував цю роль, максимально залученим, зацікавленим та переконаним у потрібності змін на підприємстві має бути CEO або власник бізнесу, що своєю чергою зобовʼяже керівників підрозділів, функціональних менеджерів, просувати ці зміни. Якщо ви не залучаєте вище керівництво, ви можете витратити час на налаштування свого рішення лише для того, щоб з’ясувати, що кінцевий результат не відповідає вимогам керівництва.

Ситуація з досвіду на одному з проєктів

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

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

Так, в ситуації організаційної невизначеності, наша команда узялася до розробки нової ERP системи. В результаті обговорень дату старту таки відсунули ще на 3 місяці. Автоматизації підлягало два напрямки бізнесу — b2c та b2b. В обидвох напрямках був свій лінійний керівник (топ-менеджер), кожен з яких підзвітний лише напряму власнику і не співпрацював один з одним. Крім того, під цими керівниками стояли керівники відділів, які також мали право скеровувати роботу своїх підлеглих та впливали на їхнє ставлення до переходу на нову систему. При цьому користувачів системи налічувалося понад сто. І, нагадаю, в цьому коловороті управлінців Замовником та керівником проєкту виступала людина без авторитету, але наближена до власника підприємства. 

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

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

Ми таки перейшли на нову систему і завершили проєкт впровадження в задані терміни ціною неймовірних зусиль. Але цей “експеримент” міг закінчитися повним провалом і саме через порушення принципу першого керівника. І ще показовим було питання від власника компанії через три місяці після переходу на нову систему, - для чого ми відмовилися від старої системи та чому вирішили почати проєкт розробки й впровадження нової? Відповіді в мене не знайшлося, настільки несподіваним виявилося питання.                                                                                                                                                                                              

Висновок

Про старт проєкту треба домовлятися безпосередньо з вищим керівництвом.

Спонсор проєкту, Керівнику проєкту, Власник продукту, хто б це не був, він повинен надавати всебічну підтримку проєкту. Тому ним обов’язково має бути вищий керівник, особа, наділена владними повноваженнями та особисто зацікавлена в успіху проєкту.

в ERP
# ERP
Увійти залишити коментар
Захист даних в ERP системах
Загальні підходи до безпеки, конкретні технології та методики, які можуть використовуватися для захисту даних, а також виклики та кращі практики в області захисту даних ERP систем