MRPII/ERP軟體系統的實現(轉)

MRPII/ERP軟體系統的實現

http://www.226e.net/article/13/Article6409_1.htm

摘要：每個實施MRPII/ERP的企業都必須有一套軟體系統。本文討論了MRPII/ERP軟體系統的實現方法，選擇商品軟體的原則、做法和購買合同的簽訂以及如何控制軟體修改等三方面的問題。

一、自行開發還是購買現成的商品軟體
每個實施MRPII/ERP的企業都必須有一套軟體系統。從MRPII/ERP的發展過程來看，軟體系統的實現有兩種方法，即自行開發軟體和購買現成的商品軟體。自行開發軟體有明顯的缺點，總結起來可有三條，即耗時過長、未必成功且起點較低。
自行開發一套MRPII/ERP軟體，一般至少要用二至三年的時間，再加上其他方面的工作，實現週期將會更長。這樣，不僅要考慮軟體開發的成本，還必須考慮推遲實現MRPII/ERP系統的損失。購買現成的商品軟體可以事先了解它是否成功。然而，自己開發軟體卻做不到這一點。於是，投資已經作出，時間已經花了，卻不能回答它一定成功。雖然實施MRPII/ERP系統不成功的原因可以是多種多樣的，可能在軟體本身，可能由於使用不當。但是在這種情況下，人們往往不可避免地把軟體作為替罪羊。
另外，自行開發軟體往往特別著眼於當前的業務環境和需求，其管理思想的體現只能取決於當前的管理人員和軟體開發人員。因而往往起點較低，可能經不起時間的考驗。一旦業務發展突破原有框架，軟體很可能不再適用。
鑑於自行開發軟體可能出現以上問題，所以採用商品化軟體實現MRPII/ERP系統的企業比例日益增加。據國外統計，70年代以前還不到50％，而進入80年代則超過了80％。這些商品軟體基本上都是按照OliverWight公司釋出的“MRPII標準系統”的要求開發的，而且功能上多有擴充，都能體現MRPII/ERP的管理思想。但是，也不能由此得出結論，認為購買現成的商品軟體就是一件簡單和十全十美的事情。事實上，購買現成的商品軟體可能出現以下問題：
1、由於商品軟體的通用性，系統可能過於複雜－－一般來說，要比具體企業的需求複雜得多，這既造成使用上的困難，而且價格也高。
2、可能需要進行二次開發來修改或擴充系統的功能。
3、可能難以連線企業已有的程式。
4、可能存在故障隱患。一個大型的MRPII/ERP軟體系統含有故障隱患是不奇怪的。問題在於這些故障可能很難發現和排除，往往需要軟體供應商的幫助，如果這種幫助不能及時得到，那麼整個MRPII/ERP專案的實施和應用可能都會推遲。

二、商品軟體的選擇
鑑於購買商品軟體可能出現這樣或那樣的問題，如何選擇商品軟體就成了十分重要的問題。下面，我們從選擇商品軟體的原則、做法以及簽訂合同等三方面提出一些建議，可供決定購買MRPII/ERP商品軟體的企業參考。

