早期的標桿企業(yè)內(nèi)曾經(jīng)提過這么一句話：“信息流跑不過物流”。

很多人對此有疑問：以網(wǎng)絡通信的速度，難道還跑不過幾個輪子的汽車嗎？

實際上，在很多企業(yè)的數(shù)字化應用場景中，我們確實可以看到信息流跑不過物流的情況。

以某些ERP系統(tǒng)為例，員工在線下完成工作后，還需要整理數(shù)據(jù)，并手動錄入到線上系統(tǒng)。這時候的IT系統(tǒng)僅僅作為記錄工具，數(shù)據(jù)的產(chǎn)生總是滯后于實際業(yè)務。

數(shù)據(jù)不會自己流動起來，只有人才能讓數(shù)據(jù)流動起來。

在這過程中，企業(yè)需要想明白：一個好用的IT系統(tǒng)，背后承載的業(yè)務價值、數(shù)據(jù)價值和運營價值是什么。

為什么上了一堆系統(tǒng)，卻很難用呢？

根本原因在于，這些系統(tǒng)并未真正實現(xiàn)作業(yè)過程的數(shù)字化。

目前，許多企業(yè)的系統(tǒng)還停留在信息化或記錄系統(tǒng)的階段，這類系統(tǒng)的一個重要特征是數(shù)據(jù)和作業(yè)相互分離。

員工在線下做一遍后，還得到線上再記錄一遍。這種重復操作不僅增加了員工的工作量，而且效率低下。于是，員工就容易產(chǎn)生抵觸情緒。

即使管理層采取強制措施要求員工使用，他們也可能會想方設法“鉆空子”。

此外，這種模式還會造成記錄過程滯后于真實的作業(yè)過程，使得數(shù)據(jù)及時性差，影響數(shù)據(jù)質(zhì)量和數(shù)據(jù)分析的有效性。

因此，這樣的IT系統(tǒng)在實際應用中難以推行。

數(shù)字化轉(zhuǎn)型的核心是業(yè)務變革。

在引入系統(tǒng)時，企業(yè)應該從業(yè)務變革的角度出發(fā)，讓數(shù)據(jù)和作業(yè)流程緊密結合，而不是為了上系統(tǒng)而上系統(tǒng)。

在IT系統(tǒng)上線的過程中，70%的工作重心應放在梳理和優(yōu)化業(yè)務流程、調(diào)整組織架構、構建運營機制等方面。

只有將作業(yè)過程與數(shù)字化融為一體，讓作業(yè)和記錄一次性同時完成，系統(tǒng)才能成為企業(yè)的工作平臺和作業(yè)平臺。

員工可以在系統(tǒng)內(nèi)完成工作，工作過程中自然會產(chǎn)生并流轉(zhuǎn)數(shù)據(jù)，達到所謂的“作業(yè)即數(shù)據(jù)，數(shù)據(jù)即作業(yè)”。

在互聯(lián)網(wǎng)領域，我們經(jīng)常提及MVP產(chǎn)品，即最小可行性產(chǎn)品。這種產(chǎn)品在設計之初，主要是為了解決某一類用戶的特定痛點。

以微信為例，它在最初上線之時，只為了解決一個問題：如何通過移動端即時發(fā)送文字信息，滿足用戶即時通信的需求。

隨著用戶量的增長，微信才逐步增加功能，進行產(chǎn)品迭代。

而在ToB領域，與MVP產(chǎn)品的設計邏輯有所不同，它更強調(diào)在第一個版本就要打通業(yè)務主線，實現(xiàn)核心數(shù)據(jù)的貫通。

這就要求企業(yè)要掌握好數(shù)字化建設的節(jié)奏。

比如，我現(xiàn)在需要一個交通工具，雖然我可能想要一輛跑車，但現(xiàn)階段以我的能力，還無法直接制造出一輛完美的跑車。

那么，我就可以選擇先制造一輛自行車來滿足基本的交通需求，在使用過程中再逐步對其進行升級。

但如果我一開始就瞄準著一輛跑車制造，那么我只能從零開始，先建一個輪子，再建兩個輪子，然后搭建車身、配套燈光等等。但問題在于，就算是完成了80%的進度，這輛車也無法上路行駛，無法解決當下的需求。

因此，第一階段的建設至關重要。

同理，在進行ToB領域的數(shù)字化建設時，必須盡可能打通業(yè)務主線，確保在初始建設階段就能讓業(yè)務運轉(zhuǎn)起來。

