真理堂數轉小組第三十二次週會會議紀錄

 

會議時間: 11月5日(三)中午12:30

與會人員: 主席Joann、詩清長老、明理、怡如、Joseph、Deborah

 

本周周會主要討論教會對需求書內容的反饋，同時包含AI知識庫、會計系統自動化、資安措施，以及系統開發與測試等議題。

    1. 網頁瀏覽器相容性

會議首先確認了關於 IE (Internet Explorer) 相容性的需求。

    • 結論： 基本不需要特別針對 IE 進行優化。
    • 背景： 雖然 IE 已經不是主流，但過去微軟 Windows 上的 Active X 功能導致 IE 難以淘汰。目前只有非常傳統的監控系統可能需要 IE 的插件 (plugin) 才能運作。
    • 主流瀏覽器： 教會內部的主流瀏覽器仍然是Chrome。
  1. AI 知識庫導入與規劃
    • 現狀與聚焦： 牧者（特別是焜梁牧師）認為如果 AI 知識庫的目標和目的不夠清楚，應讓牧師們重新聚焦討論並安排進度。如果 AI 部分跟不上第一階段的開發，可以慢一點，不要卡住其他功能進度。
    • 初期需求背景： AI 應用最初區分為對內和對外。對外應用曾討論導入 AI 智能客服以建立常見問題 (FAQ)。但後來決定先以內部應用為主。
    • 內部需求：在最早的內部需求收集階段，許多部門提出了建立知識庫的需求，因為教會知識和資訊繁雜。具體需求包括：
      • 查詢教會行政規章和流程參考。
      • 快速查閱會議記錄及已定案的結論（如主牧遴選辦法）。
      • 見證搜尋（例如為講道查找特定的文字或影片見證）。
      • 查找專案活動的歷史記錄，包括活動計畫內容、流程、出席率、經費、合作廠商資料。
      • 建立廠商資料庫。
    • 焦點轉移： 儘管初期需求多元，但牧者決議先從文字見證開始，因為見證稿的資料被認為是最完整的。然而，這個方向後來發散到例如「生成講道」（牧者不需要）等用途，造成與原本期望不符。
    • 策略建議： 由於 AI 需求不確定性高，與會者建議：
      • 將 AI 知識庫從第一階段的八大系統中獨立出來。
      • 以 「沙盒 (Sandbox)」 的方式進行，作為一個 Lab (實驗) 性質的項目。
      • 建議盡早開始讓使用者和開發者接觸 AI 相關功能，從體驗中找出確切需求。
      • 此獨立項目可能需要另外一個合約或預算來處理。
      • AI 的發展甚至有可能在未來取代部分規劃中的 SaaS 功能。
    • 知識庫建立前提：在做 AI 知識庫之前，教會必須先有中央資料庫/知識庫，亞諾建議儘早開始收集與整理現有的規章、SOP 和歷史專案資料等，因為這些都是教會資產。
  1. 會計系統自動化串接
    • 現有進展： 亞諾與財務部已舉行實體會議，會診出財務部所需的報表格式、欄位和內容，並取得確認。目前可提供的報表結合了銀行/第三方支付記錄與會友資料，用於對帳。
    • 自動化規劃： 亞諾原建議先運作一段時間，等財務部熟悉報表後，再編列預算進行會計系統的自動化串接。目標是先讓財務部可以下載 CSV/Excel 檔，將資料批次匯入會計系統，以免除人工登錄。
    • 擔憂與建議： 主席指出，如果新系統在現階段沒有自動化功能，可能反而會增加財務部的人力負擔（因對帳頻率更高）。
    • 下一步行動：
      • 需要請明理與財務部、正航（會計系統廠商）確認系統可接受的匯入格式結構。
      • 同時確認是否需要將自動化納入考量。如果確定需要，會計系統自動化並不包含在數轉需求書第一階段的八大系統內，需請財務部另在 2026 年的預算中編列。
  1. 資訊安全與維運
    • 滲透測試 (首度)： 第一次滲透測試將在第一階段系統完成、內部調整後進行。
    • 頻率建議：
      • 滲透測試（由外部）：建議頻率為兩年一次，除非有重大架構變革（如功能增加超過五種）。滲透測試費用不便宜（約新台幣 12 萬至 15 萬）且耗時。
      • 弱點掃描（由內部）：建議頻率是每半年到一年一次。這是從內部檢視系統漏洞，可透過教會自行購買或租用軟體進行。
    • 安全維護 (年約式)： 建議教會將系統安全委託給美國前三大資安公司進行年度性保護。這類服務（如防範 DDOS 攻擊）成本不高（約一年新台幣 1 萬至 2 萬），但能有效增加保障，屬於「買保險」的概念。
    • 教會經驗： 教會過去曾遭受 Email Server 攻擊（後改用 Gmail）和網站攻擊（因使用舊版 WordPress），凸顯了資安維護的重要性。
    • 維運責任： 系統維運由亞諾團隊負責，但資安方面，弱點掃描工具和外部(第三方)資安服務的費用將納入日後的維運預算考量。
    1. 系統開發與測試細節

