隨著數字化的發展，很多企業都做起了數字化，你的企業在做數字化嗎？數字化的過程中，業務和產品吵架多嗎？企業的數字化失敗，都體現在哪些方面？本文就此進行探討，一起來看看吧。

你的企業在做業務數字化嗎？

數字化的過程中，業務和產品吵架多嗎？

如果答案都是肯定的，那你要小心了，這就是數字化失敗的征兆。

你可能嗤之以鼻，畢竟從古至今，改革哪有一帆風順的。

特別是企業內部協作，哪怕不涉及改革，也總是吵吵鬧鬧。

這樣說也沒有錯，但你要透過對立的現象，深挖對立的本質。

不同的本質帶來的不同的影響程度，最嚴重的，就會直接導致項目失敗。

根據埃森哲發布的《2022中國企業數字化轉型指數研究》，我國企業數字化轉型取得顯著成效的比例僅為17%。所以至少有一大半的企業，數字化項目都無法到達順利的彼岸。

有鑒于此，企業必須認真對待業務和產品的對立。

以下三種對立的本質和解決方案，供你對號入座。

本質是權利對立，以分工治之。

本質是導向對立，以考核治之。

本質是思維對立，以規范治之。

一、人-人 與人-機-人過程的權利對立

業務不會自動地開始，也不會自動地結束。

從開始到結束，需要人和人之間的互動來改變現狀，以達成業務結果，這就是現實世界的業務推進。我們把這一套交互方式概括為“人-人”，加入系統后，人和人不再直接互動，而是通過系統來傳遞信息，“人-系統-人”成為了新的交互方式。

譬如你是一家雜貨店的老板，原本你向廠家訂貨，需要聯系廠家的銷售人員，說清楚需要飲料干雜零食若干，而現在廠家提供一個系統給你，你可以通過系統查看貨品信息并在線下單，同樣的，銷售人員從系統了解到你需要什么產品，你們不再需要互相溝通。

所以說，傳統的業務實現是靠“人-人”交互流通，這一過程也被稱為線下流程，與之相對的線上流程，依靠“人-系統-人”交互。從線下到線上的過程，就是業務的數字化。

線下流程靠的是不同的業務人員共同推進，他們環環相扣，最終服務到客戶。業務決定內部如何協作，外部如何服務客戶。而通過系統，顯然改變了原有的協作流程，進而剝奪了業務的部分話語權。這就造成了業務和產品之間的根本矛盾。

排斥線上化的業務人員會痛斥使用系統過程中種種不便，仿佛它是阻擋業務發展的最大敵人。同時放大了線上化的過程的負面體驗，不會用，不好用成為了業務的常見托詞。

反過來產品又可能因為組織賦予的責任，完全站在了業務的反面，強硬的去推廣系統。同時也把業務增長歸功于線上化，而輕視業務在一線的努力。

線下和線上是服務于同一個目標的不同方法，是硬幣的一體兩面，需要業務和產品同樣付出努力，才能既做好線下，也做好線上。況且線上化是一個以年為單位的大工程，線上和線下的同時運行，也會是一個長期的過程。

所以協調好兩者的權力對立，對于現在的業務是否能延續，未來的業務是否能發展有著重要的作用。

那怎樣協調這樣的對立呢？簡單來說就是劃地盤，用流程來劃分權限。

把產品設計分為兩個階段，階段A 業務設計 ，階段B 產品設計。

前者的話語權給到業務，讓業務來定義做什么事情，為什么做A不是做B，A的范疇是怎樣，業務準備如何去做這樣的事情。但注意，如何去做這樣的事情并不是讓業務拿出系統界面，來告訴產品這里增加一個頁面，那里放一按鈕，而是拋開系統去描述業務的實際需要。

例如，業務需要做一個客戶管理系統，并不是拿著市面上成熟的CRM告訴產品抄一份。而是定義組織內部，什么是銷售管理，要管理哪些角色，管理的過程是如何做的，具體要做什么事情，這些事情哪些是需要在系統上操作的，操作后需要保留哪些信息。

這一部分至少需要業務給出業務流程圖-角色工作說明書-線上化需求說明書。這些文檔模版后續我也會接著分享給大家。

業務給到這些基礎信息后，產品接手，開始回到產品和系統的視角來定義這件事情，思考在系統的上如何滿足業務的訴求。這里會暴露非常多的問題，例如線下能跑通的事情，你會發現線上就做不到或者需要換種方法做；再例如線下沒有的流程，像管理、審批、風控是線上必考慮的要點；還例如線下的流程鏈路長，涉及角色多，是否需要劃分一二三期。

這些問題和解決方案，在后續的文章中，我會接著分享。

總之，把產品設計的過程一分為二，各自確定自己范圍的內容和權利，是數字化的基礎。

