IT伯伯的部落格

接著我們來看看第二個案例吧！這是一個很傳統產業轉型公司的案例。

專案背景：T公司是國內知名的保溫瓶及相關產品的廠商，其在台灣的一部份物流服務由Y公司負責，Y公司是台灣傳產，因產線多已外移至國外而轉型為物流服務商活化閒置資產。

專案需求：因應T公司ERP升級：

1. 訂單EDI新了欄位
2. 出貨時必須記錄「出貨件數」並印出含「貨運公司託單號碼」的地址標籤
3. 出貨後當日將出貨明細上傳貨運公司以利貨況追蹤！

專案成員：

• PM/SD/PG：此專案我是校長兼撞鐘，一人包辦多數IT事務
• SA：Z小姐，負責將W小姐提供的需求產製規格書
• Business PM：營運端的需求都由W小姐提出，W小姐係Y公司多個倉的實際管理者。

專案內容：專案完全依W小姐提出的需求實作出來，完成了單元測試及整合測試後交給營運單位進行UAT，故事從此開始。

依W小姐的規劃，所有出貨的商品必須一件一件逐個掃描條碼由系統記錄後再計算出貨件數印出地址標籤，所以若有100張訂單，每張訂單10個品項，每個品項訂了10個，那麼營運單位需要掃描100x10x10=10000次！這讓營運單位的副理、主任、組長全都跳腳抱怨，因為：

1. 整個掃描作業太耗時且嚴重延誤出貨進度
2. 受限預算，其使用的掃描器為手持式，且條碼在每個商品的實際情況太多樣
3. 系統依材積計算的件數與實際出貨件數完全徹底不符

我實地參與營運單位的UAT，發現原來W小姐並未就此專案需求與營運單位進行任何會議討論溝通⋯⋯在經過協理核可下，我親自現場聆聽、觀察，並就我的角度提出建議，最後達成以下解決方案：

1. 出貨時由使用者輸入出貨件數，不需再掃描任何商品
2. 地址標籤的張數會依使用者輸入的件數印出
3. 取消材積計算

之後該專案順利完成！所以經由這個案例我們可以發現以下幾個重點：

1. SA接到需求真的是使用者需求嗎？End User需不需要參與專案團隊？
2. 當需求是錯誤的，該如何補救？
3. 需求需不需要求証使用者？

當然除了以上所列的重點之外還有很多面向，但那些不屬SA範疇我就不提了。

以上案例是今天的分享，我想經由這個案例應該可以讓後進少走冤枉路。

［2021/4/30 14:45］增加專案成員段落，並微調部分內容改善難以理解問題。

［2021/7/1 13:29］格式調整，增加縮牌並標記重點