中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

本文介紹了3個企業在流程變化、組織架構調整時，如何減少、甚至避免B端產品傷筋動骨大調整的技巧。

企業在經營中，業務流程變化，組織架構調整，是難以避免的事情；甚至隨著市場環境、競爭格局變化的加劇，二者需要更敏捷的隨需而變。

當業務流程或組織架構變革時，不但帶來B端產品使用角色的調整，而且經常需要產品流程的大調整、產品功能的大升級。

有些城市道路管道鋪線，經常扒開馬路，扒了填，填了扒，段子手就把建設工人稱為“扒路軍”。其實是嘲諷規劃不到位，設計不科學，甚至各自為政，管線規劃缺乏通盤考慮。

B端產品如果規劃不合理，產品設計耦合性過高，企業每次流程變化、組織架構調整時，產品技術人員，也是充當“扒路軍”的角色，把產品反復扒開改，改了扒。產品技術團隊，輕則加班加點，重則拉出去封閉，把原有產品重構，翻個底朝天。

其實，SaaS（是Software-as-a-Service的縮寫名稱，意思為軟件即服務，即通過網絡提供軟件服務。）軟件服務商在產品設計時，對業務流程變化、組織架構調整的適應程度是挺高的。但是，大多B端產品經理并沒有SaaS軟件服務商的工作背景，這也難為他們了。

那么，在企業流程變化、組織架構調整時，如何減少、甚至避免B端產品傷筋動骨的大調整呢？

我結合以前在SaaS軟件服務商的工作經歷，提供如下幾種策略。

一、多狀態單據需要拆單，并支持流程可定義

1. B、C端訂單狀態個數對比

C端訂單，一個單據五六個、甚至七八個狀態很正常，因為大多數這些訂單狀態的變化都跟用戶操作有關，或者這些狀態的變化都要通知用戶。

比如我們常見的電商訂單至少有“待支付、支付成功、已發貨、已完成、已關閉”這五個狀態，且這五個狀態都是用戶這個角色關心的。

再比如我做的旅游度假訂單，用戶能夠看到的訂單狀態至少有“待支付、定金已付待付尾款、尾款分批支付中、已付全款、尾款支付超時關閉、出行中、服務完成、退改中、訂單關閉”，這九個狀態。

對于B端產品，就不適合在一個單據上設計多個狀態了。因為，B端一個業務中，有不同的角色來處理。比如采購業務，采購員負責下單、質檢員負責到貨驗收、倉庫負責入庫、采購員或財務負責對賬、財務負責支付結算等。

2. B端單據設計不合理，是癥結所在

若是B端采購業務，把所有信息都設計在采購訂單上，狀態復雜不說，而且不易于不同角色的人員進行操作。更重要的是，各類信息都依附于采購訂單，難以支持業務流程的變化，更無法根據不同采購物資設置不同的采購流程。

試想一下，重要物資，每次采購入庫都需要檢驗。而某些常見低價值的標準物料入庫無需檢驗，若采購質檢、采購入庫信息都填在采購訂單上，會造成有些單據有采購合格數量。有些物料要么自動默認合格，要么空著，多亂啊。

若哪一天采購質檢標準變了，原來不需要質檢的某物料現在需要質檢了；當統計此物料的質檢數據時，還需人為記著從什么時間開始質檢的。否則，統計的數據不易解讀。

3. 解決方案

解決這些問題，一般本著“高內聚、低耦合”的思路，把流程中各個節點打散，支持自由組合。

比如在采購流程中，下單、到貨、質檢、入庫、對賬、支付等環節，都是獨立設計單據，每類單據可以根據上游單據生成。也可以根據業務需要省略某些單據，比如不需要質檢的物資，省去采購檢驗單。

每類單據都單獨設計單據狀態，比如采購訂單設計“已保存、已審核”的狀態，已審核的采購訂單支持生成采購到貨單或采購入庫單。

這樣，就把長鏈條的采購流程解耦開了，就非常方便的支持采購流程的按需組合。當業務流程變化、企業架構變化時，按照角色重新賦予每類單據的權限就可以了。

比如采購業務某類物資，無需做到貨單據，甚至無需做采購訂單，直接辦理采購入庫。銷售業務的某類產品不用依據發貨單出庫，直接根據銷售訂單出庫。這種“高內聚、低耦合”的設計方式都能很好的支持。

