記一次WMS的系統改造（2）-敲定方案

既定改造方案

基於上一篇分析出的種種問題，咱們將庫房人員的系統操做劃分爲兩大類。
第一類爲貨物驅動的操做，這類操做主要隨着貨物而前進，人員不看或者看軟件的次數比較少，更可能是對貨物的狀態進行系統上的確認和進行下一步的業務數據準備。
第二類爲任務驅動的操做，這類在庫房目前特指質控的相關工做（這邊的領域會有其它的定義），更可能是爲了處理各類緊急狀況、異常狀況和純系統操做，咱們將上面的各類狀況抽象爲一個個的任務，讓質控人員來處理一個又一個的任務。

貨物驅動模式

在貨物驅動的工做場景中，定義人員進行儘可能少的系統操做，條件容許的狀況下使用PDA代替電腦進行簡單的操做，條件不容許或者必須使用電腦進行的操做，設計遵循如下幾個原則

• 菜單和角色綁定，再也不進行單獨的權限設置
• 菜單再也不按照功能模塊進行拆分，而按照操做單元進行拆分，儘可能減小菜單數量
• 全部貨物操做由一個掃描框起（靈感來源於搜索引擎），系統自動識別所需操做
• 強引導模式，將操做動線限定在比較固定的範圍內
• 減小列表的使用或原則上禁止使用列表
• 將視覺焦點定義出來，並將重點區域進行極誇張的放大
• 嚴格控制界面元素，將元素維持在儘可能少的數量內
• 非重點區域，進行視覺上的略化

• 全部操做界面必須支持全鍵盤操做，儘可能不使用鼠標
  上面不是全部的設計原則，僅包含特別重要的部分。

  任務驅動模式

  在任務驅動的工做場景中，約定了幾個要點
• 任務找人而不是人找任務
• 爲用戶提供充分的決策輔助

• 一個界面處理全部任務，無需切換

在這個前提下，咱們選用了給客服提供的一套工做平臺，界面設計上相似於Slack。
咱們將全部任務虛擬成消息放在左邊的channel（slack位置）的位置，中間用來推送不一樣任務的處理界面，把各類內外部系統整合後放在最右邊欄根據不一樣的任務場景推送給用戶，用做決策支持。
固然在裏面還作了不少小的工具，好比地址、電話的自動識別的，訂單的自動鏈接啊，多異常合併，不一樣質控或者質控和外部人員的信息互通，目的都是爲了加速質控人員的處理效率，下降錯誤。

上圖爲Slack圖

基於上面的兩個設計，咱們就志得意滿的開始打造咱們的新版WMS系統了，可是到此還沒完，中間出了一些變數，下篇咱們再繼續講。