敏捷開發在SAP ERP優化工作中的應用

陳 灝

（廣西柳工機械股份有限公司，廣西 柳州545007）

0　引言

信息技術的飛快發展及其對各行各業的覆蓋、滲透，迅速地改變著人們原來所熟悉的一切，并將世界帶入了經濟全球化的新時代。隨著全球市場競爭不斷加劇，不斷縮小的利潤空間，逐步上升的客戶期望，急劇加快的創新要求，促使企業要迅速適應這種變化和要求，否則會在嚴峻的市場競爭環境中處于被動的劣勢地位。“在推進信息化的過程中注重運用信息技術改造傳統產業”，是我國傳統產業改造的指導思想。

在這個背景下，大量的制造業企業選擇了應用ERP軟件來支撐企業未來的戰略發展；當企業花了大量資金與人力對ERP進行實施上線后，隨著外部咨詢顧問的撤離，企業后續的ERP應用、優化就成了企業面臨的問題。信息化是企業核心競爭力的一部分，不是買軟件、買硬件，不是用昂貴的信息技術描述企業流程，不是簡單的信息化的應用，而要利用信息技術提升企業的管理水平和業務能力。

1　敏捷開發的應用

1.1　敏捷開發的定義

敏捷開發模式是一種應對快速變化的需求的一種軟件開發能力。其更強調程序員團隊與業務專家之間的緊密協作、面對面的溝通頻繁交付新的軟件版本、緊湊而自我組織型的團隊，能夠很好地適應需求變化的代碼編寫和團隊組織方法。該模式以用戶的需求進化為核心，采用迭代、循序漸進的方法進行軟件開發。

1.2　敏捷開發相較傳統開發方法的優點

當企業的業務部門需要做某業務優化及改善，同時需要在系統內做一些二次開發，配合業務管理的變革，將業務流程用系統的方式固化下來，而此時如果采取傳統的軟件開發的方式——瀑布法，是不能滿足用戶需求的。

瀑布模型有以下缺點：

（1）各個階段的劃分完全固定，階段之間產生大量的文檔，極大地增加了工作量；

（2）由于開發模型是線性的，用戶只有等到整個過程的末期才能見到開發成果，早期的錯誤可能要等到開發后期的測試階段才能發現，進而帶來嚴重的后果從而增加了開發風險；

（3）通過過多的強制完成日期和里程碑來跟蹤各個項目階段；

（4）瀑布模型的突出缺點是不適應用戶需求的變化。

在實際工作中，業務需求變化較快，并且業務人員很多情況下要看到真實的系統執行時才進一步說明清楚他們的需求，只是拿到一些設計階段的文檔，他們無法想象出未來系統是如何運行，不能識別系統是否已經能滿足需求。

因此如按瀑布法完成系統二次開發，往往面臨的情況是兩種：一是開發出來的程序不是用戶當初想要的，即使有可能很大一部分原因是用戶最初沒有描述清楚他的需求，但現實情況就是如此，必須做出改變；二是系統開發還沒有完成時，用戶的需求已經開始改變了，面臨系統返工甚至重建的局面。

而敏捷開發的方式，將IT開發人員、業務人員、內部顧問集中到一個小項目組里，進行迭代式的設計、開發、測試，發現問題或需求有變化時可以快速反應，從設計源頭就可以進行快速地進行調整。

1.3　敏捷開發的具體應用

對于軟件類系統或項目，即使在需求上花的時間再長，也很難在需求階段分析和挖掘出所有的需求，有些需求注定會在設計實現、用戶使用過程中才逐漸清晰地呈現出來。在現實工作中，許多用戶都是在階段交付系統的使用中才會發現原來的需求是否是他們真正想要的，也有機會將真正的需求反饋到開發人員處，以及時地進行調整；這種開發過程中存在的不確定性，如果使用瀑布法這種變化會延遲到測試或者用戶使用階段才能發現，極大地增加了返工或變更成本，而敏捷開發方法通過短周期迭代以及盡可能早的交付可用的迭代來適應這些變化。

在裝載機公司總裝工廠信息化優化項目——生產現場執行ME項目中，使用了敏捷的開發方法[1]，較好地解決了用戶需求不明晰并且變化快的問題。

例如報工部分最先的設計是針對關鍵工序進行管理，定義的7個主要功能為：

訂單派工上線報工下線報工焊接報工交接報工涂裝報工整機入庫。

變更1：在程序設計出來并投入生產現場使用后，業務人員發現系統功能與他們的業務還是有一定的差異，提出了進一步的功能需求，下一步的功能設計變成如下：

訂單派工上線報工下線報工下線處理焊接報工交接報工涂裝上線涂裝下線整機入庫。

增加了“下線處理”功能，與下線報工連接，并將“涂裝報工”拆成“涂裝上線”和“涂裝下線”，項目小組根據用戶需求在2周之內完成設計變更及測試，交付用戶使用。

