大家夏天看著荷花盛開，不知道有沒有發(fā)現(xiàn)一個有趣的現(xiàn)象。荷花第一天開放的只是很小的一部分。到了第二天，他們就會以前一天的兩倍速度開放。到了第三十天，就開滿了整個池塘。你若不仔細觀察，很多人會認為，到第五天，荷花會開放一半。若你這么認為，那就大錯特錯了。到第29天，荷花僅僅開滿了池塘的一半。最后一天，荷花才會開滿另外一半。可見，最后一天的速度最快，等于前29天的總合。

　　這就是一個企業(yè)管理家提出的著名的三十天荷花定律。

　　CIO，作為企業(yè)信息化項目的總設(shè)計師，該從這個定律中獲得如何啟示呢?

　　一、 掌握量變到質(zhì)變的關(guān)鍵。

　　任何事物都有一個量變到質(zhì)變的過程。飛蛾破繭，小鳥出殼，都需要前期重要的積累，以及最后一天加速的破殼而出。其實，我們搞信息化項目實施也是如此。

　　我在企業(yè)中，負責(zé)過多個信息化項目，如企業(yè)管理軟件部署或者操作系統(tǒng)的升級，都會有這種感受。員工剛開始還都很排斥信息化管理系統(tǒng)，可是，在某一天，其突然接受他，喜歡他。其實，這就是一個質(zhì)變到量變的過程。在這個過程中，哪些因素在起作用呢?

　　一是用戶在實際管理中，體會到了系統(tǒng)給他們帶來的好處。其實，信息化管理系統(tǒng)，無論從什么角度看，確實可以提高員工的工作效率。但是，用戶剛開始為什么會不接受它呢?這主要是因為員工已經(jīng)習(xí)慣了以前的操作方式，不愿意改變，這是人的惰性，基本上每個人都有這種想法。另外，從局部看，可能確實會增加一部分人的工作量，但是，其可以節(jié)省其他大部分人的工作，從整體來看 ，企業(yè)的工作效率還是有提高的;可是現(xiàn)在遇到的問題是，很多員工不會站在企業(yè)的高度上來看待問題，往往更多的關(guān)注自己的利益得失。所以，他們剛開始會對系統(tǒng)有本能的排斥。但是，隨著信息化系統(tǒng)實施的深入，我們幫他們解決的實際需求越來越多，他們發(fā)現(xiàn)系統(tǒng)不但沒有減少他們的利益，相反，提高了他們的工作效率與工作結(jié)果。所以，他們就從剛開始信息化項目的抗議者變?yōu)榱诵畔⒒椖康耐苿诱?。這就是一個量變到質(zhì)變的過程。故，信息化項目從質(zhì)變到量變的第一個關(guān)鍵，就是對于用戶提出的需求，作為企業(yè)信息化項目的負責(zé)人，一定要重視，要不折不扣的加以解決。在解決過程中，我們不但要注意解決的質(zhì)量，而且，而要注意解決的效率問題。而且，在有時候，解決的速度問題比質(zhì)量問題更加重要。

　　二是由于一把手的積極支持，讓他們覺得排斥信息化項目，就是跟他們作對。我非常有幸，有一個對于信息化管理非常重視的領(lǐng)導(dǎo)。每當我們集團上信息化項目時，得到了集團副總的鼎力支持。如前不久，我負責(zé)公司的各個管理系統(tǒng)的整合工作。在為期近半年的項目周期中，副總在多個場合，如管理層會議上，都多次強調(diào)這個整合項目的重要性;還多次表態(tài)，這個信息化項目非成功不可，不成功便成仁。在多個場合，立場鮮明的表述了他對于項目的支持。從而，讓其他對這個項目還持保留態(tài)度甚至反對的員工，意識到，若不積極配合這個信息化項目，就是跟一把手作對。所以，他們看到反對無效，那就只好接受他。所以，我們在信息化項目推進時，無論項目的大小，若都能夠借助一把手的權(quán)利，借助一把手的權(quán)威，來推動信息化項目，來實現(xiàn)從質(zhì)變到量變的飛躍，必定可以起到事半功倍的效果。所以，在信息化項目之前，跟一把手進行充分的溝通，讓他們認識到信息化項目對于企業(yè)管理的重要性，獲得他們毫無保留的支持，對于實現(xiàn)這個量變到質(zhì)變的轉(zhuǎn)換，非常有效。

