各類【數據處理與分析預警產品】背后的共通之處及差異剖析

0 評論 3771 瀏覽 21 收藏 16 分鐘

下面這篇文章是筆者整理分享的關于自身的產品和項目及面試經歷,其中內容包含了愛企查/輿情/情報分析/風險預警等系統所解決的業務問題、各系統的共通之處及差異分析以及關于“架構”的一些思考的相關內容,對此感興趣的同學接著往下看看了解更多叭!

個人從事2B/G產品工作3年半,期間個人直接或間接負責建設的系統包括:【智慧城管系統】、【政務熱線分析系統】、【人體/車輛異常行為告警系統】、【輿情分析系統】、【開源情報分析及偵察系統】、【公共安全防控與預警系統】、【自訓練平臺】、【OA系統】等。

  • 產品形態上,這里面以中屏居多,也有小屏和大屏;
  • 產品服務模式上,有端到端的SaaS系統、客戶端系統(需下載部署安裝)、還有直接提供API服務的;
  • 產品使用的AI技術上,有NLP的,有CV的,有ASR+NLP的,有知識圖譜的,還有跨模態的;
  • 產品使用的數據上,有僅開源的,有僅閉源的,也有開源+閉源相結合的。

今天就來聊一聊,這些系統以及諸如“愛企查”、“企查查”、“千里馬招投標”,還有面向KOLMCN提供運營/營銷服務工具的如“飛瓜數據”、“蟬媽媽”系統,有什么共通之處?又有什么差異?

一、愛企查/輿情/情報分析/風險預警等系統所解決的業務問題

二、上述各系統的共通之處及差異分析

1. 共通之處分析

做了這么多產品/系統,我發現,這些系統(城管系統、政務熱線分析系統、公共安全防控與預警系統、輿情系統、情報分析系統…,包括愛企查、企查查、還有飛瓜數據、蟬媽媽、七麥數據等),它們本質上就是一類東西:【(大)數據處理與分析系統】。

即,都是對采集或獲取到的各種數據(有僅開源的,有僅閉源的,有開源+閉環的),利用各類AI算法(有只用CV的,有只用NLP的,有多種技術結合的)進行治理和分析,最終給到業務側去應用,而且業務應用功能多為:預警、分析。作為為業務發現風險的一個“上報源”。

——這是從數據流轉層面來看的,上述各個系統的【共通之處】(即產品架構基本類似)。抽象來看,上述各個系統的業務流程都如下,且與OA系統的關系如下:

OA系統,可以負責上述【數據處理與分析系統】提供的風險數據的后續業務操作與處置,使得業務能夠流轉(如生成告警工單,案件處置表單等,進行多部門的協同)。

——從對外提供的產品服務模式來看,廠商一般也會優先提供基于互聯網的PaaS服務或SaaS形式。

這是因為服務升級、運維均在廠商自己側,維護和管理成本低。而私有化部署交付這種服務形式,對廠商側的運維成本很高。

2. 差異點分析

(1)從產品面向的客戶類型來看,這些系統(城管系統、政務熱線分析系統、公共安全防控與預警系統、輿情系統、情報分析系統…,包括愛企查、企查查、還有飛瓜數據、蟬媽媽、七麥數據等),其是有差異的。

A. 客戶類型不同,導致的交付模式差異

  • 2G產品,客戶一般都會要求私有化(不論是端到端的系統,還是AI能力);
  • 2B產品,如OA系統,在產品形態上,廠商會優先給客戶推薦SaaS方式,但同時為兼顧一些大企業客戶,也會支持私有化部署服務形式。
  • 2C產品,如七麥數據、今日熱榜等,一般會提供SaaS服務(H5),比較少有支持PC客戶端或App客戶端下載的。

B. 客戶業務場景不同,導致的業務功能差異

由于這些系統(本文開頭提到的系統)面向的行業、客戶有所不同,這就導致具體的業務場景不同,業務場景不同,就會衍生出差異化的產品功能,也會根據業務需求,確定選擇用哪些技術實現。

(2)若產品是專門提供數據服務的,從數據的開、閉源角度來看,這些系統(城管系統、政務熱線分析系統、公共安全防控與預警系統、輿情系統、情報分析系統…,包括愛企查、企查查、還有飛瓜數據、蟬媽媽、七麥數據等)的對外服務模式也是有差異的。

  • 若數據是開源的。廠商一般會選取SaaS形式交付(如輿情系統、為MCN/KOL提供營銷工具箱的產品:蟬媽媽、愛企查等、為C端用戶提供數據分析服務的產品:七麥數據等),數據治理分析的成果供客戶/業務側付費查詢、使用。
  • 若數據是客戶提供的,即閉源的??蛻粢话阈枰接谢渴鸢惭b(Based LAW)。如本文中的【城管系統】、【安防監控分析系統】、大企業使用的【OA系統】等。
  • 若數據既有開源,又有閉源的。那么產品服務模式,就會變成:半SaaS(PaaS)+半私有化??蛻粼试S廠商數據進入客戶內網,但客戶絕對不會允許客戶數據(關于人、車、公司強相關的業務數據,這些隱私、機密數據)出來到互聯網環境。

