隨著數(shù)字化轉(zhuǎn)型成為熱議話題，我們在各種場合都能聽到關(guān)于它的討論。然而，關(guān)于數(shù)字化轉(zhuǎn)型的探討往往聚焦于政策、概念和價值等宏觀層面，而忽略了實踐中的具體問題。本文旨在從自身實踐角度出發(fā)，總結(jié)和探討企業(yè)在數(shù)字化過程中遇到的問題。

經(jīng)歷過幾個大型項目的實施和建設(shè)，但是因為時間原因并沒有進(jìn)行過整體復(fù)盤，本文即是對自己經(jīng)歷的復(fù)盤，也可以通過復(fù)盤梳理在系統(tǒng)實施中遇到的問題和自身的得失。這里要說明下，ERP并不代表數(shù)字化，這兩者之間不能劃等號。但是ERP系統(tǒng)是企業(yè)數(shù)字化建設(shè)中重要的組成部分，是企業(yè)數(shù)字化過程中的重要工具，所以這即是實施系統(tǒng)過程中的總結(jié)，也是針對企業(yè)數(shù)字化實踐過程中的總結(jié)。

因為ERP系統(tǒng)搭建或信息化建設(shè)是一個很龐大的項目，所以為了方便理解，本文會按照系統(tǒng)建設(shè)的步驟來劃分章節(jié)。

什么是ERP?

• ERP的全稱是企業(yè)資源計劃，是一種思想理念；ERP系統(tǒng)是企業(yè)資源管理系統(tǒng)，是實現(xiàn)ERP理念的實體；但在日常語境下erp和erp系統(tǒng)并不需要進(jìn)行區(qū)分，做到看資料、讀文章而不疑惑即可。
• ERP系統(tǒng)是從MRP（物料需求計劃）演化而來的，最初是服務(wù)于生產(chǎn)制造企業(yè)的，隨著信息技術(shù)的不斷發(fā)展，erp系統(tǒng)逐漸應(yīng)用在更多的行業(yè)與領(lǐng)域。因為歷史原因，進(jìn)銷存系統(tǒng)是在ERP系統(tǒng)之前就被公司使用的系統(tǒng)，所以有時我們會將ERP系統(tǒng)稱為進(jìn)銷存系統(tǒng)，但是我們作為產(chǎn)品要清楚的知道，進(jìn)銷存系統(tǒng)并不能指代ERP。
• ERP系統(tǒng)就是對企業(yè)經(jīng)營中三流（物流、資金流、信息流）的集成管理的系統(tǒng)，包含企業(yè)經(jīng)營過程中的各個方面；包括但不限于：采購管理、物料管理、車間管理、庫存管理、人力資源管理、財務(wù)管理等。

一、計劃階段

1.1 為什么要做

當(dāng)企業(yè)人員越來越多、業(yè)務(wù)越來越多的時候，管理層是不能夠清晰知道員工實際情況的，只能通過業(yè)務(wù)負(fù)責(zé)人提供的報表來了解企業(yè)經(jīng)營狀態(tài)。而且匯報層級越長，信息在傳達(dá)過程就越容易失真，如同供應(yīng)鏈中的“牛鞭效應(yīng)”。因為需求信息無法有效無誤的傳遞，導(dǎo)致信息在傳遞過程中逐漸失真。這也導(dǎo)致管理層制定的規(guī)則并不能合理的覆蓋到所有人，也不能根據(jù)執(zhí)行情況及時對規(guī)則做調(diào)整。

什么是B端产品经理？和C端产品经理有什么区别？

B端产品经理中的B是Business，商业的意思，B端产品经理首先就要理解这个职位的重要性，要设计出更适合这个项目需求的产品方案，B最终产品经理在日常工作中...

查看详情 >

對于一些崗位如銷售、維修技師等，因為他們的工作就需要直接于客戶接觸，且公司制度也不能完全涉及到每個方面，所以就有機(jī)會通過崗位特點獲取不當(dāng)利益的，而且越是信息不透明越是方便通過信息差獲取不當(dāng)利益。

所以公司就需要借助企業(yè)數(shù)字化的方式，磨平管理過程中遇到的阻礙，而erp是企業(yè)數(shù)字化的重要工具，所以就會有自建系統(tǒng)或購買系統(tǒng)的理由，希望能夠通過系統(tǒng)實現(xiàn)降本增效、提高公司管理層對公司的掌控力（也包括通過數(shù)字化這個理由對人員精簡及權(quán)利回收）。

1.2 希望實現(xiàn)的目標(biāo)

無論是購買系統(tǒng)還是自研系統(tǒng)，系統(tǒng)本身肯定不是目的，而是希望通過系統(tǒng)達(dá)到的某個可量化的目標(biāo)。注意，這個目標(biāo)一定是企業(yè)數(shù)字化后希望達(dá)成的目標(biāo)，而且這個目標(biāo)是可以量化的。例如希望系統(tǒng)上線后可以提升多少效率、節(jié)省多少人力時間、相比舊系統(tǒng)提升了多少效率等。

因為傳統(tǒng)企業(yè)并不能夠真正了解企業(yè)數(shù)字化的價值，對系統(tǒng)的唯一認(rèn)知就是可以在電腦、手機(jī)上實時看到業(yè)務(wù)數(shù)據(jù)。這就導(dǎo)致企業(yè)在評估軟件價值、財務(wù)匯報的時候，只看到了公司對其的持續(xù)投入。

而且在傳統(tǒng)企業(yè)眼中，銷售部門是用來掙錢的，而產(chǎn)研部門一直是個銷金窟，并不能帶來直接經(jīng)濟(jì)價值也就算了，還不能通過簡單的成本控制或者人力的增加獲得改善。長期的投入就會導(dǎo)致產(chǎn)研部門會受到非議，對于股份制公司來說，產(chǎn)研部門的長期投入直接影響到了年底分紅，所以就會導(dǎo)致軟件實施過程中部門之間配合效率下降、配合意愿降低。

