由於車主權益是透過義務的履行才能持續保有，過去公司只是很單純的把銀行辦卡與核卡資料提供給經銷商，並無做有效的管理與應用，有了前車之鑑，必須透過資訊系統做會員權益管理，此專案才具有執行性。
透過快速學習，串連外部單位資料庫
玉山銀行、紅利系統、客服中心、產險公司、刷卡機廠商、經銷商等單位都有客戶或交易資料，各自都有資訊系統做管理與應用，但對我們而言，我們都得與自己的資訊系統整合在一起，而在整合之前，都必需與各公司詳談系統需求與定義，同時也把資訊流的架構確認清楚。
在過程中，我必須很清楚瞭解站在專案負責人的立場，甚至是公司經營會員的立場，我希望資訊系統（包括資料庫）需要什麼？要做到什麼？甚至未來可以延伸什麼。先清楚這些關鍵問題，才能與各公司的資訊單位討論，引導其配合我方需要。
我承認剛開始其實我並太懂資料庫與資訊系統的專業領域，所以剛開始和別人溝通時，都是「聆聽」居多，不然就是「多問」，在幾次討論會議之後，我漸漸地瞭解各公司的作業流程與資料庫的一些Know-how，也就較能跟得上他們，變得得心應手，在技術上當然構不上專業，但在專案的企劃上，我就變得比他們更專業了。
過程中我得自己或是與合作團隊一起思考許多問題，比如說：
(1)基於什麼樣的目的去設計應有的資料欄位（我該拿到什麼樣的data）
(2)該用什麼樣的Key作為比對條件
(3)該給系統什麼的邏輯判斷，甚至能不能與實務吻合？執行人員操作上有無限制？
(4)資訊流機制如何串連
描繪出系統架構後與內部溝通合作與完成系統建置
在與外部單位溝通到較為明確的程度後，就是要把菜端給公司內部的資訊中心的時候了，在良好的互動下（資訊中心幾位同事都是好人），我們溝通了專案內容重要概況，使其瞭解系統的重要性與必要性，我也被要求要提出清楚的「業務要件」，他們才好基於業務要件內容設計我們所需要的系統功能。
業務要件大致有以下幾大項：
‧提出系統架構需求
‧新車車主權益比較邏輯
‧舊有車主權益比較邏輯
‧整體系統比對邏輯
‧與產險公司強制險資料流架構
‧與銀行及客服中心三方資料流架構
‧服務廠接待之保修系統畫面訊息顯示
‧接待之保修系統遇實際具延保權益車主的對應
‧金流報表作業流程與製作
在他們熱心的協助下，系統還真的有被建構起來，也可開始與外部單位的資料流做串連測試。對資訊中心而言，大概只是用資料庫語言寫了好幾個程式，且相互串來串去，或是設定自動檢核機制等。而做完之後，可能再多些維護(maintain)的工作而已。但對專案而言，其實是核心中的核心，沒有系統，就做不到以下的目標了：
(1)會員權益管理（某會員在某時具備什麼的權益）
(2)資料庫管理（多方資料庫的串連，甚至是交叉分析）
(3)滿足經銷商的需求（經銷商很希望能獲得豐富而正確的會員資料）
(4)讓第一線認為我們是用心的
（待續）
留言列表
