不管在什么體量的云項目里，發現都是項目風險的癥結。盡管項目的發現和架構階段僅代表總體付出的15%，但早期的任何一個錯誤或疏忽都會導致150%或更多的蔓延。

 

不幸的是，這也是項目的蜜月階段，過度樂觀和對安全的錯誤意識會掩蓋內在的風險。這就是供應商的項目帶頭人必須最堅定的時候，引導客戶做出艱難的決定并迫使客戶承認這種不愉快的交易。真誠的客戶牽手是發現階段的成功因素。

 

50年前的今天，佩珀軍士(注：披頭士一首歌曲中的角色)就參透了這一點。讓我來向您介紹云項目中最薄弱的部分，老生常談的需求發現!

 

 

即便客戶收集了很多需求并在項目開始前就創建了需求文檔，這些大部頭不可避免地遭受以下四個問題：

 

1.文件深受供應商的宣傳和行業分析師的影響，而受業務流程實際需求的影響十分不足。這導致了技術上的“功能炎癥”并對實際用戶的偏好視而不見。

 

2.沒有對需求給予足夠的優先級別，只是就符合項目預算和時間表所需的艱難交易提供蜻蜓點水式的指導。

 

3.需求不完整，在端對端的業務流程中缺乏重要的過渡。往往是到了項目開展的時候才發現缺漏，“隱形的需求”在發現階段結束后很久才被發現。當主要的需求在系統接受度測試中突然出現的時候是最戲劇性的。

 

4.業務在項目的生命周期里一直進化著，而每一個重組或策略變更都會使原始文檔無效，甚至與原始文檔矛盾。這一點不好玩，但確有其事。

 

因為預先編寫的需求文檔對大項目的整個歷程來說往往是不可靠的路線圖，顧問喜歡把項目分解為幾個階段，每一個階段都以它自己的發現和需求批準周期開始。敏捷的項目方法把這個推到了邏輯上的極限，在每一次短跑開始時都有一個微發現。

 

 

甚至是敏捷方法也會讓項目陷入困境，如果顧問沒有帶客戶做“生命中的一天”練習，從實際客戶的視角探索端到端的業務流程(可怕!)。高層往往不知道業務實際的運作細節，而低級別的人員只管自己的一畝三分地。有了面向客戶的應用，你會發現有時只有客戶才知道你的系統有多讓人沮喪，而內部沒有人花時間將這些小細節串聯起來并以端到端的視角看待流程。

 

深度發現的起點就是將系統表述為一系列的業務流程，比如：

 

·將營銷瞄準合格的銷售線索

 

·銷售和渠道管理

 

·合同報價

 

·交付、安裝和客戶熟悉產品

 

·開票和收款

 

·保修和服務授權

 

·案例管理和服務調度

 

·問題解決方案和服務電話

 

·跟進客戶調研

 

經歷了這種分析的大公司將很快發現他們的整個業務沒有一個單一的流程工序流。跨國運營可能有很多變體要適應，它們包括：

 

·地區性的或全國性的業務慣例(例如美國的vs歐洲的vs亞洲的)

 

·上下游行業準則和監管制度(客戶隱私、合同規則或財務上的)

 

·分銷渠道與合資公司

 

·不屬于項目的一部分的舊系統(例如企業資源計劃或電子商務)

 

·公司內外的政治領地

 

要把這些變體中的每一個都以有自身需求的并行流程的形式羅列出來。

 

公司都愿意相信云可以大大地簡化他們多年來積累的系統混亂。它們可以做到，但前提是確實有人在簡化積累多年的流程混亂時做足了功課。簡化意味著理解所有可移動部分交互的目的，長遠地想出一個智能的統一和替代策略。

 

 

這聽起來很復雜、昂貴、耗時，的確如此。顧問和客戶都適應了超過總項目付出的“標準的15%”的深度發現流程。當云系統正在取代一個或更多的經歷了多年演變(以健康的或不健康的方式)的舊系統時尤其如此。

 

高層想項目快點完成的欲望必須受到遏制，他們要知道心急只會制造一個將舊習自動化，將淘汰的業務規則加強的新系統。真正的業務轉型意味著要在業務流程上做足夠的工作，將它們變成一種優勢。