因此這個目標(biāo)一定是公司內(nèi)部的共識，如果是產(chǎn)研部門內(nèi)部制定而沒有業(yè)務(wù)人員的參與，就導(dǎo)致這個目標(biāo)成了產(chǎn)研部門的一廂情愿了。例如實現(xiàn)銷售人員收款交付流程的效率提升，那么實現(xiàn)這個目標(biāo)就需要優(yōu)化整個交付流程，而銷售人員極有可能可以通過原來的流程獲取到原本不屬于自己的東西，這可以是權(quán)利也可以是利益。

只要影響到了業(yè)務(wù)人員的蛋糕，那么就很難將系統(tǒng)推進(jìn)下去。

所以在建設(shè)之初，我們就需要制定一個目標(biāo)，這個目標(biāo)既可以引領(lǐng)軟件實現(xiàn)的方向，也可以通過目標(biāo)來體現(xiàn)軟件帶來的價值，另外也可以通過大家的共識免除在推動系統(tǒng)過程中的不必要麻煩。

1.3 從何處入手

在數(shù)字化轉(zhuǎn)型的旅程中，企業(yè)面臨著兩種主要的路徑選擇：一是從小處著手，逐步推進(jìn)；二是全面布局，一次成型。

首先，從小處著手的方式，選擇那些獨立性強(qiáng)、與其他業(yè)務(wù)耦合度低、且重復(fù)勞動密集的業(yè)務(wù)線或功能開始，如客服系統(tǒng)、數(shù)據(jù)分析模塊或OA系統(tǒng)。這種方式具有以下優(yōu)點：

• 實現(xiàn)難度低：由于這些功能與其他業(yè)務(wù)沒有直接關(guān)聯(lián)，因此在實施過程中不會引發(fā)跨部門的溝通與協(xié)作難題，系統(tǒng)的上線過程也更加迅速。
• 成本可控：初期投入較小，企業(yè)可以根據(jù)自身的財務(wù)狀況逐步增加投入，避免了一次性大規(guī)模投入帶來的資金壓力。
• 風(fēng)險?。盒」δ芡ǔ］^為簡單，開發(fā)和實施的難度相對較低，即便遇到問題也易于調(diào)整和優(yōu)化。
• 見效快：通過率先實現(xiàn)一些關(guān)鍵的小功能，企業(yè)能夠迅速看到數(shù)字化轉(zhuǎn)型帶來的效果，增強(qiáng)進(jìn)一步推進(jìn)數(shù)字化的信心。

然而，這種方式也有其不足之處：

• 整體規(guī)劃不足：由于前期側(cè)重于小規(guī)模功能的實現(xiàn)，可能會導(dǎo)致缺乏整體規(guī)劃，在后續(xù)迭代中因基礎(chǔ)架構(gòu)不足而需進(jìn)行重構(gòu)。
• 系統(tǒng)整合難度大：隨著小功能的不斷增加，系統(tǒng)之間的整合和協(xié)調(diào)難度也會隨之加大，可能引發(fā)信息孤島和流程不暢的問題。

其次，另一種方式是搭建一整套系統(tǒng)，這種策略具有以下優(yōu)勢：

• 整體規(guī)劃清晰：在構(gòu)建整套系統(tǒng)之前，會進(jìn)行全面的需求分析和規(guī)劃，確保系統(tǒng)能夠滿足企業(yè)的整體業(yè)務(wù)需求。
• 系統(tǒng)整合度高：整套系統(tǒng)內(nèi)部各個模塊之間緊密集成，信息流通順暢，避免了信息孤島和流程不暢的問題。
• 用戶體驗一致：整套系統(tǒng)通常采用統(tǒng)一的設(shè)計規(guī)范和界面風(fēng)格，使得用戶體驗更加一致和友好。
• 擴(kuò)展性強(qiáng)：由于具有整體規(guī)劃，整套系統(tǒng)在后續(xù)擴(kuò)展和升級時更加靈活和方便。

當(dāng)然，這種方法同樣伴隨著一定的挑戰(zhàn)：

• 初期投入大：構(gòu)建整套系統(tǒng)需要較大的初期投入，包括硬件、軟件、人力等方面的成本。
• 實施周期長：整套系統(tǒng)的搭建和實施過程較為復(fù)雜，需要較長的時間來完成。
• 風(fēng)險較高：由于整套系統(tǒng)涉及多個模塊和復(fù)雜的業(yè)務(wù)流程，因此風(fēng)險也相對較高，一旦某個環(huán)節(jié)出現(xiàn)問題，可能會影響整個系統(tǒng)的正常運(yùn)行。

所以，企業(yè)在做數(shù)字化時沒有固定的路徑，需要根據(jù)自身的實際情況和發(fā)展階段，選擇適合自己的方式。

1.4 自研前的調(diào)研準(zhǔn)備

在做之前我們需要全面了解公司內(nèi)部的部門劃分和公司管理風(fēng)格，因為“系統(tǒng)只是工具”。系統(tǒng)是不能彌補(bǔ)管理上的缺失的，很多傳統(tǒng)企業(yè)管理者認(rèn)為只要上線了系統(tǒng)，就能讓公司煥然一新變成了擁有數(shù)字化能力的公司，這實際是并沒有理解企業(yè)數(shù)字化或者只是把本應(yīng)不屬于產(chǎn)研部門的工作強(qiáng)行加到了產(chǎn)研部門身上。

技術(shù)的先進(jìn)性并不能彌補(bǔ)管理上的缺失，如果現(xiàn)有管理就不規(guī)范，系統(tǒng)就無法開發(fā)，系統(tǒng)是穩(wěn)定的管理方式的體現(xiàn)，系統(tǒng)是在滿足現(xiàn)有標(biāo)準(zhǔn)流程的基礎(chǔ)之上去分析現(xiàn)有狀況的，這樣才能發(fā)揮出系統(tǒng)的價值。

