【深度】Outsystems产品调研报告

关键内容：低代码、开发者生态、聚焦分析。 作者：小步 篇幅：全文约 6393字 阅读时长：约10分钟 提示：以下内容仅为个人分享，有兴趣交流的伙伴可在下方讨论区留言。

知识库首页

产品API：进阶全栈PM手册

提示：上方链接属于全手册首页，伙伴们打开后可以关注或收藏，用于日常工作查看，其中关注后，可以实时收到文档更新通知，希望对你有所帮助。

新手引导

我是小步，欢迎小伙伴的访问，如果这是你的首次访问，请点击下方链接，了解文档写作逻辑，才有更好的体验。

序言 用小步迭代搭建自己的知识体系
内容导读 如何使用这个手册

正文

本次调研主要围绕Outsystems低代码开发平台调研分析，主要会分为公司维度和核心产品线维度的调研分析两部分，具体内容视实际产品而定。

第一部分 公司维度

公司简介

OutSystems是成立于2001年以改变企业软件交付方式为愿景而出发的低代码开发平台公司，截止2021年全球员工超1200人，分布在60多个国家。目前公司估值已超10亿美元，主要资本方为KKR、高盛等（2018年6月3.6亿美元融资）。目前开发者社区数量38w+，服务客户4000+。

公司核心愿景（官网）：Our vision is to fuel the future of digital innovation. A new world unbounded by traditional software and systems, where the creative potential in every organization is unleashed. A future with No Limits.——基本含义就是以创新的交付能力解放传统软件系统领域。

收费模式

当前产品根据服务规格差异，按照不同版本进行按月付费，其中basic版本最低付费产品服务费4000$/月起（原5000$/月），目前客户包括丰田(Toyota)、雪佛龙(Chevron)、罗技(Logitech)、德勤(Deloitte)、理光(Ricoh)、施耐德电气(Schneider Electric) 等，年营收达到1亿美元，当然大部分客户还是集中在欧洲和北美，据Gartner分析报告，目前在亚太地区也开始不断扩大。

产品线分布

根据调研信息可知的产品线主要包含以下四个方向：

• OutSystems 11：旨在帮助客户更新落后系统并取代大规模的应用软件组合（PC端IDE开发工具）
• OutSystems Sentry：一种拥有内建冗余，且提供全天候支援的安全监督方案
• OutSystemsInsights：提供衡量应用性能和使用者满意度平台
• OutSystems.ai：平台可视化开发过程人工智能平台

其中第一个为OutSystems 11为本次产品调研的核心内容，也是可体验的产品，其它三条产品线暂未挖掘到有用信息，不过通过以上基本产品定义可以判断，作为以工具类驱动的产品，它重点是围绕如何平衡快速开发带来的性能问题、如何通过引入人工智能技术加速可视化开发工具的交付流程，以及如何提升使用者的满意度而进行产品迭代。

其他

【公司简介部分小结】

以上为该公司官网主要曝光的内容信息概要，更多信息可访问：https://www.outsystems.com/，但是从官网可感知，客户对成功案例和开发者社区的数量有比较明显的曝光和突出，所以，下方将先抛开核心产品本身，对公司进行分析。

公司分析

根据OutSystems公司的基本信息可以了解到，该公司最明显的两个点，第一是定价高核心且核心客户主要为大公司；第二有较为庞大的开发者社区量，基于此两点可以做基础分析

第一点：关于定价高且核心客户为大公司

抛开股东方面的资源背景关系，有以下几点值得思考
（1）团队历史悠久：2001年到现在，垂直专注于同一个领域，能力沉淀是核心壁垒，也是大客户选择的原因
（2）高昂产品价格定位：这部分直接过滤掉对应客户行业规模较小的公司，间接筛选出相对有高价值的行业领域，属于产品定位的战略结果，因为Outsystems系统核心发力点是应对复杂的系统搭建。

第二点：关于价值包装及展现

官网中有一个核心板块：Why Outsystems？重点突出介绍选择Outsystems的原因

Part1：Customer Stories
主要包含了144个story，涵盖包含能源、制造业、旅游业、公益、信息技术等12个领域，每一个story就实际开发产生的效果提升和变化都做了数据化的展示（举例见下图）。

Part2：Analyst Reviews
采用外部有知名度的机构进行分析报告背书，主要为Gartner和Forrester。包含了2019年-2020年的低代码平台分析报告。

在内容分析报告中，主要展现了同类产品在市场中的地位状态，另外针对个例分析中，用户使用后的评价和得分是有含金量较高的指标，也可以从中看到低代码领域同类竞品分布及状态。

（左图为Gartner，右图为Forrester）

