ERP-система розкладу для освітнього центру
Контекст і проблема
Почавши працювати в науково-освітньому центрі фізики та хімії, я виявив, що організація працює на важкій системі, побудованій на базі Excel. Вона постійно падала, зависала під навантаженням і робила щоденні операційні зміни вкрай болісними та схильними до помилок.
Масштаб операційного навантаження:Саме тому я вирішив створити систему, яка дозволила б зробити управління розкладом і ресурсами надійнішим і передбачуванішим. У вільний від основної роботи час я розробив власну Scheduling System, а в середині серпня, перед початком нового навчального року, безкоштовно розгорнув і налаштував окрему копію системи для навчального центру, щоб полегшити щоденну роботу колег.
Досвід роботи з реляційними базами даних сформував основний архітектурний принцип проєкту: зміни розкладу та ресурсів мають оброблятися як транзакції, а не як просте редагування таблиць.
Контроль цілісності було винесено на рівень СУБД, історія змін зроблена незмінною через Audit Log, а архітектура дозволяє безпечно відновити стан розкладу на конкретний день.
Моя роль
- Архітектура системи та бази даних — розробив мультисхемну архітектуру БД, рольову модель доступу, гнучку логіку розв'язання конфліктів (заміна вчителя, перенесення уроку між кабінетами), розгортання річного розкладу з тижневого шаблону з автоматичним підбором кабінетів за заданими правилами, виніс усі ключові бізнес-інваріанти на рівень БД (інтервали GiST, що запобігають подвійному бронюванню), транзакційні знімки сесій редагування та черги подій.
- Інтеграція каталогу обладнання — інтегрував інтерактивний каталог обладнання, завдяки чому замовлення вчителя простежується через усю систему на кожному етапі обробки (dashboard вчителя, dashboard лаборанта, на панелі адміністратора та в листах-сповіщеннях).
- UX і дизайн інтерфейсу — спроєктував простий, інтуїтивно зрозумілий користувацький інтерфейс.
- Табло в реальному часі — спроєктував табло для учнів і для вчителів (табло вчителів показує додаткову службову інформацію).
- DevOps та інфраструктура — контейнеризація в Docker, Nginx, деплой AWS EC2 + Cloudflare Tunnel, автоматичні резервні копії в S3, транзакційний pipeline надсилання листів через Resend (з можливістю динамічної зміни бізнес-правил через адмін-панель).
- Disaster Recovery — розробив і протестував схему відновлення після повного краху системи (крах було змодельовано за такою схемою: повністю знищив інстанс, створив новий (оновив систему, встановив необхідні компоненти), деплой нової копії з GitHub + накатування останнього backup бази). За результатами була написана покрокова інструкція відновлення системи.
Огляд системи
ERP-система управління розкладом та операційною діяльністю:
- Річний шаблон + згенерований на його основі розклад на рік
- Редагування розкладу на рівні дня з freeze / unfreeze / rollback
- Заміни викладачів
- Скасування та перенесення уроків
- Створення нових уроків і додаткових занять
- Процес замовлення лабораторного обладнання
- Черга заявок (принцип «одного вікна»)
- Email-сповіщення про всі ключові події — зміни розкладу, зміна аудиторії, призначення заміни викладача, скасування уроку, замовлення обладнання, схвалення заявок, а також службові сповіщення для адмінів
- Гранулярний рольовий доступ
- Коридорні ТВ-табло для викладачів і учнів
- Повністю незмінний audit log
Технологічний стек:
- PostgreSQL — обрано заради нативної підтримки EXCLUDE USING GIST. Це дозволяє на рівні движка СУБД забезпечити відсутність перетинів часових інтервалів і автоматично виключати race conditions за паралельних запитів.
- Логіка в БД — перенесення інваріантів у СУБД забезпечило єдине джерело правди і цілісність даних незалежно від точки підключення (API, фонові скрипти чи прямі адмін-сесії).
- Node.js + Express — тонкий stateless-шлюз (Thin API Gateway), обмежений завданнями авторизації та транзиту запитів без дублювання бізнес-логіки.
- Vue 3 + PrimeVue — скоротив time-to-market завдяки готовій екосистемі складних UI-компонентів для адміністративних екранів.
- Cloudflare Tunnel — ізолював інфраструктуру за принципом Zero Trust, повністю виключивши потребу публікації публічного IP та відкриття вхідних портів.
Структура проєкту:
Система в реальному житті:
Інтерфейс системи
Натисніть на будь-який скриншот, щоб відкрити його у повному розмірі.
Інженерна культура — код і документація
Один із ключових принципів проєкту: логіка і рішення пояснюються прямо в коді — не лише що робить функція, а й навіщо вона потрібна і що зламається, якщо порушити інваріант.
1. Чіткий поділ структури та бізнес-логіки
2. Підбір кабінетів із явними бізнес-правилами
3. Контроль якості та перевірка інваріантів
391 автоматизована регресійна перевірка (рівні API та БД) перед кожним деплоєм — покриває ланцюжки погодження заявок, заміни викладачів, заморозку/відкат дня, запобігання конфліктам розкладу (EXCLUDE USING GIST), замовлення обладнання та матрицю правил розсилки.
4. Експлуатаційна дисципліна релізів
Кожен із ~20 релізів на прод за 9 місяців проходить за тим самим протоколом: репетиція міграції
на свіжій копії прод-бази, Docker-образи з тегом :rollback перед пересборкою,
бекап безпосередньо перед накатом і письмовий журнал деплою на сервері. Реальне вікно
перемикання контейнерів — від 13 до 55 секунд.
План відновлення після повного збою перевірено не на папері: повний цикл (знесення volume → чиста ініціалізація з нуля → відновлення реального prod-дампу у тимчасову базу) прогнано цілком, а ключові таблиці (співробітники, уроки, заявки, права) звірено з живою БД порядково.
5. Впровадження та управління змінами
Щоб перехід із застарілого Excel пройшов гладко, я вибудував поступову стратегію впровадження:
- Раннє залучення та демонстрації. На етапі розробки я регулярно показував колегам робочі прототипи, пояснюючи на конкретних прикладах, як система позбавить їх щоденної рутини та плутанини. Початкова байдужість швидко змінилася щирим очікуванням релізу.
- Плавна адаптація за 2 тижні до старту. Я уважно спостерігав за реакцією співробітників та оцінював їхню відкритість до змін. Коли я побачив, що більшість налаштована позитивно, я прийшов до директора з пропозицією: не ускладнювати перехід зайвою паралельною роботою у двох системах, оскільки подвійне введення лише нервувало б колектив. Система об'єктивно вийшла набагато простішою та зручнішою за попередню, тому я запропонував починати навчальний рік одразу на ній, і директор погодився. Щоб команда встигла освоїтися, у середині серпня всім співробітникам було відкрито доступ до «пісочниці», де кожен міг спокійно поклацати інтерфейс та вивчити свої кабінети. Одночасно нова сітка розкладу була виведена на всі коридорні екрани центру — за два тижні до 1 вересня, щоб колектив візуально звик до нового формату.
- Практичне навчання. Було проведено кілька раундів практичного навчання для викладачів та лаборантів: як влаштований особистий кабінет, як у пару кліків замовити обладнання до лабораторії, подати запит на перенесення уроку та відстежувати статус своєї заявки в реальному часі.
- Повага до звичок та паперових нотаток. Я врахував, що частині лаборантів та викладачів звичніше працювати з аркушем у руках — позначати олівцем підготовлені досліди, робити помітки на полях. Цей функціонал (відмітка готовності обладнання, коментарі до уроку) закладено і в самій системі — хтось вносить це прямо в інтерфейс, а хтось спочатку на папері, а потім переносить у систему. Тому я передбачив можливість вивантаження в Excel для подальшого друку інформації, що відображається на екрані.
- Результат. Завдяки інтуїтивному інтерфейсу навіть найконсервативніша частина колективу опанувала систему практично без запитань. Вже до кінця вересня (перший місяць навчального року) система повністю та безшовно інтегрувалася в усі щоденні робочі процеси наукового центру.
Результати
- Система успішно працює в продакшені з вересня 2026
- Витримує реальне щоденне операційне навантаження центру
- Критичні інваріанти (конфлікти розкладу, права доступу, аудит) забезпечуються на рівні бази даних
- Повна незмінна історія всіх значущих дій
- У системі щодня працюють ~50 співробітників