Janus ERP 是 MDA 架構的 ERP, 所以, 上線輔導的程序不應該那麼繁複且沒效率。
0. System Installation: Janus ERP 同樣將環境分為三個, 正式環境、測試環境、開發環境。
1A. Data Import: Janus ERP 已經有含轉檔的程式: 料號, 會計科目, 客戶, 供應商 ... 本階段要做的, 就是將舊系統的資料建入新系統。不管未來的系統解決方案如何設計, 以上的基礎資料變動的並不多; 但, 有了使用者熟悉的資料, 可以激發更多的 "想像"。預估約一週。
1B. Window Training: 了解系統的架構, 如何新增一個操作畫面, 增減欄位, 建立檢核條件 (Validation Rule)。這是很重要的一個步驟, 讓使用者可以在往後的輔導過程中, 懂的如何提出明確的需求、如何設計符合需求的系統, 並將過程記錄下來。預估約一週。
1C. Function Training: 使用真實資料做教育訓練; 看到日常作業的料號、供應商、客戶... 才能將落實訓練效果, 並反應出真實的需求。不管系統架構為何, 讓使用者的需求很快速, 明確的提出, 才是有效的導入手法。依各模組不同, 約一個月可完成, 包括: 了解 Janus ERP 已完成的功能, 以及了解系統應修改的項目; 修改的要求, 應該使用 Request Service 提出。
1D. Adjustment: 客製需求有四類,
Level 1. 增減欄位 (Field): 在上線輔導當天的下午應該可以修改完畢, 並讓使用者確認。
Level 2. 作業表單 (Report): 這個也很簡單, 一般的作業表單, 如採購單, 收料單, 工單, 領料單, 訂單, 出貨單等, 也應該在一天內完成。
Level 3. 新增作業畫面 (Window): 畫面的定義, 應該與使用者討論後, 二天內與使用者完成確認。
Level 4. 修改 JAVA 的程式 (Coding): 例如: IC Design 要求的雙單位, 不僅在 Puchase Order/ Material Receipt 畫面新增主/次單位而已, 入庫後二個單位的數量也要增加, 領料/ 出庫也要新增主/次單位, 完成後, 也要同步異動主/次單位的餘量。這些是要透過 JAVA 的程式開發才可達成, 時間依程式的大小而有所不同。
回頭看一下大廠: SAP, Oracle 的導入計畫, 教育訓練, 需求訪談, 需求映對, 客製, 上線模擬, 上線...等階段。Janus ERP 一步也沒有少做, 只是可以縮短從使用者提出需求到客製完成的時間。
而且, 因為畫面定義快速, 使用者不再是簽一份如 "空中閣樓" 般的文件, 造成更多責任歸屬的爭議, 那些成本根本對系統沒幫助。
2010年1月31日 星期日
ERP 上線輔導 - 7. 上線 & 上線後支援
新 ERP 上線已不再平行測試, 因為新舊系統架構差異, 無法平行測試比較。
正式上線的第一個月, 一定是人仰馬翻, 一堆沒預想到、已發生過、未發生過的問題, 都會蹦出來; 包括,
資料轉錯, 上線前已經知道要修正的;
作業流程錯, 實務上根本就錯的, 只好人工補強;
系統當機, 動不動就要重開機, 更改設定, 上 Patch...
Performance 差, 一堆人等在那裡, ...
顧問與 IT 人員可以解決以上問題; 只是, 通常需要一個月才會穩定下來。第一個月的結帳順利的話, 就可以放心的宣告 "上線成功"。
回顧 ERP 的上線歷程, 挑燈夜戰, 很辛苦, 也很有成就感。一般的 ERP 導入專案, 大約 8 個月的時間, 同事之間, 朋友之間, 因為 ERP 而建立更深厚的 "革命感情"。
正式上線的第一個月, 一定是人仰馬翻, 一堆沒預想到、已發生過、未發生過的問題, 都會蹦出來; 包括,
資料轉錯, 上線前已經知道要修正的;
作業流程錯, 實務上根本就錯的, 只好人工補強;
系統當機, 動不動就要重開機, 更改設定, 上 Patch...
Performance 差, 一堆人等在那裡, ...
顧問與 IT 人員可以解決以上問題; 只是, 通常需要一個月才會穩定下來。第一個月的結帳順利的話, 就可以放心的宣告 "上線成功"。
回顧 ERP 的上線歷程, 挑燈夜戰, 很辛苦, 也很有成就感。一般的 ERP 導入專案, 大約 8 個月的時間, 同事之間, 朋友之間, 因為 ERP 而建立更深厚的 "革命感情"。
ERP 上線輔導 - 6.上線模擬測試
辛苦了大半年, 終於到了上線模擬的階段;
雖然系統與買的時候的想像有所差異;
雖然作業流程, 資料量變的更龐雜, 人力反而倍數投入;
雖然專案拖延了幾個月的時間;
雖然還有很多的作業要在系統外處理;
雖然, ...
但, 無論如何, 就是還是捱到要上線了 (花了這麼多錢, 也很難跟老闆交代說無法上線)。
所以, 主要的工作就是:
資料轉檔: 料號, 供應商, 客戶, BOM & Routing, 會計科目...
開帳模擬: 庫存帳, 應收帳款餘額, 應付帳款餘額, OPEN PO, OPEN SO, 總帳...
作業流程模擬: 接單到出貨收款, 採購到收貨付款, 生產領退料, 製程移轉, 成本結算 ...
會有很多的不滿意, 也會有很多的無奈, 還有很多的不得已的故事。
雖然系統與買的時候的想像有所差異;
雖然作業流程, 資料量變的更龐雜, 人力反而倍數投入;
雖然專案拖延了幾個月的時間;
雖然還有很多的作業要在系統外處理;
雖然, ...
但, 無論如何, 就是還是捱到要上線了 (花了這麼多錢, 也很難跟老闆交代說無法上線)。
所以, 主要的工作就是:
資料轉檔: 料號, 供應商, 客戶, BOM & Routing, 會計科目...
開帳模擬: 庫存帳, 應收帳款餘額, 應付帳款餘額, OPEN PO, OPEN SO, 總帳...
作業流程模擬: 接單到出貨收款, 採購到收貨付款, 生產領退料, 製程移轉, 成本結算 ...
會有很多的不滿意, 也會有很多的無奈, 還有很多的不得已的故事。
ERP 上線輔導 - 5. 客製
從使用者提出需求開始, 到決定花錢客製, 到顧問撰寫系統分析 (System Analysis), 系統設計 (System Design) 文件, 供使用者確認, 通常約費時: 3-5 個月。
這是何等的大需求? 需要費時 3-5 個月的時間及成本; 誰來負擔費用? 難怪 ERP 客戶大嘆吃不消, 而顧問公司也不賺錢 (台灣的 Oracle, SAP 的本土顧問公司已經倒的差不多了)。
以上的時間, 還不包括正式開始寫程式, 只是估算到: 確認要寫的程式規格而已。會這麼沒效率, 全是 "系統架構" 的問題: 一支一支程式撰寫, 而不是透過定義的方式產生, 當然耗費人力。不僅外包開發費用高, 連自行找人維護的成本也很驚人。
程式撰寫過程中的問題, 主要有:
使用者自認講的很清楚, 顧問說: 寫在文件的才算數;
程式設計師認為顧問說的, 跟客戶要的, 根本是二回事;
程式設計師認為是範圍外的要加錢, 使用者說: 早就講了;
程式比估價時, 複雜太多;
需求變更多, 要求減 A項, 加 B項;
再考慮到顧問、使用者以及系統設計師的人員異動, 則事情更趨複雜。
這是何等的大需求? 需要費時 3-5 個月的時間及成本; 誰來負擔費用? 難怪 ERP 客戶大嘆吃不消, 而顧問公司也不賺錢 (台灣的 Oracle, SAP 的本土顧問公司已經倒的差不多了)。
以上的時間, 還不包括正式開始寫程式, 只是估算到: 確認要寫的程式規格而已。會這麼沒效率, 全是 "系統架構" 的問題: 一支一支程式撰寫, 而不是透過定義的方式產生, 當然耗費人力。不僅外包開發費用高, 連自行找人維護的成本也很驚人。
程式撰寫過程中的問題, 主要有:
使用者自認講的很清楚, 顧問說: 寫在文件的才算數;
程式設計師認為顧問說的, 跟客戶要的, 根本是二回事;
程式設計師認為是範圍外的要加錢, 使用者說: 早就講了;
程式比估價時, 複雜太多;
需求變更多, 要求減 A項, 加 B項;
再考慮到顧問、使用者以及系統設計師的人員異動, 則事情更趨複雜。
ERP 上線輔導 - 4. 差異分析
上階段結束後, 雙方應該都知道系統功能與使用者需求的差異 (GAP)。
一張長長的客製清單, 任誰看了都會昏倒。ERP 導入成敗關鍵在此: 專案管理。如何把 300 項的客製項目, 縮減為20項, 就是專案經理的能耐。大致的方向有:
要求防呆或操作習慣的先剔除;
簡化流程的排第二階段;
檢核或查詢的報表晚點再做;
管理分析的功能其次;
那些是該客製的項目?
作業單據: 如採購單, 領料單...;
沒有客製, 資料會不正確;
沒有客製, 資料不完整;
標準流程沒有的作業項目;
遵循這些原則, 上線才有機會。最後, 因為預算的問題, 再砍一刀。
一張長長的客製清單, 任誰看了都會昏倒。ERP 導入成敗關鍵在此: 專案管理。如何把 300 項的客製項目, 縮減為20項, 就是專案經理的能耐。大致的方向有:
要求防呆或操作習慣的先剔除;
簡化流程的排第二階段;
檢核或查詢的報表晚點再做;
管理分析的功能其次;
那些是該客製的項目?
作業單據: 如採購單, 領料單...;
沒有客製, 資料會不正確;
沒有客製, 資料不完整;
標準流程沒有的作業項目;
遵循這些原則, 上線才有機會。最後, 因為預算的問題, 再砍一刀。
2010年1月26日 星期二
ERP 上線輔導 - 3. 需求映對
順利的話, 教育訓練已讓使用者了解系統功能；需求訪談也讓顧問知道企業的作業流程。所以，這個階段就是要做作業流程與系統功能的設計。
蜜月期正式結束。
換了新系統的所有幻想, 講 "破滅" 並不過份。有使用者曾說:
以為這個系統可以自由定義畫面, 欄位;
作業流程無法彈性定義, 或要4, 5 個畫面才能完成一個作業;
什麼都是用 "雜收發", 還要求倉管人員打 "會計科目",
要求料號要分開, 或客戶要分開, 資料無限膨漲, 連張像樣的報表也沒有;
以 IC 設計業為例:
1. 外購已針測完成的 WAFER, PO 的單位為 "PCS", AP 也以 "PCS" 計價; 收料入庫為 "EA", 庫存記錄 Wafer 片數及 Good Die 數。Oracle 或 SAP 並沒有所謂的雙單位功能, 要如何處理?
2. 主要的業務流程: 外包封裝 (Assembly)、 測試 (Final Test)、包裝 (Tape & Reel), 為了帶出委外單價, 竟然要建立超過 10,000 個料號以及很複雜的作業, 才能開出一張委外加工單。
不全然是 Oracl, SAP 的責任; 在 IC 設計業蓬勃發展之前, 他們的產品就已經很成熟了, 根本就不是因為這樣的產業而設計, 只是沒在銷售時 "講清楚" 而已。
蜜月期正式結束。
換了新系統的所有幻想, 講 "破滅" 並不過份。有使用者曾說:
以為這個系統可以自由定義畫面, 欄位;
作業流程無法彈性定義, 或要4, 5 個畫面才能完成一個作業;
什麼都是用 "雜收發", 還要求倉管人員打 "會計科目",
要求料號要分開, 或客戶要分開, 資料無限膨漲, 連張像樣的報表也沒有;
以 IC 設計業為例:
1. 外購已針測完成的 WAFER, PO 的單位為 "PCS", AP 也以 "PCS" 計價; 收料入庫為 "EA", 庫存記錄 Wafer 片數及 Good Die 數。Oracle 或 SAP 並沒有所謂的雙單位功能, 要如何處理?
2. 主要的業務流程: 外包封裝 (Assembly)、 測試 (Final Test)、包裝 (Tape & Reel), 為了帶出委外單價, 竟然要建立超過 10,000 個料號以及很複雜的作業, 才能開出一張委外加工單。
不全然是 Oracl, SAP 的責任; 在 IC 設計業蓬勃發展之前, 他們的產品就已經很成熟了, 根本就不是因為這樣的產業而設計, 只是沒在銷售時 "講清楚" 而已。
ERP 上線輔導 - 2. 需求訪談
Phase 2. 需求訪談
如果教育訓練是讓使用者來了解 ERP 產品；那, 需求訪談, 就是讓顧問來了解使用者。顧問會與使用者確認流程: 先後順序、單據作業等。除了比較特別的行業或模組, 例如: IC 設計、營建業等, 流程與 ERP 的符合程度是很近似的。
這個階段的時間約二個月。使用者暢所欲言需求, 往往會偏重於現有系統無法滿足的功能, 誤以為新的 ERP 可以照所陳述的方式設計 ...；事實上, 除非有 MDA 架構的 ERP, 否則很難實現。
這階段, 苦惱的反而是顧問群。因為使用者對銷售階段的承諾還記憶鮮明，會再與顧問確認功能, 顧問已不能再隨意承諾；否則, 沒有的功能要如何提供給客戶?
如果教育訓練是讓使用者來了解 ERP 產品；那, 需求訪談, 就是讓顧問來了解使用者。顧問會與使用者確認流程: 先後順序、單據作業等。除了比較特別的行業或模組, 例如: IC 設計、營建業等, 流程與 ERP 的符合程度是很近似的。
這個階段的時間約二個月。使用者暢所欲言需求, 往往會偏重於現有系統無法滿足的功能, 誤以為新的 ERP 可以照所陳述的方式設計 ...；事實上, 除非有 MDA 架構的 ERP, 否則很難實現。
這階段, 苦惱的反而是顧問群。因為使用者對銷售階段的承諾還記憶鮮明，會再與顧問確認功能, 顧問已不能再隨意承諾；否則, 沒有的功能要如何提供給客戶?
ERP 上線輔導 - 1. 教育訓練
Phase 1 教育訓練
很可惜的, 使用者花了四個月以上的時間 Survey ERP, 除了看到一大堆的 Powerpoint 之外, 還獲得什麼? .....嗯, 我承認, 還有 Word 或 PDF.....以及一堆的承諾。
所以, 通常專案一開始, 是產品的教育訓練。在這時候, 才能真正的了解 "買到什麼"。
依產品模組多寡不同, 約一個月左右可以完成。包括系統功能說明及應用, 以及技術課程。
通常使用者的反應有幾種：
這階段的專案時程通常可以在控制之內。
很可惜的, 使用者花了四個月以上的時間 Survey ERP, 除了看到一大堆的 Powerpoint 之外, 還獲得什麼? .....嗯, 我承認, 還有 Word 或 PDF.....以及一堆的承諾。
所以, 通常專案一開始, 是產品的教育訓練。在這時候, 才能真正的了解 "買到什麼"。
依產品模組多寡不同, 約一個月左右可以完成。包括系統功能說明及應用, 以及技術課程。
通常使用者的反應有幾種：
- 好難好複雜的功能、設定, 連程式路徑都找不到...
- 講師講了很久, 好像一樣又不一樣, 要問又不知從何問起。...
- 跟我的作業無關的講一堆, 我問的問題卻沒回答...
- 不是要客製, 就是要回去查一查, 跟業務說的都不一樣, 到底可不可以? ...
這階段的專案時程通常可以在控制之內。
2010年1月24日 星期日
ERP 上線輔導
通常輔導費用要多少? 原廠或國外公司, 如 SAP, Oracle, Abeam等, 一般約 1000萬~2000萬之間, 國內 Partner, 通常在500萬-800萬之間；費用的差異, 主要在導入產品範圍、客戶的據點等因素。
上線輔導通常不外乎以下步驟：
1. 教育訓練 Training
2. 需求訪談 Requirement Taking
3. 功能映對 Business Requirement Mapping
4. 差異分析 GAP Analysis
5. 客製 Customization
6. 上線模擬測試 Conference Run Pilot
7. 上線 & 上線後支援: GO Live & Production Support
必需注意的是: 步驟 5. 客製, 不在上述的輔導費用內。
上線輔導通常不外乎以下步驟：
1. 教育訓練 Training
2. 需求訪談 Requirement Taking
3. 功能映對 Business Requirement Mapping
4. 差異分析 GAP Analysis
5. 客製 Customization
6. 上線模擬測試 Conference Run Pilot
7. 上線 & 上線後支援: GO Live & Production Support
必需注意的是: 步驟 5. 客製, 不在上述的輔導費用內。
2010年1月22日 星期五
套裝軟體 vs 專案開發
Adempiere 是套裝軟體還是專案開發工具?
SAP, Oracle ERP 套裝軟體的標準流程:
接單-> (轉工單生產) -> 出貨->立應收帳款
請購->採購->進貨->立應付帳款
工單->領退料->製程移轉->完工入庫
Adempiere 也是如此；如果可以符合, 則導 Adempiere, 算是套裝軟體; 若流程差異大, 如營建業: 報價核算, 工務管理, 工程外包, 成本估算等, 不管是 SAP, 還是 Oracle, 都是套用其 Framework 來100% 開發。但, Adempiere 是 MDA 架構, 可以定義 100% 的流程作業畫面; 若有特別的需求, 例如: 畫面上的 Button, 才需要額外的客製程式處理。
SAP, Oracle ERP 套裝軟體的標準流程:
接單-> (轉工單生產) -> 出貨->立應收帳款
請購->採購->進貨->立應付帳款
工單->領退料->製程移轉->完工入庫
Adempiere 也是如此；如果可以符合, 則導 Adempiere, 算是套裝軟體; 若流程差異大, 如營建業: 報價核算, 工務管理, 工程外包, 成本估算等, 不管是 SAP, 還是 Oracle, 都是套用其 Framework 來100% 開發。但, Adempiere 是 MDA 架構, 可以定義 100% 的流程作業畫面; 若有特別的需求, 例如: 畫面上的 Button, 才需要額外的客製程式處理。
2010年1月21日 星期四
MFG - Activity Control
工單領料及完工回報後, 這裡介紹 Activity 的成本收集。
Step 1, Activity Control Report, 將相關欄位輸入。倒是 Manufacturing Order Activity 沒設成必要欄位, 覺得比較奇怪。
Step 2, 完成後, Complete & Posted
Step 3, 以 System Admin 的身份登入, 一樣, 從 Window/ Tab/ Field Zoom 到 Table/ Column, 將 Manufacturing Order Activity 設為必要輸入。記得要 Logout/ Login; 這樣, 設定才會生效。
Step 1, Activity Control Report, 將相關欄位輸入。倒是 Manufacturing Order Activity 沒設成必要欄位, 覺得比較奇怪。
Step 2, 完成後, Complete & Posted
Step 3, 以 System Admin 的身份登入, 一樣, 從 Window/ Tab/ Field Zoom 到 Table/ Column, 將 Manufacturing Order Activity 設為必要輸入。記得要 Logout/ Login; 這樣, 設定才會生效。
將 mandatory 打勾
Step 4, 再看看結果。 Manufacturing Order Activity 已經變成必輸的紅色了。
這麼好的 Framework , 真是顧問的利器。
MFG - MO Receipt & Issue
Step 1, Order Receipt & Issue, 這支程式可以領料時, 順便回報完工數量。
Step 2, 執行 OK, .... 會出現 Update 以及 Close Document 的視窗, 要注意: 如果是分批, 這裡不能選 "Close"; 否則就無法再領料/完工了。
Step 3, 我喜歡在交易完成後, 檢查 Material Transaction 是否也有資料。
嗯, 放心了!
MFG - Manufacturing Order
OK, 有了 BOM & Workflow, 接下來就是開工單。
Step 1, Manufacturing Order, 我在這裡遇到了小小的困擾.... 為何 Resource/Plant 一直選不到? 我明明就有建立了。
Step 2, 我們來看看, 到底這個 Manufacturing Order 的 Resource 到底有何限制? 以 System Admin 的身份登入。找到 Manufacturing Order 的Window 定義。
Step 3, 同樣的, Zoom 到 Table 裡, 再找到Resource 的 Column, 發現有一 Dynamic Validation = "S_Resource Plant".
Step 4, 繼續 Zoom, 發現了這段 Validation Code, 按照這段的字義, 應該是指 Resource 必須為 "Manufacturing Resource" 以及 Resource Type = "PT" 才可以。
IsManufacturingResource='Y' AND ManufacturingResourceType='PT'
Step 5, 回頭看一下, Resource 的設定, 哦, 可以看到 Manufacturing Resouce 已勾選; PT? 應該是指 "Plant" 吧, 不放心的人, 可以再連 DB 去看。
Step 6, 果然, Re-Query 後, Resource 已經出現了。點選必要的欄位, 最後, 記得要 Complete.
Step 1, Manufacturing Order, 我在這裡遇到了小小的困擾.... 為何 Resource/Plant 一直選不到? 我明明就有建立了。
Step 2, 我們來看看, 到底這個 Manufacturing Order 的 Resource 到底有何限制? 以 System Admin 的身份登入。找到 Manufacturing Order 的Window 定義。
IsManufacturingResource='Y' AND ManufacturingResourceType='PT'
Step 5, 回頭看一下, Resource 的設定, 哦, 可以看到 Manufacturing Resouce 已勾選; PT? 應該是指 "Plant" 吧, 不放心的人, 可以再連 DB 去看。
Step 6, 果然, Re-Query 後, Resource 已經出現了。點選必要的欄位, 最後, 記得要 Complete.
2010年1月20日 星期三
MFG - Workflow
在 Adempiere 的生產途程, 是在 Workflow 定義。鼎新有 Workflow, Oracle 也有, LOTUS也有; 真是一個 Workflow, 各自表述。
Step 1, Manufacturing Workflow。注意: Start Note 是指這個 Workflow 的起始站, 這個很重要, 看來是有支援 Network Routing 的定義。要用的好就靠顧問的設計功力了。
Step 2, Activity, 就是一般所指的加工製程或站別
Step 3, Transition: 指Activity 的前後製程關係。也就是定義 Activity 的 FROM-TO 的關係; 定義後, 才是完整的 Routing。
Step 4, Product: 定義那些 Product 可以使用這個Workflow。
Step 5, Tools: 透過 ZOOM先建立Asset, .... 再廣告一聲: 有Zoom 真好用!!
Step 1, Manufacturing Workflow。注意: Start Note 是指這個 Workflow 的起始站, 這個很重要, 看來是有支援 Network Routing 的定義。要用的好就靠顧問的設計功力了。
Step 2, Activity, 就是一般所指的加工製程或站別
Step 3, Transition: 指Activity 的前後製程關係。也就是定義 Activity 的 FROM-TO 的關係; 定義後, 才是完整的 Routing。
Step 4, Product: 定義那些 Product 可以使用這個Workflow。
Step 5, Tools: 透過 ZOOM先建立Asset, .... 再廣告一聲: 有Zoom 真好用!!
MFG - BOM
這段時間, 一直不知要如何介紹 Adempiere 的製造系統。很明顯的, Adempiere Manufacturing Management 是比較弱的一環。最後, 還是決定依現行的 3.5.4a 的功能來介紹。如果有機會的話, 我們再來看 Janus ERP 如何加強不足。
Step 1. Bill of Material & Formula; 如果你有仔細看的話, 應該注意到: 這是 Adempiere 的 "難得" 的 Master-Detail 的畫面。只能建一版本。也就是說, 查不到不同時間的BOM 版本內容。
Step2. BOM -Line, 存檔。完成BOM 的建立作業。
Step 3, 這樣還不夠, 必須先去料號主檔, 完成 "Verify BOM", 屆時才開的出工單。
Step 1. Bill of Material & Formula; 如果你有仔細看的話, 應該注意到: 這是 Adempiere 的 "難得" 的 Master-Detail 的畫面。只能建一版本。也就是說, 查不到不同時間的BOM 版本內容。
Step2. BOM -Line, 存檔。完成BOM 的建立作業。
Step 3, 這樣還不夠, 必須先去料號主檔, 完成 "Verify BOM", 屆時才開的出工單。
2010年1月13日 星期三
ORACLE ERP 的前世今生 (10) End
五、結束語
十年前，春風得意的拉裏·埃裏森面對滿座高朋躊躇滿志地宣示："5年之後，世界應用軟體市場的對手，將只剩下SAP和我們，或者，我們和SAP"。果然，隨著那些風光一時的明星企業一個個倒下或被吞併，埃裏森實現了自己的預言。由於高端管理軟體產品"不懼盜版，甚至歡迎盜版"的特殊性，管理軟體"一家獨大"或"兩強爭霸"的局面，長遠來看絕非市場之福、客戶之福。想想前兩年SAP/ORACLE突然相繼單方面將年服務費率提高5個百分點時用戶的無奈吧！
無論是從經濟學的市場充分競爭原理還是從中國人固有的認識哲學角度來看，理論上，管理軟體業界未來還有可能再出現一個世界級的巨頭（但願不是微軟）。管理軟體"三足鼎立"是市場的期望，也是我們的願望，而其中"一足"能是國內本土企業則更是我們的夢想。
最近一段時間，國內業界有人耐不住寂寞，煽風點火，蓄意把SAP架在火上烤，一時間弄得烏煙瘴氣。聯想到前些時SAP有人說了句大實話"國內企業落後SAP二十年"所引發的軒然大波，實在是可悲可歎。回頭再看看ORACLE，儘管口無遮攔的埃裏森，一會是要開著戰鬥機去微軟總部扔炸彈，一會又是要去踢IBM的屁股，但ORACLE至少在幾年之前還是在表面上對SAP表現得很是尊敬。能讓埃裏森親口承認自己是學生，就是明證。只不過是在最近幾年，隨著11i的成功，ORACLE覺得自己的產品已經足夠強大，才公開喊出"OFF SAP"的口號。其實，面對國際巨頭，承認自己的落後並不是什麼丟人的事情，真不明白國內業界何以風氣如此！
與印度人相比，我們是世界工廠，有著數量龐大的工業企業供軟體產品做實踐；與美國人相比，我們有質優價廉、數量豐沛且吃苦耐勞的軟體發展人員可供驅使；與德國人相比，我們甚至可以嘲笑他們的ABAP技 術過時、平臺落後。我們的應用軟體產業與那些國外公司相比，起步並不算晚，但二十年的時光悠悠過去，當中國的家電產業從無到有，已能夠與歐美日韓並駕齊 驅，當中國的通信產業出身草根，正逼得那些百年老店、跨國巨頭走投無路的時候，何以中國的應用軟體產業還只能是在貧瘠的低端市場廣種薄收、收穫與付出不成 比例？難道真的如有些人認為的那樣，是因為國內企業的管理水準普遍偏低？這種說法和"我們造不出好車，是因為國內路況不好"一樣，實在難以令人信服。看 來，國內管理軟體業界已經到了必須集體反思的時候。
二十年前，身影憔悴的任正非面對著一幫灰頭土臉的部下喃喃夢囈："二十年後，世界電信市場三分天下，華為必將有其一"。今天夢想成為現實，2008年華為以180多億美金的營收，成為繼愛立信、諾西（諾基亞、西門子合併後的公司）之後的世界電信三甲之一。
碼字到這裏，突然想起篇首"一個偉大的公司必有一個偉大的產品"這句話，第一次看到原是出自"何經華"，這位曾花了近10年時間在國內管理軟體界轉了一圈的臺灣人剛剛涉足國內業界不久時的一篇講演稿。當去年底何先生從國內業界二次轉身、黯然離去的時候，有多少人是否還記得他這句現在已經說不清是包含"希望"還是"失望"的話：
一個偉大的公司必有一個偉大的產品！
十年前，春風得意的拉裏·埃裏森面對滿座高朋躊躇滿志地宣示："5年之後，世界應用軟體市場的對手，將只剩下SAP和我們，或者，我們和SAP"。果然，隨著那些風光一時的明星企業一個個倒下或被吞併，埃裏森實現了自己的預言。由於高端管理軟體產品"不懼盜版，甚至歡迎盜版"的特殊性，管理軟體"一家獨大"或"兩強爭霸"的局面，長遠來看絕非市場之福、客戶之福。想想前兩年SAP/ORACLE突然相繼單方面將年服務費率提高5個百分點時用戶的無奈吧！
無論是從經濟學的市場充分競爭原理還是從中國人固有的認識哲學角度來看，理論上，管理軟體業界未來還有可能再出現一個世界級的巨頭（但願不是微軟）。管理軟體"三足鼎立"是市場的期望，也是我們的願望，而其中"一足"能是國內本土企業則更是我們的夢想。
最近一段時間，國內業界有人耐不住寂寞，煽風點火，蓄意把SAP架在火上烤，一時間弄得烏煙瘴氣。聯想到前些時SAP有人說了句大實話"國內企業落後SAP二十年"所引發的軒然大波，實在是可悲可歎。回頭再看看ORACLE，儘管口無遮攔的埃裏森，一會是要開著戰鬥機去微軟總部扔炸彈，一會又是要去踢IBM的屁股，但ORACLE至少在幾年之前還是在表面上對SAP表現得很是尊敬。能讓埃裏森親口承認自己是學生，就是明證。只不過是在最近幾年，隨著11i的成功，ORACLE覺得自己的產品已經足夠強大，才公開喊出"OFF SAP"的口號。其實，面對國際巨頭，承認自己的落後並不是什麼丟人的事情，真不明白國內業界何以風氣如此！
與印度人相比，我們是世界工廠，有著數量龐大的工業企業供軟體產品做實踐；與美國人相比，我們有質優價廉、數量豐沛且吃苦耐勞的軟體發展人員可供驅使；與德國人相比，我們甚至可以嘲笑他們的ABAP技 術過時、平臺落後。我們的應用軟體產業與那些國外公司相比，起步並不算晚，但二十年的時光悠悠過去，當中國的家電產業從無到有，已能夠與歐美日韓並駕齊 驅，當中國的通信產業出身草根，正逼得那些百年老店、跨國巨頭走投無路的時候，何以中國的應用軟體產業還只能是在貧瘠的低端市場廣種薄收、收穫與付出不成 比例？難道真的如有些人認為的那樣，是因為國內企業的管理水準普遍偏低？這種說法和"我們造不出好車，是因為國內路況不好"一樣，實在難以令人信服。看 來，國內管理軟體業界已經到了必須集體反思的時候。
二十年前，身影憔悴的任正非面對著一幫灰頭土臉的部下喃喃夢囈："二十年後，世界電信市場三分天下，華為必將有其一"。今天夢想成為現實，2008年華為以180多億美金的營收，成為繼愛立信、諾西（諾基亞、西門子合併後的公司）之後的世界電信三甲之一。
碼字到這裏，突然想起篇首"一個偉大的公司必有一個偉大的產品"這句話，第一次看到原是出自"何經華"，這位曾花了近10年時間在國內管理軟體界轉了一圈的臺灣人剛剛涉足國內業界不久時的一篇講演稿。當去年底何先生從國內業界二次轉身、黯然離去的時候，有多少人是否還記得他這句現在已經說不清是包含"希望"還是"失望"的話：
一個偉大的公司必有一個偉大的產品！
ORACLE ERP 的前世今生 (9)
埃裏森是天生的領袖、天才的企業家，但他絕不是一個優秀的企業管理者，這從他曾輕率地任命一個產品開發主管兼任上市公司的CFO就可見一斑。當然，埃裏森也無意把自己打造成一個所謂的"企業管理專家"。與SAP自詡自己是"管理大師"不同，ORACLE則簡單地把自己說成是一個"資訊公司"（Information Company）。或許正是埃裏森（還有羅恩·沃爾）在這方面有自知之明，在ORACLE的產品開發團隊內部，有一個很小範圍的由核心專家所組成的執行委員會。面對來自內部（銷售、實施）、外部（客戶、夥伴）的種種壓力，埃裏森以一種近乎"孩子氣"的簡單與固執，只相信並依賴他那個"核心小組"。為此，他不惜和那些高層反對者鬧翻，並把他們一個個逐出公司。
網上的ERP論壇中常有"新人"問：SAP與ORACLE孰優孰劣，我該學哪一個？多年以來，關於SAP/ORACLE高下對比的"口水仗"就重來沒有停止過。2004年，ORACLE自己曾發表一個白皮書：ORACLE與SAP對比——是什麼使ORACLE脫穎而出？（有人乾脆將之譯成"為什麼ORACLE比SAP強"），有興趣者可以找來看看。其中有一句："SAP的表格驅動的方法已經過時，並且很難掌握"，倒是很值得認真仔細研究。SAP是ERP的鼻祖，包括ORACLE在內，大家都在學它。但回顧過去十幾年國內廠商的學習成績，令人唏噓，恐怕問題的根源正如ORACLE所說。
有一種說法：SAP求嚴求全，ORACLE求實求用，前者體現德國人的做事風格，後者體現美國人的做事風格。論者立場比較公允，切中肯綮。但是，國內另一種說法：SAP體現的是德國管理模式，ORACLE體現的是美國管理模式，國產ERP體現的是中國管理模式。則似乎就有誤導之嫌了。
管理是什麼？是科學與藝術的結合。"科學"屬於自然屬性範疇，"藝術"屬於人文屬性範疇。ERP所針對的對象、所要解決的問題，主要是企業管理中屬於自然屬性範疇的"科學"那部分。而科學無國界。一個能夠同時為成千上萬家企業所使用、高度集成的ERP產品必須同時考慮眾多的"約束條件"，數學原理告訴我們：約束條件越多，可能的最優解越少。套用托爾斯泰的一句名言：成功的產品比比相似，不成功的產品各有其不幸。
縱觀從SAP到ORACLE的歷史風雲，還應當指出的是：SAP早年曾將ORACLE的產品蔑視為中低端產品，而ORACLE董事會有人在花了50萬美金的調研後，也曾提出過"放棄高端，從中低端圍堵SAP"的建議，但被埃裏森斷然否決。德國人的傲慢、美國人的堅持成就了今日ORACLE應用產品的市場地位。再翻翻其他公司或產品的歷史，迄今似乎還沒有誰能夠實現由低端向高端"仰攻"而取得成功的先例。強大如微軟也不能例外。這一點頗值得業內人士進一步做深入研究。
網上的ERP論壇中常有"新人"問：SAP與ORACLE孰優孰劣，我該學哪一個？多年以來，關於SAP/ORACLE高下對比的"口水仗"就重來沒有停止過。2004年，ORACLE自己曾發表一個白皮書：ORACLE與SAP對比——是什麼使ORACLE脫穎而出？（有人乾脆將之譯成"為什麼ORACLE比SAP強"），有興趣者可以找來看看。其中有一句："SAP的表格驅動的方法已經過時，並且很難掌握"，倒是很值得認真仔細研究。SAP是ERP的鼻祖，包括ORACLE在內，大家都在學它。但回顧過去十幾年國內廠商的學習成績，令人唏噓，恐怕問題的根源正如ORACLE所說。
有一種說法：SAP求嚴求全，ORACLE求實求用，前者體現德國人的做事風格，後者體現美國人的做事風格。論者立場比較公允，切中肯綮。但是，國內另一種說法：SAP體現的是德國管理模式，ORACLE體現的是美國管理模式，國產ERP體現的是中國管理模式。則似乎就有誤導之嫌了。
管理是什麼？是科學與藝術的結合。"科學"屬於自然屬性範疇，"藝術"屬於人文屬性範疇。ERP所針對的對象、所要解決的問題，主要是企業管理中屬於自然屬性範疇的"科學"那部分。而科學無國界。一個能夠同時為成千上萬家企業所使用、高度集成的ERP產品必須同時考慮眾多的"約束條件"，數學原理告訴我們：約束條件越多，可能的最優解越少。套用托爾斯泰的一句名言：成功的產品比比相似，不成功的產品各有其不幸。
縱觀從SAP到ORACLE的歷史風雲，還應當指出的是：SAP早年曾將ORACLE的產品蔑視為中低端產品，而ORACLE董事會有人在花了50萬美金的調研後，也曾提出過"放棄高端，從中低端圍堵SAP"的建議，但被埃裏森斷然否決。德國人的傲慢、美國人的堅持成就了今日ORACLE應用產品的市場地位。再翻翻其他公司或產品的歷史，迄今似乎還沒有誰能夠實現由低端向高端"仰攻"而取得成功的先例。強大如微軟也不能例外。這一點頗值得業內人士進一步做深入研究。
ORACLE ERP 的前世今生 (8)
四、從SAP到ORACLE
截至2008年，ORACLE年營收為224億美金，而SAP年營收為161億美金。年人均創收ORACLE為26萬美金，SAP則為31萬美金。相比之下，國內的用友年營收2.5億美金，人均創收僅3.6萬美金，金蝶年營收1.25億美金，人均創收僅3.1萬美金，差距十分明顯。
由於ORACLE的產品銷售，應用產品與資料庫是綁在一起的，從ORACLE的年報中根本看不出各自是多少。而ORACLE似乎也有意回避做明確的劃分，因此，考慮到現如今應用產品（ERP）在ORACLE產品家族中的核心地位，大約以50%的比例來計量（110億美金），應當還算靠譜。這樣看來，就應用產品的市場份額而言，ORACLE大約是SAP的三分之二。SAP是無可爭議的老大，ORACLE是無可爭議的老二。兩者合計占應用產品全球市場總體的份額，按某些調查機構的資料約為60%（35%+25%）。至於市場上林林種種的其他產品，則就是"餘子紛紛不足數"了。
由於SAP/ORACLE的產品主要靠合作夥伴、諮詢機構來實施服務，一般認為，圍繞它們所衍生的市場價值鏈有三到五倍，因此，可以說這是一個由SAP/ORACLE所創造的千億美金規模的大市場。而國內應用軟體市場的總價值，按某些調查機構的資料，當前約為100億人民幣左右。發達國家企業資訊化市場的飽和度近70%，而國內市場的飽和度不足20%，隨著中國經濟的快速發展，電子商務與企業資訊化水準的提高，未來幾年出現一個千億人民幣規模的大市場指日可待。這對於國內應用軟體廠商們來說，無疑既是一個巨大的機會，也是一個艱巨的挑戰。
那麼，從ORACLE應用產品過往十幾年迂回曲折又波瀾壯闊的發展歷程中，國內廠商能獲得一些怎樣的有益啟發呢？概而言之，ORACLE 產品研發的經驗有以下兩個重要方面：
其一是產品開發策略的"目標明確"。以SAP為標杆、為榜樣，承認差距，奮起直追，結合技術發展的最新成果，爭取"青出於藍而勝於藍"。SAP一向喜歡標榜自己的產品"包含有豐富的管理思想，凝聚了各大成功企業寶貴的管理經驗，有著30多年的深厚積累"。那麼，以SAP為師，跟著SAP走，大方向總不會錯的。
最近有人在談到R12中的新東西"子分類帳"（Subledger）時，曾調侃說"能看到SAP的影子"。其實，如果對ORACLE與SAP的產品做一些比較深入的對比研究分析就會發現，儘管兩個產品外表長相、操作習慣差別甚大，但其核心的業務流程、應用架構相似度還是很高的，許多地方不過是名詞概念的的改頭換面而已。反觀國內不少廠商的產品，雖然也聲稱在學，但核心、本質的東西往往弄得南轅北轍。
其二是開發管理策略的"過程堅定"。這裏的"堅定"，不是說要象埃裏森那樣固執到去罵別人是"傻瓜"。然而，一個設計精良、高度集成的ERP產 品，是電腦技術與企業業務實踐的完美結合，它是如此龐大而複雜，以致於它絕對不是一般的"無知"用戶，在工廠走馬觀花的程式師，或者讀過幾本管理書籍的 諮詢實施人員就能輕易理解與掌握的。產品研發、實施、發展過程中，七嘴八舌、眾說紛紜，甚至各執一詞、矛盾衝突都是在所難免，面對內外交困的局面，如果沒 有"堅定"的意志堅持，最終必然是弄出一個"四不像"的大雜燴。
截至2008年，ORACLE年營收為224億美金，而SAP年營收為161億美金。年人均創收ORACLE為26萬美金，SAP則為31萬美金。相比之下，國內的用友年營收2.5億美金，人均創收僅3.6萬美金，金蝶年營收1.25億美金，人均創收僅3.1萬美金，差距十分明顯。
由於ORACLE的產品銷售，應用產品與資料庫是綁在一起的，從ORACLE的年報中根本看不出各自是多少。而ORACLE似乎也有意回避做明確的劃分，因此，考慮到現如今應用產品（ERP）在ORACLE產品家族中的核心地位，大約以50%的比例來計量（110億美金），應當還算靠譜。這樣看來，就應用產品的市場份額而言，ORACLE大約是SAP的三分之二。SAP是無可爭議的老大，ORACLE是無可爭議的老二。兩者合計占應用產品全球市場總體的份額，按某些調查機構的資料約為60%（35%+25%）。至於市場上林林種種的其他產品，則就是"餘子紛紛不足數"了。
由於SAP/ORACLE的產品主要靠合作夥伴、諮詢機構來實施服務，一般認為，圍繞它們所衍生的市場價值鏈有三到五倍，因此，可以說這是一個由SAP/ORACLE所創造的千億美金規模的大市場。而國內應用軟體市場的總價值，按某些調查機構的資料，當前約為100億人民幣左右。發達國家企業資訊化市場的飽和度近70%，而國內市場的飽和度不足20%，隨著中國經濟的快速發展，電子商務與企業資訊化水準的提高，未來幾年出現一個千億人民幣規模的大市場指日可待。這對於國內應用軟體廠商們來說，無疑既是一個巨大的機會，也是一個艱巨的挑戰。
那麼，從ORACLE應用產品過往十幾年迂回曲折又波瀾壯闊的發展歷程中，國內廠商能獲得一些怎樣的有益啟發呢？概而言之，ORACLE 產品研發的經驗有以下兩個重要方面：
其一是產品開發策略的"目標明確"。以SAP為標杆、為榜樣，承認差距，奮起直追，結合技術發展的最新成果，爭取"青出於藍而勝於藍"。SAP一向喜歡標榜自己的產品"包含有豐富的管理思想，凝聚了各大成功企業寶貴的管理經驗，有著30多年的深厚積累"。那麼，以SAP為師，跟著SAP走，大方向總不會錯的。
最近有人在談到R12中的新東西"子分類帳"（Subledger）時，曾調侃說"能看到SAP的影子"。其實，如果對ORACLE與SAP的產品做一些比較深入的對比研究分析就會發現，儘管兩個產品外表長相、操作習慣差別甚大，但其核心的業務流程、應用架構相似度還是很高的，許多地方不過是名詞概念的的改頭換面而已。反觀國內不少廠商的產品，雖然也聲稱在學，但核心、本質的東西往往弄得南轅北轍。
其二是開發管理策略的"過程堅定"。這裏的"堅定"，不是說要象埃裏森那樣固執到去罵別人是"傻瓜"。然而，一個設計精良、高度集成的ERP產 品，是電腦技術與企業業務實踐的完美結合，它是如此龐大而複雜，以致於它絕對不是一般的"無知"用戶，在工廠走馬觀花的程式師，或者讀過幾本管理書籍的 諮詢實施人員就能輕易理解與掌握的。產品研發、實施、發展過程中，七嘴八舌、眾說紛紜，甚至各執一詞、矛盾衝突都是在所難免，面對內外交困的局面，如果沒 有"堅定"的意志堅持，最終必然是弄出一個"四不像"的大雜燴。
ORACLE ERP 的前世今生 (7)
三、2000年-2009年：引領風騷，徵購無極限
2000年5月，歷經3年潛心研發，ORACLE 11i 電子商務套件（EBS）正式發佈。該產品有兩大宣傳賣點：一是完全的B/S架構，二是互聯網應用。關於所謂B/S架構，今天已幾乎成為行業技術標準，沒什麼好說的。而所謂"互聯網應用"，即ORACLE刻意強調的那個"i"（internet的意思），則很大部分是為了迎合當時的互聯網泡沫氾濫的時代潮流。
11i 中的那個"i"的影響之深、之廣，以至於今天的ORACLE R12 出來後，有人還習慣性地將它稱之為"12i"。但實際上從企業實際業務的核心應用角度來講，這個"i"（互聯網應用）在當時象徵意義大於實際意義。在今天企業互聯網應用已逐步深入，遠非昔日可比的時候，R12的出臺卻拋棄了這個"i"，這或許可以說明，ORACLE會玩概念，是玩概念的高手，但ORACLE從未將"玩概念"當成自家產品的"立身之本"。
2001年，財富100家中已經有65家在運行11i EBS，ORACLE搶得了市場先機。相對而言，面對互聯網所帶來的巨大改變，SAP則顯得有些反應遲鈍，業界評論家們甚至認為SAP落後了。儘管SAP在1999年10月就開始推出其新一代基於網路的企業套件mySAP.com，但多年之後，SAP不得不無奈地承認：許多人弄不明白mySAP.com是什麼東西。
伴隨著11i的 成功，客戶群的擴大，來自客戶的抱怨與不滿也在增多。應用軟體的早期版本不夠成熟，總是存在這樣那樣的問題，這本來是一個業界所普遍存在的正常現象，但所 謂"期望越高，失望越大"，客戶開始抱怨"產品並沒有埃裏森吹噓的那麼好"。加之埃裏森不介意得罪同行、得罪媒體、得罪合作夥伴，甚至得罪客戶的獨特的行 事風格，也給自己招來了許多麻煩。
過去若干年來，爭議詆毀、嫉妒中傷、幸災樂禍幾乎與ORACLE的發展如影隨形。諮詢機構AMR調查公司在自己的報告中就曾宣稱"用最好聽的辭彙描述，ORACLE應用軟體的歷史也是充滿波折。這家公司有一個傳統：將軟體賣給早期的買家，依靠它們灑下的鮮血、汗水、淚水去填補產品的漏洞，使之變得可靠"。然而，儘管如此，有趣的是，大多數客戶還是相信ORACLE能最終解決存在的問題，雖然抱怨不滿、大聲抗議，但卻一次又一次地願意給予ORACLE機會。這或許從另一個側面反映了ORACLE ERP產品所具有的強大生命力。
2002年5月，軟體巨人微軟公司在繼一年多前以11億美金收購一家美國本土中型財務軟體公司後，又以13億美金收購歐洲小型企業應用軟體供應商Navision，希圖在據說整體規模有千億美金之巨的企業應用軟體市場分一杯羹。有媒體甚至報導說"微軟收購歐洲ERP公司目標直指SAP"。Navision目前在國內有一定市場，據說曾讓用友、金蝶十分不安。該產品小巧玲瓏但五臟俱全，居然不用install就可以直接使用（感趣者可以找來試試）。但要用這樣一個類似"玩具"一般的產品挑戰SAP/ORACLE，則恐怕是媒體的捕風捉影、誇大其詞。
2003年，ORACLE推出EBS的特別版（special edition），僅包含FI、INV、PO、OM，產品形態與策略和SAP的A1類似。也就在這一年，ORACLE在與Peoplesoft爭搶JDE的過程中，演出了一場"螳螂捕蟬，黃雀在後"的好戲，最終在2004年以103億美金的代價將Peoplesoft和JDE一起納入囊中。至此，ORACLE與SAP在ERP市場的整體份額差距進一步縮小，因為Peoplesoft與JDE當時位列世界第三、第四。儘管當時有很多人懷疑ORACLE會消化不良、自食其果，但時間已經表明，ORACLE笑到了最後。
2004年，ORACLE 推出On Demand Business服務，該項業務實際上也就是三年之後忽然在國內變得異常火爆的所謂SaaS。近年來，SaaS即"軟體即服務"的概念在國內被炒到了近乎"神話"的地步，一時間國內ERP廠商們爭先恐後，仿佛它就是"救星"，真不知道這是福還是禍。
2005年，ORACLE以58.5億美金的代價並購Sieble。Sieble最著名的產品是CRM，該產品追根究源，可以追溯到ORACLE早年在其內部使用的一個"電話銷售管理系統"。葉落歸根，Sieble的歷史仿佛轉了一個圈，又回到了起點。
2006年，ORACLE 發佈"應用無極限"的產品戰略，發誓要將收購來的一堆產品（JDE/Peoplesoft/Sieble等）與自家產品"熔合"到一起。姑妄言之，姑妄信之。對於過去使用這些產品或依靠這些產品謀生的公司與個人來說，似乎還是應當未雨綢繆，早做準備。
2007年，ORACLE正式發佈EBS R12。此時的EBS已經包含有高度集成的300多個模組，幾乎覆蓋了製造業、商業、金融、服務、政府、公用事業等等各行各業的全部應用。過去曾看到ORACLE的一個說法：R12將是EBS的最後一個版本。不知道ORACLR葫蘆裏賣的是什麼藥？同年，ORACLE以33億美金的代價收購知名的績效管理軟體Hyperion，以近5億美金代價收購知名的產品生命週期管理軟體Agile。
2008年，ORACLE 提供Sieble CRM On Demand 服務。同年，ORACLE以85億美金的代價收購中間件廠商BEA。
2009年，ORACLE 宣佈提供Sourcing on demand 的合作夥伴計畫，以自己的獨特方式再次介入正熱火朝天的SAAS市場（但筆者看來，此舉似乎有點攪局的意味）。隨後，ORACLE宣佈以74億美金收購SUN，業界再次被震撼。曾有個一問一答的笑話。問：上帝與埃裏森有何不同？答：上帝不認為他是埃裏森。如果ORACLE收購SUN成功，從作業系統、資料庫到中間件、應用軟體，從底層到上層，從硬體到軟體，ORACLE全包，埃裏森一統江湖，看來真要成上帝了！
因為埃裏森被看作是收購狂人，於是有不少人似乎認為ORACLE的應用產品之所以強大，是靠收購得來的。國內有些ERP廠商也想效仿、走捷徑。但實際上這其實是一種誤解。從產品規劃設計、企業實際應用角度來看，收購只可能錦上添花，不可能是雪中送炭！然個中就裏，涉及對產品應用架構的複雜分析，實非三言兩語所能說清。
2000年5月，歷經3年潛心研發，ORACLE 11i 電子商務套件（EBS）正式發佈。該產品有兩大宣傳賣點：一是完全的B/S架構，二是互聯網應用。關於所謂B/S架構，今天已幾乎成為行業技術標準，沒什麼好說的。而所謂"互聯網應用"，即ORACLE刻意強調的那個"i"（internet的意思），則很大部分是為了迎合當時的互聯網泡沫氾濫的時代潮流。
11i 中的那個"i"的影響之深、之廣，以至於今天的ORACLE R12 出來後，有人還習慣性地將它稱之為"12i"。但實際上從企業實際業務的核心應用角度來講，這個"i"（互聯網應用）在當時象徵意義大於實際意義。在今天企業互聯網應用已逐步深入，遠非昔日可比的時候，R12的出臺卻拋棄了這個"i"，這或許可以說明，ORACLE會玩概念，是玩概念的高手，但ORACLE從未將"玩概念"當成自家產品的"立身之本"。
2001年，財富100家中已經有65家在運行11i EBS，ORACLE搶得了市場先機。相對而言，面對互聯網所帶來的巨大改變，SAP則顯得有些反應遲鈍，業界評論家們甚至認為SAP落後了。儘管SAP在1999年10月就開始推出其新一代基於網路的企業套件mySAP.com，但多年之後，SAP不得不無奈地承認：許多人弄不明白mySAP.com是什麼東西。
伴隨著11i的 成功，客戶群的擴大，來自客戶的抱怨與不滿也在增多。應用軟體的早期版本不夠成熟，總是存在這樣那樣的問題，這本來是一個業界所普遍存在的正常現象，但所 謂"期望越高，失望越大"，客戶開始抱怨"產品並沒有埃裏森吹噓的那麼好"。加之埃裏森不介意得罪同行、得罪媒體、得罪合作夥伴，甚至得罪客戶的獨特的行 事風格，也給自己招來了許多麻煩。
過去若干年來，爭議詆毀、嫉妒中傷、幸災樂禍幾乎與ORACLE的發展如影隨形。諮詢機構AMR調查公司在自己的報告中就曾宣稱"用最好聽的辭彙描述，ORACLE應用軟體的歷史也是充滿波折。這家公司有一個傳統：將軟體賣給早期的買家，依靠它們灑下的鮮血、汗水、淚水去填補產品的漏洞，使之變得可靠"。然而，儘管如此，有趣的是，大多數客戶還是相信ORACLE能最終解決存在的問題，雖然抱怨不滿、大聲抗議，但卻一次又一次地願意給予ORACLE機會。這或許從另一個側面反映了ORACLE ERP產品所具有的強大生命力。
2002年5月，軟體巨人微軟公司在繼一年多前以11億美金收購一家美國本土中型財務軟體公司後，又以13億美金收購歐洲小型企業應用軟體供應商Navision，希圖在據說整體規模有千億美金之巨的企業應用軟體市場分一杯羹。有媒體甚至報導說"微軟收購歐洲ERP公司目標直指SAP"。Navision目前在國內有一定市場，據說曾讓用友、金蝶十分不安。該產品小巧玲瓏但五臟俱全，居然不用install就可以直接使用（感趣者可以找來試試）。但要用這樣一個類似"玩具"一般的產品挑戰SAP/ORACLE，則恐怕是媒體的捕風捉影、誇大其詞。
2003年，ORACLE推出EBS的特別版（special edition），僅包含FI、INV、PO、OM，產品形態與策略和SAP的A1類似。也就在這一年，ORACLE在與Peoplesoft爭搶JDE的過程中，演出了一場"螳螂捕蟬，黃雀在後"的好戲，最終在2004年以103億美金的代價將Peoplesoft和JDE一起納入囊中。至此，ORACLE與SAP在ERP市場的整體份額差距進一步縮小，因為Peoplesoft與JDE當時位列世界第三、第四。儘管當時有很多人懷疑ORACLE會消化不良、自食其果，但時間已經表明，ORACLE笑到了最後。
2004年，ORACLE 推出On Demand Business服務，該項業務實際上也就是三年之後忽然在國內變得異常火爆的所謂SaaS。近年來，SaaS即"軟體即服務"的概念在國內被炒到了近乎"神話"的地步，一時間國內ERP廠商們爭先恐後，仿佛它就是"救星"，真不知道這是福還是禍。
2005年，ORACLE以58.5億美金的代價並購Sieble。Sieble最著名的產品是CRM，該產品追根究源，可以追溯到ORACLE早年在其內部使用的一個"電話銷售管理系統"。葉落歸根，Sieble的歷史仿佛轉了一個圈，又回到了起點。
2006年，ORACLE 發佈"應用無極限"的產品戰略，發誓要將收購來的一堆產品（JDE/Peoplesoft/Sieble等）與自家產品"熔合"到一起。姑妄言之，姑妄信之。對於過去使用這些產品或依靠這些產品謀生的公司與個人來說，似乎還是應當未雨綢繆，早做準備。
2007年，ORACLE正式發佈EBS R12。此時的EBS已經包含有高度集成的300多個模組，幾乎覆蓋了製造業、商業、金融、服務、政府、公用事業等等各行各業的全部應用。過去曾看到ORACLE的一個說法：R12將是EBS的最後一個版本。不知道ORACLR葫蘆裏賣的是什麼藥？同年，ORACLE以33億美金的代價收購知名的績效管理軟體Hyperion，以近5億美金代價收購知名的產品生命週期管理軟體Agile。
2008年，ORACLE 提供Sieble CRM On Demand 服務。同年，ORACLE以85億美金的代價收購中間件廠商BEA。
2009年，ORACLE 宣佈提供Sourcing on demand 的合作夥伴計畫，以自己的獨特方式再次介入正熱火朝天的SAAS市場（但筆者看來，此舉似乎有點攪局的意味）。隨後，ORACLE宣佈以74億美金收購SUN，業界再次被震撼。曾有個一問一答的笑話。問：上帝與埃裏森有何不同？答：上帝不認為他是埃裏森。如果ORACLE收購SUN成功，從作業系統、資料庫到中間件、應用軟體，從底層到上層，從硬體到軟體，ORACLE全包，埃裏森一統江湖，看來真要成上帝了！
因為埃裏森被看作是收購狂人，於是有不少人似乎認為ORACLE的應用產品之所以強大，是靠收購得來的。國內有些ERP廠商也想效仿、走捷徑。但實際上這其實是一種誤解。從產品規劃設計、企業實際應用角度來看，收購只可能錦上添花，不可能是雪中送炭！然個中就裏，涉及對產品應用架構的複雜分析，實非三言兩語所能說清。
ORACLE ERP 的前世今生 (6)
歷史的發展軌跡常常是詭異的，勝利者或許是不該受責備的。以今天的眼光回頭來看，埃裏森的一意孤行，對於ORACLE ERP產品的未來發展，又很難說是"負面"的。有一位元ORACLE的 長期客戶、後來成為諮詢公司負責人的馬克·法納姆就堅持認為：羅恩·沃爾不對應用軟體發展限定日期的做法是正確的。應用軟體非常複雜，在一個地方做改動就 可能影響另一功能。銷售人員想要產品有更多功能、能夠及時出來，那樣他們就可以有更多收入。但對於應用軟體用戶來說，晚半年拿到產品，拿到能正常運轉、更 穩定的產品，也許更有利，即使這意味著有些功能暫時不到位、產品交付錯過日期。
但客戶由於產品功能、品質方面所遭受的痛苦與挫敗感也是實實在在的。以國內最早的ORACLE ERP 用戶"華為"為例，最初使用的頭兩年，情況是是相當可怖的。莫名其妙的錯誤、無緣無故的宕機、沒完沒了的補丁，以及用戶忽然間進不去、出不來等等一系列問題，導致公司上下怨聲載道，IT部門承受著沉重的壓力，以至於最終導致負責IT工程選型與實施的一位創業元老、公司副總裁，在被老闆罵得狗血噴頭後怏怏地黯然離去。
1997年底，圍繞應用軟體業務在ORACLE公司高層之間所引發的政治鬥爭已經到了"白日化"的地步，鑒於應用軟體在市場上的糟糕表現，董事會有人跳出來公開建議：ORACLE要 麼收購一家競爭對手以壯大應用軟體業務，要麼乾脆將這方面業務全部賣掉。這當然引起了來自開發團隊的無比憤怒。以公司總裁雷·萊恩為首的運營團隊則公開指 責羅恩·沃爾無能，在大庭廣眾之下說應用軟體根本是個敗筆，並向埃裏森"逼宮"：要麼讓羅恩·沃爾出局，另換他人，要麼我們就辭職。
鬥爭的最後結果以埃裏森將公司總裁雷·萊恩及其他反對者通通逐出公司為收場。埃裏森從此開始關心並親自掌管起應用軟體的開發工作，並敏銳地提出了"應用產品轉向B/S架 構、全面實現互聯網應用"的創新設想。應當說，以羅恩·沃爾為首的開發團隊並沒有辜負老闆的"知遇之恩"，產品開發與完善進度明顯加快，產品的市場表現開 始逐步變得亮麗。多年以後，對於羅恩·沃爾曾經受到的攻擊與屈辱，埃裏森還在替他打抱不平："雷稱羅恩為笑料，這不僅與事實不符，而且說的是外行話，有失 公允。羅恩建造的應用軟體管理著全球近1.5萬家公司，僅次於SAP"。
1998年，ORACLE應用產品R11 套件面世。到98年4月，已經有大約1300個客戶。到98年10月，ORACLE 發佈CRM3.0，並實現ERP與CRM產品的高度集成。也是在這年，ORACLE ERP 的線上商務應用（business On line）與移動商務應用（Mobile APPS）得以成功實現。這兩款應用亦即多年後國內有人熱炒的ASP、移動ERP。
1999年4月，ORACLE 開始對於其"業界第一款完全基於互聯網應用的 11i 電子商務套件"進行預發佈，面對電子商務潮流，ORACLE開始下手把自己塑造成新時代的領袖。同年11月，ORACLE經營的B2B電子交易市場ORACLE EXCHANGE 正式開張，繼贏得三大汽車商（福特、通用、克萊斯勒）的網上交易市場Covisint 的大單之後，ORACLE又贏得不少虛擬市場的生意。
需要順便一提的是，也是在1999年末，IBM公司決定將企業應用軟體部門分拆出去，全面退出。按照郭士納在其自傳中的說法：IBM在先前的12年中，用於應用軟體發展和並購的投資是200億美金，但利潤回報卻是大約負增長70%。IBM一度曾考慮並購SAP。看來，應用軟體這碗飯不是那麼好吃的，也不是財大氣粗就能搞定的，連IBM這個藍色巨人最後都選擇了知難而退。而在今天，恐怕已經很少有人知道IBM曾經搞過什麼應用軟體（據說主要是有關生產製造方面的）。
儘管在上世紀90年代後期，ORACLE付出極大努力在盡力追趕SAP，但從ERP市場的總體份額來看，仍不足SAP的三分之一。埃裏森為其對ERP市場曾經的漠視付出了代價。2001年， 埃裏森在一次公開講演中曾說道"我幾乎十年時間沒有關注應用軟體。我非常幸福地看到資料庫的起步與飛翔。後來我認識到，我從未見過我們的應用軟體。作為首 席執行官而沒有見過自己的某種產品，這令我很驚訝。對於沒有儘早以應用軟體為核心，我感到遺憾嗎？絕對遺憾。要是早在這方面多下功夫就好了，我犯了許多錯 誤"。
不過，平心而論，ORACLE能在短短的6年時間裏，打敗諸多競爭對手，一躍而居於應用軟體世界第二的位置，儘管與SAP仍有不小差距，但這已經是個不小的成績。難怪那位元作為ORACLE應用軟體創始人的傑夫·沃克，在被迫離開公司多年之後重提舊事，仍抑制不住地感到驕傲與自得："僅在6年時間裏，ORACLE就從一個不入流的角色發展成應用軟體行業的領頭羊，儘管SAP有R/3，但在應用軟體市場上，他們並沒有達到高不可及的程度，他們並沒有真正做到象ORACLE那樣成功"。或許可以說，ORACLE 應用軟體產品後來的成功，傑夫·沃克在最初的產品規劃設計階段，就已經為之植入了最重要的成功"基因"，昔日他植下的"幼苗"已長成大樹，他有理由為之驕傲。
但客戶由於產品功能、品質方面所遭受的痛苦與挫敗感也是實實在在的。以國內最早的ORACLE ERP 用戶"華為"為例，最初使用的頭兩年，情況是是相當可怖的。莫名其妙的錯誤、無緣無故的宕機、沒完沒了的補丁，以及用戶忽然間進不去、出不來等等一系列問題，導致公司上下怨聲載道，IT部門承受著沉重的壓力，以至於最終導致負責IT工程選型與實施的一位創業元老、公司副總裁，在被老闆罵得狗血噴頭後怏怏地黯然離去。
1997年底，圍繞應用軟體業務在ORACLE公司高層之間所引發的政治鬥爭已經到了"白日化"的地步，鑒於應用軟體在市場上的糟糕表現，董事會有人跳出來公開建議：ORACLE要 麼收購一家競爭對手以壯大應用軟體業務，要麼乾脆將這方面業務全部賣掉。這當然引起了來自開發團隊的無比憤怒。以公司總裁雷·萊恩為首的運營團隊則公開指 責羅恩·沃爾無能，在大庭廣眾之下說應用軟體根本是個敗筆，並向埃裏森"逼宮"：要麼讓羅恩·沃爾出局，另換他人，要麼我們就辭職。
鬥爭的最後結果以埃裏森將公司總裁雷·萊恩及其他反對者通通逐出公司為收場。埃裏森從此開始關心並親自掌管起應用軟體的開發工作，並敏銳地提出了"應用產品轉向B/S架 構、全面實現互聯網應用"的創新設想。應當說，以羅恩·沃爾為首的開發團隊並沒有辜負老闆的"知遇之恩"，產品開發與完善進度明顯加快，產品的市場表現開 始逐步變得亮麗。多年以後，對於羅恩·沃爾曾經受到的攻擊與屈辱，埃裏森還在替他打抱不平："雷稱羅恩為笑料，這不僅與事實不符，而且說的是外行話，有失 公允。羅恩建造的應用軟體管理著全球近1.5萬家公司，僅次於SAP"。
1998年，ORACLE應用產品R11 套件面世。到98年4月，已經有大約1300個客戶。到98年10月，ORACLE 發佈CRM3.0，並實現ERP與CRM產品的高度集成。也是在這年，ORACLE ERP 的線上商務應用（business On line）與移動商務應用（Mobile APPS）得以成功實現。這兩款應用亦即多年後國內有人熱炒的ASP、移動ERP。
1999年4月，ORACLE 開始對於其"業界第一款完全基於互聯網應用的 11i 電子商務套件"進行預發佈，面對電子商務潮流，ORACLE開始下手把自己塑造成新時代的領袖。同年11月，ORACLE經營的B2B電子交易市場ORACLE EXCHANGE 正式開張，繼贏得三大汽車商（福特、通用、克萊斯勒）的網上交易市場Covisint 的大單之後，ORACLE又贏得不少虛擬市場的生意。
需要順便一提的是，也是在1999年末，IBM公司決定將企業應用軟體部門分拆出去，全面退出。按照郭士納在其自傳中的說法：IBM在先前的12年中，用於應用軟體發展和並購的投資是200億美金，但利潤回報卻是大約負增長70%。IBM一度曾考慮並購SAP。看來，應用軟體這碗飯不是那麼好吃的，也不是財大氣粗就能搞定的，連IBM這個藍色巨人最後都選擇了知難而退。而在今天，恐怕已經很少有人知道IBM曾經搞過什麼應用軟體（據說主要是有關生產製造方面的）。
儘管在上世紀90年代後期，ORACLE付出極大努力在盡力追趕SAP，但從ERP市場的總體份額來看，仍不足SAP的三分之一。埃裏森為其對ERP市場曾經的漠視付出了代價。2001年， 埃裏森在一次公開講演中曾說道"我幾乎十年時間沒有關注應用軟體。我非常幸福地看到資料庫的起步與飛翔。後來我認識到，我從未見過我們的應用軟體。作為首 席執行官而沒有見過自己的某種產品，這令我很驚訝。對於沒有儘早以應用軟體為核心，我感到遺憾嗎？絕對遺憾。要是早在這方面多下功夫就好了，我犯了許多錯 誤"。
不過，平心而論，ORACLE能在短短的6年時間裏，打敗諸多競爭對手，一躍而居於應用軟體世界第二的位置，儘管與SAP仍有不小差距，但這已經是個不小的成績。難怪那位元作為ORACLE應用軟體創始人的傑夫·沃克，在被迫離開公司多年之後重提舊事，仍抑制不住地感到驕傲與自得："僅在6年時間裏，ORACLE就從一個不入流的角色發展成應用軟體行業的領頭羊，儘管SAP有R/3，但在應用軟體市場上，他們並沒有達到高不可及的程度，他們並沒有真正做到象ORACLE那樣成功"。或許可以說，ORACLE 應用軟體產品後來的成功，傑夫·沃克在最初的產品規劃設計階段，就已經為之植入了最重要的成功"基因"，昔日他植下的"幼苗"已長成大樹，他有理由為之驕傲。
ORACLE ERP 的前世今生 (5)
上世紀90年代中期，與在應用軟體市場相形見絀不同的是，ORACLE在資料庫市場正高歌猛進，埃裏森發誓要將其競爭對手Sybase、Informix趕盡殺絕。SAP R/3的火爆間接地也促進了ORACLE資料庫的銷售，兩家公司的合作關係一度還是相當的融洽。對於ORACLE的應用軟體產品，SAP表現得不以為然、不屑一顧。雖然也受到來自IBM資料庫DB2的有力競爭，但ORACLE資料庫很快就獲得了王者地位，在高端資料庫市場幾乎佔有50%的份額，這為ORACLE帶來了滾滾財源。
1995年，ORACLE應用產品R10SC（smart client application）發佈。1996年，ORACLE開始實施其應用產品的JAVA戰略，30多個模組全部實現JAVA使能。1997年，ORACLE應用產品R10.7NCA 套件（network change architecture）發佈，此時已經大約包含35個應用模組，涉及財務、人力資源、製造、供應鏈等所有企業核心業務範疇。
與大多數應用軟體發展公司一樣，ORACLE也是一邊開發、完善其產品，一邊在市場上推廣、銷售。此時的SAP已逐漸感受到來自ORACLE的競爭威脅，1996年SAP在中國華為專案上輸給ORACLE就是案例之一，其後，又在美的、中興等項目上相繼失利於ORACLE。SAP此時開始公開與ORACLE翻臉交惡，並宣佈在其ERP銷售中將主要向客戶推薦IBM的DB2資料庫產品。
邊 開發邊銷售的產品戰略，雖有儘早搶佔市場先機、增加銷售收入，並依靠客戶應用發現產品漏洞、促進產品完善的好處，但其弊端也是顯而易見的。產品的功能與質 量有欠缺、客戶使用體驗差、投訴抱怨多、市場口碑不佳等等，這些問題如果掌握、處理不好，甚至可能會毀掉產品自身的前途。在這方面，ORACLE也不能例外。更為糟糕的是，由應用產品所引發的問題，逐步演變成了ORACLE公司內部高層之間的一場複雜的政治鬥爭。
1994年， 埃裏森指派年輕的羅恩·沃爾負責應用軟體發展，但公司其他高層如負責市場銷售的雷·萊恩，負責諮詢服務的羅伯特·肖，以及董事會的一些人反對埃裏森的這一 決定，理由是他們認為羅恩·沃爾不懂應用軟體。而不太善於團隊合作、有些書生意氣的羅恩·沃爾，則仗著有埃裏森的撐腰，幾年來又一直與運營團隊針鋒相對。
從 市場銷售、諮詢實施的角度考慮，運營團隊希望在自家產品不夠完善的情況下，要麼開發部門優先提供能夠集成第三方公司優秀產品的介面軟體（即所謂"最佳配置 方案"），要麼開發部門能對自家產品開發、完善的進度期限能給出盡可能早的明確承諾，以幫助消除客戶怨氣，為市場滅火。而從產品開發管理角度考慮，由於ERP產品體系十分龐大而複雜，羅恩·沃爾堅決不願意就應用產品的開發進度與完成期限作出明確承諾，也不願意多花費寶貴的開發資源為第三方產品作嫁衣裳。於是，開發團隊與運營團隊之間的矛盾、爭吵就不可避免、越演越烈。
有 意思的是，隨著公司經營狀況的大大改善，本來就對應用產品開發不甚感興趣，此時正熱衷於開飛機、玩帆船的埃裏森，對開發團隊採取了明顯"袒護"的態度。在 他看來，開發人員的職責就是提供產品，銷售人員的職責就是賣出產品。"不要回來告訴我，你賣不出去。如果客戶不買，那麼他們就是傻瓜"。面對運營團隊的責 難與不滿，埃裏森甚而至於在一次管理層會議上掏出自己的銀行存摺翻了翻，然後對在座的人說"我按照自己的方式來處理這件事，我有足夠的Money，我做得肯定沒錯"。
1995年，ORACLE應用產品R10SC（smart client application）發佈。1996年，ORACLE開始實施其應用產品的JAVA戰略，30多個模組全部實現JAVA使能。1997年，ORACLE應用產品R10.7NCA 套件（network change architecture）發佈，此時已經大約包含35個應用模組，涉及財務、人力資源、製造、供應鏈等所有企業核心業務範疇。
與大多數應用軟體發展公司一樣，ORACLE也是一邊開發、完善其產品，一邊在市場上推廣、銷售。此時的SAP已逐漸感受到來自ORACLE的競爭威脅，1996年SAP在中國華為專案上輸給ORACLE就是案例之一，其後，又在美的、中興等項目上相繼失利於ORACLE。SAP此時開始公開與ORACLE翻臉交惡，並宣佈在其ERP銷售中將主要向客戶推薦IBM的DB2資料庫產品。
邊 開發邊銷售的產品戰略，雖有儘早搶佔市場先機、增加銷售收入，並依靠客戶應用發現產品漏洞、促進產品完善的好處，但其弊端也是顯而易見的。產品的功能與質 量有欠缺、客戶使用體驗差、投訴抱怨多、市場口碑不佳等等，這些問題如果掌握、處理不好，甚至可能會毀掉產品自身的前途。在這方面，ORACLE也不能例外。更為糟糕的是，由應用產品所引發的問題，逐步演變成了ORACLE公司內部高層之間的一場複雜的政治鬥爭。
1994年， 埃裏森指派年輕的羅恩·沃爾負責應用軟體發展，但公司其他高層如負責市場銷售的雷·萊恩，負責諮詢服務的羅伯特·肖，以及董事會的一些人反對埃裏森的這一 決定，理由是他們認為羅恩·沃爾不懂應用軟體。而不太善於團隊合作、有些書生意氣的羅恩·沃爾，則仗著有埃裏森的撐腰，幾年來又一直與運營團隊針鋒相對。
從 市場銷售、諮詢實施的角度考慮，運營團隊希望在自家產品不夠完善的情況下，要麼開發部門優先提供能夠集成第三方公司優秀產品的介面軟體（即所謂"最佳配置 方案"），要麼開發部門能對自家產品開發、完善的進度期限能給出盡可能早的明確承諾，以幫助消除客戶怨氣，為市場滅火。而從產品開發管理角度考慮，由於ERP產品體系十分龐大而複雜，羅恩·沃爾堅決不願意就應用產品的開發進度與完成期限作出明確承諾，也不願意多花費寶貴的開發資源為第三方產品作嫁衣裳。於是，開發團隊與運營團隊之間的矛盾、爭吵就不可避免、越演越烈。
有 意思的是，隨著公司經營狀況的大大改善，本來就對應用產品開發不甚感興趣，此時正熱衷於開飛機、玩帆船的埃裏森，對開發團隊採取了明顯"袒護"的態度。在 他看來，開發人員的職責就是提供產品，銷售人員的職責就是賣出產品。"不要回來告訴我，你賣不出去。如果客戶不買，那麼他們就是傻瓜"。面對運營團隊的責 難與不滿，埃裏森甚而至於在一次管理層會議上掏出自己的銀行存摺翻了翻，然後對在座的人說"我按照自己的方式來處理這件事，我有足夠的Money，我做得肯定沒錯"。
ORACLE ERP 的前世今生 (4)
二、1993年至2000年：奮起直追，艱難突圍
1988年，SAP的創業者們做出了一個後來被稱為"天才"的決定：開發基於C/S架構的R/3系統。4年之後的1992年7月，R/3問世並很快風靡歐洲、席捲美國。在隨後的短短幾年內，R/3取得了空前的成功，那些世界500強的企業巨頭，包括在IT業界聲名顯赫的大公司諸如IBM、惠普、微軟、蘋果、英代爾等等，紛紛上線SAP R/3。
如今的SAP在其市場宣傳中，總是喜歡刻意強調"SAP 是世界500強中80%公司的選擇，是財富500強背後的管理大師"。其實，這也沒有什麼特別的，因為在上世紀最後十年，資訊化革命浪潮滾滾而來，各大公司紛紛進行企業資訊化建設的時候，SAP幾乎就是唯一的、可能的選擇。用SAP的CEO普拉特納的話說就是："我們把同行嚇得3年動彈不得，放眼望去，市場上還看不見對手"。
SAP 當時可謂占盡天時、地利、人和，並奠定了到如今都一直難以撼動的市場老大地位。高端ERP軟體的"粘著性"很強，與企業之間用"夫妻關係"來形容毫不為過。如今的世界500強圈子裏，除了極少數近10多年才冒出來的"暴發戶"，ORACLE要想去那些"老貴族"家裏插一腳、當"小三"，談何容易，何況SAP也根本就不是"糟糠"。
對於ORACLE的應用產品而言，1992年R/3的問世無異於一場災難。前ORACLE總裁雷·萊恩曾說"R/3改變了整個競爭格局，我們好像沒穿褲子被逮到一樣。與SAP相比，我們顯得微不足道，我們與SAP之間根本無競爭可言，因為我們幾乎從未有與他們一較短長的局面"。
知恥而後勇。於是ORACLE管理層做出了一個重大的決定：從1993到1997年，爭取用4年的時差奮力追趕SAP，集中精力投入到打造特色應用軟體產品中，以此與SAP展開競爭。為了能夠儘快縮短與SAP的差距，ORACLE購買並使用了SAP的產品，一向倨傲不遜，喜歡口出狂言的ORACLE老闆拉裏·埃裏森，甚至也謙虛地承認SAP是自己的老師。
1993年，ORACLE 決定將過去所有的應用產品重寫以適應於C/S架構。當年，發佈應用產品 R10，包括財務、製造與人力資源三大部分。財務部分包括：總賬GL、應付AP、應收AR、採購PO、訂單OE、庫存INV、固定資產FA、項目會計（project account）；製造部分包括：工程ENG、清單BOM、物料計畫MRP、主計畫MPS、能力計畫CAP、在製品WIP；人力資源部分：人事管理Employee、工資冊Payroll。儘管R10實際尚無力與SAP競爭，但從企業核心業務應用角度來看，產品的規劃設計至少看起來已經相當完整，這為產品的市場推廣及以後的完善與提高打下了堅實基礎。
1993年，ORACLE曾經的市場銷售"狀元"，一度曾負責ORALCE內部所使用的"電話銷售管理系統"開發並在公司危難時刻離開的湯姆·西貝爾，創建"Siebel 系統公司"，主推CRM產品（西貝爾看來一直是對自己在ORACLE曾搞過的產品念念不忘）。公司迅速壯大，後來成為ORACLE的一個強勁對手，年營收曾高達16億美金，並最終在2005年被ORACLE收購。
另外，值得一提的是，1993年另外一家中國本土企業應用軟體公司"金蝶"成立，也是從財務軟體開始做起。截至2008年，其年營收約1.25億美金。
1988年，SAP的創業者們做出了一個後來被稱為"天才"的決定：開發基於C/S架構的R/3系統。4年之後的1992年7月，R/3問世並很快風靡歐洲、席捲美國。在隨後的短短幾年內，R/3取得了空前的成功，那些世界500強的企業巨頭，包括在IT業界聲名顯赫的大公司諸如IBM、惠普、微軟、蘋果、英代爾等等，紛紛上線SAP R/3。
如今的SAP在其市場宣傳中，總是喜歡刻意強調"SAP 是世界500強中80%公司的選擇，是財富500強背後的管理大師"。其實，這也沒有什麼特別的，因為在上世紀最後十年，資訊化革命浪潮滾滾而來，各大公司紛紛進行企業資訊化建設的時候，SAP幾乎就是唯一的、可能的選擇。用SAP的CEO普拉特納的話說就是："我們把同行嚇得3年動彈不得，放眼望去，市場上還看不見對手"。
SAP 當時可謂占盡天時、地利、人和，並奠定了到如今都一直難以撼動的市場老大地位。高端ERP軟體的"粘著性"很強，與企業之間用"夫妻關係"來形容毫不為過。如今的世界500強圈子裏，除了極少數近10多年才冒出來的"暴發戶"，ORACLE要想去那些"老貴族"家裏插一腳、當"小三"，談何容易，何況SAP也根本就不是"糟糠"。
對於ORACLE的應用產品而言，1992年R/3的問世無異於一場災難。前ORACLE總裁雷·萊恩曾說"R/3改變了整個競爭格局，我們好像沒穿褲子被逮到一樣。與SAP相比，我們顯得微不足道，我們與SAP之間根本無競爭可言，因為我們幾乎從未有與他們一較短長的局面"。
知恥而後勇。於是ORACLE管理層做出了一個重大的決定：從1993到1997年，爭取用4年的時差奮力追趕SAP，集中精力投入到打造特色應用軟體產品中，以此與SAP展開競爭。為了能夠儘快縮短與SAP的差距，ORACLE購買並使用了SAP的產品，一向倨傲不遜，喜歡口出狂言的ORACLE老闆拉裏·埃裏森，甚至也謙虛地承認SAP是自己的老師。
1993年，ORACLE 決定將過去所有的應用產品重寫以適應於C/S架構。當年，發佈應用產品 R10，包括財務、製造與人力資源三大部分。財務部分包括：總賬GL、應付AP、應收AR、採購PO、訂單OE、庫存INV、固定資產FA、項目會計（project account）；製造部分包括：工程ENG、清單BOM、物料計畫MRP、主計畫MPS、能力計畫CAP、在製品WIP；人力資源部分：人事管理Employee、工資冊Payroll。儘管R10實際尚無力與SAP競爭，但從企業核心業務應用角度來看，產品的規劃設計至少看起來已經相當完整，這為產品的市場推廣及以後的完善與提高打下了堅實基礎。
1993年，ORACLE曾經的市場銷售"狀元"，一度曾負責ORALCE內部所使用的"電話銷售管理系統"開發並在公司危難時刻離開的湯姆·西貝爾，創建"Siebel 系統公司"，主推CRM產品（西貝爾看來一直是對自己在ORACLE曾搞過的產品念念不忘）。公司迅速壯大，後來成為ORACLE的一個強勁對手，年營收曾高達16億美金，並最終在2005年被ORACLE收購。
另外，值得一提的是，1993年另外一家中國本土企業應用軟體公司"金蝶"成立，也是從財務軟體開始做起。截至2008年，其年營收約1.25億美金。
ORACLE ERP 的前世今生 (3)
資料庫是ORACLE的業務基礎，是它存在的最初理由，而ORACLE應用軟體業務則幾乎是在偶然間發展起來的。ORACLE最初應用軟體（財務會計軟體）的業務開展，與當時的兩位公司高管有關，一個是ORACLE歐洲地區負責人傑夫·斯誇爾，一個是公司的首席財務官（CFO）傑夫·沃克。上世紀80年代中期，ORACLE公司的管理運作還處在一個極其鬆散的狀態，出於工作需要以及個人興趣，遠在英國的傑夫·斯誇爾決定搞一個財務會計軟體。他不僅在自己的公司內部使用這種軟體，而且還將它銷售給國際客戶。與此同時，在美國總部的ORACLE老闆拉裏·埃裏森也找來了曾自己建立過財務軟體公司的傑夫·沃克，來負責ORACLE的應用軟體發展，但很快埃裏森又任命傑夫· 沃克兼任公司的首席財務官，理由僅僅是"搞財務軟體發展必然也懂財務管理"。埃裏森這一奇怪、輕率的任命，為幾年之後（1990年）的公司銷售財務管理失控、公司瀕臨崩潰埋下了隱患。埃裏森後來不得不承認"任命傑夫·沃克為CFO是一個錯誤，不幸的是，我當時不明白"。
按照今天ORACLE官方資料的說法：ORACLE於1987年收購了一個名為"TCI"的專案（project）管理軟體公司，當年首先發佈了基於UNIX的總賬GL模組與採購PO模組，並在以後從無到有開發了其他所有應用軟體。1988年，ORACLE開發出固定資產FA模組與應付帳款AP模組。
但實際情況並非如ORACLE官方說的那樣"輕描淡寫"。在斯誇爾與沃克這兩個"傑夫"的分別努力下，ORACLE有了兩套不同的開發工具和兩套不同的會計軟體：一套在美國，一套在海外。兩個開發團隊之間的關係非常糟糕，在至少兩年時間裏，雙方各幹各的、相互爭鬥，以決出誰的財務會計系統能夠勝出。埃裏森最後介入，讓他們都重寫產品，以達到公司要求。最終埃裏森於1989年選中了傑夫·沃克的產品，而另一個"傑夫"的產品則被束之高閣，後來賣給了第三方。
1989年，ORACLE首次發佈製造應用，庫存管理（INV）是其第一個模組。注意：INV模組以後將在ORACLE ERP產品的應用架構中，扮演著極其重要的角色。ORALCE早期的產品規劃設計人員或許是于"無意識"當中，為應用產品以後的發展、壯大奠定了一個重要的基石。如同在"幼苗"階段，物種"基因"將決定未來能否長成"參天大樹"一樣，ERP 產品在早期規劃設計階段有關業務流程的設計理念與模式選擇，對於產品未來發展前景將產生重大、深遠的影響。須知"小草"是怎麼澆水也長不大的。
1990年，ORACLE發佈應用產品R7、R8，主要還是C/S架構的財務會計軟體，與SAP對"R"的"即時"定義不同，這裏的"R"僅是"Release（版本）"的意思，ORACLE應用產品後來一直沿用了這一叫法。
在1990-1991年期間，由於公司對銷售財務管理的混亂，作為上市公司的財務報表反復被修改，收入數字一再被調減，虧損數字一再被擴大。ORACLE陷入了一場空前的災難，股價暴跌，股民提起訴訟，埃裏森被要求下臺。作為"替罪羊"，曾經搞過財務會計軟體的傑夫·斯誇爾，一直負責應用軟體發展兼CFO的傑夫·沃克，先後都被埃裏森逐出公司。
不過，1992年中進入公司並承擔起挽救公司角色的前ORACLE公司總裁雷·萊恩，對於已經離開公司的傑夫·沃克在應用軟體發展方面的表現，則有相當高的評價："沃克才華橫溢，他將一些非常具有創意的東西注入了應用軟體當中"。 雷·萊恩的話很容易讓人聯想到ORACLE 產品中獨特的"彈性域"技術，彈性域與其說是一種技術，不如說是一種"方法論"，它最早使用在財務領域的會計科目中，隨後逐步發展，成為今日應用產品最重要的基礎元素之一。
1992年，ORACLE發佈應用產品R9，這是一個包含財務會計、生產製造、人力資源的應用套裝軟體。這一年ORACLE已經基本擺脫危機困境，年營收達到12億美金，當然，資料庫仍是主要收入來源。其時，在應用軟體方面，ORACLE大約已經擁有了1500個客戶，但主要是一些中小型的美國公司，它們使用ORACLE的應用套裝軟體來管理自身財務、人力資源以及生產製造方面的一些業務。
儘管埃裏森較早就意識到了ORACLE應 當進入應用軟體業務，但事實上當時及其後很多年，他對應用軟體業務一直興趣不大，他認為相對于資料庫、開發工具，應用軟體太過平庸，只是管理賬目、工資單 之類的無聊東西。埃裏森後來曾坦言："我從未關注過應用軟體領域的事情，可以說我是個對此漠不關心的旁觀者"。有這樣一位主要對技術感興趣，對於屬於管理 範疇的應用軟體甚至有些不屑一顧的CEO，或許已經預示著ORACLE應用軟體產品今後的發展道路不會一帆風順，將命運多蹇、充滿坎坷。
按照今天ORACLE官方資料的說法：ORACLE於1987年收購了一個名為"TCI"的專案（project）管理軟體公司，當年首先發佈了基於UNIX的總賬GL模組與採購PO模組，並在以後從無到有開發了其他所有應用軟體。1988年，ORACLE開發出固定資產FA模組與應付帳款AP模組。
但實際情況並非如ORACLE官方說的那樣"輕描淡寫"。在斯誇爾與沃克這兩個"傑夫"的分別努力下，ORACLE有了兩套不同的開發工具和兩套不同的會計軟體：一套在美國，一套在海外。兩個開發團隊之間的關係非常糟糕，在至少兩年時間裏，雙方各幹各的、相互爭鬥，以決出誰的財務會計系統能夠勝出。埃裏森最後介入，讓他們都重寫產品，以達到公司要求。最終埃裏森於1989年選中了傑夫·沃克的產品，而另一個"傑夫"的產品則被束之高閣，後來賣給了第三方。
1989年，ORACLE首次發佈製造應用，庫存管理（INV）是其第一個模組。注意：INV模組以後將在ORACLE ERP產品的應用架構中，扮演著極其重要的角色。ORALCE早期的產品規劃設計人員或許是于"無意識"當中，為應用產品以後的發展、壯大奠定了一個重要的基石。如同在"幼苗"階段，物種"基因"將決定未來能否長成"參天大樹"一樣，ERP 產品在早期規劃設計階段有關業務流程的設計理念與模式選擇，對於產品未來發展前景將產生重大、深遠的影響。須知"小草"是怎麼澆水也長不大的。
1990年，ORACLE發佈應用產品R7、R8，主要還是C/S架構的財務會計軟體，與SAP對"R"的"即時"定義不同，這裏的"R"僅是"Release（版本）"的意思，ORACLE應用產品後來一直沿用了這一叫法。
在1990-1991年期間，由於公司對銷售財務管理的混亂，作為上市公司的財務報表反復被修改，收入數字一再被調減，虧損數字一再被擴大。ORACLE陷入了一場空前的災難，股價暴跌，股民提起訴訟，埃裏森被要求下臺。作為"替罪羊"，曾經搞過財務會計軟體的傑夫·斯誇爾，一直負責應用軟體發展兼CFO的傑夫·沃克，先後都被埃裏森逐出公司。
不過，1992年中進入公司並承擔起挽救公司角色的前ORACLE公司總裁雷·萊恩，對於已經離開公司的傑夫·沃克在應用軟體發展方面的表現，則有相當高的評價："沃克才華橫溢，他將一些非常具有創意的東西注入了應用軟體當中"。 雷·萊恩的話很容易讓人聯想到ORACLE 產品中獨特的"彈性域"技術，彈性域與其說是一種技術，不如說是一種"方法論"，它最早使用在財務領域的會計科目中，隨後逐步發展，成為今日應用產品最重要的基礎元素之一。
1992年，ORACLE發佈應用產品R9，這是一個包含財務會計、生產製造、人力資源的應用套裝軟體。這一年ORACLE已經基本擺脫危機困境，年營收達到12億美金，當然，資料庫仍是主要收入來源。其時，在應用軟體方面，ORACLE大約已經擁有了1500個客戶，但主要是一些中小型的美國公司，它們使用ORACLE的應用套裝軟體來管理自身財務、人力資源以及生產製造方面的一些業務。
儘管埃裏森較早就意識到了ORACLE應 當進入應用軟體業務，但事實上當時及其後很多年，他對應用軟體業務一直興趣不大，他認為相對于資料庫、開發工具，應用軟體太過平庸，只是管理賬目、工資單 之類的無聊東西。埃裏森後來曾坦言："我從未關注過應用軟體領域的事情，可以說我是個對此漠不關心的旁觀者"。有這樣一位主要對技術感興趣，對於屬於管理 範疇的應用軟體甚至有些不屑一顧的CEO，或許已經預示著ORACLE應用軟體產品今後的發展道路不會一帆風順，將命運多蹇、充滿坎坷。
ORACLE ERP 的前世今生 (2)
一、1993年之前：漠不關心的旁觀者
講到ERP的歷史就不能不講到SAP，因為在上個世紀末的最後十年，業界幾乎公認SAP是ERP軟體的鼻祖，SAP的R/3幾乎就是ERP的代名詞。而講到SAP的歷史（也正如講到Microsoft、Oracle 的歷史），就不能不提到一個人所共知的名字"IBM"。IBM與當今世界最大的三家"獨立軟體供應商ISV"（第一Microsoft、第二Oracle、第三SAP）的關係可說是"源遠流長"。不僅如此，今天的所謂"獨立軟體供應商ISV"之所以能有立足之地並發展壯大，也與40年前IBM的一紙聲明大有關係。
四十多年前的上世紀六十年代，是IBM大型電腦所主導的時代，當時所謂的應用軟體巿場，例如企業用的財務管理軟體，才剛在起歩階段。雖然IBM銷售出大型計算機時會"附贈"這種軟體，但通常研發應用軟體還主要是客戶自己的工作。IBM起初並沒有向電腦買主另外收取軟體費用，附贈軟體純粹是為了促銷整個電腦系統。IBM此舉使得那些希望靠為企業的大型電腦編寫軟體生存的小公司處境艱難，於是幾家小公司聯合起來準備向美國司法部提起"反托拉斯"訴訟。面對來自美國司法部的壓力以及內部軟體發展成本的不斷增加，IBM於1969年6月23日終於做出了一個決定性的聲明：將停止發送免費隨機軟體，硬體和軟體開始分別定價。這一天或許可稱為"世界軟體業的誕辰日"，從此，一個個未來的軟體巨人將得以出生、壯大，並開始主導我們這個世界。
正是在這一背景之下，1972年5位從IBM西德分公司辭職的德國人開始了創業之旅，他們成立了一家名為SAP的公司（全稱為"Systems，Applications and Products in Data Processing"），公司的遠景目標是：開發用於即時業務處理的標準應用軟體。1973年，SAP推出第一個標準軟體產品：財務會計軟體RF，它是公司繼續幵發其他軟體元件的基礎，該軟體後來成為著名的R/1系統。"R"代表即時處理（Real time），主要針對當時大型機非互動式程式運行方式而言。前兩年，有國內ERP廠商玩起"即時企業"的概念，不知道其"靈感"的來源是否正出於此！
1981年，已有80多位員工、100多家客戶的SAP推出其第二代標準產品： R/2系統。此後經SAP對R/2系統的多年發展與完善，截至1986年，即使以今天的眼光從企業的核心業務應用角度來衡量，R/2也已經是一個相當完整的"企業級"應用系統，它包括了RF （財務管理系統）、RK（管理會計系統）、RK-P（生產計畫系統）、RM（工廠維護管理系統）、RM-Mat（物料管理系統）、RM-PPS（生產管理系統）、RM-QSS（品質管理系統〉、RP（人力資源管理系統）、RV（銷售、配貨、出貨管理系統）。R/2系統在鼎盛時期的客戶約為2200家。1988年，SAP的股票開始在德國上市。直至1992年SAP推出劃時代的第三代產品"R/3系統"之前，SAP的年收入已達8.3億馬克（按當時的匯率約為3.5億美金）。
上世紀70-80年代，是企業應用產品（即今天泛稱的ERP）英雄輩出的時代，其中有不少公司在上世紀末的90年代，均在中國國內留下過身影，其中有些產品目前在國內還有一定市場、發展得不錯，有些迄今雖以寂寞無聞，但可能還在某些企業裏工作。它們是：
Sage（賽捷），一家成立於1979年的美國公司，目前自稱是僅次於SAP、ORACLE的世界第三大ERP供應商，2008年的營收達21億美金。（另一家成立於2002年的名為Infor ，屬於私人基金性質的投資公司，在過去幾年網羅收購了一班ERP的"昨日黃花"後，年營收也高達23億美金，也自稱自己是世界第三大ERP供應商）。
Peoplesoft（仁科），1987年成立的一家美國公司，曾被譽為世界第二大ERP供應商，年營收最高曾達28億美金。2004年底以103億美金的身價"下嫁"ORACLE。
J.D.Edwards（愛德華茲），1977年成立的一家美國公司，上世紀80年代中期，曾被公認為是應用軟體的領頭羊，年營收曾高達10億美金，2003年以15億美金身價被Peoplesoft 收購，次年底隨Peoplesoft一起被oracle 納入囊中。
Baan（博安），1978年成立的一家荷蘭公司，年營收曾達6億美金，在本世紀初的互聯網泡沫破裂後，任人買賣、幾經轉手，於2008年隨SSA被私人基金投資公司Infor收購，成為其一個產品品牌。
SSA全球科技，1981年成立的一家美國公司，年營收曾達3億美金，2003年曾收購BaaN，2008年被私人基金投資公司Infor收購，成為其一個產品品牌。
Fourshift（四班或思博），1985年成立的一家美國公司，年營收最高也未曾超過1億美金。該ERP產品國人對之有些特殊感情，因為其全球2000多家製造業客戶中，有近20%的400多家客戶是中國企業。可惜其在2001年遇人不淑，以4000萬美金收購其的新東家，一家英國公司AremisSoft的老闆竟然是個騙子，涉嫌財務造假欺詐。Fourshift（四班）隨後改名Softbrands（思博）獨立運營，歷經艱難，最終於2009年5月以每股不足1美金的低價，賤賣給了私人基金投資公司Infor收購，成為其一個產品品牌。
值得一提的是，1988年一家名為"用友"的中國本土企業應用軟體公司成立，與大多數國外應用軟體公司相似，都是從財務軟體開始做起。2001年用友在上海交易所上市，募集資金8億元人民幣。用友上市當日，受到了國內股民的熱烈追捧，每股價突破100元。截至2008年，用友年營收約2.5億美金。
那麼，在整個上世紀七、八十年代，正當SAP在應用軟體市場如魚得水，其他諸多公司亦風生水起的時候，ORACLE在幹什麼呢？這家於1977年創建的軟體公司，於1986年在NASDAQ上市，1987年營收已達1億美金，當然，主要是資料庫產品的收入，因為oracle於1987年才正式建立起一個僅7個人的應用軟體發展部門。可笑的是，這個應用軟體部門最初的任務，一半是為自己的財務部門開發應用軟體，一半是在銷售資料庫產品時，應客戶的要求順便將自家使用的財務軟體拿出來賣。
講到ERP的歷史就不能不講到SAP，因為在上個世紀末的最後十年，業界幾乎公認SAP是ERP軟體的鼻祖，SAP的R/3幾乎就是ERP的代名詞。而講到SAP的歷史（也正如講到Microsoft、Oracle 的歷史），就不能不提到一個人所共知的名字"IBM"。IBM與當今世界最大的三家"獨立軟體供應商ISV"（第一Microsoft、第二Oracle、第三SAP）的關係可說是"源遠流長"。不僅如此，今天的所謂"獨立軟體供應商ISV"之所以能有立足之地並發展壯大，也與40年前IBM的一紙聲明大有關係。
四十多年前的上世紀六十年代，是IBM大型電腦所主導的時代，當時所謂的應用軟體巿場，例如企業用的財務管理軟體，才剛在起歩階段。雖然IBM銷售出大型計算機時會"附贈"這種軟體，但通常研發應用軟體還主要是客戶自己的工作。IBM起初並沒有向電腦買主另外收取軟體費用，附贈軟體純粹是為了促銷整個電腦系統。IBM此舉使得那些希望靠為企業的大型電腦編寫軟體生存的小公司處境艱難，於是幾家小公司聯合起來準備向美國司法部提起"反托拉斯"訴訟。面對來自美國司法部的壓力以及內部軟體發展成本的不斷增加，IBM於1969年6月23日終於做出了一個決定性的聲明：將停止發送免費隨機軟體，硬體和軟體開始分別定價。這一天或許可稱為"世界軟體業的誕辰日"，從此，一個個未來的軟體巨人將得以出生、壯大，並開始主導我們這個世界。
正是在這一背景之下，1972年5位從IBM西德分公司辭職的德國人開始了創業之旅，他們成立了一家名為SAP的公司（全稱為"Systems，Applications and Products in Data Processing"），公司的遠景目標是：開發用於即時業務處理的標準應用軟體。1973年，SAP推出第一個標準軟體產品：財務會計軟體RF，它是公司繼續幵發其他軟體元件的基礎，該軟體後來成為著名的R/1系統。"R"代表即時處理（Real time），主要針對當時大型機非互動式程式運行方式而言。前兩年，有國內ERP廠商玩起"即時企業"的概念，不知道其"靈感"的來源是否正出於此！
1981年，已有80多位員工、100多家客戶的SAP推出其第二代標準產品： R/2系統。此後經SAP對R/2系統的多年發展與完善，截至1986年，即使以今天的眼光從企業的核心業務應用角度來衡量，R/2也已經是一個相當完整的"企業級"應用系統，它包括了RF （財務管理系統）、RK（管理會計系統）、RK-P（生產計畫系統）、RM（工廠維護管理系統）、RM-Mat（物料管理系統）、RM-PPS（生產管理系統）、RM-QSS（品質管理系統〉、RP（人力資源管理系統）、RV（銷售、配貨、出貨管理系統）。R/2系統在鼎盛時期的客戶約為2200家。1988年，SAP的股票開始在德國上市。直至1992年SAP推出劃時代的第三代產品"R/3系統"之前，SAP的年收入已達8.3億馬克（按當時的匯率約為3.5億美金）。
上世紀70-80年代，是企業應用產品（即今天泛稱的ERP）英雄輩出的時代，其中有不少公司在上世紀末的90年代，均在中國國內留下過身影，其中有些產品目前在國內還有一定市場、發展得不錯，有些迄今雖以寂寞無聞，但可能還在某些企業裏工作。它們是：
Sage（賽捷），一家成立於1979年的美國公司，目前自稱是僅次於SAP、ORACLE的世界第三大ERP供應商，2008年的營收達21億美金。（另一家成立於2002年的名為Infor ，屬於私人基金性質的投資公司，在過去幾年網羅收購了一班ERP的"昨日黃花"後，年營收也高達23億美金，也自稱自己是世界第三大ERP供應商）。
Peoplesoft（仁科），1987年成立的一家美國公司，曾被譽為世界第二大ERP供應商，年營收最高曾達28億美金。2004年底以103億美金的身價"下嫁"ORACLE。
J.D.Edwards（愛德華茲），1977年成立的一家美國公司，上世紀80年代中期，曾被公認為是應用軟體的領頭羊，年營收曾高達10億美金，2003年以15億美金身價被Peoplesoft 收購，次年底隨Peoplesoft一起被oracle 納入囊中。
Baan（博安），1978年成立的一家荷蘭公司，年營收曾達6億美金，在本世紀初的互聯網泡沫破裂後，任人買賣、幾經轉手，於2008年隨SSA被私人基金投資公司Infor收購，成為其一個產品品牌。
SSA全球科技，1981年成立的一家美國公司，年營收曾達3億美金，2003年曾收購BaaN，2008年被私人基金投資公司Infor收購，成為其一個產品品牌。
Fourshift（四班或思博），1985年成立的一家美國公司，年營收最高也未曾超過1億美金。該ERP產品國人對之有些特殊感情，因為其全球2000多家製造業客戶中，有近20%的400多家客戶是中國企業。可惜其在2001年遇人不淑，以4000萬美金收購其的新東家，一家英國公司AremisSoft的老闆竟然是個騙子，涉嫌財務造假欺詐。Fourshift（四班）隨後改名Softbrands（思博）獨立運營，歷經艱難，最終於2009年5月以每股不足1美金的低價，賤賣給了私人基金投資公司Infor收購，成為其一個產品品牌。
值得一提的是，1988年一家名為"用友"的中國本土企業應用軟體公司成立，與大多數國外應用軟體公司相似，都是從財務軟體開始做起。2001年用友在上海交易所上市，募集資金8億元人民幣。用友上市當日，受到了國內股民的熱烈追捧，每股價突破100元。截至2008年，用友年營收約2.5億美金。
那麼，在整個上世紀七、八十年代，正當SAP在應用軟體市場如魚得水，其他諸多公司亦風生水起的時候，ORACLE在幹什麼呢？這家於1977年創建的軟體公司，於1986年在NASDAQ上市，1987年營收已達1億美金，當然，主要是資料庫產品的收入，因為oracle於1987年才正式建立起一個僅7個人的應用軟體發展部門。可笑的是，這個應用軟體部門最初的任務，一半是為自己的財務部門開發應用軟體，一半是在銷售資料庫產品時，應客戶的要求順便將自家使用的財務軟體拿出來賣。
ORACLE ERP 的前世今生 (1)
轉載自: http://zhaojeff.erp100.com/
一個偉大的公司必有一個偉大的產品。如果說資料庫是ORACLE在上世紀最後二十年賴以起家並奠定江湖地位的旗艦產品，那麼，企業應用產品（或曰ERP）則毫無疑問是ORACLE在本世紀初的這近十年，征戰疆場、所向披靡的核心武器。有關ORACLE資料庫的傳奇故事，相信對於大多數程式師或IT技術人員來說，已經是耳熟能詳、了然於心，但對於ORACLE的ERP產品的來源與發展歷史，許多人則似乎不甚了了，甚至於連ORACLE自己對於自家ERP產品的歷史淵源也是語焉不詳，有些遮遮掩掩。2007年國內有一位SAP顧問在網上與ORACLE的擁躉者爭吵時就曾說過："十年前哪里有人聽說過Oracle有什麼ERP產品，就是三年前如果你去問做ERP的，大家只知道SAP R/3，Oracle是資料庫"。
觀來看，這位仁兄所言也並非完全是意氣用事，因為十多年前，當時人們還習慣稱之為MRP II 的ORACLE ERP確實有些默默無聞（至少在國內是這樣），以至於2000年8月15日，聯想集團正式對外自豪地宣佈：由聯想、SAP和德勤合作的聯想集團ERP項目實施成功。有媒體歡呼：聯想集團ERP項目的成功，不但創造了中國IT行業在ERP項目中的"第一"，也創造了一個新的Legend (傳奇〉。可實際情況卻是，早在1996年華為就已經開始了ORACLE R10.6的全業務應用（13個核心業務模組，僅HR模組策略性地選擇了SAP）。到2000年正當媒體及業界上下正熱議柳傳志的名言"上ERP是找死，不上ERP是等死"的時候，華為卻正靜悄悄地部署著由ORACLE R10.7升級到R11。
毋庸置疑，倒退十多年，今日與SAP並稱並被業界譽為"一個是賓士、一個是寶馬"的ORACLE ERP，在當時與SAP相比，確實還只能算是一個"醜小鴨"，以至於當年SAP在華為項目上（因為更貴）輸給ORACLE之後，只是有些"不屑"地表示"遺憾"。當年的華為，與聯想相比還只是個不太起眼的角色，SAP的"遺憾"也不能完全說是故作輕鬆，多少也帶有點"等著瞧好看"的意思。只是十年之後的2006年，當在IT業界已是聲名顯赫、如日中天的華為以"重金"禮送SAP出境，將HR模組也切換到ORACLE的時候，SAP的銷售人員除了大罵"前輩"的愚蠢，就怎麼也"輕鬆"不起來了。
過去十多年來，那些曾在ERP業界風光一時、有著不俗業績的企業，諸如J.D.Edwards、Baan、Peoplesoft、Siebel、i2等等，都已經一個個倒下或象流星一般消失。後加入的重量級玩家如微軟，十年耕耘ERP，也是收穫甚微。為何只有ORACLE ERP 最終脫穎而出，能夠與SAP比肩如雙峰壁立？是歷史的必然，還是偶然？或許從回顧、探討ORACLE ERP的發展歷史能給我們一些有益的啟發。
一個偉大的公司必有一個偉大的產品。如果說資料庫是ORACLE在上世紀最後二十年賴以起家並奠定江湖地位的旗艦產品，那麼，企業應用產品（或曰ERP）則毫無疑問是ORACLE在本世紀初的這近十年，征戰疆場、所向披靡的核心武器。有關ORACLE資料庫的傳奇故事，相信對於大多數程式師或IT技術人員來說，已經是耳熟能詳、了然於心，但對於ORACLE的ERP產品的來源與發展歷史，許多人則似乎不甚了了，甚至於連ORACLE自己對於自家ERP產品的歷史淵源也是語焉不詳，有些遮遮掩掩。2007年國內有一位SAP顧問在網上與ORACLE的擁躉者爭吵時就曾說過："十年前哪里有人聽說過Oracle有什麼ERP產品，就是三年前如果你去問做ERP的，大家只知道SAP R/3，Oracle是資料庫"。
觀來看，這位仁兄所言也並非完全是意氣用事，因為十多年前，當時人們還習慣稱之為MRP II 的ORACLE ERP確實有些默默無聞（至少在國內是這樣），以至於2000年8月15日，聯想集團正式對外自豪地宣佈：由聯想、SAP和德勤合作的聯想集團ERP項目實施成功。有媒體歡呼：聯想集團ERP項目的成功，不但創造了中國IT行業在ERP項目中的"第一"，也創造了一個新的Legend (傳奇〉。可實際情況卻是，早在1996年華為就已經開始了ORACLE R10.6的全業務應用（13個核心業務模組，僅HR模組策略性地選擇了SAP）。到2000年正當媒體及業界上下正熱議柳傳志的名言"上ERP是找死，不上ERP是等死"的時候，華為卻正靜悄悄地部署著由ORACLE R10.7升級到R11。
毋庸置疑，倒退十多年，今日與SAP並稱並被業界譽為"一個是賓士、一個是寶馬"的ORACLE ERP，在當時與SAP相比，確實還只能算是一個"醜小鴨"，以至於當年SAP在華為項目上（因為更貴）輸給ORACLE之後，只是有些"不屑"地表示"遺憾"。當年的華為，與聯想相比還只是個不太起眼的角色，SAP的"遺憾"也不能完全說是故作輕鬆，多少也帶有點"等著瞧好看"的意思。只是十年之後的2006年，當在IT業界已是聲名顯赫、如日中天的華為以"重金"禮送SAP出境，將HR模組也切換到ORACLE的時候，SAP的銷售人員除了大罵"前輩"的愚蠢，就怎麼也"輕鬆"不起來了。
過去十多年來，那些曾在ERP業界風光一時、有著不俗業績的企業，諸如J.D.Edwards、Baan、Peoplesoft、Siebel、i2等等，都已經一個個倒下或象流星一般消失。後加入的重量級玩家如微軟，十年耕耘ERP，也是收穫甚微。為何只有ORACLE ERP 最終脫穎而出，能夠與SAP比肩如雙峰壁立？是歷史的必然，還是偶然？或許從回顧、探討ORACLE ERP的發展歷史能給我們一些有益的啟發。
2010年1月11日 星期一
Document Sequence
訂單, 出貨單, 採購單, 收料單等, 是如何編號的?
Step 1. 查看 Document Type 的定義
Step 2. Zoom 到 Document Sequence, 可以設前置或後置字元。
其實, 難的在台灣人的習慣, 要加年、加月、加日、怕空白、怕跳號等, 把編碼規則搞的很複雜。這樣就符合稽核的原則? 恐怕不見得!
Step 1. 查看 Document Type 的定義
Step 2. Zoom 到 Document Sequence, 可以設前置或後置字元。
Step 3. 查詢有那些要編號的? 共有 1,115 筆, 哇.... 嚇死人的多, 有空再好好研究咯。
Drop Shipment (2)
Step 5. Material Receipt. 預期收料後, 應該可以產生 Shipment.
並沒有如期產生, 確認一下程式碼:
int linkedOrderID = new MOrder (getCtx(), getC_Order_ID(), get_TrxName()).getLink_Order_ID();
if (linkedOrderID != 0)
{
dropShipment.setC_Order_ID(linkedOrderID);
int linkedOrderID = new MOrder (getCtx(), getC_Order_ID(), get_TrxName()).getLink_Order_ID();
if (linkedOrderID != 0)
{
dropShipment.setC_Order_ID(linkedOrderID);
所以, PO 要有 Link_Order_ID 才會產生, Check C_Order, 確實有 SO Order ID, ... 再查其他, 終於讓 Shipment 在 Material Receipt 後, 自動產生。若有 Invoice, 也會一併帶入。
並沒有如期產生, 確認一下程式碼:
int linkedOrderID = new MOrder (getCtx(), getC_Order_ID(), get_TrxName()).getLink_Order_ID();
if (linkedOrderID != 0)
{
dropShipment.setC_Order_ID(linkedOrderID);
int linkedOrderID = new MOrder (getCtx(), getC_Order_ID(), get_TrxName()).getLink_Order_ID();
if (linkedOrderID != 0)
{
dropShipment.setC_Order_ID(linkedOrderID);
所以, PO 要有 Link_Order_ID 才會產生, Check C_Order, 確實有 SO Order ID, ... 再查其他, 終於讓 Shipment 在 Material Receipt 後, 自動產生。若有 Invoice, 也會一併帶入。
後記: Generate PO from SO後, PO 要勾選 Drop Ship, 才會於 Material Receipt 產生 Shipment 的資料。
2010年1月7日 星期四
Drop Shipment (1)
今天花了很多的時間測試 Drop Shipment, 好不容易才測成功。Open Source 的品質管控不嚴謹以及文件不完整, Janus 應該要改善這些問題。
Step 1. 開一張 Sales Order, 勾選 Drop Ship。
Step 2. Generate PO from Sales order, 就是這裡, 發生了問題, 現在也解決了。注意, 不是 Drop Ship 的 SO, 也是可以產生 PO 的。
Step 3. 如果有不成功的, 注意 Organization & Item Price List 是否有維護正確。
Step 4. 成功產生PO 後, 會在 PO 的 Order Reference 記錄 SO#。
Step 1. 開一張 Sales Order, 勾選 Drop Ship。
Step 2. Generate PO from Sales order, 就是這裡, 發生了問題, 現在也解決了。注意, 不是 Drop Ship 的 SO, 也是可以產生 PO 的。
Step 4. 成功產生PO 後, 會在 PO 的 Order Reference 記錄 SO#。
2010年1月5日 星期二
CM - Cost Management (3) Cost Setup
Step 7. JANUS 是採用那一種成本制度? 原來是標準成本。
Step 8. 查詢 EOS-500D 的標準成本。
Step 9. Purchased Price Variance/ Invoice Price Variance 在那裡? 回頭再看 (W) Invoice (Vendor) (T) Matched Receipt 就可以看到了。
Step 8. 查詢 EOS-500D 的標準成本。
Step 9. Purchased Price Variance/ Invoice Price Variance 在那裡? 回頭再看 (W) Invoice (Vendor) (T) Matched Receipt 就可以看到了。
CM - Cost Management (2) Invoice
Step 4. 執行 Posted, 產生 Material Receipt 的會計分錄。為何是 $25,020 * 2?
Step 5. Generate Invoice from Recipt, 產生 Invoice。
Step 6. 執行 Posted, 產生分錄, 並查看分錄; 為何是 $47,900 ?
Step 6. 執行 Posted, 產生分錄, 並查看分錄; 為何是 $47,900 ?
2010年1月4日 星期一
Initial Client Setup
想要完全測試, 就來自己開一家公司吧!
Step 1. 以 SuperUser/ System Login, 於 Initial Client Setup 進入, 填入必要欄位, Accounting Template 用 AccoutingUS.csv。
Step 2. 確認後, 即可看到這個畫面, 那, 就代表成功了。
Step 3. 記得到 Accounting Calendar 把會計期間打開。Good Luck!
Step 1. 以 SuperUser/ System Login, 於 Initial Client Setup 進入, 填入必要欄位, Accounting Template 用 AccoutingUS.csv。
Step 2. 確認後, 即可看到這個畫面, 那, 就代表成功了。
Step 2. Login 時, 就可以看到這個 Role 了!
CM - Cost Management (1) Material Receipt
MDA 可以讓 USER 自己定義畫面的 Field 或 Buttons; 但, 總不能所有的欄位都自己從頭開始吧?!
今天, 就來介紹 JANUS 的功能面: Cost Management。
Step 1. 先一張 PO, 以購買 CANON EOS-500D 為例, 最近在 Survey 這一台相機, CP 很高哦! 如果使用 Adempiere DEMO DB, 記得先 Create & Open Period。要記得 Complete 才可以 Material Receipt.
Window: Purchase Order
Tab: PO Line
在 PriceEntered_Price 輸入後, 系統會依據 PriceList_List Price 計算 Discount_Discount %, 但存檔離開後, 系統會 Update PriceEntered_Price。 - 這是Adempiere 的 BUG。
Step 2. Material Receipt: Create Line from PO, 先收一台。並執行 Complete。
Step 3. 查看 Material Transaction, 庫存也確實增加了一筆 EOS-500D 了。
今天, 就來介紹 JANUS 的功能面: Cost Management。
Step 1. 先一張 PO, 以購買 CANON EOS-500D 為例, 最近在 Survey 這一台相機, CP 很高哦! 如果使用 Adempiere DEMO DB, 記得先 Create & Open Period。要記得 Complete 才可以 Material Receipt.
Window: Purchase Order
Tab: PO Line
在 PriceEntered_Price 輸入後, 系統會依據 PriceList_List Price 計算 Discount_Discount %, 但存檔離開後, 系統會 Update PriceEntered_Price。 - 這是Adempiere 的 BUG。
Step 2. Material Receipt: Create Line from PO, 先收一台。並執行 Complete。
Step 3. 查看 Material Transaction, 庫存也確實增加了一筆 EOS-500D 了。
Service Request
今天來新增一筆 Request, 代表 User 要求 IT 人員: 將 PO Header 畫面中的一些欄位隱藏, 如 Drop Ship。
Step 1. 進入 Request 畫面, Status 我明明已經建立了, 為何選不到?
EXISTS (SELECT * FROM R_RequestType rt INNER JOIN R_StatusCategory sc ON (rt.R_StatusCategory_ID=sc.R_StatusCategory_ID) WHERE R_Status.R_StatusCategory_ID=sc.R_StatusCategory_ID
哦, 原來是依 Request Type 不同, 而可以設不同的 Status 的控制, 例如: Service Request, 可以分 Draft、OPEN、Close。另一類 Request 可以分: Draft, SA, SD, Coding, UAT, Production 等。
Step 4. 所以, 在 Request Type 要對應 Status Category: Service Request
Step 1. 進入 Request 畫面, Status 我明明已經建立了, 為何選不到?
Step 2. 透過 Window, Tab & Field查出 Request 的 Table: R_Request & Column: R_Status_ID. 發現 Dynamic Validation 有值, ... 可能是這裡的問題。
Step 3. 同樣的, 右鍵 Zoom In 到 Validation Rules, 發現這段 Script,
EXISTS (SELECT * FROM R_RequestType rt INNER JOIN R_StatusCategory sc ON (rt.R_StatusCategory_ID=sc.R_StatusCategory_ID) WHERE R_Status.R_StatusCategory_ID=sc.R_StatusCategory_ID
哦, 原來是依 Request Type 不同, 而可以設不同的 Status 的控制, 例如: Service Request, 可以分 Draft、OPEN、Close。另一類 Request 可以分: Draft, SA, SD, Coding, UAT, Production 等。
Step 4. 所以, 在 Request Type 要對應 Status Category: Service Request
好了, 現在可以選到 Status 了!
MDA 是萬靈丹?
MDA 把大量的表單式的客製化避免掉了。實在沒必要為了一個畫面的一、二個欄位而花太多力氣。但, MDA 也不是萬靈丹，有些客製還是沒辦法避免!
ERP Software Customization: The Ultimate Sin of Enterprise Software?
依個人的顧問導入經驗, 很多的客製, 應該用彈性的系統定方式克服, 而不是因為會動到標準 FORM 之放棄。
ERP Software Customization: The Ultimate Sin of Enterprise Software?
依個人的顧問導入經驗, 很多的客製, 應該用彈性的系統定方式克服, 而不是因為會動到標準 FORM 之放棄。
Best Practice
國外的 ERP, 尤其像 Oracle , SAP 這些大型軟體公司, 總是號稱他們的 ERP 是 Best Practice。不僅是 ERP, 還包括 PLM, CRM...等等都是。有些行業, 在 ERP 的系統分析過程中, 尚未成型。像 IC Design House 的 Wafer 買賣, 以 "PCS" 計價, 但入庫以 Good Die 的 "EACH" 管理, Oracle, SAP 如何管理 "雙單位"? 如何號稱他們的軟體是這個行業的 Best Practice?
每個行業, 都有其特別的管理重點, 像 IC 設計產業, 其 Wafer Bank 雙單位、Lot Tracking、Date Code、委外挑片、加工條件、完工入庫及出貨挑片等大量的資料以及數量上的變化等, 絕對不是因為一套軟體 "大" 就可以解決的。某 IC Design House 為了外包, 也要先建好超過 10000 筆委工料號、委工資源、再配合委工標準製程；然後, 在真正要發外包的料號 (至少5000筆) 上, 把可能會發的委外製程放上去 (至少20筆), 才能在發外包時, 帶出委外單價。
而其他的行業, 如營建業, 從競標報價開始, 到分包, 工地管理, 成本控制等, 也不是一般軟體適用的。某傳統產業, 自己開發的系統, 一週約 500 張工單左右。導入新系統, 配合其軟體架構, 一週要開超過二萬張工單, 然後, 軟體廠商說這樣才是 "Best Practice"?
Oracle, SAP 這類 ERP, 都是以組裝業為出發點的系統架構。除了組裝業的公司呢? 除非有該行業的專屬軟體, 否則, 選擇 MDA 架構的軟體, 才能符合他們的期待!
每個行業, 都有其特別的管理重點, 像 IC 設計產業, 其 Wafer Bank 雙單位、Lot Tracking、Date Code、委外挑片、加工條件、完工入庫及出貨挑片等大量的資料以及數量上的變化等, 絕對不是因為一套軟體 "大" 就可以解決的。某 IC Design House 為了外包, 也要先建好超過 10000 筆委工料號、委工資源、再配合委工標準製程；然後, 在真正要發外包的料號 (至少5000筆) 上, 把可能會發的委外製程放上去 (至少20筆), 才能在發外包時, 帶出委外單價。
而其他的行業, 如營建業, 從競標報價開始, 到分包, 工地管理, 成本控制等, 也不是一般軟體適用的。某傳統產業, 自己開發的系統, 一週約 500 張工單左右。導入新系統, 配合其軟體架構, 一週要開超過二萬張工單, 然後, 軟體廠商說這樣才是 "Best Practice"?
Oracle, SAP 這類 ERP, 都是以組裝業為出發點的系統架構。除了組裝業的公司呢? 除非有該行業的專屬軟體, 否則, 選擇 MDA 架構的軟體, 才能符合他們的期待!
2010年1月3日 星期日
Item Attribute
Janus 的 Item Attribute 是很強的功能, 可以讓不同規格的物品, 共用一個料號, 例如:
鐵棒, 不用每一個長度, 都要先建料號, 只要依直徑、材質等條件編料號, 在交易時, 再填入長度即可。
這個有點類似 Oracle Item 的 Lot Attribute, 但, 有二項主要的差異:
1. Lot Attribute 是所有料號, 不管是成品, 半成品, 原料, 物料, 是共用同一組 Lot Attribute, 就會有鐵棒、鋼板或Wafer、CP Wafer、Assembly、FT、FG等, 都是共同 Lot Attribute。就算有分類定義, 選擇也沒限制, 例如: Wafer 可以選 Assembly 的 Lot Attribute.
2. Janus 的 Item Attribute 在每一個料號的畫面皆會出現, 包括下 PO, SO, BOM 等, 已經有點變成料號的分身了。
使用 Item Attribute 同時要滿足成本及 Planning 的需求, 就要靠顧問的功力了。
鐵棒, 不用每一個長度, 都要先建料號, 只要依直徑、材質等條件編料號, 在交易時, 再填入長度即可。
這個有點類似 Oracle Item 的 Lot Attribute, 但, 有二項主要的差異:
1. Lot Attribute 是所有料號, 不管是成品, 半成品, 原料, 物料, 是共用同一組 Lot Attribute, 就會有鐵棒、鋼板或Wafer、CP Wafer、Assembly、FT、FG等, 都是共同 Lot Attribute。就算有分類定義, 選擇也沒限制, 例如: Wafer 可以選 Assembly 的 Lot Attribute.
2. Janus 的 Item Attribute 在每一個料號的畫面皆會出現, 包括下 PO, SO, BOM 等, 已經有點變成料號的分身了。
使用 Item Attribute 同時要滿足成本及 Planning 的需求, 就要靠顧問的功力了。
2010年1月2日 星期六
Data Import
系統導入的一個重要階段: 資料轉換。系統上線初期, 會有大量的資料要轉入新系統, 包括上萬筆的料號, BOM, 製程, 庫存量, 單位成本, 應收應付餘款等。
大家應該習慣在 EXCEL 整理資料或由現有系統導出至 EXCEL, 這樣就很方便了。
JANUS已經有從 EXCEL 的導入 DB 的工具, 並且可以在導入前, 看到導入的筆數:
1. Import File Loader: 選檔案、選字元編碼 (這對中文使用者很重要)、選導入之格式, 就可以確定了。
2. 導入後的結果, 可以看到 總共 382筆, 成功 375筆。
3. 那些 EXCEL 是要導入到那一個 TABLE? 就是在 Data Import Loader 定義。
每一個欄位要對應的 Column:
因為 Import 不再是那麼的困難, 在系統導入的任一階段, 皆可以直接使用真實資料, 包括: 教育訓練、需求訪談、定義解決方案、差異分析...等, 一定事半功倍。
大家應該習慣在 EXCEL 整理資料或由現有系統導出至 EXCEL, 這樣就很方便了。
JANUS已經有從 EXCEL 的導入 DB 的工具, 並且可以在導入前, 看到導入的筆數:
1. Import File Loader: 選檔案、選字元編碼 (這對中文使用者很重要)、選導入之格式, 就可以確定了。
3. 那些 EXCEL 是要導入到那一個 TABLE? 就是在 Data Import Loader 定義。
每一個欄位要對應的 Column:
因為 Import 不再是那麼的困難, 在系統導入的任一階段, 皆可以直接使用真實資料, 包括: 教育訓練、需求訪談、定義解決方案、差異分析...等, 一定事半功倍。
2010年1月1日 星期五
Janus & Happy New Year
今天是元旦, 一年過去, 留下了什麼?
JANUS is the Roman god with the two faces, one looking forward and one back.
很多人的部落格, 記錄了一年來的點點滴滴: 工作, 吃喝, 玩樂, 休閒, 技藝 ...。在新的一年, 期能留下令人值得的工作紀錄。
Hyperlink 的功能, 常被引導至無謂的所在。Google 的 Blogger 正是最佳的平台, 簡潔、清爽, 可以專心的把事情做好。
新年新希望, 新年快樂!
JANUS is the Roman god with the two faces, one looking forward and one back.
很多人的部落格, 記錄了一年來的點點滴滴: 工作, 吃喝, 玩樂, 休閒, 技藝 ...。在新的一年, 期能留下令人值得的工作紀錄。
Hyperlink 的功能, 常被引導至無謂的所在。Google 的 Blogger 正是最佳的平台, 簡潔、清爽, 可以專心的把事情做好。
新年新希望, 新年快樂!
訂閱：
意見 (Atom)