實(shí)體零售在數(shù)字化轉(zhuǎn)型，IT落地過程中可能存在系統(tǒng)與流程不匹配，IT與業(yè)務(wù)需求差異度較高，IT落地價(jià)值未能體現(xiàn)。在企業(yè)戰(zhàn)略思路與IT落地的過程中，需要如何梳理邏輯，勾勒詳圖，逆推業(yè)務(wù)需求是否實(shí)現(xiàn)。來伊份的數(shù)字化戰(zhàn)略與IT落地實(shí)踐，值得零售人去學(xué)習(xí)，在學(xué)習(xí)的基礎(chǔ)上去轉(zhuǎn)型、創(chuàng)新、超越。讓每個(gè)零售企業(yè)在數(shù)字化轉(zhuǎn)型落地、創(chuàng)新突破的道路上少走一些彎路。本文內(nèi)容根據(jù)來伊份副總裁趙漢利在2023智慧商業(yè)信息化、數(shù)字化、智能化高峰論壇上的演講整理。
目前，絕大多數(shù)的企業(yè)已經(jīng)明確將數(shù)字化納入企業(yè)戰(zhàn)略，而數(shù)字化轉(zhuǎn)型與企業(yè)原有戰(zhàn)略如何相融合，成為管理者面臨的首要難題。時(shí)代的變化迫使企業(yè)必須擁抱戰(zhàn)略和數(shù)字化的融合，從工業(yè)時(shí)代到數(shù)字時(shí)代，市場(chǎng)的關(guān)注點(diǎn)已從大眾轉(zhuǎn)向了個(gè)人，相應(yīng)地，企業(yè)對(duì)產(chǎn)品、市場(chǎng)、客戶、行業(yè)的價(jià)值理解也應(yīng)發(fā)生根本性的改變。
企業(yè)應(yīng)真正想清楚，所有的數(shù)字化背后的方案、行動(dòng)、政策、策略能真正支撐企業(yè)的目標(biāo)落地嗎？如果業(yè)務(wù)思考不清楚，給到IT的需求實(shí)現(xiàn)難度極大，并且收效甚微。
從零售數(shù)字化的發(fā)展趨勢(shì)和已經(jīng)得到驗(yàn)證的成功模式，我們不難發(fā)現(xiàn)，集團(tuán)型企業(yè)應(yīng)該統(tǒng)一規(guī)劃旗下所有子品牌和零售業(yè)務(wù)的數(shù)字化系統(tǒng)，從而無限接近理想中的數(shù)字化目標(biāo)。如多場(chǎng)景融合、多渠道打通、多業(yè)務(wù)串聯(lián)、多部門協(xié)同，以及集團(tuán)的IT數(shù)字化能力的多品牌復(fù)用。
需要盡快轉(zhuǎn)型改造一個(gè)品牌一套系統(tǒng)，一個(gè)業(yè)務(wù)一套系統(tǒng)，一個(gè)部門一套系統(tǒng)的局面。集團(tuán)層面重新統(tǒng)一規(guī)劃多品牌、多渠道、多業(yè)務(wù)的數(shù)字化系統(tǒng)。難點(diǎn)目前存在于兩個(gè)方面：一是如何進(jìn)行整體的集團(tuán)IT架構(gòu)規(guī)劃？二是如何找到適合多品牌集團(tuán)的完整的數(shù)字化系統(tǒng)和落地解決方案？而且這樣的規(guī)劃一定是基于長(zhǎng)期且細(xì)化的數(shù)字戰(zhàn)略考量，而不是短期的市場(chǎng)行為。
數(shù)字化的戰(zhàn)略、業(yè)務(wù)與IT實(shí)現(xiàn)的邏輯關(guān)系
數(shù)字化的背后，頂層思維決定了后面的所有落地，又決定了整個(gè)信息層服務(wù)的對(duì)象。業(yè)務(wù)層需要業(yè)務(wù)講清楚，實(shí)現(xiàn)業(yè)務(wù)與IT的融合。否則在業(yè)務(wù)需求落地的過程中，牽一發(fā)而動(dòng)百，就像蓋樓一樣，反復(fù)地推到重來不是零售企業(yè)IT建設(shè)之道。
當(dāng)戰(zhàn)略規(guī)劃完成之后，這只是第一步，接下來從財(cái)務(wù)指標(biāo)到客戶指標(biāo)、從流程指標(biāo)到能力指標(biāo)，IT是由業(yè)務(wù)來推導(dǎo)，業(yè)務(wù)推導(dǎo)出來需求后，進(jìn)而去支撐需求。其中邏輯不能反，業(yè)務(wù)邏輯清晰才可能實(shí)現(xiàn)IT支撐業(yè)務(wù)。
因此既懂業(yè)務(wù)又懂IT的人是最牛的。他能把能力沉淀到流程上。
從業(yè)務(wù)藍(lán)圖到業(yè)務(wù)結(jié)構(gòu)，從業(yè)務(wù)流程到業(yè)務(wù)詳圖再到IT實(shí)現(xiàn)，信息化相關(guān)負(fù)責(zé)人往往覺得非常浮躁，實(shí)際上這是因?yàn)闆]有列明業(yè)務(wù)詳圖，真正規(guī)劃好業(yè)務(wù)詳圖才有可能不再出現(xiàn)BUG。
每一個(gè)流程，連接到IT實(shí)現(xiàn)，當(dāng)IT推導(dǎo)回去進(jìn)行迭代時(shí)，一定有一個(gè)翻譯，而翻譯的水平?jīng)Q定了后續(xù)落實(shí)業(yè)務(wù)的水平。對(duì)業(yè)務(wù)的認(rèn)知和理解，決定了信息化相關(guān)人員能否將“翻譯”完美地實(shí)現(xiàn)，這就需要驗(yàn)證。這是一個(gè)不停的循環(huán)過程，在不停的循環(huán)當(dāng)中不斷完善。（如下圖）
細(xì)化業(yè)務(wù)流程，實(shí)現(xiàn)業(yè)務(wù)與IT二者之間的翻譯與溝通
細(xì)化業(yè)務(wù)流程的過程中，重要問題是信息化/數(shù)字化部門能否用通俗語言將其講清楚，細(xì)化的業(yè)務(wù)流程必須以客戶為中心，實(shí)現(xiàn)二者之間的翻譯與溝通。
即使是清晰的，一千個(gè)人眼里有一千種解法，在BPM需求專屬Jira空間中，一旦BPM需求受理流程由需求承接人提交通過，系統(tǒng)會(huì)自動(dòng)創(chuàng)建該需求Epic。
完整的BPM（業(yè)務(wù)流程管理）系統(tǒng)流程如下：
提報(bào)業(yè)務(wù)需求、需求受理人（部門總）——需求承接人（產(chǎn)品經(jīng)理）——產(chǎn)品排期&研發(fā)——產(chǎn)品驗(yàn)收——業(yè)務(wù)測(cè)試——功能上線——業(yè)務(wù)驗(yàn)收。
在上述需求承接人和產(chǎn)品排期&研發(fā)之間，涉及到流程主題、詳細(xì)描述需求（優(yōu)化后情況）、申請(qǐng)人、申請(qǐng)人部門、需求業(yè)務(wù)系統(tǒng)、流程ID、審批環(huán)節(jié)、審批人、流程創(chuàng)建日期、需求受理人、需求受理部門 。進(jìn)入PRD設(shè)計(jì)（自動(dòng)）——PRD評(píng)審中（手動(dòng)）——PRD評(píng)審?fù)瓿桑ㄊ謩?dòng)）——待開發(fā)（手動(dòng)）——UAT（手動(dòng)）開發(fā)完成，手動(dòng)調(diào)整——上線（手動(dòng)）發(fā)布完成，手動(dòng)調(diào)整上線狀態(tài)。
以上就是一個(gè)完整的翻譯過程。作為企業(yè)IT戰(zhàn)略落地的第一步，企業(yè)數(shù)字化負(fù)責(zé)人需要將系統(tǒng)藍(lán)圖規(guī)劃這個(gè)路徑劃清楚。
如何將業(yè)務(wù)轉(zhuǎn)化成流程？隨著業(yè)務(wù)的復(fù)雜度增高，如何在流程構(gòu)建的時(shí)候更模塊化？
比如：在業(yè)務(wù)過程中買A+B送C，交給部門開發(fā)，部門開發(fā)將業(yè)務(wù)需求寫死，又過了一個(gè)星期，業(yè)務(wù)需求變成了買A+B送F，部門開發(fā)又需要重寫；不要將業(yè)務(wù)需求的開發(fā)寫死。整個(gè)業(yè)務(wù)邏輯需要想清楚，否則將是一個(gè)非常頭疼的事情。因此我們?cè)谧鲕浖臅r(shí)候，戰(zhàn)略設(shè)計(jì)層要求所有維度大量增加，而這樣的思考與規(guī)劃只是數(shù)字化落地實(shí)踐其中之一......
因?yàn)椴磺�，所以迭代，因�(yàn)樽兓缘�。迭代是永恒的主題，因?yàn)檫@個(gè)世界唯一不變的是變化。
