Madrasah OS (MOS) adalah platform ERP internal terpusat untuk madrasah yang menggantikan proses Excel terfragmentasi dengan satu sumber kebenaran untuk administrasi, akademik, keuangan, dan operasional. Produk ini membantu staf, guru, dan administrator bekerja lebih cepat, lebih akurat, dan lebih transparan melalui workflow berbasis izin, audit trail immutable, dan model data historis yang tidak menimpa catatan lama.
Madrasah OS (MOS) adalah platform ERP internal terpusat untuk madrasah yang menggantikan proses Excel terfragmentasi dengan satu sumber kebenaran untuk administrasi, akademik, keuangan, dan operasional. Produk ini membantu staf, guru, dan administrator bekerja lebih cepat, lebih akurat, dan lebih transparan melalui workflow berbasis izin, audit trail immutable, dan model data historis yang tidak menimpa catatan lama.
Administrator Operasional (Ibu Rina, 41, bekerja setiap hari dan mengelola banyak proses manual) - Bertanggung jawab atas data siswa, guru, surat, dan koordinasi administrasi harian. Sangat bergantung pada ketepatan data dan ingin mengurangi pekerjaan berulang.
Petugas Keuangan (Pak Dedi, 36, memeriksa pembayaran setiap hari dan sering menyusun laporan bulanan) - Mengelola invoice, pembayaran, pendapatan, pengeluaran, dan pelacakan saldo. Membutuhkan data yang konsisten dan mudah diaudit.
Kepala Madrasah (Ustadzah Maya, 48, memantau operasional secara berkala dan mengambil keputusan berbasis laporan) - Tidak melakukan input detail setiap hari, tetapi membutuhkan pandangan ringkas, aman, dan akurat untuk pengambilan keputusan.
Setiap pagi, Ibu Rina biasanya membuka beberapa file Excel berbeda untuk memeriksa data siswa baru, status pembayaran, dan surat masuk. Sering kali ada versi file yang tidak sinkron, nama siswa yang dobel, atau kolom yang terisi tidak lengkap. Pekerjaan yang seharusnya selesai dalam hitungan menit berubah menjadi proses cek ulang yang memakan waktu dan penuh risiko kesalahan.
Setelah MOS diterapkan, Ibu Rina masuk ke dashboard dan langsung melihat tugas hari ini, notifikasi data yang belum lengkap, dan shortcut untuk membuat invoice atau mengimpor data. Saat ada file baru dari bagian pendaftaran, ia mengunggah template, memeriksa hasil validasi, dan memperbaiki baris yang bermasalah sebelum data masuk ke sistem. Kini, kepala madrasah bisa melihat data yang sama secara real time, bagian keuangan punya histori transaksi yang dapat diaudit, dan Ibu Rina bekerja dengan percaya diri karena semua pihak melihat satu sumber kebenaran yang sama.
# Madrasah OS ### AI Project Constitution > An internal ERP platform for managing educational institutions. # Vision Madrasah Operating System (MOS) is an internal ERP platform designed to become the **Single Source of Truth** for all administrative, academic, financial, and operational activities within a Madrasah. The primary objective is to replace fragmented Excel-based workflows with a centralized, integrated, secure, and auditable platform. MOS is **not** an LMS, Payroll system, or public SaaS. It is built exclusively for internal institutional operations and is intended to evolve incrementally through modular expansion. --- # Business Philosophy Every design and implementation decision must follow these principles: - **Entity-Centric** — Business entities are permanent and never recreated. - **History-Preserving** — Business history must never be overwritten. - **Organization-Driven** — Organizations manage identities, memberships, and permissions. - **Workflow-Oriented** — Features exist to support business processes, not the other way around. - **Single Source of Truth** — Every piece of business data has one authoritative source. - **MVP First** — Build the smallest solution that delivers measurable business value. --- # Core Domains - Student Lifecycle - Teacher Management - Academic Structure - Student Billing - Finance - Administration --- # Foundation Capabilities Every module shares these platform capabilities: - Identity & Access Management - Organization Management - User Provisioning - Role & Permission - Master Data - Dashboard - Notification Center - File Management - Immutable Audit Trail - Data Exchange Framework --- # Identity & Organization Model Authentication is independent from business entities. ``` User │ Membership │ Organization │ Business Entity ``` Definitions: - **User** → Login identity. - **Membership** → Relationship between User and Organization. - **Business Entity** → Student, Teacher, Staff, Guardian, etc. Rules: - Users are not automatically Teachers or Staff. - Business entities may exist without login accounts. - One User may belong to multiple organizational units. - Roles are assigned by the organization. - Users never assign their own permissions. --- # User Provisioning The platform follows an invitation-based onboarding model. Default workflow: 1. Administrator creates an invitation. 2. Invitation defines Organization, Unit, and initial Role. 3. User accepts invitation. 4. User completes profile and credentials. 5. Membership becomes active. Self-registration is intentionally excluded from the MVP. --- # Authorization Model MOS uses a hybrid authorization model. ``` User ↓ Membership ↓ Role ↓ Permissions ↓ Policies (Attributes) ↓ Accessible Data ``` Where: - **Role** defines who the user is. - **Permission** defines what actions are allowed. - **Policy** defines which data those actions apply to. Policies may include: - Organization - Unit - Department - Assigned Class - Academic Year - Data Ownership Avoid role explosion by expanding policies instead of creating new roles. --- # Data Model Principles Data is categorized into four layers. ## Master Data Permanent business entities. Examples: - Student - Teacher - User - Subject - Department - Chart of Accounts --- ## Reference Data Configurable operational references. Examples: - Academic Year - Semester - Grade - Class - Billing Template --- ## Operational Data Historical activities. Examples: - Enrollment - Class Membership - Teacher Assignment - Student Status History - Certificate Distribution --- ## Transaction Data Business transactions. Examples: - Invoice - Payment - Income - Expense - Budget - Transfer Historical data is append-only. Never overwrite previous records. --- # Academic Year Philosophy Academic Year is contextual. It is **not** the backbone of the system. Permanent entities remain unchanged throughout their lifecycle. Instead of recreating data every year, create new historical records. Examples: - Enrollment - Teacher Assignment - Class Membership - Billing Plan Reports are filtered by Academic Year instead of duplicating data. --- # Audit Trail Every significant business action records: - WHO - WHEN - WHAT - FROM - TO - WHY - HOW Audit logs are immutable, append-only, searchable, and permission protected. Every import, financial transaction, permission change, and business mutation must generate an Audit Trail entry. --- # Dashboard Philosophy Dashboards are workflow-oriented, not role-oriented. The dashboard is composed of reusable widgets. Widget visibility depends on permissions and policies rather than hardcoded roles. Dashboard priorities: - Alerts - Today's Work - Key Metrics - Notifications - Quick Actions Business users focus on operational activities. Platform administrators focus on system management. --- # Workspace Model The platform provides two workspaces. ## Business Workspace Operational modules. - Students - Teachers - Billing - Finance - Administration - Events ## Administration Workspace Platform management. - Organizations - Users - Memberships - Invitations - Roles - Permissions - Audit Trail - System Settings Workspace visibility is permission-based. --- # Data Exchange Framework Import and Export are shared platform capabilities. ## Import Purpose: - Excel migration - Bulk create - Bulk update Requirements: - Downloadable templates - Validation - Duplicate detection - Preview - Error reporting - Import history - Audit Trail - Background processing ## Export Purpose: - Reporting - Backup - Offline access - Spreadsheet analysis Requirements: - Excel & CSV - Respect filters - Permission-aware - Export history for sensitive modules Business validation rules must be identical between manual input and imported data. --- # MVP Modules ## Student Management - Enrollment - Student Profile - Guardian - Academic Status - Promotion - Graduation - Alumni ## Teacher Management - Teacher Profile - Assignment - Attendance - Performance - Employment Status ## Student Billing - Billing Plans - Invoice Generation - Discounts - Subsidies - Payments - Outstanding Balance ## Finance - Chart of Accounts - Income - Expense - Transfer - Budget - Cash Flow - Reports ## Event Management - Calendar - Google Calendar Integration - Reminders ## Letter Management - Incoming Letters - Outgoing Letters - Disposition ## Certificate Management - Certificate Registry - Distribution Tracking --- # Planned Modules Designed for future expansion without changing the architecture. - Library - Student Attendance - Student QR Card - Extracurricular - Teacher Portal - Parent Portal - Inventory & Asset Management - Dormitory Management - Procurement - Assessment & Gradebook - Curriculum Planning - Mobile Application - Payment Gateway - AI Assistant - AI Analytics Future modules must reuse existing entities instead of creating duplicate databases. --- # Global Design Principles Always: - Understand the business problem first. - Extend existing capabilities whenever possible. - Preserve historical integrity. - Reuse existing entities. - Keep MVP intentionally simple. - Document assumptions explicitly. - Evaluate Permission, Audit Trail, Dashboard, Notification, Reporting, and Import/Export impacts for every new feature. Never: - Duplicate business entities. - Overwrite historical records. - Introduce unnecessary modules. - Generate implementation before validating business rules. - Optimize for hypothetical future requirements. Business correctness always takes priority over implementation speed. --- # Language Convention The application UI, forms, validation messages, and all user-facing content must use **Bahasa Indonesia**. Source code, architecture, database schema, APIs, documentation, variables, naming conventions, and business terminology must consistently follow **English best practices** to maximize maintainability and AI-assisted development.
Design by The Resonance | Powered by GPC – The AI Transformation Company