通過系統(tǒng)來重新梳理規(guī)范時，也容易出現(xiàn)一廂情愿的情況，因為公司高層長時間的脫離一線，導(dǎo)致對一線的工作情況并不了解，雖然有規(guī)范，但一線人員往往并不能百分百的按照標(biāo)準(zhǔn)執(zhí)行，而標(biāo)準(zhǔn)是否嚴(yán)格執(zhí)行也不會體現(xiàn)到短期營收上去，而高層只能通過營收數(shù)字來分析指導(dǎo)工作，接著就導(dǎo)致了信息不對稱,就算下達(dá)強(qiáng)硬的措施也只能造成陰奉陽違。

在不能夠真正了解一線的情況下，部門主管在指導(dǎo)功能流程時還會提出自己的想法，希望通過系統(tǒng)再次將流程標(biāo)準(zhǔn)化。這就會導(dǎo)致流程與業(yè)務(wù)的不匹配，造成開發(fā)出來的流程與實際業(yè)務(wù)差距很大，而自研之前就應(yīng)該需要充分的了解公司的實際情況，而不是為了標(biāo)準(zhǔn)而標(biāo)準(zhǔn)、為了規(guī)范而規(guī)范，使用才是第一步。

另外我們也需要知道當(dāng)前已經(jīng)使用了哪些系統(tǒng)，以及系統(tǒng)是通過什么邏輯詮釋業(yè)務(wù)的。舉個例子：退貨是訂單中很常見的業(yè)務(wù)，常規(guī)的做法是當(dāng)用戶發(fā)起退貨操作的時候，根據(jù)訂單生成倉儲系統(tǒng)的退貨入庫單，當(dāng)倉管入庫后，再根據(jù)退貨入庫單生成財務(wù)單據(jù)。當(dāng)時公司當(dāng)時使用的金蝶系統(tǒng)是在原有的銷售出庫單上推式生成新的采購入庫單，直接在原有的采購入庫單上進(jìn)行修改。

通過這個例子，我們就能夠很直觀的感受到業(yè)務(wù)的實際流程和系統(tǒng)詮釋后的流程。有系統(tǒng)和沒有系統(tǒng)這是兩回事，我們可以理解公司所有業(yè)務(wù)都有一個最優(yōu)的流程和方案，如果之前已經(jīng)有系統(tǒng)詮釋了公司的業(yè)務(wù)，那么勢必會影響到我們自身對于業(yè)務(wù)的理解，也影響到業(yè)務(wù)人員對于系統(tǒng)的操作習(xí)慣。

二、調(diào)研階段

2.1 線下需求調(diào)研

做大型系統(tǒng)或系統(tǒng)關(guān)聯(lián)多崗位時，可以根據(jù)業(yè)務(wù)線為突破口。采用頭腦風(fēng)暴的形式，每接觸一個崗位就將該崗位的所有職責(zé)都記錄下來，在記錄職責(zé)時不需要關(guān)心哪些內(nèi)容可以做到系統(tǒng)上，因為記錄職責(zé)的目的是為了讓我們更了解業(yè)務(wù)人員所需要做的事情。

業(yè)務(wù)線這三個字每個人理解是不同的，甚至在業(yè)務(wù)領(lǐng)導(dǎo)那就沒有業(yè)務(wù)線的概念，但是他們清楚的知道自己的職責(zé)以及部門職責(zé)，這種方式的好處就是可以避免因只關(guān)注業(yè)務(wù)線而產(chǎn)生遺漏。在記錄職責(zé)的時候也盡量精簡，“動詞+名詞+部分解釋”就足夠記錄每個崗位要做的事情了（見下圖）。

而且在調(diào)研時，哪怕語音和視頻會議溝通的再清楚，也都需要線下面對面調(diào)研。調(diào)研時一定要去線下，語音或者視頻會議溝通的再清楚，都不如線下溝通。

比如有次去線下調(diào)研 ，維修車間和前臺有一墻之隔，技師經(jīng)常來回跑，我就問為啥不弄一個對講機(jī)？業(yè)務(wù)說之前弄過，但是因為門店旁邊有很多飯店，用對講機(jī)的時候經(jīng)常遇到串頻道的情況。這邊剛問車修好了沒，結(jié)果那邊傳過來：5號桌的菜已經(jīng)好了。如果不是線下調(diào)研，這種情況我相信產(chǎn)品永遠(yuǎn)無法獲取到，只是沉浸在自己的邏輯世界里。

2.2 業(yè)務(wù)建模

調(diào)研結(jié)束后，我們可以將調(diào)研結(jié)果通過崗位職責(zé)腦圖、用例圖、業(yè)務(wù)流程圖來體現(xiàn)。如果業(yè)務(wù)線的流程過長且涉及多個部門，那么可以根據(jù)領(lǐng)域驅(qū)動設(shè)計的理論，通過拆分領(lǐng)域的方式將一個大的業(yè)務(wù)線拆分成多個子業(yè)務(wù)，針對每一個子業(yè)務(wù)單獨分析。這里需要注意，這些子業(yè)務(wù)可能并不是真實存在的，而是根據(jù)對業(yè)務(wù)的了解和對產(chǎn)品架構(gòu)的理解人為劃分的。

以整車的維修為例，可以根據(jù)職責(zé)相似度和業(yè)務(wù)場景可以將其拆分為：服務(wù)顧問接待客戶、維修技師維修車輛、倉管員出庫配件、客戶付款這四個子業(yè)務(wù)（可見下圖的服務(wù)顧問接待客戶的業(yè)務(wù)）。

1）業(yè)務(wù)用例圖

2）業(yè)務(wù)流程圖

在“服務(wù)顧問接待客戶”業(yè)務(wù)中，我們需要詳細(xì)了解到每一個步驟是如何完成的，如果有紙質(zhì)單據(jù)，紙質(zhì)單據(jù)是什么格式；如果需要做電子單據(jù)，那么電子單據(jù)的簽字是否能夠用電子簽名完成；進(jìn)店的客戶是不是車主，不是車主怎么處理；客戶以什么形式進(jìn)行付款，是否使用了積分、券等一些列細(xì)節(jié)問題。