　　在項目實施的過程中，一定要盡快促使這個量變到質(zhì)變的過程，要提高荷花開花的速度。

　　二、 項目的質(zhì)量好壞往往不是簡單的數(shù)量累加。

　　有些人在信息化項目管理時，有個誤區(qū)。一位項目質(zhì)量的好壞，只是數(shù)量簡單的累加而已。以至于當領(lǐng)導(dǎo)問他們現(xiàn)在項目進行的如何時，他們總是習(xí)慣的講出，現(xiàn)在解決了多少用戶的問題。

　　其實，利用這個角度來評價信息化項目使用的效果的話，是非常不合理的。有可能我們確實解決了用戶許多的問題，如單據(jù)可以不通過修改可以直接打印出來使用，又或者單據(jù)上可以實現(xiàn)電子簽名，這些問題的確是用戶所面臨的問題，但是，這些需求及時實現(xiàn)了，給企業(yè)創(chuàng)造了多少的價值呢?若用戶現(xiàn)在遇到庫存不準，在系統(tǒng)帳上經(jīng)常出現(xiàn)負庫存。若我們可以通過系統(tǒng)控制，防止負庫存的出現(xiàn)。明顯，后面這個需求，比前面幾個需求重要的多，甚至比他們累計的價值還要高。

　　類似的情況，在信息化項目管理中，經(jīng)常會出現(xiàn)。由于我們在信息化項目中，主次輕重不分，只是為了討好企業(yè)管理者，我們盡挑一些軟骨頭吃，導(dǎo)致一些更加有價值的需求被累積起來，無法實現(xiàn)。最后，解決企業(yè)用戶需求的數(shù)量是多了，但是，項目的質(zhì)量就長時間在原地踏步，沒有多大的進展。

　　這就是我們沒有認識到項目的質(zhì)量往往不是數(shù)量的簡單累加。

　　所以，我們在項目開始實施之前，要好好的進行需求調(diào)研，進行項目規(guī)劃?？纯茨男┬枨竽軌蚪o企業(yè)帶來更多的價值;哪些需求可能只是表面上的東西，不會給企業(yè)的管理帶來實際的改善。在項目開始時，把這些收集起來的問題，好好的排排序，先把重要的給解決了，然后，再來解決剩余的問題。要知道，有時候，解決排在第一位的用戶需求，其帶來的影響，可能比解決剩余的問題都要大。

　　所以，我們在安排項目計劃的時候，不要學(xué)荷花。而是最好把荷花定律反過來做，第一天就開滿一半。把重要的問題優(yōu)先解決了，就可以起到立竿見影的效果，可以在最短時間內(nèi)，獲得企業(yè)用戶的支持，讓他們接受這個信息化管理項目。

　　三、 信息化項目要持之以恒，越到后面項目提升效果越快。

　　我負責(zé)過多個信息化項目管理，都有這種感受，就是項目剛開始的時候，可能進行的比較順利;可是，進行一段時間后，就會遇到阻礙，覺得萬事都不順利;但是，再堅持一會兒，過了這個坎兒，項目后面的工作就越來越順利了。

　　其實，我們在跑步時，也會有這種之觀點感受。如我們現(xiàn)在跑一千五百米，剛開始的四百米可能覺得非常的輕松;可是到六百米到一千米的時候，就會感受到特別的累，因為人已經(jīng)快到了極限;但是，非常的奇怪，一突破一千米的關(guān)口，再跑的時候，我們就覺得不這么累了。這就是突破極限的問題。

　　其實，信息化項目推進時，跟這個現(xiàn)象非常的類似。

