Понад 5 років документообіг найбільшого в Україні виробника й експортера соняшникової олії Kernel здійснювався на платформі К2 4.7. Він охоплював усі бізнес-процеси: від управління персоналом до підписання електронних документів. Перехід із затишного, однак, на той момент уже застарілого К2 4.7 на нову версію K2 Five тривав рік. Про велику міграцію, помилки й результати розповідає Марія Ботвинкіна, керівник IT-проєктів напрямку організаційного розвитку й HR Kernel.
На момент міграції число автоматизованих процесів у компанії досягло піку. Щодня в системі створювалося понад 3 тисячі документів, процесів, заявок на погодження й підпис. Більшу частину документів фіналізували протягом доби. Платформа K2 4.7 задовольняла потреби бізнесу аж до появи K2 Five. «У новій версії з’явилися не лише нові функції, а й повністю змінився движок бізнес-процесів – він прискорює розробку й робить її більш гнучкою. Серед головних фіч – WorkSpace. Це портальне рішення, що дало змогу нам задіяти увесь функціонал К2 й відмовитися від Sharepoint. Завдяки цьому користувацький інтерфейс став більш юзабільним. Також з’явилася мобільна версія К2, що дозволяє застосовувати її у майбутньому для різноманітних погоджень документів», — розповідає Марія Ботвінкіна.
Нову версію платформи розгорнули на окремому майданчику. Команда відібрала кілька ключових типових процесів і перевела їх на К2 Five. Для успішної міграції операцію довелося виконувати понад 10 разів: недокументовані баги гальмували процес. На те, щоб пройти, отримати й описати покроковий процес міграції існуючих процесів, знадобилося 2 місяці. Лише після цього до роботи взялася команда тестувальників.
Потрібно було перевірити, як на новому движку працюватимуть бізнес-процеси й наскільки з новою платформою сумісні дизайн-форми, які Kernel використовував на попередній версії. На той момент компанія мала понад тисячу реалізованих форм. Зміна кожної була б надміру важким завданням.
На тестування, виявлення багів і виправлення помилок пішло 5 місяців. Лише тоді з’явився стенд, який працює стабільно і на якому до того моменту розгорнули шість базових процесів, повністю задокументовані кроки з міграції, скрипти. Міграцію провели на тестовому середовищі й на копії продуктивного середовища. Через проблеми, що періодично виникали, команді довелося провести кілька ітерацій, щоразу відкочуючись на початок усіх етапів.
Kernel — глобальна агрокомпанія, що експортує продукцію у понад 80 країн. Бізнес такого масштабу не можна поставити на паузу. Тож для міграції обрали 3 вихідних дні. Команда мала 72 години й ні хвилини більше.
У призначений день систему зупинили. Було запущено резервну копію даних на випадок, якщо щось піде не так. Бекап зайняв майже добу, і міграція стартувала. Процес безперервно супроводжувався інженером від вендора й спеціалістами з інфраструктури. Команда діяла відповідно до розробленого сценарію, але впроваджувала його вже на продуктивному середовищі. Міграція відбулася успішно й була завершена протягом двох діб. З наступного робочого дня всі підрозділи Kernel перейшли на нову систему.
«Ми готувалися до можливих технічних проблем із новою версією. Однак кількість звернень користувачів виявилася значно нижчою, аніж ми передбачали. Попри те, що процес зайняв цілий рік, нам вдалося успішно перенести величезну систему з однієї платформи на іншу. Сподіваюся, наш кейс надихне інші бізнеси на автоматизацію й навчить не боятися змін», — підсумувала Марія Ботвінкіна.
Важливо, що ми не зупиняли процес розробки нових процесів, вони рухалися паралельно з міграцією. Одна команда працювала над новинками, друга займалася міграцією типових процесів для подальшого переведення всієї системи.