以LTC數(shù)字化為例，在數(shù)字化的初始階段，就要確保打通整個LTC從線索到回款、端到端貫穿企業(yè)運作的主業(yè)務流，并將這些主線數(shù)據(jù)打通并納入系統(tǒng)。否則，整個LTC的數(shù)據(jù)都將無法被有效使用。

同時，圍繞LTC主線的周邊應用功能，如客戶關系管理、評審決策、Pipeline管理等，也將無法得到豐富和完善。整個LTC數(shù)字化建設就會像一個跛腳的人，難以穩(wěn)健前行。

為了提高系統(tǒng)的使用率，管理層只能強制要求員工：只要創(chuàng)建訂單，就必須關聯(lián)立項商機。

沒辦法，為了使訂單流程能繼續(xù)，員工只能選擇線下完成合同之后，再來錄入商機數(shù)據(jù)并立項。最終，商機管理系統(tǒng)還是變成了一個記錄系統(tǒng)。

正常情況下，商業(yè)數(shù)據(jù)應是呈現(xiàn)金字塔式的分布，從立項到方案、報價、成單逐步遞減。然而，由于線索管理、合同管理等系統(tǒng)的不完善，大部分商機數(shù)據(jù)都停留在了立項階段，后續(xù)方案、報價、成交階段的數(shù)據(jù)更是寥寥無幾。

識別出關鍵業(yè)務痛點，抓住每個領域的關鍵業(yè)務數(shù)據(jù)，分階段同時進行構建，再逐漸迭代升級是非常重要的。

在構建過程中，要避免“煙囪式”的垂直建設方式，即各個關鍵業(yè)務數(shù)據(jù)之間各干各的、各用各的，互不相通。

在“煙囪式”IT系統(tǒng)中，子系統(tǒng)就像一個個的“煙囪”，自己燒得火熱，對其他爐子的冷暖卻一無所知。

企業(yè)需要通過梳理主要矛盾、識別關鍵數(shù)據(jù)和業(yè)務痛點，并橫向地、像打地基一樣，層層遞進地構建IT系統(tǒng)。

接下來，我們要探討的是在進行作業(yè)過程數(shù)字化時，應該怎么選擇關鍵業(yè)務數(shù)據(jù)。

在過去，當企業(yè)引入CRM系統(tǒng)或其他業(yè)務系統(tǒng)時，他們往往只是簡單地根據(jù)系統(tǒng)提供的功能來決定使用哪些功能。

然而，這種做法并沒有深入考慮這些功能是否真正適應企業(yè)的業(yè)務特性、應用場景以及核心業(yè)務需求。

為了避免這種情況，在推進作業(yè)過程數(shù)字化時，我們必須首先深入分析業(yè)務，特別是其中的核心業(yè)務矛盾。

這些矛盾通常隱藏在具有“三高”特點的作業(yè)場景中——高頻、高耗能、高風險。

只有準確識別了這些業(yè)務矛盾，我們才能有針對性地設計業(yè)務變革和數(shù)字化變革，從而確保系統(tǒng)上線后能夠真正解決日常業(yè)務問題，并提升業(yè)務價值。

在識別了這些高頻、高耗能、高風險的關鍵業(yè)務后，我們還可以通過矩陣圖來對它們進行優(yōu)先級排序。

一般來說，那些高頻、高耗能且技術難度相對較低的場景，數(shù)字化后的業(yè)務價值最高，投入也相對較低，因此應該優(yōu)先考慮。

而對于那些業(yè)務價值較低、頻率不高、參與人數(shù)少且技術難度大的場景，我們可以將其優(yōu)先級排在后面。

例如，像戰(zhàn)略規(guī)劃的相關產(chǎn)品，如果一年只用一次，那么在數(shù)字化水平較低的公司中，可能就不會將其作為當前重點考慮的方向。

與傳統(tǒng)業(yè)務變革不太一樣的是，數(shù)字化變革需要緊密圍繞應用場景來展開，因為最終它將被轉(zhuǎn)化為IT系統(tǒng)供用戶使用。

企業(yè)數(shù)字化變革，必須明確地知道“場景在哪”“用戶是誰”“痛點在哪”。

這就涉及到了應用場景設計和用戶體驗設計的重要性，這兩點在過去的信息化時代并未受到足夠重視。當時的大部分系統(tǒng)強調(diào)以流程為中心的業(yè)務設計，相對忽視了用戶體驗和應用場景的設計。

然而，在數(shù)字化時代，我們必須高度重視用戶體驗設計。

