低代码和无代码工具的核心原则——企业用户可以依靠这些工具来填补“应用程序的空白”——正在引起企业的共鸣。
据 Gartner 称,41%的非IT员工构建或定制自己的解决方案——到2023 年,这些“公民开发人员”的数量将是大型企业中专业开发人员的四倍,该研究公司预测。大多数组织已经使用了至少一种低代码工具,由部门或有问题需要解决的个人用户采用。Forrester预测,有一天,也许很快,开发不写代码的应用程序将像电子邮件和电子表格一样成为一种普遍的商业技能。
但随着发展速度的加快,风险也随之增加。据 Gartner称,治理自助式服务和低代码带来的更多自主权已经成为IT方面的一个关键考虑因素。
虽然正式的治理结构还不常见,但 IT 领导者已开始解决管理低代码的问题。低代码平台带来了更高的生产力、成本的节约,以及通常可以改善业务与 IT 之间关系的文化变革。如果做得好,低代码可以帮助企业在数字解决问题的文化中实现业务转型一直承诺的那种持续改进。
以下是 CIO 如何以务实的方式帮助公民开发人员取得成功,既降低了风险,又不妨碍试验和自助服务。
1. 走出阴影
Gartner 杰出副总裁分析师 Jason Wong 表示,要想让低代码取得成功,IT 领导者不能将其视为影子IT,而且CIO也不应将其视为潜在的负担。
公民开发的目的是说我们在IT和业务、这些公民开发人员对他们想要构建的内容的参与和投入之间达成一致,并了解哪些工具最适合他们。
此外,低代码和无代码平台不仅提供了一种可视化构建应用程序的方法:它们还集中访问和资源并跟踪它们的使用方式。正因为如此,IT部门可以制定政策,规定哪些人可以访问哪些数据源,以及如何允许他们共享应用程序和自动化流程,以整合这些数据。
基于角色的细粒度访问控制使IT能够管理对特定端点和数据表的访问,下至字段和记录级别,为不同开发环境中的不同部门提供适当的访问权限。还应该能够管理哪些连接器可用以及它们可以在端点上执行哪些操作。例如,可能希望客户支持能够构建可以读取但不能发布推文的应用程序,或者可能决定全局允许低代码用户更新记录但永远不会删除任何内容。
2. 平衡控制和自主性
为公民开发人员获得控制和自主权的正确平衡至关重要。不希望安全性差,但如果治理和访问流程过于繁重,人们就会回到不受监管的影子IT。
这不是非常复杂,但你必须全面考虑,而且它是针对你的环境的,在建立治理之前,数据是关键。其基础是:我们拥有哪些数据,哪些是敏感的,哪些不是。
一定要对外部共享的任何数据都应该进行数据泄漏保护,并且如果普通开发人员正在创建可能违反法规的自动化或工作流(例如复制电子邮件或PII),就要有警告他们的策略。
公民开发者也应该拥有平台选择的自主权,强迫企业在单一的低代码平台上进行标准化是错误的。如果业务用户无权选择适合他们的工具,那么就没有公民开发。
3. 选择正确的战略方法
为组织的公民发展问题建立正确的战略模型也很关键。
Forrester 确定了三种常见方法,第一种方法是由具有流程改进经验的人员组成的小型自治团队,这些团队由 IT 批准但嵌入业务部门并向业务主管报告。这种战略方法非常灵活,但无法扩展,这是一个小团队完成所有工作。
第二种方法是自助服务,任何人都可以根据平台中的策略和护栏使用低代码工具进行开发。
第三种也是最成熟的方法将敏捷团队和广泛的民主化结合到一个联合模型中,一个卓越中心管理低代码平台、实施护栏、支持部门和业务部门的团队或个人冠军以及自助服务低代码平台。
在这个模型中,特定应用程序的开发方式取决于其用例、使用的数据以及相关开发人员的经验。在安全开发生命周期中,可能有或多或少的步骤;可能对预览有或多或少的要求;在使用某个数据源之前,可能需要与某人合作。”
这种成熟的模型更为复杂,但它也是覆盖最广泛的模型:你控制数据,控制开发过程,但要务实。
4. 提供足够的 IT 支持
除了治理和政策,CIO还需要提供资源和支持。“IT部门对公民开发者的态度对他们的生产力和成功结果至关重要,”Gartner的 Wong 说。
为此,Gartner 建议通过涵盖“绿色”安全区的治理框架来规范公民开发,公民开发人员可以在其中创建工作流程和自动化;“黄色”支持区,公民开发者与专业开发者合作构建更强大的应用程序;以及需要 IT 监督和批准的“红色”危险区域,其中一些应用程序被认为非常复杂且对业务至关重要,它们仍处于 IT 控制之下。
例如,卓越中心可能会创建API 和自定义组件,或者支持融合团队与在低代码和传统开发环境中工作的专业开发人员。COE 还可能为公民开发人员提供学习资源和专家帮助,以完成更复杂或关键的工作(例如编写查询表达式),可能开放办公时间。这种协作和支持是低代码与影子 IT 的区别。
借助影子 IT,可以让个人独自做一些隐藏在阴影中、看不见的事情。让我们开放它,这样用户就不用担心因为使用这些工具而受到谴责。我们为他们提供了一条必要的学习路径:他们只是想深入到足够深的地方去构建他们需要的东西,并一边学习一边向社区、其他高级用户以及潜在的IT寻求帮助。
5. 正确使用 API 和连接器
为了取得成功,IT 需要主动提供连接器并创建强大的 API 以访问内部数据。
“确保您的 API 定义明确,拥有管理层或目录,然后可以通过这些低代码/无代码解决方案轻松连接,”API 平台 Postman 的首席布道师 Kin Lane 说。
还需要跟踪 API 在生产中的使用位置,既要控制外部 API 的成本,又要确保提供内部 API 的系统得到适当的资源。并非所有像 API 一样工作的东西都是由强大的后端生成的。尽管我们愿意相信设计良好的RESTful API 才是 API 的组成部分;事实并非如此, 带有 CSV 的 FTP 位置被认为是 API,而电子表格才是王道。
并且不要忘记机器人流程自动化(RPA),这是一种越来越流行的方式,用于将信息从遗留系统中获取到低代码应用程序和自动化工作流中。例如,通过建立自动从扫描的 PDF 中提取数据的 RPA 工作流程,IT 可以进一步授权公民开发人员创建有益的业务应用程序。
6. 不要忘记评论和指标
解决自己问题的个人业务用户不太可能考虑高可用性、业务指标或任何形式的正式审查。很少有低代码平台包含用于此的工具,但完成流程所需的时间等指标可能会有所帮助,引入定期审查以跟踪性能并分析进一步开发的机会也是如此。
指标和审查还提供了检查业务流程的机会,因为自动化一个糟糕的流程只会更快地获得糟糕的结果。使用流程挖掘工具来发现一些团队可能正在执行的低效率或额外工作,并为实际处理流程的员工提供简化流程的机会,而不仅仅是创建应用程序来解决问题。
7. 根据需要改进操作
低代码平台上的分析和监控工具不仅可以跟踪API的使用情况,还可以提醒你那些已经变得非常流行或对业务至关重要的应用,以至于你可能想把它们移到高德纳(Gartner)列出的更高层次的黄色或红色支持区域。
突破性的想法变成了非常受欢迎的应用程序,它们需要更多的IT支持,这是商业创新的标志。IT的工作就是让这种情况持续下去。
在实践中,这种进展会造成紧张;最初的低代码开发人员可能担心 IT 接管该工具,而 IT 团队可能担心支持不是他们创建或指定的应用程序。业务和 IT 之间的协作文化应该有助于避免双方的怀疑。
8. 培育创新文化
虽然CIO可能担心低代码实验会为自己的 IT 团队生成过多的应用程序,但更常见的问题是没有聚集足够的动力来使策略发挥作用。Bratincevic 指出,许多遇到低代码可能帮助他们解决的问题的业务用户不会自然地将自己视为“开发人员”。
许多组织发现内部黑客马拉松——加上培训、指导和支持的时间——可以激发兴趣并生成初始应用程序的核心。或者,寻找可能成为早期采用者的问题解决者。已经使用影子 IT 作为涉及持续改进或特殊项目的角色的一部分的人是成为冠军的主要候选人,特别是如果他们请求了一个 IT 没有时间开始工作的应用程序。
低代码可以实现显着的职业发展,业务和一线员工可以获得更多技术角色的专业知识。将其视为发展未来数字化劳动力的一种方式——并准备支持和奖励员工以实现这一目标。低代码程序无法扩展的一个原因是期望员工将其作为日常工作之外的工作,而不是作为其中的一部分,尤其是在公司文化不重视持续改进的情况下。
必须处理变更管理的人的方面。如果最初的公民开发者跳槽了,而他们的同事或接替者对这款应用不感兴趣怎么办?或者,如果他们感兴趣,是否有足够的文件证明应用的目的和背景?
另一方面,Wong 说,并不是每个低代码应用程序都会永远有用。“如果没有人站出来拥有它,那么假设必须是:它不是很有用;让它死吧。”当实现的成本一开始就很低时,这就不是什么问题。
Bratincevic 建议,将低代码视为机会,但也意识到这是不可避免的。这不会是完美的;会有问题,你会犯一些错误,但这是你的机会来协调所有人在组织内开发应用以一种相互联系,自动化和明智的方式;要建立一个正确的基金会,而不是让一切碰运气。