身為MIS主管的您，代表貴公司釋出「要上馬ERP」的消息後的次日，UF、KD、「大中華區」業務總監、和專程從德國坐商務艙飛過來的「資深高級顧問團」火速面交給您三本各900頁的「建議書」，封面上大書「ABC ERP System as the Ultimate Total Solution for XYZ Business Group」。該「proposal」 內容包含下列這段文章：

「Based on our decades' countless successful examples, we want your company to follow this guideline to buy ERP system license from us:

1. 小公司買smarty ERP、U8、KIS
2. 中等規模的公司買workflow ERP、business one、NC、K3
3. 大型企業集團投資4GL ERP、R/3 ERP、U9、EAS」

這些強制規定將帶給貴公司下列負面影響：

1. 如果貴公司現在選錯同一家ERP供應商的產品系列，則：
   • 因為購買的ERP產品「太小」，所以貴公司需要的很多功能，軟體卻不提供。
   • 因為購買的ERP產品「太大」，導致貴公司除了支付不必要的軟體購買費用，而且還必須聘用大量的資訊人員。最嚴重的是，因為軟體複雜難用，導致上線出現困難。
2. 如果貴公司在購買ERP產品的當時，錯誤預測貴公司的未來規模，則：
   • 當貴公司從小規模成長到中型企業的時候，貴公司必須放棄smarty ERP、U8、KIS和最重要的多年歷史交易資料，重新購買workflow ERP、business one，面對新版軟體的新風險、重新適應新軟體的特性和操作、接受新軟體的新缺陷。
   • 當貴公司從中型企業成長為大型公司的時候，貴公司必須放棄workflow ERP、business one、NC、K3和最重要的多年歷史交易資料，重新購買4GL ERP、R/3、U9、EAS，面對新版軟體的新風險、重新適應新軟體的特性和操作、接受新軟體的新缺陷。
   • 貴公司是大企業，因為業績的滑落而必須縮編其組織規模的時候，貴公司將被迫繼續維持大量的資訊人員去操控其複雜難用的ERP軟體。這時候，ERP軟體反而成為貴公司的財務重擔、在景氣低迷時期成為加速貴公司敗亡的重要推手。（參考資料：美國加州州政府資訊專案案例）。

     備註：不須要具備成本觀念的國營企業，例如臺灣菸酒公賣局，因為有中央銀行的印鈔機在24小時運轉，又是獨佔事業，所以永遠不會倒，其MIS主管完全不必和阿諾史瓦辛格州長一樣，去擔心政府財務赤字問題。

我們打破ERP產業的陋習，讓各種規模的企業都使用相同的一套PostERP：

1. 一人公司和小企業用戶：使用PostERP的局部功能。
2. 當PostERP的用戶從中型企業成長為多角化經營的大型企業集團的時候，他們的IT部門在同一套PostERP上面自行開發更多的業務功能，給集團下的不同營業型態的成員企業使用：IT部門跟隨，甚至引領，其企業向上發展、水平擴大。
3. 只需要極少數的IT人員（小規模企業可以不設置IT人員），企業就能平順運行PostERP。

請見更多參考資料。

對一些產業而言，列印樹狀結構是常見的需求，例如：製造業的BOM、多層次傳銷業的上下游經銷商、大公司的組織表。

使用PostgreSQL，一句SELECT的SQL指令就能辦到。不僅如此，執行速度之快，遠非任何procedural language所能比較：

CREATE TABLE bom ( item TEXT, child TEXT, PRIMARY KEY (item,child) );

INSERT INTO bom VALUES ('X','B'),('X','C'),('B','D'),('D','E');

WITH RECURSIVE wr(item,component,level) AS (
SELECT item,child,0 FROM bom WHERE item='X'
UNION ALL
SELECT bom.item,bom.child,level+1
FROM wr JOIN bom ON bom.item=wr.component
WHERE level < 10
)
SELECT repeat('.',level) || item AS item
,component AS dots
FROM wr;

結果：

item | component 
------+-----------
X    | B
X    | C
.B   | D
..D  | E
(4 筆資料列)

這個SQL指令限制層次在10層以內，即使user的資料有迴圈的錯誤情形，此SQL保證不至於把PostgreSQL操到當掉。

PostERP也是這樣設計。我們竭盡所能把ERP系統的效能推到極限，避免反向要求客戶提高主機的硬體規格。

已經不記得用了多久的PostgreSQL了！從可以找到的最早記錄是1998年。當時，open source的資料庫管理系統（Database Management System，DBMS）群雄還有mSQL和mySQL。我選擇PostgreSQL的理由很簡單：PostgreSQL的功能最先進。

做決定的當時，PostgreSQL已經具有function（或稱之為「stored procedure」）和sub-query的能力了，其餘open source的DBMS都沒有這兩個功能。同時期，即使是tiptop使用的Informix 4.1也沒有sub-query和stored procedure的能力。當時，DHL也在全球使用Informix，Oracle則尚未成氣候，M$ SQL Server還沒有誕生，能和PostgreSQL的品質相提並論的DBMS，可能只有Sybase和IBM的DB2。當時的DB2可能只有main frame的版本，還沒有PC版本，我也不瞭解當時的性能。M$ SQL Server有今天的功能，是因為M$購買Sybase的技術。

sub-query的例子：SELECT a FROM b WHERE c=(SELECT x FROM y WHERE z='abc')

MIS行業最重要的要求之一是：DBMS的技術服務品質。如果資料庫毀損或是行為怪異，就是MIS人員的職位危機時刻！如果這時時候

