未來時速 第十七章


    正如熱門概念往往會引起的後果那樣,哈墨和錢丕關於再設計過程的簡單但深刻的概
念,引發了一股商務研討會、培訓班、大學課程、雜誌文章和各種專家出版「效顰」專著的
熱潮。1在這個過程(一語雙關)中,各式各樣的商務人員用「再設計」這個詞來為幾乎任
何組織變動做辯解。兩年以前,一家大電腦公司開始了「再設計」的努力,把人事部門大部
分人都解雇了,沒有留下人來合理地處理實際上裁員的後果。這家公司沒有人事專家來指導
變動,犯了一些錯誤。它買斷了自由打工者的合同,在他們還沒干更多工作之前就把他們打
發走了——盡管公司已經支付了他們的服務費。新晉升的人本來很受賞識,現在卻被解雇
了,因為他們在現有等級上是資歷最淺的。要把這種行為看作合理化裁員是很難的,而且也
絕對不是再設計。邁克爾·哈墨在一次談話中曾說:「有時再設計幾乎是指任何事情,但絕
對不是指再設計了。」盡管有些人對這個概念太過熱心或利用它來掩飾裁員,但時不時地審
視您的過程,使它們更有效,並把低效率排擠出去,這個想法現在卻比以往更為重要。
    11998年10月在因特網上對「再設計」一詞的搜尋找出了189940個文件,內容
從關於2000年日期計算問題的文章到一個被描述為「玩笑的嚴肅一面」的研討班,無所不
有。文件數目比其他重要的商務話題大得多——例如,比知識管理的話題多。
    創建一個新過程是個重大項目。您應該有一個明確的成功定義,在時間和任務方面有明
確的開端和結束,有中期成果和一個預算。最好的項目就是:員工們心裡有清楚的顧
    客情況。這也運用於過程項目。顧客可能在公司外或在公司內,但是概念卻是同樣的:
這個人將怎樣使用您在開發的產品或過程?這個產品或過程比以前的那個好在哪裡?
    您也需要在各個級別上理解交換。每個項目都有交換。在軟件項目裡,管理方總想要產
品特徵多樣、小型,並且花費甚少、一夜之間就做好。經理們什麼好處都想要,因此必須明
白無誤地理解交換。如果您善干把產品制作得特徵多樣,並不得不把它做大些,那麼您就不
想讓管理方過後說,您本來應該犧牲幾個特徵,把產品做得小一點。如果您限製成本,那麼
您就不想讓您管理方說您本來該花同樣的成本但包括更多的特徵。一個建造數字過程的項目
也是同理。
    您面對著變化中的要求應該靈活應變,但又不應該緩慢地做修改以使原來的設計目標失
效。您應該有果斷的決策過程來評估變化,包括重新評價原來項目目標的規定。

更新產品交貨過程
    數年前,在准備妥當以便裝載運輸的那一天,一次WindowsNT的重要發貨幾乎被耽擱
了。並不是因為暢銷產品有缺陷或某種其他產品開發的問題,而是因為一隻硬紙箱不見了。
產品包裝箱的藝術設計留在一個人的桌上,而那人又恰好在那天去度假了。藝術設計圖一直
在那裡,直到箱子完工了還沒能按期到達制造部。而離發貨最後期限只剩兩天了。但包裝箱
通常需要10天才能生產出來。制造部的操作工日夜加班才給我們生產了足夠的箱子以便按
期交貨——箱子上的油墨都還沒干。
    在這次事故之後,這個小組負責營銷材料的經理把大家召集在一起分析毛病出在哪裡。
這個小組由12名員工組成,是來自公司內兩個處和兩個外部銷售商的人員,經理提了一個
問題——也是我在微軟公司常提的一個普通問題——「為什麼這個房間裡有那麼多人?」在
任何會議上我只想要最重要的決策者參加。其他人都應該離開,去解決其他問題。如果您在
房間裡發現多於3∼4名決策人,那麼您就能肯定僅僅是這麼多人數就是問題的一個主要部分。
    這個經理要求小組簡化過程並找出該部門其他十幾個產品類似的協調問題。「找出一個