Part3：Partner Ecosystem
合伙人生态，主要为合作伙伴提供完整的生态支持，通过资源整合的方式，技术分享，帮助合伙人快速发展业务，本质上也是以客户成功出发。另一个核心点就是扩大服务生态圈，引入更多传播节点。

Part4：Success&Services
客户成功主要围绕最大化Outsystems的技术能力实现来辅助客户完成业务成功，包含全球化的售后服务，体系化的课程培训，专业的咨询服务和指导等。这部分在SaaS领域就是围绕续费打造各种内容性服务和技术性服务，助力客户成功

综上所述，价值包装和展现可以最大程度的体现产品质量，渠道方面增加信息化的反馈，增加互动可以提升产品品牌的推广，这部分对做开发者生态有持续性的影响，也是一种品牌价值沉淀的方法。

第三点：开发者社区建设

以下是结合官网和信息检索得到的相关数据可以有以下分析：

Twitter关注者：2.4万 （https://twitter.com/OutSystems）
浏览最新的互动内容，至少可以感知两点：
1 Outsystems目前已与AWS达成战略合作关系，此渠道可以看到最新动态
2 咨询方面在不断的进行价值案例的宣传，与第二点的价值包装相匹配

四大公众互动反馈社区：1,533+
主要聚焦公众对Outsystems的产品公开评价和反馈，每个社区计划都包含了星级评价，推荐排行。

Gartner的部分截图

G2的部分截图

核心聚焦点依旧是品牌的打造
以上信息作为公司的宣传内容，基本评估：这样的机制属于在打造行业规范和标准，简单的表现就是为该领域提供一种相对官方的排名机制，并用作推广方式，提高市场品牌传播度。

开发者社区：30w开发者
outsystems自建的开发者社区，目前的数据量十分可观，39w+成员，1000w+级应用下载、28w+教程
社区一共分为六大块的建设：社区、课程培训体系、文档库、解决方案库、开发者社交互动、专家交流。

特点：社区排名机制——带动贡献者积极性的一种机制，也可提高黏性，是个平台维度值得参考的建设

结合以上基础内容，我们可以简单总结，针对一个核心面向开发者的产品生态，开发者数量是衡量此产品生态质量的关键指标；另外围绕开发者黏性，Outsystems采用了认证机制和等级评分方面的运营，类似于GitHub的开源社群建设，在开源节流方面的闭环设计。

即为开发者提供工具的同时，还必须将配套的内容建设同步完善，让输入有反馈、有结果、传播有路径，进而形成完整的开发者社群生态。

【公司分析部分小结】

若作为开发者工具为切入点定位出发，则构建一个开发者生态需要全链路闭环设计，开发者即生产者必须要有所收获，同时生产的结果，必须有转化的渠道。

第二部分 产品维度

基本信息

产品信息

产品类型：图形化低代码开发工具产品，PC客户端
产品定位：低代码快速交付平台，主要应用于企业各种工作流产品的开发，以及系统集成
产品核心用户：具备一定开发经验的开发者（小白用户需要较高的学习成本，工具复杂度较高）

产品风评：用户以国外大企业居多，外企接受度高。开发者承接项目单价很高，在全球组织本地的客户服务团队。可拓展性强，支持智能硬件。 多用来开发流程类应用，可以实现全栈快速开发，支持从UX到后端集成的所有内容，大型应用程序端到端DevOps和生命周期管理。

产品分析

分析逻辑

主要通过产品形态、产品业务架构、产品功能结构、产品体验评估四方面进行分析，围绕阐述产品是什么，它以怎样的业务逻辑工作，它的功能分布形态如何，以及它的整体产品体验状态，每个环节做了部分解释说明。

产品形态组成

形态说明：
Outsystems产品主要为PC客户端工具，需要下载安装使用，同时下载时发现Mac版本暂时无直接的下载渠道，甚至可以理解为没有，因此主要体验Window版本，软件包大小123M，属于轻量级的工具，但由于需要联云操作，所以获取信息较慢，关于PC端内容及界面形态，会在后续功能部分补充说明。

产品业务架构

业务架构说明：

如上图所示，产品整体业务由云端+客户端组成，其中云端负责生产资料的管理，负责连接数据、扩展、社区等；客户端主要为低代码开发编辑器部分，整体产品的层级关系是，开发者需完成在云端cloud注册成为开发者，获取独有的开发者环境environment，应用和Modules统一在该环境下管理。

每个应用可以包含多个module，每个module作为一个完整的生产单元进入编辑器中，进行构建。且完成开发后可以选择是否转为转为公共组件等

