數據整理與數據流

我們首先議定每項數據的含義，因為「客戶」、「有效合約」和「銷售」在每個部門都有不同定義。對每項客戶、產品和銷售數據，我們確定其產生的系統、公司內的負責人，以及所有部門接受的定義。此外，我們寫下數據質素規則，處理欠缺部分資料的記錄、重複登記的客戶，以及兩個系統數值互相矛盾的情況。每種情況都有一條規則：拒絕、標記待核，或採用指定來源的數值。

接着我們建構數據流，即數據由產生它的系統，到報告和AI模型取用之處所經的路徑。這個地方就是數據倉庫：一個存放所有系統經查核數據的資料庫，每份報告和每個模型看到的都是同一組數字。傳輸本身就是ETL：從來源提取數據、按質素規則檢查、轉換為統一格式，再寫入數據倉庫。數據流可以定期運行，也可以實時運行，即來源系統的變更一產生便送入數據倉庫。

現有系統保持不變。把系統連接起來，讓它們在日常工作中互相交換數據，屬「系統與整合」服務的另一範圍；這裏處理的是供報告和模型使用的數據。建基於這個數據倉庫的管理報告和儀表板，亦屬另一服務範圍。工作成果包括數據來源說明、質素規則，以及一條可查看數據是否送達的運作中數據流。

1. 我們確定每項數據的來源。與現時負責編製報告的同事一起，查看每個系統如何記錄客戶、產品和銷售。成果：數據來源說明，以及系統之間有待您決定的矛盾清單。
2. 我們議定定義和質素規則。為每項有爭議的數據指定來源和負責人，並為缺漏和重複寫下規則。成果：在開始建構前由您批准的質素規則。
3. 我們建構數據流，並以您的數據驗證。逐一把系統納入數據流，並把數據倉庫的數字與各部門現時報告中的數字比較。成果：存有經查核數據的數據倉庫，以及與現有數字每項差異的解釋。
4. 我們讓數據流投入日常運作。報告使用者和AI團隊轉用數據倉庫，原有匯出停用，監察畫面和通知交由指定人員負責。成果：一個投入使用的單一數據來源，以及負責監督它的人員。

1. 當CRM和ERP的數值不同時，哪個系統是客戶數據的來源，我們這邊由誰決定？
2. 數據流會如何處理欠缺部分資料或重複登記的記錄：拒絕、標記，還是放入數據倉庫？
3. 來源系統出現變更後，要多久數據才會出現在數據倉庫？
4. 某個系統的數據沒有送達，誰會在多久之後知道？
5. 數據倉庫的數據存放在哪裏，哪些屬個人資料，由誰授予存取權限？
6. 定義和質素規則會否以文件記錄，讓其他承辦商無需詢問原作者也能新增數據項目？

哪些數據、來自多少個系統、以甚麼速度匯入同一數據集，我們會在流程分析中確定，並以附工作範圍的建議作結。