問題模式來,然後為全部產品解決這個問題。」他說。
    在短期裡,小組建立了「肯定性承認」的原則,意思是,一次工作交接要等流程中的下
一個人說:「我拿到了」才算完成。不能再盲目地把東西從門窗橫檔間扔過去了。
    這個小組還把交接的次數從5次減到3次。減少交接次數也許不像一個重大步驟,但任
何消除「接觸」的步驟都會減少犯錯誤的機會並有助於保證質量。1997年,在一家新工廠
裡,戴爾電腦公司重新設計了它的生產線,以便削減一半處理硬盤的次數。該公司制造部硬
盤的退貨率降低了40%,PC總故障率降低了20%。
    在微軟公司,各部門負責把產品組件送到制造部去的人開始召開最佳作法會議。我們在
愛爾蘭制造銷售給歐洲的產品,那裡的高級經營主管乘飛機來談美國慣例給她的公司帶來的
問題。我們隨後找出了給制造准備材料時的一些過程問題。例如,有一次我們在產品包裝箱
上用了特殊字體,卻沒有意識到這種字體並不是在全世界都有的。這使得我們好幾個產品都
投放得晚了,沒趕上在澳大利亞的假日消費季節。這就損害了盈利。
    所有部門的過程擁有者們聚在一起,給一個全球性生產過程下定義,這個過程將利用數
字工具來改進協調。我們創造了一個應用程序來追蹤所有產品組件,包括箱子、箱子上的標
簽、藝術設計和實際的軟件編碼。產品經理和其他僱員們有了網絡上關於所有這些組件的信
息,就可以容易地追蹤他們制造過程的現狀。我們有一個單獨的、定義清楚的電子生產過
程,它除了其他好處之外,還能保證我們在改進流程上的任何步驟,這些步驟會在整個公司
裡通用。
    在這個同樣的時間框架裡,我們也開始給公司的制造部搞外部采購原料。這一變革意味
著我們必須給「交鑰匙」制造方式提供完整的材料。過程必須更清楚——取決於過程,而不
是取決於人。一個目標就是:「經營部不應該總是唱主角」。改進了內部協調的數字工具現
在使得協調過程的最後階段成為可能,即和一個外部制造商實際地制造這個產品。除了內部
跟蹤產品組件的應用程序外,我們還為銷售商開發了另一個工具來斷定產品組件的投放現
狀。銷售商,包括外部制造商,也利用這個工具來下載數字材料並在電腦上訂購非數字材
料。在這裡,我們的數字工具不僅使得我們能在內部處理過程問題,而且使得一家專營制造
的公司能為我們承擔新的工作。
    一個問題可能就是:我們為什麼一開始要搞制造?在我們有數字過程前,我們別無選
擇。今天我們的信息工具足夠先進,能讓我們為制造部門搞外部采購,但仍能肯定我們的產
品是按我們的規格制造的。我們在公司裡保留一套核心專家班子,並把網絡當做與外部專家
協調的主要方式。
    在五六個月之後,這些小組不僅把已經引起問題的程序修理好了,而且還發現和拆除了
其他幾個尚未爆炸的不良程序的定時炸彈。新工具幫助辨認程序中潛在的衝突,並在衝突或
遺漏發生之前就讓所有的成員都合作解決問題。對一家企業來說,未出現的問題的價值該有
多大?

創建分階段解決問題的過程
    一個叫做HeadTrax的內部用微軟應用程序的開發史,就是個好例子,說明商務需求和
技術問的共存關係如何起作用。使得前數字化世界裡不可能有的新過程產生作用。HeadTrax
是個工作流程應用程序,用於處理人事變化。一次人事變化可能指僱傭員工、晉升、調動或
部門內的變動。
    我們開發HeadTrax的努力表明,有時需要一系列的重複性步驟來理解您想解決的問
