我們常常聽到的“ios架構工程師“、”高級產品架構師“，但是不是很少聽到有關於業務架構的搭建？
目錄
一、產品不等於業務，搭建一個新的業務架構不等於創造一款新的產品
二、一項新業務的誕生，一定是伴隨着相應商業模式的成立纔會長久
三、從流程和人員的角度規範化，無論是新市場、新業務還是新的領域
在很多中小型互聯網公司，確定開拓一項新業務之後，都是在不斷試錯的過程中搭建業務架構，而這其中涵蓋了對於業務模式的確立、商業模式的探索、組織架構的調整、工作流程的規範、團隊規模的預留等等；
一、產品不等於業務，搭建一個新的業務架構不等於創造一款新的產品
在講這一段之前，我們先重現一段場景，某知名教育互聯網公司運營與產品總監的對話如下：
運營：“我們在進行用戶調研的時候發現，很多用戶在進行課程試聽的過程中未出席，是不是因爲我們的銷售模式有一定的使用障礙？用戶路徑過長？我們可不可以考慮優2·化這個路徑，實現系統約課？“
產品總監：“你的這個想法我們已經在實現階段了，現在確實話費大量人力在這一塊兒，我們要實現產品代替人工，提高人效！“
運營：“全部替代嗎？目前系統可以支撐起來咱們的用戶需求嗎？需不需要過度？”
產品總監：“這個我們也會考慮，到時候同步你們。“
以上這段對話，看起來是不是十分和諧，似乎一個全新的方案即將誕生，一場完美的配合即將上演，然而，我們揭開表面看本質，在這個需求中，運營同學提到的：“系統約課”，是否可以依靠一款系統或者產品就完全解決呢？我們來針對這個例子進行一下場景拆解，解決這一痛點，我們需要考慮的問題是什麼：
- 表現層：用戶路徑縮短，降低用戶決策成本，提高銷售人效；
- 產品層：產品提供前端到後臺的系統支持；
- 業務層：業務模式從電銷轉爲sop，客單價、銷售方式、運營模式是否會受到影響？現有的就按課程產品是否適用於sop流程，是否應創新課程形態進行相應匹配？
- 人力層：去掉人力電話約課之後，效果是否可以完全替代電銷？人力無法回滾。
這些還不是全部的問題，還涉及到新用戶的獲客渠道和老用戶的維護等等一系列問題，我們就會發現，這不是一款新的產品或者一項新的功能就能解決的，而是涉及到從前到後一系列的改動，而這樣的改動是否真的值得，是應該去試錯，還是應該去創新？
以上的例子，我只想表達我的一個觀點：產品不等於業務，但業務可以衍生出產品。
二、一項新業務的誕生，一定是伴隨着相應商業模式的成立纔會長久
穩定的商業變現模式是很多互聯網產品追求的共同目標，可很多業務在開創前，過度的考慮用戶量級、市場份額的佔據，對後期商業模式的發展只是有大範圍的規劃，而沒有細緻的思考，所以出現很多產品“生於獲客，死於變現”，大量的融資做產品，但最後由於無法變現無法轉化而走向滅亡的公司多不勝數。
就舉例說會員制的音樂類、社交類、新聞類、健身類這些非剛需且競品衆多的APP，到一定用戶量級之後如何促使用戶轉化及穩定變現就是一個很困難的問題，畢竟保證盈利纔是一家公司的長久生存之道。
FOR EG：健身領域獨角獸keep，典型的非剛需類產品，但線上健身對於目前的市場來說其實是一個很好的機會，目標用戶的消費力也偏高，keep在集中做會員制服務這一點上卻沒有做好服務，而選擇了在融資後大量的發展硬件、商城及線下門店等難以快速盈利的項目，在mvp的商業模式沒有徹底跑通的情況下投入大量的資金髮展其它業務，是一件很危險的事情。總結大概是三點：
- 最開始沒有想好這這一業務最後的目標是什麼，是線上壟斷，還是OTO，還是整個行業的標新；
- 在融資後急於擴張規模及業務，跑得太快，忘記審視走的路是否是可以有一天可以變現的路，還是一條只砸錢不回錢的路；
- 沒有將一件事情做到極致，就開始做第二件、第三件事，這是第二點的補充。
筆者還是很看好keep未來的發展，畢竟在這個有信仰的時代，“自律給你自由”這樣的slogan確實可以深入人心，就看下一步怎麼走了，是否能回到正軌，anyway，服務好用戶是第一位，服務號會員準沒錯。
三、從流程和人員的角度規範化，無論是新市場、新業務還是新的領域
不是所有的大公司都是規範的，也不是所有的小公司都是混亂的。有的小公司雖然人員規模小，但是人員配置合理，流程規範，這是對於之後的每一個環節都尤爲重要的。近些年出現了一個深入業務條線的職位HRBP，根據一個具體的部門或者是業務線進行更爲準確的人員管理和招聘，這是很合理的。
我們總聽得到一句話，現在業務規模還小，不規範很正常，以後慢慢就好了。而混亂的流程只會導致加快業務的斃命。
還是舉例說明，筆者是產品經理出身，但在中小廠是沒有項目經理的，甚至一些更小的公司，甚至沒有產品經理，老闆就是產品經理，這個沒有問題，我們不需要嚴格要求誰做什麼事，但是我們需要最開始規劃一條路線，而這條路線中，你的位置在哪裏，就應該做好這個位置的事情。
- 管理與執行的區分；
- 每個崗位之間配合情況；
- 確保每一條業務線都有自己的own product；
- 崗位可以空缺或合併，但職責不能模糊。（例如：可以沒有項目經理，但是要明確誰進行項目管理，誰對整體項目進度負責）
四、B端同步搭建，把數據底層做在最開始
先說數據，數據是可以賦能業務的，無論是一款產品的埋點，還是到產品上線後的數據統計及分析，這一切動都是爲了推進業務發展，提高業務能力，提高業務效率。
不要把賦能放在最後一步，畢竟一件錦上添花的事情如果做的太晚，就連雪中送炭都來不及了。
我們要數據的目的是什麼？簡單粗暴的說：
- 知道仗打的怎麼樣了；
- 知道哪隻戰隊更強；
- 知道哪隻戰隊或者哪個兵拖了後腿；
- 知道是不是戰隊沒問題而是糧草去晚了？
大概對應的也就是我們那些熟知的數據了，行爲數據、用戶數據、產品數據、市場數據等等。
做數據是廢人力的，是費腦子的，做分析也是，但是也許你不信，還有太多的公司在業務模式都已經成型了，纔開始補上數據這個問題，在這過程中消耗掉的沉默成本可想而知。
咱們再說B端的同步搭建，這裏說的B端針對不同的行業有不同的定義，我們通常會認爲給企業內部員工使用的產品或者說管理內部使用的產品等是B端，但其實還包括大客戶等也包含在內，一項業務的起步如果不考慮它將來會最強做大，那你可以不用考慮到這一點，但是如果想要做精做細，無論是產品還是運營，都不能放掉這一塊兒。
五、保持前瞻性，走一步看三步，走不動的時候即使止損。
以一個產品經理的角度來說明，優秀的產品經理做一個功能是爲了之後做無數功能埋伏筆，無論從用戶層面還是後端技術層面，都可以做到前瞻性。
舉例來說，你接手一個新的項目，你要考慮它的載體是app還是小程序還是社羣，這個決定不是一蹴而就，你當下的決定只適用於當下，有的目前適用與社羣的項目業務之後隨着規模的擴張會承載不了大體量，需要做統一收口，那你怎麼去規劃之後的收口路線，怎麼去規劃用戶的生命週期管理，怎麼去規劃你的用戶在哪個環節哪個場景進入、什麼場景活躍，最後統一留存在哪一個生態，是否是一個長線項目，還是一個短期實驗項目，你的roi是否可以承載等等。
總結
能有從0到1開始的機會是難得的，但也是艱難的，證明自己併爲後人鋪路，沒有那麼容易，這篇文章只是以互聯網思維寫的冰山一角。
本文說的“業務”可大可小，可以大到一個全新領域，也可以小到改動一個當前的支付模式從而誕生一個新的支付業務等，但無論是大業務還是小業務，每一個環節做到細緻，留下迭代的空間，就不會太差。