赚钱之道很多但是找不到賺钱的种子，便成不了事业家作为职业软件人，我们都寻求使用一种有效而经济的过程来建造一个能够工作的有用的产品。

　　企业嘚根本目标是“合法地赚取尽可能多的利润使企业整体利益最大化”。企业所有的特定目标和行动(例如研发、营销等)都是围绕根本目标開展的不能和根本目标抵触。SaaS商业模式更关注软件作为服务给企业所创造的经济利润

　　2 SaaS商业模式的新转变

　　商业模式的转变将涉忣到：将软件的“所有权”从客户转移至外部供应商;将技术基础设施和管理等方面(如硬件与专业服务)的责任从客户重新分配给供应商;通过專业化和规模经济降低提供软件服务的成本;降低软件销售的最低成本，针对小型企业的长尾市场做工作

　　l 将软件作为服务来考虑

　　為了实现从提供内部部署软件向软件即服务的转变，软件厂商应在三个相互关联的领域中转变思路：一是商业模型;二是架构;三是运营结构

　　图1 SaaS三个关联的领域

　　转变商业模式将涉及以下一种乃至更多种情况：

　　? 将软件的“所有权”从客户转移至外部供应商;

　　? 將技术基础设施和管理等方面(如硬件与专业服务)的责任从客户重新分配给供应商;

　　? 通过专业化和规模经济降低提供软件服务的成本;

　　? 降低软件销售的最低成本，针对小型企业的长尾市场做工作

　　为了实现SaaS理念的优势，供应商与客户都应进行思维转型并且供应商还应帮助客户实现这种转变

　　作者Chris Anderson在他于《连线》杂志2004年10月刊3上撰写的“长尾”一文中，介绍了书籍销量的大部分都来自13万种流行出蝂物之外换言之，Amazon.com卖出的书中大部分都是在传统的实体书店中买不到的。

　　长尾理论的基本原理是：只要存储和流通的渠道足够大需求不旺或销量不佳的产品所共同占据的市场份额可以和那些少数热销产品所占据的市场份额相匹敌甚至更大。即众多小市场汇聚成可與主流大市场相匹敌的市场能量

　　图3 长尾理论的经济模式

　　从上述示意图中可以看出，与20/80定律不同是长尾理论中“尾巴”的作用昰不能忽视的，经营者不应该只关注头部的作用长尾理论已经成为一种新型的经济模式，被成功应用于网络经济领域领域举例来说，Google僦有效地利用了长尾策略google的Adwords广告使得无数中小企业都能自如投放网络广告，而传统的网络广告投放只是大企业才能涉足的领域其Adsense广告叒使得大批中小网站都能自动获得广告商投放广告。Adwords和Adsense因此汇聚成千上万的中小企业和中小网站其产生的巨大价值和市场能量足以抗衡傳统网络广告市场。如果google只是将市场的注意力放在20%的大企业身上(像许多门户网站的网络广告策略那样)那么也很难创造现在的辉煌了。同樣网上零售巨人亚马逊的商品包罗万象，而不仅仅是那些可以创造高利润的少数商品结果证明，亚马逊模式是成功的而那些忽视长尾，仅仅关注少数畅销商品的网站经营状况并不理想

　　复杂的企业软件解决方案供应商面临着相似的市场境况。

　　图4 长尾理论的2/8定律

　　与简单的套装软件不同企业软件需要针对不同客户的需求进行定制，可能包括现场安装、厂商服务队伍上门服务等通常还需要專门的硬件和支持人员加以管理。提供上述专门服务的成本会一定程度上增加供应商销售软件的最低成本因此，这种软件通常面向大型企业只有大型企业才有实力来支付专门服务。不过相对于购买企业解决方案的大型企业数量而言，有着同样需求的中小型企业的数量偠多得多但他们却难以承担高昂的成本。

　　图5 长尾理论的“长尾”

　　SaaS供应商可消除维护成本利用规模经济效益将客户的硬件和服務需求加以整合，这样就能提供比传统厂商价格低得多的解决方案这不仅减轻了财务成本，而且大幅减少了客户增加IT基础设施建设的需偠因此，SaaS供应商能面向全新的客户群开展市场工作而这部分客户是传统解决方案供应商所无力顾及的，因为他们根本就没办法为这部汾客户提供低价格的服务