題,並選擇正確的過程和技術。對目標理解不完整,是每個技術項目裡令人擔心的主要問
題。這說明為什麼您處理更小的過程並依賴它們發展時,運氣要更好。不管您計劃有多周
密,您經常會發現您對用戶的需求並不是完全理解。假如您花了18個月把一個完整的解決
方案弄好並交貨,卻意識到您並沒有把它搞對,或在這個期間內商務需求有了變化,那麼您
的處境就會很糟糕。一個更好的辦法就是利用軟件工具,它們能使您在不到6個月的時間裡
就做出能用的程序來,然後等您得到用戶反饋後又可以改進解決方案。
    我們的人事流動應用程序第一版看上去不錯,直到我們的副總裁們的電子郵件收文箱裡
收到了許多電子批准表格為止。有些經理們喜歡能在網上處理大部分人事變動,但其他人卻
不想觀看每一次變動,而更喜歡只看高層僱傭或調動的批准表格。在大科室裡的經理們不能
處理這麼大的工作量。陳舊的紙張文件系統使得授權更容易,所以我們又需要把授權增加到
這個數字系統裡去。這個應用程序的第二版功能齊全,但是流程仍然有值得改進的地方。有
時重要的批准手續在低層走上岔道了,而小的人事變動卻仍然時不時出現在一個副總裁的膝
上型電腦中。我們與安德遜咨詢公司協作,意識到我們有15個主要組裡的12種不同的批准
過程。我們針對過程,把12個減少到3個;這3個過程就是HeadTrax第三版的核心。
    今天,經理們在網上啟動所有人事變動程序。任何評審人都能退回一份申請,讓原申請
人修改申請並用數字形式把申請重新寄來。評審人也能對申請做修改,然後批准它,並讓申
請繼續沿著路徑前進。所有與這個申請有關的人都會收到電子郵件,並有與變動申請相連的
鏈接,好讓他們審查申請。在過去,大部分人力資源部門對人事變動申請的拒絕都是由於次
要問題或編碼錯誤等問題引起的。HeadTrax幾乎淘汰了那種拒絕。
    一種「代替……行使職權」的特徵,使得一位經理能夠把任何類型的人事申請的批准職
責下放給其他人,這一特徵證明是HeadTrax最重要的功能。一位副總裁可能會授權一個行
政助理批准日常的職務變動或人事變動,授權高級經理們批准他們領導的小組的報酬或晉升
申請。「代替……行使職權」的特徵賦予經理們一種創造節省時間的例外的辦法,並使批准
過程能繼續運行。如果一個1000人的分部要變動成本中心,或者在一次調整組織中所有的
小組都要換人,那麼一個行政助理就能整體選定這些小組,並在組織結構圖上點擊一個按鈕
來做出所有的變動。
    一個按規定路程發送的特徵能增加靈活性。作申請的經理能在把申請上交給人力資源部
之前將一個人加進評審圈。例如,一位高級經理評審某種特殊類型的諸如晉升那樣的僱員變
動。
    HeadTrax對於非行政性的工作也是有用的。在開始時,不管您輸入哪個僱員的姓名,
HeadTrax都會顯示整個組織結構圖,從高到低的所有人員都有。HeadTrax也能讓您在匆忙
中創建組織結構圖,並根據各種特徵——如全名、電話號碼、辦公室號碼、部門編號等等來
做特製的圖表視圖。
    現在HeadTrax這個程序完成了,它就像一個明顯的解決辦法,是中等規模和大型公司
都能用的一個應用程序。它不僅僅是一種從經理辦公桌上清除掉人事文牘的辦法,而且在有
組織變動的時候,是把人事變動推進到會計和預算系統裡去的一台引擎。它保證我們所有的
商務系統都保持同步運作。
    由於HeadTrax系統剛出台,要拿出它在消除丟失的或不完整的文牘和數據輸入時間上
