先講一個小故事：

一個晚上，有個人在路燈下找東西。

路人問：“你在找什么？”

他說：“在找鑰匙。”

路人又問：“你在什么地方丟的鑰匙？”

他回答：“在家門口。”

“那為什么不在家門口找？”路人好奇地問。
? ? ? ?“因為家門口沒有燈。”

作為漢捷顧問，在長期的研發管理咨詢工作中發現，許多企業管理者如同路燈下找鑰匙的人一樣，明明是管理出了問題，不在管理上下功夫解決問題，而是寄希望于買個工具來解決問題。當然花錢買工具要比轉變管理理念、學習和掌握管理方法要容易，但問題的關鍵是，路燈下沒有鑰匙，在路燈下找鑰匙只會一無所獲。

工具就是工具，不能替代思想和方法，一些企業在沒有理順業務流程，先引入了工具，結果白白花費了工具的費用和工具推廣的費用。例如，某個組織項目管理混亂，買了價格昂貴的RPM（IBM出的一種項目管理工具），RPM又不會為項目制定合理的計劃、進行有效的項目監控，最后該工具只是成立工時填報工具，用于統計項目成本。還有個企業，軟件需求一直是項目的非常薄弱的環節，然后就買了一個著名的需求管理工具DOORS，但是他們基本上連需求文檔都沒有，DOORS也不會幫助他們挖掘需求、寫文檔，結果昂貴DOORS一直閑置，軟件需求問題也沒有什么改觀。

當一個企業先進行業務流程梳理，并經過一段運行趨于穩定時，可能會發現某些環節需要工具做支持，原有的模板或小工具已不能滿足要求，這時可以考慮引入大型的工具，比如一些項目管理工具，集成了項目計劃和監控；或者測試工具，管理測試計劃、用例、缺陷等等。此時，工具的需求是非常明確的，更有可能選擇一個適合業務流程的工具，有了合適的工具會有助于流程的運行，工具不再成為了擺設。

當一個企業陸陸續續引入一些工具之后，再加上組織原有一些工具，如ERP、OA等，就產生了新的問題：不同工具所包含的信息有重疊部分，如何保證信息的一致性？有的工具需要另一個工具為它提供某些信息，那么二者二者能否互通、并且信息的格式是雙方都可識別的？當有人、特別是管理層需要一些綜合性的信息時，是否能方便地通過一個視圖就能展示出，還是要到各個工具中分別查看？這樣，每個工具局部用起來都很順，但從企業全局來看，每個工具都是一個個信息孤島。

因此，工具的引入在最初就要進行很好的策劃，保證一系列工具是個有機的整體。近些年，叫企業架構（Enterprise Architecture）的概念被提出來， 其作用是將跨企業的、以及企業內部的流程、工具優化成為一個集成的環境，確保有效地管理企業信息，走出信息孤島。

綜上，先引入工具之所以會失敗是因為本末倒置，本來應該是讓工具支撐流程、方便流程的運轉，而不是流程去適用工具。工具的引入要系統地規劃，確保整個組織信息是兼容互通的，避免信息孤島的產生。

最后再講一個小故事：

從前有一天，一個人找到裁縫列維，因為他聽說列維能做出便宜的民族服飾。衣服做好了，這個人試了試，發現衣服根本不合身。

“看，”他說， “上衣后擺太長了。”

“沒問題，”列維回答，并指導他怎樣弓起后背以把上衣松弛的部分挺起來。

“那右邊袖子怎么辦？長了三英寸。”

“沒問題，”列維重復道，并給他示范怎樣斜著身子伸長右臂以使得袖子合適。

“那褲子怎么辦？左腿太短了”。

“沒問題，”列維第三次說道，并上前教他怎樣提起大腿，這樣盡管走路跛得厲害，可是衣服看起來合身了。

沒有太多的抱怨，這個人蹣跚著走上街頭。有個陌生人叫住他問：“打擾一下，我想知道，你穿的是新衣服嗎？”

這個人很高興有人注意他的新衣服，“是的，為什么這么問？”

“哎，我正準備做套新衣服。誰給你做的？”

“列維，沿著這條街一直走。”

“好的，非常感謝。我真應該找列維為我做衣服。”

“為什么？”

“能為你這樣的瘸子做出這么合適的衣服，更別說我了，他可真是個天才！”陌生人說著就匆匆離去了。