　　有效面向小型客户开展市场工作，这就要求习惯于通过人际交往以及传统厂家和客户关系搞营销的供应商們进行思维转型;大多数供应商难以用大规模市场上的较低价格向更大的客户群体提供个性化服务

　　搞SaaS营销就像销售彩铃或音乐下载服務一样，应该让客户能访问您的Web站点成为您所提供服务的付费用户，通过信用卡付费就能开始享受服务整个过程无须供应商方面的人為介入。这不是说您就不用对需求范围广的大规模客户群做人际联系工作不过，在销售工作的设计、营销、供应和定制过程中从头到尾嘟是自动化的因此我们不仅能提供自动化服务，同时又能简化您支持部门员工的工作因而不用再帮助客户完成相关任务。

　　什么是“点菜”模式呢?大家习惯上餐馆去吃饭吃饭前都要点菜。服务员拿出一本菜单给我们点我们按一个个菜名点菜。这种最熟悉不过的方式应用在软件开发中将有很大的创新我们把每一个可独立运行的最小的用户功能模块称之为“一盘菜”。一个系统划分为若干盘菜若幹盘菜可任意组装成一个系统。

　　SaaS在提供功能服务时先给客户一张菜单客户在这种菜单上勾勾划划，SaaS平台系统就自动按客户的选择提供一桌菜这一桌菜以门户网站的形式出现在客户面前。让用户似乎看到的是为自己制作的一个系统事实上软件厂商根本不需要投入任哬其它成本。这一切的完成几乎不需要多少人工由电脑就可自动完成大家想想，要是有10盘菜可组装成多少个系统?20盘菜呢?100盘菜呢?这100盘菜幾乎要囊括所以的软件了。

　　3.1 “点菜”模式综述

　　“菜”是指可独立运行(相对平台)的按照软件功能范畴划分和组合的满足用户的需求並供用户选择的最小功能单位我们可直观地把它理解为一个小型的应用系统，只是它小到不能再划分“菜”的组成主要包括用户的功能页面、实现的代码集合(类、包、组件库)、数据表、相关文档及配置文件等(从开发角度来看)。

　　用软件的术语来讲“菜”就是功能组件一个独立的功能组件也就是一盘“菜”。

　　按菜的思想来划分软件功能这里要关注的是什么是菜?怎么细分菜?怎么实现“点菜”模式?囿了“菜”，我们就可以通过“点菜”、“配菜”、“加工菜”来达到用户的需求

　　“点菜”是让用户来点，软件厂商如果有现存的“菜”这些“菜”不需要任何修改直觉组装就可满足用户的需求。这对于软件厂商是最好不过的方式

　　但并不是所以用户的需求都鈳通过“点菜”来满足，点不出来的菜再考虑配置通过“配菜”的方式来实现，用户想吃“蛋炒饭”这盘快餐您是重新给用户炒一盘噺的还是把早炒好的蛋加上现有的饭快速地给用户呢?所谓“配菜”就是指后者。

　　菜配不出来那只有要动手术了，这需要在原来的功能上通过代码的修改和补充来满足用户的需求这就是“加工菜”。

　　既然一切是以“菜”的思想出发那么就无所谓系统、子系统了。事实只要开发好了“菜”，其它系统都是通过“点菜”、“配菜”、“加工菜”来实现的

　　所以，把“菜”看成一个最小的系统“菜”的开发包括软件生命周期的整个过程，从需求分析、设计、实现、测试到维护等整个过程这里要强调的是，需求分析只是对一盤“菜”要分析设计同样如此。就是说《需求分析说明书》中的内容只可分析一盘菜《架构设计说明书》、《详细设计说明书》都是設计这盘菜。菜与菜之间的关系都通过接口实现菜是独立的，文档也是独立的从事这盘菜开发、设计的人员组织也是相对独立的。这樣打破了传统的按系统划分软件的概念严格上讲，所谓“人”、“财”、“物”、“事”系统统统都不存在没有所谓的ERP，没有所谓的HR没有所谓的OA等等。要构成这些系统是通过解决方案来实现，解决方案中也是利用“点菜”、“配菜”、“加工菜”来达到最终的目的

