saas产品如何搭好架构？

我之前的一篇文章中讲到过，一款Saas产品，产品架构搭建的好坏，对结果的影响截然不同。
假设Saas产品架构搭建的不好，那么带来的直接结果就是：
1.客户在完成某一个详细任务的时候，在整个操作的过程中，有一堆不相关的功能出如今客户的操作页面里，导致客户无法高效率的完成工作；
2.没有一个框架性的产品架构指导，后面遇到的新需求，新功能，有可能会被后来的产品经理任意归类，或者新建一个归类来处置新问题，最终产品越做越乱；
3.随着需求越来越多，需要开发的功能就越来越多，功能的耦合度也越来越高，然后开发难度就进一步增大，经常会面临重新搭建架构的局面。
反之，假设架构搭建的好，那么带来的好处至少有以下几种：
1.对客户来讲，看到的页面都是简洁的，能高效的完成任务，给客户带去价值；
2.架构搭建的好，客户用起来好用，就会有更多的客户愿意用，给公司带来了更多的商业价值。
3.不用由于架构搭建不合理而带来的重构烦恼，以后的新需求、新功能根本上都能在架构内找到适宜的位置；
4.公司可以花费更低的本钱来实现不同客户的不同需求。
可见，架构搭建的好坏，对业务的影响是比较大的。那么，如何才干把一款Saas产品的产品架构搭建好？
这里，我们先对架构做一个定义。
百度百科对“架构”的定义，里面有很多技术语言方面的解释，理解起来也比较费事。
于是，我根据自己的理解，做了一个新的定义。
架构的定义是指：
“根据架构搭建者对业务的理解，找出用户需求，把用户需求转换为对应的功能，把功能按不同维度停止分类整合，并梳理出分类整合好的各个模块之间的逻辑关系，最终形成一个产品来处置某一类问题”。
这就是产品架构。
这句定义里有三个关键点：
1.对业务的理解，找出用户需求，把用户需求转换为对应的功能，把功能按不同维度停止分类整合；
2.并梳理出分类整合好的各个模块之间的逻辑关系；
3.最终形成一个产品来处置某一类问题”。
通过对这3个关键点的理解与运用，对如何能搭建好一个Sass产品架构，你会有一个整体的认识。
01
处置某类问题
先从第三个关键点开端聊，对于Saas产品来讲，搭建好的产品是用来处置问题的，而且还是某类问题。
这个“某类问题”就是战略问题。
战略对于产品，或者说对于产品经理来说，最重要的作用就是：
晓得要做什么，不做什么，很明晰或者大约范围的晓得要处置的问题的边境在哪，然后在这个边境范围内去定义产品，设计产品，给客户带来价值，从而也给公司带来商业价值。
02
功能分类整合
战略问题梳理好以后，接下来就到第二步：通过对业务的理解，找出用户需求，把用户需求转换为对应的功能，把功能按不同维度停止分类整合。
如何对Saas业务停止理解？
宏观上，可以从行业定义的理解、行业的市场规模、行业开展所处阶段、外部经营环境的分析（PEST）等维度来理解业务；
中观上，可以从产业链上下游分析，企业竞争格局的分析、资源集中度、进入门槛的分析、标杆企业商业形式分析、Saas竞品分析等维度来理解业务；
微观上，可以从效劳企业经营的业务，相关角色，工作流等角度来理解业务。
关于对业务理解的问题，我这里讲了一个考虑框架。
如何找用户需求？方法有很多，比如：
1.可以通过用户访谈的形式找需求；
2.可以通过用户调查的方式找需求；
3.可以通过深化一线，观察、学习的方式找需求；
4.可以通过会议沟通的方式来找需求；
5.可以通过竞品分析的方式来找需求…
如何把用户需求转换为对应的功能？
如何把功能按不同维度停止分类整合？
这里就是在做分类整合时的核心思想就是，一个大分类里要用来处置一类问题。
比如，一款给餐饮商家用的Saas系统，后台包括的功能模块有：商品、订单、数据、营销、店铺、财务等模块，不论是如今还是将来，遇到商品需求功能，就要把功能归类到商品模块；遇到营销需求功能，就要把需求归类到营销模块；而不是没有规范，乱放。
通过对业务的理解，找到了用户需求，并把用户需求转换为功能，并对功能停止分类整合后，最终就会得到了一个功能构造图。
例如，下图就是某景区Saas产品通过以上方法梳理得到的功能构造图：