• DBMS供應商回答你「因為你沒有簽維護合約，所以，你先簽約，我們才受理。」
• 你的電話和e-mail被轉來轉去、轉了兩三天
• 回答你的工程師是三腳貓，程度比你差，感嘆「求人不如求己！」
• 老闆心裡在問：「付薪水給你這個資料庫管理師，你卻不能解決資料庫問題，還要另外付費請廠商過來修理，那要你幹甚麼？」

的話，那麼，你隨時會陣亡，只能用「悲憤」形容自己的心情了！

我使用過Informix和M$ SQL Server，十分瞭解Informix和MS SQL Server的服務品質。也曾經悲憤過：Informix出問題已經超過一日，user因為受不了而去「打小報告」，股票上市公司的董事長親自打電話來責罵我！M$ SQL Server的情況也類似：每天有大量的資料在輸入，資料庫檔案卻停止長大！ 中國的M$業務員在電話裏的回答和Informix一樣：先付款，否則免談！

印象中，我向PostgreSQL的社群提出問題，超過90%會得到回覆。而回覆的品質可以這樣總結：

• 回覆的內容，絕大部份都切中問題，有解決掉我的麻煩。
• 回覆的時間是：美、歐的上班時間的開始2小時內。
• 95%的回覆來自美國和歐洲。
• 5%的回覆來自日本。
• 0%的回覆來自台灣和中國。

1. 2012/1/12 22:25 提問。得到回覆：
   • 2012/1/12 22:47

     Pavel Stehule：可能是奧地利人。最近才把他加進去我的linkedin好友清單裏。

   • 2012/1/13 01:11

     Merlin Moncure：美國人。自最近7年起，在PostgreSQL頗活躍

2. 2006/9/20 14:18 提問。得到回覆：
   • 2006/9/20 20:33

     Harald Fuchs：德國的教授。查他的資料，感覺他的專業好像不是資料庫，但是他竟然能在極短的時間內解出我覺得很複雜而且解不出來的SQL問題！

   • 2006/9/21 03:38 Aaron Bono
3. 1998/7/17 11:09:29 提問。得到回覆：

   1998/7/17 14:05:48。Bruce Momjian。

   此人是PostgreSQL的開山祖師之一，現在可能是EnterpriseDB的股東。EnterpriseDB在賣甚麼？順便免費幫他們廣告一下：

   PostgreSQL的性能好好到哪裏？據EnterpriseDB的報導：Sony線上娛樂公司（是不是賣Play Station線上遊戲的日本公司？）用PostgreSQL取代Oracle。

   疑問：「Oracle用戶已經開發的PL/SQL不可能直接拿去PostgreSQL上面跑吧？」。我也有相同疑問。我猜想：可能是EnterpriseDB的人在PostgreSQL上面加上他們自己開發的PL/SQL語言就搞定了吧？可能是因為PostgreSQL的PL/pgSQL和Oracle的PL/SQL很相似，所以EnterpriseDB能很快地加上Oracle的PL/SQL的語法到PostgreSQL上面。有時間的人可以去EnterpriseDB網站去瞭解。

有感而發：

• 甚麼是「高科技」？開發和維護DBMS的核心程式碼就是高科技。
• 我不鼓勵崇洋心態。但是在DBMS這個領域，可能還沒有台灣人具發言資格，佔地球四分之一人口的對岸也沒有。
• 「小偷」的行為被許多亞洲人視為人格「小瑕疵」。但是大部份的歐美國家人民和日本人認為偷竊行為是一生的奇恥大辱，如果犯過案，就很難再翻身。

我的經驗指出：PostgreSQL值得MIS人員去跟一輩子，不必擔心它的

• 功能
• 運行效率
• 穩定性
• 擴充能力
• 技術服務

跟不上你的要求。

給台灣的公、民營機構的MIS人員一些小建議：

• 建立「誠實」的心態：我們沒有義務幫任何人去偷竊Oracle、SQL Server、DB2、Informix的連線人數。引進高性能的open source資料庫管理系統PostgreSQL到你的機構，做一個堂堂正正的人。
• 體恤2300萬個人民的殘破財務、幫付我們薪水的公司股東省錢：使用高性能的open source資料庫管理系統PostgreSQL。
• 如果在春節有空，去閱讀詳細且品質高到不行的PostgreSQL技術手冊。

參考資料：幾位我印象深刻的其他DBMS高手：

• Tom Lane：美國人。博士。10年以上的核心開發人員。我曾經數次受教於Tom。他的回答簡單明瞭、一針見血。沒見過他打錯英文字、很難看到此人的照片。
• Vadim B. Mikheev。俄羅斯人。此人把PostgreSQL的品質拉高N個層次：加入了「multi-version concurrency control (MVCC)」功能。遙遙領先mySQL至少8年！
• Jan Wieck。德國人。此人把PostgreSQL的品質拉高N+1個層次：加入了PL/pgSQL。遙遙領先mySQL至少8年！

後記：我絕不選用不具sub-query、stored procedure、trigger、MVCC和procedural language等能力的DBMS，例如5年前的mySQL，用它們來開發ERP系統。我只選用PostgreSQL，既保護客戶的權益，也保障自己的信譽。

鞋廠的終極目標是找到全部符合下列要求的ERP系統：