會議討論了使用者手冊、測試流程和介面設計。

    • 文件與測試：
      • 各系統使用者手冊 (User Guide)：亞諾確定會提供。
      • 測試時程：
        • 需要將測試時程反映到需求書內開發建置時程的甘特圖。
        • 採用滾動式開發，即每個模組完成後立即進行測試，不會等到整個系統結束。
    • 瀏覽器相容性 (關鍵)：
      • RWD 設計： 前端（給一般會員使用）將採用 RWD (Responsive Web Design)，確保在行動裝置上（手機）操作正常。後台管理介面則建議使用桌機。
      • LINE 瀏覽器： 教會特別強調，由於教會主要溝通渠道在 LINE，測試時必須包含 LINE 內部瀏覽器。儘管 LINE 瀏覽器相容性問題較多且難以完全控制，但這是非常高的使用情境，必須納入 QA 測試。
      • 詩清長老建議再加上Microsoft Edge。
      • 系統測試除了按照不同功能進行測試，也需依不同瀏覽器進行測試。
    • UI/UX 設計：
      • 目前 Google Drive 上的活動與報名頁面示意圖僅為工程圖，不是設計圖。
      • 亞諾建議採用現成購買版權的公版 template (範本)，然後替換 Logo 和調整風格。這樣可以節省時間且精準。
    • LINE 官方帳號整合： 建議考量如何將新系統的重要功能（如會員登錄、會友資料更新）整合到 LINE 官方帳號的設計和操作上，因為這是會友最重要的接觸點。
    1. 會友資料欄位與更新

討論了會友資料欄位的收集與維護。

      • 牧者需求： 牧者傾向於增加關於服事團隊的欄位，認為比專長欄位更具立即性需求。
      • 資料品質挑戰： 擔憂資料若為選填，可能會因為未填寫或資料過時而失去價值。
      • 更新策略： 建議可透過 活動操作（如參加課程打折、回娘家禮物）或將某些欄位設為必填來鼓勵會友更新資料。
      • 系統限制： 系統無法自動生成會友的恩賜或服事意願。這需要回歸到教會的牧養系統來推動和鼓勵大眾更新。
      • 下一步： 怡如將製作一個會友資料欄位的草稿給牧者審閱。

會議結論與後續步驟

    • AI 知識庫： 從第一階段需求書獨立出來，以沙盒方式進行實驗，不影響第一階段開發。
    • 會計自動化： 儘速與財務部及正航確認批次匯入格式，並確認 2026 年預算編列需求。暫不併入第一階段需求書。
    • 系統測試： 需求書將納入 LINE 內部瀏覽器的相容性測試。
    • 需求書最終調整： 亞諾將根據本次討論對需求書進行 Final 調整，並提供新版本給大家確認。