軟件系統如何去評定好用與否，其實是一個需要長期去思考的問題。對一個系統好用與否的定義，在一定層面上可以說明使用者對這個系統的定位以及作爲這款系統對目標用戶的瞭解程度。企業在選用系統的時候，也要有自己的概念，自己需要的是什麼，這些功能實現到什麼程度，纔是自己的理想值。
前置思考：
首先，在定義優劣之前需要先定義用戶期望，只有滿足用戶需求的系統纔有存在的價值，而對用戶的滿足程度實際上就是我們可以拿來評判優劣的標準了。所以首先必須要明確：
系統是爲誰服務的（用戶）
用戶希望獲得什麼（價值）
用戶害怕什麼（痛點）
- 滿足度的評價指標
針對於用戶的期望和需求的整理，可以將維度分成以下幾個（實際上，大部分的管理類系統都可以從以下幾個方面進行評估）：
1.1 流程覆蓋度
流程線上化是很多管理型系統都需要走的一條很漫長的路，因爲幾乎後期所有的數據積累、流程優化、智能化都是基於先一步的流程線上化。所以往往各個層級的用戶都非常關注流程的搭建。
但同時，這也是一條一不小心就容易走歪的路。經常有用戶提線上化需求，在需求價值分析和溝通的過程中，他們往往把“線上化程度提高”作爲一個價值點。
不過這真的是價值點嗎？
不，切記，流程線上化是途徑而不是目的，管理系統並不是單純爲了用鍵盤代替紙筆。所有線上化的前提是確保流程數據的價值性或者效率的提升點（當然，還有線上化的實施難度）。
此外，在這個過程中，對系統和流程認知的固化也是十分危險的。比如，做倉儲做WMS就一定會有上下架嗎？盤點一定是對着實物數據和庫存數據進行的嗎？這個問題的答案可在後文中找到。
1.2 用戶驅動力
上文提到，流程線上化只是途徑，真正的目的應該是實現系統的自我驅動。如果只是單純的線上化，那麼從單次來看，或許確實可以省幾個人員，那麼長期看你的前進方向在哪裏？
在此，個人認爲系統的用戶驅動力可以分成2部分來看——數據驅動、策略驅動。
數據驅動，這部分是需要結合用戶關鍵指標來進行考量的。線上化的流程需要對關鍵數據和節點進行積累，提取關鍵指標，通過數據及報表的數據展現來驅動業務動作，並幫助業務進行決策（題外話：之前我們對用戶的報表需求管控是十分嚴格的，並不是單純因爲資源問題，更多的是希望用戶真正認識到“正確數據”的重要性，而不是報表越多越好）。需要注意對於不同層級/角色的用戶，數據是需要有區分度的。
策略驅動，在線上化的過程中，針對用戶對流程的期望進行策略設計，通過策略實現流程優化及對用戶指導。如WMS中的入庫策略、分揀策略，不是單純的用系統代替紙筆，而是直接由系統提供決策結果，減少用戶思考，實現最優方案。
1.3 系統容錯性
人非聖賢孰能無過，這句話用在系統使用過程中真的是一點都不過時，因爲我們無法確保使用者對系統的瞭解程度和個人的能力，所以在系統設計必須要系統的易用性、防呆和異常處理，以此來提高系統的容錯能力。
易用度：減少用戶思考，在適當的時候給用戶提示；瞭解用戶習慣和用戶語言，讓你的系統看起來更簡單易懂。
防呆：儘可能設計不會出錯或者更難出錯的流程。簡單的如二次確認或者入庫前的掃碼校驗等，都是系統的防呆設計。
異常處理：如果還是難以避免用戶犯錯，那麼還是要考慮必要的異常處理，最簡單的“單據撤回”功能就是一個很典型的異常處理。甚至有時我們需要特意設計一些“後門功能”避免用戶在出錯時無計可施而影響正常業務（這些功能往往需要高權限人員操作）。
雖然說對員工的培訓和管理是業務在推進系統實施中需要盡到的職責。但是，記住，人總會犯錯。我們可以通過系統記錄異常數據協助用戶進行員工管理，但單純通過提高系統使用門檻絕對不是最好的辦法。
1.4 用戶體驗
雖然說對於管理系統來說，用戶體驗的重要性可能確實沒有在2C應用中那麼重要，但是也是不可忽略的。不同於C端的體驗是側重於體感，B端的體驗依然是更側重於流程。
比如，筆者之前接觸了一款OMS，在新增發貨倉庫時，需要分別在多個頁面配置倉庫基礎信息、倉庫-物流對應信息、物流覆蓋信息、物流成本信息、物流時效信息等基礎資料，且系統並未提供任何指導，但是隻要少配置一個信息，這個倉庫都將無法使用，這對於不熟悉系統的用戶是十分不友好的，用戶學習成本也提高了，也容易讓用戶在不斷的報錯、嘗試中感到沮喪。
當然並不是完全不注重體感，系統視覺設計的美觀簡潔當然也可以提升用戶體驗。
1.5 安全性
安全性往往是用戶關注比較少，但是作爲設計者又不得不考慮的事。主要體現在權限的管控、審批流的設計（哪些流程需要審批，達到什麼條件需要審批，需要誰審批）、用戶數據的安全性、內容數據的安全性（如供應商信息、客戶信息的存儲、可見性）、數據隔離等。
對不同的企業，甚至對同一個企業不同的發展階段對不同維度的重視度必然是不同的，通常系統前期更關注流程，中期關注驅動，後期關注體驗，而安全和容錯則貫穿其中。
產品經理也需要根據當前企業的需求分階段性設計，分資源投入。這樣才能做到在不同的階段實現“好系統”的目標。
- 基於行業的適應度
最後基於個人的體會，我還想補充一點，系統需要對行業有一定的適應度。
什麼叫行業適應度？
目前的經濟環境下，行業內、甚至企業內其所運營和承載的業務往往都不只一種，比如電商公司的供應鏈按運營模式有自營、聯營，按品類更是五花八門，同時還結合各種營銷；比如倉儲按目的可分爲前置倉、品類倉、中心倉等；並且所有的行業、企業內部都在快速的發展着，嘗試着不同的新業務。
所以，一個好的系統其底層搭建，是需要能夠快速適應同行業不同業務模式的需求的。
這裏我來分享個負面案例：
從業初期，我有幸先後負責過兩個不同行業的WMS設計，電商的和生鮮的。
在電商WMS的設計過程中，對當時的電商倉儲場景基本完全覆蓋，所有的出入庫及庫內管控都是非常標準化的流程。
但是在接到了生鮮的需求後，幾乎是傻眼了，當時我們只做前置倉，基本的庫內作業就是驗收、分揀。因爲需要快速出入庫（前置倉是爲了滿足近距離的配送需求是不做倉內存儲的）的需求，且生鮮類目並不多，所以業務流程是不需要上下架的，通過線下的實體庫位劃分來管控；且生鮮類目的驗收規則（涉及到稱重）和普通商品也是完全不同的，而原來的那套WMS的流程是不具備任何可配置能力，如果直接套用反而造成現場浪費大量的時間在系統操作上，且原訂單的來源是固定來源於上游X系統，也沒有做標準的對外對接接口。所以當時爲了滿足生鮮業務的需求，幾乎是新做了一套WMS。
所以，如果企業存在多業務運營的可能性，或者本身就考慮到SAAS化，那麼前期就必須考慮到系統流程的可配置性去滿足後期業務的快速拓展。
蜘蛛表格——一站式企業服務雲平臺使用高端技術研發，不區分行業，可自定義搭建適合自己企業的系統軟件，操作方面簡單易用，歡迎大家體驗使用。
- 總結/寫在最後
所以好的系統來源於對用戶和系統定位的準確把握，通過對用戶期待的抽象，定義需求優先級，需要在資源有限的情況下合理安排迭代。同時不要忘記系統的可適應性設計，提升系統的適配度。