• 能全程處理尺碼。
• 能充分運行MRP。
• 無縫整合財務模組 （部份人士稱之為「以財務為核心」） 、會計分錄清楚呈現各項交易。
• 適用於企業集團內各種行業的公司，不是僵化、寫死的「鞋業專用」ERP。
• 整個企業集團共用一個資料庫，不是每一座工廠各用一個資料庫。
• 高度國際化：一字不改，國外廠沿用；一處設計，全球使用。
• 客戶軟體不特別要求操作環境，就能高速運轉、安全使用。
• 容易維護。

這種ERP系統，

• 低失敗風險
• 短期內上線
• 高速運轉
• 低財務負擔
• 資訊可靠
• user操作簡單
• IT部門負擔輕
• 對企業的限制少

上述ERP系統特性，不只鞋廠需要，其實也是全部產業的共同追尋目標。如果IT主管

• 還沒有找到這種ERP系統，那麼，接下來要做的是：找出不尋找它的科學理由。
• 已經找到這種ERP系統，那麼，接下來要做的是：找出不使用它的科學理由。

PostERP

鞋業ERP的第8個挑戰：ERP系統的後續維護工作

鞋廠的作業繁瑣且多變，持續維護ERP系統不可免。但是，IT部門的軟體人員如果增加，則工廠的獲利率和IT部門主管的績效同時減少。

因此，IT主管務必要求ERP供應商回答這個考題：ERP系統是否允許客戶永續自行維護？如果答「是」，請接續回答下列各項：

• 用哪些程式語言和工具開發和維護？
• 原始碼的大小為何？

這個考題的答案，會在使用ERP系統以後逐一證實下列陳述的真偽：

• ERP系統使用的程式語言和開發工具越多、原始碼越大，則必須聘任越多的軟體人員。
• ERP系統使用的程式語言和開發工具的學習曲線越陡峭，則軟體人員的生產力越低落。例如：java。
• ERP系統使用的程式語言和開發工具如果太冷門，則即使重金禮聘，也不易補足所需的軟體人員。例如：ABAP、Genero。
• ERP系統的整合度越低，則越難分發和維護、使用人的抱怨越多。例如：報表系統獨立於ERP主體之外，俗稱：「外掛」。
• ERP系統使用的程式語言越落伍，則開發出良質ERP系統的可能性越低。例如：超過25年歷史的4GL、ABAP。

PostERP：

• 全部原始碼於壓縮後小於70 KB
• 僅需熟稔2種程式語言：
  1. SQL
  2. PL/pgSQL（與Oracle的PL/SQL相似）
  不需要其他開發工具。
• 選單、輸入/修改/刪除畫面、報表、執行業務邏輯運算（例如：MRP、結帳）等user操作，以及IT人員設計選單、畫面、報表、業務邏輯運算，全部整合在一個2 MB的瘦客戶.exe檔案裏。不需要任何外掛檔案、引擎、工具、.DLL。
• IT人員不必安裝瘦客戶，user直接雙擊2MB的.exe檔，開始操作PostERP。
• IT人員不必安裝通訊軟體，user直接在Internet上面跨國操作ERP系統。
• IT人員可研讀PostgreSQL的技術文件和PostERP的設定技術手冊，自我學習而成就。
• IT人員接受我們的訓練，有機會於1日內完成。
• IT部門開發一個新畫面，90%的時間用在設計資料庫的table，7%的時間用在設計trigger和stored procedure，3%的時間用在設定PostERP。
• IT部門開發一份新報表，90%不超過1人小時：50%的時間用在設計SQL的「SELECT ...」指令，45%的時間用在設計報表外觀，5%的時間用在設定PostERP。
• IT部門開發一個新業務處理程式，90%不超過1個人日。
• 有資料庫設計經驗的IT人員自行探索1週，即具生產力。

參考資料：

• 隨時有數十萬人上線的Sony線上娛樂公司（Sony On-line Entertainment）用PostgreSQL取代數十套的Oracle 9i RAC
• 在PostERP上面永續發展資訊系統的技術手冊
• 在PostERP上面永續發展資訊系統的畫面樣品

我們針對現有tiptop用戶隆重推出下列優惠升級方案：

1. 用購入tiptop價格的50%更換成PostERP。
2. 滿意更換成效，再付款給我們。若有任何不滿意之處，無須解釋理由，不必付款。

企業如果使用任何ERP軟體有下列困擾，請儘速升級到PostERP：

1. 工廠是製鞋廠。
2. 必須購買昂貴的Informix或Oracle資料庫軟體，不能使用免費、高品質的開放原碼資料庫PostgreSQL。
3. 假的多公司、多工廠、集團級ERP軟體：每一家公司、每一家工廠，各開一個資料庫，產生大量不易察覺且難以除錯的問題。例如：ERP用戶有2家工廠，
   • 甲工廠有料號A，乙工廠卻找不到。
   • 甲工廠的料號B，就是乙工廠的料號X。
   • 料號C在甲工廠的品名說明是10u電容器，在乙工廠的品名說明卻變成10u矽電容器。
   • 料號D在甲工廠的最小單位是個，在乙工廠卻變成包。
   • 客戶E在甲工廠的授權信用額度是100萬元，在乙工廠變成1億元。
   • 客戶編號、客戶名稱、客戶地址、客戶電話、客戶的累積應收帳款...也有相同問題。
   • 供應商、員工、部門、會計科目也有相同問題。
