上週約了兩位經研所同學在桂林路的家樂福吃個飯，並聊一聊互相的近況。以大家現在工作的年資，都大約是中低階主管的資歷了，最是勞心勞力的一群，每天面對著繁瑣的工作，總會讓人感到心力憔悴。

其中一位同學現任職於xx壽險的放款科長，他知道我在IT軟體產業，他問我一個問題：「一年計息天數基礎(Days in year)為什麼系統不可以提供給使用者參數的型態，讓使用者自行決定，為什麼一定是360？印度的顧問竟敢要求我們修改作業規則去適應他們的系統，這可不是內部的作業規則，而是金管會的規定，放款的計息天數基礎是365。」

我想很多人的第一反應就是那個系統太爛，設計不良！但我不是如此思考！因為該外商的產品可是已經行銷好幾國，問題真正癥結點是出在當初合約的規範！當初xx壽險招標之時他所設定的想法：「他要買的是一個"package"?還是"solution"?」若是xx壽險所要的僅是一個套裝軟體，而且合約或Request for Proposal(建議書徵求書上)未明載計息天數基礎的需求。沒錯，就如那位印度顧問所言：「這是客戶的問題，要求客戶自己處理。」但如果xx壽險當初所要的是一個解決方案，而且合約已有載明系統必須能提供計息天數基礎的參數設定，那這問題就回歸到廠商的身上。

一般人或許以為這個修改很單純，不過改一下數字嗎？但在金融應用軟體上，基層參數與架構的修改可是牽一髮動全身喔！有些金融應用軟體是每日計息，有些是每月計息；計息天數基礎參數有的是所有產品別一體適用，有的是根據產品類別，有的是根據每一契約。這還牽涉到提前還款，解約，逾期…等不同的繳款狀態；而繳款的方式不同－現金臨櫃、便利商店繳款、支票繳納…－也會造成影響。因此這可不是改一個數字就好了的簡單想法。

個人近來忙於北部一家地方性金融機構的建議案，此次我們所提供的是一個解決方案"solution"。本案中我們除了包括一部份系統外，更擔任了系統整合商的角色。在合作的五家廠商中有的是提供套裝元件，有的是需要提供客製化修改，因此專案管理的責任跟風險就在系統整合商的身上。

日前聽說：「永豐銀行已簽約更換現有的Unisys銀行核心系統為Temenos系統。全程以英文為溝通的語言，而且以現有Temenos系統的功能為交付的功能，不進行修改。」若真得如此！則整體風險將在客戶的身上，廠商其實就只有安裝跟協助使用。

從以上的例子，我的客戶要的是一個"solution"；而永豐銀行要的僅是一個"package"。這其中的價格差異可是很大的！屆時永豐銀行在無法更改"package"下，勢必要修正一些作業規則，或者自行在"package"外面加以包裝，以符合實際的需求。

個人先前也曾親身參與過一個國際知名的應用產品廠商的專案。原國外母公司的規定是他們僅販售"package"和協助進行參數設定。但因為台灣的競爭激烈，業務們當成"solution"去賣，以致後續可能必須以非IT的能力去結案。這個就是一個非常大的盲點：「您賣(買)的是一個"package"?還是"solution"?」這跟專案成本跟時程的考量是緊密連結的，也跟專案進行方式與風險承擔更有著天壤之別的差異。