最近某客戶來電洽商「敏捷式專案管理與團隊合作」的教育訓練案，在跟客戶談完他們公司的內部工作流程之後，我的腦海浮現出多年前的一個親身經歷，這兩者之間竟有如此巧合的雷同之處，可見許多問題的根本原因，分析到最後其實都是殊途同歸呢！
故事是這樣的，過去我曾經因為崇洋媚外而使用某知名美商銀行的 Visa 信用卡，以為出差在國外的時候，刷這張卡消費會比較通行無阻，尤其是在美國境內。結果沒想到，根本就不是這麼回事！明明額度很大，卡片卻經常被美國店家說刷不過，回到國內刷卡卻又一切都很正常，讓我覺得很莫名其妙！
後來，該銀行的理專又一而再、再而三地打電話來兜售他們的理財商品，讓我不勝其擾，即便我都已經打過電話去客服中心客訴了，也只清靜了一小陣子，之後這種電銷行為又再度故態復萌！
當時的手機還沒有像現在可以封鎖來電的功能，更沒有 Whoscall 這種 APP，在沒有其他方法的情況之下，我只好憤而去電客服中心退掉信用卡！
客服人員非常有禮貌地詢問了我「大量」的「取消卡片原因」，在那個每家銀行都還會收信用卡年費的時代，客服人員甚至連免年費的「秘密優惠」都端出來給我了，我仍然是不為所動，堅持要退卡。
就這樣盧了好一陣子，客服人員終於屈服在我堅定的剪卡意志之下。沒想到，這最後一個動作還真的是把我給惹惱了！
「盧先生您好，好的，我們在系統中已經先『暫時』註記取消您的卡片了，要再麻煩您將卡片剪掉，寄回我們公司，地址是xxx xxxxxx xxxx xxxx 收，這樣才能夠完成取消卡片的動作喔！」
「你的意思是說，如果我不寄回去，你們就不會取消卡片，而且明年還會繼續跟我收年費，是嗎？」
「很抱歉，是的！公司的規定是這樣的！」
「別家銀行都是客服電話就可以處理完取消信用卡的動作，完全不用再麻煩顧客把廢卡寄回去，為什麼你們要這樣要求？」
「盧先生，真的很不好意思，這是公司的規定，還是要麻煩您將卡片剪掉之後，寄回我們公司….」
客服人員開始跳針，鬼打牆式地回應我，於是，我直接掛了電話、剪了卡片，並扔進了垃圾桶。從此，我再也沒跟這家銀行有過任何的往來！
這家銀行犯了一個很嚴重的錯誤，就是，為了讓顧客知難而退（放棄退卡），竟然設下了重重的退卡障礙！設計和審核通過這個流程的相關人員沒料想到的是，這根本就是在滿身怒火的不滿顧客身上，繼續地火上加油！
雖然各產業的狀況不太一樣，但我們大概都還可以知道，通常不滿意的顧客當中，只有不到
10% （甚至是不到 5%）的顧客會提出客訴，其他的顧客通常就這樣默默地流失掉了。如果這家銀行當下能夠向我保證「不再受到電銷行為的騷擾」，不管是不是真的做得到，我很可能就會打消剪卡的念頭，畢竟信用卡業務單位是被電銷團隊所陷害的！
巧得是，這家來電找我談教育訓練案的客戶，其組織內部也有這樣的類似流程設計！
該組織歷史悠久，人數規模龐大，因此我想像，各需求單位對於 IT 應用系統（網站）的增修需求數量理應相對龐大。而這個組織為什麼會想要為同仁們開設敏捷式專案管理與團隊合作的課程呢？其實痛點就是「IT 部門做出來的系統，經常遠遠不符需求單位的期望！」
有趣的是，開課決策單位竟然認為，這樣的問題是因為各需求單位「不懂得如何提出好需求」，所以要讓「提需求的人」來上課！殊不知，這個問題其實是整個工作流程的結構性問題！
我們就來看看這個組織的工作流程是怎麼回事，問題又到底出在哪裡。
問題一：重重路障卡需求
這個組織的需求單位如果要向 IT 部門提出系統的增修需求，首先就必須填寫一個頗具複雜度的文件。這份文件的內容不但要有用
Microsoft Visio 畫好的畫面和操作流程，還得說明這個需求的必要性、重要性和效益！
別說是完全沒 IT 背景的一般需求單位人員了，就算是要軟體設計專業背景的我來填寫這種文件，都未必能填寫得好、填寫得完整呢！何況，需求單位不是只該提出「要被解決的問題（what）」就好嗎？怎麼變成還得提出「如何解決（how）」的細部流程與畫面呢？
不光如此，IT 部門還規定，需求的提出必須以「年度」為單位，年度中間所提出的需求只能在下個年度排入審查，完全杜絕重要需求的插單機會！
這些做法就像上述美商銀行為退卡所設下的重重障礙一樣，在系統增修需求的道路上設下重重關卡。不管 IT 部門是有心還是無意，是官僚還是無知，總之，最後的結果就是讓多數的需求單位「知難而退」，不想花費巨大的心力去提出系統改善需求，後果當然是扼殺了組織效能提升的機會！
問題二：球員兼裁判
好了，就算有少數需求單位突破各種艱難，完成了合格的需求文件提交給 IT 部門，
IT 部門還有權進行下一道障礙：審查！需求文件格式是否完整，內容合格與否，都由 IT 部門自己成立的決策小組來認定。也就是說，不管 IT 部門是真客觀還是假公正，IT 部門其實可以想做就讓審查通過，不想做就否決退件！
這種看似民主開放，人人皆可填寫系統增修需求文件的規矩，骨子裡卻埋藏著 IT 部門可以獨斷的至高無上否決權！試想一下，在這種
IT 部門自己球員（需求實做者）兼裁判（需求審查者）的情況下，又有多少人願意繼續上場跟 IT 部門比賽打球（合作改進系統）呢？
問題三：人力不足金牌令箭
不管如何，總有人會闖過前面兩道關卡，此時，IT 部門還有第三道防線，就是「人力不足」的說詞！
這個說詞就如同是一道這樣的金牌令箭：「你提的需求很重要、很有道理，不過我們部門就是沒人沒時間（排滿工作了），明年請早！」需求單位面對這樣的說詞，通常也只能徒呼負負！
但奇怪的是，明明才剛審查過文件，IT 部門都還沒與需求單位進行詳細的需求討論和進一步的系統設計，為什麼可以這麼早就宣稱沒有人力和時間呢？這似乎一點也不符合邏輯！
看到這裡，也許你會認為，阿這樣的流程不是很正常嗎？大家不都是醬子做嗎？不然勒！？
[下篇]