Як почати без перенесення всієї школи

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

Безпечніше спочатку довести, що процес підходить школі.

Чому повне перенесення не має бути першим кроком

Переносити всі записи до розуміння процесу - зайвий ризик.

Це може змусити команду витрачати час на:

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

Ця робота може знадобитися пізніше, але вона не має блокувати першу оцінку.

Почніть з демо-даних

Використайте демо-дані, якщо мета - зрозуміти, як поводиться система.

Демо-дані дозволяють власнику й адміністраторам переглянути підготовлений навчальний центр:

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

Це відповідає на перше питання: чи зрозумілий школі пов'язаний процес?

Потім додайте один реальний фрагмент

Коли демо-дані стали зрозумілими, додайте малий реальний процес замість усієї школи.

Корисний перший фрагмент:

• одна філія;
• один курс;
• одна група;
• один викладач;
• кілька учнів;
• короткий період розкладу;
• кілька реалістичних статусів відвідуваності;
• кілька оплат і балансів;
• один період білінгу.

Цього достатньо, щоб перевірити реальні правила школи і не перетворити пробний старт на міграційний проєкт.

Що перевірити на малому сценарії

На малому сценарії перевірте, чи система відповідає на практичні питання:

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

Якщо відповідь так, у школи є підстава розширювати використання.

Тримайте білінг під контролем перед розширенням

Білінг зазвичай є найчутливішою частиною впровадження. Помилка в розкладі незручна. Помилка в рахунках впливає на довіру і грошовий потік.

Перед додаванням більшої кількості учнів пройдіть перевірку білінгу перед запуском:

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

Розширюйте використання лише після того, як команда може пояснити фінансовий результат.

Імпорт пізніше, не на старті

Імпорт корисний тоді, коли школа вже розуміє, що саме хоче переносити.

Можливі етапи імпорту:

1. Основні довідники: учні, викладачі, групи, філії, аудиторії.
2. Поточний розклад і активні групи.
3. Поточні баланси та відкриті рахунки.
4. Історія оплат, яка ще потрібна в роботі.
5. Старіша історія лише тоді, коли вона потрібна для звітів або перевірок.

Не кожен старий запис потрібно переносити. Частину історії можна залишити в архівних таблицях або старій системі, якщо вона потрібна лише для довідки.

Коли повне перенесення має сенс

Ширше перенесення має сенс після того, як команда підтвердила:

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

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

Результат

Ви можете оцінити Intelligence Cloud без перенесення всієї школи на першому кроці.

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