PS：为了方便理解，以上一二级模块细节内容有所删减
03
模块之间的逻辑关系
通过上一部分，我们已经找到了要做的功能，并把功能停止了分类整合，形成了一个又一个的模块。
此时还不算完成产品架构的整体考虑，因为一个又一个的产品模块独立着，没有连接在一起的效果就是：并不能发生什么效果。
只要把各个模块有效的连接在一起才干实现目的，处置问题。
这时，需要梳理出分类整合好的各个模块之间的逻辑关系；
如何梳理各个模块之间的逻辑关系？
可以用数据流转过程来梳理。
比如，还是以文章中提到的景区Saas产品为例：
1.景区想要卖票，那首先应该在门票管理模块上传门票，管理门票；
2.上传的门票信息会进入店铺中，供游客查看、购置；
3.游客通过店铺购置完门票以后，就会生成订单信息，进入订单模块；生成财务信息，进入财务模块；生成数据信息，进入数据模块。
最后，通过数据连接，就能把各模块之间的逻辑关系梳理清楚了。
最终形成的产品架构图如下：

为了方便理解，以上的逻辑考虑图，有所删减
这里补充个话题聊一下：
“关于搭建产品架构时，我们是否有类似的处置方案可以参考？”
虽然说，每家公司的每条业务根据行业、时机、自身才干等情况的不同，梳理出来的战略根本上都不一样，搭建出来的产品架构也就不一样。
但是，我们把这些所有的不一样，给笼统考虑，分类整合一下，根本上可以发现所有公司做的Saas产品，根本上都属于两大类（以下分类目的，是梳理出产品要处置的问题大约属于什么类型，然后我们在搭建产品架构时，可以找到类似的处置方案来参考）：
1.业务垂直型；
2.行业垂直型。
随着创业公司业务的开展，这两大类会有合二为一的情况存在，也就是Saas产品里包含了多个垂直行业的多个业务场景的多个处置方案。
第一类，业务垂直型：
业务垂直，可以这样理解，Saas产品要处置的问题是一家公司商业系统中的某个系统，也可以这样讲，要处置的问题是一家公司价值链的某个环节问题。
可能理解起来比较笼统，这里我举两个例子讲讲。
比如：
在制造行业，一家公司的商业系统会是这样的，研究开发——采购——制造——营销——销售——效劳；
在广告行业，一家公司的商业系统会是这样的，购置媒体——开发客户——商品企划书——企划销售——广告制作——施行、评论。
这两个案例就是制造行业和广告行业商业系统情况的一个介绍（或者是制造行业和广告行业价值链相关环节的一个介绍）。
做Saas创业的公司，会把整个大的商业系统中的某一个或多个小系统单独提取出来，给出相应的Saas产品处置方案，这就是业务垂直型。
如今比较通用的业务垂直型Saas产品，处置的业务问题，大约都有：
1.CRM；
2.人力资源；
3.ERP；
4.推广营销；
5.财税；
6.OA；
7.等等。
假设，你处置的是业务垂直型相关的业务，那么每一个业务垂直型相关的问题，你都可以找到相关的书籍、竞品等来看，看看类似的产品是如何搭建架构的，可以学习，参考。
第二类，行业垂直型：
行业垂直型，就是你公司Saas产品要处置的问题是某个垂直行业相关的问题。比如：
1.零售；
2.餐饮；
3.旅游；
4.教育；
5.医疗；
6.物流；
7.等等。
处置行业垂直型问题时，可以通过以下两个框架去考虑：
行业产业链+企业价值链。
首先停止行业产业链的考虑，可以得出的结果是，能清楚的晓得公司要处置产业链里哪个经营主体的业务问题。
晓得要处置哪个经营主体的问题后，接下来要考虑的是，要处置经营主体哪个或者哪几个价值链环节的问题。
比如：你想进入的是旅游这个垂直行业，首先你停止产业链分析，整个旅游产业链，大约可以分为4个环节：
上游供给商（包括景区、酒店等等）——渠道商——媒介和营销平台——用户。
通过各种分析、评估后，你决定要协助经营主体景区处置业务相关的问题。
接着，你进一步考虑，需要协助景区处置什么业务问题呢？
这时就要梳理出景区的价值链包含的有哪些模块，经过梳理，你得出大约包括：
消费、营销、销售、效劳、人力资源管理、财务管理等等。
再通过各种分析，你决定协助景区处置销售、营销和效劳环节的问题，最终设计出Saas产品来处置景区销售、营销和效劳环节的问题。
如何处置销售、营销、效劳问题，你可以通过找到相关的书籍、竞品来参考，看看类似的产品是如何搭建架构的，可以学习，参考。
这里总结一下，就是不论是做业务垂直型的Saas产品，还是行业垂直型的Saas产品，它终究都要回到价值链的某个环节里去考虑，考虑要协助企业处置什么业务问题。
然后针对这样的业务，参考比较成熟的产品是如何搭建架构的，我们可以去参考、借鉴。
​ 最后，关于Saas产品如何最好架构搭建的问题就讲到这里了，希望对你有所协助。
saas开源：https://www.wei-it.com/