Підприємство не повинно зупинитися заради нової системи
На презентації повний перехід за один день може виглядати дуже чисто: перенесли дані, вимкнули стару систему, відкрили нову і продовжили роботу.
У реальному підприємстві одночасно існують відкриті замовлення, незакриті документи, залишки на складах, платежі, резерви, повернення, незавершені операції та люди, які вже працюють із цими даними.
Тому найбільший ризик переходу часто не в самому перенесенні таблиць із бази в базу. Ризик виникає в момент, коли потрібно відповісти: з якого часу нова система вже є основною, що робити з операціями, які почалися раніше, і як переконатися, що нічого не загубилося між двома станами.
Для мене хороший перехід має бути не красивим на схемі, а передбачуваним для бізнесу.
Що робить великий одноразовий перехід ризикованим
Чим більше процесів перемикаються одночасно, тим складніше зрозуміти причину проблеми, якщо щось піде не так.
Неповні дані
Частину історії перенесли, але відкриті документи, зв’язки або довідники залишилися неповними.
Неперевірені правила
Нова система рахує правильно технічно, але один із реальних бізнес-випадків ще не був перевірений.
Занадто багато змін одночасно
Працівники отримують нові екрани, нові правила і нові процеси в той самий день.
Немає простого шляху назад
Якщо стара система вже вимкнена, навіть невелика проблема може вплинути на роботу всього підприємства.
Як може виглядати поступовий перехід
Для мене логічний порядок починається з даних і закінчується не переключенням, а перевіркою стабільної роботи після нього.
Визначити межі першого етапу
Не переносити все підприємство одразу. Обрати конкретний процес, підрозділ, склад або іншу частину, яку можна перевести контрольовано.
Підготувати та очистити дані
Зрозуміти, які довідники та історія справді потрібні, прибрати дублікати, перевірити зв’язки та домовитися про правила перенесення.
Зробити пробне перенесення
Перенести дані до нової системи без остаточного переключення та перевірити структуру, кількість записів, залишки й ключові зв’язки.
Перевірити результат разом із бізнесом
Технічної перевірки недостатньо. Працівники мають підтвердити, що клієнти, товари, документи, залишки та звичні сценарії виглядають правильно.
Запустити паралельну роботу
На обмежений період частина операцій перевіряється в обох системах. Це допомагає побачити відмінності до остаточного переключення.
Визначити момент переключення
Має бути чітко зрозуміло, після якої операції або дати нові дані вже створюються тільки в новій системі.
Перенести останні зміни
Перед переключенням потрібно підтягнути операції, які з’явилися після попереднього перенесення, і ще раз звірити критичні показники.
Переключити процес
Працівники починають виконувати нові операції в новій системі, а стара переходить у визначений режим читання або резервного доступу.
Стабілізувати
Після запуску потрібно перевіряти помилки, питання працівників, незвичайні випадки та розбіжності, а не вважати міграцію завершеною в момент переключення.
| Етап | Що перевіряємо | Коли можна рухатися далі |
|---|---|---|
| Пробне перенесення | Структуру та повноту даних | Ключові записи та зв’язки збігаються |
| Перевірка бізнесом | Реальні робочі сценарії | Працівники підтверджують результат |
| Паралельна робота | Однакові операції у двох середовищах | Критичні розбіжності пояснені |
| Остаточне оновлення | Нові операції після пробного перенесення | Дані звірені перед переключенням |
| Переключення | Нові операції тільки в новій системі | Основний процес працює стабільно |
| Стабілізація | Помилки та нестандартні випадки | Новий процес більше не потребує постійного ручного контролю |
Окрема складність полягає в тому, що перенести дані не означає просто скопіювати всі старі таблиці.
У старій системі можуть бути дублікати контрагентів, товари без актуальних реквізитів, історичні документи зі старими правилами, записи, які давно не використовуються, або поля, значення яких уже ніхто точно не може пояснити.
Якщо перенести все без аналізу, новий продукт успадкує не лише історію бізнесу, а й усі накопичені проблеми.
Тому до міграції важливо відповісти на окремі питання: що потрібно перенести як живі дані, що потрібно залишити як історію, що можна архівувати і що взагалі не повинно потрапляти в нову систему.
Саме тут для мене природно повертається ідея AVN Center.
Я не хочу будувати продукт навколо припущення, що підприємство одного дня просто відмовиться від усього, чим користувалося раніше.
У реальному бізнесі бухгалтерія, таблиці, складські процеси, документи та внутрішні правила вже існують. Частина з них працює добре. Частина потребує заміни. Частину можна під’єднати раніше, ніж буде готовий весь новий контур.
Тому для мене один із важливих принципів AVN Center полягає в поступовому переході: новий продукт має вміти входити в уже працююче середовище, а не вимагати спочатку зруйнувати його.
Коротко про перехід на нову систему
Не кожне підприємство потребує однакового сценарію, але ризик можна зменшувати системно.
Чи потрібно переносити всю історію?
Навіщо робити пробне перенесення?
Чи потрібно довго працювати у двох системах одночасно?
Коли можна переключати процес?
Що робити зі старою системою після переходу?
Чи обов’язково замінювати все одночасно?
AVN Center: від потреб бізнесу до продукту
У цій серії я дивлюся не лише на те, якою могла б бути нова бізнес-система, а й на практичне питання: як дійти до неї з уже працюючого підприємства без різкого розриву процесів.
Новий продукт має входити в працюючий бізнес поступово
AVN Center я бачу як середовище, яке можна вводити частинами: під’єднувати дані, перевіряти процеси, переносити окремі ділянки та поступово зменшувати залежність від старих систем без вимоги зупинити підприємство.