通過上述問題，我們就應(yīng)該可以知道拆分成子業(yè)務(wù)的好處了。它能夠更深刻的理解業(yè)務(wù)中的每一個環(huán)節(jié)，在功能設(shè)計的時候也可以更清晰的認(rèn)知到功能誰在用，使用者的場景和痛點。

我們當(dāng)然可以將一整條業(yè)務(wù)線全都體現(xiàn)出來，這樣能體現(xiàn)出業(yè)務(wù)的流向和了解業(yè)務(wù)整體，但是這樣會導(dǎo)致信息太多，讓我們忽略掉一些細(xì)節(jié)。如果想要了解整個業(yè)務(wù)流程，可以單獨繪制一張獨立且完整的業(yè)務(wù)流程圖。

2.3 調(diào)研結(jié)果需達(dá)成共識

相比于上述的調(diào)研產(chǎn)出，最最重要的就是調(diào)研結(jié)果能否達(dá)成共識。

再重復(fù)一遍，調(diào)研產(chǎn)出固然重要，但更重要的是調(diào)研結(jié)果能否達(dá)成共識。

每一次產(chǎn)出都應(yīng)向業(yè)務(wù)人員確認(rèn)，并且需要獲得各業(yè)務(wù)部門領(lǐng)導(dǎo)及部分基層人員的認(rèn)可。一線人員通常更接近實際工作環(huán)境，對具體操作過程中的問題有著更深入的理解；而管理層則更多地關(guān)注整體戰(zhàn)略規(guī)劃和流程優(yōu)化，其視角更為宏觀。因此，我們不僅需要管理層的確認(rèn)，還需要與一線人員共同探討流程的可行性。

如果不進(jìn)行充分的確認(rèn)，很容易因為溝通不到位而產(chǎn)生返工的情況，讓產(chǎn)品夾在中間無法順利推進(jìn)工作。

三、設(shè)計研發(fā)階段

3.1 系統(tǒng)建模

復(fù)雜系統(tǒng)的在實現(xiàn)之初，都是從很簡單的功能開始的。但是隨著功能的增加、代碼數(shù)量增加、結(jié)構(gòu)的變更的原因，逐步變得復(fù)雜且不可控。所以我們需要借助“理念”“工具”的力量來避免系統(tǒng)走向混亂。

領(lǐng)域驅(qū)動設(shè)計（簡稱DDD）就是應(yīng)對復(fù)雜系統(tǒng)很有效的方法，DDD的核心目的就是利用各種方法、技巧和工具提煉出問題本質(zhì)的領(lǐng)域模型，將大系統(tǒng)拆分為子模塊，通過這種方式降低“單體架構(gòu)”因功能變多、需求變多、數(shù)據(jù)變多而產(chǎn)生了過多的復(fù)雜性。并且為了避免系統(tǒng)的過度設(shè)計、設(shè)計不足，為系統(tǒng)留下的技術(shù)債，我們需要重視調(diào)研和產(chǎn)品規(guī)劃。

系統(tǒng)建模的關(guān)注點在于劃分系統(tǒng)與外界的職責(zé)，系統(tǒng)能做什么、外界的反饋是什么。軟件系統(tǒng)就如同現(xiàn)實世界的映射，通過系統(tǒng)建模將現(xiàn)實世界中出現(xiàn)的實體映射到軟件中。在線下調(diào)研時，我們已經(jīng)得知了企業(yè)所有崗位、每個崗位所作的工作、拆分了業(yè)務(wù)線，那么下一步就需要根據(jù)現(xiàn)實世界去分析系統(tǒng)。

1）功能用例圖

系統(tǒng)用例圖可以在業(yè)務(wù)用例圖的基礎(chǔ)上進(jìn)行修改。我采用的方法是在業(yè)務(wù)用例圖上將可以通過系統(tǒng)完成的工作標(biāo)紅。這樣既能節(jié)省重新畫圖的時間，也能清晰地界定業(yè)務(wù)和系統(tǒng)的邊界，明確哪些工作由系統(tǒng)完成，哪些不由系統(tǒng)處理。如果系統(tǒng)在某個環(huán)節(jié)出現(xiàn)問題，可以通過用例分析出是系統(tǒng)的問題還是使用者的問題。

2）實體關(guān)系圖

實體關(guān)系圖（ER圖或ERD圖）是將業(yè)務(wù)需求轉(zhuǎn)化為系統(tǒng)設(shè)計過程中的重要工具。它可以幫助產(chǎn)品經(jīng)理將業(yè)務(wù)流程轉(zhuǎn)化為具體的數(shù)據(jù)結(jié)構(gòu)，讓我們能夠更好地理解各數(shù)據(jù)實體之間的邏輯關(guān)系。并且實體關(guān)系圖還能為團(tuán)隊成員提供了一種共同的語言和框架，讓產(chǎn)品和技術(shù)在相同的語境下溝通。

雖然產(chǎn)品經(jīng)理并不需要會寫代碼，但是我們?nèi)匀恍枰私庀到y(tǒng)的數(shù)據(jù)結(jié)構(gòu)，這種理解可以為后續(xù)的系統(tǒng)規(guī)劃、業(yè)務(wù)邏輯的實現(xiàn)以及數(shù)據(jù)分析奠定基礎(chǔ)。

3.2 需求文檔產(chǎn)出

上一步我們已經(jīng)清晰的知道系統(tǒng)需要完成哪些工作，下一步就需要產(chǎn)出原型和需求文檔了，在產(chǎn)出原型和文檔時需要注意以下幾點。

1）名詞命名要統(tǒng)一

