品牌行銷策略，產品行銷與設計，各類型行銷推廣案例分享-品牌行銷點點讚
編輯導語：想做B端，但對于B端系統操作不熟練、不知道從何入手？作者為我們分享了一些快速上手B端系統的方法，供你閱讀參考。
最近一段時間都比較忙，剛接手了一個新系統，又趕上H1的項目，每天邊熟悉系統邊出方案，回過頭甚至有點驚訝，看似頭大無從下手的事情竟然不知不覺做完了。復盤一下接手新系統的一些體驗和收獲，希望可以給你帶來幫助～
一、先業務，后系統
了解系統前，先要了解系統背后支撐著什么業務、業務的運行模式，這樣可以讓你宏觀地了解整個系統的價值。例如了解它的用戶群體、它的定位、它的目標。
在這個基礎上結合現狀，結合目標制定后續的規劃。
舉個例子：
如果你負責的是一套交易的策略后臺系統，那你需要搞清楚以下知識點：
- 使用這套系統的業務方分別有哪些、他們各自是什么角色。如不同業務方向的各個策略運營團隊。
- 在交易的全鏈路過程中的哪個節點會用你的系統，分別會做什么操作。如配置策略、編輯策略、刪除策略、查詢策略。
- 這些操作在整個流程中起什么作用。如新增策略后，用戶提單時才能依賴策略算價，或依賴策略校驗來保證成單；再比如通過查詢策略能看出策略的改動頻次、策略改動的范圍，來判斷業務變化的趨勢。
- 異常情況：如中途刪除策略后是否導致部分模塊走不通，調整策略后是否提前同步用戶以免影響體驗，策略配置錯誤產生線上數據后推動規范運營的sop，以及系統如何提前監控預警等。
二、數據來源
如何快速上手一個系統最核心的是：
- 知道所有的底層數據從哪來；
- 有怎樣的取值邏輯；
- 基于此系統上做了什么展示邏輯；
- 操作邏輯等。
舉個例子：
你的策略系統有一個功能叫新增策略，業務在系統上配置策略時可能會基于各種維度，比如：
- 策略類型，是屬于基礎的策略，還是促銷玩法的策略？
- 策略性質，內部測試的還是外部使用的？
- 滿足用戶的角色，哪些用戶可以命中這條策略？
- 這條策略所生效的商品名稱、所生效時間、所生效的售賣渠道等信息。
要么這些字段的值就是寫死的，但是大多數情況下是分別調用各個系統、各個模塊的接口讀到的，比如角色系統、商品系統等，這就是數據來源。
這樣做的好處是你不用單獨維護一份別人的數據，后續人家數據變更時你無需感知。
三、數據交互
數據的流轉和交互是B端系統設計時必不可少的一點。我會把數據交互當做兩種來看，一種是系統內部的數據交互，另外一種是和外部系統的數據交互。
還是用策略系統舉個栗子，假設你要針對于某個A渠道，配置一條新的策略B。
如果渠道信息是在策略系統上的某個模塊維護的話，需要先前置建立好這個渠道A，那么可能需要用到渠道id、渠道名稱等一些業務屬性的信息。配置好渠道A后，再配置策略B，這個就是系統內部的數據交互。
系統外部的數據交互，比如這條策略B應用于A渠道，那用戶在A渠道下單時，就會命中策略B，策略會為用戶進行算價，展示在C端，這就是系統外部的數據交互。
四、系統邊界
我們一般說的系統邊界問題其實就是一句話，做自己該做的事兒～
哪些能力是你系統該做的，哪些能力不屬于你的，以及哪些數據你直接從上游獲取是合理的，而你還在彎彎繞繞從其他系統查。
舉個很經典的例子：中臺系統和業務系統的邊界。
中臺系統提供的是基礎服務，是通用化的能力，它對接的是多個業務系統，但不耦合業務邏輯，不做定制化需求。中臺系統的核心是維穩，提供通用化、穩定的服務和能力，業務側不必二次開發，可以直接復用。
業務系統最重要的還是貼合業務，一定和業務強耦合，一些基礎的服務不需要自己開發，但是針對業務有很重的業務邏輯就必須內部閉環。
邊界不清最大的問題是各個系統之間耦合嚴重，牽一發而動全身，各自承擔著不該自己承擔的功能，效率低下，穩定性差，PM必須識別出這個問題，不做冗余的功能，這樣對自己的系統有更多話語權。
本文由 @閆秀兒 原創發布于人人都是產品經理，未經作者許可，禁止轉載。
題圖來自Unsplash，基于CC0協議。
給作者打賞，鼓勵TA抓緊創作！
1人打賞