　　信息化項目剛開始實施時，一方面用戶出于一種興趣，一種好奇心，或者說，對于信息化項目存在一種過高的期望，所以，對于信息化項目還是比較歡迎的。但是，隨著信息化項目的深入，流程的改進、操作方式的改變，開始觸及到他們的即得利益，而且，由于剛開始對于信息化管理期望過高，發(fā)現(xiàn)以前的期望無法實現(xiàn)時，他們就會對系統(tǒng)進行地處;所以，信息化系統(tǒng)就會慢慢的變得舉步維艱。但是，我們能夠挺過這個難關(guān)，迅速解決用戶的實際問題，讓用戶重新恢復(fù)對信息化管理的信心，突破這個關(guān)口以后，則項目后續(xù)的工作就會變得非常的順利。

　　但是，很多企業(yè)，由于這個難關(guān)無法突破，或者由于時間過長把用戶的耐心都消磨光了，使得信息化項目不得不以失敗而告終。

　　所以，我們在信息化項目的實施過程中，若遇到一時的瓶頸，一時的挫折，我們不要放棄，要堅持。陽光總在風(fēng)雨后，我們要有信息，要堅持，要持之以恒，也許，渡過了這個難關(guān)后，就可以引來陽關(guān)大道呢。

　　荷花是越到后面，開的數(shù)量越多;信息化項目也是越到后面，其提升的速度越快。我們做信息化項目管理的，一定要持之以恒，而不能半途而廢。

　　四、 需求解決要到位，不要留有尾巴。

　　在解決用戶的具體需求時，要注意，要解決到位，而不要留有尾巴。

　　我以前在企業(yè)里部署郵件系統(tǒng)的時候，為此還處罰過一個手下。那時，郵件系統(tǒng)剛部署完成，我因用戶的請求，對于郵件進行了簽名設(shè)置。我根據(jù)企業(yè)的信息制定好簽名模板之后，就讓我的手下給各個員工配置簽名文檔?？墒?，由于我手下不小心，把簽名文檔給用戶配置的時候，沒有把簽名文檔上的傳真號碼改過來，我以前是以采購部門的傳真號碼作模板的，而他在給業(yè)務(wù)員進行簽名設(shè)置的時候，由于一時疏忽，只修改了名字，而沒有修改傳真號碼。這就導(dǎo)致客戶發(fā)銷售訂單的傳真時，客戶發(fā)了好幾遍，銷售員都遲遲沒有收到。剛開始還以為是傳真機出現(xiàn)問題了，后來跟客戶一核對，才發(fā)現(xiàn)是傳真號碼出現(xiàn)了問題。為此，我也有責(zé)任，在制作模板的時候，沒有注明清楚。為此，我跟我手下都受到了處罰。

　　所以，我們在實現(xiàn)用戶的需求時，不要留有尾巴。若需求解決的不到位，留有尾巴，那還不如不解決。因為有時候反而會引來更大的麻煩。

　　如何才能夠使得需求不留有尾巴呢?最簡單的做法，就是需求實現(xiàn)后，自己進行測試一下。如這個簽名文檔設(shè)置好以后，我們自己寫一份郵件，看看簽名文檔設(shè)置有沒有錯誤。有時候，可能我們自己出于業(yè)務(wù)不熟悉等原因，還不能馬上發(fā)現(xiàn)問題，此時，我們可以跟用戶一起，測試需求。當局者迷，旁觀者清，有時候，用戶可能比我們的眼睛更加亮，可以一眼看出問題所在。所以，需求實現(xiàn)了，不要就那么一了了之，要進行測試才行，最大程度的消除尾巴。

　　三十天荷花定律，告訴我們越到后面，事情越關(guān)鍵，越重要。若我們需求實現(xiàn)了，但是對于需求的最后一道關(guān)口“檢驗”把關(guān)不嚴，則很有可能給需求留下尾巴，最后是竹籃子打水，一場空，以前的工作都白忙活了。

　　三十天荷花定律，給我們這些企業(yè)信息化項目的管理人員，正反兩面的指導(dǎo)，我們一定要引以為鑒。