例如業(yè)務(wù)這個詞，我們可以理解成“業(yè)務(wù)人員”，也可以理解成“業(yè)務(wù)流程”。因為有這種情況的產(chǎn)生，所以我們就需要統(tǒng)一命名規(guī)范，需要統(tǒng)一命名的不止是軟件中的常用字段，也包括業(yè)務(wù)人員常用的名詞，避免使用同義詞或者類似的表達(dá)方式，導(dǎo)致理解上的混淆。

我們可以制定一套明確的命名規(guī)范，在整個團(tuán)隊中推廣使用，命名規(guī)范里包括名詞、名詞含義。

2）保障輸入信息的正確性

業(yè)務(wù)人員在使用系統(tǒng)的時候，經(jīng)常會填錯信息，甚至?xí)霈F(xiàn)單據(jù)已經(jīng)提交財務(wù)且財務(wù)已經(jīng)審核通過了，此時業(yè)務(wù)人員要求回退單據(jù)，如果出現(xiàn)這種情況，我們?nèi)绾翁幚?？這就要求系統(tǒng)擁有糾錯機(jī)制機(jī)制、防呆機(jī)制、逆向流程，確保員工錄入信息的正確性。

在設(shè)計功能時，我們需要考慮到無論業(yè)務(wù)操作到了那一步，我們都可以幫助業(yè)務(wù)人員將錯誤信息改正。但是我們要注意，所有的數(shù)據(jù)改正都是建立在現(xiàn)實世界中的，我們不能去處理現(xiàn)實世界中根本不存在的錯誤。

通過實際例子，我們應(yīng)該能更好的理解為什么要保證數(shù)據(jù)的正確性：

• 服務(wù)顧問創(chuàng)建單據(jù)，已經(jīng)將單據(jù)指派給主修人了，發(fā)現(xiàn)車輛VIN填錯了，，此時如何處理？

這種錯誤我們可以設(shè)置VIN的格式，如果與VIN的格式不符，那么就無法提交；如果格式填寫正確但內(nèi)容錯誤，這種情況就可以將單據(jù)撤銷回創(chuàng)建的狀態(tài)進(jìn)行車輛信息的修改；如果狀態(tài)已經(jīng)無法回退了，那么就可以通過修改功能，將新的信息覆蓋舊的信息，并保留舊的數(shù)據(jù)以作記錄。

• 服務(wù)顧問創(chuàng)建單據(jù)后，客戶因為緊急事情需要離店，此時如何處理？

前面我們說了，系統(tǒng)是現(xiàn)實世界的映射，我們可以根據(jù)業(yè)務(wù)實際的情況來解決軟件搭建的難題。如果車輛還沒有進(jìn)入維修（創(chuàng)建狀態(tài)），那么我們可以作廢單據(jù)；如果車輛已經(jīng)在維修了，但是還并沒有拆解車，我們可以通過單據(jù)回退的方式，將單據(jù)回退至創(chuàng)建狀態(tài)再進(jìn)行作廢單據(jù)。如果車輛已經(jīng)拆解了某些配件，我們就無法進(jìn)行處理了，這并不是系統(tǒng)不支持而是實際業(yè)務(wù)場景不支持。

3）避免過度設(shè)計

B端產(chǎn)品在設(shè)計時需要重視“易用性”，要盡力避免過度設(shè)計，組件庫有的樣式就直接沿用組件庫的樣式就好了，沒必要絞盡腦汁去實現(xiàn)一個不一樣的交互和展示形式。因為實際用戶可能學(xué)歷不高、不太會用電腦、年齡較大等等，這些因素都影響原型的實現(xiàn)。

在設(shè)計B端產(chǎn)品時，應(yīng)高度重視“易用性”，盡量避免過度設(shè)計。組件庫可以提供的樣式，可以直接沿用，沒必要絞盡腦汁去實現(xiàn)一個不一樣的交互和展示形式，畢竟產(chǎn)品的價值不在于交互的新穎、設(shè)計的創(chuàng)新。而且考慮到實際用戶可能學(xué)歷不高、不熟悉電腦操作或年齡較大，我們還需要將頁面設(shè)計的“丑”一些，例如：加粗的文字、明顯的按鈕。

常用的組件庫包括：Ant Design、Vant、Element。

4）不要過于迷信技術(shù)

科學(xué)技術(shù)是第一生產(chǎn)力，但不能狹隘的就認(rèn)為新技術(shù)就是好的。要辯證的去看待技術(shù)，不能陷入到產(chǎn)研團(tuán)隊的自嗨。在某些特定情境下，技術(shù)的應(yīng)用并非取決于其先進(jìn)與否，而是受制于更為基本的因素——人力成本。

例如，RFID技術(shù)作為一種高效的數(shù)據(jù)采集手段，能夠提升供應(yīng)鏈管理的效率，但并不代表有倉儲業(yè)務(wù)的企業(yè)就會去用RFID。并非因為技術(shù)有缺陷，而是用人力比用這些新技術(shù)更省錢。

以小倉庫（50㎡）為例，無論是否應(yīng)用RFID，總歸是需要一個倉管員來負(fù)責(zé)的，而且RFID的標(biāo)簽不是憑空出現(xiàn)在物料上的，還需要花費(fèi)時間將標(biāo)簽貼到物料上，應(yīng)用新技術(shù)除了多花錢之外沒有節(jié)省任何時間，只不過是將出庫的時間花費(fèi)在了貼標(biāo)簽上。

3.3 業(yè)務(wù)負(fù)責(zé)人及一線人員確認(rèn)

產(chǎn)出原型、需求文檔之后，先不要著急去開發(fā)，而是需要與業(yè)務(wù)人員進(jìn)行確認(rèn)。因為軟件畢竟是員工使用的，所以我們就需要不斷的去和員工進(jìn)行溝通，向他們詢問對于系統(tǒng)設(shè)計的建議與合理性。與調(diào)研結(jié)果的確認(rèn)類似，即需要與一線人員確認(rèn)也需要與對應(yīng)管理層確認(rèn)。

