迷思二： 甲方只要把現有的流程全部轉化為資訊流程，人工作業改為電腦作業，一切現存問題就會迎刃而解?

反思二：資訊系統畢竟只是工具，擅長的是資料保存與再利用，系統化只是一種手段，但若企業內部對現況作業方式與流程，不思精進與正確分工，那變化的只是作業習慣，有可能短期內還會加重員工的負擔，原問題就更難改善! 

迷思三：通過資訊系統的導入，就是要將甲方長期的沉痾，藉由系統化的手段一次解決。

反思三：許多問題解決不在系統化與否，更何況長期的包衭大多無法一日竟功，實不應視系統化為萬病之藥石。 革新之步伐也應考慮各部門承受之度，如有大刀闊斧之意，當配壯士斷臂之勇，領導層如無此魄力，系統化只會淪為眾矢之的。

迷思四：系統化的優勢就是能快速反應所需，快速取得其果，而期望資訊化的綜效可以短期見效。

反思四：系統化的優勢是在作業過程所建立的資料，能保留下來，通過資訊手段透明化繼而重複查詢、統計、分析，來運用資料形成決策參考。而這通常很難立竿見影。系統建設如同建築之地基，而地基的穩固需要相關業務同仁落實基礎資料的建置，作業規範的遵循，從員工到各級主管，在日常作業都能認同且支援系統的運作，才能讓系統正確、完整地記錄所需資料資訊，而這只不過是基礎資訊的建構，後續才有機會在此基礎上，繼續延展應用，逐步實現資料智慧的願景。

迷思五：需求既然來自甲方，所以規劃只要配合甲方的想法，乙方盡可能地以系統實踐即可。

反思五：乙方顧問的專業除了系統技術，應該還有實施經驗，甲方畢竟不熟悉系統，也不一定能正確地表達核心需求，乙方顧問需要以案例、經驗，在調研過程中誘導甲方成員提供現況情境與表達需求與期待，再從中篩選分析出有價值的需求項。唯有瞭解甲方的情境與難處、期望與目標，才能設身處地規劃較適用甲方的方案。

迷思六：系統都是標準功能，不論任何目的，開發客制化應該盡力避免，以免維護困難。

反思六： 此迷思的問題在於，要或不要開發客制化的目的何在? 系統實施固然要有規範架構，才不易需求發散，導致專案失控，但系統功能與企業文化勢必存在差異。 適度客制的彈性來配合甲方企業的應用優化是可能需要的手法，不應單以系統標準功能為由，規避開發客制議題，然而專案若受限於成本時間範圍，二次開發客制化可列為另案階段性的規劃建議。

迷思七：反正需求在實施驗證過程往往改不勝改，檔製作落實很耗工時，所以有個初版規劃檔，以其為基礎來與甲方溝通，不必經過甲方的簽審確認，就開始開發配置，可以節省時間，檔呢? 參考就好。

反思七：事實證明，分析設計檔不落實，雙方溝通就流於口頭而無法具體，很可能雞同鴨講，分析設計檔也可以輔助想法的條理與澄清，雖然檔溝通確認會花費較多成本來完成，若無檔確認的環節，邊做邊改的方式就很容易重工，交付結果時，驗證的目標也不明確，消耗的工時成本將會更多更高。

迷思八：計畫永遠趕不上變化，所以計畫僅供甲乙雙方參考，然後就只能隨著變化調整，周周變，月月改。

反思八：再完美的計畫，的確無法避免執行過程中的意外，但是計畫一旦發佈執行，所有成員皆被設定了時程與目標，如果這時程與目標周周變、月月改，相信雙方的成員都會變得麻木無感，最後演變的結果就是今天只作明後天要交付的事，交付不出來，就再延遲，整體目標遙遙無期，也難保專案執行的品質。所以除了在規劃時要盡可能地考慮計畫細節，另外也要事先規劃風險控管，擬訂預防措施與矯正作業，目的是在最大程度地確保依計畫進行，不得已要異動時，也要慎重評估後，再發佈給成員，鞏固雙方團隊執行的信心。

上述分享皆乃個人經驗所得，無意指導甲方或乙方如何作專案，但希望藉由拋此粗磚能引來更多的迴響或批評，經過意見交流與想法交融，使甲乙雙方在執行專案時建立更多共識，而提高專案成功率，為吾心所願。