1、選擇商品軟體的原則 （1）選擇一個實用的軟體產品
人們往往陷入一種境地：去追尋“最好的”軟體產品。於是，花費了很多時間和精力，而不得要領。他們不清楚，軟體選擇的目標應當是選擇一個實用的、現在就能工作的軟體產品來滿足企業的需求，而不是經過五年或八年的選擇，選擇一個“最好的”軟體產品。事實上，在這種情況下，所謂“最好”，往往是一種感覺，而不是根據某種客觀的標準。企業的軟體選擇隊伍往往根據個人對於軟體產品的好惡，而形成了不同的意見，爭來爭去，難以決定，浪費了時間和金錢，丟失了機會。在這種情況下，無論哪一派贏了，企業都是輸家。
（2）要選擇有成功使用者先例的商品軟體系統，不要做“第一個吃螃蟹的人”
成功的使用者可以說明該軟體產品以及相關的服務都比較成熟。實施MRPII/ERP是企業的大事，不要貿然選擇哪些未經實踐證實的軟體產品。特別要注意，不要被供應商牽著鼻子走。企業選擇商品軟體系統的過程，也正是軟體供應商推銷其產品的過程。在這個過程中，軟體供應商將會表現得特別積極。他們會幫助企業分析需求並給出解決方案。這一切都是以推銷其產品為目的。雖然軟體供應商也當然地希望他們的使用者獲得成功，因為成功的使用者將會幫助他們進一步推銷產品，但是，他們首要的目的是把當前的產品推銷出去。因此，企業應當對此保持清醒：在選擇軟體系統的過程中，軟體供應商並不是自己的同盟者，而是生意對手。
（3）不要操之過急
在開始選擇商品軟體之前，首先應當參加關於MRPII/ERP的初始教育，瞭解什麼是MRP、什麼是MRPII、什麼是ERP、成本如何、效益如何、如何實施、如何管理等一系列問題。在完成初始教育之前，不能開始軟體選擇的過程。對於首次實施MRPII/ERP的企業來說，最大的錯誤之一就是在沒有進行初始教育的情況下，就去選擇商品軟體系統；而最大的錯誤就是在這種情況下作出了決定。因為，在這種情況下作出正確的選擇實在是一個小概率事件。
（4）不要拖延太久
首先，我們應當強調一個事實，沒有十全十美的軟體產品。所以也不要指望找到十全十美的軟體產品。其次，根據國內外的經驗，在一定意義上說，實施應用MRPII/ERP成功與否的原因並不在於MRPII/ERP商品軟體的差別，而在於人。因此，不要因為過分的挑剔而延誤了MRPII/ERP的實施。因為延誤MRPII/ERP的實施本身就意味著損失。一般來說，商品軟體產品都自己有市場定位。企業根據自身的實際情況（需求和資金），確定對商品軟體的選擇範圍，在3－4個月內，認真考察5－6個商品軟體產品，應當能夠作出決定。
（5）要搞清為了補償不足的功能要對軟體做哪些修改或擴充，以及如何與現有系統相連線如前所述，沒有十全十美的軟體系統。因此，不要希望原封不動地使用現成的商品軟體來實現所希望的所有功能。MRPII/ERP不是一個簡單的計算機專案，它涉及到企業運營的各個方面。這裡，一方面是人們所希望的功能，一方面是商品軟體所提供的功能。二者往往不盡一致。根據MRPII/ERP的標準邏輯調整前者是不言而喻的，但有時對後者在一定程度上進行修改或使用者化開發也是不可避免的。應當確定哪些修改或擴充是必須的，以及由誰來承擔這樣的工作，是由自己來做，還是由供應商來做，或是請第三方來做。在任何情況下，都既要計算成本，又要考慮所需的時間。必須有一個時間表，因為任何推遲都是損失。
（6）要保留原有系統中好的部分
有些企業在某一方面有很好的應用程式。例如，有的企業有很好的車間生產控制系統，而其他方面較差。如果所選擇的商品軟體系統中車間生產控制系統不如原有的好，則應保留原有的系統，開發相應的介面與商品軟體連線，而不應盲目地拋棄原有系統。
（7）根據效能價格比來評價軟體系統
不同的商品軟體產品往往有不同的功能、效能、可選特徵，也有不同的價格。
因此，必須綜合考慮。效能價格比則是一個比較好的指標。在根據企業需求確定了軟體系統的效能之後，可以通過以下四項之和來計算軟體的初始成本（不計維護成本）：軟體系統的價格、軟體修改的成本、介面成本、推遲實施的成本。正確選擇商品軟體任務應使總成本最小。
（8）軟體選擇隊伍的組織
組織一個精幹、高效率的軟體選擇隊伍，對於正確地選擇MRPII/ERP軟體產品是非常重要的。這裡有三點應當引起注意：
1)要把對企業組織有影響力的人包括在軟體選擇的隊伍中，以便作出決策。
2)軟體產品的選擇隊伍應當和將來的實施隊伍統一。這樣，在軟體選擇的過程中，就能考慮到實施的要求，對問題的處理能夠更全面。
3)資料處理部門應參與軟體的選擇和評價。雖然資料處理部門的人員不應對軟體的選擇負最終的責任，但應參加軟體評價的活動。他們可以從技術上對軟體進行評價，對選擇過程中的不同意見起到平衡的作用，且能保證所選擇的軟體能夠與已有的系統相容。
（9）購買MRPII/ERP商品軟體系統需要一筆較大的投資，在開始選擇軟體產品之前，應當先作好預算並得到批准，以保證選購商品軟體的活動正常進行。