以上面的流程為例，我們可以向部門負(fù)責(zé)人（售前部門領(lǐng)導(dǎo)）去確認(rèn)流程的合理性。如果流程是合理的，可以讓領(lǐng)導(dǎo)去根據(jù)區(qū)域、門店、經(jīng)營等情況，推薦幾個一線業(yè)務(wù)人員，再向他們確認(rèn)功能流程和頁面交互。與一線業(yè)務(wù)人員確認(rèn)的時候需要注意，最好不要和業(yè)務(wù)領(lǐng)導(dǎo)一塊確認(rèn)，免得因為領(lǐng)導(dǎo)在場而不敢主動發(fā)言，提不出自己的意見。

3.4 需求評審

如果部門領(lǐng)導(dǎo)以及一線員工都認(rèn)為沒有問題之后，我們就需要進(jìn)入到需求評審階段了。

需求評審的核心就是PRD文檔，所以一份好的PRD文檔非常重要。什么是好的PRD文檔呢？那就是結(jié)構(gòu)清晰。結(jié)合前面的業(yè)務(wù)建模、系統(tǒng)建模，我們就可以將其結(jié)合到PRD文檔中。

通過業(yè)務(wù)建模讓團(tuán)隊對業(yè)務(wù)有個清晰的認(rèn)識，再通過系統(tǒng)建模讓同事知道系統(tǒng)邏輯是什么樣的，再去根據(jù)系統(tǒng)建模去講解對應(yīng)的原型頁面。這樣就可以讓我們的團(tuán)隊從業(yè)務(wù)到系統(tǒng)都有了一個全面的認(rèn)知，統(tǒng)一認(rèn)知之后，就能保障技術(shù)同學(xué)能夠在了解業(yè)務(wù)的基礎(chǔ)之上去提問，避免技術(shù)同學(xué)頻繁去反駁產(chǎn)品方案的合理性，導(dǎo)致整個會議都是在與技術(shù)同學(xué)的爭執(zhí)中度過。

在需求評審時需要注意，我們一定要做好會議紀(jì)要。就像上面提到的，需求評審不可避免的會與技術(shù)產(chǎn)生爭執(zhí)，有時會議上爭論很激烈，但是爭論來爭論去，就會越來越遠(yuǎn)離會議目的的，成了為了爭論而爭論。所以為了避免這種情況的產(chǎn)生，如果遇到會議上不能立刻產(chǎn)生解決方案的問題，那就先做記錄等會后解決。

有爭執(zhí)先記錄，等第二次需求評審就可以直接針對上次的遺留問題做評審。

3.5 測試驗收

在需求評審?fù)ㄟ^并完成開發(fā)工作后，接下來的關(guān)鍵步驟是測試驗收。這一階段確保軟件滿足功能需求，同時也能在實際使用場景下滿足業(yè)務(wù)使用。

測試驗時要注意下面三點:

• 壓力測試：我們可以根據(jù)企業(yè)員工數(shù)量，來調(diào)節(jié)和確定壓力測試的強(qiáng)度。畢竟對于一家100人的企業(yè)和一家10000人的企業(yè)，壓力測試的重點和規(guī)模會有明顯的區(qū)別。特別是導(dǎo)入導(dǎo)出功能需要重點測試，因為一般月底會做總結(jié)會議，經(jīng)常需要導(dǎo)出數(shù)據(jù)進(jìn)行數(shù)據(jù)分析。
• 兼容性測試：完成壓力測試后，緊接著進(jìn)行兼容性測試。這一測試就是驗證軟件在不同操作系統(tǒng)、瀏覽器以及設(shè)備上的表現(xiàn)。在兼容性測試前，可以先統(tǒng)計企業(yè)內(nèi)使用設(shè)備的情況，假如企業(yè)統(tǒng)一使用edge瀏覽器（微軟原生瀏覽器），那么也就沒必要去測試國產(chǎn)的各種亂七八糟的瀏覽器了。
• 用戶體驗測試：在確保了軟件的基本功能和技術(shù)穩(wěn)定性后，接下來的重點是用戶體驗測試。通過收集用戶反饋和觀察他們的實際操作行為，我們可以深入了解軟件的優(yōu)缺點，并根據(jù)結(jié)果進(jìn)行必要的調(diào)整和優(yōu)化，提升整體的用戶體驗。我們可以邀請需求評審時那些同事（調(diào)研產(chǎn)出確認(rèn)、需求確認(rèn)的業(yè)務(wù)同事），畢竟和他們溝通過原型和流程，他們已經(jīng)對我們的系統(tǒng)有了基本的了解。由他們主導(dǎo)用戶體驗的優(yōu)劣，也免除了重新介紹系統(tǒng)的時間。

四、實施準(zhǔn)備階段

4.1 內(nèi)部認(rèn)同的實施計劃

你可能會想，實施計劃不就是簡單地規(guī)定一個時間，讓企業(yè)開始使用新系統(tǒng)嗎？然而，事情遠(yuǎn)沒有那么簡單。對于大多數(shù)業(yè)務(wù)人員來說，這套ERP系統(tǒng)是一個全新的工具，他們甚至可能從未見過。在這種情況下，我們?nèi)绾未_保每個員工都能熟練地使用這套系統(tǒng)呢？即使系統(tǒng)的功能設(shè)計得再簡單，仍然會面臨企業(yè)歷史數(shù)據(jù)的處理、財務(wù)對賬等一系列復(fù)雜問題。

因此，在制定實施計劃時，我們必須將這些潛在的問題都考慮在內(nèi)，并根據(jù)實際情況出具詳細(xì)的實施記錄。

首先，由于財務(wù)的特殊性，我們只能選擇在每個月的1號進(jìn)行數(shù)據(jù)和系統(tǒng)的切換，以確保財務(wù)數(shù)據(jù)的準(zhǔn)確性和連續(xù)性。其次，考慮到行業(yè)的實際情況，我們需要選擇一個業(yè)務(wù)相對不忙的時段進(jìn)行切換。以汽車零售行業(yè)為例，由于年底是沖銷量、完成廠家任務(wù)的關(guān)鍵時期，我們盡量避免在10月、11月、12月和1月進(jìn)行切換，以免對業(yè)務(wù)造成不必要的干擾。

