將系統連接為一體

一個讓ERP、CRM、行業系統和試算表自動交換數據的樞紐，每項數據交換都有說明，並可隨時查看是否正常運作。

與我們討論您的項目查看範圍

範圍

客戶找我們時的情況

同一位客戶輸入了三次
銷售人員在CRM中建立客戶資料。由於系統沒有連接，會計部在ERP中再建立一次。營運部第三次把客戶輸入行業系統。三筆記錄久而久之出現差異：地址不同、稅務編號不同、聯絡人不同。發票寄到舊地址，投訴則由一位不知道資料已更改的同事處理。
合作夥伴要求按其格式和時間提供數據
銀行、電訊營運商、零售連鎖店或大型供應商，要求以既定格式、在既定時間收到訂單、確認和結算資料。公司以人手應付：有人匯出檔案，在試算表中調整欄位，再以電郵寄出。這位同事不在時，數據交換便停頓。合作夥伴一旦更改格式，整套工作就要重新安排。
每個連接都是個別建立的
系統之間有部分連接，但每個連接都由不同承辦商在不同時期建立。沒有人有一份清單，列明哪套系統與哪套系統溝通、傳遞哪些數據。更換CRM供應商或ERP版本，就意味要逐一檢查所有連接，因為沒有人知道哪些會停止運作。

範圍

我們的工作

API即應用程式介面：一套約定的方式，讓一套系統在無需人手參與下向另一套系統提供數據。API層是公司各系統互相溝通的單一樞紐。每套系統只需連接一次，連接到API層，由API層負責知道從哪裏取得客戶數據、把訂單送往何處，以及某套系統沒有回應時應如何處理。
我們連接已在運作的系統。ERP、CRM、行業系統、網店、倉庫管理軟件：每套都有某種數據交換途徑，可能是製造商提供的現成介面、檔案匯出，或資料庫存取。我們核實系統提供哪種途徑、在甚麼條件下提供，然後把這條途徑接入API層。除非分析顯示正是該系統拖慢流程，否則我們不會更換系統。我們把試算表視作一套系統：如果部門在試算表中工作，API層會為它提供數據並接收結果，直至公司決定取代它為止。
在部分行業，數據交換方式早有規定。在電訊業，這是TM Forum，即營運商之間合作的行業標準。如果您的行業有這類標準，API層會使用該標準的語言，而您的內部系統無需了解它。
最終會產生三樣東西。介面：為每套系統約定的輸入和輸出，並以您公司的數據驗證。文件：說明每項數據交換涉及哪些數據、從哪裏來、到哪裏去、頻率如何、由誰負責，形式讓下一位承辦商也能讀懂。數據交換監察：可查看哪些交換已完成、哪些停頓及原因，並通知指定人員。

範圍

您會得到甚麼

- 數據流向圖：各系統、系統之間傳遞的數據、每項交換的方向和頻率，以及公司這方負責每項數據的人員。
- 部署在歐盟境內的雲端或您的基礎設施內的API層，附每個介面的文件。
- 與現有系統的連接，在上線前以您的數據驗證，並說明出錯時會發生甚麼。
- 附通知和日誌的數據交換監察，日誌顯示每項交換及其結果。
- 連接下一套系統的指引，以備更換CRM供應商或新增網店時使用。

範圍

工作如何進行

1. 我們整理數據流向。我們與目前負責重複輸入數據的同事面談，並從內部查看各系統。成果：數據流向圖，以及待建立的數據交換清單，按每項交換所取代的人手工作量排序。
2. 我們設計API層。我們確定哪套系統是每項數據的來源、每個介面的形式，以及系統沒有回應時如何處理。成果：在建構前交由您確認的API層設計和介面文件。
3. 我們逐一連接系統。每個連接分別上線，先在數據副本上運行，再投入一個部門的日常工作。成果：數據交換逐項自動運作，人手重複輸入逐個部門停止。
4. 我們移交監察工作。我們啟動監察，教導指定人員閱讀數據交換日誌，並提交連接更多系統的指引。成果：數據交換按合約由您的團隊或我們負責維護。

範圍

團隊經驗

團隊成員曾在電訊業建構符合TM Forum標準的營運商間平台，並為一家批發市場營運商建構產品目錄管理系統；批發市場即營運商之間的服務交易。在金融業，團隊成員曾建構具備文件識別和債務追收自動化功能的ERP和CRM。他們亦曾在一家銀行業客戶的集團旗下多家公司負責實施JIRA並將其標準化，JIRA是一套處理工單和任務的工具。

範圍

管理層應向整合承辦商提出的問題

1. 項目結束後，介面文件由誰保管？內容是否寫得讓其他承辦商也能讀懂？
2. 如果其中一套系統一小時無法使用，數據會怎樣：等待、遺失，還是重複傳送？
3. 數據交換停頓時，誰會得知？以甚麼方式得知？
4. 連接下一套系統，或更換現有系統的供應商，需要多少工作？
5. 哪些個人資料會經過API層？存放在哪裏？誰可以存取？
6. 連接我們的ERP或CRM是否需要製造商同意或授權？由誰取得？
7. 上線前會以哪些數據驗證連接？我們這方由誰確認結果？
答案取決於涉及哪些系統和哪些數據，因此我們從分析流程和系統開始，並以附工作範圍的建議作結。