Як оцінити процес навчального центру на демо-даних

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

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

Що мають показувати демо-дані

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

У демо-компанії мають бути:

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

Так команда проходить систему так, ніби школа вже працює.

Почніть з розкладу

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

Перевірте, чи відповідає демо-розклад на практичні питання:

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

Якщо розклад зрозумілий, переходьте до відвідуваності.

Перевірте відвідуваність у контексті заняття

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

На демо-даних перевірте:

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

Пов'язана сторінка можливості - контроль відвідуваності. Ширше пояснення дивіться у посібнику з обліку відвідуваності.

Пройдіть одного учня від заняття до рахунку

Виберіть одного демо-учня і пройдіть операційний ланцюжок:

1. Відкрийте групу або розклад учня.
2. Перегляньте кілька занять.
3. Перевірте статуси відвідуваності.
4. Відкрийте рахунок учня.
5. Порівняйте рядки занять, знижки, оплати та фінальний баланс.

Саме тут демо корисніше за скріншоти. Власник бачить, чи щоденні операції із заняттями створюють зрозумілі фінансові записи.

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

Перевірте оплати та баланси

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

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

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

Логіку оплат пояснено у статті як працює розподіл оплат.

Перегляньте звіти з тих самих даних

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

Корисні питання:

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

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

Чого демо-дані не доводять

Демо-дані - це перший крок оцінки, а не фінальний тест впровадження.

Вони не можуть повністю довести:

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

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

Коли додавати реальні дані

Додавайте реальні записи після того, як процес уже зрозумілий. Безпечний наступний крок - одна філія, один курс, одна група, кілька учнів, кілька оплат і один період білінгу.

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

Результат

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

Перше питання має бути не "чи можемо ми імпортувати все?". Краще питання: "чи розуміє наша команда зв'язаний процес від розкладу до відвідуваності, білінгу, оплат, виплат і звітів?"