變更2：用戶使用一段時間后又提出了新的需求，功能設計再次變更如下：

訂單派工上線報工下線報工下線處理焊接報工交接報工調試排班調試派工調試派工及接收涂裝下線涂裝下線整機入庫。

增加了“調試排班”，“調試派工”，“調試派工及接收”功能，即把整機調試工作的流程也融入了IT系統管理；需求確定后，設計變更及測試3周內完成，交付用戶使用。

變更3：在使用了一段時間后，用戶又有了新的需求，此次變化如下：

訂單派工上線報工下線報工下線處理焊接報工交接報工調試排班調試派工調試派工及接收檢驗報工涂裝下線涂裝下線整機入庫。

增加了“檢驗報工”功能，目的是把質量檢驗與生產流程關聯受控（原先兩塊業務在系統中是相對獨立，沒有關聯控制的），項目組也是在兩周內完成變更交付用戶使用。

可以看到這個項目中，報工部分用戶的需求是在使用的過程中不斷變更的，主要功能由7個變成了13個，用戶在項目開始階段提不出完整而清晰的需求，如果使用傳統的瀑布法進行開發，肯定不能快速地滿足用戶地需求；采用了敏捷的方法，在項目中快速地進行迭代，發布產品。雖然最終的產品與最初設計時相距甚遠，但是達到了用戶的預期，將業務的管理固化到了IT系統之中，改善了業務管理。

1.4　敏捷開發的經驗與總結

敏捷開發的方法，可以說是快速迭代+快速嘗試+快速改進+充分交流+簡化流程。以下是在實行敏捷開發的方法中得到的一些經驗與體會：

（1）敏捷開發方法較適用于客戶不知道自己要什么的情況（這樣的客戶占絕大多數）。因為客戶不知道要什么，所以顧問及開發人員需要在項目的進程中不斷幫客戶弄明白他到底想要什么，通過和客戶溝通，合作，傾聽反饋，持續改進；敏捷的開發方法使我們從害怕用戶需求的變化，轉變為歡迎用戶的需求變化，并采用正確的方式去響應這種變化，使項目到達最大地改善業務的目的。

（2）快速迭代及產品發布

不要求每一個階段的任務做的都是最完美的，而是明明知道還有很多不足的地方，并不急著去完善它，而是把主要功能先搭建起來為目的，以最短的時間，將“半成品”提交給用戶使用，通過用戶的反饋信息，在這個“半成品”上逐步進行完善。這也是挖掘用戶需求的另一種方式。

（3）簡潔有效的小團隊溝通方式[2]

項目組核心團隊規模要小，不超過8人這宜，但人員要精干，能力要強；主要有項目經理、關鍵用戶、內部顧問、開發人員四個角色；并且在項目期間，項目組核心團隊盡可能在同一辦公室內集中辦公，這樣才能有效地保證溝通的及時性和準確性，也是保證迭代周期短的必要條件。任何的通訊工具都比不上面對面的溝通。

（4）項目范圍的控制

用戶的需求確實是在不斷的變化，但是不意味著無限制地去滿足用戶的需求；項目經理一定要把握住項目的基線、目標，不能讓需求無限制的蔓延；畢竟項目是有成本和時間的要求的。關鍵點：不要拒絕用戶的非原則性需求，這也是為了項目在受控范圍內達到最好的用戶滿意度。

（5）敏捷不要求面面俱到的文檔但離不開文檔，整個項目過程中的文檔控制仍然是必需要有的，不能因為說為了敏捷而省略了，對后期的維護及持續改善是不利的。

（6）敏捷并不僅是快，更是靈活；敏捷方法有時候被誤認為是無計劃性和紀律性的方法，實際上更確切的說法是敏捷方法強調適應性而非預見性，適應性的方法集中在快速適應現實的變化。

2　結束語

總裝工廠信息化優化項目——生產現場執行ME項目的順利完成，并得到用戶認可，促進了用戶的業務改善。之后許多的優化項目，也采取了敏捷開發的方法去開展，取得了良好的效果。關于敏捷開發方法的應用，還有非常多的方面可以去探討，不同的項目，不同的團隊，不同的產品，具體實踐方式都有可能是不同的。有一件事情應該是相同的，就是每隔一段時間，都要進行自我總結和調整，逐步改進。

信息化是一個長期持續的過程，這個過程可以這樣描述，由數據變成信息，由信息變成知識，由知識產生效益。而改進是永無止境的。

參考文獻：

[1]約翰.C.古德帕斯丘（John C.Goodpasture）（美國）.敏捷項目管理-企業級實踐與案例[M].北京：電子工業出版社，2012.

[2]Alistair Cockburn.Crystal Clear小團隊的敏捷開發方法[M].北京：清華大學出版社，2006.