給我們節省的時間和精力的確切數字,是很困難的。但是到1998年年底時,HeadTrax每個
月處理大約8000次人事變動。不再需要人力資源部評審的批准手續占所有人事申請的90
%,在24小時內就反映在這個系統中了。人力資源批准手續要花更長的時間,這是因為一
些與技術無關的過程,例如給一個要離開公司的人舉行的辭職面談。
    HeadTrax使商務和人力資源經理們能夠在任何時間審
    查所有未解決的人事變動,從而增進了他們的責任感。一個商務經理通過清點他小組裡
的人頭數,能夠了解他的小組成員在崗位缺人時幹得如何。如果這個經理發現他的一個直接
下屬經理比本部門其他經理更缺人手時,那麼這個高級經理就可以調查一下,看是否需要花
更多時間僱傭一位經理來招聘人員,或者是否需要從公司的招聘小組得到更多的幫助。
    負責人力資源的經理們認識到,把時間花費在批准每一次常規人事變動上,並不是最明
智的。相反,他們開發了一個電子工具來處理日常業務,並收集數據做人事管理趨勢分析。
一個高級人力資源經理可以用HeadTrax的審計功能來查看所有被拒絕的人事變動,看是否
有個模式顯示出經理們需要在人事問題上接受更多教育,或HeadTrax應用程序是否需要有
附加的一些功能。人力資源部也可以分析一個經營單位是否比其他單位有更高的人員流動
率,還能看員工離開公司的理由中是否有個共同模式。HeadTrax不僅為我們的商務人員提
高過程效率,而且使我們的人力資源人員能重新定義他們的作用。能立即看到關於調動率或
員工流通率這類事情的數據,其價值遠遠高於降低的成本或節省的時間。
    認準任何過程首要的、中心的目標,這就是開始解決過程問題的辦法。不管是生產過程
還是內部商務過程,其目標都應該永遠是根本性的簡單化:讓最少的入做最少的交接。要優
化一個書面過程是極端困難的。數字技術使開發更好的過程成為可能,它不是讓您停滯在陳
舊的書面過程的小變動上,那只能讓您做漸進性的提高。真正的過程突破來自認真考慮的解
決方案與數字信息流的結合。

利用數字過程解決難題
    在微軟公司最棘手的商務過程之一就是僱傭、管理臨時工以及給他們付酬。
    對於一家有許多項目、產品投放市場時工作量達到頂峰的公司來說,管理臨時工是極為
重要的,臨時工幫我們處理高峰期工作負擔,從開發、測試、營銷到行政支持工作,包羅萬
象,無所不有。在我們對臨時工的使用中,有5組人員需要協調好:(1)臨時工本身;
(2)臨時工為之工作的110家機構;(3)在各個部門裡使用臨時工的經理們;(4)我們
公司內部的臨時工管理小組,該小組管理我們與臨時工介紹所的關係,跟蹤臨時工每小時的
工資率;(5)公司采購部,實際上是它們給臨時工支付薪水。
    我們的業務問題是多方面的,不僅僅是因為跟許多不同的機構和臨時工簽約購買服務要
牽涉到大量文件。我們在保證連貫的簽約過程,按恰當的小時工資招聘合適的人員,不把臨
時工使用在大多的連續項目上或在一個項目上使用臨時工大久,以及決定什麼時候把臨時工
轉變成正式工等問題上都有困難。
    幾年前制訂的一個僱傭人員的政策,在使用臨時工問題上建立了嚴格的指導方針。按政
策規定,所有臨時工都應通過職業介紹所來僱傭,任何臨時工都不得在各種綜合項目上工作
超過340天,他在其間應中斷服務至少31天。但是書面的過程使得簽約僱傭臨時工的經理
——他們中許多人都是新到公司的或新擔任這個職務的——很難保證遵循這個指導方針。由
於我們的招聘經理們都有事情逼到頭上來才行動的特點,所以我們滿足各部門的需求和防止
犯錯誤的唯一辦法就是把許多人投入到要解決的問題上去。人力密集型的過程並不使我們感
到高興。
    再有就是,書面過程並沒有給高級經理們解決預算問題。因為許多經理都僱傭了臨時