每个应用开发一般需要以一个module开始开发，同时需要有必要的依赖包（主要来源于outsystems自有的成熟UI框架，以及扩展第三方的Sercive等），具体需要以业务需求进行选择搭建。

应用开发部分编辑器主要由四大编辑视图组成，每个视图处理不同的内容，基本逻辑流程如下：

即页面包含哪些元素——>每个元素有哪些数据组成——>每个数据通过怎样的逻辑处理展示——>流程控制，实现应用组装——>最终完成交付

• Interface：主要负责界面内容展示，每个页面可进行CSS调整，同时支持JS等脚本配置，进一步提供界面布局和交互维度的调度，与Data、Logic、Process协同支持数据内容绑定。架构中包含了核心组成元素如screen即页面管理，它支持输入和输出和action等的调度

• Logic：主要处理client和server端不同Action的数据处理，根据实际使用情况做数据内容的响应。架构中可以看出每个action可以通过对action结果输出，内容输入做控制。

• Data：主要负责数据部分的获取，可以通过云端数据库，也可以进行本地数据调用，快速使用的点即支持excel导入后快速生成Entity即实体表，做字段定义等。

• Process：主要负责处理数据操作后集成相关业务系统，并不同流程逻辑的连接，属于构建工作流工具的核心部分。架构中包含它主要组成的元素，有条件、定时器、活动等流程触发点，完成对工作流的连接构建。

产品功能结构

说明：功能结构主要为客户端信息功能的梳理，仅梳理了主要的功能内容，颗粒度为核心界面元素

应用开发视图部分结构（核心！！！！！！）

说明：这部分主要拆解梳理了，每个功能单元内容包含的核心元素层级构造，可以有效了解该工具的信息结构状态。

产品体验评估

（1）界面交互方面

完成客户注册后，正常下载安装编辑器完成后，包含四个基本界面

构建资源库视图（Forge）——获取可用模板和扩展库

Step1：应用管理视图——管理账户下的应用

Step2：应用信息视图——整体应用信息的管理和构建入口

Step3：核心编辑器页面——应用开发核心构建部分

基本分析：
a、界面风格
在不考虑功能维度情况下，整体界面设计已经不太适合现如今主流的IDE工具界面，属于上一个时代的界面状态，其他方面无有价值的分析点。

b、功能分区
功能分区相对较清晰，主编辑页面内容，主要根据右上角【资源管理视图】切换发生内容改变，资源详情视图Tree结构较清晰，对有开发经验的用户有一定的友好性

c、新手引导
新手引导一般包含了工具的核心交互逻辑，由于内容较多，需要详细了解的可以访问此链接：outsystem入门 https://www.cnblogs.com/qbin/p/12108330.html，下图为主要引导风格展示，基本可以理解为细化的步骤引导，根据此引导可以基本完成一个简单的CRM应用的开发。

【界面交互小结】

可借鉴的地方：

• 新手引导部分具备完整的完成demo开发的引导，让新手能够快速体验基本操作流程
• 四个关键逻辑视图功能划分相对清晰，符合开发者的编排习惯，同时编排灵活度做到了代码级，可视化内容与树状目录基本可以一一对应，业务操作者可以有较清晰的操作逻辑，前提是知道背后的操作流程。

不足的地方：

• 视觉维度：整体界面风格太过老旧，从按钮到文字都可以做优化，已不符合当下的界面审美。同时肯定也缺少了作为工具类自定义风格配置部分。
• 交互维度：客户端的模式缺乏类似于保存文件概念的操作逻辑，不符合当下对本地文件的操作习惯，容易造成随时内容会丢掉的错觉。
• 结构层次：Interface部分的树状结构，页面与页面之间无法做父子级别的管理，不利于界面元素布局，同时无法通过拖动来完成页面布局也是无法理解的一个地方。

（2）功能实现方面

技术实现部分

• 移动应用主要基于Codova创建，使用的是visual langguage，自定义DSL，支持一次开发后编译出Android和IOS
• web应用主要是运行在浏览器的响应式web应用，可能框架为jQuery+bootstrap

此部分由于技术性太强，暂无更多有用信息。

功能性应用部分
由于需要偏技术性的内容学习，才能有更好的应用，以下仅为基本逻辑功能的分析，介绍内容主要围绕四大核心编辑视图作基础介绍。

功能视图1：Interface视图

此功能视图主要进行界面的创建，包含screen和block创建，右方资源树可以对内容资源做有效管理，左边工具箱，可根据需要拖动内容至界面中心，但不太友好的内容是，位置内容的调整，没有如预期状态可以进行拖拽移动，但可以通过界面化的参数调节调整。

