市面上琳琅满目的各类【数据处理与分析产品】背后的共通之处及差异剖析

个人从事2B/G产品工作3年半,期间个人直接或间接负责建设的系统包括:【智慧城管系统】、【政务热线分析系统】、【人体/车辆异常行为告警系统】、【舆情分析系统】、【开源情报分析及侦察系统】、【公共安全防控与预警系统】、【自训练平台】、【OA系统】等。

  • 产品形态上,这里面以中屏居多,也有小屏和大屏;
  • 产品服务模式上,有端到端的SaaS系统、客户端系统(需下载部署安装)、还有直接提供API服务的;
  • 产品使用的AI技术上,有NLP的,有CV的,有ASR+NLP的,有知识图谱的,还有跨模态的;
  • 产品使用的数据上,有仅开源的,有仅闭源的,也有开源+闭源相结合的。

今天就来聊一聊,这些系统以及诸如“爱企查”、“企查查”、“千里马招投标”,还有面向KOL&MCN提供运营/营销服务工具的如“飞瓜数据”、“蝉妈妈”系统,有什么共通之处?又有什么差异?

一、爱企查/舆情/情报分析/风险预警等系统所解决的业务问题

二、上述各系统的共通之处及差异分析

1. 共通之处分析

做了这么多产品/系统,我发现,这些系统(城管系统、政务热线分析系统、公共安全防控与预警系统、舆情系统、情报分析系统…,包括爱企查、企查查、还有飞瓜数据、蝉妈妈、七麦数据等),它们本质上就是一类东西:【(大)数据处理与分析系统】。

即,都是对采集或获取到的各种数据(有仅开源的,有仅闭源的,有开源+闭环的),利用各类AI算法(有只用CV的,有只用NLP的,有多种技术结合的)进行治理和分析,最终给到业务侧去应用,而且业务应用功能多为:预警、分析。作为为业务发现风险的一个“上报源“。

——这是从数据流转层面来看的,上述各个系统的【共通之处】(即产品架构基本类似)。抽象来看,上述各个系统的业务流程都如下,且与OA系统的关系如下:

OA系统,可以负责上述【数据处理与分析系统】提供的风险数据的后续业务操作与处置,使得业务能够流转(如生成告警工单,案件处置表单等,进行多部门的协同)。

——从对外提供的产品服务模式来看,厂商一般也会优先提供基于互联网的PaaS服务或SaaS形式。

这是因为服务升级、运维均在厂商自己侧,维护和管理成本低。而私有化部署交付这种服务形式,对厂商侧的运维成本很高。

2.差异点分析

(1)从产品面向的客户类型来看,这些系统(城管系统、政务热线分析系统、公共安全防控与预警系统、舆情系统、情报分析系统…,包括爱企查、企查查、还有飞瓜数据、蝉妈妈、七麦数据等),其是有差异的。

A.客户类型不同,导致的交付模式差异

  • 2G产品,客户一般都会要求私有化(不论是端到端的系统,还是AI能力);
  • 2B产品,如OA系统,在产品形态上,厂商会优先给客户推荐SaaS方式,但同时为兼顾一些大企业客户,也会支持私有化部署服务形式。

B.客户业务场景不同,导致的业务功能差异

由于这些系统(本文开头提到的系统)面向的行业、客户有所不同,这就导致具体的业务场景不同,业务场景不同,就会衍生出差异化的产品功能,也会根据业务需求,确定选择用哪些技术实现。

(2)若产品是专门提供数据服务的,从数据的开、闭源角度来看,这些系统(城管系统、政务热线分析系统、公共安全防控与预警系统、舆情系统、情报分析系统…,包括爱企查、企查查、还有飞瓜数据、蝉妈妈、七麦数据等)的对外服务模式也是有差异的。

  • 若数据是开源的。厂商一般会选取SaaS形式交付(如舆情系统、为MCN/KOL提供营销工具箱的产品:蝉妈妈、爱企查等、为C端用户提供数据分析服务的产品:七麦数据等),数据治理分析的成果供客户/业务侧付费查询、使用。
  • 若数据是客户提供的,即闭源的。客户一般需要私有化部署安装(Based LAW)。如本文中的【城管系统】、【安防监控分析系统】、大企业使用的【OA系统】等。
  • 若数据既有开源,又有闭源的。那么产品服务模式,就会变成:半SaaS(PaaS)+半私有化。客户允许厂商数据进入客户内网,但客户绝对不会允许客户数据(关于人、车、公司强相关的业务数据,这些隐私、机密数据)出来到互联网环境。

三、关于“架构”的一些思考

为什么会写到这个内容,之前在面试过程中,几次被问到了产品架构相关的问题,遂有了下述思考,小伙伴们可有自己的见解哈~

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年的产品经理平时在进行产品工作时,要多去了解公司的组织结构以及业务情况,以及市场上的其它优秀产品,才能据此设计出适合于部门或团队的产品架构。架构能力的提升,我认为本质在于模块化、抽象化思维的不断锻炼。

四、全文总结

本文主要基于个人此前的产品和项目及面试经历,首先梳理了每个产品所解决的业务问题,然后介绍了这些产品在架构层面、在对外服务形态等层面的共通之处和差异点。最后介绍了关于“架构思考”的内容。文章中,如有不正确之处,欢迎小伙伴们指出,我们一同探讨,共同成长~

本文作者 @南方碟道

版权声明

本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符,请点击 举报 进行投诉反馈!

相关文章

立即
投稿

微信公众账号

微信扫一扫加关注

返回
顶部