二、單據模板化，需支持多版本

1. 需求場景

當企業管理改善，或組織架構調整后，經常伴有業務流程的變化、管理要求的不同。對于業務流程變化的支持，在前面已給出了解決方案。而對于管理要求變化的支持，單據信息若能靈活定義，便能解決相當一部分。

因采購業務好理解，還是拿它舉例子。

比如公司要提高某類重點物資的采購到貨及時率，在下達采購訂單時，采購員必須要給供應商先約定采購到貨周期，同時還要清楚此物資的當前可用量、日均消耗量；甚至還要針對物料填寫一些備注信息。

這樣做，一是明確到貨時間、約定采購細節；二是可以知道余量夠不夠吃，避免青黃不接時斷糧。

但是，沒有必要每種物料這樣搞。尤其是到貨日期，不能采購員都填一個吧，這樣也無意義呀。

那怎么辦呢？

2. 解決方案

臨時風風火火的加班改產品方案、改程序，是一種辦法。

那要經常做這種調整呢？

顯然這不是一個好路子。

SaaS軟件服務商常用的辦法是：把重要單據進行模板化，在下單時，支持設置默認版本，支持選擇版本。

互聯網企業，在B端產品上，也可以采用這類辦法，給重要的單據，先設置模板。

此單據涉及的所有數據，在單據模板上都支持設置是否顯示、是否必輸。支持模板多版本、支持模板復制、支持模板的停啟用、支持模板的重命名、支持模板設置默認等。

除此之外，還支持字段的自定義。比如在單據頭（單據主信息）、單據體（單據明細信息）分別支持16個自定義字段名的字段。給這些字段提前定義好數據類型，支持設置是否必填等。當需要使用時，根據所增加的信息是否日期類型、文本類型、枚舉類型等，按需使用。

當這樣進行產品設計時，需求方也不會天天背后盯著加信息、改信息了；技術小伙伴也不用急慌慌的著急上線了；管理變化、業務變化的很多需求自然也隨時支持了。

大家都樂意、都高興，多香??！

三、對變動頻繁的業務流程或重要節點，進行參數化

仔細想一下，很多時候業務的小調整、小優化，不是某類選項在“是否”間調整，就是某個閾值調整，或者增加或減少一個選項。雖然這三類調整涵蓋不了全部，但是也能應付大部分日常業務優化與調整。

比如銷售業務，原來銷售出庫必須依據銷售訂單，即“銷售出庫必有訂單”選項，選擇“是”?，F在針對某些商品，可以直接填寫銷售出庫單，即“無訂單出庫”。若系統有參數支持“銷售出庫必有訂單”在“是否”間調整；那么，銷售出庫單既可以根據銷售訂單生成，也可以手工添加了。

比如采購到貨預警日期，原來在預計到貨日期前1天預警，現在調整到預計到貨日期2天前預警。系統若設置了此參數，也不用每次調整時，找技術同學操作了。

再比如庫存可用量，通常包含現存量，還可以包括“采購在途量、質檢在途量、生產在途量”等可選項，那么是否必須包括這些呢？這就可以根據企業需要及業務變化進行靈活調整了。

其實，這些參數化，可以做的更細。比如按商品品類設置是否支持無訂單出庫。再比如是否按倉庫設置庫存可用量等。

四、小結

B端產品要想快速的支持組織與流程變革，是要付出研發成本的，這點大家要清楚。互聯網公司講究MVP（Minimum Viable Product，最小可用產品），講究快速迭代，在這種背景下，講究快速上線。

但是，一旦MVP上線后，經常沒有動力或總感覺這類重要不緊急的“磨刀類”需求優先級不高，導致上述三類需求永遠排不上期。當再有業務變化時，又是著急忙慌的改方案、改產品。

這樣就進入了一個死循環，不斷的改產品，產品技術同學，成了名副其實的產品“扒路軍”。

不斷地扒開改，改了扒，最后算下來，投入的資源、精力更多。甚至到了某一天，改不動了，只好推翻重來。

在這里，需要提醒大家的是：首先知道什么是好的、什么是對的，然后，在綜合評估資源投入的前提下，需要朝正確的方向進軍！

相信長痛不如短痛，這是智者的選擇。