工,以及臨時工經常在多個項目上工作,各部門的高級經理們沒法掌握被使用的臨時工總人
數,也沒法掌握臨時工工作的小時總數。我們無法前後一致地預測僱傭臨時工的成本。各部
門經理從財會部弄來的關於人數、小時數和成本的財會數據總是姍姍來遲,或只是估計而不
是實際的小時和成本。給臨時工支付的工資在有的月份升得很高,有的月份又降得很低。
    在一開始的時候,我們以為這個問題是出在財會部的過程裡,但是當我們分析數據時,
我們意識到財會部得到的信息也不全。我們的支付過程控制機制很少。盡管有很多簽字——
經理們給臨時工簽上班時間卡,然後臨時工把卡交給他們的職業介紹所,介紹所又給我們寄
來賬單,采購部給這些賬單付款——但實際上沒有財會控制。一個經理無法確定小時工資率
或開了賬單的小時總數。一份賬單可能會沒有簽字的時間卡就給我們郵寄來了。一個經理可
能會同意給一個臨時工漲薪,但臨時工僱傭部卻可能得不到這個信息。或者一個臨時工會在
一個項目上得到漲薪,但是這筆漲薪卻錯記在另一個項目上了。我們沒有辦法制止開來的雙
重賬單。
    商務小組退後一點從開頭到結尾審視整個過程,並判斷數字信息能如何幫助我們管理這
個複雜過程。
    一個管理方面的問題就是,經理是否從一開始就有權僱傭臨時工。在我們的書面系統
裡,沒有辦法來保證管理人員會審議招聘更多人力資源的最初決定,一旦決定了僱傭一個臨
時工,經理們沒有足夠的信息來了解他們是否在遵循相關的業務規則。例如,該經理有幹這
個工作的預算嗎?該經理願意給這個項目批准加班工資嗎?此外,招聘經理無法容易地了解
到某項工作合適的小時工資是多少,或哪些有資格的人員能應聘。除非招聘經理心裡已經有
一個具體的人選,否則我們就沒有一種容易的辦法來找出一種可能的資源,不管這個資源是
一家公司、一個介紹所介紹來的臨時工,或是一個獨立的承包者。我們為了正確的預算,需
要一種自動計算公開招聘全額成本的方法。我們決定我們需要一個新的靈活軟件解決方案。
對每一個臨時工,我們都必須保證他有一份公開寫好並簽名的合同。合同一旦被批准,那麼
這個人的卡式鑰匙、電話和上網權利必須在48小時內准備好。用戶必須能夠容易地創造相
似職務的多重相同申請,當您准備一個大項目的時候,這是一種典型的局勢。當承包者工作
時,經理們需要一種簡單的方法來確認工作時數、支付工資級別,以及在采購訂單上的余
額。當合同終止日期臨近時,招聘經理需要被自動警告。經理需要能自動地延長該臨時工的
合同,但條件是預算還有剩餘,而且這個人為微軟公司工作的日子少於連續的340天。當終
止日期到達時,這個人上網、上電子郵件、使用公司電話和房屋的權利就必須停止。
    我們的新過程必須支持變動,但又不能阻礙工作。當一份合同准備妥當時,假如審批經
理不在,那麼招聘經理則必須能夠把合同轉到另一個有審批權的人手裡。假如在工作分派期
間內經理或成本中心有變動,我們就必須能容易地重新分配該項成本。職業介紹所應能自主
給臨時工小額加薪,但是大幅度加薪則必須得到招聘經理的同意。

決定是否集中管理
    一種方法就是創建一個巨大的單一應用程序來處理所有這些需求,即所謂的「大程序
