記一次WMS的系統改造（3）— 行進中的覆盤

行進中的波折

革新總會面對一些阻力和風險，一種新的觀念、一種新的模式要來替代既有的產品，歷來都不是一件簡單的事，在WMS改造這件事上咱們一開始就提出兩種概念貨物驅動和任務驅動，並找到一個標杆產品Slack就是爲了創建心理上的信任感，並從側面證實這件事不是一件純新的模式，提供成功案例來下降阻力，但在實際落地的時候仍是沒有多麼順利。

慣性的強大力量

有時候你們不支持和反對，並非真的不支持和反對，而是由於習慣某一種模式和狀態，而偏偏新的設計和他熟悉的不一樣。
習慣就意味着第一時間出如今腦中的就是那個樣子，因此很難想象出還有其餘的可能性，也沒有辦法接受其餘的可能性，這也就是所謂的想象力比較匱乏吧。
在作這一版WMS的過程當中，首先出現的問題是，產品經理的設計拉不齊。說完設計的方向和原則後，你們一塊作了一個功能的設計用於對齊設計理念，然分別去作了不一樣功能的設計，在階段彙總時當即就發現，絕大多數人的設計都沒有作到明顯的體驗改善。
當時發現這種狀況後，你們坐在一塊兒一頁一頁的覆盤每一個功能每一個點的。裏面其實包含了幾種狀況

• 思路上不自覺的、很天然的就轉回原來的設計思路上
• 遇見設計樣板中沒有提供，不能照抄的功能點，不自覺的用原來的模式進行設計，不能領會新的設計的風格要點
• 遇到苦難的流程，自動切換原來的模式
• 設計的負責人，面對現實的各類細節困境並不能堅決的執行設計思路
  面對這樣的狀況，其實咱們採用了兩種辦法
• 一遍又一遍的高頻開設計評審會，讓你們高頻的對齊設計
• 打破成本的幻想，毫不接受已經設計成這樣了、已經作了這麼多了、時間太緊了等理由，不合理的設計必須從新設計

三版設計以後（大體1周多的時間），再看整體的設計就頗有眼前一亮的感受了。不過沒想到的是最後給UED人員時還有一次反覆，由於他們不理解生產類的軟件系統的設計要點，包含的特別放大的部分和特別明確的分區，通過UED人員後反而都弱化了，因此在效果圖出來後還要作一輪調整。

除了UI設計的問題，還有業務架構設計的問題。

傳統業務系統的三個問題

UI設計進行中的同時咱們又覆盤了一遍即有系統的全部菜單，結果從中發現了一個具體的問題。
縱觀整個WMS，由三個部分功能組成：

• 業務主流程
• 操做容錯/運營容錯
• 系統容錯
  業務主流程，爲倉儲而設計的主要業務操做節點，業務主流程通常由關鍵節點和附屬節點組成，好比倉儲裏面有個關鍵的業務節點叫作「上架」，附屬的節點就可能有不少，好比儲位推薦、路徑推薦、任務分配等等
  操做容錯/運營容錯，生產輔助的軟件是一個強人員屬性的軟件，軟件的基礎功能就是指導和記錄人員的生產動做。無論操做員如何仔細，人員操做在一個比較長的時間範圍和比較多的人數範圍內，錯誤都是不可避免的，操做錯誤須要由系統來提供補救的功能。
  系統容錯，WMS每每使用環境的條件都不會太好，遠離IDC，遠離鬧市，網絡條件不好；服務器和終端的硬件條件每每也不好；並且軟件開發自己也不能徹底避免BUG的產生；可是由於生產輔助軟件的特殊性，每個軟硬件、網絡環境等等不可預知因素產生的異常，都會影響到具體的貨物，因此通常也會提供一些（或不少）業務工具來進行異常後的生產流暢，確保貨物生產不會由於軟件緣由而沒法進行。
  即有的系統中，這三部分是混合在一塊兒的，這屬於頂層設計問題，新的設計中最開始只考慮了單功能或功能流的使用體驗優化，如今就要將重構頂層設計考慮進來了。
  業務主流程是正常的系統節點，系統應該圍繞着這部分功能，將附屬的節點巧妙的融合進去，而後把絕大部分操做容錯和系統容錯用技術手段處理掉，確實須要人工參與的，須要很慎重的設計一個異常流程，且不能散列放置要讓它與正常流程造成閉環。
  最終咱們設計的方案是
• 運營容錯，由於涉及一個系統的動與靜的問題，因此要單獨拎出來，作一個新的技術方案處理。
  ::（系統的動與靜會單寫一篇）

• 系統容錯，儘可能讓系統自主處理，如非阻塞不設計人工干預流程。

  頂層設計的重要性

  開始僅僅是想改善一下倉儲人員的使用體驗，從UI的優化開始一直推導到設計的規範，再發現運營容錯的技術方案系統的動與靜，還有系統容錯軟件自動化處理（可能會今後開端WMS的智能化）。
  這裏咱們有一個體悟，一個軟件的頂層設計是極其重要的，點線面歷來也不是單獨存在。後續我想咱們部門每一個軟件都會有一個業務架構師，這麼一我的對整個軟件的研發太太重要了，他可能不是專職的但崗位職責必定要明確。
  下一篇離題一下，寫咱們在另外一套軟件上面的優化成果
  『2018年12月24日 廣州白雲』