4. 假的多語系：
   • ERP用戶的工廠在越南，業務辦公室在台灣，客戶在美國。因為ERP的多數使用者在越南工廠，所以，ERP是越文版：
     • 台灣的業務人員不懂越文，所以，IT人員必須另外維護一套中文畫面（form）和報表程式，給台灣的業務人員專用。
     • 駐越南工廠的台幹，也面臨台灣業務人員的相同問題。
     • 台灣的業務人員用英文和外國客戶溝通，ERP也不能提供英文報表。業務人員必須用手工整理報表後，再發給客戶。
     如果同時有中文使用人、越南文使用人、英文使用人，則IT人員必須製作與維護3份報表、程式、畫面。
   • 用戶同時只能用一種語系維護客戶名、地址、料件名、會計科目名稱...。用戶不能同時用繁體中文、簡體中文、英文、越南文...等多種語文輸入同一家客戶的名稱、地址、聯絡人。
5. 銷售訂單、出貨單、銷貨退回單、請購單、購買訂單、進貨單、進貨退出單：
   • ERP不允許客戶在同一張訂單要求於5個不同日期出貨。ERP反向要求客戶：下5張訂單。
   • ERP不允許user把5張銷貨訂單集中在一張出貨單出貨。ERP反向要求user：開5張出貨單。
   • ERP不允許user把5張出貨單集中在一張銷貨退回單退貨。ERP反向要求user：開5張銷貨退回單。
   • ERP不允許user在同一張出貨單：出3個品名，每一個品名各有5種不同批號。ERP反向要求user：開15張出貨單。
6. 成本、會計、庫存：
   • 存貨資料、成本資料、總帳資料 ，三者各自獨立，牛頭不對馬嘴。
   • 月初結算前月的成本時，因為出現負庫存數量而中斷，user為此加班找原因到深夜。重跑數次，都還是有負庫存數量，因為接近結帳期限，不能再拖下去，會計人員乾脆手工強制調整，挑戰做假帳的底線。
   • 會計的月過帳、反過帳、結帳、反結帳動作來回跑好幾次，結果都有問題，會計人員每個月初都承受極大的壓力。
   • 業務主管在月中要求現在的成本資料，以做為其訂價、報價的依據。但是系統只提供上個月底的舊成本資料。
   • 系統令管理人員無從區分第1條生產線和第2條生產線的成本（績效）差異。
   • 為計算成本，要求用戶為每一個料號指定一個複雜的多段會計科目編碼。例如：1111-00A-123-456。其中，1111代表原料、00A代表部門00A、123代表料號123、456代表產品類別456：
     • 一千個料號就有一千個多段會計科目編碼，user容易錯編、錯打。
     • 分析這些會計科目編碼，需要龐大、複雜的4GL程式，花費大量的主機CPU，拉低整套ERP系統的運行速度。
7. 粗糙的權限控制
   • 不能針對某些user設定一些欄位成為唯讀。
   • 不能針對某些user隱藏一些欄位。
   • 不能針對某些user設定一些記錄（record）成為唯讀。
8. 上線過程和新職員報到，需要大量的不必要訓練，因為：
   • 沒有線上程式說明，user不知道跑這個程式的目的、不知道有何影響。
   • 沒有線上報表說明，user不知道參數的意義、不知道報表內容的計算邏輯、不知道報表內容的資料取得來源。
   • 紙本手冊不好找、交代不清、過期、錯誤。
9. 低效率、混亂的程式碼
   • 維護軟體，十分困難。IT人員沒有3個月的練習（4GL、form、report）並由衷接納原廠的獨特且多樣的設計風格，則沒有生產力。
   • 資料庫的tlf_file table有近千萬筆記錄，並且快速成長中。其儲存內容包羅萬象：銷貨記錄、進貨記錄、轉倉記錄、盤點差異、調整記錄、進貨退出記錄、出貨退回記錄、調撥記錄。其資料有時候會和銷貨、進貨、轉庫、盤點、調整、進貨退出、出貨退回等原始單據不符，IT人員和user都不知道誰是誰非。它佔用大量的硬碟與磁帶的空間、花費大量的備份與restore的時間。 這個table一旦毀損，則一些重要資料不能在畫面上查找。沒有IT人員敢刪掉裡面的舊記錄，任其膨脹。
   • 大量的4GL程式碼用來動態產生SQL語句，然後再送該SQL語句到Informix/Oracle執行，浪費主機CPU。
   • 捨棄SQL不（會）用，卻大量使用低效率的FOREACH、IF... ELSE...、LET ...=...等4GL程式碼，浪費主機CPU，IT主管不斷地向公司請款以升級主機。
   • 畫面資料和報表資料不一致。
10. 用戶沒有買足netterm或vtcp的版權，甚至一套也沒有買。IT主管甚至不知道有這項必要投資，不知道自己侵犯軟體版權多年。
11. 結構性缺陷
    • 只能處理和顯示文字、數字，不能儲存員工照片、不能在雷射印表機印報表、報表名稱不能放大、不能印條碼。
    • 研發人員希望把施工說明、銷貨訂單原文、品質要求等檔案（.DOC、.PDF、.JPEG、.XLS...）附掛在指定的料號之下，卻得到IT人員的標準回答：「辦不到」。
    • 報表問題
      • 報表有時候可以預覽，有時候卻直接從印表機出去。
      • 印報表期間，有時候會莫名其妙地跳頁、亂碼。既傷財且不環保。
      • 必須花錢購買print server才能穩定出報表。安裝print server很費時。
    • 希望進步到GUI（圖形化使用介面）環境，必須加購轉換軟體和http server，不但費錢，且平添一個系統的運作速度瓶頸。購買轉換軟體後，user抱怨速度太慢。因此，要買昂貴的高性能主機去跑轉換軟體，並且，必須大幅提高數據專線的租用速率。
    • 雖然不穩定，但是user以前大部分仍能在自己的點矩陣印表機出報表。換成所謂的web環境後，user再也不能在自己座位旁邊的印表機輸出版面正常的報表。
    • user的按鍵動作經常會停格：user的原意是按一次tab鍵以跳到下個欄位，因為系統沒有反應，所以再按好幾次tab鍵。結果是：等到系統回過神，一次跳好幾個欄位。
