以下内容為記錄某司DMS訂貨系統的改造過程
21年，疫情的第二年，入職某司IT部任職産品經理
入職後恰巧趕上該司的IT部門大整頓，親眼見證了一些不可思議的事情，瞬間感覺以前所在的團隊真的是太好了…當然與本内容無關，放下不表。
單說被配置設定到ToB組後，接手一個半成品的DMS系統。先說下當時ToB組的人員組成情況：項目經理一名，主要負責與業務部門對接和團隊管理；java開發兩名，前端開發兩名及測試一名。之是以說半成品系統，是因為在我之前沒有産品經理梳理，導緻系統架構和流程均有莫名的問題。
原本入職是要進OMS組的，但因為大整頓，OMS自研項目取消。好吧，既然分到ToB組，又恰好是自己擅長的，那就把這個産品打理好~跟項目經理溝通後，決定着手改版整個DMS系統。
怎麼開始呢？根據過往經驗，大緻按以下步驟進行：
① 了解目前産品的定位，核心流程
② 了解業務人員架構、業務涉及角色、業務整體流程
③ 梳理業務現狀，總結業務問題
④ 應用架構确認、功能子產品優化及演進藍圖
⑤ 資料模組化、流程角色優化
⑥ 其他細節設計及編寫文檔
⑦ 需求溝通會
⑧ 實施整體改版計劃
第一步：了解目前系統的産品定位
之前做過很多商城，ToC和ToB都有涉及，對商城體系還是有比較深刻的了解，是以對于DMS訂貨系統有着自己的認知。當然，不同的公司同樣的産品定位可能不一樣，還是要先了解目前系統在整個公司銷售環節中的定位如何。
但是該項目無任何資料，本身就是一個問題。沒有辦法，就目前來看最了解系統的是項目經理，隻能自己一邊了解系統、梳理邏輯及流程，一邊與項目經理溝通。
經過了解得知，目前的DMS系統是承接公司整個線下（經銷商）銷售業務的平台，主要為公司線下經銷商提供線上訂貨的能力。而試用系統可以看出目前核心流程就是下單及結算。諸如價格體系、可銷物料、對賬等也是圍繞核心下單和結算的輔助功能。
産品大緻功能子產品
第二步：了解業務人員架構、業務涉及角色、業務整體流程
對現有産品定位、功能點、核心流程有大緻了解後，需要了解先業務部門的人員架構及業務開展的整體過程，以便我們進行産品的規劃，使之更符合業務需求。
經過與項目經理及銷售團隊溝通，梳理線下銷售團隊相關的人員架構如下：
銷售人員架構
目前使用系統的主要角色有銷售、銷售經理及财務部人員。主要的業務流程為銷售代替經銷商進行訂貨代下單操作。
目前訂單流程
在了解清楚業務主要流程後，需要梳理下單相關的其他流程：
① 經銷商如何入駐到DMS系統？（即賬号如何建立）
② 下單後如何結算？是否支援線上支付？
對于經銷商從無到有及使用經銷商賬号下單，扣款等基本流程才算相對完整：
經銷商建立及餘額下發
第三步：梳理業務現狀，總結業務問題
梳理完成人員及業務流程，下一步就是跟線下銷售團隊溝通業務現狀，來分析總結業務和系統使用問題了。
由于銷售團隊跟IT部門不在同一座城市，且公司性質及組織架構注定IT部門屬于公司内的支援部門，咱沒辦法直接跟業務搭上線，隻能跟項目經理可勁兒的兩地跑，中間的過程辛苦就不說了，還經常出現約好了時間卻被鴿的情況。當然可能銷售團隊本身業務就很繁忙，也情有可原。終于功夫不負有心人，再經過N次的溝通後，算是把目前的業務情況摸了個清楚。
經過對業務情況的分析總結，提取以下幾個比較突出的問題：
業務問題：
① 前期經銷商下單，均為銷售代下單操作，而後續即将下放給經銷商自主下單（與代下單并存）
② 由于業務組織架構會經常變動，系統來不及更改導緻資料權限混亂
③ 業務側新增加了經銷商可以退貨，目前系統暫無流程支援
④ 業務側新增了臨期品處理，目前系統暫無流程支援
使用問題：
① 小程式訂貨端頁面簡陋，銷售都不想打開使用，急需優化
② 由于業務流程多處需要進行财審，财務希望更多的資料可以在DMS系統中展示，減少财務人員在不同系統中的切換
③ 系統隻有一個買一贈一的營銷活動，需要更多的營銷工具
梳理業務現狀并總結業務及系統問題後，咱們下次接着講如何進行解決問題的方案設計，也就是進行系統整體改版規劃。