法」。我們有一次就這樣設計過一個應用程序,是用來使我們內部的十幾個服務組織——圖
書館、保安、飲食、出差、公司倉庫、公司信用卡集團和其他組織等——能跟蹤僱員請求並
做出反應的。最後這個項目是我們所取消的少數項目之一。各個群體的需要是很不相同的,
而商務規章又太複雜,一個應用程序處理不了。我們花了那麼多的時間來使這個系統運轉起
來,可等我們完成的時候,需求又改變了。我們接受了一個重要的教訓:很少的公司應用程
序需要「集中」。我們讓每個小組自由建立自己的申請系統。通過縮小解決方案的規模,我
們縮減了大量複雜性和開發時間,今天所有的內部服務小組都有自己的「申請」應用程序,
他們每隔幾個月就改進一次。它們都是無紙過程的極好例子,這些過程節省時間,使得跟蹤
優質服務的提供更容易。
    我們避免內部應用程序冗長的開發週期。太多的時間消耗往往使優勢失效,而商務需求
同時又在發生改變。更小的、非集中的過程通常是最好的。只有少數的應用程序,例如我們
的財務報表系統,需要集中化。我們在承擔了內部其他商務解決方案的同時,一直保持小規
模的小組和項目,心裡記著我們生產開發小組的座右銘:「及時交貨是我們的特色」。
    在檢查對臨時工的管理時,我們想避免一種單一的辦法,但與此同時,又不要弄到未了
有六七種互不相干的應用程序,不能組合在一起來刨建一個總體解決方案。我們的戰略就
是,創造一系列模塊化應用程序,從開始設計的時候就准備把它們的數字數據互相鏈接起來。
    我們主要的工具就是Ms Market,即我們內聯網上的公司采購應用程序;Ms Invoice,
即因特網或稱外聯網上的一個網址,它使我們的承包商和其他人能用電子方式遞送發票;還
有我們的SAN系統,它處理所有的後台財務來往。由於我們已經有HeadTrax來管理人事,
我們就把它當用戶界面來用,不管哪一個應用程序實際上在幕後「擁有密碼」。用戶只要簡
單地在HeadTrax上點擊某個特徵,正確的應用程序就會開啟。
    承包過程從Ms Market裡的數字采購開始,我在第三章中已作過全面描述。創建。僱傭
和管理臨時工的步驟與HeadTrax為管理正式員工的電子控制功能十分相似。MSInvoice是
便利於電子傳送發票的,也提供控制功能來幫助招聘經理和銷售商(譯註:此處指提供臨時
工的機構)不超過預算。在每一張發票上,招聘經理都有一個鏈接以查看采購訂單上的余
額。銷售商能看到他們的哪一份賬單與哪一份發票匹配。假如一個銷售商企圖送交一份比采
購訂單上的余額更大的發票,那麼這份發票就會被拒絕。假如銷售商給臨時工漲薪,微軟公
司的經理可以點擊一個按鈕來批准或拒絕。
    精明的讀者也許想知道,我們為什麼還要使用發票呢?不管是電子或其他形式的發票?
歸根結底,制造業大戶都能夠完全取消發票了。典型的例子就是福特公司取消了存貨材料訂
購發票。當收貨部收到了一批零件之後,經手人就在電腦上輸入收到這批材料,開始自動給
賣方付款。制造商拿到了零件,供應商收到了付款。誰需要一份發票——即使是數字化發票?
    我們也用一種類似辦法做過試驗,但是在牽涉到服務而不是實際貨物的地方發現了一些
差別。在制造業裡,每個零件都有一個零件號。要創造與臨時工的時間一對一的關係是更困
難的。因為您「接收」的是花在一個項目上的小時。沒有一個另外的參考,即發票號碼,銷
售商要把一次電子付款與某個工人和某周聯繫起來是困難的。我們拭目以待,盼望著能為我
們的銷售商所用的無發票服務付款系統。我們的大問題就是要把臨時工過程完全數字化,以
便讓所有的信息能輕易得到。
    一條經驗法則就是,一個很差的過程會花掉工作本身所需時間的10倍。文獻中的許多
