Перехід з 1С на нову ERP систему

Вступ…

Автоматизація бізнес-процесів – це життєва необхідність кожного підприємства. Незважаючи на це, ситуація з автоматизацією на підприємствах дуже різна. Але є чіткі дані, які говорять про те, що більшість підприємств України здійснили автоматизацію бізнес-процесів на програмних продуктах (далі ПП) країни, яка є агресором до України, а саме на 1С Підприємство і BAS. І зрозуміло, що усім нам хочеться відмовитись від усього, що в нашому житті має хоч якесь відношення до країни-терориста і ПП не виняток. 

Які саме ПП є альтернативою 1С і BAS, ми доволі детально розглянули у нашій попередній статті “Заміна 1С та BAS , з якою також рекомендуємо вам ознайомитись, якщо ви цього ще не зробили. Але виникають логічні питання: “Який саме ПП підійде мені?” і “Як відбувається перехід на альтернативні ПП”. У даній статті ми відповімо на ці питання, а також надамо практичні рекомендації, які допоможуть скоротити час переходу і зекономити кошти, зважаючи на сучасні реалії.

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

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

1. Аналіз і опис бізнес-процесів підприємства ;
2. Налаштування та доробка (кастомізація) ;
3. Тестова експлуатація;
4. Виробнича експлуатація. 

Це основні етапи, достатні для здійснення переходу. Але, на практиці, після завершення останнього етапу користувачі потребують активної підтримки/консультацій, тому це обов’язково потрібно враховувати.

На перший погляд усе виглядає доволі просто, але давайте “зануримось” у кожен пункт окремо і розглянемо їхні особливості. 

Етап 1. Аналіз і опис бізнес-процесів підприємства

Оцінка доопрацювань

Маючи ПП і бізнес модель, не складно визначити, які саме доопрацювання необхідно здійснити. Отже, як це зробити:

• їх необхідно зібрати в окремий список;
• провести  пріоритезацію / ранжування  від обов’язкових до менш важливих; 
• кожне окремо обговорити і оцінити в часових та грошових рамках реалізації. Рекомендуємо фіксувати абсолютно усі доопрацювання.

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

При опрацюванні списку, можуть виникнути наступні ситуації:

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

У результаті ви отримуєте список доопрацювань, які потрібно виконати в програмі для повноцінного функціонування підприємства.

Побудова бізнес-моделі

Для виконання даного підетапу, необхідно виконати комплексне обстеження діяльності всього підприємства. Розділити його на підсистеми (наприклад: закупівлі, продажі, бухгалтерський облік та ін.), в рамках кожної підсистеми побудувати бізнес-процеси і не забути врахувати взаємодію, або так би мовити “точки дотику” підсистем. Обов’язково усе записувати і візуалізовувати, бо коли візуалізується увесь бізнес-процес певної підсистеми, набагато простіше його аналізувати. В ці моменти аналізу, стає зрозуміло де у бізнес-процесах є вузькі місця, де потрібно оптимізувати, або де певну дію дублюють декілька працівників і так далі.

Рекомендуємо обов’язково залучати усіх працівників до даного процесу, враховуючи працівників “найнижчих ланок”, які займаються звичайною операційною роботою. Адже, саме за рахунок роботи цих працівників, формуються дані, які надалі використовуються для аналізу діяльності підприємства і прийняття рішень. Практично завжди вони володіють знаннями операційних нюансів, з якими зіштовхуються кожен день, а керівник, дивлячись на підприємство в загальному, може цих нюансів не знати. А часто ці деталі можуть значно впливати на функціонування системи.    

У результаті, ви повинні отримати зрозумілу візуалізовану бізнес-модель, яка показує загальну “картину” діяльності, з можливістю її розкласти по підсистемах з урахуванням усіх наявних деталей. 

Як зрозуміло з вище описаного, даний підетап є, мабуть, найважливішим у проєкті, адже на нього “опираються” усі наступні етапи.

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

Вибір програмного продукту

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

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

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

Формування план-графіку проєкту 

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

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

Формування бюджету проєкту

Отримавши усі складові, які описані вище, складається бюджет проєкту, де згідно з часовими рамками і ресурсами, які будуть залучатись, розраховується сума, необхідна для успішного завершення проекту.

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

Також, однією з рекомендацій буде закласти резервний фонд, який складе від 20% до 50%. З практики, не важливо наскільки скрупульозно ви підходите до планування, завжди виникають додаткові роботи в ході переходу. Саме для таких випадків потрібно закласти резервний капітал.

Отже, результатом етапу є: 

• побудована бізнес-модель; 
• список доопрацювань (з оцінкою); 
• технічні завдання на доопрацювання; 
• план-графік переходу;
• бюджет переходу.

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

Етап 2. Налаштування та кастомізація

Якщо ви вирішили перейти на бізнес-процеси, рекомендовані ПП, цей етап може бути відсутній .  

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

Важливим моментом є пріоритезація задач налаштування та доробки (кастомізації) . Це дасть можливість поділити розробку на блоки, наприклад: обов’язково реалізувати до запуску, бажано реалізувати до запуску, можна реалізувати і після запуску або інші варіанти. Для кожного блоку проставити кінцеву дату реалізації і старатись її дотримуватись.