12. 用戶不能從既有ERP系統無縫改用同一軟體供應商的另一套ERP系統，只能二選一：
    • 另外付高額費用給軟體供應商，讓他們以手工轉局部基本資料，放棄大多數的交易歷史資料。
    • 放棄全部資料，一切重來。

 

電腦主機數量、IT部門的軟體人員人數、財務部門的人數，與公司或工廠的獲利率成反比、與IT部門主管的績效成反比。

 

如果ERP在微利時期帶給貴公司的整體負面效益是

• IT部門持續地加重公司的的財務負擔：
  • 設置大量的IT程式人員。
  • IT部門的程式人員離職的速度高於補充速度，IT主管只好重複地要求老闆提高IT人員薪資。
  • 購齊授權昂貴的Informix或Oracle資料庫軟體和年度維護合約。
  • 不斷地升級主機、網路設備、數據專線、年度維護合約。
• 一位部屬離職後，其他部屬也無力承接其4GL程式，IT主管只好親自下海承接，經常加班。
• IT部門無法快速滿足user的需求，甚至積壓數年。
• IT部門不受user部門的敬重，IT部門的角色被老闆和user定型：只會花錢，不會解決問題。
• IT部門的程式人員士氣渙散，IT主管的職位急急可危。

，那麼，是IT主管必須嚴肅檢視上述各項問題的時候了！如果無力解決這些問題，請用PostERP取代這些恐龍軟體，一次永遠解決！

鞋業ERP的第6個挑戰：ERP系統的國際化程度

滿街都是號稱「兩岸三地」、「大中華區ERP領導」、「多語系」。事實：ERP系統的國際化能力有真、假兩種。有實力的鞋廠IT主管一定要提問ERP供應商下列問題：

• 如果鞋廠去印度設廠，ERP的程式能不能一字不改，拿過去就開始使用？
• 如果鞋廠去越南設廠，ERP的使用人同時有台幹和越南文員。ERP能不能在越南：
  • 提供中文報表和畫面給台幹
  • 提供越文報表和畫面給越南主管和文員

真正具實力的IT主管不是頭痛醫頭、腳痛醫腳，高瞻遠矚的IT主管才是公司的寶貴人才。

台商鞋廠因為台灣工資上漲而出走到中國沿海；隨著中國沿海工資的暴漲，加上勞工進工廠的意願日趨下滑，因而「轉進」內陸，例如：四川；為因應歐美開徵鞋傾銷重稅，一些台商又去越南、印尼、印度「擴廠」。這種逐水草而居的特性充分反應台商鞋廠的高機動性，也是無法抗拒的潮流。

位居要職的鞋廠IT主管不可能完全沒有察覺這股擋不住的潮流。這裏突顯出一個問題：如果哪一天鞋廠老闆通知全廠要去東南亞設廠，眾人眼中是資訊專家的IT主管如果這樣回答老闆：「我當初建議工廠買這套ERP，目的是要給中國廠專用。去印度設廠，最好由印度廠的IT主管自己去向別家ERP供應商買另一套英文版的鞋廠ERP、他自己去推動ERP上線專案。」，這答案是否妥當？這種分崩離析、重複投資的做法有沒有把鞋廠累積的資訊技術在集團內傳承？

PostERP：

• 跨國操作同一套PostERP：
  • 中國文員使用簡體字畫面
  • 台灣聯絡處列印繁體字報表
  • 品牌客戶用英文畫面監看進度
• 在中國使用的PostERP，直接拿去印度，立即以全英文介面運作
• 在中國使用的PostERP，翻譯3個檔案後，直接拿去越南，立即列印越文報表、操作越文畫面
• 操越語的IT人員出差3個人月應能完成技轉任務

我們對PostERP的品質深具信心；面對客戶，我們謙虛而不傲慢。歡迎客戶驗證PostERP的品質，滿意再付費。

鞋業ERP的第7個挑戰：客戶軟體的操作環境

IT主管要提問ERP供應商下列問題：

• 是不是每一部電腦都要安裝客戶軟體、安裝瀏覽器、安裝java運行環境（java runtime environment，JRE）、安裝.net運行環境、設定ODBC...？
• 跨國使用ERP客戶軟體，
  • 必須安裝哪些軟體？例如：vtcp
  • 要否必須使用Windows Remote Desktop、Citrix？
  • 需要多大的頻寬？
  • 是否要投資VPN設備才能機密傳輸？

ERP系統的操作環境影響下列各項：

• IT人員佈署客戶軟體的工作時數
• 給使用人的方便程度
• 操作環境需要的軟、硬體採購和升級費用

PostERP：

• 低耗頻寬：台灣聯絡辦公室先試用256kbps/64kbps的ADSL
• 不需要VPN：傳送的資料經過加密
• 不需要高速網路：傳送的資料經過壓縮
• 不需要買遙控軟體
• 雙擊2MB的.exe檔案，開始全球操作ERP系統、開發和維護ERP系統。

