速度緩慢的系統，是無人樂見的情況，因為緩慢回應而導致的漫長等待時間，會大幅消耗企業的整體生產 力。尤其當隨著時間日久，且問題依然未獲解決時，使用者勢必會開始失去耐性。 畢竟當必須面對重複發生的效能問題時，即使是再有耐性的使用者也會開始抱怨。尤其當高級管理人員開始抱怨，資訊部門的每一位成員都覺得那是針對他們而來，最終使得負面情緒瀰漫在整個團隊中。
沒有任何一個團隊喜歡當輸家，但光是要在日益複雜且相互依賴的網路環境中，迅速辨識出效能問題根源，本身就是一項極大 的挑戰。然想要快速找到解決辦法的天性，往往反而造成無所助益的程序、工具和行為，而這正是造成失敗的原因。
每一個資訊團隊都希望能表現最佳一面，因此了解一 些常見的失敗問題或許能有所助益。因此，可以參考由 Enterprise Management Associates 協會(EMA)進行的最新研究，探討運用一些世界頂尖效率團隊的實務作法，進而避免前述失敗狀況一再重演。

失敗問題一：反應模式耗費太多時間
不可否認，每個資訊團隊都會在反應模式中耗費一些時間，畢竟每間公司都會遇到不預期的服務中斷。然而作業團隊好壞的衡量標準，往往取決於主動反應處理效能問題的頻率。若資訊團隊在使用者回報問題前，早已開始著手尋找解決方案，那此時團隊故障排除時間已搶得先機。反之，若是透過使用者的投訴才知道問題的存在，最終勢必將會耗費太多時間在解決問題上。

避免問題一的措施
根據最近一項由 EMA 公布的研究報告指出，工作效率較差的團隊，傾向使用較多工具來監控不同的技術（網路、伺服器、應用程式），相較之下高效率的團隊，則傾向使用較少工具，其中部分工具監控較廣泛的技術範圍。該份研究報告顯示，使用較少量工具但具備較廣泛的技術範圍，可為團隊帶來較多優勢，因為全面透視的能力和依存關係，相關警報可協助早期偵測問題的形成。
團隊要搶先在使用者發現之前，預先察覺到問題需要相當努力，必須設定以臨界值為基礎的監控警報。
這些警報臨界值應根據過往的效能資料來設定。如此一來，可設定這些臨界值來達成精確的平衡，在不致於收集到太多錯誤警報的時，依然能找出潛在的問題情況。

失敗問題二：解決問題耗費太多時間
如前面所說的，團隊要在複雜的網路環境中，辨識出問題的根源，本身就是一項極大的挑戰。不幸的是，許多資訊團隊採取沒有助益的程序、工具及行為，而最終導致失敗的發生。
在此狀況下，分級小組必須在無法全面透視問題的情況下，試著解決網路問題問題。換句話說，資訊團隊往往必須靠猜測來作業，進而造成潛在的問題，然隨著各個成功診斷路徑無法找出問題，在網路問題時間逐漸拖長下，最終將導致使用者越來越惱怒。
避免問題二的措施
在前述的 EMA 研究報告中，指出團隊使用監控工具數量與耗費在解決問題上，彼此之間的時間關係，使用更多工具不一定能加速解決問題。 這種「工具各自為政」的監控作法，通常會使平均解決 時間（MTTR）大幅延後，而如果資訊作業環境比較複雜，問題會更加嚴重。
此外，當資訊團隊僅運用 1~3 種監控工具，耗費在其他任務和專案上的時間，約佔整體時間的 33%，相較與使用四種工具以上的資訊團隊，大約多出 10%~20% 時間可用於其他有意義的專案上。

失敗問題三：無法找到及解決問題根源
當網路效能問題越複雜，資訊要迅速找到根源的可能性就越低，尤其牽涉到中介軟體、應用程式和資料庫之間的內部依存關係情況時，自然就更難以找出真正原因。當分級小組在找出問題的真正根源，遭遇到難以解決困難，為急於快速找到修正的方法，通常選擇快速重新啟動伺服器，以至於會對網路效能造成衝擊。
雖然此種做法可讓網路應用服務回復到正常運作，但事實上此種做法使得同樣的問題一再發生 。高效率的資訊團隊，會發現此方式可能會造成需仰賴重新啟動來解決的服務事件未來越多，最終花費在故障排除反覆出現問題的時間比例，自然會愈來愈高。
避免問題三的措施
平心而論，要找到所有發生問題根源的機率並不高，然高效率資訊團隊會找到較多的問題，因此會造成較少前述的「廢止問題」，而關鍵在於能否使用較少的工具，達成有效辨識根源問題的辨識。
這項訣竅，在於團隊所運用工具可否監控多種技術，以對其環境提供更整體性的畫面。根據 EMA 研究報告指出，獨立網路管理工具往往無法在其他工具收集的數據中，呈現內部應用程式的依存關係，而多功能管理工具則能呈現相關依存關係，並將其以多種形式呈現到網路作業上，如可供自訂的儀表板和報表，以及依存關係警報。
可提供整合全體環境檢視的單一工具，提供資訊團隊所需的多項優點，如可在使用者回報問題之前收到警報，也可更快解決問題。如此一來，高效率團隊可辨識出更多問題根源，且可在沒有壓力的情況下，於在使用者惱怒之前先找出問題根源。

高效率資訊團隊因為使用較少的管理工具，所以反而可比使用者更快發覺網路異常，有助降低使用者抱怨的比例。

高效率團隊雖然僅使用 1~3 種網路監控工具，卻反而可儘早找出問題根源，且多出 10~20% 時間可用於其他專案上。