光映科技 (Stella) 新世代系統
實務場景與雙向共識討論書
【前言】
針對光映科技新世代系統的建置，我重新梳理了上一版的討論文件。上一版雖然涵蓋了豐富的實務情境，但在「系統分工」與「模組界線」的定義上還不夠明確，容易導致資料庫架構與業務管理產生混淆。
本次的「進化版」將日常業務的實際行為模式，精準對應並拆分進五大獨立系統模組中。我們嚴格剝離了「動態行為（如拜訪打卡、待辦任務）」與「靜態資料（如客戶主檔、設備清單）」的界線，讓每一筆資料的流向都清晰可見。
這套系統的運作核心，將完全聚焦於「分公司硬體業務部」的前線作戰需求。這不僅能確保未來開發架構的高延展性，更能讓大家明確了解每一項功能「該在哪個模組操作」。請各位透過以下五大模組的輪廓，與我一起檢視實務上的契合度，實現真正的降本增效。
全域資料流向與五大系統模組
權限與帳戶
基底身份與跨區連線
業務管理任務
動態打卡與會議
客戶 CRM
靜態資產與公海
訂單交接
行政與文件拋轉
設備生命週期
二次經營與情報
一 使用者帳戶權限管理系統 (User & Access Management)
1. 實務場景與核心價值
本模組的核心價值在於「資料資產防護」、「跨境安全連線」與「責任邊界釐清」。由於業務常需前往中國大陸（竹科與內地客戶雙軌），系統必須確保在中國網路環境（防火牆牆內）下能穩定且安全地登入；同時，系統會嚴格紀錄每次登入的實體設備資訊，防止帳號私下出借，並在人員異動時確保客戶資產 100% 完整移交。
2. 角色權限劃分與視野邊界
- 分公司主管（硬體業務部）：上帝視角與控管權
- 全域視野：查看全公司所有業務名下的客戶資產、跟催進度與營運數據。
- 帳號停權與防刪除：遇人員異動可將帳號「停權」。曾有資料紀錄的帳號禁止「實體刪除」，確保資料庫完整。
- 一鍵資產轉移：業務離職時，可將其名下的客戶與未結案訂單批次轉移給接手同仁。
- 一般業務：專注視野
- 個人工作區：僅能存取「自己名下」的客戶、拜訪日誌、負責訂單與設備進度，保護個人開發機密與專注度。
- 台北總公司行政人員：任務限定視野
- 階段性讀取權：僅能看見「已成單 / 進入訂單階段」的客戶基礎聯絡資料，無法讀取未成單的潛在客戶或拜訪紀錄，用於開立 PI 及對接德國原廠發貨。
全域視野、帳號防刪與資產一鍵轉移。
僅存取自己名下客戶與設備進度。
僅能看見已成單客戶資料，處理 PI 與發貨。
全域視野 or 僅看銷售數據？
3. 跨境登入與身份驗證方案評估 (影響開發與外部 API 成本)
因應大陸出差需求，傳統的 Google / LINE 登入在大陸環境無法使用，系統提供以下四種登入機制供公司決策：
| 登入驗證方案 | 大陸連線可行性 | 外部費用與維運成本 | 使用者體驗與安全性 |
|---|---|---|---|
| 方案 A：帳號 + 密碼 + 圖形驗證碼 | 完全可行 (無防火牆阻擋問題) | 零額外費用 | 最標準作法。需規範密碼複雜度與定期變更。 |
| 方案 B：中國/台灣 手機簡訊驗證碼 (SMS) | 完全可行 | 需負擔簡訊發送費 (按條計費，如阿里雲 SMS) | 免記密碼，安全性高，但每次登入皆有簡訊發送成本。 |
| 方案 C：第三方平台授權 (釘釘 / 飛書) | 完全可行 | 基礎 API 免費 (需企業申請平台帳號) | 若公司內部已有使用釘釘或飛書，可免密碼一鍵登入。 |
| 方案 D：企業微信授權登入 | 完全可行 | 需企業微信認證與開通費用 | 需綁定微信生態系，導入與驗證流程較為繁瑣。 |
建議方案：第一階段建議以「方案 A (帳號密碼)」或「方案 A + 簡訊/釘釘」為主，即可滿足 100% 跨境登入需求且系統架構最穩定。
4. 登入設備紀錄與 Session 安全控管
為防止系統帳號被私下出借給非公司人員使用，並釐清資料變更責任，系統內建以下設備控管機制：
- 登入設備軌跡 (Device Log)：每次登入時，背景會自動記錄：登入時間、IP 位址、實體設備類型（iPhone/Android/Windows PC）、作業系統與瀏覽器版本。
- 多設備併存與互踢機制 (選配功能，影響報價)：
- 模式一：允許多端同時在線（預設）：業務可同時在手機（打卡用）與筆記型電腦（填寫紀錄用）保持登入狀態。
- 模式二：單一設備強制作廢（互踢機制）：當同一帳號在「設備 B」登入時，系統會自動將「設備 A」強制登出，確保同一時間僅有一台裝置可操作系統，防止帳號共享。
📝 需與團隊開會共識的提問 (帳戶與登入安全專用)
為確保開發範疇與報價準確，請主管與團隊協助確認以下問題：
- 選項 1：標準帳號密碼（最穩定、無額外費用）
- 選項 2：帳號密碼 + 簡訊驗證碼（需預算簡訊發送費）
- 選項 3：串接公司現有的第三方平台（如：釘釘、飛書或企業微信）
二 業務管理與日常任務管理系統 (Sales Activity & Task Management)
1. 實務場景與核心價值
本模組是業務前線作戰的「行事曆與任務中心」。模組邊界嚴格區分「行為」與「靜態資料」——專注於紀錄業務「什麼時候、去哪裡、見了誰、開了什麼會、接下來要做什麼」。核心目的是透過行動化輔助，大幅降低業務在外奔波後，回辦公室還要補寫一堆報告的行政負擔，同時確保主管能掌握案件的推進節奏。
2. 業務人員基本資料建構與維護 (基礎 Master Data)
雖然帳號權限（能不能登入）歸屬在模組一，但業務在公司內部的「實體身份資料」將建立於本模組。這是所有客戶分配、業績歸屬與報價單簽名的基礎來源。
- 欄位建構邊界：包含業務姓名、聯絡電話/分機、所屬區域（台灣/內地）、職級、直屬主管設定，以及在職/離職狀態。
- 報價與架構意義：這份名單將作為系統內所有下拉選單（如：指派任務、移交客戶、會議出席人）的資料來源，確保資料的一致性與關聯性。
3. 行動化拜訪日誌與定位輔助
為了讓業務在外能快速建立工作日誌，系統提供基於手機瀏覽器的定位輔助功能，除非業務自動觸發打卡按鈕不然系統無法取得業務位置。
- 無圖資 API 架構（高性價比、無防火牆阻擋）： 系統不使用 Google Maps 或任何付費地圖。僅單純透過手機瀏覽器獲取當下經緯度，並與資料庫中的客戶座標進行「後台數學距離運算」，自動跳出「您目前附近客戶清單」供業務快速點選，省去手動搜尋打字的時間。
- 去中心化的時間紀錄（支援事後補登）： 系統完全不勾稽或追蹤業務的移動軌跡。若業務當下不方便操作，完全允許「事後補寫日誌」。為確保資料真實性與管理需求，系統在資料庫會自動分離並留下兩筆時間戳記：
- 實際拜訪時間（業務手手動選擇或確認的時間）
- 系統創建時間（這筆日誌實際寫入系統的時間）
4. 內部會議紀錄與模板化 (影響開發工時與複雜度)
專門用於記錄「公司內部」的日報、週會、月會及跨部門專案會議。
- 表單自訂程度（報價差異點）：
- 模式一：固定版型（預設建議，成本最低）：由系統端寫死幾種標準會議版型，包含通用的固定欄位（會議類型、主持人、參與人員、議題、決議事項）。
- 模式二：動態表單產生器（開發工時高）：提供後台讓主管「自由拖曳」新增/刪除欄位來創造新模板。
- AI 語音辨識（邊界確認）：考量商業機密與初期建置成本，第一階段明確「不導入」AI 語音轉文字功能。
5. 決議事項 (Action Items) 與待辦追蹤引擎
會議中產生的「決議事項」將轉化為可追蹤的任務。
- 任務指派與跟催：在會議紀錄中，可直接將事項指派給特定業務，並設定預計完成日。
- 自動化戰情儀表板：業務登入首頁時會看到專屬待辦清單，逾期任務亮紅燈警示；主管可從全域視角檢視所有人的任務達成率。
📝 需與團隊開會共識的提問 (業務管理與會議專用)
為確保開發範疇精準，請主管與團隊協助確認以下問題：
- 選項 A：全公司業務公開透明，作為經驗傳承。
- 選項 B：極度保密，僅「發布者、被標註的參與人與主管」可見。
- 選項 C：發布時由填寫人每次手動勾選誰能看見。
三 客戶關係管理系統 (CRM - Customer Relationship Management)
1. 實務場景與核心價值
本模組是公司的「客戶資產金庫」。模組邊界嚴格聚焦於「客戶是誰、聯絡人是誰、目前談到什麼階段」。我們將導入清晰的「主/從負責人雙軌機制」與「公海管理」，確保商機不漏接、老鳥帶新人有據可循，並嚴防業務間因重複建檔而產生搶單爭議。
2. 主副負責人雙軌制與歷史軌跡 (協同作戰與資產保護)
實務上，客戶經營常有「老鳥帶新人」或「跨區支援」的狀況，系統必須能如實反映這種協同作戰模式：
- 主要負責人 (Primary) 與輔助業務 (Secondary)：每個客戶只能有一位「主要負責人」（扛主要業績與責任），但可設定多位「輔助業務」。兩者皆能看見該客戶的完整資料與進度。
- 負責人異動歷史軌跡： 系統會自動寫入不可刪改的歷史 Log，明確記錄「某客戶從 X年X月 到 Y年Y月 的主要負責人是誰」。
- 歷史購買紀錄總覽： 客戶主頁將直接顯示過去的設備購買紀錄，包含：購買時間點、購買設備型號，以及「當時成交時的主要業務與輔助業務是誰」，讓接手人員瞬間掌握過往合作脈絡。
- 首要分水嶺 (台灣 / 大陸雙軌制)： 新增客戶資料時，系統會以「台灣」與「大陸」作為首要選擇。當業務選擇不同國家/區域時，系統會動態切換對應的專屬輸入欄位。例如：選擇台灣，介面會呈現「統一編號、縣市區」；選擇大陸，則切換為「統一社會信用代碼、省市區」，確保資料格式符合當地規範，避免欄位冗餘與輸入錯誤。
- 【報價邊界聲明】客製化國家擴充限制： 考量初期開發成本與系統穩定度，第一階段系統不提供「後台自訂新增國家欄位」的功能，將全數聚焦並鎖死於兩岸市場的業務需求。
- 歷史資料 Excel 批次匯入（重大報價差異點）： 針對舊有客戶資料，系統方將提供「標準表頭格式的 Excel 空白檔」。由內部業務或行政人員將資料整理貼入後，即可一鍵批次匯入系統。不進行高成本的客製化舊表單清洗作業。
3. 嚴格防重複建檔與主動分享機制
為徹底解決撞單問題，系統採行「唯一性阻擋與權限下放」策略：
- 唯一性防呆：客戶資料由負責的業務手動新增。當建立時，系統會比對「公司完整名稱」或「統編/信用代碼」，一旦發現同名資料，將絕對禁止重複新增。
- 主動開通輔助權限：若業務 B 發現客戶已被業務 A 建立，業務 B 無法自行搶件；必須由業務 A（主要負責人）在系統中將業務 B 加入為「輔助業務」，業務 B 才能參與該客戶的經營。這將大幅減少管理部的協調負擔。
4. 資料批次匯入與匯出控管 (影響權限與報價邊界)
- 標準公版 Excel 匯入 (降低開發成本)： 針對舊有客戶資料，系統方將提供「標準表頭格式的 Excel 空白檔」。由內部業務或行政人員將資料整理貼入後，即可一鍵批次匯入系統。不進行高成本的客製化舊表單清洗作業。
- 匯出權限極度鎖定： 為保護公司商業機密，「批次匯出客戶資料」的功能僅限【分公司主管】擁有。一般業務或行政人員無法將名單大量打包帶走。
5. 公海名單機制 (Public Pool)
- 公海定義：系統內凡是「尚未綁定主要負責人」的客戶資料（如：展會整批匯入的新名單），即自動視為「公海名單」。
- 公海名單僅顯示基本的公司名稱與聯絡資訊，等待被指派或認領後，才會轉入專屬業務的私海中進行深度經營。
6. 未來擴充性藍圖：AI 名片辨識回填 (Phase 2)
考量展會後常有大量名片需建檔，系統底層已保留未來串接「AI 光學字元辨識 (OCR)」的架構。
【報價邊界聲明】：為確保初期系統能快速上線並穩定運作，第一階段 (Phase 1) 暫不開發 AI 名片自動掃描回填功能。待系統推行順暢後，未來可作為第二階段的擴充升級項目。
📝 需與團隊開會共識的提問 (CRM 專用)
為確保管理流程符合公司文化，請主管與團隊協助確認以下問題：
- 選項 A（極權指派）：只有「主管」有權限從後台將公海名單指派給特定業務。業務不能自己去公海撈客戶。
- 選項 B（開放認領）：允許業務自己去公海「點擊認領」，先搶先贏。
四 訂單管理與跨部門交接系統 (Order & Admin Handoff System)
1. 實務場景與核心價值
本模組專責處理商機確認成單後的「行政作業、文件歸檔與跨部門拋轉」。由於新竹分公司業務部不經手實際金流與收款作業，本模組的核心價值在於確保合約與下單文件（如 EUC、BAFA）的完整性，並作為與台北總公司行政/財務端交接資訊的樞紐，讓對德國原廠的採購能無縫推進。
2. 訂單生命週期的「完結點」定義 (需討論確立)
系統必須明確定義「一筆訂單何時算正式結案」，這將影響資料流何時交接給【五、設備管理系統】。目前預設兩種常見的實務邊界供選擇：
- 斷點 A（行政作業完成即結案）：台北總公司開立 PI 並向德國原廠取得 HIMT NO. (原廠訂單編號) 後，訂單模組即視為「完成交接」。後續機台的生產、海運與交機，全數歸入「設備管理系統」追蹤。
- 斷點 B（完全交付與驗收才結案）：訂單的生命週期一路涵蓋到設備抵達現場、工程師完成調機、雙方簽署 SAT（現場驗收測試），甚至台北端確認尾款結清後，該筆訂單才算真正 Close。
3. 文件歸檔與存放邊界 (文件歸屬與成本控管)
訂單推進與交機過程中會產生多項關鍵文件（如合約掃描檔、原廠 Proposal、EUC、BAFA 申請、SAT 簽名頁等）。
- 歸屬彈性：這些文件究竟應附隨於「訂單紀錄」中，還是歸檔於「設備實體」名下，系統將保留彈性，交由主管依據現有管理習慣決定。
- 低成本歸檔策略：系統預設提供「外部 URL 網址連結」欄位，由業務將檔案上傳至公司現有的網路硬碟後貼上連結，避免系統產生額外的雲端儲存空間與流量費用。
4. 台北總公司「正航 ERP」資料拋轉
為避免雙重輸入的人工錯誤，系統將針對台北總公司正在使用的【正航 ERP 系統】，產出對應的標準化 Excel 匯出檔。
新竹業務與行政在本系統完成報價與訂單前置作業後，可一鍵匯出符合「正航 ERP 匯入公版格式」的 Excel，讓台北端無痛接軌後續的財務與進銷存流程。
📝 需與團隊開會共識的提問 (訂單與行政交接專用)
為確保跨部門協作順暢、系統邊界清晰，且前端介面符合實際需求，請主管與團隊協助確認以下問題：
- 選項 A：原廠確認接單，產生 HIMT NO. 就算結案（後續純粹追蹤設備進度）。
- 選項 B：機台運抵現場，客戶簽署完 SAT 驗收報告才算結案。
- 他們登入後，是否只需要看到一個專屬的「訂單任務清單」（僅包含已成單客戶的聯絡資訊、需處理的 PI/BAFA 文件與交辦事項）即可？
- 是否需要嚴格限制他們無法看見業務的日常拜訪紀錄、未成單的潛在客戶（公海/私海），以簡化他們的操作介面並確保業務開發機密？
五 設備生命週期與客戶二次經營系統 (Equipment Lifecycle & Secondary Sales)
1. 實務場景與核心價值
本模組專注於「實體機台」從德國原廠開始製造，一路到送達客戶端完成驗收的生命週期追蹤。考量到機台交付後的維修、調機與教學，均由德國原廠直接負責，分公司業務不再介入技術售後。因此，本模組的核心價值在於「商機雷達與關係維繫」。系統將漫長的設備等待期，轉化為業務不斷與客戶（採購/廠務）互動的籌碼；透過掌握客戶廠內的設備現況，確保未來客戶產線擴張或預算編列時，業務能掌握絕對的先機。
2. 設備主資料維護 (Master Data - 零程式碼擴充架構)
- 零程式碼擴充：設備型號與基礎規格開放在後台管理介面。未來原廠若推出新機型，主管只需在後台新增一筆資料，完全不需修改系統程式碼，馬上就能套用到前端的報價與設備清單中。
3. 設備進度情報網 (與德國原廠的資訊同步)
銜接【訂單模組】產生的原廠訂單編號 (HIMT NO.) 後，設備即進入製造與物流追蹤期（如：生產組裝➔出廠檢驗 ➔ 海空運➔進口清關 ➔ 抵達現場➔現場驗收 SAT）。
本系統不處理複雜的技術工單，而是作為「情報節點」。當任何一個關鍵節點發生改變時，系統狀態即刻更新，讓所有相關人員隨時掌握這台價值千萬的設備目前走到哪裡。
4. 自動化客戶關懷觸發機制 (業務最核心的武器)
這是本模組設計的重中之重。當設備狀態節點發生變更時，系統背景將自動拋送一個任務到【模組二：業務管理系統】的待辦清單中。
- 創造互動契機：例如，當系統狀態更新為「產品包裝出貨中」，系統即提醒業務：「請主動發信或致電告知客戶預估抵達時間」。
- 深化信任感：透過這類主動回報，業務能扮演德國原廠與在地客戶間的溝通橋樑，將冷冰冰的等待期轉化為高信任度的專業服務，讓客戶感受到「雖然是德國修機器，但台灣業務全程都在盯」。
5. 客戶專屬資產庫 (Installed Base) 與擴張預測
當設備完成 SAT 驗收並結案後，該設備將永久綁定於該客戶的主檔之下，清楚記錄機型、交機日期與當時負責業務。
精準的二次行銷：這份清單讓業務對客戶廠內的「火力配置」瞭若指掌。當客戶釋出擴廠風聲，或是同型號設備推出新一代時，業務能第一時間精準切入，不需要再盲目探問。
📝 需與團隊開會共識的提問 (設備進度與二次經營專用)
為確保系統的「提醒機制」能真正幫助到業務，請主管與團隊協助確認以下問題：
【結語與下一步行動】
以上五大模組的架構輪廓與技術邊界，主要是根據 Dino 哥先前提供給我的基本流程資料，以及我們上次會議中取得的資訊，所進行的系統大類別解析。然而，再嚴密的系統設計，也無法單靠外部視角就能完全涵蓋第一線實戰的隱性知識。
實質上，肯定還有許多真實的業務流程細節是我尚未完全掌握的，因此非常需要各位的實務經驗來填補這些空白。舉例來說，在「報價單」的處理流程上，實務上是如何運作的？
- Stella 的報價單，是由台北總公司直接發給客戶？還是總公司發給新竹業務部後，再由業務轉交客戶？
- 或是分公司業務會直接向德國原廠詢價？
- 這套系統是否需要協助產生「基礎報價單模版」？（例如：雖然沒有具體的機台內容，但系統可以一鍵帶入客戶抬頭、公司聯絡資訊、標準合約條款等），以節省業務每次複製貼上的時間？
誠摯邀請大家回想一下，平時在處理日常公務時，時間最常消耗在哪裡？有哪些「重複性的庶務工作」是你們希望能多讓系統去分擔的？
本系統的最終目的，是作為各位前線作戰的最強後盾，替大家處理掉繁瑣的行政追蹤與防呆機制，讓大家能把省下來的寶貴時間，全數投注在「培養客戶關係」與「與客戶高頻互動」之上，進而為公司創造更大的業務產值。歡迎大家針對上述的提問多多補充，期待我們能在接下來的討論中，打造出最貼合大家使用習慣的專屬系統。