鞋業ERP的第5個挑戰：選擇題：(a)每一座工廠各用一個資料庫(b)整個企業集團共用一個資料庫

如果ERP供應商不是清楚地回答(b)，那麼，IT主管就可以確定這類ERP軟體是假的多公司、多工廠、集團級ERP軟體，它們其實只適合一家公司或工廠使用，例如：4GL ERP、U8、K3。因為它們有下列無法修補的缺陷：

假設用戶有2家工廠，這類軟體將帶給用戶下列不易發覺且難以除錯的後遺症：

• 甲工廠有料號A，乙工廠卻找不到。
• 甲工廠的料號B，就是乙工廠的料號X。
• 料號C在甲工廠的品名說明是10u電容器，在乙工廠的品名說明卻變成10u矽電容器。
• 料號D在甲工廠的最小單位是個，在乙工廠卻變成包。
• 客戶E在甲工廠的授權信用額度是100萬元，在乙工廠變成1億元。
• 客戶編號、客戶名稱、客戶地址、客戶電話、客戶的累積應收帳款...也有相同問題。
• 供應商、員工、部門、會計科目也有相同問題。

必須補充的重點是：4GL ERP這類軟體設計一些「工具程式」在資料庫之間雙向甚至多方向拋轉基本資料的補救措施，廠商謂之「同步、mirror」，在外行人眼中看來是頗神奇的「solution」；然而，任何有資料庫常識的IT人都知道這種非正規的複雜小技倆不可靠、不穩定、不徹底、常常凸鎚，這些「工具程式」的邏輯極其複雜、容易遺漏，非一般人所能維護。

資料在資料庫之間被局部同步，遠比全部沒有同步 糟糕！因為用戶再也無法分辨何者正確、何者過期！

PostERP只用一個資料庫：

• 基本資料，例如：人事資料，只保留一份。所以各工廠、各公司永遠看到一致的基本資料。
• User只輸入或維護一筆基本資料或交易資料，整個集團共用。所以無須在各資料庫之間匯出、匯入、同步、拋轉。

參考資料：tiptop升級方案。

鞋業ERP的第4個挑戰：ERP系統是不是鞋業專用軟體？

如果軟體商回答「是」，那麼，我們不建議鞋廠使用！不建議的理由：鞋業專用軟體只能用在鞋廠。這類軟體把業務邏輯寫死在程式裏，不能用在其他產業。如果你的鞋廠是集團企業的一員，或者有朝一日計畫朝多角化經營，例如：開辦鞋專賣連鎖店，那麼，這家集團企業將必須另購一套流通業專用軟體。

這項限制，對眼光短淺的人而言，不是問題。但是，高瞻遠矚的IT主管能預測到問題的嚴重性：企業集團有多套不同的ERP系統在跑，企業集團猶如聯合國！

• 資訊技術不能在企業集團內各公司傳承：鞋業專用軟體使用Oracle Developer工具維護、鞋專賣連鎖店資訊系統用PowerBuilder開發、模具廠ERP用java設計、物流公司用.NET環境...
• 資料互不相容，企業集團資訊不能整合
• 資訊人員必須重複聘任

PostERP可以用在各行各業，包括鞋廠。

真有這種ERP系統？

千真萬確、絕無戲言！PostERP不是寫死的所謂行業專用ERP。因為PostERP本身就是一個應用系統開發架構。PostERP允許用戶增加、改變核心業務，甚至可發展出連鎖零售店、大賣場、運輸業、進出口業...等產業型態迥異的ERP系統。

PostERP給鞋廠和企業集團無限的發展空間。 

我們對PostERP的品質深具信心；面對客戶，我們謙虛而不傲慢。歡迎客戶驗證PostERP的品質，滿意再付費。

鞋廠發給ERP供應商的第3道考題：你的ERP系統能否無縫整合財務模組？答「是」者，請繼續作答：

1. 與金額相關的任何交易，是否100%生成會計分錄，而非交易事件發生之後，會計人員另外用手工計算後再補登會計分錄？
2. 成本計算過程，是否以會計分錄的形式清楚交代？
3. 成本資訊是否達到下列細緻程度？
   • 鞋款編號
   • 尺碼
   • 材料編號
   • 工作站編號
   • 倉庫或儲位編號
4. 是否具永續盤存能力，隨時提供最新的成本資訊，而不是等到下個月初做完月結？

   也就是說，業務人員可以隨時取得最新的產品單位成本，以做為報價的參考；財務人員不必手工整理、調整，可以隨時在財務模組直接列印下列報表：

   • A款鞋的B尺碼在C工作站的實際成本
   • D款鞋的E尺碼在F倉庫或儲位的實際成本
   • G材料在H倉庫或儲位的實際成本
   • I款鞋的J尺碼在K儲位的實際用料成本，供申報出口退稅之用
5. 會計科目編碼是不是只用一段統制會計科目（control account），而非要求用戶設計一套複雜的多段會計科目編碼？例如：1111-00A-123-456。其中，1111代表原料、00A代表部門00A、123代表料號123、456代表產品類別456：
   • 一千個料號就有數萬個多段會計科目編碼，user容易錯編、錯打。
   • 分析這些會計科目編碼，需要龐大、複雜的程式，花費大量的主機CPU，拉低整套ERP系統的運行速度。

「鞋業專用ERP」的業務經理一旦被問到這個問題，就開始顧左右而言其它，諸如：「我們的ERP整合LEAN」、「我們有Oracle專家」、「我們的成功鞋廠客戶多到參考不完」。

