目前市面上的低代码产品品种类型繁多，产品定位、功能细节各个不同，需要按照企业自身的适用场景进行精准选型，针对某公司的数字化现状和需求情况，现梳理出一份简要的选型建议书，仅供参考。

  以提供saas服务为主要模式，对私有化支持较弱（此处的支持不单单是指部署层面，也包括部署之后的平滑升级、原厂服务等），中小企业是其目标客户，系统的集成能力、可扩展性容易受到限制。

  传统的OA、BPM产品往往会包括一个快速开发平台。近两年传统厂商喜欢通过对快速开发平台组件做包装，以低代码的概念进行宣传。

  那么此类产品往往有两个问题，第一快速开发平台与低代码相比，实际的产品体验（快速开发平台属于2.0产品，低代码平台是3.0产品）在易用性、可扩展性方面差距较大，但在选型前期，由于客户与厂商之间的信息不对等，此类问题一般暴露不出来。第二传统厂商原有产品的功能体系和支撑服务，难以通过自身的低代码进行相对有效转化，低代码只能构成其服务能力的一小部分。

  低代码产品的定位本质上是aPaaS（应用开发即服务），除了要提供方便快捷的拖拉拽配置工具，还要在iPaaS层（集成能力即服务）对API、数据库有强大的治理能力，如此低代码产品的效能才能得到最大化的体现。

  此类厂商主要是通过低代码工具面向自身客户生态体系进行赋能，产品往往是重量级工具，若企业自身的信息化系统主要由此类厂商产品做构建，那么接入该厂商的低代码产品可能是比较好的选择，否则重量级的产品无论是在应用还是在部署、运维层面都是一项费精力的事情。

  股份公司已建成一体化信息化平台，具备一定的应用管理和接口接入能力，所以针对投资公司，建议选型轻量级的低代码产品，避免生态型重量级产品在能力上与股份公司的一体化平台做重复建设。对于轻量级产品，要确定保证产品可以快速接入一体化平台即可。

  投资公司信息化层面具备IT的管理能力和一定的技术能力，产研层面目前主要是依靠外部厂商。基于此种情况，建议选型时关注产品是不是具备低代码和API管理能力，并确保低代码产品具备较强的开放性（能力开放和源码合作）和可扩展性（即原厂不是唯一服务商）。具体来说，有以下两个关键点：

  （1）低代码产品的功能定位要能满足业务部门和信息化部门的共同需要，可以为信息化部门赋能，从原先的IT运维管理转向信息化数智运营，为业务部门提供信息化的设计咨询、低代码开发咨询服务。

  （2）低代码产品除了能面向业务部门交付以外，也要能为信息化管理部门和相关的软件供应商提供低代码开发和API治理方面的服务。即通过API治理（iPaaS）增强低代码平台（aPaaS）的效用和服务范围。通过API平台对供应商的系统（数据、API）形成管控能力，避免对供应商进行过度依赖，通过低代码平台形成多员共建的应用开发能力。