2、選擇商品軟體的做法
面對商品軟體系統的各種各樣的功能和模組，應把目光集中在最本質的地方。從以下五個方面進行考察，是選擇MRPII/ERP商品軟體的常見做法。
（1）考察軟體的功能
通常有兩種常用的軟體功能考察方法：
1)使用功能需求問題單根據企業的需求編寫一個問題單，其中列出企業所需要的功能，然後一一的衡量軟體產品的功能。這種方法的缺點是：沒有考查系統的內在邏輯，而正是這種內在的邏輯才能使系統的各項功能很好地執行起來；問題單上所列的功能很容易使不同的人有不同的理解；另外，用這種方法選出的軟體往往是比較複雜的。
2)以MRPII/ERP標準作參照
更好的方法是把MRPII/ERP的標準邏輯和企業的實際需求相結合，構造一份問題單，用來考查軟體的功能。首先了解系統的內在邏輯，以及為了使系統付諸使用必須要做哪些使用者化工作，這些工作能否在所要求的時間內完成。OliverWight公司出版的<>集中論述了從功能上和邏輯上為製造業普遍接受的MRPII的標準。
實際上，其中列出了作為MRPII系統的軟體應具備的最小功能集合。ERP的概念由美國GartnerGroup於90年代初首先提出，經短短几年時間，成了製造業市場上的時髦名詞，但至今尚遠未形成像MRPII那樣的標準。粗略地說，ERP的覆蓋範圍更寬，涉及整個企業範圍的資源，特別強調面向客戶進行管理；在技術上，ERP強調包括客戶機/伺服器體系結構、圖形使用者介面(GUI)、計算機輔助軟體工程(CASE)、物件導向技術、關聯式資料庫、第四代語言、資料採集和外部整合(EDI)等先進技術。
另外，還應考查軟體功能的合理性，如：模擬現實的能力；軟體的連通性，是否具有資料介面和程式介面，以便於二次開發；軟體的輸出報告是否滿足企業的要求；軟體的執行時間和響應時間；軟體的相容性；以及軟體是否簡明、易學、易用等等。
（2）考察軟體的技術
從系統的角度考慮，所用的技術是否具有先進性，如上述的客戶機/伺服器體系結構、圖形使用者介面(GUI)、計算機輔助軟體工程(CASE)、物件導向技術、關聯式資料庫、第四代語言、資料採集和外部整合(EDI)等都可作為考察的物件。
另外，從使用者應用的角度考慮，如：軟體漢化的質量、主要欄位的位數是否符合應用的要求、數字欄位的整數及小數位數是否符合應用的要求等等，也要進行考察。
（3）考察軟體的文件
軟體的文件對於軟體的應用是非常重要的。軟體文件包括使用手冊、幫助檔案和培訓教材。要考察軟體文件是否齊全以及漢化的質量，還要考察文件組織的邏輯性，是否有有效的索引，是否敘述清楚、簡明、易讀，而不是煩瑣冗長。
（4）考察供應商實力
一般來說，企業不但要購買供應商的MRPII/ERP商品軟體，還要購買他們的服務。因為經驗表明，沒有外部專家的幫助，一個沒有經驗的企業幾乎是不可能把MRPII/ERP專案實施成功的。所以，雖然企業最終應當立足於依靠自己的力量去使用和維護軟體系統，但是在開始階段，供應商所提供的培訓、實施諮詢和技術支援對於順利地實施MRPII/ERP專案是非常重要的。這樣，企業在購買MRPII/ERP商品軟體之後，在比較長的一段時間內還要就許多事情和供應商打交道。因此，瞭解供應商的實力是很重要的。要考察供應商的財政實力，以證明該供應商是一個可以比較長期地打交道的物件。還要考察供應商的服務支援能力，特別是供應商的培訓教師、實施顧問和其他技術人員的資歷和經驗，對於成功地實施和應用MRPII/ERP系統是非常重要的。從這一點考慮，最好直接從軟體開發商那裡購買軟體和服務。
（5）考察供應商的使用者
通過考察供應商的使用者群落、特別是本企業的同行業使用者，可以瞭解使用者對軟
件的使用情況和滿意的程度，可以瞭解供應商對使用者的培訓、實施指導與幫助是否得力，可以瞭解供應商對使用者的技術支援是否及時有效，可以瞭解其供應商的使用者成功率，等等。如果使用者的反映比較好，至少說明供應商的軟體和服務不是很差。應當注意的是，這項活動不要完全聽憑供應商的安排，應當請供應商提供幾家使用者，從中進行選擇。

