No.18

今天看到一則名為(誰說數大便是美？ 系統也有邊際效應遞減問題)的文章，該文提到幾個觀點我還滿認同，

雖然文中是以BPM專案為主出發但其實任何系統看來我認為應該是通用的，藉以分享個人心得

 

文中提到邊際效應遞減，其實這是經濟學上的東西，簡單來說就是同樣的東西在條件不變的情況，投入與產出

效用比經過一定的時間下，會開始呈現遞減，套用到系統上來看，使用者的需求永遠是無止盡，今天可能需要個報表，

明天可能需要個什麼維護功能，然後經過一定時間後常會發現系統功能愈開發愈多、報表愈來愈多，可是End User對系

統的效用感或滿意度並沒有增加，反而抱怨愈來愈多

 

其實原因可能在於對於系統需求的評估，並沒有真正打中紅心，也就是說End User提的新需求是否真正的是一個不得不

做的需求，又或是只是滿足當下所想要的東西而已，白話一點就是對於需求的評估能否看到需求問題背後的問題核心點

，以往對於有求必應的開發做法必須被捨棄，才能跳脫框架，呈現不同的思維角度

 

有時候問題的徵結點在於作業流程的錯誤，然而系統的導入的成效在一定程度上必須是作業流程也要跟著做良好的調整

，否則光只是依靠系統而想提升作業成效是不可能的，反而只是把原本paper work改為type work而已，文中提到「企業競

爭力的改善不是基於系統的改善，而是業務流程的改善，系統僅只是一個資料傳輸與展現的媒介，重點還是在如何規劃

有效率的業務流程。」

 

另外對於產品開發的領域上來說亦是如此，一項產品的改善及成熟度絕非只是落入功能隻數的直覺性評斷，能否藉由該

產品的導入或功能的提供改善作業流程，解決80%以上(80/20理論)使用者作業的困擾，相信才是客觀的評斷。而產品設計

者亦必須以發覺需求背後真正的核心為原則，評估產品功能的提供與改善，才不會落入投入資源愈多，但產品認同感及

滿意度並未成正向成長的困境中。