上一期中，我具体针对现在B端产品及产业层次的产品设计整理了几个问题：
B端产品怎么设计？用户凭什么会用你的产品？
B端产品的形态：ERP，CRM，后台，中台，及C端业务产品APP？小程序？
B端产品的真正价值是什么？大数据？价值链条？利益关系？人脉关系？
B端产品有什么发展？及怎么发展？市场有多大？
B端产品更大的价值：生态链关系，产业格局。以格局观看B端产品设计。
B端产品引入区块链有啥发展？合适什么行业？引入区块链的几点可行的实际业务设计。
怎么建设生态圈及形成自己的生态壁垒？
并针对第一个问题做了深入的探入分析（详细请看：《B端产品心法（1）：如何设计B端产品，且让用户愿意用？》）
今天开始第二篇，也是第二个问题。
B端产品的形态：ERP、CRM、后台、中台、及C端业务产品APP、小程序？
在B端产品中，我们会经常听到很多个专业词汇，什么SAAS呀，PAAS呀，IAAS呀，ERP呀，CRM呀，或是什么后台，中台之类的。这些词中，相信很多人名词是可以在网上查清楚，但对这些东西怎么使用？在哪阶段使用的定义还并不清楚。
简单的说，什么是行业的产品形式，什么是面向用户的产品形态，可能都还是停留在概念比较模糊的状态，还不能自如的去运用，这才是根本问题。
所以，我们今天就以一切的起点来开始这个问题，B端产品应该如何去明确自己的产品形态。
让大伙更加清晰明了这些东西如何在你手中合适的去使用，让大伙心中有谱！
首先，我们先看一个图，这个图基本上描述了B端的产品与用户间的关系结构。
大量的B端用户与产品的关系是三角形的，付费的人不是使用的人。
而B端与目前大家认识的C端有什么区别呢？其实，在我看来，如果明确了业务关系的话是没区别的。反正都是为了商业，建设一个场，然后为了赚钱，有啥区别？
区别只有简单的产品与用户利益关系：
C端付钱的人也是使用的人。同时，这个C的业务可能还不明确。
B是付费的人可能不是使用的人。这个业务是非常明确的。
那接下来，从这个三角关系（先立个标：为以后同学回顾埋个尸，一但明确了业务关系，其实后边发展与C端其实也没区别）再发展，就是要不断证明你的产品体系是有效的，对业务的推动是有效的。同时，还能更好的节省或创造价值，让B的决策者更愿意继续与你的产品合作下去。
所以，在发展上，就会形成以下的结构：
简单说明一下，就是将使用者在使用的过程中产生的相关业务推进的阶段结果成绩数据化。然后整理出报表，给上层看。当然，上层本身也是用户之一，所以，他用这个东西有没有提高各种方面的效率，本身也是数据采集的一环。
看到这里，相信聪明的人就会产生一个关键的问题。怎么知道用了产品之后会比原来好？B端的BOSS关心的效率质量如何体现？（如果你脑子里真的蹦出这样的问题，那说明你是一个很有潜质的产品经理哦）
这时，我们就要先回归业务，我先画个图：
任何一个业务，其实都可以看成是一段一段的。有业务开始，有业务结束。
如果是一个大业务呢？则可能是很多个人完成一个业务中的不同环节。
复杂的业务可能是这样的：(了解甘特图的应该秒懂）
当然还有更复杂的。但是，我们可以从中看到规律，就是业务在执行过程中，不同大小的业务都可以切不同环节。每个环节都是一段，有开始有结束。
有的环节间可能很完美的可以衔接，有的可能需要些滞空期，有些可能会在某个时间多道推进。
所以，我们可以从业务的过程中提取以下几个关键点：
起点，结束点（包括小段的起点，小段的结束点），中间的过程，及过程中执行的情况，时间，效率。
而每个项目其实都有计划时间，预估的或是经验的。及实际数据跟踪后，实际提取的。
那自然，将这两者一对比。就能取得当前业务设计与推进中的情况。
超出预计了，则可以帮助找到为什么为超出计划，是哪个环节用时或是用料用成本过多？哪些环节是不是可以改进？还是实际上已经没有改进空间？这些问题自然就能很清晰的呈现出来，并指引下一步的计划如何安排。
而达成了计划呢？同样可以看到，哪个环节是在实际的节省，哪些环节可控性强，可以标准化，是不是预估的可以更加明确实际的情况？是否可以对下一次预估指出更明确的指引？同时，是不是可以让整体一个更大的项目或业务的整体时间缩小？成本降低？或是其它什么地方改进能节省出更多资源？这些问题自然而然的也能明确起来。
而这，就是在B端产品中其中一个比较有价值的体现产品价值的地方：让管理者更清楚的看清楚实际的情况；让其心里越来越有谱。
说到这，有了明确的价值，那要回归本身问题。如何确定B端会采用什么样的产品形态才是最合适的呢？这也得在你理解了上边价值体现的基础上，才能到这一步的。
什么样的方式，更能帖近或帖着使用者，将这些环节的真实情况的数据，采出来。
这时，我们就要开始进入下一步的分析：
通过上图，我们可以整理出以下两步：
第一步：使用者分析
通过执行人员（一线使用人员）实际在工作中的场景及工作情况，来决定前端，采用什么样的形态。一个端还是几个端？
C端产品只是少几个角色？但性质及环节一个都不会少，B端产品与C端产品只要明确了业务，除了业务的严谨性的标准要求，其实没有什么本质区别。
当然现在越来越多C端的产品标准，要求也在向B端靠齐。
第二步：以上的数据采集，保真性，现阶段什么样的技术最合适？
那自然而然的就可以明确，应该做成APP？还是小程序？或是一个网站？或是一个本地执行程序？还是一个什么？这个软件要求跨平台么？还是需要兼容跨平台？是本地布私有环境还是可以有远程外网环境等，自然可以通过这个推导得出。
如果付钱的BOSS直接要求了，就不需要思考了么？同样，还是要负责任的思考一下，如果意见不合理的，可以给出相应的更合适的建议。比方：现在很多已经不做APP了，APP还有发行等很多不完全可控问题。小程序是否可以替代？
总之，在不影响B端业务的情况下，选择你可以搞定并可以有效推进下去的产品形态方案是你的必须要深入体会的一个环节，这样做产品才能更全面，才能为你下一步的具体设计给出一定的规则边界。
所以，面向使用的用户，我们会定义出：
一线的使用者工具的形式=小程序，还是APP，还是一个WEB的工具，方便其在业务场景中的应用。
后端的管理者工具形式=小程序，或APP，或一个WEB的工具，或是一个固定本地私秘的执行程序供其使用。
而使用者不同的工作性质，或是用户有必要形成有价值的用户体系或，则会产生相应的CRM，用于用户业务数据积累，同时本身CRM也可以成为用户推进业务的工具之一。
（以上两者是不是有很多的共同点？如果你注意到这点，很好，请记住，之后用得着）
而对于管理者，自己企业或各种业务中资源的监督与管理，调配，自然就形成了所畏的ERP。
综合以上产品的类型形态及终端的形式，这即是SAAS的意义，软件即服务。软件就是为了服务而产生的。设计好了，针对使用场景及情况布署好就用吧。（就这么简单粗暴！）
逻辑上说，SAAS、PAAS、IAAS，以前我就有过解释，网上也有一大堆的名词说明，所以这里就不再浪费时间。但运用这些东西还是需要个直白的理念，心里要有点基础的认知。
而一线业绩的产生的数据，首先先是要有个地方存，是机器吧，你还得时刻监督管理这些机器，那这个自然是IAAS的事。
而如果这个业务可以更好的扩展给更多的B端商家使用。那自然会产生相应的PAAS层，产生相应的技术接口或是合作开发的开放功能。也就是说，你可以开放这个体系给更多用户用啦或是合作用户用啦。
而对于B端的管理者或公司，他们要有自己的后台。同样，做为服务的提供者，产品开发方，可能方便业务的推进，一样也会有自己的后台。后台就是一般前端用户不需要看见的业务功能部分。时刻控制着前端业务的推进，或是给相关的人权限或是开放什么功能这样子。有时后端也可以是一个ERP或是就是一个ERP，因为人力及权限及功能其实本身就是“资源计划的一部分”。
当一个后台，对接前端的用户多了，为了节省一些反复或重复的前后端高占资源的一些信息交流情况，这时就会产生一个中间部分的概念，他可以直接处理一部分的后台业务，也可以很好的支撑前端的业务。同时能为后台减少相应巨大的负担。
所以，中台这东西，并不是什么特别神的东西，特别是那个马云搞乱市场的“中台“言论，真是把一个本来就有的东西搞得市场鬼哭神惊。
当一个业务对接非常多的客户端时，不同的错时交互中为了达成更的资源信息交换，本身就会需要一个中间部分集中的处理协调好各种部分的对接，这本身就是自然而然的事。搞得这么大惊小怪。
所以，以我对多家公司及很大行业内人员的了解看来。包括所谓大厂阿里系出来的，其实都对这个问题没有充分的想过，思考过，更多的只是因为自己是大厂的，好像见到的就是唯一的。所以，感觉好像是拿着所谓标准答案就不再去思考这个问题了。同样TX系的也有差不多同样的情况，那些招B端产品或是招总监的，也是如此的无知者占多数。
说到这里，你是否具体的知道SAAS，PAAS，IAAS，与ERP，CRM，后台，中台，小程序，APP，网页工具如何在产品人手里自由的运用了呢？
不过我相信，以上什么是服务形式，什么是产品形态，什么是业务模式，什么方式合适用在哪，也应该有谱了吧？不会再被一些满嘴跑火车的所谓专业业内人士忽悠了就成了。
下一篇的问题：B端产品的真正价值是什么？大数据？价值链条？利益关系？人脉关系？
其间会相关另外一个核心问题进行解读：产品形态与战略啥关系？
而再下一个问题呢，则会跟垂直领域知识图谱有最直接 的价值关系，一步步来吧。