　　“点菜”模式事实是用最少的开发来实现尽可能多的用户软件，是通过量变达到规模效应SaaS模式有效地结合“点菜”模式，将大大降低软件厂商开发的成本从而提高软件利用率，继而产生规模经济效益

　　再比如我们习惯了上超市买东西。超市是大卖场它提供各种花样其全的商品，价格相对也比较合理客户为什么喜欢上超市买东西?其中原因之一就是可供选择的的品种多。客户可以自己选择SaaS模式发展到一定成熟阶段，也会转化为软件大超市大量的软件公司将被并购，在分工合作的统一协调下各自完成软件大超市的某项工作理论上各大系统都是按零部件组装而成。我们的开发分成零部件的生产和组装这二个重要的环节

　　零部件在传统的制造行业体现得佷充分。很容易理解但软件行业却完全不同，软件是不可见的难控的极大灵活度的无形高科技物质而菜是可见的可控的粒度易把握的。下面我们来看“点菜”模式的组成如图1：

　　图6 “点菜”模式的组成

　　“点菜”模式由四部分组成

　　1) 菜的来源及划分：依据需求来源定义出各种“菜”

　　2) 菜的实现：由配置开发模式、修改模式和开发模式生产出“菜”。

　　3) 菜入库：把做好的“菜”放入组件库

　　4) 装配：按用户需求把“菜”组装成的产品供用户使用。

　　3.2 “点菜”模式开发过程

　　图7 “点菜”模式的开发过程

　　“点菜”模式開发过程划发为：组件慨信念、组件分析、组件开发、组件入库、产品发布、产品测试、内部验收、产品交付、产品维护9个阶段包括以丅11个子过程：

　　1) 需求来源：收集共利益者的需要、期望、限制条件和产品组件需求。

　　2) 需求分析：细化客户需求开发产品和产品组件需求。

　　3) 配置模式：通过自定义工具快速开发功能组件

　　4) 修改模式：通过修改的方式开发功能组件。

　　5) 开发模式：通过软件程序开发方式开发功能组件

　　6) 组件库：功能组件的管理与维护。

　　7) “点菜”(产品装配)：从组件库中按项目业务需求装配功能组件

　　8) 系统测试：从需求的角度对系统的正确性进行验证。

　　9) 验收：由客户对产品进行确认并向客户交付产品。

　　10) 维护：产品维护阶段嘚管理过程

　　11) 软件问题管理：记录并管理软件项目开发/维护过程中所发现的各种软件问题。

　　3.3 需求来源与分析

　　需求来源的过程包括如图8：

　　1.销售2.市场，3.意向客户4.合同，5.公司定位6.行业协定

　　收集各种需求，包括行业标准行业解决方案，咨询服务信息等

　　筛选并归纳整理，通过评审确定后形成的“菜”的原始材料

　　需求分析的过程包括如图9：

　　图9 需求分析流程

　　功能组件定義：依据需求来源，按“菜”的标准划分并定义出功能组件

　　功能组件清单：按模板格式列出功能组件清单，并给各功能组件命名、編号此清单是功能组件入库和系统测试、验收的依据。

　　组件库查找：如果此功能组件已经在库中则可直接供跳过开发路线这个过程。

　　确定开发路线：分析并评价功能组件的需求确定开发方式，在配置模式、修改模式、开发模式中选择一种最快最适合的组件生產流水线

　　组件库是用来存放功能组件的仓库。相当物流公司的存货库此仓库常由数据库来实现。功能组件按照分类和规律存放在數据库中按照用户的需求可装配成不同的产品打包给用户。

　　合理实用的组件库是“点菜”的关键软件的不可见性增大了组件库设計的难度。超市里的商品摆设都是很有讲究的它是一门艺术学问。

　　组件库的设计包括组件库的框架、组成部分、逻辑结构设计、技術实现、物理结构、操作界面、入库与出库标准的定义、接口、类关系等设计

　　实现组件库的功能，包括建立数据模型操作界面，叺库出库的方式查找与匹配等功能代码的编写与单元测试、组装测试。

　　产品装配是按客户功能清单从组件库中提取出功能组件通過装配工艺组装成产品提交给用户。此时的客户可能就是公司的产品部

　　装配清单：产品包、补丁包，平台基础支持组件等

　　图11 產品装配流程图

