正如熱門概念往往會引起的後果那樣，哈墨和錢丕關於再設計過程的簡單但深刻的概念，引發了一股商務研討會、培訓班、大學課程、雜誌文章和各種專家出版「效顰」專著的熱潮。１在這個過程（一語雙關）中，各式各樣的商務人員用「再設計」這個詞來為幾乎任何組織變動做辯解。兩年以前，一家大電腦公司開始了「再設計」的努力，把人事部門大部分人都解雇了，沒有留下人來合理地處理實際上裁員的後果。這家公司沒有人事專家來指導變動，犯了一些錯誤。它買斷了自由打工者的合同，在他們還沒干更多工作之前就把他們打發走了——儘管公司已經支付了他們的服務費。新晉陞的人本來很受賞識，現在卻被解雇了，因為他們在現有等級上是資歷最淺的。要把這種行為看作合理化裁員是很難的，而且也絕對不是再設計。邁克爾·哈墨在一次談話中曾說：「有時再設計幾乎是指任何事情，但絕對不是指再設計了。」儘管有些人對這個概念太過熱心或利用它來掩飾裁員，但時不時地審視您的過程，使它們更有效，並把低效率排擠出去，這個想法現在卻比以往更為重要。
１1998年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％都在完工前被放棄。據這篇文章說，複雜性通常是罪魁禍首。文章把浪費稱作「驚人的」，並補充說，「項目越大，它們就越頻繁地失敗，而且花費更大。」１
１小貝爾納·威索基、《拔掉插頭：一些公司對昂貴的電腦失望，從而選擇『非籌劃』》，華爾街日報，1998年4月30日。
只持續三四個月的項目的失敗率卻低得多。對於短期項目，您被迫做一些重要的取捨，追使您做得更簡單更集中。您最後的目標是可執行的。假如短期項目失敗——由於種種原因，少數確實會失敗——您損失的時間和金錢也少得多。把您的開發小組撤出來搞另一個項目，這在心理上也要容易承受得多，因為人們沒有浪費一年的生命搞一個要被放棄的項目。
即使那些累計要花好凡年的項目也可以分為一系列更小的項目，每個項目都有確定的核查點。這樣的辦法使得項目能平行前進，並使您能享受到許多領域裡更快的數字過程，即使您在一兩個領域裡卡殼。美國第五大零售連鎖店戴頓。哈德遜公司想縮短它1100家百貨公司的商品經營週期——即訂購一件商品並將它放置到貨架上所需的時間。該公司把每個商務過程分解成互不關聯的步驟——設計。顏色和紡織物的選擇、銷售商選擇，等等。然後快速地、獨立地執行每個步驟。最後的數字過程鏈接在一起，從而
把公司下屬商店的家用物品進貨週期從25天減少到不足10天——這些商店包括戴頓、哈德遜、塔吉特、梅文和馬歇爾·菲爾茲。
一旦您的數字環境建立起來了，那麼您承擔的項目就會更成功。假如您的環境主要是紙張，那麼一個新的數字應用程序就會在正常的業務活動之外，而正常的學習應用程序的時間就會顯得非常麻煩，不值得去做。但是，如果您的環境是數字化的，您就將能夠快速地普及這個程序。您可以舉債搞許多應用程序的培訓。能夠很嫻熟地使用技術的工人在講到新應用程序需要怎樣工作時也會很苛刻。一旦有幾個成功的應用程序在給您工作了，員工們就會說，嗨，為什麼我們的員工總數系統不像我們的銷售系統？我們在這裡為什麼不能從摘要數據轉到細節去？您意識到這裡給員工安裝一個電子警報會很容易嗎？他們會讓您知道您可以容易地鏈結的其他應用程序或網頁，而您最後就會有一個更完整的解決方案。
您利用您現有的技術投資就可以花費很少的成本來創建新的數字應用程序，回報卻是巨大的。您已經需要電子郵件來做專門目的的通信。您需要進入萬維網來搞到關於全世界的信息。您需要外聯網址來向顧客和合夥人推銷自己，您需要內聯網址來提供公司信息。為什麼不把這些技術用於每一個商務過程呢？利用技術和您現有僱員的專業知識吧。
擁有過程變化
在我們1998年的第二次首席執行官高峰會議上，我們組建了一個由首席執行官和首席信息經理組成的小組，探討商務需求和技術的交叉作用。向小組成員提出的一個問題就是：是什麼引起了重大的技術故障？強生公司總裁拉爾夫·拉森說，「重大失敗」最經常的原因就是，實業家們乾脆把大項目交給他們的信息技術部門或外部咨詢公司，「然後就撒手不管，因為這是很困難的活兒。」拉爾夫說：「絕對不能那麼做。您所看到的所有成功都是因為強有力的商務所有權，不是因為信息技術所有權，有強大的信息技術支持的商務所有權。項目並不屬於顧問或信息部門。項目不屬於任何人，只屬於企業所有人。」
沒有一個能把商務和技術連接起來的人的監督，就不可能正確地再設計一個利用技術的過程。這個商務過程擁有者不必是最資深的人或在您的公司的商務部門裡最懂技術的人。但是這個人的確要懂得商務需要，懂得技術是如何在實際工作中被使用的。這個人必須在公司裡受到足夠尊重才能讓決策堅持下去。這個人最可能有真知的見，知道開發更新的、更簡單的過程，知道在商務和技術要求之間搞平衡。
拉爾夫的答覆得到該小組裡首席信息官們的有力支持。阿爾科阿公司的首席執行官員帕特裡夏·希金斯說，她見到再設計項目超支嚴重的唯一一次，就是因為公司的商務部門沒有負起責來。她說：「絕不要簡單地用新信息技術來代替老的商務過程，甚至替換遺留下的好信息系統。始終要抓住機會來檢查和提高過程的效率，問問自己您的業務優先項目是什麼。」許多公司發現，資金浪費來自這個事實：您不把您的過程當作新解決方案的一部分來重做。您總是不可避免地要隨後另請個人來再設計解決方案，使它們生效。
誰該擁有再設計過程呢？今天做了最大努力或明天能得到最大好處的商界領袖，應該擁有新過程的開發和支持新過程的技術。
商務啟示
◆從各種視角來解決過程問題，並利用技術來創建以前不可能有的流水線過程。週期性地重新評價所有過程。
◆如果您重新設計過程來產生最佳的信息流，那麼您就會解決重要的商務問題。
◆過程問題說到底就是簡單化的問題：讓最少的僱員從事最少的工作交換。
◆不僅僅是信息技術部門，而且商界領袖也必須擁有關於技術過程的決策。
◆一個低劣的過程會消耗掉工作本身所需時間的10倍。一個好的過程會排除掉浪費的時間；技術會加快剩下的真正工作。
◆複雜性是一切再設計項目的未日．尤其是那些牽涉到技術的項目。
診斷您的數字神經系統
◆您的數字系統能使初期解決方案快速實施嗎？它能使其他分階段改進工程快速執行嗎？它們能讓每個僱員都很容易地跟蹤系統現狀嗎？它們能使人們很容易地看到需要管理方採取行動的趨勢嗎？
◆您能用幾個獨立的小過程建造一個大過程並把它們鏈接起來創建一個高效率的系統嗎？
◆您在使用數字信息流來簡化一個完整的過程嗎？
◆您是通過創建更小的、分單元的、從開始就設計為交換數字信息的解決方案來避免長久的開發週期嗎？
|
|