并且在制定實施計劃時，我們也要留出足夠的時間來做培訓(xùn)，培訓(xùn)時盡量能夠在線下完成，雖然視頻培訓(xùn)可以覆蓋廣泛的受眾，但在實際操作中，員工可能會遇到各種預(yù)料之外的問題。

在后續(xù)的軟件試用期間，也需要制定試用的計劃。例如試用的第一周的目的是讓員工熟悉軟件，第二周要通過系統(tǒng)錄入至少實際業(yè)務(wù)10%的數(shù)據(jù)，第三周要通過系統(tǒng)錄入實際業(yè)務(wù)50%的數(shù)據(jù)，通過目標(biāo)制定的方式，方便我們能夠把控軟件實施的實際情況。

通過考慮上面的這些問題，就可以制定出一個讓各方比較滿意的實施計劃，這個計劃可能不那么完美，但它是我們與業(yè)務(wù)同事和管理層達(dá)成的共識，而且也可以根據(jù)后續(xù)推進(jìn)情況不斷優(yōu)化（如下圖）。

4.2 實施準(zhǔn)備工作

• 內(nèi)部時間節(jié)點的通知：在ERP項目啟動之初，就需要設(shè)立明確的時間表和關(guān)鍵里程碑。這些時間節(jié)點包括但不限于系統(tǒng)上線日期、培訓(xùn)安排等。為了確保信息的透明度和一致性，企業(yè)需要通過內(nèi)部公告或郵件等方式及時通知所有相關(guān)人員，避免信息不同步。
• 數(shù)據(jù)準(zhǔn)確性的保證：數(shù)據(jù)質(zhì)量是ERP實施成功的關(guān)鍵因素，在系統(tǒng)切換之前，需要對原始數(shù)據(jù)進(jìn)行全面的審計，避免因為原始數(shù)據(jù)錯誤而影響到ERP的運(yùn)行。并且還可以設(shè)定一個特定的時間節(jié)點作為數(shù)據(jù)的“凍結(jié)”點，比如在切換前的一周內(nèi)進(jìn)行大盤點，以此確保所有數(shù)據(jù)都是最新的且準(zhǔn)確無誤。
• 外包業(yè)務(wù)的考慮：企業(yè)在運(yùn)營過程中可能會涉及外包業(yè)務(wù)，在ERP系統(tǒng)實施過程中，需要考慮如何將外包流程整合進(jìn)來，或者是兼容外包業(yè)務(wù)。

4.3 產(chǎn)研的部門定位及團(tuán)隊建設(shè)

在實際推進(jìn)過程中管理層好像是條件反射，只要是系統(tǒng)問題就會推給產(chǎn)研部分，導(dǎo)致產(chǎn)研同學(xué)總是處理那些低價值的問題，例如物料價格錯了需要修改、采購怎么做、A地區(qū)和B地區(qū)的售價不一樣需要調(diào)整等等問題。

所以產(chǎn)研部門需要明確自己的角色和責(zé)任，避免成為業(yè)務(wù)流程問題的唯一解決者，需要明確哪些責(zé)任屬于產(chǎn)研部門，哪些應(yīng)由業(yè)務(wù)部門承擔(dān)。例如，某些數(shù)據(jù)的系統(tǒng)配置應(yīng)由對應(yīng)部門的領(lǐng)導(dǎo)負(fù)責(zé)，單據(jù)錯誤后應(yīng)該由直屬部門領(lǐng)導(dǎo)來修改。ERP項目的實施一旦啟動，就不可能隨意停下來，所以產(chǎn)研部門需要在實施前就開始招聘一些人，確保有足夠的人力資源來應(yīng)對可能出現(xiàn)的各種問題。

4.4 實施過程中緊急問題的處理

越是接近實施階段，技術(shù)和測試同學(xué)發(fā)現(xiàn)的問題往往越不會那么簡單，此時對于已經(jīng)存在的邏輯和功能，在沒有完全理解前因后果（即100%了解）的情況下，不要輕易進(jìn)行改動。這是因為之前的做法必定有其合理的緣由，隨意改動可能會引入新的問題或破壞原有的平衡，就好像代碼中有bug所以系統(tǒng)才能正常運(yùn)行。

如果確實需要進(jìn)行修改，就必須遵循正規(guī)的需求評審等流程，這樣做可以確保所有相關(guān)的利益方都了解改動的意圖及其可能帶來的影響，同時也能夠避免在緊急處理過程中產(chǎn)生新的bug。

五、實施階段

5.1 實施前期

在實施的前期，是工作最近緊張的時刻，前期的一系列工作就看實施的是否順利了，下面是實施前期需要注意的事情。