二、短期導向和長期導向的對立

當流程確定，業務和產品都已明確知道自己的權利和責任。

此時更容易發生的問題是在業務訴求本身，以及業務期望的實現方法。

也就是從目標——方案的推導。

這一過程是由業務確定的，但由于業務工作具有強烈的短期導向性。每月，每季度，每年都有各種指標任務，銷售考核，大家會盯著各種結果數據全力奔跑，就會想盡辦法由目標去推方案。

線下他們或許會采取一些不那么正規的手段，而轉到線上，就延伸出一些奇奇怪怪的訴求。

舉個例子，除了部分特殊業務，公司要求所有訂單都進行線上化，這樣客戶下單后，公司統一的訂單中臺能看到所有渠道的所有數據。那有一些既不是特殊業務范疇，現階段又不能線上化的訂單，為了獲取這部分業績，業務希望事后導入功能可以放開權限，在公司不知情的情況下“弄虛作假”。

對于這類明顯違規的訴求，產品自然應該拒絕，但還有一些在安全線內但是對長期無益的訴求，產品覺得實現這些需求是資源浪費，只能解決一時的問題，也容易和業務發生爭吵。

另外還有一些訴求，業務無法證明方案的有效性，推著需求上線的時候非常著急，但是做好了又因為種種原因擱置，迫于無奈產品做了，最終證明確實是資源的浪費。

作者做過一個統計，在多家受訪的企業中，大約有10%的功能上線后會被立即使用，而20%的功能會在3個月內被使用，還有40%的功能會在1年內被使用，而有30%的功能將會長期沉寂，不會為企業產生價值。換句話說，內部系統也好，SaaS也好，至少有3成的需求做了都是無效的。

綜上，從業務目標到業務方案，業務會因為方案的合理性，有效性和產品產生爭論，主要取決于大家的導向性問題，業務更會傾向于試錯，只要完成目標，什么都可以嘗試，而產品希望想明白了再去實施。

那怎么解決這個問題呢？用考核。

對于線上化的業務，不應該僅考核業務收入成本等核心數據的達成，也要考核研發資源的利用率。

既然由業務決定了一定要使用A 方案來實現目標，那最后我們就要看A方案帶來的效果，以及投入的成本?，F實里不乏耗費1個月，幾十上百萬萬的研發費用，1年后回顧，個位數用戶，甚至沒人使用的例子。

對于產品的考核，適當把業務目標分配下來，讓產品去考慮如何使用技術手段幫助業務達成目標，不需要產品像一線業務一樣去做具體的事情，但會更積極的利用系統工具去想辦法。

好好合作，互相配合可能是一個場面話，但綁定起來的目標能有效讓大家站在一起。

三、業務思維和產品思維的對立

業務思維以“我”為主，認為自己非常熟悉客戶，熟悉公司內部，于是就能代表客戶，代表內部的各個角色去對系統提出意見。

產品思維以“用戶”為主，講究的是以用戶整體的特征去推導，去考慮如何設計頁面符合客戶共性。

曾經有產品告訴我，因為一個圖標展示和業務吵了好久，因為業務認為這個圖標就不能精準表達業務的定義，而產品不改動理由是：客戶沒有業務那么專業，是分不清圖標代表的款式區別的，表達女裝，那用連衣裙和短裙都沒有關系，況且這個頁面停留時間不足3秒內，圖標的作用是讓用戶快速區別這個選項和其他選項的區別。

面對業務思維和產品思維的對比，我們應該怎么解決呢？

一方面沿用第一部分說的分工，既然是界面上的事情，那拍板就該由產品來做。

另一方面是給到具體的規范。

每個人都不可能全知全能，業務也不應該認為自己就懂全部的，反過來雖然產品擁有決策權，也可以聽一聽業務給出的信息。針對界面的爭論，其實可以用一個巧妙的辦法解決，也就是各自去搜集證據，來佐證自己的觀點，像競品的方案，用戶交互的規范，用戶的反饋都可以成為證據。

大家把證明自己的觀點一一擺出來，充分討論并取得理解。

當然，如果不能取得理解，那還是尊重產品的權利范圍。

回顧文本，我們講述了，企業數字化爭論的背后就蘊含著失敗的信號，這點從數字化轉型的失敗率來看，絕不是危言聳聽。

同時，我們細分了三種對立，并提出了解決方案。

首要的是權力的爭論，這也從流程設計上來劃分權利。

在從目標到方案的設計上，由于兩者的視角不同，建議使用考核的方法，考核業務的資源利用率，也考慮產品一定的業務達成率。

最后是在具體設計上，在界面和操作范疇，業務和產品有爭論時，一方面尊重產品的最終決策權，另一方面注意拿出各種證明各自從理性說話而少用“我覺得”“我認為”“我應該”。