三、關于“架構”的一些思考

為什么會寫到這個內容,之前在面試過程中,幾次被問到了產品架構相關的問題,遂有了下述思考,小伙伴們可有自己的見解哈~

1. 什么是架構?

我們經常會在什么短語中聽到這個詞?組織架構,對吧?每行每業都會有架構師。建筑行業的架構師:建筑設計師,再細分開來:有土木結構設計師、鋼結構設計師、住宅建筑設計師、室內家裝設計…

我們互聯網這行,提到架構,經常會聽到:解決方案架構、業務架構、技術架構、產品架構、功能架構、信息架構…對吧?

那到底什么是架構呢?先放幾張圖感受一下:

圖來自網絡(如有侵權,聯系刪除)

圖來自于百度云官網-智能客服產品架構(僅作交流學習使用,如有侵權,聯系刪除)

圖來自于網絡-標簽體系架構(僅作交流學習使用,如有侵權,聯系刪除)

圖來某項目-個人設計的產品架構

圖來自于阿里云官網-某數據需求場景解決方案架構圖(僅作交流學習使用,如有侵權,聯系刪除)

我理解架構的本質,就是一個東西的內核,是其核心框架/骨架,并按一定的邏輯順序,將支撐這個系統的核心骨架串起來,并給出各個模塊間的交互關系,在每個骨架層同時加以“血肉”使其稍微“具象化”。至于最終的呈現形式可以是上面那些常見的規規整整的架構圖,也可以是流程圖,也可以是腦圖、表格…等多種展現形式。

那業務架構、產品架構、技術架構、信息架構之間的關系是怎樣的?

  • 業務架構,一般來自于業務需求調研、業務流程梳理后,進行設計的,一般由企業的組織架構決定;
  • 產品架構,一般來自于業務架構。
  • 技術架構,來自于產品架構。
  • 信息架構(在軟件領域),來自于產品架構,等于最終呈現給用戶的信息結構,如導航欄、菜單欄等。

2. 如何設計產品架構?

根據我相關產品/項目工作實踐經驗,我總結了幾個有效的設計產品架構的方法:

(1)從數據流向來設計。即從數據怎么來的->怎么加工處理的->到怎么給到業務去應用的這樣的順序去設計。

(2)參照OSI框架來設計。

(3)按Iaas、PaaS、SaaS,從底到頂逐層來設計。

其實,上面這幾種方法的本質是一樣的,我認為都是根據數據流向來設計的。那什么是好的產品架構設計?

——類比于房子等建筑的架構,其好與壞,可以用一些實際應用情況來評估,比如抗風程度、抗地震程度…軟件產品架構(軟硬件結合產品的架構),一般要求:其穩定性、健壯性、魯棒性均較強。

——但軟件產品與房子建筑架構(結構)又不太相似的地方在于:軟件產品一般更新迭代速度較快,而實體房子不會推倒重建(除非地震坍塌、建筑主體損壞,需要翻修等等),這就要求軟件產品架構還需具備很重要的復用性和可擴展性。

3. 產品經理的架構能力要求

產品經理,一般從產品助理做起,從一開始接觸簡單的功能需求(如設計一個簡單的功能模塊:這里面可能會包含業務流程的調研/梳理/設計、功能輸入輸出的制定、原型界面設計等內容)、到負責一個產品核心模塊的建設、到負責一整個產品線的建設,并為產品商業化負責。

在整個產品經理打怪升級過程中,不論是功能型的產品經理,還是策略型的產品經理,還是軟硬(硬件產品經理)結合的產品經理,其架構能力要求,肯定是逐漸升高的。

  • 工作1-3年的產品經理,其JD中,基本上不會有架構設計能力要求
  • 工作3-5年的產品經理,其JD中,大部分開始要求具備產品規劃、架構設計能力;
  • 工作5-10年的產品經理(本質上,應該是高級產品經理或產品架構師了),其產品架構設計能力要求不言而喻,肯定是極高的。

圖來自Boss直聘(如有侵權,聯系刪除~)

圖來自我的某個offer

圖來自Boss直聘(如有侵權,聯系刪除~)

所以,我們1-3年或3-5年的產品經理平時在進行產品工作時,要多去了解公司的組織結構以及業務情況,以及市場上的其它優秀產品,才能據此設計出適合于部門或團隊的產品架構。架構能力的提升,我認為本質在于模塊化、抽象化思維的不斷鍛煉。

四、全文總結

本文主要基于個人此前的產品和項目及面試經歷,首先梳理了每個產品所解決的業務問題,然后介紹了這些產品在架構層面、在對外服務形態等層面的共通之處和差異點。最后介紹了關于“架構思考”的內容。文章中,如有不正確之處,歡迎小伙伴們指出,我們一同探討,共同成長~

本文由 @南方碟道 原創發布于人人都是產品經理。未經許可,禁止轉載

題圖來自Unsplash,基于CC0協議

該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 目前還沒評論,等你發揮!