我今天演講圍繞的主題就是，《應需而變的管理軟件構建平臺——高效構建管理軟件應用的捷徑》，這個主題應該是我們公司首次面向社會發布，但是他也比較古老，基于這種技術，同力天合持久化的研發過程已經經歷了11年的時間，它的好處何在，請大家慢慢品嘗。
同力天合公司首席運營總監 隋寶華
從上層的財務管理到集團財務到車間管控再到生產線，軟件范圍越來越廣，越來越深。我們在做ERP推進的時候，一定要遵循一個特定的規律，即從代替手工開始，ERP能幫助企業提升管理，節約成本，最后提升競爭力。在15年前，中國推進電算化的時候，就是解決一個代替手工的工作，在10年前我們強調ERP概念的時候是強調ERP提升管理，現在我們要提倡一個節約成本的問題。
軟件企業的利潤在不斷下滑，主要體現在“三高兩低”，即，開發成本高、維護成本高、重復開發率高，市場應變低，工作效率低。中國最好的軟件企業的利潤率是多少？20%，這并沒有體現出高科技企業帶來的優勢，這是軟件企業的一個痛點，利潤率不斷下滑。
我們再看另外一個痛點，就是企業IT部門的煩惱，IT部門是承建方，不是真正意義上的甲方，甲方是公司的管理部門和業務部門，而軟件公司扮演的是建設方。IT部門首先要做的一個非常重要的事情，就是確定需求誰來簽字。作為企業的IT部門，它是不敢簽這個字的，一定要讓企業的管理部門來簽字。而企業的業務部門和管理部門簽字的時候，就要慎重了，因為簽字后就要承擔責任。因此，往往一個很好的項目，原計劃3個月，由于需求沒有簽字就拖延了6個月，因為不可能沒有簽字就去做，同時，這個項目團隊還不能解散，這樣實施成本就高了。管理軟件誰來驗收也是個問題。如果系統實施不順利，怎么找客觀原因，首先企業的管理部門不能指責本公司的業務部門不配合，也不能指責軟件廠商，所以說這時企業的IT部門的煩惱就非常多了。
同時，我們不得不談的就是信息技術的五大革命。第一次革命是接口技術，第二次革命就是中斷技術，由于有了第三個革命就是數據庫技術，它使管理軟件構建起來非常的簡單。第四個就是組建技術，就相當于搭積木似的，搭建一些組建。第五次革命就是平臺化技術，現在無論是國際還是國內的任何一個軟件公司都在追求平臺化。在各個軟件公司的網站上平臺兩個字找不到是不可能的。因此，北京同力天合鎖定了第五次革命，推出了一個全新的平臺。那么請大家看一看軟件開發技術改變的歷程，第一個過程叫做從無序到簡單有序，第二個過程叫做從簡單有序到有規則。第一個過程就是組建化開發模式，第二個過程是平臺化開發模式。
圖1
假設圖1中系統1是財務系統，系統2是人力資源系統，那么每一個系統實際上都由三個系統組成，第一是前端界面，第二是業務邏輯，第三是業務數據。那所有的廠商都在追求門戶的集成、應用的集成和數據的集成，這些集成做到一定程度之后，就形成一個軟件的平臺，因此Business Logic（BL）就形成了。首先BL是經過上百家企業應用的軟件系統，第二BL是采用MDA模型驅動的構建方法，第三BL是基于XML方式描述的業務處理過程，第四BL采用的是可望既可及、所見即所得構建過程。構建一個ERP可能您期望三年之內構建好，可能您最希望1個月，但往往不會，那么為什么會這樣，因為傳統的軟件方法，他就是需要這么長時間，用BL去構建，可能7天就可以了。
圖2
我舉個例子，圖2是印染行業的案例，它的功能模塊300多個，如果說我們在完全開發的情況下，需要1000多天，50個人（這還是在項目推動比較順利的情況下，可能需要50人）。如果用同力天合的BL方法對比一下，如圖3工作量變成了5人/月，大家只是記住這個重要的數據就可以了。
圖3
總結一下，這就是強大的柔性應用擴展能力，因為采用了MDA模型快速的構建模型軟件，比傳統的方法效率要提高10倍以上，構建100個功能模塊，和構建10000個功能模塊的道理是一樣的，不會占用很大的空間。
接下來，我簡單講一下工作原理，首先要了解業務需求，根據業務需求去構建企業業務模型，接著生成一個ERP系統模型，就可以上線運行了，其實步驟非常簡單。在這里我不得不提一個匹配時間差的概念，就是我們管理和業務的期望與系統上線之間的時間差，比如說我們今天開的會提出的管理需求，領帶希望3天就能在系統中實現，而通常用傳統軟件工程方法實現可能需要60天，也有可能更長，而用我們BL模型驅動方法匹配時間差就只有7天。比用傳統軟件工程方法提高了10倍以上。
我解釋一下什么是應需而變。首先它不是一個“無中生有”的系統。更不是“限量的變化”，只能在現有的系統上修修補補。它是“有中求變”，能夠隨著企業的發展而變化，即根據管理需求的變化而隨時變化，用一個比喻來講是開著跑車換輪胎，是快速的、高效的，在保持系統持續運行情況下應需而變的服務。我們強調協同，即你的ERP與功能匹配的協同，是更高端的協同。通過這個協同，我們可以最大程度的壓縮時間匹配差。
現在我們來談一談同力天合T3的方法。T3分為三個階段。第一個階段，需求、模型、運行、評估，我們假設這個階段叫做“玄黃階段”，大家都不清楚怎么做，客戶也不知道你的軟件達到什么程度。經過這么一輪就解決了，至少大家相互的目標清楚了。在這個階段，不需要相互簽字，只是一個評估的過程，大家開個會，形成一個評估報告。我們第二階段叫“昆岡階段”，經過第一階段之后，就是第二階段需求的開始。大家基本上相互了解了，非常清楚這個軟件應用得怎么樣了，同時能夠相互啟迪應用的深入。經過這么一個周期，第三個階段是“律呂階段”，還是要經過這么一個過程，我們不需要每個人簽字，但是大家要記住，這是一個可持續完成的階段，我們每個季度做一次這個活動，一年就是四次。這里我們避免了一個簽字的心理包袱，讓大家簽字，可能大家誰都不愿意簽。
最后是28原則。傳統軟件的工程方法，20%以下的時間用于采集客戶的需求與需求分析，80%的時間用于代碼開發與系統測試或者功能匹配，目標是滿足詳細需求規格說明書，因為我們只對你的客戶簽字認賬，不簽的東西我們不做。而同力天合BL模型驅動的是什么？80%以上的時間用于了解客戶的需求分析，20%的時間用于模型的實例化與一致性檢查，目標是100%滿足客戶的需求。
轉載請注明出處：拓步ERP資訊網http://www.guhuozai8.cn/
本文標題：應需而變的管理軟件構建平臺
相關文章
