0 前言
“已有的研究表明，不像人們想象的那樣，復(fù)雜系統(tǒng)一定都要有很大的規(guī)模，都要由大量的元件組成......但是引起系統(tǒng)復(fù)雜行為的主要原因并不是元件的數(shù)量，而是元件之間的交互�！边@句話同樣適用企業(yè)信息系統(tǒng)，企業(yè)信息系統(tǒng)的復(fù)雜性是由于不同系統(tǒng)和模塊之間的交互。降低系統(tǒng)復(fù)雜性將使得迭代優(yōu)化非常方便，這將使得系統(tǒng)建設(shè)成功比例的提高，同時也將實現(xiàn)成本的降低。最終會實現(xiàn)讓“使用、構(gòu)建、測試的用戶能夠感到由衷的高興”的美麗架構(gòu)。
從上世紀(jì)90年代開始，企業(yè)架構(gòu)的方法論開始在國際上逐漸得到接受和使用。目前來看，能夠站在全局實施EA的企業(yè)非常的少。一些IT作為其核心競爭力的大公司開始有步驟地全面在展開，如一些世界500強(qiáng)的銀行。而在中國國內(nèi)，由于對于IT價值的認(rèn)識還遠(yuǎn)遠(yuǎn)落后于發(fā)達(dá)國家。這也導(dǎo)致許多方法論的實施無法得到企業(yè)最高層的重視和理解。而企業(yè)架構(gòu)是業(yè)務(wù)戰(zhàn)略流程和IT架構(gòu)的有機(jī)結(jié)合，是IT支撐企業(yè)實現(xiàn)靈活、快速、透明、智能的業(yè)務(wù)方法論。如果沒有最高層的理解和支持，可能變成了畫虎不成反類犬了。對于大而全的企業(yè)架構(gòu)方法論，目前在中國的許多企業(yè)實施會面臨著許多的挑戰(zhàn)，有時這也會帶來不必要的復(fù)雜性。
“根據(jù)我的經(jīng)驗，企業(yè)架構(gòu)的成功一般都和復(fù)雜性相關(guān)。企業(yè)架構(gòu)越復(fù)雜，它成功的可能性就越小。換句話說，你期望企業(yè)架構(gòu)給你帶來的越多，你成功的可能性就越小。” 因此對于許多企業(yè)而言，通過“解耦”實現(xiàn)分而治之，可能更加現(xiàn)實。由于解耦后問題變得簡單，從而可以集中資源實現(xiàn)最大的效果。
企業(yè)架構(gòu)的框架和方法論已經(jīng)有了Zachman、TOGAF、FEA、GARTNER和企業(yè)總體架構(gòu)。目前使用較為廣泛的是TOGAF，它也定義了明確的開發(fā)方法，如圖1所示。狀態(tài)B包括業(yè)務(wù)建模、詳細(xì)業(yè)務(wù)分析和技術(shù)需求文檔。業(yè)務(wù)架構(gòu)在企業(yè)架構(gòu)中是基礎(chǔ)，合理地進(jìn)行業(yè)務(wù)架構(gòu)的分層和分解可以有效地降低后面設(shè)計的復(fù)雜性。
圖1 TOGAF架構(gòu)開發(fā)方法（ADM）
根據(jù)TOGAF標(biāo)準(zhǔn)，狀態(tài)E首先要“把重點放在短期的項目，以此來促進(jìn)長期的項目”。“所以，我們應(yīng)該竭力尋找那些投入少，產(chǎn)出多的項目。這樣的項目大多出自組織的痛處，讓企業(yè)確信采取企業(yè)架構(gòu)策略的最初的地方。”（明確這里的論述來自哪里）但是同時可以發(fā)現(xiàn)，由于方法論中缺少對于復(fù)雜性的分析，很多時候，都陷入了瑣碎的事物中忘記了方向。ADM作為方法論如果能夠有效地結(jié)合降低復(fù)雜性的分析，將會得到可以迭代的少投入、快產(chǎn)出的項目。從而實現(xiàn)可不斷進(jìn)行迭代優(yōu)化，這不但可以保障項目的成功，也符合當(dāng)前市場競爭環(huán)境下的業(yè)務(wù)變化的需求。
貫穿本文的核心觀點是通過迭代的方式降低企業(yè)架構(gòu)實施的復(fù)雜性，從而有效降低風(fēng)險，實現(xiàn)最大的收益。特別需要強(qiáng)調(diào)的是，本文不是完備的方法論，而是對于基本方法論缺少論述的復(fù)雜性的思考及解決方案。具體的EA方法論可以參考TOGAF或者企業(yè)總體架構(gòu)，企業(yè)架構(gòu)的構(gòu)成請參考圖2。
圖2 企業(yè)架構(gòu)的構(gòu)成
本文的組織如下：
第1部分將提出根據(jù)企業(yè)戰(zhàn)略，在最高層次對業(yè)務(wù)進(jìn)行解耦，這里將借鑒企業(yè)精簡架構(gòu)的ABC（自治業(yè)務(wù)能力）的方法論。并且對于汽車行業(yè)以O(shè)TD為例進(jìn)行說明。
第2部分將描述信息架構(gòu)，根據(jù)業(yè)務(wù)架構(gòu)來定義信息架構(gòu)。這里將會涉及到業(yè)務(wù)分層以及主數(shù)據(jù)的分級管理問題的討論。將以企業(yè)生產(chǎn)管理和生產(chǎn)管控系統(tǒng)為例進(jìn)行說明。
第3部分將描述技術(shù)架構(gòu)降低復(fù)雜性的方面。許多企業(yè)在IT技術(shù)方面已經(jīng)投入了許多資金，IT技術(shù)架構(gòu)也可以采用逐漸迭代的方法實現(xiàn)復(fù)雜性的降低。這里也將舉一個小型機(jī)+開放平臺的案例。
第4部分將綜合進(jìn)行分析，討論如何通過迭代的方式讓企業(yè)架構(gòu)方法論離大家不再遙遠(yuǎn)，真正能夠在給企業(yè)帶來最大的價值。
1 業(yè)務(wù)架構(gòu)
對于企業(yè)實施業(yè)務(wù)架構(gòu)，如果開始時就進(jìn)行全業(yè)務(wù)范圍的分析，無疑是沒有必要的。但是這里需要強(qiáng)調(diào)的是，需要在企業(yè)價值鏈層面進(jìn)行第一層次的ABC劃分。然后選擇重點期待研究的業(yè)務(wù)，進(jìn)行第二層的ABC劃分。在第二層中也可以挑選重點領(lǐng)域進(jìn)行深入的ABC劃分。最終實現(xiàn)的目標(biāo)是根據(jù)業(yè)務(wù)重點劃分出具有較為自治的業(yè)務(wù)功能，各業(yè)務(wù)功能之間具有較低的耦合，也即相互之間的信息交換最小化。具體的劃分方法論可以參考《企業(yè)精簡架構(gòu)》一書。
下面舉一個例子來說明如何進(jìn)行業(yè)務(wù)第一層的ABC劃分。對于汽車主機(jī)廠而言，OTD是其核心價值鏈， OTD涉及到的業(yè)務(wù)包括銷售線索管理、需求預(yù)測、訂單管理、產(chǎn)品研發(fā)和制造管理、零件采購與入場物流、生產(chǎn)排產(chǎn)和執(zhí)行、整車物流。OTD的各環(huán)節(jié)及相關(guān)業(yè)務(wù)見圖3。
圖3 汽車OTD流程
由于OTD的復(fù)雜性，因此對于該業(yè)務(wù)必須進(jìn)行詳細(xì)的分析才能夠發(fā)現(xiàn)問題的復(fù)雜性。僅僅從圖3來看，無法發(fā)現(xiàn)各業(yè)務(wù)深層的聯(lián)系，因此我們需要對各業(yè)務(wù)進(jìn)行進(jìn)一步的分解。
圖4 汽車OTD流程層次分解圖
從以上的業(yè)務(wù)關(guān)系來看，可能重新將業(yè)務(wù)分組打包后，業(yè)務(wù)關(guān)系更加明確，見下圖所示。
圖5 重新分組后的關(guān)系圖
從上圖可以看出，重新分組后，每組間的關(guān)聯(lián)性變小，而組內(nèi)的業(yè)務(wù)關(guān)聯(lián)性是較大的。下面將說明重新分組打包后的好處。
1 業(yè)務(wù)耦合降低，職責(zé)明確。如感知與預(yù)測由市場部負(fù)責(zé)，訂單管理與執(zhí)行由銷售部負(fù)責(zé)，生產(chǎn)與采購部分由生管部負(fù)責(zé)。大部分業(yè)務(wù)屬于部門內(nèi)部，業(yè)務(wù)流程清晰明確。
2 由于每個包內(nèi)耦合度較高，包間耦合度較低。因此整體的業(yè)務(wù)優(yōu)化就變成了在滿足外部較少約束前提下的獨立優(yōu)化。這將大大降低業(yè)務(wù)優(yōu)化的復(fù)雜性。
3 系統(tǒng)規(guī)劃時，可以將每個包做成一個系統(tǒng)或者模塊，從而實現(xiàn)了系統(tǒng)之間的解耦。降低了系統(tǒng)之間信息交互的復(fù)雜性。
以上僅僅以O(shè)TD的業(yè)務(wù)流程為例進(jìn)行了分析，并且分析的層次僅限于比較高的層級。如何進(jìn)行業(yè)務(wù)ABC的分解，《企業(yè)精簡架構(gòu)》一書中有著較為嚴(yán)密的定義及方法論。這里需要特別強(qiáng)調(diào)的是，由于各種限制條件（如保護(hù)投資、距離限制）等，不見得能夠完全實現(xiàn)ABC的分解。但是，這里再次強(qiáng)調(diào)，業(yè)務(wù)架構(gòu)是未來系統(tǒng)建設(shè)的前提。如果業(yè)務(wù)架構(gòu)不能夠非常仔細(xì)地推敲，不能夠把業(yè)務(wù)模塊之間的信息流描繪清晰。未來的系統(tǒng)建設(shè)在這個階段就已經(jīng)埋下了隱患。舉例來說，就如汽車各總成系統(tǒng)的關(guān)聯(lián)都沒有分析清晰，就期待能夠做出質(zhì)量和操控感都好的汽車一樣。
2 信息系統(tǒng)架構(gòu)
信息系統(tǒng)架構(gòu)包括了對于應(yīng)用架構(gòu)和數(shù)據(jù)架構(gòu)。這里不再介紹具體的方法論，而是考慮如何在設(shè)計信息系統(tǒng)架構(gòu)時有效地避免復(fù)雜性。在應(yīng)用系統(tǒng)層面將通過分層和配置的方式來簡化應(yīng)用系統(tǒng)，從而可以獲得簡單的架構(gòu)。在數(shù)據(jù)架構(gòu)層面將通過分層主數(shù)據(jù)的思想來考慮我們?nèi)绾蝸砉芾碇鲾?shù)據(jù)。
2.1 應(yīng)用架構(gòu)
來看一個業(yè)務(wù)應(yīng)用場景。企業(yè)從生產(chǎn)/采購計劃開始，到生產(chǎn)/采購管理，以及現(xiàn)場制造的執(zhí)行�？梢詫�(yīng)用系統(tǒng)劃分為兩種模式，如圖6所示：
圖6 生產(chǎn)/采購應(yīng)用系統(tǒng)劃分
左：同一個系統(tǒng)，不同的模塊；右：根據(jù)層次，分為兩個系統(tǒng)
乍一看，好像統(tǒng)一的應(yīng)用系統(tǒng)比較理想。但需要站在業(yè)務(wù)的角度重新思考：
1）計劃和管理的緊急度和執(zhí)行不同。有些企業(yè)的計劃是月度或者周間計劃，有些是每日的計劃。但是生產(chǎn)執(zhí)行的系統(tǒng)其要求的程度是分鐘級別。
2）計算模式不同。生產(chǎn)/采購計劃含有大量的批處理，主要利用的是計算處理能力。而生產(chǎn)/物流的執(zhí)行涉及到大量的信息采集和信號控制，因此需要快速的交互能力。
3）對于不同響應(yīng)級別的系統(tǒng)，其系統(tǒng)需要的高可用和運維級別差異較大。如生產(chǎn)/物流執(zhí)行系統(tǒng)需要實時熱備，而計劃和管理對于一般制造業(yè)而言，具備小時級別的恢復(fù)能力就可以了。
而這里沒有把計劃和管理分開基于兩個模塊的交互信息多，而且其響應(yīng)級別差異不大，因此將其放在同一系統(tǒng)中。在汽車行業(yè)內(nèi)，計劃/管理一般作為MRP系統(tǒng)，而執(zhí)行一般作為MES系統(tǒng)。
談完了系統(tǒng)的分層問題，下面再談?wù)勱P(guān)于實現(xiàn)和配置的復(fù)雜性問題。圖7是一個具體的例子，其中類型是應(yīng)用的類型，實現(xiàn)指具體的系統(tǒng)實現(xiàn)，配置是指對應(yīng)用系統(tǒng)配置完成具體的業(yè)務(wù)功能。圖中上半部分指對于生產(chǎn)線的信息采集和發(fā)送類型的應(yīng)用，經(jīng)過多年的發(fā)展，形成了一個非常復(fù)雜的系統(tǒng)群。這導(dǎo)致了架構(gòu)復(fù)雜，數(shù)據(jù)重復(fù)，管理運維困難，升級困難等問題。
圖7 信息采集應(yīng)用系統(tǒng)
而經(jīng)過分析，發(fā)現(xiàn)這些應(yīng)用系統(tǒng)的基本功能有許多共同之處，發(fā)現(xiàn)系統(tǒng)的類型可以歸結(jié)為信息收集和發(fā)送。通過設(shè)定不同設(shè)備接口的配置，可以實現(xiàn)配置實現(xiàn)對生產(chǎn)現(xiàn)場的信息采集以及控制。因此簡化后的應(yīng)用系統(tǒng)如圖7中的下圖所示。造成這種復(fù)雜性的原因是系統(tǒng)在建設(shè)時缺少統(tǒng)一的規(guī)劃，尤其是缺少未來系統(tǒng)增多時的靈活擴(kuò)展的考慮。最終造成了出現(xiàn)了大量的煙囪。
2.2 數(shù)據(jù)架構(gòu)
在業(yè)務(wù)架構(gòu)進(jìn)行合理劃分以及應(yīng)用系統(tǒng)進(jìn)行有效分層后，許多時候就將一些數(shù)據(jù)應(yīng)該存在的范圍定義下來了。但是企業(yè)內(nèi)部存一些許多系統(tǒng)都會使用到的數(shù)據(jù)，這些數(shù)據(jù)稱之為主數(shù)據(jù)。有的解決方案看起來很美，如下圖：
圖8 主數(shù)據(jù)的管理和使用
但是，對于許多企業(yè)而言，這種做法不見得是最有效的，有時可能就是一個災(zāi)難。而且由于涉及到數(shù)據(jù)的管理流程更多，主數(shù)據(jù)管理又需要獨立的系統(tǒng)，因此有必要考慮一種簡單的主數(shù)據(jù)管理方式。首先考慮HR系統(tǒng)，真的有必要把HR系統(tǒng)的主數(shù)據(jù)獨立于HR的應(yīng)用系統(tǒng)放在主數(shù)據(jù)系統(tǒng)中嗎？同樣對于生產(chǎn)的車型信息放在主數(shù)據(jù)中管理也帶來了較大的復(fù)雜性。因為這些系統(tǒng)只提供數(shù)據(jù)，而且它們的變化速度很慢，外部的系統(tǒng)也不會修改他們的數(shù)據(jù)。他們只要定期將變化點發(fā)送到相關(guān)系統(tǒng)即可。因此借助ESB的概念，利用ESB來定期更新其他系統(tǒng)的數(shù)據(jù)即可，如圖9所示。
圖9 有效利用整合工具來管理主數(shù)據(jù)
此外的一種數(shù)據(jù)，比如對于銀行或者汽車企業(yè)的顧客信息。由于其來源廣，信息的真實性以及信息變化后的更新都有較高的要求，可以借鑒主數(shù)據(jù)管理的流程。但是需要說明的是，可以將同顧客信息緊密相連的應(yīng)用進(jìn)行改造，使得它們變成天然一體的應(yīng)用系統(tǒng)。對于其他需要用到顧客信息的系統(tǒng)可以利用ESB獲取顧客信息以及顧客信息的變化。
《理想的數(shù)據(jù)架構(gòu)的研究和實現(xiàn)》給出的層次模型我比較認(rèn)可，見圖10。但對于主數(shù)據(jù)而言，其實現(xiàn)模型值得商榷。從業(yè)務(wù)架構(gòu)、應(yīng)用架構(gòu)和數(shù)據(jù)架構(gòu)綜合考慮才能夠確定是否需要集中的MDM。至少，對于許多已經(jīng)具有許多系統(tǒng)的企業(yè)而言，根據(jù)業(yè)務(wù)和應(yīng)用系統(tǒng)將主數(shù)據(jù)的管理分散在不同系統(tǒng)中是個明智的選擇。當(dāng)然也不能忘記，有些數(shù)據(jù)雖然不列為公司層次的主數(shù)據(jù)。但是它們在應(yīng)用系統(tǒng)中仍然得到大量的使用，可以借鑒主數(shù)據(jù)的管理思路來有效地管理它們，實現(xiàn)在應(yīng)用系統(tǒng)層面的集中管理。從而使得應(yīng)用系統(tǒng)簡單和高效。
圖10 理想的數(shù)據(jù)架構(gòu)
對于交易型系統(tǒng)而言，盡可能做到數(shù)據(jù)量最小化，這將使得交易系統(tǒng)的性能優(yōu)良。此外，也使得運維便利。但是數(shù)據(jù)架構(gòu)的這些內(nèi)容最好最到對于用戶透明，通過Portal可以讓用戶的體驗就像在一個系統(tǒng)中一樣。
3 技術(shù)架構(gòu)
關(guān)于技術(shù)架構(gòu)，站在現(xiàn)在的IT發(fā)展階段來看。虛擬化和云應(yīng)該是一個方向，基礎(chǔ)平臺的虛擬化，軟件平臺的統(tǒng)一化將極大地降低復(fù)雜性。但是，站在歷史的角度來看，許多企業(yè)的軟硬件平臺繁多，軟件版本不同。如何去做才能夠即降低復(fù)雜性，又能夠降低風(fēng)險呢？在該部分主要探討對于小型機(jī)應(yīng)用和開放平臺并存的企業(yè)，如何在保護(hù)已有投資的基礎(chǔ)上降低復(fù)雜性。
隨著虛擬化技術(shù)的逐漸成熟，許多企業(yè)將小型機(jī)的應(yīng)用逐漸向虛擬化平臺轉(zhuǎn)換。而且應(yīng)用平臺也逐漸向開放平臺轉(zhuǎn)變，比如從RPG語言向Java的轉(zhuǎn)變。以第2部分應(yīng)用架構(gòu)為例，由于歷史原因，其生產(chǎn)和物流相關(guān)的系統(tǒng)多種多樣，企業(yè)的生產(chǎn)/采購相關(guān)系統(tǒng)如圖11所示。這樣就造成了系統(tǒng)分散和接口復(fù)雜，維護(hù)困難。
圖11 生產(chǎn)/采購相關(guān)系統(tǒng)（優(yōu)化前）
結(jié)合第二部分的討論，由于生產(chǎn)/采購計劃和管理結(jié)合緊密而且計劃層面有非常大量的批處理計算，因此可以分步實施降低復(fù)雜性，從而保證整合的成功。因此第一步可以考慮結(jié)合應(yīng)用架構(gòu)的討論得到第一步。
圖12 生產(chǎn)/采購相關(guān)系統(tǒng)（優(yōu)化后）
更進(jìn)一步，可以考慮將生產(chǎn)/物流管理剝離到開放平臺，最后將生產(chǎn)/采購計劃也可以遷移到開放平臺。
4 迭代實現(xiàn)簡單的架構(gòu)
在《人月神話》一書中，作者給出了對于大型軟件項目人員和時間關(guān)系圖，如圖13所示。從圖中可以發(fā)現(xiàn)，如果任務(wù)能夠有效分解，人員的投入可以有效降低交付時間。而對于無法進(jìn)行有效分解導(dǎo)致關(guān)系錯綜復(fù)雜的任務(wù)，人員的投入可能會導(dǎo)致任務(wù)更加復(fù)雜，從而需要更多的時間去解決問題。
圖13 大型軟件項目人員和時間關(guān)系圖
站在系統(tǒng)論的角度來看，系統(tǒng)的功能大于各元件（或者子系統(tǒng)）功能之和，這是系統(tǒng)的特點。那么對于企業(yè)IS而言，如何有效地減少子系統(tǒng)的復(fù)雜性而不影響總體系統(tǒng)的功能呢？或者換句話說，如何能夠有效地分解系統(tǒng)，形成功能較為獨立的子系統(tǒng)，而又能很好地實現(xiàn)系統(tǒng)的總體功能呢？結(jié)合系統(tǒng)論和IS系統(tǒng)的特點以及上文的一些討論，作者給出了一些關(guān)于企業(yè)IS建設(shè)的建議：
一、子系統(tǒng)的分割：
1.1 快慢系統(tǒng)最好在軟硬件上進(jìn)行分割，通過有效地設(shè)計通訊接口服務(wù)實現(xiàn)數(shù)據(jù)的交換。比如單獨的生產(chǎn)實時控制系統(tǒng)和其他業(yè)務(wù)系統(tǒng)的分割。
1.2 對于業(yè)務(wù)功能耦合度低的系統(tǒng)進(jìn)行有效分割，盡最大可能解耦系統(tǒng)，分割成獨立功能的子系統(tǒng)或者功能模塊。實現(xiàn)單獨業(yè)務(wù)系統(tǒng)對外的數(shù)據(jù)服務(wù)接口。
1.3 不同安全級別系統(tǒng)進(jìn)行有效的分割，比如研發(fā)系統(tǒng)、生產(chǎn)系統(tǒng)和辦公系統(tǒng)進(jìn)行有效分割，其數(shù)據(jù)交換接口設(shè)計為具有安全檢測功能的服務(wù)接口。
1.4 業(yè)務(wù)處理系統(tǒng)和業(yè)務(wù)分析系統(tǒng)的分割，確保業(yè)務(wù)處理系統(tǒng)盡可能輕量級。
以上分割的基本原則即考慮了系統(tǒng)的解耦，也考慮了較優(yōu)的投資回報。
二、子系統(tǒng)的整合
2.1 構(gòu)建統(tǒng)一用戶安全管理平臺，管理用戶權(quán)限和系統(tǒng)使用安全。
2.2 構(gòu)建星形的數(shù)據(jù)交互平臺，而不要讓各子系統(tǒng)直接通訊，形成太多不必要的耦合。
2.3 對于主數(shù)據(jù)管理，建立適當(dāng)范圍內(nèi)的主數(shù)據(jù)。可以考慮分為公司級及應(yīng)用系統(tǒng)級別（部門級）。
通過有效地分割和整合，可以實現(xiàn)不同子系統(tǒng)獨立優(yōu)化，隨著技術(shù)的變更或者流程的變更而實現(xiàn)靈活的變更。
架構(gòu)的規(guī)劃大部分內(nèi)容是否可以交給供應(yīng)商呢？當(dāng)然可以，不過不能夠完全依靠供應(yīng)商，即使是世界最知名的IT咨詢供應(yīng)商。IS部門必須培養(yǎng)出較為強(qiáng)大的系統(tǒng)架構(gòu)能力。因為這是既想節(jié)省成本，又想提升IS價值必須培養(yǎng)的能力。(關(guān)于新型IS組織的必要能力請參考《新型CIO》領(lǐng)導(dǎo))
最后我還想用汽車行業(yè)舉一個例子：一輛汽車目前有上萬個零部件，各個級別的供應(yīng)商加起來可能有上千個。那么到了汽車制造廠的總裝車間，會發(fā)現(xiàn)組裝汽車好像很簡單，利用經(jīng)過簡單培訓(xùn)的工人即可完成。但是，要看到背后大量智力的投入，那就是良好架構(gòu)的設(shè)計。同樣的，系統(tǒng)的架構(gòu)設(shè)計同汽車設(shè)計人員的工作一樣，把系統(tǒng)有效分解，最后實現(xiàn)通過簡單的“拼裝與組合”就可以實現(xiàn)有效支持業(yè)務(wù)的系統(tǒng)。
核心關(guān)注：拓步ERP系統(tǒng)平臺是覆蓋了眾多的業(yè)務(wù)領(lǐng)域、行業(yè)應(yīng)用，蘊涵了豐富的ERP管理思想，集成了ERP軟件業(yè)務(wù)管理理念，功能涉及供應(yīng)鏈、成本、制造、CRM、HR等眾多業(yè)務(wù)領(lǐng)域的管理，全面涵蓋了企業(yè)關(guān)注ERP管理系統(tǒng)的核心領(lǐng)域，是眾多中小企業(yè)信息化建設(shè)首選的ERP管理軟件信賴品牌。
轉(zhuǎn)載請注明出處：拓步ERP資訊網(wǎng)http://www.oesoe.com/
本文標(biāo)題：實施精簡的企業(yè)架構(gòu)
本文網(wǎng)址：http://www.oesoe.com/html/consultation/1082004684.html
相關(guān)文章