另外，我們不只一次聽到這類主張：「

• 我們現在用xyz財務專用軟體很順暢，所以不必換財務軟體，我們只需要鞋業ERP。
• 其實，即使一家工廠跑兩套資訊系統：鞋業專用軟體和財務專用軟體，財務報表也做得出來！如果結帳時間太長，用人海戰術也可以縮短！
• 一家工廠跑多套資訊系統，根本不必整合！
• 進銷存模組無縫整合財務模組根本不是鞋廠的重點！

」

按理，企業即使完全不使用電腦軟體，企業也能運轉。用與不用資訊系統、資訊系統是否無縫整合，只有一項差異：企業的運作效率和成本有高低之別。

但是，稱職的IT主管永遠不會忘記MIS部門的唯一使命：提高企業的運作效率、降低營運費用。 資訊系統的進銷存是否無縫整合會計，直接影響到鞋廠的

• 財務部門的人事費用
• 現場績效評估的公平性
• 業務人員的報價品質

2008年的金融海嘯使中國東莞和溫州的一部份鞋廠倒閉。存活下來的局部台商鞋廠則加緊降低人事成本動作，例如：遷廠至中國內陸、外移至印尼、越南、印度。身為鞋廠重要幹部的IT主管們不宜置身度外，應撥冗拜訪會計部門，數一數會計部門的合計人數。因為：

會計部門的合計人數增加，則鞋廠的淨利與IT主管的績效雙雙下滑。

使用PostERP零風險：滿意再付費。

鞋廠發給ERP供應商的第2道問卷考題：你的ERP系統能否運行MRP？答「是」者，請詳述下列各項：

1. 相同的鞋款，能否在BOM設定3.5號至12.5號（或更多）的不同尺碼的用料量。
2. 某些材料並不區分尺碼，例如：皮革，可做為各尺碼的鞋材。請問：BOM是否可視鞋材的用途，有些設定、有些不設定尺碼？
3. 請詳列MRP的考慮因素和計算結果明細。例如：鞋款、尺碼、開發試作訂單量、量產訂單量、銷貨退回補做量、報廢補做量、BOM、在手量、日期、安全存量、耗損率、最少訂購量、訂購倍量、在途量...等。
4. 能否按設定的各鞋材供應商的供應比例，把MRP的建議整批轉成對鞋材供應商的採購訂單？

特別要注意的是，有一類軟體供應商對上述問題(1)會回答「是」。其內部做法是：user只須在BOM輸入5.5號鞋的用料，其餘工作就交給IT部門接手。而IT部門也是神乎其技：他們把其他尺碼的用料按預設比例，在夜深人靜時「展開」。 鞋廠如果堅持採用這類「全自動」軟體，我們無權反對，也不樂觀其成。

這道考題可以把鞋業ERP區分成3類：

1. 不能跑MRP（注意！供應商可能辯稱：「鞋廠不須要跑MRP！」或是「MRP的理論在鞋廠不適用！」）。
2. MRP只跑半套。MRP的結果誤差大，所以「僅供參考」。
3. 可以跑MRP。

MRP在鞋廠有何重要性？答案是：和電子廠相同，MRP影響鞋廠的

• 呆料程度
• 缺料程度

也就是說，MRP直接影響：

1. 品牌商對鞋廠的形象
2. 鞋材供應商對鞋廠的形象
3. 鞋廠的資金運用效率
4. 鞋廠的例外費用金額
5. 鞋廠的損益表

我們對PostERP的品質深具信心；面對客戶，我們謙虛而不傲慢。歡迎客戶驗證PostERP的品質，滿意再付費。

製鞋公司，尤其是外國知名品牌商的代工鞋廠，的IT主管準備問卷考題時宜把握下列原則：

1. 明確指出鞋廠的要求項目。
   試想：如果連IT部門的最高主管都不知道自己工廠的需求，那麼，
   • 等於在鼓勵包山包海的ERP供應商大開空頭支票。可以預料到的是：回收的問卷毫無價值！
   • 因為有商業良心的ERP供應商不敢亂開支票、亂回答，所以問卷的終極作用恰好是排除有商業良心的ERP供應商。
2. 只提問技術性問題，不給ERP供應商只顧行銷（兜售其招牌尺寸、市佔率、員工人數、資本額、標竿客戶...）卻避談ERP軟體品質的機會。
3. 問題的答案必須明確，藉以壓縮ERP供應商大做文章、實問虛答的敷衍空間。避免浪費彼此的時間與通訊費用。

鞋廠給ERP供應商的問卷第一題：你的ERP系統能否全程處理「尺碼」？

這道考題預期可以篩選出1%的初選合格ERP供應商。因為IT主管可以從這一題得到下列幾種結果：

1. 40%的ERP供應商長篇大論，炒賣「大中華區ERP領導品牌」、「一日結帳」、「ERP內含LEAN精神」等slogan，唯獨不明確回答「是」或「否」。
2. 30%的ERP供應商回答：「是。只要稍做修改，就沒問題。」。
3. 28%的ERP供應商回答：「是。只要把尺碼和鞋款編號合併，編成一個號碼。」
4. 1%的ERP供應商回答：「否」。
5. 1%的ERP供應商明確回答：「是」。

至於必須淘汰回答(3)的軟體，其理由請參考這裏。

我們對PostERP的品質深具信心，同時，我們對客戶謙虛而不傲慢。歡迎客戶驗證PostERP的品質，滿意再付費。

