在市场经济环境下，所有商业组织（主要是企业）的使命都是在于为市场提供价值，以换得相应的利润回报。每个企业都是一个价值转化系统，通过原材料、资本、人力资源、企业家精神、管理等要素输入并经过企业内部的业务流程从而输出市场所需的产品或服务。因而每个企业至少包括三个环节：入口、内部流程、出口。每一个企业的出口对应着下游企业的入口，这种上下游协同关系就构成了产业链。
在《九轩资本刘亿舟：互联网+的本质是新通路》一文中，把这三个环节分别定义为：上通路、中通路、下通路。可以说，今天所有的互联网或技术性企业都在围绕这个三个环节提供相应的服务。
近年来受资本热捧的B2B企业其实是在帮助企业解决上通路（采购供应链）的问题，而SaaS和云计算等企业服务则是为企业解决中通路（内部流程管理）的问题，而一众B2C、O2O等互联网企业则是帮助企业解决下通路（销售）的问题。对于服务于上通路的互联网企业来说，提升供应链效率是其核心。对于服务于中通路的互联网企业来说，本质是要帮助其所服务的提升组织内部的运营效率，对于服务于下通路的互联网企业来说，降低获客成本和交付成本是其核心。所有的商业变革和技术创新，都在致力于从整个社会商业流通大格局的角度提高这三段通路的效率和降低其成本。
产业演进的终极状态通常是，整个社会的资源和要素在同一个“片层”内整合（形成几家大型企业，不同产业能够实现的整合程度不同，有些甚至很难整合）以实现最大程度的规模经济效应，为产业下游提供最富效率的“公有云”服务，而整个产业就如同一串被串起来的薯片，其中只有少部分规模巨大的企业可以实现纵向一体化，而他们一般通过并购来实现，这也是留给创业者的机会，找一个“薯片”机会，迅速做大，然后被巨头并购（感兴趣的可以参阅《刘亿舟：用“薯片理论”理解产业演进》一文）。
引导这种产业演进的本质规律其实是市场背后那只无形的手——交易成本最小化。显然，当市场存在“公有云”服务的选择并且成本更低时，把企业内部的服务职能甩给市场的专业机构来做可能更有效率，反之则反。
传统的企业之间以及企业和消费者之间的交易都是基于传统的“人肉”信息传递模式，可以形象地称之为“卖灌装煤气”，而产业互联网则致力于打通产业链上下游之间的信息通路，将“卖灌装煤气”模式变为“卖管道煤气”。
如果说消费互联网建立了“球”（商业组织，企业）和“点”（消费者个人）之间的连接，那么产业互联网则试图要建立球和球之间的数字化连接，而要建立“球”和“球”之间的数字化连接，必须要打通“球”内部的数字化连接（内部流程的信息化）。其最终愿景是要建立“生产-流通-消费”整个通路的信息化和数字化。
当单个企业在市场上的采购和销售行为被数字化后，企业和企业之间、企业和消费者之间就从原来的“软连接”和“冷连接”变成了“硬连接”和“热连接”，企业自身也就实现了数字化生存。当这一愿景实现后，现有的金融风控体系、企业征信体系、采购决策体系、供销模式都会发生巨大的变化。因为，企业作为一个市场的主体的大部分行为也纳入大数据的范畴，就像今天我们每个个体已经初步实现数字化生存（各种消费行为数据被数字化），在互联网上被一系列ID所表征那样。
当然这是一个宏大的愿景，需要一个漫长的演变过程。没有哪一家公司有能力从顶层设计的角度规划所有市场参与主体之间的信息化连接，而从单个企业和单个行业出发的SaaS解决方案又往往从最终来看无法满足社会顶层设计的需要（事实上没有谁会从这个逻辑角度设计产品），这就注定了社会总体层面的系统集成就像单个企业内部的系统集成那样，过分超前的设计往往都是失败的，而满足局部和眼前需求的设计又往往容易被推动重来。所以，从某个角度来说，浪费是不可避免的，这是市场发育和教育的成本，也是市场动态博弈的成本。
从某种意义上来说，消费互联网时代的每一个网站都是SaaS，只不过面向消费者那一端只是一个“瘦客户端”，而面向商家那一端最初是一个相对的“胖客户端”，在平台模式下，可能还无法把背后商家的业务流程给“托”起来，当然，其进一步发展目标是希望能够全盘“托”起来，从而给商家实现信息化赋能。
在产业互联网时代，SaaS的使命就是要站在全产业链的角度帮助“上通路”、“中通路”、“下通路”实现信息化和数字化。今天，任何缺乏产业互联网思维而从孤立、短浅的角度开发的SaaS产品可能都无法迎合“大连接”时代的数据贯通要求，当然过分的超前也是不可行的，前面说了，就信息化建设而言，浪费是必须的。
今天，SaaS在企业的上通路、中通路、下通路三个环节都出现了很多创业项目，其各自有其价值逻辑和发展逻辑。在《九轩资本刘亿舟：SaaS路上，你不得不直面的那些坑》（万字文）一文中，刘亿舟将所有的SaaS分成“大SaaS（管理工具型SaaS）”、“小SaaS（业务管控型SaaS）”和“供应链SaaS（交易平台型SaaS）”，并分别分析各种类型SaaS的价值模式以及可能碰到的坑。
虽然，从终极格局的角度来看，SaaS是贯通整个产业链数据链条的基础设施，但无论哪种SaaS，要能够切入企业的具体业务并为企业所接受，必须在具体而微观的场景中为企业提供实实在在的价值。产业互联网和消费互联网完全不同，如果说消费互联网属于“轻连接”，前期可以靠烧钱补贴可以把用户累积起来，待用户基础大了以后再逐步迭代产品和服务从而“脱虚入实”的话，产业互联网则属于“重连接”，企业用户的决策心智完全不同于个人消费者，企业用户的决策更加理性而惰性、更加看重产品价值而非成本、更加具有前瞻性而看重转换成本。因此不能用2C的互联网思维来做SaaS产品。
理论上讲，存在即数据，行为即数据。企业每天在每个业务过程都有大量的数据产生，当这些业务过程没能通过一套软件系统去信息化，那么这些数据就只是表现为一堆纸质文档或者表单的数据孤岛，或者虽然已经被信息化或者数据化，但是无法互联化，那么这些数据就没办法被识别、被统计、被解读、被汇总、被分析，因而也就无法产生业务价值增值。
信息化的过程本质就是：线下的工作线上化、隐性的数据显性化、数据共享容易化、数据分析智能化。
所以，SaaS对于产业互联网来说，其价值释放路径应该是按照信息化、数字化、互联化、智能化进行演进。当然，这几个环节并不是必然串行的，在SaaS应用的场景下，信息化、数字化、互联化可以同步实现，而只有累计的数据足够多且采集的数据足够“富”（贫数据没有太大价值）以满足增值业务场景时才具备了智能化的价值。
以人力资源领域来说，最初我们招人要到人才市场去摆摊收简历，互联网招聘网站发挥了让我们告别了这种招人模式，产生了信息红利1.0，但是时至今日，我们在招人环节依然有很大的痛点，简历不真实、匹配不精准、海选太费时、通知面试爽约而没有数据反哺机制、员工日常表现的数据不能在职业生涯中传递、背景环节反馈的数据容易失真等。
如果所有的企业都基于一套SaaS系统进行人力资源的全流程管理，并累积这些数据，并且这些数据能够在公有云上进行某种程度的互联共享，如果这些数据能够反哺至互联网招聘网站，建立每个求职者的职场信用分数，那么这些互联网招聘网站就可以发挥信息红利2.0了，就能够实现真正的智能招聘了。当然，如果某个HR SaaS从这个角度切入，很有可能是失败的，后面会分析这一点。但产业互联网的愿景，从长期来看，就是应该实现数据的互联互通。在具体的实现形式上，既有公有云模式也有私有云模式，在涉及要素流通（如人才流动）的领域，显然，公有云模式下的数据积累更加容易产生网络效应和价值倍增效应。
围绕企业服务的SaaS领域还包括原料供应链（分行业）、财税、电子发票、费控、HR、社保、智能合约、知识产权、公证、法律诉讼、商业数据、投融资等领域。可以想象，当这些领域的SaaS像原始丛林一样，其根系牢牢地抓住企业业务过程这片土壤，汲取各种业务数据，那么这些从垂直领域出发的数据未来有望基于区块链技术进行整合和优化，从而实现智能化的产业互联网。但这个过程必然会遇到很多的阻力，因为企业家们都希望别人呈现一个阳光的企业，而自己则是一个“黑盒子”。
这几年人工智能火了以后，很多SaaS的项目一夜之间插上了AI的翅膀。然后如何区分到底是一个SaaS项目还是一个AI+的项目呢？我有一个简单的鉴别方式。
在财务学中，通常将会计分为财务会计和管理会计。财务会计的核心职能是记录和反映真实的财务状况，而管理会计的核心职能是分析和优化。如果某个SaaS软件主要是将“线下的工作线上化”，实现了业务过程的信息化，那么相当于只发挥了财务会计的职能，为业务过程管理实现了信息化赋能，这个时候没有产生“化学反应”，只是发生了“物理反应”；而在此基础之上，如果能够有更多的数据挖掘和商业智能（BI）分析功能，能够为业务优化提供可视化的报表和持续改进的建议，那么相当于进一步发挥了管理会计的职能，除了有过程管控的价值，还提供了数据赋能的价值。从整个行业来说，如果SaaS只是实现了信息化、数字化，那么只能提供过程管控的价值，如果能够进一步实现互联化（哪怕是内部的互联化）、智能化，那就可以产生数据赋能的价值，也才可以称得上SaaS+AI了。
愿景是美好的，道路是曲折的。现实中接触很多做SaaS的兄弟，在具体的业务场景中遭遇很多的困局和挑战。下面就几个典型的问题展开分析，有关SaaS发展过程中可能会碰到的坑，可以进一步参阅《九轩资本刘亿舟：SaaS路上，你不得不直面的那些坑》。
对于通用型SaaS（甚至某些垂直SaaS）来说，通常存在一个这样的现象：
小微企业可用可不用，用户黏性不高，付费意愿很低；
中等规模的企业有信息化的需求也愿意付费，但企业总有很多个性化需求（与其他系统的集成、更加便捷的功能及UI、更加灵活的表单引擎、流程引擎、规则引擎等），当这种个性化需求强烈到一定程度，而SaaS平台又无法提供充分的接口和后续开发服务时，企业总有一种冲动想要自建系统；
大企业通常内部都有一个庞大的信息化部门在进行各种系统的建设以及系统之间的集成，他们很难选择外部基于通用逻辑设计的SaaS产品。
这就好比一根甘蔗，树梢部分太嫩（小微企业），不能吃，根部太老，吃不动，只有中间一段是甜的，可以吃。暂且把这个现象称之为“甘蔗理论”吧。
如果中间的部分有足够的“汁”可以榨取，SaaS产品也可以支撑资本市场的投资逻辑。但如果产品过于通用，给用户提供的价值厚度不够，无法保证足够的续费率，其用户周期价值（LTV）低于其获客成本（CAC），则SaaS产品的投资价值就会受到资本市场的质疑。
个人一直坚持认为，通用型的SaaS平台如果不能成为PaaS级的生态平台，无法成为一个靠“强产品强服务”甚至“强产品弱服务”而挺住的“木本植物”，又纠结于不想成为一个“项目式公司”的“草本植物”，则很容陷入尴尬的境地。尤其对于今天已经估值高达几十亿的通用型SaaS平台来说，如果不能在垂直领域为用户提供深度的价值，其高企的估值可能将自己闷死（只能靠传统软件巨头接盘了）。
因此，SaaS产品应当围绕垂直细分的领域进行深耕（可以参阅《九轩资本刘亿舟：管理型SaaS应聚焦垂直领域做深做透》和《亿舟微评：SaaS产品应该从垂直角度切入，价值深度要重要于价值宽度》），在具体的业务场景里面，才能将过程管控和数据赋能的价值落到实处，指望给客户一个Excel表格，而指望客户具有高超的VBA（Visual Basic for Applications）技能不太现实。
传统的信息化项目一般都要经历一个业务流程梳理和管理需求提炼的过程，后续的代码开发只是以一种技术逻辑去实现咨询阶段所梳理的业务逻辑和管理逻辑。而SaaS产品通常都是基于行业的“最大公约数”而设定了一些表单模板。
而事实上，不同的企业其管理需求是完全不同的。对于一个要携带数据的过程控制表单来说，该设置哪些字段，这些字段应该设置成什么类型，如果是选择题，应该设置哪些选项，颗粒度应该如何把控，设定好之后，如何将判据规则落实到具体的操作层，如何保证操作过程中的执行力，哪些字段应该被设定为必填字段等等，这些问题都是决定了SaaS软件跑下来的最终效果，而这些最终效果又决定了用户持续使用该软件的意愿和动力。
在现实中，很多软件没有跑起来，领导问起来，原因大部分都是“软件太烂了，不够智能，不好用！”，而缺乏信息化经验的领导又无法武断地强奸团队的想法，怎么办呢？最后不了了之。
事实上，对于很多信息化场景来说，半自动化半手工化的解决方案其实比所谓的全自动化的系统更好（事实上很多操作是需要人机交互，因而是无法全自动化的），但是很多人无法深入理解这一点。带着技术性思维的产品经理也会不由自主地迎合这种想法，而试图去做一个完全智能化、自动化的产品（这种努力是非常值得赞赏的），但往往要么无法做出来，要么就必须牺牲一些非自动化可以采集信息的字段，从而使系统跑一遍出来，获取的数据点确实相当有限的。
要设计一个合理的数据表单驱动一个完整的业务过程，并且满足管理者在后期的数据分析的需求，其表单设计必须遵循以下原则：
能做选择题就不要做填空题，能做填空题就尽量不要做论述题，实在万不得已要做论述题，也应当给出一个模板。
而事实上，我们在设计字段时往往面临两难选择，迎合用户的易用性要求，就必须要牺牲填空题和论述题字段（需要敲字的），而这样一来，站在管理者角度就不得不牺牲一些信息诉求。而在做选择题时，应该设置为单选题还是多选题同样需要根据具体的场景和管理需求进行精细化的考虑。另外就是，哪些字段应该设置为必填项（带星号的），哪些可以设置为可填项，在不同的团队其接受力也是不同的。
对于选择题来说，如何设置具体的选项也是很有讲究的，通常来说，有以下几个原则可供参考：
1、标准化原则（尽可能做选择题）；
2、从管理需求出发原则（每一个字段都可以回溯到某一个管理需求）；
3、颗粒度适中原则；
4、完备性原则（覆盖所有的可能）；
5、互斥性原则（不能同时有两个可选项，多选除外）；
6、可执行原则（每一个选项应该有明确的归类标准）。
举个例子来说明以上这两段。比如在某个工单管理场景下，我想知道上个月一个叫小张的小伙子在给30岁以下的穿红色衣服的女孩子做的工单中，有多少是超时完成多少是按时完成的。假设要实现这个管理需求，那么在工单管理的表单设计中，必须包含执行人、被服务对象的性别、衣服的颜色、年龄、漂亮与否、计划完成时间、实际完成时间等字段，否则“此情可待成追忆，只是当时已枉然”，也就是说如果表单设计没有预埋这些字段，事后来看，原本一秒钟可以搞定的数据统计工作，给你2个小时你也未必能搞定。
以上这些细节的问题，恰恰是SaaS软件在实现基本的过程管控价值之外，能否实现彻底的数据赋能的关键所在。而大部分的SaaS（尤其是通用型SaaS）完全无法掌控这些情况。
此外，流程引擎和规则引擎无法支持针对定制化的字段进行灵活的处理，也是企业在后期应用中碰到的头疼的问题。
所以，SaaS产品要帮助客户成功，必须要针对垂直场景深度挖掘客户的需求，并且为客户实施咨询赋能，才有可能产生持续的价值。
相反，大部分的SaaS产品虽然基于行业最大公约数进行设计，也能够为用户产生一定的价值，但是如果用户自身不是一个合格的“超级用户”（大部分的用户都不是，也缺乏足够的重视，也可能没有配备专门的信息化专员），则很难让越过用户的替代性拐点，很难持续付费也就不奇怪了。
按照应用场景，企业中使用的软件通常可以分为三类：技术工具类软件、业务软件、管理软件。一般来说，技术工具类软件和业务软件不存在执行力的问题，前者如果作为效率工具通常工程师都愿意接受使用，如监控软件等；后者跑的是企业的核心业务流程，员工绕不过去。而管理软件在企业里面的执行力最容易遭受考验。
管理软件有几个基本特点：
1、不是强刚需，用也可以，不用似乎也没什么大问题；
2、需要员工充分配合，越用越有用，越不用越没用；
3、一旦某个或者某些环节不用，会导致整个体系的垮塌；
4、短期和局部来看是牺牲效率的；
5、有时候，领导容易带头破坏流程。
对于很多SaaS产品来说，如果切的不是企业的核心业务流程，很容易遭受执行力不强的问题。所以，就其最终效果而言，40%取决于产品本身（无论自认为做得多完美），40%取决于企业的老板，只有20%取决于操作层的员工。
为什么这么说呢？前面已经分析到，一套软件要在企业中真正落地，除了前期需要一个完善的产品选型、初始化设计（业务流程梳理、数据字典设计、角色设计等）、员工宣贯培训外，更离不开后期的监督和持续改进，如果企业的老板不能认识到这一点，很容易半路上“投降”而屈服于员工的阻力，很容易导致应用推广过程流产。因此，有信息化经验的领导深谙这一点，在确保执行力上都是强迫症！
所以，一个软件产品在企业要真正落地成功，其最大的挑战来自于流程文化的缺失。什么是流程？
流程就是不惜牺牲个人效率，保证团队的效率；
不惜牺牲当前的效率，保证长远的效率；不惜牺牲局部的灵活性，保证整体的统一性；
不惜牺牲效率保证风险控制的要求。
但是很多人没有这个意识（包括领导者本人），所有人都不停的加塞、闯红灯，结果所有人都很堵。在中国，这种企业的流程和规则意识是很薄弱的，甚至好多流程是老板带头打破的。但领导们从来不认为是他的管理有问题，他们认为是你的软件的问题。这件事的评判权在你，但继续付费与否的决策权在领导。
所以，SaaS软件尤其是管理软件类的SaaS产品，不能简单带着卖产品的思路去推。你想省事，你想轻，你想采用鸵鸟策略，让客户自行挣扎，其最终的结果是你轻不了，还是得跳下去帮助客户成功，因为你要追求续费率。
对于很多企业来说，管理软件其实是个软刚需，即便你站在一个咨询专家的角度认为对企业很重要，企业可能还是后知后觉地坚持自己的观点。因为管理软件的价值很多时候取决于使用的过程本身，因而价值并不显性。因此，选择切入角度很重要的。
通常来说，如果能选择产品（如原料供应链）或者服务（如代缴社保或代发工资）切入，并且这种产品和服务是企业欢迎的，那么应优先建立产品或服务的供应链往来，先“卖灌装煤气”，先为客户提供供应链本身的价值，然后再逐步把SaaS“管道”延伸过去。其实，如果是先以服务或者产品切入，其逻辑已经不是SaaS的逻辑了，而是产品或服务供应链的逻辑。
很多SaaS项目有个误区，以为先把SaaS产品延伸过去就可以进一步转到供应链服务。其实不然，应该反过来，先卖罐装煤气，再卖管道煤气。也就是说，总体上来讲，通过服务或者产品的价值切进去，会比软件赋能（过程管控）更容易切入，另外，通过数据赋能去切入又相对会比单纯的过程管控更容易切入。
当然，对于没有其他产品或者服务切入的单纯SaaS产品来说，就只能踏踏实实地为客户提供过程管控的价值，如果用户普遍为这种软件价值买单并续费，本身就说明SaaS产品对于客户是有持续的价值的。
有些SaaS产品在互联网思维的影响下，采用免费策略将SaaS产品给商家使用，然后试图通过B端的使用带动C端的用户流量，最终希望能够成为该垂直领域的O2O服务平台，个人认为这种思路要谨慎。
SaaS其实相当于是个“胖客户端”，通过SaaS软件对线下商家或者服务商的业务流程的渗入，实现了线下资源的线上化，成为一个整合的资源网络，相当于打造了线下服务的接口平台，站在互联网的角度来看，相当于建立了一个SSP（供给方平台），而传统的互联网流量巨头则相当充当了DSP（需求方平台）。SaaS要逆袭成为DSP而作为互联网入口挺难的，这个结论很残酷但也很现实。
但在有些重服务的领域，如果SaaS服务商不仅仅给线下商家输出软件赋能，同时还输出品牌红利和管理红利，并且在初期通过整合其他互联网巨头的流量给线下商家或者服务商进行流量赋能，同时，在有些重资金的领域为线下商家提供供应链金融赋能（如房产中介领域的SaaS服务商好房通），理论上，SaaS服务商有可能通过品牌强化成为垂直服务平台。待品牌效应形成之后，可以触发平台的流量机制，进而为线下商家提供流量赋能。
而对于很多标准化程度很高的轻服务领域，SaaS的植入要成为独立的自流量平台，有相当的难度。但这并不意味着这种场景下的SaaS没有价值。在这种情况下，建议SaaS产品更加聚焦于为客户提供业务价值，做深做透，牢牢抓住用户，就一定具有价值（起码可以被巨头并购），否则，有可能两头空。
对于很多价值黏性不够的SaaS产品来说，BD能力越强越容易掩盖产品本身的价值不足的事实。如果产品团队不能尽早地发现这一点，很有可能导致过分烧钱跑马圈地换来的用户数据无法支撑后续的融资和估值，毕竟2B的领域跟2C的领域逻辑完全不同。在强大的BD攻势面前，很多用户会尝试着使用SaaS产品，但如果客观上需求暂时不成立或者需求虽然成立但是产品无法为用户提供足够的价值，最终活跃用户数据也会很难看。用2C的思维去做2B的SaaS产品会是一场灾难。
