righteffort wrote:這應該很難
（丙）具職業道德的民營企業或政府公務員的MIS主管，心中應無時不刻以企業或人民的利益為最高優先。...(恕刪)
嫌錢不夠多的時候, 哪會傻傻去賣命
錢多的時候也不會
台灣人不會拼
台灣人之所以在全球算拼,這是被壓榨的
但是如果要自動自發,那當然不會犯傻
而且程式設計有寫不完的程式
個人積分：2209分
文章編號：52521611
個人積分：423分
文章編號：52527801
righteffort wrote:
我不建議open s...(恕刪)
會提open source ERP，實在是ERP基本上沒有不改的，既然要改，就用一套從頭到尾都能改的。
>>投資硬體以彌補軟體的缺陷...
對我來說，硬體只是基礎，建立一個效能很好的基礎，而非拿硬體來撐高效能。
軟體的缺陷本身有過經驗，調整架構(系統、網路、DB、硬體等等)後，效能暴增，但能做、想做，或者做這幹嘛，應這麼說，ERP是使用者反應，得知某功能效能不佳，需長時間等待，然後去了解後解決，這樣能體現自我價值，價值為何？上面的人能理解？
>>軟體的品質
>>mainframe 3 ~ 10分鐘不回應
這太久了吧，一般使用者不會請部門主管在開會上大罵系統有問題嗎？提改善需求單，請MIS改善，然後改善業績算在該部門上。
系統上要加速，改系統架構(軟體)，流程變更，有否牽扯到相關人員，資料輸入、要開會討論，相關單位配合與否，改了之後，短中長期的一再確認，是否有資料異常，舊新資料的處理、顯示，報表的顯示....要花太多的心力，再加上變更後，要心驚膽跳，是否有沒考慮到的地方(相關table之多，大家知道的).......如果只是這樣單一工作就算了！同時間手上至少還有十幾個問題待處理，電話剛來三個bug或問題了解中，等一下半小時後，還要開會討論新系統的導入之軟硬體平台規劃，使用者PC有問題，網路和大陸斷線，跟中華電信的經理溝通，說不定上面還覺得你太閒，請你去剪樹，或是去倉庫幫忙整理…哈…年終考評自打100分，還被批鬥...哈
>>系統也必須「容易修改」
自己的理解上是非常充足正確的說明文件，整個系統含DB中所有都有一份正確完整的文件，能夠很容易理解系統，都不能理解系統又如何修改？
有那個ERP是有這樣的文件，通常是跟不上新版的更正，更不用說系統一但進入企業後，大量的修改，內部對文件的管控上，根本是不行的，企業也不是軟體公司，一但用幾年後，新人、高手的加入，對現行系統就沒有容易修改的條件了。(自動產的文件，是有看沒有懂，列幾個method、class、function...看取名...別鬧了，註解??!!ERP的問題有時候怎麼說明，放上幾千的文字說明??!!)
軟體品質：就本身的了解，OO 到後來的多重繼承會死人，追很麻煩，改更是麻煩，overwrite overload，更是亂七八糟，這一塊那一塊，所以又有新的理論，但有一堆先人死在灘上了！不是指OO不好。自動測試.....在一個上述環境中，那來的自動測試，我還真的沒看過，ERP系統廠商，要求或教學企業內部在開發軟體時，要做自動測試，連最基本本的版本控制都沒有，還在用 copy file加上年月日的...自動測試也有很大的問題，那請“人“測試這塊更是也沒有，開發、測試、正式資料不一致，怎麼測(好佳在現在有snap shot)，但資料一致，又會有資安問題......
快速開發ror之流，是很好(個人的偏見，多年下來的)，但登不上大雅之堂，效能....開外掛.....嘆.......
UML之類的...................開會中定use case會不會就在吵了(會用其實蠻好用的)
彈性好效能肯定比寫死差，這很容易理解的。jvm到處跑，效能就差(現在java效能好多了)。更不論寫程式時，規劃上想彈性...可讀性....都是 相較下較低的效能，單就for迴圈 寫死和彈性 效能就有差了！
系統UserInterface這塊，也沒有多人在意，指的是真正的UI，而不是幾個做幾十年的老員工，一句這樣才是對的.....就搞定，ERP單單鍵盤組和滑鼠組就有得吵了，要都相通？！企業內部修改之後，又有誰會去上個UI課程，找個UI高手，建立UI知識庫，仔細把UI做好，Web和win32的控制又不同。 通常最簡單的做法是，老闆說：請按新ERP操作，誰敢不配合，直接砍頭滾蛋，殺老臣，殺菜鳥，殺到員工都說好用，用久了，誰又記得什麼dos，什麼鍵盤，什麼...還有什麼，不過那個barcode輸入或RFID，確實能加速輸入，避免錯誤。
還有一個，bug trace.........................嘆！.......嘆！..........嘆！...........這不是報修單.......
個人非常喜歡 約耳 ，但自己真正能做到又有多少。
總而言之，都是在改，為什麼不找一套從頭到尾能改，把錢燒在刀口上的，燒在改上，這是多年下來的心得。
個人積分：15分
文章編號：52535758
SGR 0418 wrote:
這應該很難嫌錢不夠多...(恕刪)
結論
（丙）具職業道德的民營企業或政府公務員的MIS主管，心中應無時不刻以企業或人民的利益為最高優先。
的原意並非主張白領打工仔要為其雇主或百姓自我犧牲、無私奉獻。而是簡單的：MIS主管應展現其專業，對等貢獻給其雇主或百姓支付給他的薪酬。
引用Goggle的銘言：
在ERP用戶端公司員工的的心態是 能說服老闆用大廠erp就盡量用
有大廠erp專案經驗 ， 未來對轉職有很大的關係
以及
www.gretai.org.tw/storage/csr/negative/西門子的行賄事件.doc
以及42#樓「多年心得」的銘言。
古諺：「君子愛財，取之有道」。
更直白些：MIS主管宜堅守道德的底線，勿犧牲股東或人民的利益而自肥。
欲知者，至此，應該已知。其餘，不打算在專業主題繼續深入申論哲學領域的議題。
個人積分：8分
文章編號：52536828
企業的核心在於「經營」
ERP是個為了增進「經營」效率的「工具」
水能載舟，亦能覆舟
「經營」的方向錯了，「工具」再好也沒有用
而用「工具」的人，他的觀念不對，那「工具」再好也沒有用
我本身資歷尚淺，經歷過的案子跟樓主相比都是小巫見大巫，
但用在中小企業應該都還算適用。
在ERP廠商內，顧問、業務、工程師都需要同時處理數個客戶。
我確信一樣的系統，有良好的溝通、談判、引導能力，最後可以點石成金，讓「工具」變得有價值。
我遇過高階抗拒長達一年，最後高階一走馬上行雲流水，運作順暢。
我遇過系統做出去使用者覺得不能用，最後中間接手，重理需求，畫出流程與規劃，重新將工程師與使用者的橋樑接上，最後與使用者討論增加一些預算，都加當初的規劃，成為能夠使用，到現在三年了也沒有異動且使用頻率高的模組。
我遇過為了當初使用者要求的價格，東砍西切功能的一套系統，變成不像樣的系統，我中途接手，在付了兩年的維護費後，他們換了系統，我思考的是為何要這樣賣一套系統出去，為了成交嗎？
我從工程師出身，再轉顧問，最後接上業務，就是秉持著為企業做最好規劃、為團隊做好的接單的原則在與客戶溝通，帶著這樣的心態，加上本身也是自製ERP的廠商，所以要更動只要經過幾位核心設計者的討論，確認影響事項與成本即可，幾乎沒有什麼不能達成的功能。
系統好不好用，我的認知上是很難判定，使用者百百種，也許可以受大部分人肯定，但要每一個人都肯定那是不可能的。
樓主的經驗非常多，資料整理也完備，非常具有參考價值，感謝您的分享！
SGR 0418 wrote:
這應該很難嫌錢不夠多...(恕刪)
個人積分：15分
文章編號：52537423
希望你的上級能早日發現：你是貴公司的寶貴資產。祝福你！
(相關table之多，大家知道的)
我的系統還好。製造業只有250個table（當然，也可以把它解釋成不夠完整），智慧財產權事務所資訊系統只有180個table。
.......如果只是這樣單一工作就算了！同時間手上至少還有十幾個問題待處理，電話剛來三個bug或問題了解中，等一下半小時後，還要開會討論新系統的導入之軟硬體平台規劃，使用者PC有問題，網路和大陸斷線，跟中華電信的經理溝通，說不定上面還覺得你太閒，請你去剪樹，或是去倉庫幫忙整理…哈…年終考評自打100分，還被批鬥...哈
看來，你也是拼命三郎。等你忙完以後，也許我們可以來研究一下合作的可能性？
自己的理解上是非常充足正確的說明文件，整個系統含DB中所有都有一份正確完整的文件，能夠很容易理解系統，都不能理解系統又如何修改？
這個要求一點都不過份。
有那個ERP是有這樣的文件我的ERP剛好有這樣的文件。
，通常是跟不上新版的更正，還好。情況不是很嚴重。
ERP的問題有時候怎麼說明，放上幾千的文字說明??!!)盡力而已。我是把文件的加註放在這些地方：
* 資料庫的table、column、stored procedure
* Server和client
* 使用手冊
* 線上Help：畫面用途說明、欄位用途說明、stored proecdure用途與執行參數說明、報表用途與參數說明
每一則說明放在5120 byte的欄位空間，暫時夠用。
軟體品質：就本身的了解，OO 到後來的多重繼承會死人，追很麻煩，改更是麻煩，我的系統還沒有用到多重繼承。
overwrite overload，更是亂七八糟，這一塊那一塊，所以又有新的理論，但有一堆先人死在灘上了！不是指OO不好。記憶中，我的系統還沒有用到overwrite和overload。
自動測試.....在一個上述環境中，那來的自動測試，我還真的沒看過，ERP系統廠商，要求或教學企業內部在開發軟體時，要做自動測試羞愧！ERP的regression test這東西對我來說也是太高深了，所以也沒做過。只做過效能（performance）測試。
彈性好效能肯定比寫死差，這很容易理解的。這我也能理解。IF ... THEN .. ELSE .. END多的軟體跑不快。
不過，大家不可以故意忽略市面上的一款只賣給現金滿滿的頂級企業，「彈性最好」、「best company」才能「run」的頂級萬能ERP，其開關成千上萬。
「開關」是甚麼東西？就是：使用人要勾選這個選項、不要勾選那個選項那種機制：
* 這裏要輸入代碼『X』、那裏設定『Y』代碼。
* 如果勾選『選項A』，則要記得千萬不要勾選『選項B』、『選項C』和『選項D』，否則會有預料不到的效果。
* 而且，如果沒有勾選『選項C』，則『功能P』會被啟動而且『功能Q』會失效
也就是要另外付費請國際級的ERP流程顧問開班訓練的「流程調校」高科技，一種把軟體與企業管理科學融合的高深技術，一門大學沒有教的獨門高級課程。
jvm到處跑，效能就差(現在java效能好多了)。
我的系統是用compile過後才能跑的C++開發的。
更不論寫程式時，規劃上想彈性...可讀性....都是 相較下較低的效能，單就for迴圈 寫死和彈性 效能就有差了！就我所知，要衝高寫死的套裝軟體的彈性、讓它能滿足各行各業的萬能ERP，唯一辦法就是設計開關。開關多，則效能低、MIS人員難維護、使用人難以「正確使用」。
因為我的製造業ERP的開關數目可能少於10個，所以，它是一套小系統。不過，大企業應該很合用。
而且，全部的原始碼加中、英文手冊，含一些畫面截圖（.PNG）檔，壓縮後小於5MB。
總而言之，都是在改，為什麼不找一套從頭到尾能改，把錢燒在刀口上的，燒在改上，這是多年下來的心得。不能同意更多。
個人積分：15分
文章編號：52537612
個人積分：15分
文章編號：52582231
用友NC用戶心中永遠的痛，U9拭目以待
本人在IT行業從事企業信息化工作十幾年，曾經是用友的客戶，也在用友工作若干年，經歷頗多，感觸更深，作為國內ERP軟件供應商的龍頭老大用友，其高端拳頭產品NC成為我心中永遠的痛。
引子：裘皮大衣的故事
開始用友為我描繪了一個美好的願景，說為我定做一件“裘皮大衣”;簽約後告訴我只能為您做件“襯衣”，也好；調研結束後告訴我只能給件“背心”，貼心,也還好；實施開始說：還是給您一條“內褲”吧，苦笑；等初步驗收時變成了一雙“襪子”，嗨，襪子也勉強；上線後發現只剩一只“襪子”了，無語！！！
–– 某NC客戶項目負責人
NC的管理模式：用友NC“綁架”了客戶
NC的集團管理模式管理僵硬，反映遲緩。集團企業一旦應用了NC，就好比遭到NC的“綁架”，失去了管理個性，已成為用戶心中永遠的痛。
管理僵硬：NC無法支持跨分子公司的矩陣式管理
當中國集團企業將信息化眼光從集團財務邁向集團經營管理的時候，總部將更多地面臨原材料集中採購、跨區域聯合倉儲、多工廠協同生產、統一銷售和網絡化、全國聯保服務等多元化經營的價值鏈整合，基于公司治理結構之上的集團總部，不僅要沿著責任中心體系考察下屬單位的業績，而且要沿著產品和業務線考察經營領域的競爭力，在全集團推行矩陣式管理。
NC單一的公司目錄式的組織架構體系，沒有人力資源組織概念，績效考核從屬于公司，無法實現不同公司的員工對同一下級進行矩陣考核，無法實現同一員工對不同公司的下級進行矩陣考核，無法實現跨分子公司的薪酬計發。
NC在V5.0後才匆匆增加了業務組織，但不能定義業務組織層級關系，業務組織只能從屬一個公司而不能委託多個公司進行費用自動結算，供應商、物料信息只能從屬財務組織，這種落後的“業務從屬財務”的管理模式不能適應業務線矩陣管理。
反應遲緩：NC無法應對集團的戰略變革
面臨集團管控模式、組織架構的不斷變化，NC在大力推行成熟管理模式之外，閉口不談如何響應變革，是視野所限還是視而不見？
1、NC不能響應集團管控模式變革
對于一個多元化經營的集團，NC對科目的控制策略只能針對整張科目表統一定義控制級次，不能針對個別科目靈活制定控制方式；對客商等基礎檔案，沒有統一定義控制策略的功能。這樣模糊的集團管控策略設計如何能響應管控模式的變革？
2、NC不能響應集團組織變革
集團資源整合會帶來業務部門的整合，集團營銷公司、集中採購平台、集團物流中心應變而生。面臨跨分子公司業務組織體系的變革，NC只能通過新建賬套、重新實施來完成，難以實現組織變革的平滑升級，也無法做到業務線的分層逐級管理，完全違背了集團整合業務資源的初衷。
NC的技術：UAP先天愚型，扶不起的“阿斗”
用友在SAP、Oracle、Kingdee等陸續推出平台後，迫于市場壓力，倉促包裝系統管理工具為UAP“平台”。此時NC已經推出4年，NC並非在UAP上實現，先建房子再搭框架可想而知，一個1級“地震”也能震跨整個系統。
NC在2006年之前的應用服務器一直是使用免費開源產品，NC V5.0之後開始使用IBM WebSphere，成為IBM WebSphere的代理商。終究是擺脫不了沒有核心技術的尷尬：
1 項目的累加開發，零散編程，已經無法重構，每次升級都是推倒重來；
2 大量應用使用內存，網絡傳輸數據沒做“虛模式”處理，內存佔用巨大；
3 支持JAVA1.3和JAVA1.4，但並沒有遵循J2EE（JavaEE5.0）標準，系統兼容性、擴展性和可升級性很差；
4 完全依賴服務器的處理，性能奇差無比
5 使用HTTP傳輸協議，沒有加密壓縮，安全級別很低；
案例：天音控股（NC在用客戶的苦惱）
2002年簽約NC，經過大量的二次開發之後勉強上線，客戶陷入了兩難得境界：
1、一個客戶兩套應用：一套是有大量二次開發的NC3.0，一套是NC5.0，技術架構上的缺陷導致無法升級、無法集成，形成信息孤島；
2、NC的性能非常糟糕，服務器經常癱瘓，客戶端出現“灰屏”，不得不“創造”出分時段使用NC方式：今天A分公司上午之前使用，B公司下午使用；明天C公司上午使用，D公司下午使用。即便採取這種方式，服務器每天還是需要重新啟動
NC發展史：新三年、舊三年、縫縫補補又三年，蒙了客戶近10年
【新三年】
NC產品的起源為“中國海洋石油總公司”財務系統的定制開發，由于客戶的需求主要是財務系統，因此NC初期的設計僅局限于財務的總賬和報表應用。
【舊三年】
捉襟見肘的財務系統，已無法滿足集團化管控，所以只好大舉收購：
1、 收購“恆信譽華”的網絡報表產品
2、 收購“匯理公司”的資金產品（其創始人王浩明擔任資金業務負責人）
3、 收購“開元通寶”的BI產品（其創始人邱創擔任BPM和預算業務負責人）
4、 收購“BAAN”生產制造產品
5、 收購“朔望”的HR產品（其創始人陳諫擔任HR業務負責人）
勉強拼湊了一套所謂的NC管控系統，無法實現“協同商務、集中管理”
補充說明：目前NC產品的核心架構師王浩明、邱創、陳諫等人已離開用友，造成NC發展緩慢、停止不前。
【縫縫補補又三年】
由于先天缺乏集團管控的整體規劃，只好無奈的繼續縫縫補補：
1、補功能：將若幹客戶的功能簡單疊加，導致系統的臃腫、肥大
2、補整合：將若幹異構系統簡單拼湊，導致用戶重復登錄、數據多處管理、數據不統一
3、補“平台”：將系統管理工具美化包裝成UAP
造成NC維護復雜、運行緩慢、效率低下。
【蒙了客戶近十年】
事實的真相是，大批的NC客戶還只使用了一些簡單的總賬、報表系統，對于集團管控的資金、預算、供應鏈等系統尚未使用，根本談不上集團管控。
例如：南京大賀廣告、廣東省國土資源廳、北京江河幕牆、完達山乳業、雨潤集團、南京中脈集團、一致藥業、金鷹國際……包括最初的原型客戶中海油集團也早已拋棄了NC系統。
NC無法回避的曲線：軟件產品的生命週期曲線
用友已將大批NC研發人員轉向U9的開發，以彌補NC在多組織架構、多工廠制造等方面的嚴重缺陷。
2006年12月21日發布NC V5.0後，歷時一年半，目前僅發版V5.02，也可以看出NC產品進入了維護階段，後續投入乏力。(2008年6月下旬用友將跳躍式發布V5.5版本)。
于是NC從07年下半年開始“大跳水”、“報低價”、甚至“不要錢”。
NC大跳水：上海華宇集團
用友NC報價大跳水從500萬（含硬件）降到80萬，結果還是輸給了別的軟件供應商，而且簽約高達400萬。
NC報低價：金漢斯餐飲連鎖
用友報價不到100萬，某國內另外一個供應商報價650萬，結果用友NC輸了。
NC不要錢：特力集團（股票代碼：000025，NC老客戶）
用友公司提出免費升級到NC最新版本，並承諾除2.7萬服務費/年外無其他收費；客戶評價用友不重視服務、NC技術過時，而且預算系統不能滿足需求，經慎重考慮後選擇了國內的別的軟件供應商，重新上一個系統。
結論：NC是淘汰產品
那麼用友投入大量人力和費用的U9會將會是一個什麼樣的未來呢？援引IT專家網的一篇文章與大家分享。
用友U9新生 軟件市場下一步該怎麼辦？
作者: 阿朱, 出處:IT168,責任編輯: 王炎,
2008-04-30 13:05
在國內做管理軟件的，用友就是一個標桿。用友有U8，金蝶就有K3;用友有NC，金蝶就有EAS。用友有“通”系列，金蝶就有KIS。
時代在發展，曾經輝煌的管理軟件行業成了沒有人關注的壁花。大家都在關注互聯網，關注嵌入式，關注PPG哄孩子，關注阿裡巴巴和垂直行業網，關注如家分眾橡果國際，關注網遊、搜索、地圖、QQ，關注通信手機3G。阿裡軟件橫空出世，Salsforce打起SAAS，頓時讓過慣了即定遊戲規則的管理軟件大佬一下子不知道怎麼玩了。
中小企業曾經是塊最難啃的肉。沒有錢投資軟件硬件，沒有錢雇傭IT維護人員，雖數量眾多卻失之無味棄之可惜。阿裡攜商品展示、溝通(IM、郵件、短信)、支付、營銷群發、商機搜索、社區交流、廣告營銷、口碑營銷、誠信評價、銷售管理、市場營銷管理、客戶管理、客戶聯系歷史、客戶回訪、事務提醒、客戶訂單過程管理、財務管理、採購管理、庫存管理、文檔管理、企業域名、企業郵箱、企業WEB全套SAAS打了用友們的陣營。憑借阿裡巴巴和淘寶數以千萬的客戶，和阿裡集團的強大宣傳和運營團隊，還有阿裡最重要的支付安全而帶來的數據信任，一舉把用友們多年沒有解決的問題突然攻克，並且迅速佔領了大量中小企業信息化市場份額。也讓那些國內單槍幹的程序員兄弟們的生意帶來了很大的衝擊，原想拉幾個小客戶，賣個600、1000或7000塊，這會生意也慢慢不行了。
用友看在眼裡，饞在心上。但阿裡具備誰也不具備的數據誠信優勢，所以其他人幹看也吃不了。還得想想在自己優勢的中大企業怎麼站好腳，別讓阿裡抽底，SAP削頂。
于是，U9出世。
用友就是中國管理軟件行當的標桿。每個從事管理軟件的都得看看老大是怎麼做產品的。我也是抱著這個心態時時跟蹤U9的。
管理軟件，技術門檻並不高。其突出特點就是：需求不斷，每個企業都不願意和別人一樣。管理軟件，說到本質，還是管理思想的落地。只有保持差異化的管理思想，才能保證差異化的競爭。尤其每個企業面臨的內部外部環境都不相同，面臨的問題，目前的競爭地位，過去的歷史包袱，現在的人的利益平衡，未來的走向，都決定了一個企業肯定與另一個企業不相同，所以落實到管理軟件肯定是不相同的。(當然，你可以騙企業你是最先進的管理思想。不過這個吹法已經過時，都在商界江湖混了N年的，玩錢玩人玩術玩銷售多年的老板，你以為他們就是不懂現在信息化的原始人?當然，你也可以宣傳你這是模仿SAP做的，你這是模仿歐洲美國做的。但是現在老板們都清楚，中國和外國不一樣，從人的思想層次到經濟發展到外部經濟幹預，都需要立足現狀，而不能趕英超美。過去大躍進，每個老板都記得)需求不斷，是咨詢顧問缺乏的惡果。但是，軟件公司擅長的是制作軟件，而非咨詢。如果非要在咨詢和軟件都雙頭並進，那麼還沒有那麼多資源做，而且也不專業，不符合現代企業特征。就連世界管理軟件老大SAP都專業做軟件，合作伙伴做IT咨詢，如IBM、埃森哲、德勤，而IT的安裝、軟件操作培訓、軟件二次開發、軟件支持，還得分到東軟之類的集成商手裡。這也就是王文京愛將高少義出走創辦IT咨詢公司，都是順應發展潮流。(高少義出身軍人，管理強悍，當然銷售也強悍。曾經負責U8事業部，後來做華東市場。高在用友的影響力，非常類似三國關羽，而王文京又極為類似劉備。王文京對這位兄弟是又愛又恨又沒有辦法，于是請來何經華。何也管不了高，每每決議都是華東市場除外。最後，還是王文京杯酒釋兵權，給高投資創立公司，送走了高爺。當然，高爺還是代理銷售用友的系統、IT咨詢、實施。估計定制化和支持不管。這兩塊既不肥又麻煩。估計高以後會涉入)。
時代要求產業鏈必須分工合作了，所以才有了王文京的制造軟件，高少義的軟件服務。而且，現在的客戶，也不是U8 10年研發那樣規模小經營單一，要不是U8在這快10年中不斷被內部重構，甚至在高的領導下重寫了U8，U8早就無法承載用友這個每年需要幾億資金才能讓財務報表好看的大航母。(當時何經華無奈而走，高覺得自己能挑起未來大梁。U8，小菜，我過去不是管理U8事業部麼，我也懂研發。如今U8家架構老化，我還能讓它跟上新時代。所以U8架構重新用新架構思想新技術開發。當然，思路是好的。無奈高的技術眼光還停留在過去的U8架構思路，當然U8重寫也不能變動太大，還有平滑升級的問題。所以，動用了直到現在還沒有推廣開的XAML/WPF技術。做了一個能兼容過去，也不至于過去包袱太重的新U8產品。但新U8產品出來後並沒有什麼大起色，讓高感覺大勢已去，統管一個事業部，從研發到銷售，而且還能面向未來領導，高覺得自己已經不適合時代了。于是自己專注做好一方面，軟件制作或服務，挑一個，高挑了後者)。
從以上來看，承擔下一個要將用友推到突破10億銷售收入的地位，U8的下一代，U9，必須具備以下特點：
(1) 用戶企業規模已經比10年前大得多，需求也當然要比U8復雜的多。
(2) 軟件制造和軟件服務必須分開了，專業化發展，產業鏈協作。
要能滿足這兩個條件，一個堅實的軟件架構是必須的。
王文京知道U8輝煌了這麼多年，不可能把用友帶到下一個10年。所以未來10年，用友要想10個億，100個億，就需要一個很重量級的，能代表未來10年技術和應用趨勢的產品。
當然，王文京也吃過研發虧。當年王文京另外一個愛將邵凱受命研發面向大型企業，能夠集團運行，能夠在網上運行，能夠和SAP抗衡的產品，那就是一定要是中間件、要是JAVA的NC。NC的研發，時機不當，落地也不當。但那個時期的人們都已經瘋狂。為什麼?因為那時候是1999年，互聯網讓大家都迷失了方向。大量程序員出走用友去創業，大量企業爭先恐後給自己打.com的標簽。互聯網經濟似乎顛覆了一切，就連老江湖柳傳志都動搖了，上了FM365。邵凱受命後，立即打造核心團隊，全國搜找行內老手。邵凱確實找到了幾個從管理、到閱歷、到業務、到運作、到技術開發都很在行的人。但可惜致命的有兩個地方：1 當時大家都被互聯網速度衝昏頭腦大幹快幹，而且當時軟件工程也不太流行，設計模式也沒有火起來，于是就打算在鳳凰嶺封閉3個月就可以OK(事實上，一個重量級的想和SAP抗衡的產品不是這樣能出來的)。 2 當時大家根本就沒想到用啥大型架構，還按照過去U8的架構走，其實當時在國外中間件已經流行，各種大型企業架構已經流行，但中國還未流行。很多NC團隊的人都是過去開發VB之類產品的人，對大型企業架構都不是特別理解，覺得U8的架構就應該可以了。但樊冠軍的出現讓大家第一次認識到大型架構模型。而樊當時是從和佳(還是佳軟，忘了，都是老牌的管理軟件商)跳過來的。樊並沒有用這套架構作過真實的一個大型產品，也沒有完整的主導經歷過一個大型產品的生命週期。但是團隊其他人都沒什麼大型架構經驗，樊就成了這方面的權威了。大家一看他的架構確實好，而且確實代表未來，就決定用了。但那時候，樊做的架構其實質是一個3000多行代碼的DEMO原形演示。而一個真正產品需要的接受過各種復雜企業需求考驗的大型架構，樊還沒有經驗。
而且當時大家已經封閉了，很多人都聚在一起天天設計業務和表結構了。而且，1999年的JAVA，大家都知道，從JAVA本身到開發工具本身都還不是太利索，如果2001年開發，情況就會好很多。但就是各種陰差陽錯，NC就上路了。
我想，直到現在，王文京也對NC很是戚戚然。雖然，中間件成熟了，JAVA成熟了，開發工具成熟了，設計模式成熟了，大型軟件工程成熟了，但NC架構已經定型了，只能這麼繼續走了。NC在用友內部很多年都被稱為就會花錢不會賺錢的雞肋，老遭U8事業部的人看不起，因為用友大部分收入還是U8支撐的。但NC不斷艱難堅持，也變的越來越好了，唉，起了個大早，趕了個晚集。邵凱經過這麼一遭，也深深反省自己在軟件工程管理上的問題，于是他接手了用友軟件工程公司，這個公司專門做外包，是非常講究軟件工程的。邵凱就是希望能取取經，看看人家外國人是怎麼管理的。當然，現在管理軟件公司做外包，沒有一個成氣候的，用友也把外包公司脫離了用友軟件，以防影響上市報表成色。
經過NC這一遭，王文京知道這個U9的研發就要沉住氣，不能再走NC老路了。
注重架構、注重軟件工程管理的U9，沒想到這一走就是4年(其實是5年，2003年就有策劃，但實質進展在2004年)。
過去的U8架構，是田榮舉做的。這個管理軟件行業的傳奇人物，出自金算盤。然後用友，然後金蝶，然後又回金算盤，然後又回金蝶，然後又回重慶不知所蹤。田榮舉幾乎給U8、K3都帶來了至少影響10年的架構思想。現在，做管理軟件的，搭建架構，都是借鑑的是田榮舉的思想。而田榮舉在10年前就這麼思考了。可見是高人。
而U9呢，誰來負責?黃濤浮出水面。黃濤，也是出自金算盤(這個公司到底怎麼了?黃埔軍校?)。然後在用友就沒走。在鄭雨林、章培林、楊祉雄、高少義、向奇漢、何經華、黃義璋這些猛人輩出的用友，黃濤並不引入注目。直到U9，才慢慢出現在媒體坊間。
黃濤這次是真沉住了氣。經歷了這麼長的中國管理軟件發展，黃濤知道管理軟件研發的每一個核心點。管理軟件，首先是管理。沒有一整套完整的先進的管理體系(而不是功能)，管理軟件只能成為電子化工具，成為跟隨客戶需求的一個工具，而無法幫助企業提升管理。
所以，黃濤一開始就大力招聘業務專家。他實行交叉管理模式。按職能分：架構平台組、開發管理組、業務功能設計組、數據庫設計組、測試組、文檔組、UI組。按系統又交叉分為：財務、生產、OA、HR等等。真正按照流水線生產方式來生產。
而在架構上呢?黃濤的設計又比田榮舉10年前的設計高出哪些呢?
我也不是用友人，所以我也拿不到更詳細的材料(這是管理軟件行當的一個淺規則，管理軟件廠商很少在網站上詳細介紹產品，如果你真是企業，想用他們的產品，可以電話咨詢，銷售人員會跟進遞送資料)。
從我手上的這份U9宣傳手冊來看，U9的架構並沒有多大改進。
U8架構的時代，還沒有面向組件。而現在面向組件已經走進了面向服務時代。COM/COM+已經由于是WIN32時代，.NET時代屏蔽了COM，而且COM也無法穿透防火牆，現在都互聯網普及了，上下遊需要整合了，必須穿透內部防火牆走向外部EAI。所以，開發WebService業務組件是必須的。和U8比，當然比U8強很多，U8連面向組件都沒有趕上，而U9直接跳過面向組件，走向面向服務。所以，U9一直號稱自己是第一款原生SOA管理軟件。
SOA是個基礎技術。重要的是看U9架構。
其實，作為管理軟件的架構，其實是比較簡單的技術。大致相同。所以從U9，到SAP Netwear，都差不多思路。管理軟件最主要的成功門檻還是管理思想、項目質量、項目進度、項目文檔、項目大規模團隊組織協調、咨詢滲透、專業培訓。管理軟件最主要的技術門檻還是在于海量數據存取，但性能受業務需求、功能設計、數據庫設計、代碼開發多種因素影響，所以需要在各個層面去調節。我過去做架構師的時候，由于數據庫產品有些BUG補丁沒有出來，由于OS有些BUG，由于COM+有些BUG，還有開發工具對于COM+和ADO支持上有些BUG，所以被性能弄的很是麻煩，整天在客戶機房蹲守檢測CPU、內存、I/O、線程、池化、連接數、事務並發。
我也是做管理軟件架構的，所以在這裡給大家講講一個管理軟件的一般架構思想。一個架構的作用：
(1) 業務程序員少寫代碼就能實現業務功能
(2) 有了需求來，也好定制修改
(3) 也穩定
(4) 性能也高
(5) 部署和支持也方便
(6) 安全性也高
為了實現這些目標，所以我們需要具備以下這些組件設施：
(1)登陸用戶口令驗證、license許可驗證、盜版驗證、過期失效驗證、版本差異驗證。
(2)主控台 用戶功能樹 管理主控台。
(3)表單設計器、業務實體設計器、工作流設計器、報表設計器、功能菜單設計器、多語言設計器、多皮膚設計器、查詢過濾定制器。
(4) UI框架：Grid/Toob bar/Tree/TabSheet/Menubar/參照錄入組件/Edit/Button/Combo之類。
(5) 單實體輸入框架、主從List/Detail輸入框架。
(6)運行配置參數設置、單號計數器、業務預警設置。
(7)異常框架、業務實體權限框架、業務實體存儲引擎、業務實體查詢引擎。
(8)報表：套打、單據報表、普通二維查詢統計報表、交叉報表、圖表。
(9)工作流引擎、消息引擎、自動任務引擎。
(10)企業組織結構設計工具、權限分配工具、數據導入導出工具、數據備份恢復工具、升級更新工具、錯誤診斷跟蹤工具、性能監測工具、日志查看工具。
(11)OFFICE集成、BO集成、通信集成、郵件集成、短信集成、IM集成、搜索集成、電子商務集成、企業門戶集成等等一切外圍集成。
有了這些基礎，就可以在其上開發業務模塊了。一般，讓業務開發人員能夠順利開發業務組件並且能順利插入這個平台去運行，還需要有Example、Docs、IDE。這樣，在IDE中，自動就能查到所能調用的公共業務類庫命名空間的成員，也能有幫助文檔知道如何使用，更有Example代碼，幾乎修改一下就能用。于是，幾乎，業務人員不需要直接使用VS之類的開發工具。如果確實做不了，平台組會擴充平台功能。如果平台也不很好的完成，就需要平台組來分解需求抽象需求僅提供公共功能API，然後讓業務人員調用API，適當使用VS工具，但都容易很多，開發的速度、質量穩定、性能都不錯。
沒有平台，高手低手都混在一起，開發的功能模塊有的強有的弱，有的很好擴展很好修改原代碼也很好理解性能也不錯質量也不錯，有的代碼一團漿糊BUG百出幾乎無法下手修改，整體質量無法保證。有了平台，就讓能力高的開發平台，讓能力低的去使用平台。畢竟，我們能招到的高手不多，而且成本高，大部分都是資質平凡的一般程序員。如果整體成功，就需要搭配各施其職。
我看這次U9引入了DSL這個新技術。這也是我10多年一直摸索的，但卻沒有成果的。如今，Google和Ruby給了我很多思路。Google的REST、JSON、JAVASCRIPT，能夠實現比BEPL廣泛的Mashup，也比JAVA要輕量級。而Ruby更是引入真正的DSL腳本，像在編寫遊戲腳本一樣。如果我們沒有DSL，我們必須用JAVA這類原生重型語言操刀，這就難為業務開發人員了。
我們並不期望DSL給客戶的IT維護人員用，但至少也不希望業務開發人員去全面深入的學習JAVA或C#，大家都知道現在各種框架越來越大，各種類庫越來越大。讓一個資質平凡的程序員去學習這些東西還要能開發，那上手需要多慢，培訓成本需要多高。
但是，從U9在媒體透露出來的各種消息來看，U9現在已經完成的業務模塊比較少，應該是財務、供應鏈、OA、HR這四部分(有沒有生產管理、質量管理、CRM、物流倉儲?沒看到宣傳內容)。其實要做ERP，就必須從CAD設計到產品數據管理到物料清單、採購、供應鏈、生產排程、倉儲管理、生產成本管理、質量管理、物流、銷售管理、市場管理、服務管理、客戶管理、商業智能、企業OA、人力資源都得需要(不熟悉ERP構成的可以學習這些完整的ERP鏈，SAP基本業務套件[行業解決方案除外]也不外乎這些)。
四年，聽說用友每年投資1個億研發，U9研發甚至動用了600-800研發人員，堪稱國內第一單產品動用人數最多的完成這麼點，而且從看到的資料，UI和功能細節上都不能讓人信服這是一個研發了四年的產品。我個人猜想，估計還是NC的兩個錯誤：
1. 技術的不成熟，從.NET/WPF/WCF/WF，想實現的架構底層技術不支撐。
2.軟件工程管理的不成熟。
其實還有第三點：管理思想和業務細節。
黃濤過去一直做技術方面，這次統領產品大局，研發時間之久卻業務模塊出的少，很有可能和我估計的第三個軟肋有關(用友一直封鎖消息做的很好，具體我不清楚，我只作為門外漢猜測而已)。
U9不斷跳票，從王文京說的2006，跳到2007，然後是2007年底，然後是2008年3月。希望U9在今年上半年能夠正式發版(編者注：2008年4月18日，用友U9正式發布)。
U9是又起早了呢，還是正好。不管怎樣，管理軟件行當都想看到未來的標桿是什麼樣?
個人積分：15分
文章編號：52601578
末學在此恭請苟同這些武斷：
（1）ERP專案的失敗主因是ERP軟體的品質不良
（2）ERP產業離完美仍相當遙遠，必須改善
，而且自認為英雄的各路豪傑，齊力改善ERP產業的不完美。
期望：
（1）一方面，幫助進退兩難、騎虎難下的ERP用戶脫離困境，
（2）另一方面，設法獲取心安理得之正當收入。
我當然也瞭解：迄今為止，ERP品質從未與ERP市場佔有率連動過，ERP市場早已被各路互利共生鍊分食得差不多。所以，也不排除期望等於幻想的可能。
但是，我也深信互利共生鍊終究有其不能的一面：用劣質ERP四處強迫灌食現金滿溢、好高騖遠、病急亂投醫的企業，則或早或晚，終有一些營收不敵揮霍、因劣藥併發副作用而倒下來，突然想到必須另覓良醫的一日。
也就是說，我能想到的唯一機會是：經年累月不滿意ERP品質的用戶。即進退兩難、騎虎難下，股東無法繼續容忍MIS部門吃垮財務、令公司經營陷入危機的ERP用戶，包括電力公司、菸酒公司、股票#6116等。
前文已清楚列舉的國內外大型的ERP專案失敗實例指出：問題應該不是有、無重病患者，而是：
（1）醫院有無能力招攬病患住院？
（2）醫療團隊有無能力醫治患者？
我只是一個人，猶如一隻渺小的螞蟻面對大象群，需要各路英雄豪傑的帶領、提攜。（我沒有錢，也不是在找錢。而且相信：金錢在ERP這個產業的作用不大。）
個人積分：1294分
文章編號：52612750
但歷史上，能成功導入外來學說(ERP系統)而富國強軍，統一天下的，也只有秦國導入的法家學說。其他家為何失敗?? 簡單來說既得利益者(貴族或資深高層員工)是推動改革變法的最大阻礙，而導入顧問有沒有辦法親身實踐自家學說(自家ERP真的完美好用嗎?)，沒有思考轉變方式與讓利(釋放因改變而獲得的利益)給多數人(多數百姓或多數員工)，反而只有集中利益給統治階層(君主或董事會)，那變法失敗就是必然的結果。
要成功導入新系統，要從更高層次的戰略目標來看待...
個人積分：993分
文章編號：52638960
