http://www.nipei.com/article/3116
本人在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是又起早了呢，還是正好。不管怎樣，管理軟件行當都想看到未來的標桿是什麼樣?
本人在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是又起早了呢，還是正好。不管怎樣，管理軟件行當都想看到未來的標桿是什麼樣?
留言
張貼留言