Перехід із 1С / BAS на нову ERP систему:
Етапи, Особливості, Рекомендації.

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

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

• їх необхідно зібрати в окремий список;

• провести  пріоритезацію / ранжування  від обов’язкових до менш важливих; 

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

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

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

• усі зміни прийняті - можна рухатись далі на наступний етап; 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• побудована бізнес-модель; 

• список доопрацювань (з оцінкою); 

• технічні завдання на доопрацювання; 

• план-графік переходу;

• бюджет переходу.

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

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

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

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

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

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

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

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

• Врахуйте, якщо ви вирішили самостійно вивчати програму, без залучення зовнішніх організацій, то даний етап у вас займе більше часу, просто будьте до цього готові;

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

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

• прийняти рішення, що всі початкові дані будуть вноситись вручну: 

• Плюси: вноситься тільки необхідна інформація і в нову базу не переносяться старі дані, які уже давно не використовуються; 

• Мінуси: якщо об’ємні початкові дані, то для користувачів - це великі додаткові часові витрати;

• реалізувати пряме перенесення зі старої бази в нову: 

• Плюси: неважливі розміри початкових даних, навіть при дуже великих, займає значно менше часу, ніж ручне перенесення; 

• Мінуси: перенесення старих даних, які не будуть використовуватись; необхідна наявність висококваліфікованого технічного спеціаліста;

• комбінований метод - частково вручну, а частково - за допомогою додаткових інструментів. У списку визначити дані, які є дуже об’ємні - для них планувати розробку інструменту для перенесення, а вручну - переносити дані з меншою кількістю записів. З досвіду, до об’ємних ми відносимо списки, у яких налічується більше 50 записів.

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

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

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

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

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

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

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

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

• Плюси:

• користувачі при внесенні даних в нову базу мають з чим звіряти наповнення нової бази;

• при виникненні критичних ситуацій, коли потрібно терміново “витягнути” дані, можна взяти їх із старої бази;

• у користувачів є час звикнути до роботи в новій базі, тому перехід відбувається більш плавно.  

• Мінуси:  

• додаткове навантаження на користувачів, бо дані потрібно паралельно вносити в обидві бази;

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

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

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

• Плюси:

• немає навантаження на користувачів, адже дані вносяться в одну базу;

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

• Мінуси:

• при виникненні критичних ситуацій, час на їх вирішення дуже обмежений;

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

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

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

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

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

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

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

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

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