平臺轉移到SAP
看到JDT所取得的種種可量化的成效，JDT公司的ERP功能組并沒有輕松下來，相反，卻被不斷涌現(xiàn)的更多的難題困擾著。由于自身的行業(yè)特性的相對復雜，也為JDT的ERP運行造成了許多困難。據(jù)介紹，一臺拖拉機的層次有十多層，上萬多個物料。數(shù)據(jù)動態(tài)發(fā)生量內(nèi)存目前已達5G，每月僅會計數(shù)據(jù)就有近4萬多筆，要保證其準確性，其1%的誤差都不能容忍……
在總結中，JDT發(fā)現(xiàn)系統(tǒng)方面出現(xiàn)的問題主要有三個原因，一是系統(tǒng)的缺陷（通常稱此為“Bug”）；二是應用方根據(jù)實際情況對系統(tǒng)提出一些要求；三是產(chǎn)生的數(shù)據(jù)不符合應用方的本意。在應用中出現(xiàn)的問題總是有辦法解決的，但由于系統(tǒng)自身的缺陷帶來的問題卻是最令管理層頭疼的。
同樣是物料的的問題，有時某些變動沒有在系統(tǒng)中反映，“當時情況是，我們在系統(tǒng)中做了將某物料從此貨位移至彼貨位的操作，系統(tǒng)在運算存貨時只考慮移至彼貨位上的存貨應該加上的數(shù)值，而未對此貨位的數(shù)值進行消減，導致總體存貨數(shù)量虛增。此問題早已反映到Grapecity，通過雙方的核查，證實這是一個Bug，確認并將在升級版本中修正，Grapecity公司目前為此給我們制定了臨時措施（調看存貨時先進行某些計算），使我們暫時用此措施達到了物料變動（貨位移送）不會影響存貨準確反映的目的。”
最后，鮑依民的一席話還是讓我們感覺到他們的“企圖”，“其實我也知道像我們這樣擁有60個并發(fā)用戶的規(guī)模已經(jīng)是Grapecity的極限了，而我們也為今后切換到SAP時打好基礎，畢竟約翰·迪爾總公司就是應用的SAP，只是現(xiàn)在JDT的規(guī)模還不夠?！?BR>期待快速反應
用了2年多的ERP，JDT管理者對于應用情況的感受還是“自豪”的，拿其基層員工對ERP系統(tǒng)的形容的話來說：17個模塊串成一個熠熠生輝的項鏈。
即便如此，JDT管理者們也感到其壓力還是很大。這種壓力還來自于市場，主要體現(xiàn)在客戶對某一系列產(chǎn)品提出了諸多不同的變化要求，但由于產(chǎn)品最初設計時的局限性，從而導致為滿足每一種變化而進行的長時間的專門生產(chǎn)和測試，直接影響銷售。下一步JDT考慮從產(chǎn)品設計方面著手，要求從設計時就考慮到今后用戶對該產(chǎn)品可能提出的變化需求，變化的范圍有多大，可能會涉及哪些部位，在設計時就考慮模塊化問題，通過模塊化設計產(chǎn)生出模塊化產(chǎn)品，以盡快地適應市場的要求。
看來，JDT的ERP之路還很長，管理者們要做的事還會很多。