前一篇專文提到：

• ERP選型時，做ERP市場調查是IT主管不專業的最佳證明。不專業的IT主管包括以前的我。
• ERP選型，是IT部門最高主管證明其專業和職業良心的最佳時機。

走筆至此，也許有高人開始要質疑：

• 如何證明：台速網、鼎辛、微阮、SAP、大陸製的abc...xyz鞋業專用軟件在代工鞋廠真的都那樣不堪用？
• 如果ERP選型，做ERP市場調查，也就是請ERP廠商多提供幾家「成功案例、參考客戶」都不夠專業，那麼，要怎樣做才算專業？

對此質疑，我給ERP選型中的IT主管的建議是：做我曾經做過具職業良心與IT專業的事 –– 對ERP廠商發出技術問卷，請他們做答後繳回。具職業良心與專業素養的IT主管應該針對自己公司的資訊需求和問題，逐一向軟體商提問，類似政府標案的RFP（Request For Proposal）。 一定要這麼麻煩嗎？是的！因為：

• 你有能力準備問卷內容，就證明：你瞭解自己公司的資訊需求和問題，所以你確實具備IT主管的應有專業。
• 為降低貴公司的損失風險，你願意辛苦地製做問卷，這證明：你是一位敬業的IT主管。
• 如果ERP廠商繳回問卷，你就可以根據其答覆而局部確定其ERP系統的合用度。
• 如果ERP廠商不願意作答並繳回問卷，你就可以直接認定：(a)該廠商的ERP系統不合用，或是(b)該廠商的態度傲慢。
上面每一項特點都證明：你是操守良好的專業IT經理人，是貴公司的瑰寶。

自下篇文章起，將列舉一些「考題」，供鞋廠的IT主管於ERP選型時製作問卷的參考。

我們對PostERP的品質深具信心，同時，我們對客戶謙虛而不傲慢。歡迎客戶驗證PostERP的品質，滿意再付費。

MIS這一行的普遍現象是：公司要買ERP系統，其IT主管的第一個本能反應就是開始「做市場調查」。

即使7年前的我，雖然已經寫了15年的商業程式、領先一些人使用Linux kernel 2.0.35、身為股票上市公司的IT主管，卻也和時下一些CIO一樣：面對ERP系統實在不行的困境時所表現出來的極不專業、非常外行的一面 – 只會做市場調查。

當時，用的是前任主管花公司錢買的鼎辛tiptip，對公司和資訊人員而言，是個災難！為了解套，我咨詢鼎辛，研究補救的可能性。包山包海的軟體公司一旦得知有賺錢的機會，當然要遵守業務守則第一天條：回答「我們包山包海。沒問題！」。但是，夜深人靜時，我的專業重複地質疑：

• 我們把tiptip改了面目全非。公司還要付錢給鼎辛，讓他們的程式人員先瞭解我們改過的程式，這合理嗎？
• 鼎辛的程式人員一定比我們瞭解公司的作業與軟體二者的矛盾點嗎？
• 我們自己都改不好。派來的都是程式老手，不是新手，所以能力一定比我們強、能改好系統？
• 派來的程式人員比我們敬業？

另一方面，我也諮詢當時的台灣ERP市場第二把交椅，IE，的解套方案。IE老闆是台灣MIS產業裏極少數的技術型老闆，是台灣ERP產業的前輩，其專業令吾人敬佩！他竟然御駕親征，令吾人徨恐不已！可惜！當時的軟體品質沒有跟上IE老闆的專業腳步：老闆示範軟體過程中老是冒出「...Error..」、「...Access violation...」、「...abort..OK?」。最令我擔心的是：這麼多我記不起來的複雜畫面，將如何忠實滿足公司的點點滴滴作業需求？有無鼎辛tiptip多如牛毛的相同毛病？ 

耗費自己和軟體商大量的寶貴時間，我的市場調查結果竟然是：還是下不了決定。

還是接任的CIO英明！他一上任就閃電成功說服該公司買了Oracle ERP。自此，該公司徵軟體小主管的動作從未間斷過，迄今已約7年。

這些經驗再次告訴我自己：

• ERP選型時，做ERP市場調查是IT主管不專業的最佳證明。
• ERP選型，是IT部門最高主管證明其專業和職業良心的最佳時機。

令人感到十分意外的是，上述結論竟然適用於國內、外各種規模的企業裏的IT主管！參考資料：

• 美國加州州政府的人事薪資系統失敗案例
• R/3 ERP勇奪十大ERP災難競賽4面金牌
• R/3 ERP導致FoxMeyer藥廠倒閉
• 高科技業公司，#6116，採睛：（以下金額單位：新台幣）
  1. 買賣雙方形成共識：投資R3 ERP將獲得下列具體效益：
     1. 引進國際級管理技術及理念，提高公司的競爭力及經營效率
     2. 降低營運成本
     3. 增加企業獲利
  2. 1998年以高於1億元購買R/3 ERP全部模組
  3. 僱用30餘位IT人員專責configure（調校）R/3 ERP
  4. 2007年減資104億元打消虧損
  5. 2011年第3季資本額＝522.44億元
  6. 2011年第3季淨值＝5.36元/股（股票面值＝10元/股）
  7. 2011/12/7股票交易市場收盤價＝1.4元/股

我們對PostERP的品質深具信心，同時，我們對客戶謙虛而不傲慢。歡迎客戶驗證PostERP的品質，滿意再付費。