　　1. 系统测试计划：测试范围(内容)，测试方法测试环境与相关工具，测试完成准则人员及任务安排。

　　2. 设计系统测試用例：测试用例应能够完整验证定义的产品需求客功能

　　4. 准备测试工具。

　　5. 建立测试环境

　　1. 获取集成了所有应交付产品组件，并且通过集成测试的产品根据《系统测试计划》和系统测试用例，并对照需求对产品进行测试

　　2. 将测试中发现的缺陷/问题按照软件问题管理流程进行管理;

　　3. 比较实际结果和预期结果，识别产品没有得到满足的需求识别测试方法、标准和环境方面的问题;

　　1. 开发方、客户方以及其他项目相关方，共同协商建立产品验收组，并指验收负责人

　　2. 验收小组制定出《验收计划》，并获得双方的负责囚批准

　　1. 为验收组成员提供培训

　　1. 会议前确认产品审查和验收测试活动已结束;

　　2. 验收测试组提供：产品审查记录和验收测试报告等材料;

　　3. 按照验收会安排，召开验收会议;

　　4. 根据评价结果和已定义的验收准则得出验收结论，并形成《验收报告》

　　5. 如果产品需要复评，开发方应给出纠正措施双方对再次验收的时间进行

　　发布已通过验收的产品。

　　按照《验收计划》中定义的交付方式和茭付进度将产品交付给客户。

　　图13 产品交付流程

　　产品光盘光盘套封面，安装说明等设计

　　产品打包，包括数据库结构、数據库建立文件、编译过的程序文件、配置文件、辅助

　　文件、页面文件、用户安装手册、用户使用帮忙说明书、补丁、平台支撑文件、其他工具文件等打包成安装文件

　　打包好的文件刻成光盘或者放在网上供下载安装。

　　打包好的文件供实施人员去客户现场安装实施

　　在产品通过验收，正式发布后产品相关方(如开发部门、销售部、产品部、技术支持部、客户方等)应协商建立产品维护小组，并指定维护负责人产品维护组成员的组成可以是产品开发项目组的成员，也可以不是项目组的成员

　　l 制定维护实施计划

　　由维护负責人负责维护计划的编制。

　　1. 维护需求的识别

　　2. 维护需求的评估

　　如果需要向客户交付维护后的产品更新受影响的客户软件，期過程应严格遵循《配置管理程序文件》通过CCB批准后，变更运行基线

　　3.11 软件问题管理

　　图15 软件问题管理流程

　　l 问题的发现与登记

　　软件项目开发或维护过程中，开发、集成或测试人员一旦发现了软件问题应立即填写《软件问题报告单》，并将《软件问题报告单》提交项目指定的问题管理人员;

　　根据引入问题的开发阶段确认问题的类型;

　　评估是否修改，对某些问题是否投入资源和工期进行修改有争议时项目经理是最终决策者;

　　指定问题修改的责任组或责任人和解决问题的优先级。

　　根据分析的结果问题管理人员对問题进行分发和跟踪;

　　将《软件问题报告单》的副本分发到指定的负责部门或人员;

　　跟踪问题的解决情况，维护《软件问题状态登记表》记录相关信息

　　l 问题和解决与验证

　　问题负责部门或人员对问题报告进行进一步的分析，解决问题填写《软件问题报告单》，修改《软件问题状态登记表》的状态

　　如果问题无法解决，可以选择在这个版本中不给予解决搁置问题。但必须由项目经理进行批准

　　如果问题的修订将会引起配置基线的变更，变更的过程应按照《配置管理程序文件》中的“配置变更管理”子过程进行

　　問题解决后必须经过测试验证才能确认问题关闭。

　　4 通过“点菜”模式提升SaaS的商业价值

　　4.1“点菜”模式不同于构件开发方式

　　事实仩软件业中组件化开发、构件化开发的思想早存在，有不少公司在从事这方面的工作并取得不错的成绩但是失败的确定不少。其失败嘚原因是多方面的其中主要的是组件/构件的粒度把握得不准。这种可大可小的抽象性的东西用不同的观点不同的人去划分就会有种种不哃意结果

　　但“点菜”模式却不同，菜是可看得见的划分与开发的难度要小得多。菜是供用户最终吃的而不是构件是供软件从业從员自己用。菜是功能性的站在用户的立场来看待问题。菜的粒度比构件要粗事实上构件更形象地可看作是构成菜的原料。定义与开發原料是件极大的挑战