针对界面元素中数据字段内容展示，可通过代码或可视化的组装完成内容展示，支持静态和参数配置。

功能视图2：Data视图

由于数据支持外部excel的导入，导入后支持自动化完成表实体Entity的建立，数据字段在视图里也支持展示，基本可以理解为数据库的增删改查功能，可以通过逻辑配置完成，简单操作，可以发现过滤器支持条件图形化配置查询。

Entity编辑

数据查询

数据过滤

功能视图3：Logic视图

此部分功能主要作用于client和server部分的行为处理，分别可以对client和server部分的动作做逻辑编排，基本上可以通过拖拽方式快速进行业务流程的创建，包含如何数据序列化、条件判断、异常捕获等，只要有清晰的逻辑流程关系，几乎可以做到零代码的状态完成创建，其中action创建后，可以在Interface界面，进行action的关联，完成数据逻辑处理，支持JavaScript、JSON等

功能视图4：Processes视图

此编辑视图，主要用于业务流程与应用程序集成，核心应用场景聚焦为Entity Action Event时，进行流程置入，举个例，如订单创建，当订单出现新增或更新行为以后，可接入怎样的流程机制，便可通过此视图工具完成。最常见的OA审批流便是典型用例，这部分业界也称之为“微流”的开发。

【功能实现小结】

基本体验后，有以下几点认识：
1、功能开发逻辑处理颗粒度维度：最小原子操作可以到数据字段维度，异常处理流部分也可以做到一定维度的处理，但由于整体操作逻辑还是需要深度学习才能使用，面向开发者基本上有较高的门槛。
2、流程工具维度：可视化功能组装，组件足够丰富，基本上可以不用重复进行轮子创造，从低代码维度来看，它确实减少了代码的输入，但对业务逻辑性要求又产生了新的要求。
3、业务完整性：基本上满足了从界面开发到功能调试全流程，同时debug模式也有Breakpoints部分的设置
4、版本管理：从工具应用角度理解，每一次的内容变更，一方面需要保存，另一方面需要保持如同代码上线的概念，但版本化概念比较缺失，如果在本地就具备版本维护，那对开发者会更友好。

其他部分，由于此工具复杂性较高，无法一一列举说明，更多内容还需要更多的学习，此部分就不做展开了。

（3）产品逻辑方面

首先Outsystems在产品切入口，与当下的产品转低代码的方式不同，它一开始的定位就是以低代码的方式打造开发工具。所以它的产品逻辑就是纯开发逻辑，偏向于业务系统的快速开发和集成，主要聚焦在工作流相关。而当下的低代码（国内）更多是业务开发生产出现了大量重复开发的内容，为提高业务搭建速度，降低开发成本，便衍生出了低代码工具，同时伴随PaaS和SaaS领域的爆发，将其产品化，便成了一个趋势。

其次产品内容与生态体系化搭建，配套的开发者社区，丰富的扩展库，以及依靠大客户的业务支持，工具以稳定为准，在既有大量的课程内容建设的投入的基础上，原生的Outsystems工具不会发生太大的变化。但不排除会出现全新的SaaS化的工具。

总结

通过对Outsystems从公司到产品维度的基本拆解分析，可以得出基本点：

• Outsystems低代码开发工具因为深耕领域较早，一定程度享受到了低代码前期概念的红利，同时在19年发展期间，技术和生态的搭建帮助他们沉淀更多大客户资源，因此它与当下的低代码产品生存切入场景不同，它不缺业务客户资源支撑，它要做的是更新迭代符合当下时代的互联网产品，SaaS、PaaS化是它必然选择的路径。
• 针对产品方案，由于技术迭代迅速，当前的客户端方案，可能有更合适的工具技术解决方案，因此能够为当下低代码平台产品提供借鉴价值点，主要是开发者生态社区的搭建，而内部功能设计逻辑，需要遵循当下开发者的工具习惯重新构建，底层的流程构建比如工作流、模板，是所有低代码必须具备的要素。

调研参考文档链接

1 低代码开发平台 outsystems 体验小记（前端视角）https://github.com/iuap-design/blog/issues/292
2 低代码跑出了独角兽，通用平台靠什么 http://www.soft6.com/news/201911/01/359343.html
3 outsystem入门 https://www.cnblogs.com/qbin/p/12108330.html
4 国内外low-code工具 https://zhuanlan.zhihu.com/p/55109696
5 对比网站：Mendix vs OutSystems 专门介绍 https://www.g2.com/products/outsystems/reviews

根据调研内容，可以挖掘更多可调研的产品，如Mendix、宜搭（钉钉）、搭搭云等

推荐阅读

阿里宜搭产品调研报告

相关说明

帮助与反馈