3、簽訂合同
（1）這類生意的合同一般是由軟體供應商來起草的。除非特別有利，一般不要籤供應商提供的標準的合同。在所籤的合同中一定要反映本企業對軟體的評價和要求。
（2）要有準備，企業的談判代表在軟體評價和選擇階段就應儘早閱讀供應商起草的合同。
（3）在合同中一定要包括處理故障隱患的條款，應當儘可能詳細、清楚地規定排除故障的責任、時間以及懲罰方式等等。一個軟體供應商，如果拒絕承擔迅速地排除故障的責任，則可能是一個訊號，表明他們對於自己的產品或排除產品故障的能力缺乏信心，或二者兼而有之。在這種情況下，應當毫不猶豫地另選其他供應商。
（4）關於供應商的義務以及相關的日期，一定要通過明確的語言在合同中表述清楚，避免使用模稜兩可或含糊不清的語言。
（5）所有包括在生意中的內容，都要以書面形式在合同中表達清楚，任何未經書面形式在合同中表達的，都不是生意的一部分。不要相信任何口頭承諾。
（6）要有一個合理的付款日程表，不要把財務控制槓桿輕易地交到供應商手中。
（7）如果合同中包括懲罰條款，則必須和付款日程表相結合。
（8）關於軟體的維護，一般一次只簽訂一年的合同，以便確定供應商的服務質量。

三、控制對軟體的修改
以上我們談了關於如何選擇商品軟體的問題。其中，我們談到，有時對於軟體的修改是不可避免的。但是，過多的修改會破壞MRPII/ERP專案的實施。那麼，如何防止過多的修改呢？這是一個非常重要的實際問題。有三方面的工作可以幫助解決這方面的問題，即教育、標準軟體和管理。
如果一個企業對MRPII/ERP做了很好的教育工作，則可把修改軟體的要求減至最少。因為使用者理解了MRPII/ERP的邏輯之後，就可以幫助他們在MRPII/ERP的總體框架內來考慮如何解決他們的問題。再加上功能完善的標準軟體，使得使用者對MRPII/ERP的瞭解和要求都可以在軟體上得到反映。這樣，修改軟體的要求自然減少。然後通過有效的管理來控制仍然出現的修改軟體的要求。
專案實施過程中的關鍵人員，特別是指導委員會和專案組的成員，應當堅持兩條原則，一是抵制，二是區分系統的兩類功能，採取不同的處理方式。
如果一項修改軟體的要求對於企業的運營和MRPII/ERP的實施都不是本質的，則應予以抵制。因為任何修改都會推遲MRPII/ERP專案的實施，提高成本費用，減少成功的機會。要區分系統的兩類功能。MRPII/ERP系統的功能可以分為兩類，一類是必須由計算機來做的，另一類是手工方式的自動實現。前者如MRP、CRP以及車間作業管理等，它們必須由計算機來完成，因為所涉及到的計算量太大，使得無法以手工方式來完成。後者如自動列印採購訂單、工資單、以及總帳和帳單的生成等等，均可以手工方式完成，但使用計算機可以提高工作效率並改進工作質量。對於一個企業來說，從MRPII/ERP系統獲得的最大的效益還是來自那些必須由計算機完成的工作。在區分了MRPII/ERP系統的兩類不同的功能之後，可以通過以下方法有效地控制對軟體的修改。
1、對於在軟體選擇階段已經估計到、因此已經有預算的修改，可以按照計劃去做。
2、對於新出現的修改軟體的請求，要首先交資料處理部門進行工作量的估算，以確定是較大的修改還是較小的修改。這個界限對於不同的企業可能是不同的。對於較小的修改，專案小組可以決定是否接受（立即去做）、拒絕（沒有必要）或推遲。
3、對於一項較大的修改，專案小組要進行審查並提出建議。這裡要考慮的關鍵問題是，這項改變對於企業的經營和MRPII/ERP的執行是否必需？是否必須由計算機來做？如果兩個問題的回答都是肯定的，則應立即做，或儘快做。如果所請求的修改是好的、但不是本質的，則應當推遲。（有時，從外單位聘請的實施顧問也可以幫助考慮這些問題。）然後，專案小組把此項請求連同小組的建議提交給指導委員會去作出決定。
按照以上方式處理問題，軟體的修改可以得到有效的控制。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/7942439/viewspace-19767/，如需轉載，請註明出處，否則將追究法律責任。