因為只有當用戶覺得系統(tǒng)好用，他們才會愿意一直使用，整個系統(tǒng)才能真正運轉(zhuǎn)起來，才能最終實現(xiàn)業(yè)務指標改善、業(yè)務價值提升。

在設計過程中，可以從四個方向來考慮變革方向的設計。

效率模式主要涉及到一些非常標準化的動作，這些動作的數(shù)據(jù)相對結構化。

針對這些動作，我們可以制定一些規(guī)定的規(guī)則和動作，并進行數(shù)字化和自動化的設計，從而提高整個業(yè)務運作的效率。

實際上，在面向消費者（to C）的互聯(lián)網(wǎng)領域，這種訂單可視化已經(jīng)實現(xiàn)很久了。我們在電商平臺上下的每一個訂單，都可以清楚地查看其發(fā)貨物流、派送進度等整個過程。

然而，在面向企業(yè)（to B）的生產(chǎn)制造領域，這一點還遠遠沒有實現(xiàn)。因此，這些應用場景是未來企業(yè)數(shù)字化可以投入精力和資本去改善的重要方向。

專家模式主要應對的是那些高度依賴個人能力和經(jīng)驗的業(yè)務場景。在這種模式下，我們可以通過數(shù)據(jù)建模的方式來復制專家的能力。

以企業(yè)經(jīng)營診斷和分析為例，過去，這項工作可能需要財經(jīng)領域經(jīng)驗豐富的專家來完成。他們需要從企業(yè)導出經(jīng)營報表，制定各種指標，然后分析企業(yè)的經(jīng)營情況和潛在風險。

然而，在數(shù)字化時代，我們可以將這些結構化的業(yè)務數(shù)據(jù)和財務數(shù)據(jù)通過數(shù)字化模式進行整理，包括經(jīng)營指標的結構化之后，就可以構建經(jīng)營診斷的分析模型，從而指導企業(yè)進行業(yè)務決策。

協(xié)同模式主要解決的是過去由于缺乏數(shù)字化平臺，許多業(yè)務流程只能串行進行的問題。在串行流程中，一個環(huán)節(jié)完成后才能傳遞給下一個環(huán)節(jié)，這種傳遞往往依賴人工，效率相對較低。

然而，有了數(shù)字化技術的支持，我們可以消除這種信息不對稱，讓所有的業(yè)務活動并行進行。

以供應鏈中的計劃管理業(yè)務場景為例。傳統(tǒng)上，在制定供應鏈計劃時，企業(yè)往往從客戶的要貨預測出發(fā)?？蛻粝聠魏螅瑫a(chǎn)生采購訂單（PO）。采購部門看到訂單后，會制定相應的物料需求計劃，再制定詳細的采購計劃，最后進行采購執(zhí)行。這一流程需要龐大的廠家協(xié)同組織來管理整個計劃的產(chǎn)生。

然而，這種運作方式存在明顯弊端。采購部門在最后階段才得知需要采購的具體物品，導致采購過程非常被動。

由于某些物料的備貨周期較長，而一些行業(yè)對交貨期的要求又非常高，如半導體和新能源行業(yè)。這種傳統(tǒng)的采購方式可能會嚴重影響供應鏈的執(zhí)行效率，甚至導致交貨期延后，進而影響整個生產(chǎn)制造的效率。

為了解決這些問題，我們可以考慮對傳統(tǒng)的計劃運作模式進行數(shù)字化變革，采用協(xié)同并行的運作模式，將采購業(yè)務與銷售的要貨預測環(huán)節(jié)進行前置打通。

借助數(shù)字化工具，供應鏈的采購端能夠提前看到未來三個月甚至半年內(nèi)，可能有哪些客戶會需要哪些品類或物料。采購部門可以提前制定采購計劃，并進行相應的備貨準備。隨著預測逐漸轉(zhuǎn)化為實際的采購訂單（PO），物料需求再進一步細化。

這種端到端的業(yè)務過程將大幅提高效率，同時大幅降低時間成本。原本依賴人力組織的廠家協(xié)同模式，也將逐漸被數(shù)字化平臺所替代，從而大幅減少人力成本。這就是產(chǎn)銷協(xié)同的一個典型應用。

在以前的創(chuàng)新過程中，許多業(yè)務都需要付出巨大的試錯成本，尤其是線下操作。

通過以上四種模式，企業(yè)可以找到作業(yè)過程數(shù)字化的變革方向，重塑和改變作業(yè)模式。