既定改造方案
基於上一篇分析出的種種問題，我們將庫房人員的系統操作划分為兩大類。
第一類為貨物驅動的操作，這類操作主要隨着貨物而前進，人員不看或者看軟件的次數比較少，更多是對貨物的狀態進行系統上的確認和進行下一步的業務數據准備。
第二類為任務驅動的操作，這類在庫房目前特指質控的相關工作（這邊的領域會有其它的定義），更多是為了處理各種緊急情況、異常情況和純系統操作，我們將上面的各種情況抽象為一個個的任務，讓質控人員來處理一個又一個的任務。
貨物驅動模式
在貨物驅動的工作場景中，定義人員進行盡量少的系統操作，條件允許的情況下使用PDA代替電腦進行簡單的操作，條件不允許或者必須使用電腦進行的操作，設計遵循以下幾個原則
- 菜單和角色綁定，不再進行單獨的權限設置
- 菜單不再按照功能模塊進行拆分，而按照操作單元進行拆分，盡量減少菜單數量
- 所有貨物操作由一個掃描框起（靈感來源於搜索引擎），系統自動識別所需操作
- 強引導模式，將操作動線限定在比較固定的范圍內
- 減少列表的使用或原則上禁止使用列表
- 將視覺焦點定義出來，並將重點區域進行極誇張的放大
- 嚴格控制界面元素，將元素維持在盡量少的數量內
- 非重點區域，進行視覺上的略化
- 所有操作界面必須支持全鍵盤操作，盡量不使用鼠標
上面不是所有的設計原則，僅包含特別重要的部分。
任務驅動模式
在任務驅動的工作場景中，約定了幾個要點
- 任務找人而不是人找任務
- 為用戶提供充分的決策輔助
- 一個界面處理所有任務，無需切換
在這個前提下，我們選用了給客服提供的一套工作平台，界面設計上類似於Slack。
我們將所有任務虛擬成消息放在左邊的channel（slack位置）的位置，中間用來推送不同任務的處理界面，把各種內外部系統整合后放在最右邊欄根據不同的任務場景推送給用戶，用作決策支持。
當然在里面還做了很多小的工具，比如地址、電話的自動識別的，訂單的自動連接啊，多異常合並，不同質控或者質控和外部人員的信息互通，目的都是為了加速質控人員的處理效率，降低錯誤。
上圖為Slack圖
基於上面的兩個設計，我們就志得意滿的開始打造我們的新版WMS系統了，但是到此還沒完，中間出了一些變數，下篇我們再繼續講。