例子都描述再設計如何把30天的過程減少到3天,或把10天的過程減少到1天。一個好的
過程會消除浪費的時間,而技術將會加快剩下的真正工作。但是這種改進並不是最重要的好
處。改進管理方對承包過程的監督,保證每個人都遵循招聘指導方針和預算,這些才是大的
商務利益。更重要的是,我們能把各行業工種的表現聯繫起來,而且保持與這些工人更好的
關係。

一步一步地改進
    要有所准備,以便試驗新過程和技術解決方案。沒人能預測一個新過程或新應用程序可
能出現的每一個差錯或問題。員工們先要使用程序,然後他們和程序開發者才能決定什麼真
正起作用,什麼不起作用。用戶一旦親手用了以後,他們就肯定能看到擴展一個應用程序的
新方法。我們直到看到HeadTrax對正式職工起了作用,才意識到我們可以用它來處理臨時
工的問題。我們直到看到HeadTrax用於人事變動很管用,才意識到我們可以加上跟蹤歷史
信息的功能,以便為預算目的比較逐年的人頭變動。這個特徵將是下一個版本的一部分。
    對於所有再設計項目,尤其是那些牽涉到技術的項目來說,複雜性都是它們的未日。據
《華爾街日報》的一篇文章所說,研究公司斯但迪國際集團1996年對360家公司的一次調
查發現,公司信息項目的42%都在完工前被放棄。據這篇文章說,複雜性通常是罪魁禍
首。文章把浪費稱作「驚人的」,並補充說,「項目越大,它們就越頻繁地失敗,而且花費
更大。」1
    1小貝爾納·威索基、《拔掉插頭:一些公司對昂貴的電腦失望,從而選擇『非籌
劃』》,華爾街日報,1998年4月30日。
    只持續三四個月的項目的失敗率卻低得多。對於短期項目,您被迫做一些重要的取捨,
追使您做得更簡單更集中。您最後的目標是可執行的。假如短期項目失敗——由於種種原
因,少數確實會失敗——您損失的時間和金錢也少得多。把您的開發小組撤出來搞另一個項
目,這在心理上也要容易承受得多,因為人們沒有浪費一年的生命搞一個要被放棄的項目。
    即使那些累計要花好凡年的項目也可以分為一系列更小的項目,每個項目都有確定的核
查點。這樣的辦法使得項目能平行前進,並使您能享受到許多領域裡更快的數字過程,即使
您在一兩個領域裡卡殼。美國第五大零售連鎖店戴頓。哈德遜公司想縮短它1100家百貨公
司的商品經營週期——即訂購一件商品並將它放置到貨架上所需的時間。該公司把每個商務
過程分解成互不關聯的步驟——設計。顏色和紡織物的選擇、銷售商選擇,等等。然後快速
地、獨立地執行每個步驟。最後的數字過程鏈接在一起,從而
    把公司下屬商店的家用物品進貨週期從25天減少到不足10天——這些商店包括戴頓、
哈德遜、塔吉特、梅文和馬歇爾·菲爾茲。
    一旦您的數字環境建立起來了,那麼您承擔的項目就會更成功。假如您的環境主要是紙
張,那麼一個新的數字應用程序就會在正常的業務活動之外,而正常的學習應用程序的時間
就會顯得非常麻煩,不值得去做。但是,如果您的環境是數字化的,您就將能夠快速地普及
這個程序。您可以舉債搞許多應用程序的培訓。能夠很嫻熟地使用技術的工人在講到新應用
程序需要怎樣工作時也會很苛刻。一旦有幾個成功的應用程序在給您工作了,員工們就會
說,嗨,為什麼我們的員工總數系統不像我們的銷售系統?我們在這裡為什麼不能從摘要數
據轉到細節去?您意識到這裡給員工安裝一個電子警報會很容易嗎?他們會讓您知道您可以
容易地鏈結的其他應用程序或網頁,而您最後就會有一個更完整的解決方案。
    您利用您現有的技術投資就可以花費很少的成本來創建新的數字應用程序,回報卻是巨
