編者按：本文來(lái)自微信公眾號“ToB老人家”（ID:ToBlaorenjia），作者：王戴明，36氪經(jīng)授權發(fā)布。
對于大部分SaaS公司來(lái)說(shuō)，產(chǎn)品標準化程度決定了企業(yè)的生死。今天，我們就站在產(chǎn)品經(jīng)理的角度，來(lái)看看SaaS從0到1的標準化設計應該怎么做。
限于篇幅，本文對如何畫(huà)流程圖、如何制作原型等基礎技能就不再敷述，側重闡述實(shí)現SaaS標準化設計的要點(diǎn)。
為便于大家理解，本文會(huì )以一個(gè)案例為線(xiàn)索，一步一步演示如何從0到1設計一款SaaS產(chǎn)品。
雖然同為B端產(chǎn)品，SaaS與自研系統的差異卻非常明顯。
從根本上來(lái)說(shuō)，SaaS產(chǎn)品需要服務(wù)于眾多企業(yè)：少則幾十家，多則幾萬(wàn)家。因此，對業(yè)務(wù)的包容性需要很強。代價(jià)則是產(chǎn)品迭代速度相對緩慢。
自研系統由于只服務(wù)于一家企業(yè)，強調的是貼身服務(wù)，因此對產(chǎn)品包容性要求較低，但是很強調迭代的速度。
雖然SaaS和自研產(chǎn)品的邏輯是類(lèi)似的，但是對產(chǎn)品經(jīng)理能力的要求卻有一定差異。
具體可以參考下圖：
內部B端產(chǎn)品經(jīng)理更多是輔助角色。因此比較強調深入參與和支持業(yè)務(wù)，通過(guò)協(xié)調甚至推動(dòng)業(yè)務(wù)部門(mén)，達成公司目標。
SaaS產(chǎn)品經(jīng)理就不一樣了。因為負責商業(yè)化產(chǎn)品，是公司實(shí)現營(yíng)收和盈利的核心環(huán)節，所以比較強調產(chǎn)品本身的架構能力和設計能力。
我個(gè)人認為，衡量SaaS產(chǎn)品經(jīng)理的優(yōu)劣，其中一個(gè)重要的標準就是：當用戶(hù)數不斷增加，產(chǎn)品功能會(huì )不會(huì )被推翻或大幅修改，即能不能多做加法，少做減法和改法。
關(guān)于SaaS產(chǎn)品經(jīng)理能力的更多觀(guān)點(diǎn)，可以關(guān)注公眾號：ToB老人家，閱讀文章《我的實(shí)踐：如何提升B端產(chǎn)品架構能力》。
產(chǎn)品標準化對SaaS公司至關(guān)重要。
曾經(jīng)聽(tīng)某知名SaaS公司大區總監說(shuō)，某個(gè)百萬(wàn)級項目談得非常好，約定4個(gè)月交付上線(xiàn)。
結果到了第3個(gè)月，客戶(hù)要求推倒重來(lái)，按客戶(hù)實(shí)際業(yè)務(wù)重新開(kāi)發(fā)。這位銷(xiāo)售總監抱怨道：“前面談得好好的，就用標準化產(chǎn)品。但到項目后期，客戶(hù)卻說(shuō)產(chǎn)品滿(mǎn)足不了業(yè)務(wù)需求。真是搞不懂?！?/p>
這就是典型的產(chǎn)品能力支撐不了銷(xiāo)售能力。如果這樣的項目很多，SaaS公司就很難盈利。
具體來(lái)說(shuō)，SaaS標準化有以下三個(gè)重要意義：
SaaS公司最大的成本投入是研發(fā)成本， 如果每一個(gè)項目都是通過(guò)配置完成交付，這意味著(zhù)隨著(zhù)用戶(hù)數的增加，研發(fā)成本會(huì )被逐步攤薄，最終形成規模效應。因此標準化是SaaS公司盈利的關(guān)鍵之一。
B端客戶(hù)真正希望購買(mǎi)的是“行業(yè)最佳實(shí)踐”。
即便SaaS公司具備豐富的行業(yè)經(jīng)驗，也了解行業(yè)標桿的業(yè)務(wù)策略和執行方案，如果SaaS產(chǎn)品不能體現和支撐這些“最佳實(shí)踐”，那么推廣和執行的成本都會(huì )很高。
所謂標準化，其實(shí)就是把領(lǐng)先企業(yè)的解決方案進(jìn)行提煉，再固化到系統中。這些固化的解決方案，是SaaS系統的靈魂。
如果SaaS公司依賴(lài)運營(yíng)而不是依賴(lài)產(chǎn)品來(lái)保障“客戶(hù)成功”，那產(chǎn)品和產(chǎn)品經(jīng)理的價(jià)值都會(huì )大打折扣。
標準化會(huì )不斷增強產(chǎn)品的配置能力，使得產(chǎn)品越來(lái)越厚重，價(jià)值越來(lái)越高。也只有厚重的B端產(chǎn)品，才能磨煉和體現產(chǎn)品經(jīng)理的產(chǎn)品能力。
標準化策略是SaaS產(chǎn)品策略的重要組成部分。完整的SaaS產(chǎn)品策略這里不再敷述，感興趣的讀者可以關(guān)注公眾號：ToB老人家，閱讀文章《SaaS從0到1，產(chǎn)品策略決定成敗》。
SaaS標準化策略可以分為三個(gè)部分，分別是：
標準化最重要的策略，是確定“不滿(mǎn)足哪些客戶(hù)的需求”。
“一套產(chǎn)品吃遍天下”的傳統軟件時(shí)代，已經(jīng)過(guò)去了。即便我們要占領(lǐng)多個(gè)細分市場(chǎng)，也要謹慎判斷，是否通過(guò)“一個(gè)行業(yè)版本”滿(mǎn)足全部客戶(hù)的需求。
比如，在快消品行業(yè)，經(jīng)銷(xiāo)商和生產(chǎn)商的管理模式差異是比較大的。對于經(jīng)銷(xiāo)商來(lái)說(shuō)，組織和權限的管理是相對簡(jiǎn)單的，也不涉及嚴格的外部賬號管理；而品牌商則有復雜的多組織管理的需求，包括外部組織和賬號的管理。
再比如，經(jīng)銷(xiāo)商的價(jià)格體系是相對簡(jiǎn)單的，不同等級的客戶(hù)可能會(huì )有對應的價(jià)目表，部分客戶(hù)會(huì )簽訂特定的價(jià)格協(xié)議；但是品牌商的價(jià)格體系則復雜很多，不同分公司、不同區域、不同商圈等級都會(huì )影響具體的價(jià)格。這是因為“價(jià)盤(pán)”是品牌商的生命線(xiàn)，所以精細的控制是有必要的。
快消品經(jīng)銷(xiāo)商和品牌商需求差異
當然，并不是說(shuō)，我們一定不能在一個(gè)版本滿(mǎn)足多個(gè)行業(yè)的需求。過(guò)去SAP、Oracle的成功已經(jīng)證明這一點(diǎn)是可以實(shí)現的。
但是，SaaS引以為傲的正是足夠“高可用”的系統。過(guò)于臃腫的產(chǎn)品，會(huì )大大增加客戶(hù)的使用成本。
反過(guò)來(lái)說(shuō)，“一個(gè)版本滿(mǎn)足所有需求”當然是不正確的。但是如果盲目的橫向擴充版本，也會(huì )給SaaS公司帶來(lái)沉重的研發(fā)負擔。
比如，當我們面對“非處方藥”行業(yè)的客戶(hù)，是否需要劃分出一個(gè)版本呢？雖然并不是快消品行業(yè)，但是“非處方藥”卻在學(xué)習快消品行業(yè)的分銷(xiāo)模式。在這種情況下，如果我們提供的是分銷(xiāo)SaaS產(chǎn)品，就暫時(shí)沒(méi)有必要單獨為“非處方藥”劃分一個(gè)行業(yè)版本出來(lái)。
標準化第二重要的策略，是決定“哪些功能不標準化”。
對于大部分SaaS，90%以上的功能是能夠在產(chǎn)品層面進(jìn)行標準化的，但是可能有10%的功能是很難標準化的。分清楚哪些功能可以“在產(chǎn)品層面進(jìn)行標準化”，也非常重要。
比如，中小企業(yè)對報表的需求相對簡(jiǎn)單，因此報表功能是相對容易標準化的；但是對于百億級企業(yè)來(lái)說(shuō)，報表是一個(gè)高度復雜且不能妥協(xié)的需求，因此對于還沒(méi)有BI或者PaaS產(chǎn)品的SaaS企業(yè)來(lái)說(shuō)，暫時(shí)進(jìn)行定制也是一個(gè)可行的選擇。
對于無(wú)法“在功能層進(jìn)行標準化”的功能，我們要想辦法在開(kāi)發(fā)層進(jìn)行標準化，即通常我們所說(shuō)的PaaS，現在流行的叫法是“低代碼”。
低代碼是一個(gè)很“古老”的事物。我還在Oracle公司的時(shí)候，就很頻繁的使用Oracle的低代碼能力了——我們又叫personalization。通過(guò)它，我們可以改變字段的屬性，也可以嵌入SQL甚至package。
也就是說(shuō)，即便是能夠靈活二次開(kāi)發(fā)的傳統軟件，也非常依賴(lài)低代碼。更不用說(shuō)二次開(kāi)發(fā)相對困難的SaaS公司了。
因此，如果一家SaaS決意要做大，PaaS能力就不是可選題，而是必選題。
但是，自研PaaS平臺確實(shí)是一個(gè)費錢(qián)的工作，并不是所有SaaS創(chuàng )業(yè)公司，都能夠輕易負擔得起的。好消息是，中國SaaS正在進(jìn)入平臺時(shí)代，釘釘、企業(yè)微信逐步增強的低代碼能力，有望幫助SaaS公司低成本的擁有“PaaS自由”。
和自研系統相比，SaaS產(chǎn)品的設計更依賴(lài)長(cháng)遠規劃。這是SaaS設計的核心，也是SaaS設計的難點(diǎn)。
重視長(cháng)遠規劃，主要是由于兩個(gè)原因。
由于標準化強調配置能力，因此同樣一個(gè)功能，所需要的開(kāi)發(fā)量可能是自研系統的數倍。一旦開(kāi)發(fā)了拙劣的功能，就可能對開(kāi)發(fā)資源造成驚人的浪費。
更重要的是，作為“公用產(chǎn)品”，SaaS必須保持簡(jiǎn)潔性：如果系統充斥著(zhù)一堆雞肋的功能，且有少數企業(yè)堅持在使用，那么會(huì )對系統迭代造成阻礙。讀者可以思考一下，當規劃的新功能與這些雞肋功能產(chǎn)生沖突，產(chǎn)品經(jīng)理應該如何處理？
因此，好的SaaS設計就是盡量做“加法”，避免做“減法”和“改法”。
當然，標準化設計對產(chǎn)品經(jīng)理本身也是有要求的。我常常比喻，所謂的標準化設計，就像在棋盤(pán)上放棋子：棋盤(pán)就是產(chǎn)品經(jīng)理所擁有的架構能力，棋子就是具體的需求。沒(méi)有棋盤(pán)，就不可能正確落子。
從設計過(guò)程來(lái)說(shuō)，標準化設計可以遵循以下四個(gè)步驟：
所謂策略層梳理，是站在相對宏觀(guān)的層面梳理業(yè)務(wù)。具體又包括以下步驟：
1.1、明確業(yè)務(wù)范圍
企業(yè)的業(yè)務(wù)可以分為前中后臺業(yè)務(wù)，前臺業(yè)務(wù)包括商城APP等，中臺業(yè)務(wù)包括CRM、訂單管理、物流管理等，后臺業(yè)務(wù)則包括HR、財務(wù)等。
我們首先需要明確，第一版SaaS產(chǎn)品版本主要是滿(mǎn)足哪一塊業(yè)務(wù)需求。劃定好了邊界，才能匹配公司的戰略和資源。
案例：
一家知名快消品廠(chǎng)家找到某SaaS公司（簡(jiǎn)稱(chēng)A公司），希望開(kāi)發(fā)一款管理銷(xiāo)售人員的移動(dòng)APP。經(jīng)過(guò)溝通，SaaS產(chǎn)品經(jīng)理小李意識到，客戶(hù)的需求實(shí)際上是分銷(xiāo)管理，包括銷(xiāo)售訂單管理、銷(xiāo)售人員管理和門(mén)店管理等。
雖然A公司有服務(wù)于快消品'經(jīng)銷(xiāo)商’的分銷(xiāo)管理系統，但是一直苦于無(wú)法切入利潤更豐厚、收入更穩定的快消品'品牌商’市場(chǎng)，這正是一個(gè)非常好的機會(huì )。
1.2、梳理經(jīng)營(yíng)策略
所謂經(jīng)營(yíng)策略，其實(shí)就是企業(yè)的打法。比如，在線(xiàn)下分銷(xiāo)業(yè)務(wù)中，用戶(hù)企業(yè)是采用深度分銷(xiāo)？還是兼有直銷(xiāo)？搞清楚客戶(hù)的經(jīng)營(yíng)策略，才能理清產(chǎn)品研發(fā)的思路。
此外，我們必須明白，SaaS是給一個(gè)行業(yè)的眾多客戶(hù)使用的。因此，我們還需要對企業(yè)所在行業(yè)的經(jīng)營(yíng)策略進(jìn)行梳理。這樣，一方面可以將客戶(hù)的經(jīng)營(yíng)策略匹配到行業(yè)的經(jīng)營(yíng)策略，便于我們抓住本質(zhì)，確保產(chǎn)品的通用性；另一方面，也可以通盤(pán)考慮未來(lái)的拓展方向，提前打好架構基礎。
比如，快消品線(xiàn)下分銷(xiāo)常見(jiàn)的策略包括大批發(fā)制、多級分銷(xiāo)、深度分銷(xiāo)、直銷(xiāo)、車(chē)銷(xiāo)等，而深度分銷(xiāo)又分為廠(chǎng)家覆蓋模式和經(jīng)銷(xiāo)商覆蓋模式。作為產(chǎn)品經(jīng)理，有必要全面梳理這些模式，才能在產(chǎn)品設計時(shí)胸有成竹。
案例：
小李和客戶(hù)溝通后，發(fā)現該快消品廠(chǎng)家主要采用了大批發(fā)制、直銷(xiāo)和深度分銷(xiāo)三種經(jīng)營(yíng)策略，屬于行業(yè)比較經(jīng)典的打法，可以先開(kāi)發(fā)這三種分銷(xiāo)模式，同時(shí)兼顧到未來(lái)向多級分銷(xiāo)和車(chē)銷(xiāo)的拓展。
1）大批發(fā)制
大批發(fā)是廠(chǎng)家把貨賣(mài)給批發(fā)商，由批發(fā)商再進(jìn)行二次分銷(xiāo)。大批發(fā)模式雖然是比較粗放的分銷(xiāo)方式，但是當廠(chǎng)家管理能力不足時(shí)，采用大批發(fā)模式可以實(shí)現快速鋪貨，因此仍然是常見(jiàn)的一種分銷(xiāo)模式。
2）直銷(xiāo)制
快消品行業(yè)有40%左右的銷(xiāo)量，都是通過(guò)以大超市為代表的現代通路完成的。這些大超市往往是區域連鎖甚至全國連鎖，可以樹(shù)立品牌形象，但是進(jìn)入門(mén)檻高、談判過(guò)程復雜，因此，往往是由快消品廠(chǎng)家直接進(jìn)行合作。
3）深度分銷(xiāo)
深度分銷(xiāo)是快消品分銷(xiāo)的重要方向。實(shí)行深度分銷(xiāo)的企業(yè)，往往已經(jīng)具備一定的規模和管理能力。他們將區域進(jìn)行劃分，指定經(jīng)銷(xiāo)商專(zhuān)營(yíng)，強調終端門(mén)店的鋪貨率、陳列、新品普及率等。
對于企業(yè)來(lái)說(shuō)，深度分銷(xiāo)可以最大化挖掘終端門(mén)店的潛力，提高新品和高毛利商品的銷(xiāo)售量，并有效的阻擊競爭對手。因此，這種模式一直是伊利、康師傅、可口可樂(lè )等大型快消品企業(yè)的重點(diǎn)分銷(xiāo)模式。
1.3、梳理業(yè)務(wù)難點(diǎn)
相對于傳統軟件，SaaS是后來(lái)者。
根據產(chǎn)品替換公式：新產(chǎn)品價(jià)值>舊產(chǎn)品價(jià)值+替換成本，只有SaaS提供了更大的價(jià)值，客戶(hù)才會(huì )考慮購買(mǎi)。退一步說(shuō)，即便沒(méi)有競爭的傳統軟件，SaaS也必須解決“以前無(wú)法解決的問(wèn)題”，才能在激烈的競爭中站穩腳跟。
因此，梳理清楚業(yè)務(wù)難點(diǎn)，明白“客戶(hù)為什么選擇我們”，是非常重要的工作，可以讓我們把資源集中在最關(guān)鍵的功能上。而不是分散資源，做那些客戶(hù)雖然愿意使用，但是不構成“差異化競爭力”的功能。
案例：
經(jīng)過(guò)和客戶(hù)溝通，小李了解到，其實(shí)客戶(hù)之前已經(jīng)耗費上百萬(wàn)實(shí)施了某國際知名品牌的CRM系統，但是移動(dòng)端的用戶(hù)體驗非常糟糕。除了使用上不夠高可用，需要反復培訓才能上手；低下的操作效率和緩慢的響應速度，更是使得系統的推廣困難重重。
客戶(hù)為什么選擇由A公司來(lái)開(kāi)發(fā)分銷(xiāo)系統，就是在體驗了A公司的移動(dòng)端產(chǎn)品后，認為產(chǎn)品的用戶(hù)體驗非常優(yōu)秀，可以解決當前系統推廣的最大難題。
了解到客戶(hù)的訴求后，小李意識到：這個(gè)針對快消品廠(chǎng)家的SaaS系統，設計的重心要放在移動(dòng)端。
快消品行業(yè)普遍存在銷(xiāo)售人員學(xué)歷低、管理難的問(wèn)題，如果通過(guò)移動(dòng)端大大提高員工效率、降低員工使用難度，那么該SaaS產(chǎn)品將對快消品品牌商產(chǎn)生巨大吸引力。
業(yè)務(wù)層梳理，最有效的做法就是畫(huà)業(yè)務(wù)流程圖。
流程圖的重點(diǎn)在于，產(chǎn)品經(jīng)理要幫助客戶(hù)梳理清楚業(yè)務(wù)和需求，避免錯亂和遺漏。而做到這一點(diǎn)的關(guān)鍵，是產(chǎn)品經(jīng)理要有一定的架構能力，即知道典范的流程應該如何流轉。
如果是針對大客戶(hù)的SaaS，那么建議到客戶(hù)現場(chǎng)呆一段時(shí)間。大客戶(hù)的要求比較細致，現場(chǎng)溝通可以提高溝通的效率。
如果是針對小客戶(hù)的SaaS，那么建議你先找到幾個(gè)種子用戶(hù)，通過(guò)流程圖，確保1.0版本是他們能夠接受的MVP（最小可行產(chǎn)品）。
流程圖繪制細節是基本功，這里就不再敷述。下面放一張我曾經(jīng)繪制的流程圖供大家參考。
案例：
一開(kāi)始，該快消品企業(yè)認為自己的需求很簡(jiǎn)單，主要是業(yè)務(wù)人員在手機端錄入銷(xiāo)售訂單，再通過(guò)接口實(shí)時(shí)傳送到已有的ERP系統即可，如下圖：
小李并沒(méi)有急于下結論，而是在黑板上畫(huà)出了典范的分銷(xiāo)管理流程，然后按照流程環(huán)節逐個(gè)進(jìn)行梳理，如下圖：
經(jīng)過(guò)梳理，小李很快發(fā)現，該廠(chǎng)家對于區域連鎖賣(mài)場(chǎng)等大客戶(hù)，采取的是廠(chǎng)家業(yè)務(wù)員拜訪(fǎng)、工廠(chǎng)直接發(fā)貨的直營(yíng)銷(xiāo)售策略；對于非連鎖便利店等小客戶(hù)，采取的是廠(chǎng)家業(yè)務(wù)員拜訪(fǎng)、經(jīng)銷(xiāo)商發(fā)貨的深度分銷(xiāo)策略。因此，客戶(hù)實(shí)際上有兩種不同的銷(xiāo)售管理流程，如下圖：
流程梳理清楚，設計思路也就清晰了。同時(shí)，小李專(zhuān)業(yè)的需求梳理方法也得到了客戶(hù)認可，客戶(hù)領(lǐng)導當場(chǎng)表達了合作的意向。
企業(yè)業(yè)務(wù)的開(kāi)展，是基于多個(gè)部門(mén)的相互協(xié)同和相互監督的。當用戶(hù)在使用SaaS系統時(shí)，流程流轉、數據安全性都必須符合企業(yè)協(xié)同與管控的要求。這就需要我們設計好組織、角色和權限功能。而這里面最有難度的，就是多組織架構設計。
比如，某飲料公司為擴大銷(xiāo)售規模，分別在A(yíng)市和B市建立了分公司，各負責一個(gè)大區的生產(chǎn)和銷(xiāo)售。為便于管理和激勵分公司團隊，公司決定兩個(gè)分公司獨立核算利潤，并根據實(shí)現的利潤進(jìn)行分紅。
為支持兩個(gè)分公司的獨立核算，并防止數據泄露，該飲料公司IT團隊決定分別給兩個(gè)分公司建立一個(gè)“利潤中心組織”。在“利潤中心組織”下面建立了相應的“角色”，并分配了相應的“功能”比如銷(xiāo)售訂單、發(fā)貨功能等等。最后，將相應的“角色”分別分配給了兩個(gè)分公司的員工。
這樣，A公司員工建立的銷(xiāo)售訂單，所產(chǎn)生的收入和利潤數據，均會(huì )統計到A公司。且銷(xiāo)售訂單、收入和利潤等數據，只能由A公司的員工查看。B公司亦如此。
多組織架構實(shí)際上體現了企業(yè)責權利的劃分，決定了組織間協(xié)同與風(fēng)險管控策略。由于企業(yè)越大，組織架構就越復雜，管控要求也越高。因此，越是針對大型企業(yè)的SaaS，越需要重視多組織架構的設計。
當然，如果是針對小企業(yè)的SaaS，多組織架構就相對簡(jiǎn)單了，大家把角色和權限管理設計好即可。
關(guān)于多組織架構設計的詳細內容，我專(zhuān)門(mén)寫(xiě)了一篇文章，大家可以關(guān)注公眾號：ToB老人家，閱讀《B端大PM必備：多組織架構設計》。
案例：
小李梳理發(fā)現，客戶(hù)下設2個(gè)獨立核算的營(yíng)業(yè)部，每個(gè)營(yíng)業(yè)部下面都有若干經(jīng)銷(xiāo)商。對于直營(yíng)的KA門(mén)店，只能由對應營(yíng)業(yè)部管理數據和處理業(yè)務(wù)；對于經(jīng)銷(xiāo)商管理的便利店，只能由對應經(jīng)銷(xiāo)商管理數據和處理業(yè)務(wù)。同時(shí)，經(jīng)銷(xiāo)商所屬的營(yíng)業(yè)部，也具有這些便利店相關(guān)數據的管理權。
小李設計了“利潤中心”組織類(lèi)型，并創(chuàng )建了兩個(gè)利潤中心組織：江東營(yíng)業(yè)部和江南營(yíng)業(yè)部。經(jīng)銷(xiāo)商A、經(jīng)銷(xiāo)商B、KA門(mén)店C都屬于客戶(hù)（具有不同的客戶(hù)類(lèi)型），在客戶(hù)信息上加上“所屬組織”字段，通過(guò)該字段，將這3個(gè)“客戶(hù)資料”都分配江東營(yíng)業(yè)部。這樣，就只有江東營(yíng)業(yè)部的人員可以看到他們的資料以及業(yè)務(wù)數據。
對于便利店a、b、c、d，則通過(guò)類(lèi)似的方式，關(guān)聯(lián)到對應的經(jīng)銷(xiāo)商，確保經(jīng)銷(xiāo)商之間業(yè)務(wù)信息的隔離。
作為SaaS設計的主體，產(chǎn)品功能設計又可以分為應用架構設計和詳細功能設計。
4.1、應用架構設計
所謂應用架構設計，即各系統應用的整體結構圖。
相對于自研產(chǎn)品，SaaS的應用架構設計更為關(guān)鍵。合理的應用架構可以減少功能重復、避免數據混亂和降低系統拓展的難度。而一旦在不合理的應用架構上搭建起功能模塊，并且擁有一定數量的企業(yè)客戶(hù)后，修改的成本就非常高了。
相對來(lái)說(shuō)，自研產(chǎn)品的糾錯成本就低得多。畢竟只有一家企業(yè)在用，只要和業(yè)務(wù)部門(mén)協(xié)商好，推翻重建也不是不可以。
對于產(chǎn)品經(jīng)理來(lái)說(shuō)，應用架構設計的重點(diǎn)要做到低耦合、高復用。
所謂低耦合，是將功能按照業(yè)務(wù)相關(guān)性，分為多個(gè)系統應用。系統應用之間通過(guò)API進(jìn)行交互。這樣，單個(gè)應用的升級，對其他應用的影響就小很多，從而提高了系統的敏捷性。比如，銷(xiāo)售訂單管理、倉庫管理和CRM就可以獨立為多個(gè)應用，并且在必要的時(shí)候分配給不同的團隊負責。
所謂高復用，即將各個(gè)模塊所共用的功能抽離出來(lái)，單獨形成一個(gè)系統應用。這樣，一方面確保了信息來(lái)源的一致性，另一方面簡(jiǎn)化了系統，避免了重復開(kāi)發(fā)。比如，客戶(hù)信息在銷(xiāo)售訂單管理、CRM、TMS（運輸管理）等系統應用中都會(huì )用到，是有必要獨立成一個(gè)應用的。
應用架構設計雖然沒(méi)有標準答案，但實(shí)際上不管是傳統的Oracle ERP系統，還是新興的各大電商、SaaS系統，都有非常成熟的應用架構設計。多研究競品，再結合實(shí)際情況進(jìn)行適當的調整是應用架構設計的好方法。
案例：
考慮到A公司已經(jīng)有獨立的客戶(hù)信息系統，也有成熟的商品管理系統，小李決定直接復用這些系統。為了滿(mǎn)足品牌商的需求，小李增加了一些新的功能，比如商圈管理、價(jià)格策略管理等。
其實(shí)，復用客戶(hù)信息管理和商品管理模塊，小李還有長(cháng)期的考慮，即未來(lái)品牌商版本和經(jīng)銷(xiāo)商版本可能會(huì )打通，形成交易型的SaaS產(chǎn)品。如果兩個(gè)版本共用一套基礎數據功能，會(huì )有利于將來(lái)的數據集成和流程整合。
4.2、詳細設計
SaaS詳細功能設計很考驗產(chǎn)品經(jīng)理的系統經(jīng)驗。
從設計流程上來(lái)說(shuō)，SaaS功能設計也遵循通用B端產(chǎn)品設計流程，如下圖：
但是，SaaS系統面對的是多個(gè)企業(yè)的具體需求，而這些具體需求看起來(lái)總是千差萬(wàn)別的；更困難的在于，產(chǎn)品經(jīng)理并不能確定未來(lái)會(huì )面對什么樣的企業(yè)，也就無(wú)法預知所有的需求。
在這種情況下，產(chǎn)品經(jīng)理可能就會(huì )面臨各種尷尬局面，比如：
功能升級需要大幅修改原有功能，開(kāi)發(fā)抱怨
功能升級改變原有體驗，客戶(hù)抱怨
功能上線(xiàn)后，沒(méi)有人使用，團隊抱怨
功能上線(xiàn)后，客戶(hù)說(shuō)需求變更了，各種人抱怨
所以SaaS詳細功能設計很考驗產(chǎn)品經(jīng)理的規劃和深度思考能力。
具體來(lái)說(shuō)，SaaS產(chǎn)品經(jīng)理需要做好以下幾點(diǎn)：
1）長(cháng)遠規劃，謹慎設計
從0到1的SaaS，往往是從一小群客戶(hù)的需求起步。
當客戶(hù)數量較少，功能也不多的時(shí)候，產(chǎn)品的設計缺乏約束，很容易野蠻的生長(cháng)。
比如，買(mǎi)贈是消費品行業(yè)常用的促銷(xiāo)手段。在某些情況下，贈品需要關(guān)聯(lián)到主品，比如買(mǎi)5瓶大可樂(lè )送1瓶小可樂(lè )。產(chǎn)品經(jīng)理為了設計和操作方便，可能選擇直接在訂單行上新增字段，體現贈品名稱(chēng)和數量。
這樣的設計在面對簡(jiǎn)單需求的時(shí)候，可能不會(huì )出現問(wèn)題。但是一旦遇到比較復雜的情況，比如1）需要管理贈品發(fā)貨；2）買(mǎi)5增2，買(mǎi)5瓶大可樂(lè )送2種贈品；3）需要和ERP系統集成等情況時(shí)，就會(huì )出現問(wèn)題。
正確的做法是，主品和贈品都放在獨立的訂單行，擁有相同的字段，并且通過(guò)“贈品”字段來(lái)標識該訂單行是否贈品（打勾即為贈品）。
因此，作為SaaS產(chǎn)品經(jīng)理，不能夠只盯著(zhù)眼前的需求，而應該放眼長(cháng)遠，盡可能考慮全面。
另外，SaaS產(chǎn)品經(jīng)理必須承認：即便通曉所有需求，我們仍無(wú)法確定全部需求的優(yōu)先級。
因此，一般情況下，產(chǎn)品經(jīng)理只能挑選那些最有價(jià)值的需求優(yōu)先進(jìn)行滿(mǎn)足。而且，每一次的設計都應該是MVP，從而避免暫時(shí)不需要的功能被提前開(kāi)發(fā)。
這就是SaaS謹慎設計的原則。
2） 深度思考，究竟精神
SaaS設計的糾錯成本，遠高于自研產(chǎn)品。
但是，SaaS產(chǎn)品經(jīng)理離客戶(hù)往往比較遠，不容易深入參與客戶(hù)的日常經(jīng)營(yíng)。
相對而言，傳統軟件時(shí)代的項目制，需求設計師可以在一個(gè)客戶(hù)現場(chǎng)駐點(diǎn)數月進(jìn)行需求調研和系統開(kāi)發(fā)；而自研產(chǎn)品的產(chǎn)品經(jīng)理，則幾乎天天和業(yè)務(wù)方在一起溝通。
SaaS公司的研發(fā)團隊龐大，不可能都派駐到客戶(hù)現場(chǎng)，因此產(chǎn)品經(jīng)理往往需要兩頭兼顧，既要把客戶(hù)的需求搞透徹，也要做好設計，讓研發(fā)能夠順利工作。
在這種情況下，SaaS產(chǎn)品經(jīng)理就必須具備“究竟精神”：對客戶(hù)的每一個(gè)需求刨根問(wèn)底，究其本質(zhì)。
我一直堅守一個(gè)原則：永遠相信客戶(hù)有一個(gè)痛點(diǎn)，但是永遠不要相信客戶(hù)有一個(gè)正確答案。也把這個(gè)原則送給大家。
3）便覽競品，死磕細節
SaaS為什么能夠搶占傳統軟件的市場(chǎng)？最重要的原因并不是SaaS更便宜，而是SaaS的出生就帶有移動(dòng)化、社交化的屬性。
但是，移動(dòng)端設計的難度是PC端設計的好幾倍。原因除了手機屏幕更小，同時(shí)也是因為移動(dòng)端操作是在戶(hù)外，場(chǎng)景更復雜，對體驗和效率的要求也更高。
比如，快消品車(chē)銷(xiāo)業(yè)務(wù)員為了完成一天的拜訪(fǎng)任務(wù)，拜訪(fǎng)一個(gè)客戶(hù)的時(shí)間平均不能超過(guò)5分鐘。為了節約時(shí)間，業(yè)務(wù)員需要一邊卸貨一邊拿著(zhù)手機下訂單。因此，“錄入銷(xiāo)售訂單”這個(gè)頁(yè)面必須足夠簡(jiǎn)單和高效。
比如，在輸入商品數量時(shí)，就可以直接錄入多單位數量（不需要選擇單位），如“1箱/3瓶”。并且允許通過(guò)加減號來(lái)增減數量。
這樣，當業(yè)務(wù)員搬下車(chē)1箱3瓶酸奶（假設1箱酸奶有9瓶），他就不需要再計算出“1箱3瓶等于12瓶”才能錄入系統。這就可以大大提高業(yè)務(wù)員的操作效率。
要做好SaaS交互設計，除了和UE同學(xué)充分溝通和探討，更重要的是多研究和學(xué)習競品。
案例：
在進(jìn)行報表設計時(shí)，客戶(hù)有幾張已經(jīng)使用了5年的核心統計報表，客戶(hù)領(lǐng)導希望新的報表仍然沿用以前的統計邏輯。
但是，小李仔細分析后，發(fā)現以前的邏輯并不是最優(yōu)的。
因為客戶(hù)的部門(mén)和人員每年都會(huì )調整，而原報表是根據“訂單-人員-部門(mén)”的對應關(guān)系，來(lái)計算銷(xiāo)售業(yè)績(jì)。這就導致進(jìn)行同期對比時(shí)，歷史年份和最新年份的業(yè)績(jì)基礎并不公平。
比如，去年的A部門(mén)，有10個(gè)人員，管轄a片區；今年的A部門(mén)，有20個(gè)人員，管轄b片區。如果簡(jiǎn)單的把去年A部門(mén)業(yè)績(jì)和今年A部門(mén)業(yè)績(jì)做對比，實(shí)際上是有失公允的。
小李和客戶(hù)的項目負責人進(jìn)行了溝通。由于這個(gè)客戶(hù)是快消品行業(yè)最頂尖的企業(yè)之一，項目負責人也屬于比較自信的領(lǐng)導，因此一開(kāi)始小李的建議并沒(méi)有得到重視。
但是小李堅持與客戶(hù)進(jìn)行溝通，指出“在分銷(xiāo)模式下，只有便利店和對應的區域是相對穩定的。因此應該用A部門(mén)所負責c區域的今年業(yè)績(jì)，和c區域去年業(yè)績(jì)做對比，這樣才是真正公平的”。
最終，客戶(hù)領(lǐng)導被小李說(shuō)服了，他當著(zhù)眾人的面夸獎了小李。而有了客戶(hù)領(lǐng)導的配合，項目的推進(jìn)也非常順利，最終成功上線(xiàn)。小李也借助這個(gè)項目完成了SaaS的從0到1。不久，他又將這個(gè)SaaS產(chǎn)品銷(xiāo)售給了其他的大客戶(hù)，幫助公司成功完成在大客戶(hù)市場(chǎng)的突破。
SaaS產(chǎn)品的設計，很強調產(chǎn)品經(jīng)理的架構能力。
關(guān)于架構能力怎么培養，大家可以關(guān)注公眾號：ToB老人家，閱讀文章《我的實(shí)踐：如何提升B端產(chǎn)品架構能力》。
如果用一句話(huà)對本文做個(gè)總結，那就是：
畫(huà)好棋盤(pán)，放好棋子。
祝大家，設計出一款改變世界的SaaS產(chǎn)品。
聯(lián)系客服
