C чого почати впровадження ERP +1
- 30.07.17 10:14 •
- JustRamil •
- # 334466 •
- Хабрахабр •
- 1 •
- 2800
- такий же як Forbes, тільки краще.
У минулій статті я розповідав про те, Що таке ERP система. а також про те, в яких випадках впровадження цієї програмної системи принесе реальну користь, і на що звертати увагу при виборі ERP. А зараз я хочу поговорити про те, як отримати практичну користь від ERP-системи. А для цього програмний продукт необхідно впровадити.
Найважливіше питання, яке виникає напередодні впровадження будь-якої програмної системи, це «з чого почати»? Якщо ви знаєте, як і з чого починати впровадження, і почнете роботу правильно, скоріше за все, процес пройде без зайвих складнощів, переробок і конфліктів. А результат виправдає очікування бізнесу.
Різні підходи до впровадження
Існує кілька підходів до впровадження ERP-систем, які я бачив в чужому виконанні і / або сам застосовував на практиці. Кожен з них має свої плюси і мінуси, якісь «підводні камені» і переваги.
В принципі, всі підходи до впровадження ERP, також актуальні для будь-яких складних систем, наприклад, 1C УПП, 1С ERP, SAP Bussines ONE, ODOO і ін. Давайте про них поговоримо детальніше.
Підготовка технічного завдання
ERP-система - це продукт дуже технологічний. А тому як у розробників, так і у бізнесменів дуже часто виникає спокуса по максимуму розпланувати впровадження ще до початку робіт. Здавалося б, все логічно. При такому підході виходять з того, що технологічна програмна система повинна бути максимально алгоритмизировать. І до процесу впровадження можна і потрібно підходити з точки зору алгоритмізації і математичної моделі.
Як це реалізують:
- Створюється об'ємне технічне завдання, в якому по максимуму продумані і описані всі процеси, включаючи найдрібніші.
- Під технічне завдання створюється календарний план робіт.
На складання подібного технічного завдання можуть піти місяці. Я особисто бачив, як фахівець становив технічне завдання по впровадженню ERP протягом півроку. У цей період він регулярно виїжджав на об'єкт, вникав в усі нюанси і вносив їх у документ.
Від такого підходу плюси отримують, перш за все, розробники:
- Документ Технічне завдання буде коштувати дорого. Виконується великий обсяг роботи, який займає чимало часу. І замовники зазвичай погоджуються з високою ціною техзавдання без будь-яких питань.
- Розробники отримують детальну інструкцію, на основі якої можна проводити роботи. А в разі невдалих рішень, наявних у підписаному ТЗ, переробки будуть оплачуватися окремо.
Мінус підходу полягає в його обсязі і складності. Створити всеосяжне технічне завдання, в якому будуть передбачені всі модулі, документи, всі нюанси майбутньої роботи неможливо. Система багатофункціональна, і будь-які зміни в одному модулі можуть спричинити за собою необхідність внести зміни в інший.
Аналогічно і з помилками при складанні технічного завдання: будь-які неправильні рішення в одному модулі можуть спричинити за собою безліч змін в інших. Наприклад, якийсь бізнес-процес міг бути зрозумілий не вірно, і тоді при впровадженні з'ясується, що частина документації і довідників - не потрібні, а потрібні зовсім інші. Занадто великий обсяг інформації, занадто висока складність системи - в результаті, виявляється неможливо закласти спочатку всі нюанси і передбачити всі можливі помилки.
У моїй практиці був випадок, коли я прийшов на підприємство обговорювати впровадження нового програмного продукту (я був керівником проекту), і мені представники бізнесу прямим текстом говорили: «Досить з нас технічних завдань. У нас цих документів вже - більше, ніж треба ». І дійсно, показали об'ємні папки з документами, рішення з яких так ніколи і не були реалізовані.
«Часткове» впровадження
В цьому випадку складають список найбільш значущих для бізнесу напрямків і модулів для роботи з ними. На їх основі складають якийсь план впровадження, який і є основою для початку робіт.
В цьому випадку технічне завдання також є. Як і календарний план при варіанті роботи, де за основу беруть об'ємне ТЗ. Але тут технічне завдання не є таким всеосяжним, можливо складання для різних етапів роботи власних технічно завдань. Тобто основний документ в даному випадку - План виконання робіт.
В якості першого етапу впровадження вибираємо ділянку Фінанси і Рух товарів. Ця ділянка робіт є дуже важливим для будь-якої компанії. Розбираємося з особливостями рухів фінансових в організації, вивчаємо зберігання і продаж товарів. На основі цього складаємо ТЗ для автоматизації в ERP вибраної ділянки. І впроваджуємо необхідний для цієї ділянки функціонал.
На наступному етапі вибираємо інший напрямок, наприклад, виробництво. І також працюємо з цим напрямком плюс враховуємо проведені роботи (і можливі доробки) в уже готових модулях, що відносяться до фінансів і продукції.
Основна перевага такого методу - реалістичність. Охопити все і відразу вкрай складно. Впроваджувати поетапно - набагато простіше, помилок при цьому зазвичай допускається менше. І результати роботи видно вже в процесі впровадження. Я і сам найчастіше вибираю цей підхід.
Мінуси - збільшення термінів, яке замовник може розглядати як затягування. При частковому впровадженні терміни проведення робіт можуть затягуватися як з об'єктивних причин, так і по різних приводів, пов'язаних з фінансуванням, людським фактором і т.д. Крім того, якщо керівник бізнесу прагне отримати все і відразу, його також може не влаштувати відсутність точних даних про впровадження (коли буде завершено, яка буде точна сума і т.д.).
Цей метод роботи дуже обережний, і найчастіше вимагає часу більше, ніж при інших варіантах впровадження. Так, якщо при першому підході (складанні ТЗ) всі терміни і суми розраховані заздалегідь, до початку робіт, то тут все попередні цифри приблизні. А технічні завдання для різних етапів складаються в процесі впровадження.
Також при першому методі роботи по автоматизації роботи різних підрозділів можуть проводитися паралельно. Клієнт буде бачити автоматизацію і бухгалтерії, і продажів, і складу, і виробництва. Тут же робота проводиться етап за етапом. І підрозділу підключаються до ERP також по черзі.
«Agile» підхід
В цьому випадку роботи по впровадженню починаються відразу без якогось підготовчого етапу. Здавалося б, це неприйнятно, ERP-системи занадто складні, щоб впроваджувати їх без попереднього вивчення особливостей бізнесу і складання документації. Проте, на практиці я подібну роботу бачив.
Деякі розробники навіть в разі ERP-систем діють за принципом «почнемо, а потім розберемося». Відповідно до цього підходу створюється попередньо загальний план впровадження, який у міру необхідності ділиться на дрібні частини.
Найчастіше подібний метод роботи практикують продавці «коробкових» програмних продуктів. Причина полягає в тому, що прибуток від продажу «коробки» вони отримують в будь-якому випадку, а впровадження для них - лише супутня послуга.
Основний плюс такого методу - робота по впровадженню починається відразу після прийняття рішення. Без тривалої підготовки. Саме це і приваблює бізнесменів. Наприклад, було прийнято рішення - автоматизуємо відділ продажів - відразу приступили до роботи. Вирішили - треба перенести залишки - тут же вони переносяться.
В принципі, успішне впровадження за таким принципом також цілком можливо. Але це дуже складно і для успіху потрібно дуже високий рівень професіоналізму керівника, а також значний досвід впровадження подібних проектів. І навіть в цьому випадку професіонали частіше вибирають інші шляхи. Просто тому, що вони дозволяють знизити число помилок і накладок, впливу людського фактора. У підсумку, варіанти роботи по ТЗ або впровадження частинами дозволяють отримати потрібний результат з меншою кількістю накладок і переробок.
Мінуси - відсутність планування комплексного впровадження. Тут проблеми виникають практично з тих же причин, що і при складанні всеосяжного ТЗ: ERP - складний комплексний програмний продукт, і помилки при впровадженні одного модуля можуть вплинути на роботу іншого модуля. Але якщо в першому випадку такі проблеми виникають через спроби заздалегідь передбачити занадто багато, то тут - через відсутність планування. Тобто фахівці при впровадженні вирішують нагальні завдання, не замислюючись про те, що на наступному етапі їм будуть потрібні дані і документи з поточного модуля для організації роботи іншого підрозділу.
Ще один мінус - при такому підході залучення співробітників компанії в процес впровадження значно нижче, ніж при будь-якому з описаних вище. Це негативно позначається на рішучості співробітників брати участь в тестуванні і переході на нову систему, а також провокує саботаж використання нових інструментів.
«Потроху, але все і відразу»
Ще один підхід до впровадження ERP я особисто називаю "Потроху, але все і відразу". Цей варіант також цілком може бути успішним і зручним рішенням. Я особисто його застосовував неодноразово. І якщо при частковому впровадженні в роботу беруть один або два модулі, повністю їх налаштовують, і тільки потім приступають до роботи над іншими модулями, то в цьому випадку робота також ведеться поступово, то немає такого чіткого обмеження - тільки цей модуль і ніякі інші.
При такому підході насамперед також складається план проекту. В цьому плані основними етапами вважаються модулі (один, потім - другий і т.д.), а якісь види робіт, які можуть зачіпати одночасно всі модулі або вибірково якісь з них. При цьому для кожного етапу вказуються приблизні терміни і вартість.
У найзагальнішому випадку подібний план виглядає наступним чином:
- Розробка технічного завдання.
- Виконання робіт згідно технічного завдання ... Цей пункт може бути деталізований, виконання робіт тоді ділиться на кілька етапів.
- Тестування системи.
- Введення в експлуатацію.
- Навчання персоналу.
- Завершення (здача) проекту.
Подібний план складається і окремо для кожного модуля, що дозволяє максимально конкретизувати для замовника вартість кожного етапу робіт, а також найбільш точно визначити можливі терміни. При цьому із замовником обов'язково обмовляється можливість в процесі впровадження в разі необхідності змінити якісь види запланованих робіт іншими.
Такий метод зручніше і реалістичніше, ніж складання технічного завдання, так як загальне ТЗ для всього проекту потребує 2-3 місяців роботи або навіть більше, а отриманий в результаті об'ємний документ з усіма подробицями замовнику вивчити буде дуже складно.
Тут замовник бачить план з термінами і сумами для кожного етапу. А техзавдання під кожен етап робіт створюються окремо, вони невеликі і не вимагають значних витрат часу. Бажано ще й називати кожен з документів зрозумілим чином. Наприклад, «Бухгалтерія і фінанси» або «Відділ продажів».
Плюси такого підходу:
- Замовник відразу бачить весь проект цілком. З максимально точними термінами і вартістю, наскільки це взагалі можливо до початку впровадження.
- Виконавець чітко визначає бюджет кожного етапу і виставляє рахунок для оплати. При цьому сума рахунку не викликає ніяких питань, що дозволяє продуктивно працювати, не відволікаючись на обгрунтування рахунку або підрахунок кількості витрачених за фактом годин.
- Замовнику необхідно дуже ретельно вибирати виконавця, щоб керівник проекту на належному рівні розбирався в особливостях впровадження кожного модуля. Інакше розрахунки в плані опиняться недостатньо точними. Бюджет може несподівано збільшуватися, терміни розтягуватися, тобто основні переваги підходу будуть втрачені.
- Виконавцю потрібно значну кількість висококваліфікованого персоналу, щоб укластися в терміни і займатися паралельно різними модулями. Тобто невелика команда такий підхід не зможе реалізувати.
Важлива особливість планування: При підрахунку бюджету незалежно від вашого досвіду і точності оцінки слід "закласти" додаткову суму на випадок непередбачених ситуацій. Оптимальний розмір такої суми - 30% від вартості запланованих робіт. Це можна назвати узгоджене плановане відхилення вартості проекту. Ці кошти можуть знадобитися при виникненні якихось труднощів - організації обміну даними з програмою, яка не підтримує існуючий API, доробка базових довідників, складності при перенесенні даних, реалізація необхідних для роботи функцій, які з тієї чи іншої причини не зуміли передбачити заздалегідь і т . Д.
З яких модулів починати?
Кількість модулів, які може запропонувати система ERP, викликає нерідко питання, з чого ж почати, адже можливостей дуже багато, так би мовити, «очі розбігаються». Я рекомендую починати з найбільш критичних для роботи компанії напрямків і пов'язаних з ними модулів:
- Фінанси і взаєморозрахунки. (Не плутайте з бюджетуванням - цей модуль можна і потрібно впроваджувати пізніше, він відноситься до планування, а не до поточної критично важливій роботі).
- Рух товарно-матеріальних цінностей (ТМЦ): зберігання, реалізація, надходження. Дуже важливо, щоб ТМЦ враховувалися коректно, перед перенесенням залишків зазвичай проводять інвентаризацію, далі - переносять залишки, після чого робота ведеться вже тільки в новій системі.
- Бухгалтерський облік. Впровадження модуля бухобліку або організація обміну даними з бухгалтерською системою. Держава нічого не прощає, і за будь-яке порушення, незалежно від наявності умислу, передбачено покарання. А тому бухгалтерський і податковий облік - також система, критична для роботи будь-якої компанії.
Іноді я чую заперечення, що у компанії можуть бути свої нюанси, наприклад, у зв'язку з високою плинністю кадрів найбільш критичним є HR. Насправді, скоріше за все, якась автоматизація роботи HR в компанії на момент початку впровадження ERP є. І незалежно від того, наскільки критична для бізнесу робота цього підрозділу, деякий час управління персоналом можна буде вести в тій системі, яка є. А якщо в процесі будуть виявлені певні помилки - це буде мінусом, але не самим критичним для існування компанії.
Також і проектний відділ або маркетинг якийсь час зможуть працювати в звичному режимі і вести облік автономно в тій системі, якою вони користувалися раніше.
У той же час строгий облік і контроль руху основних цінностей (фінансових і матеріальних), а також відсутність помилок в бухгалтерському та податковому обліку - це ті «стовпи», без яких не зможе існувати жодна компанія.
Я сподіваюся, що матеріал про те, з чого варто починати впровадження ERP, і які методи роботи з цією системою практикуються, був вам корисний. У наступних публікаціях я розповім про свій особистий досвід впровадження ERP, поділюся інформацією про помилки, яких краще уникати, а також про те, на що потрібно звертати увагу в процесі впровадження і як краще побудувати цю роботу, щоб перехід на ERP був максимально ефективним.
З повагою Кінзябулатов Раміль.