• 瀏覽器的緩存問題：在ERP系統(tǒng)部署過程中，瀏覽器緩存可能會導(dǎo)致顯示錯誤或功能異常。為了避免這類問題，可以通過硬性更新的方式來清除緩存，確保用戶看到的是最新的系統(tǒng)狀態(tài)，或者在頁面上加一個按鈕，方便用戶清除緩存更新系統(tǒng)。
• 銷售收款的合規(guī)性問題：對于非標(biāo)品或非固定價格的商品，銷售過程中可能存在較多不透明的地方。所以在ERP系統(tǒng)設(shè)計時，需要特別注意銷售收款的合規(guī)性，盡量保證所有交易都符合要求（只能說盡量，因為只要牽扯交易，就必然會有不合規(guī)的地方，公司可能就靠這些不合規(guī)的地方盈利）。
• 產(chǎn)品研發(fā)部門的人力安排：在ERP實施過程中，產(chǎn)品研發(fā)部門的人力安排需要合理規(guī)劃，避免出現(xiàn)一部分人員非常忙碌而其他同事卻無事可做的情況。這可以通過靈活調(diào)配資源、優(yōu)化任務(wù)分配來實現(xiàn)。
• 正規(guī)流程處理數(shù)據(jù)錯誤：如果業(yè)務(wù)人員做錯了數(shù)據(jù)，不能直接刪除數(shù)據(jù)或修改數(shù)據(jù)庫，而應(yīng)遵循正規(guī)流程進(jìn)行處理，不能因為客戶著急而去走特殊渠道修改數(shù)據(jù)。
• 每日問題記錄：在ERP實施過程中，每天都需要記錄遇到的問題及其解決方案，這不僅有助于解決當(dāng)前問題，也為后續(xù)可能出現(xiàn)的類似問題提供了參考。
• 信息同步：在ERP實施過程中，各部門之間的協(xié)作能力和信息同步是很重要的，可以每周末進(jìn)行一個同步會議，溝通本周遇到的問題，如果是業(yè)務(wù)問題，可以直接交由對應(yīng)業(yè)務(wù)領(lǐng)導(dǎo)去解決，避免產(chǎn)研部門直接指揮一線業(yè)務(wù)人員。

5.2 實施后期

ERP系統(tǒng)的實施并非以業(yè)務(wù)使用或財務(wù)順利做賬為終點，而應(yīng)以月末做賬的成功作為最終目標(biāo)。這是因為月末做賬涉及到大量的數(shù)據(jù)整合和處理，只有當(dāng)這個環(huán)節(jié)順利完成，才能說明ERP系統(tǒng)真正融入了企業(yè)的日常運(yùn)作。

我們需要確保所有的財務(wù)報表都能夠準(zhǔn)確無誤地生成。這意味著不僅要驗證數(shù)據(jù)本身的準(zhǔn)確性，還要確認(rèn)報表邏輯的合理性。例如，在月末結(jié)賬時，系統(tǒng)應(yīng)該能夠順利處理所有相關(guān)的財務(wù)記錄，并生成符合會計準(zhǔn)則的報表。

財務(wù)數(shù)據(jù)的準(zhǔn)確性對于ERP系統(tǒng)至關(guān)重要。任何錯誤的數(shù)據(jù)輸入都可能導(dǎo)致嚴(yán)重的后果。在ERP實施后期，需要重點檢查財務(wù)模塊的數(shù)據(jù)輸入流程，確保每一筆交易都能夠被正確記錄。此外，還應(yīng)建立一套完整的數(shù)據(jù)校驗規(guī)則，比如設(shè)置自動對賬程序來發(fā)現(xiàn)并糾正潛在的錯誤。

除了財務(wù)數(shù)據(jù)的準(zhǔn)確，管理人員往往在月末需要各類業(yè)務(wù)數(shù)據(jù)去做分析，方便他們?nèi)プ鲈露葏R報，我們可以為特定角色設(shè)定定制化的數(shù)據(jù)推送機(jī)制。例如，可以為高層管理者設(shè)定自動報告功能，定期向他們的郵箱發(fā)送銷售分析、庫存水平等重要指標(biāo)，幫助他們掌握業(yè)務(wù)動態(tài)。

六、收尾工作

再完成ERP實施之后，恐怕到了部門最嚴(yán)峻的時候了，集團(tuán)需要計算投資回報率。

集團(tuán)投資了一大筆錢來做系統(tǒng)，當(dāng)系統(tǒng)建設(shè)完成之后總會去做投資回報率或者上線后的收益，但計算的結(jié)果肯定不會讓產(chǎn)研團(tuán)隊舒服，因為ROI只是一個財務(wù)指標(biāo)，而ERP系統(tǒng)不只是從手工單據(jù)到電子單據(jù)的轉(zhuǎn)變，更是企業(yè)管理、業(yè)務(wù)流程、組織架構(gòu)的變革，并不是ROI不重要，而是ROI不應(yīng)該作為唯一的決策依據(jù)。

作為產(chǎn)研部門，我們需要從企業(yè)數(shù)字化的角度去評估系統(tǒng)的價值，包括流程優(yōu)化、員工生產(chǎn)力提升、打破信息壁壘、數(shù)據(jù)決策等。我們可以通過項目復(fù)盤去回顧整個ERP項目，我們的初衷有沒有堅守、設(shè)立的目標(biāo)有沒有實現(xiàn)、當(dāng)前ERP的價值有沒有體現(xiàn)。如果實現(xiàn)了，那么具體產(chǎn)生了多少的效益，信息化建設(shè)的下一個目標(biāo)是什么；如果沒有實現(xiàn)，是因為什么原因?qū)е碌?，后續(xù)需要怎么做才能滿足目標(biāo)。

這些東西都可以作為復(fù)盤會議的總結(jié)，而這些總結(jié)又可以匯報給集團(tuán)領(lǐng)導(dǎo)，避免高層只看到了ROI數(shù)據(jù)而否定了整個項目的價值。

七、結(jié)尾

自建ERP系統(tǒng)是一個非常復(fù)雜且充滿挑戰(zhàn)的過程，但這也只是企業(yè)數(shù)字化建設(shè)的一小部分。企業(yè)數(shù)字化不只是做個系統(tǒng)，用上什么新技術(shù)這么簡單，它是對企業(yè)管理、業(yè)務(wù)流程的一次變革，在這個過程中，知道為什么做比知道怎么做更重要，因為ERP的價值不僅僅體現(xiàn)在直接的財務(wù)回報上，更重要的是它為企業(yè)帶來的長遠(yuǎn)發(fā)展?jié)撃堋?/p>

本文旨在從自身實踐角度出發(fā)，總結(jié)和探討企業(yè)在數(shù)字化過程中遇到的問題，因為需要兼顧系統(tǒng)建設(shè)的各個方面，某些地方寫的比較籠統(tǒng)也有一些不足，希望大家能夠諒解，也希望能給你帶來一些思考。