如何建立學校管理系統

學校管理系統保存學校運作所依賴的紀錄：學生是誰、他們在哪些班級、是否有出席，以及他們的表現如何。一個有用的第一版，遠比多數人想像的要小：學生、班級、考勤及成績，再配以管理人員、教師和家長各自的登入。把這些做好、仔細測試權限，然後才加入時間表、學費及訊息功能。

本指南適合小型學校、補習中心、語言學校、課後活動機構，以及培訓機構，這些機構覺得大型系統對其需要而言過於沉重或昂貴。

學校管理系統需要什麼

資料

大部分功能都圍繞六張資料表：

待考勤功能運作正常後，再加入評核（班級中的測驗或作業，附最高分數及比重）與成績（一名學生在一項評核中的結果）。

報名紀錄這張資料表比表面上更重要。學生會在學期中途轉班。如果把「班級」直接存放在學生資料上，你就會失去歷史紀錄，考勤報告也將無法對得上。

頁面

• **管理人員儀表板：**今日考勤一覽、未有點名的學生、最近的更改。
• **學生列表及檔案：**可搜尋，可依班級或學年篩選，檔案中顯示班級、考勤及成績。
• **班級頁面：**名單、今日點名及成績簿。
• **點名畫面：**教師每天使用的畫面，應該在手機或平板上數秒內完成。預設為出席，點擊即可更改。
• **成績簿：**評核為欄、學生為列，並附計算平均分。
• **家長檢視：**只顯示他們自己子女的考勤、成績及通知。

權限

學校系統的成敗往往取決於此。在建構前先寫下規則：

• 管理人員可以查看及編輯所有資料。
• 教師只能查看及編輯他們任教的班級，以及班內的學生。
• 家長只能查看自己的子女，且為唯讀。
• 學生（如果他們會登入）只能查看自己的紀錄。

「只能」必須在伺服器端強制執行，而不只是隱藏按鈕。家長若在頁面網址中更改數字，不應能打開另一個孩子的檔案。我們的角色式存取控制指南會介紹這種模式。

開始前需要決定的事項

**第一版要不要讓家長與學生登入？**只讓教職員登入會簡單得多。家長與學生會令權限情況和支援要求都倍增。許多學校會先只讓教職員登入，並以印刷本或電郵方式把報告寄給家長，直至核心功能穩定為止。

**成績如何計算？**加權平均、扣除最低分、字母等級區間、合格與不合格，請選定一種計分方式，並附上一個例子寫明。成績計算邏輯是最值得人手核對的部分。

**什麼是「學期」？**班級、報名及報告都依賴它。決定你使用的是學期、學段，還是整個學年，並把它做成資料表，而不是一個文字欄位。

**匯入，而非重新輸入。**你幾乎肯定已經有一份學生名單在試算表中。從第一天起就應規劃學生、監護人及報名紀錄的 CSV 匯入功能。參見如何把試算表變成應用程式。

**資料存放在哪裡，以及誰可以查看？**學生紀錄十分敏感。在許多地方，它受特定規例規管，例如美國的 FERPA、歐盟及英國的 GDPR，以及其他地方的相關規定。在載入真實姓名之前，請確認適用於你的規定，如有不確定，請諮詢專業顧問。最低要求是：預設為私人、記錄誰更改了什麼，以及能夠匯出或刪除學生資料的方法。

有效的第一個提示

為一所小型學校建立學校管理網頁應用程式。教職員以電郵及密碼登入；角色分為管理人員及教師。資料包括：學生（姓名、出生日期、年級、狀態）、與學生相連的監護人、教職員、學期、班級（名稱、科目、教師、學期、每週時間表），以及把學生與班級相連、附開始與結束日期的報名紀錄。教師只能查看他們任教的班級，以及在班內的學生；管理人員可以查看所有資料。建立班級頁面，包括名單及每日點名，預設所有人為出席，教師可點擊標示缺席、遲到或請假，並可選擇加入備註。管理人員儀表板顯示哪些班級尚未完成今日點名。加入學生及監護人的 CSV 匯入功能。所有資料儲存於資料庫。成績、家長登入及學費留待以後。

注意這個提示做了什麼：它列出角色，用一句話說明權限規則，詳細描述最常用的畫面，並說明要剔除哪些功能。

建構步驟

1. **資料模型與範例資料。**要求建立資料表，以及一所小型、明顯屬虛構的範例學校：兩個學期、五個班級、四十名學生。建構期間切勿使用真實學生紀錄。
2. **管理員畫面。**學生列表、檔案、班級列表、報名編輯。確認把學生轉班時，舊的報名紀錄會保留並設定結束日期。
3. **教師登入及點名。**以教師身份登入，確認你只看得到自己任教的班級。在手機大小的畫面上完成一次點名。
4. **權限測試。**以兩位不同的教師登入，並嘗試透過網址打開對方的班級。兩次嘗試都應失敗。
5. **匯入。**把你的真實試算表匯入一份副本，修正無法對應的欄位，然後決定是否已準備好正式啟用。
6. **成績。**加入評核及成績簿，並用你親手計算的一個例子測試平均分。
7. **報告。**按日期範圍列出每位學生及每個班級的出席百分比，這是管理人員最常被要求提供的報告。
8. **家長存取（如有需要）。**最後才加入監護人登入，採用唯讀檢視，並進行最嚴格的權限測試。

常見錯誤

• **把班級直接存放在學生身上。**應使用附日期的報名紀錄，否則歷史會消失。
• **權限只存在於介面中。**隱藏按鈕並非保安。要透過網址及 API 進行測試。
• **點名太慢。**如果考勤比紙本更花時間，教師就會停止使用。
• **測試時使用真實資料。**在權限獲得證明之前，請使用虛構姓名。
• **刪除學生紀錄。**應改為標記為已離開。過去的考勤與成績仍然屬於學校的紀錄。
• **同時建構所有功能。**時間表、學費、訊息、成績表及家長應用程式同時進行，會需要一整年。應先推出點名功能。
• **沒有審計紀錄。**當某項成績被更改時，總會有人問誰在何時更改。要記錄下來。

何時採用現成產品更合適

成熟的學校管理及學生資訊系統能處理自訂建構難以匹敵的事項，例如政府及考試局的呈報、複雜的時間表編排、與學習平台的整合、學費收取，以及多年累積的各種特殊情況。如果你經營大型學校、有法定的呈報責任，或需要供應商承擔支援及合規工作，就應該購買現成系統。

當你的需要較為狹窄或特殊時，自行建構才有道理：例如補習中心需要追蹤課節及進度、語言學校採用滾動報名、培訓機構以批次開課，或小型學校只使用昂貴系統的五分之一功能。一個能準確配合你工作流程的專注工具，往往勝過你每天都要與之搏鬥的大型系統。我們的自建 vs 購買軟件指南會分析其中的取捨，而如何建立內部工具則涵蓋只供員工使用的版本。

在 Mythex 建構

在 Mythex，你在對話中描述系統，並在即時預覽中看著它成形。在動筆寫程式之前，先使用計劃模式，確定資料表與角色。當應用程式需要時，Mythex 會加入專用的資料庫；如果你想把文件附加到學生檔案上，則可使用檔案儲存。教職員及家長的登入屬於你的應用程式本身：Mythex 不提供內建的登入產品，因此代理人會接入你選擇的方式，見為應用程式加入登入。發布至 mythex.ai 連結，或在 Pro 方案下使用你自己的網域。該地址是公開的，因此保障紀錄私隱的，正是你應用程式的登入及權限檢查。如需起點，可參考教師評分工具範本，或補習中心建構頁面。

常見問題