您确定要删除该商品吗？
商品已成功加入购物车！
商品加入购物车失效！
标签：产品研发
企业内部的OA协作系统由来已久，它们可以帮助企业实现流程审批、即时沟通、文档管理、内部论坛、任务管理等等功能。随着企业级SaaS服务的发展，现在即使是对于只有十几位员工的小微企业来说，用上成熟的OA办公系统也不再是难事(在过去需要线下部署的时代，这无异于是天方夜谭）。除此之外，这些新型系统在易用性、界面美观度上也有明显进步。产品设计与开发是OA系统最典型的应用场景之一。今天我们就从需求收集与分析、产品设计与研发、产品运营、产品迭代这几个核心模块出发，为您详细介绍主流的OA系统都是如何针对该场景给出解决方案的。➤OA解决方案内容（一）需求收集目前各个oa系统软件通过三方服务集成功能为企业提供市场调研与需求收集的能力。其中不仅包括可以用来进行收集前期意见的各种表单和问卷调查工具，还有AppStore、微信、微博等应用中心或者社交中心，企业可以通过这些渠道来收集用户的后期反馈。接下来，企业内部的运营团队可以创建一个名为专门的“需求收集”任务项目，并将产品经理邀请进入该项目。收集到的需求，经由产品经理的判断，最后可以分为执行和不考虑等多种结果，并更具实际情况设置不同的任务优先级，从而有效的对所收集的需求进行归类整理。（二）需求分析产品经理确定了要做的需求后，就需要跟设计、研发等人员开会商讨。这些会议产品经理可以通过创建日程快速安排（有实时更新的公开日程表，方便各部门进行排期）。不仅如此，日程还会支持关联功能，每次会议上要讨论的内容和材料，都可以事先关联在日程详情中，方便会议期间随时查看需求的具体信息。（三）产品设计与研发产品经理可以在任务项目内将对应的设计／研发任务（原型设计、视觉设计、开发、内测等）分配给设计师和研发人员，并设置相应的任务说明与截止时间，实现任务的快速分配流转。在设计与研发过程中，不同部门间的工作文件可以按预先设定好的流转规则进行传递（比如设计师上传的设计稿件，在经过审核后，会马上递送给相关的研发人员）。在另一方面，关于任务的进展产品经理和研发／设计人员可以通过评论进行沟通，并且信息都有实时记录，不用担心丢失。（四）产品运营与迭代产品发布后，就进入了运营阶段。在产品正式上线后，用户会在使用过程中产生各种各样的问题，运营团队在收集到用户反馈后，又会统计到“需求管理”项目中，作为下一轮迭代的需求来源。这些需求在之后也会提交给产品经理进行下一轮评估；这样就实现了整个研发的闭环。➤有哪些主流的OA系统我们在综合考查了国内OA市场内各款产品的核心功能、收费、用户量、客户服务等指标后，为您挑选出了以下10款适合中小企业使用的主流OA办公系统，并对它们分组做了横向对比评测。它们分别为：Teambition、Worktile、iQuicker、Tower、Trello、明道、泛微eteams、今目标、日事清、企业微信。
saas行业有着很多。但是大家能知道SaaS行业会迎来什么样的顿悟吗?下面我给大家来说一下。产品的边界是命根SaaS企业已经普遍感受到必须严格控制产品的边界。硅谷产品的专注简洁特征不是偶然现象，而是这个产业的必然。在中国SaaS界，很多人都拿Salesforce作为标杆和榜样，认为这才是成功SaaS企业的模范形象。销售云，营销云，服务云，XX云，只要是客户需要的，都可以加一个“云后缀”。但是，Salesforce的今天是从Salesforce的昨天发展而来的。Salesforce，SAP，Oracle，微软的昨天才是我们的榜样。在20年前，Salesforce只是一个在浏览器中运行的SalesPipeline，它的复杂度甚至不如今天月费20美元的轻型CRM。在企业软件领域中，没有一个公司可以做到在开端的前三年建立一个庞大和复杂的产品体系。在站稳脚跟之前，每一个企业软件都应该极其专注和收敛的，即便拥有一定量的客户以后，还要设法提升产品成熟度，建立牢不可破的高留存。在留存率问题没有解决之前，就急于通过扩展产品宽度来拓客，就会在获客和留存两个环节都困难重重。产品边界松弛还因为我们会对研发成本的不当预期。像金蝶用友的传统软件产品，研发投入的确是周期性的，建立一个产品，投入一轮研发，交付产品以后一段时间，研发成本就可以消除，从而投入到新的产品当中去。可是SaaS不一样，研发成本不会消除，甚至都不会减少。任何产品只要上线以后，就是始终不断地迭代，一个接一个技术问题的解决，特性的增加和调整，新技术的运用。这本身并不是问题，因为理想情况下，收入也是叠加的。但是，如果初创SaaS企业放松了产品边界，从一个职能延伸到另一个职能，从一个行业拓展到另一个行业，研发成本就不仅是持续，而且是倍数叠加的。更要命的是，复杂软件产品的研发效率和人数根本不成正比。研发人数越多，消耗在计划和沟通上的成本就会额外增加，导致研发边际效能严重下降。读过《人月神话》的人必然知道这其中的奥秘。如果产品的模块化设计程度较低，那么这种叠加的研发投入还会带来质量和用户体验的灾难。有加法，也可以有减法。理论上，加减相抵也许能够控制复杂度。但是，做这行的都明白，除非你做了一个完全错误的决定，导致新的扩展没有人使用。你也许可以悲伤地砍掉这个产品。但是遗憾的是，这种极端情况很少见，大多数的叠加总会发展一些客户。发展了客户，就有合同，有了合同就有了承诺，有了承诺，你就很难做减法。一个不能做减法的行业，是多么可怕。所以，第一个顿悟就在于产品边界的控制。我们再也不能轻率地决定开发新的功能，增加新的模块，发布新的产品。保持产品的单一和简洁不一定能够SaaS产品成功，但却是保证存活的生命线，是我们的命根子。终于开始彻底信任开放小客户缺乏支付力，所以国内不少SaaS产品开始转向服务大中客户。但是一进入这个服务区间，马上就面临了现实的问题——客户的议价能力。议价能力并不一定指的是砍价，更重要的是对需求满足度的刚性要求。你见过几个大客户的需求描述是正好吻合或者小于一个SaaS产品的既有产品能力边界的?一个都没有。所有的客户原生需求或多或少都会超过单个产品的能力范畴。比如采购渠道管理系统的客户会自然提出管理库存、物流、培训等模块的需求。没有这个功能，怎么办?面对大客户，牙关是咬不紧的。只能做!这几年，SaaS公司的销售和研发不知道为这些问题花了多少口水，多少CEO都为了这个问题纠结万分。答应得容易，做起来难，于是SaaS产品界出了很多很多奇葩的做法，各种版本，各种方案，林林总总，就是为了满足多样化的需求。当复杂到一定程度，干脆，产品自助试用环节也被砍了，因为完全不知道该怎么给一个陌生客户试用什么样的版本。单一代码库是别指望了。模块化设计得好的，还能够进行必备的代码分离，主产品的迭代还能保证;急于业务，疏于技术管理的，干脆就加团队算了，反正账上还有钱。一个又一个的项目，一个又一个的版本。为什么客户的需求都要通过一个产品满足呢?因为我们既无法说服客户，又无法调动行业。渠道管理产品无法简单地和仓库管理应用打通，当渠道商下一个订单的时候，不知道需要从哪些仓库发出哪些物流，怎样组合是最经济的。于是明明做渠道管理的产品，不得不调研和开发WMS，TMS系统。而同一时间，WMS厂商和TMS厂商也被同样的客户要求追加订货系统。客户把每一家SaaS企业都当作SAP和微软了，这是一个多么糟糕的世界?答案在哪?开放。通过相对标准和安全的授权模式(API Key或者OpenAuth)提供公开的API，让任何开发者(包括其他厂商和客户自己)都可以轻松读取和写入业务数据。有健壮和完善的API，就等于将自己的产品和所有其他产品的集成创造了条件。于是上面的问题就有很好的解决方案，我们只需要创建一个简单的服务，让渠道管理应用的渠道订单触发生成WMS系统的出货单，从而继续触发TMS的物流单。虽然这个过程还需要一些定制开发，但它无疑保护了每一个产品的边界。令人高兴的是，在过去一年内，开始提供标准范式API的SaaS产品越来越多，只不过有很多还不够开放，比如没有OpenAuth体系，APIKey要单独申请。这种本来可以快速实现的对接开发还必须伴随很多线下的沟通和协作。围绕产品之间的集成需求而出现的IPaaS品类也开始出现。将集成服务产品化，让用户或者厂商通过表单配置来完成API之间的调用，甚至建立SaaS产品的集成用例库，零代码实现任何两个产品之间的场景对接。今天，这样的路已经有了，只是还不够通畅。我相信顿悟的SaaS厂商接下来会不遗余力地推动它，让产品聚焦不至于在满足客户需求的压迫下而土崩瓦解。在这次崔牛会精彩的辩论赛上，有厂商甚至还在喊出客户需求第一的口号，认为只要是客户的需求，我们就应该不惜一切代价去满足。这个逻辑只会让企业走向深渊，让行业开放无限期推迟。任何有商业常识的人都知道，客户的需求应该满足，但绝不是没有取舍的。流量从何而来最后的一个顿悟，其实是不言自明的。用户流量从何而来?钉钉吗?企业微信吗?绝不是。我相信未来SaaS产品的主要流量除了来自自己品牌本身口碑以外，就来自于自身的开放性，而不是因为巨头产品中有一个应用市场。因为我买的飞利浦显示器同时支持HDMI和USB-C，而我的电脑是MacbookPro，所以我选择了飞利浦显示器。因为明道云有Webhook触发接口，而我用的金数据表单带有Webhook输出，所以我选择了明道云。IT产业中相当比例的用户流量就是这样流动的。即便是企业微信用户选择应用市场中的应用，本质上也是因为用户账号和消息已经和所有应用打通，而不是因为有一个集市在促销。其实，企业软件的获客通路是非常显然的，那就是其他企业软件。真正有价值的企业客户肯定不会只依赖一个单项产品，所以当已经在使用某个产品的用户选择扩展场景时，优先选择的当然是能够和现有产品低成本高质量集成的那一些。所以SaaS产品两两之间建立互补性获客是非常容易的事情。北美市场在这个问题上已经达到了极致，因为任何两个产品之间都不存在集成困难，某公司使用Salesforce的销售管理，同时使用Netsuite的ERP，没有任何问题，还有Zapier这样的厂商早就建立好了Salesforcevs. Netsuite的集成场景，甚至这个集成场景用MicrosoftFlow也没有任何问题，更不用说Slack用户还可以轻松创建一个消息提醒到群组。Slack为什么能够增长这么快啊?因为使用任何一个与它集成的SaaS应用的用户都多了个使用Slack的理由，而这样的应用超过1000个。希望通过以上知识可以帮助到大家。
京公网安备 11010502030885号
您的余额不足，请到充值中心充值或选择其他版本
立即充值
致力于打造中小企业可信赖
会员权益
招募专家
18954161236
在线客服