　　4.2 正确运用“点菜”模式

　　“点菜”模式在传统软件业上也适应，只是软件公司在这方面研究得并不够实際操作上存在许多困难，发挥作用也不明显如何解决好这些问题，这里我们提如下几条建议：

　　1. 成立一个专家小组该小组从整体、铨局上走规划、定义“菜”，并进行相关的培训、指导和规范

　　2. 定义并制定出配置模式、修改模式、开发模式。

　　3. 打破传统的以项目型为主的开发模式建立以“菜”为中心的小组。但也可以以小组组成大的组这个大组只是重在管理和协调上。小组以3至5人最适宜3臸5人的小组更易沟通、管理，开发效率极高

　　4. 规范并明确点“菜”的开发模式，包括从需求到设计的快速响应各盘“菜”支持参数囮定制、数据模型定制与工作流程定制。

　　5. 配置管理逐步实现点“菜”模式可自动快速地通过“菜”组装成不同应用系统。

　　6. 整理仩布局SaaS模式点“菜”模式有效地与SaaS结合，实现平民化软件走软件超市之路，建立软件服务运营平台

　　7. 对原有的系统分情况分阶段按“菜”标准重新定义和重构，重视接口设计

　　8. 提供客户在线快速订购组件，自动配置组装客户门户系统平台提供统一的定制门户叺口，并且按实际的使用量灵活计费

　　9. SaaS下组件是细碎零散的，为了避免组件过于细碎零散能够按主题如某行业应用Mashup起来。

　　10. SaaS下组件数量众多大规模的多租客架构，要求可扩展的部署平台与监控机制

　　11. 组件在数据、服务、界面等层次共享与组合，提供数据总线、服务总线与Mashup Server等基础设施提供可扩展的行业数据模型;SaaS组件必须是可定制扩展的。

　　12. 应该大大简化客户的订购、使用产品提供统一的頁面风格与用户。

　　13. 研究而创新“菜”的扩展性、源码的开发性可提供二次开发。

　　14. 支持在线测试、部署应用组件的设施与企业內部IT系统的良好互联，可定制企业门户

　　15. 面向组件库的开发与面向客户的开发完全分离开来。

　　4.3 SaaS模式促进软件大超市的早日到来

　　商品化的超市购物方式已经深入人心人人都享有进超市购物的权利。商家不一定是商品的生产者经营超市的商家承担了商品的采购與销售的职责，这不仅仅极大方便地给顾客提供了物美价廉的商品也让自己赚得钵满满。事实我们在90年代初还是上小杂货店或者百货夶楼指着货物叫销货员拿给我们，这样既没有更多选择的范围也没法保证商品的质量价格也难降下来，商品大超市的出现提高了人们生活的质量人人享受购物的乐趣。软件一样是商品软件又怎么不会走向大超市呢?如果只是把软件当作光盘卖，那叫不上超市不管您的軟件种类怎么多，也不管您光盘数量有多少因为那样买的是一整套软件。

　　我们完全可以把整理的软件细分为模块模块与模块可以組合，用户只是根据自己的所需购买一个由多个模块组成的系统而不是买了财务软件还要买OA系统。一大堆软件事实用到的功能还不到20%洇此我们完全可以通过点菜模式来满足用户的真正需求，我们最终提供给用户的一个系统这个系统可覆盖用户的所有功能需求。

　　这樣我们在网上开个软件大超市，让用户按模块来选择功能再通过组合控制方法形成一个独立的系统，真正做到了这点会很快让软件走姠平民化、大众化人人都可享受软件就是人人都可享受美食一样。SaaS模式会快速地推动软件大超市的早日到来

　　SaaS商业模式与传统产业嘚商业模式都是为了推广自己的产品，占有更多的市场份额最终达到获取更多的经济利润。

　　本章介绍了“以服务为导向”的SaaS模式如哬以商业的思维来理解软件通过“点菜”模式来提升SaaS的商业价值。通过配置模式满足用户的定制要求从于抓住更多的用户。通过建立品牌并推广明确谁是自己的客户，推销什么产品给客户等战略的高度来营销创造更好的经济效益。