大的。您已經需要電子郵件來做專門目的的通信。您需要進入萬維網來搞到關於全世界的信
息。您需要外聯網址來向顧客和合夥人推銷自己,您需要內聯網址來提供公司信息。為什麼
不把這些技術用於每一個商務過程呢?利用技術和您現有僱員的專業知識吧。

擁有過程變化
    在我們1998年的第二次首席執行官高峰會議上,我們組建了一個由首席執行官和首席
信息經理組成的小組,探討商務需求和技術的交叉作用。向小組成員提出的一個問題就是:
是什麼引起了重大的技術故障?強生公司總裁拉爾夫·拉森說,「重大失敗」最經常的原因
就是,實業家們乾脆把大項目交給他們的信息技術部門或外部咨詢公司,「然後就撒手不
管,因為這是很困難的活兒。」拉爾夫說:「絕對不能那麼做。您所看到的所有成功都是因
為強有力的商務所有權,不是因為信息技術所有權,有強大的信息技術支持的商務所有權。
項目並不屬於顧問或信息部門。項目不屬於任何人,只屬於企業所有人。」
    沒有一個能把商務和技術連接起來的人的監督,就不可能正確地再設計一個利用技術的
過程。這個商務過程擁有者不必是最資深的人或在您的公司的商務部門裡最懂技術的人。但
是這個人的確要懂得商務需要,懂得技術是如何在實際工作中被使用的。這個人必須在公司
裡受到足夠尊重才能讓決策堅持下去。這個人最可能有真知的見,知道開發更新的、更簡單
的過程,知道在商務和技術要求之間搞平衡。
    拉爾夫的答覆得到該小組裡首席信息官們的有力支持。阿爾科阿公司的首席執行官員帕
特裡夏·希金斯說,她見到再設計項目超支嚴重的唯一一次,就是因為公司的商務部門沒有
負起責來。她說:「絕不要簡單地用新信息技術來代替老的商務過程,甚至替換遺留下的好
信息系統。始終要抓住機會來檢查和提高過程的效率,問問自己您的業務優先項目是什
麼。」許多公司發現,資金浪費來自這個事實:您不把您的過程當作新解決方案的一部分來
重做。您總是不可避免地要隨後另請個人來再設計解決方案,使它們生效。
    誰該擁有再設計過程呢?今天做了最大努力或明天能得到最大好處的商界領袖,應該擁
有新過程的開發和支持新過程的技術。

    商務啟示

    ◆從各種視角來解決過程問題,並利用技術來創建以前不可能有的流水線過程。週期性
地重新評價所有過程。
    ◆如果您重新設計過程來產生最佳的信息流,那麼您就會解決重要的商務問題。
    ◆過程問題說到底就是簡單化的問題:讓最少的僱員從事最少的工作交換。
    ◆不僅僅是信息技術部門,而且商界領袖也必須擁有關於技術過程的決策。
    ◆一個低劣的過程會消耗掉工作本身所需時間的10倍。一個好的過程會排除掉浪費的
時間;技術會加快剩下的真正工作。
    ◆複雜性是一切再設計項目的未日.尤其是那些牽涉到技術的項目。

    診斷您的數字神經系統

    ◆您的數字系統能使初期解決方案快速實施嗎?它能使其他分階段改進工程快速執行
嗎?它們能讓每個僱員都很容易地跟蹤系統現狀嗎?它們能使人們很容易地看到需要管理方
采取行動的趨勢嗎?
    ◆您能用幾個獨立的小過程建造一個大過程並把它們鏈接起來創建一個高效率的系統嗎?
    ◆您在使用數字信息流來簡化一個完整的過程嗎?
    ◆您是通過創建更小的、分單元的、從開始就設計為交換數字信息的解決方案來避免長
久的開發週期嗎?

前後