Етап 3. Тестова експлуатація 

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

Розгортання тестової бази

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

Дана база необхідна для проведення навчання користувачів, тестування доопрацювань користувачами, і, в принципі, для відтворення усіх бізнес-процесів, які були описані початково.

Навчання користувачів

Уже маючи середовище, користувачі можуть навчатись. Але в даному підетапі вашого переходу дуже багато різних нюансів, усіх їх врахувати надзвичайно складно. Але врахуйте наступні основні моменти:

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

Продумайте систему мотивації працівників за успішність освоєння програмного продукту. Це не обов’язково повинні бути грошові винагороди.

Перенесення початкових даних

Складіть список довідників і реєстрів (сумових і кількісних) залишків, які необхідно внести в нову базу даних. Надалі можна по-різному підійти до перенесення:

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

Рекомендуємо використовувати “комбінований метод” перенесення даних, адже він поєднує плюси двох попередніх методів, що значно скорочує час їх перенесення.   

Ще одна рекомендація, не переносити дані з старої бази напряму в нову. Розробити шаблони (у будь якому зручному форматі), вивантажити в них дані, опрацювати (видалити дублі, виправити неправильні та ін.) і тоді з них вантажити в майбутню робочу базу.

Який би варіант ви не обрали, перевірте його на тестовій базі. Тобто, дайте працівникам попрацювати з отриманими даними, щоб виявити неточності при перенесенні. 

Додаткові доопрацювання 

При тестуванні у користувачів майбутньої системи виникатимуть моменти, які не вдалось передбачити на етапі “ Аналіз і опис бізнес-процесів підприємства ”. Не сприймайте їх критично, ще ніхто ніколи не передбачив усе наперед. Деякі з них потребуватимуть просто управлінських рішень, а деякі додаткових доопрацювань в системі (якщо ви не прийняли рішення працювати на типовому функціоналі, не вносячи змін в програмний продукт). Саме в ці моменти на допомогу прийде резерв, який описувався в етапі “ Аналіз і опис бізнес-процесів підприємства ”.

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

Ми в своїй діяльності часто зіштовухуємось / неодноразово виявляємо, що цьому етапу не приділяється належна увага , незважаючи на усі наші рекомендації і застереження.

Етап 4. Виробнича експлуатація 

І останній етап – це старт роботи у новій системі. Тут, як таких, підетапів визначити неможливо. Варто виділити лише 2-ва варіанти запуску: 

Паралельна робота старої і нової баз

Доволі часто застосовується при старті. 

• Плюси:
  • користувачі при внесенні даних в нову базу мають з чим звіряти наповнення нової бази;
  • при виникненні критичних ситуацій, коли потрібно терміново “витягнути” дані, можна взяти їх із старої бази;
  • у користувачів є час звикнути до роботи в новій базі, тому перехід відбувається більш плавно.  
• Мінуси:  
  • додаткове навантаження на користувачів, бо дані потрібно паралельно вносити в обидві бази;
  • користувачі будуть більше уваги приділяти внесенню даних в стару базу, що може призвести до великого відставання і значно підвищується ризик, що перехід так і не відбудеться;
  • відмінна структура аналітик та алгоритмів старої і нової баз, через що співставлення багатьох результатів є фактично неможливим – чи то собівартість, чи фінансовий результат.

Відмова від старої бази і робота тільки в новій базі даних.

• Плюси:
  • немає навантаження на користувачів, адже дані вносяться в одну базу;
  • підприємство точно буде працювати у новій системі, адже користувачі зосереджені на одній базі і налагодження відбувається швидше.
• Мінуси:
  • при виникненні критичних ситуацій, час на їх вирішення дуже обмежений;
  • на перших періодах доведеться “жертвувати” наявністю певної звітності, адже більше уваги буде приділятись відлагодженню роботи операційної діяльності.

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

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

Ще дамо кілька рекомендацій загалом по проєкту, для полегшення переходу. 

Рекомендації по переходу на іншу ERP

Рекомендація 1: Призначте менеджера проекту.

Знайдіть або виділіть з працівників під проєкт окрему людину, яка 100% часу буде приділяти роботі по веденню проєкту. Не важливо, залучаєте ви зовнішню організацію для впровадження чи будете це здійснювати самостійно. Для успішності перехід вимагатиме постійної роботи над ним, а якщо ви – керівник, то у вас на це часу не буде. Але попри те, що є людина, ви також приділяйте цьому свій час. Наприклад, організуйте 2-чі на тиждень наради по годині часу, щоб мати в загальному актуальні дані по проєкту. Адже, може виникнути ситуація, що доведеться приймати рішення по проєкту і вам доведеться вникати з самого початку, а на пізніх етапах це буде складно і аргументи, які будуть наводитись, уже будуть “перекручені”.

Рекомендація 2: Премії для працівників.

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

Рекомендація 3: Не змінюйте дати запуску.

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

Рекомендація 4: Все не передбачиш.

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

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

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

З радістю готові поділитись нашим досвідом з вами. А також допомогти знайти та перейти на ваш ідеальний альтернативний ПП.

Про One Service Consulting 

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

Автор: Ярослав Висоцький, провідний аналітик і консультант в компанії One Service Consulting.