跳转到主要内容

IT 领导者分享他们的经验和建议,以加快 IT 改革,包括减少项目、转向基于产品的交付以及促进文化转型。

IT 部门在向业务交付技术支持的变革方面面临着前所未有的压力。 然而,对 IT 的大量需求可能会使 IT 领导者难以将 IT 资源集中在正确的工作上。

在这里,敏捷性至关重要,聪明的 IT 领导者正在加倍努力简化 IT,无论这涉及重新确定项目优先级和重新调整 IT 组合、合理化应用程序和追求云原生方法、通过采用 DevOps 或 AIOps 提高自动化,还是彻底改革 IT运营结构。

CIO.com 与四位 IT 领导者讨论了推动他们精简 IT 以提高敏捷性的努力、他们如何做到这一点、最大的挑战是什么,以及他们发现的做好这件事的技巧。

拒绝给予 IT 专注的礼物


IT 服务公司 Randall-Reilly 的首席信息官 Chiranjoy Das 在今年早些时候的 LinkedIn 帖子中描述了他如何“无情地取消项目以增加组织的关注度”,“专注让员工更容易在更高的水平上工作”。 ”但这只是 Das 重新承诺他的技术组织变得更加敏捷和产品驱动的一种方式。

Das 的最大优先事项包括将 Randall-Reilly IT 与客户系统集成,以使其对其业务更加重要,使用微服务等现代方法重新架构旧系统,实施人工智能和机器学习以自动化手动流程,并提供干净、标准化的数据用于分析和监控.

让这些挑战更加复杂的是 IT 对速度和敏捷性的巨大压力:“事实上,我们不得不以不完美的功能上线,以保持敏捷并满足客户的需求,”Das 说,并指出他将 sprint 从两周减少到了一周。 “这迫使团队保持警惕,反过来又给 Scrum 团队带来了很大的压力,因为我们不能危及安全性。”

现有资源只能挤出这么多东西,这就是为什么达斯开始重新评估他团队的项目。导致管道过满的问题包括部门负责人推动可能对整个企业没有战略利益的宠物项目,将太多投资回报率不高的大项目归类为紧急项目,以及达斯所说的“大而闪亮的想法, ”比如没有经过适当审查的加密项目。

由于交付——以及他精疲力竭的团队成员——在期望的重压下遭受重创,达斯开始着手解决一些重大问题,包括某些项目缺乏商业案例,其他项目没有执行发起人或项目所有者,以及缺乏可用于解决技术债务的时间。他缩减了 IT 正在进行的项目总数,并一直倡导转向“以产品为中心”的软件开发,这意味着除非产品所有者根据利益相关者的需求确定优先级,否则不会完成任何工作。除了每周冲刺,IT 还实施了 CI/CD 并进行了自动化回归测试,从而提高了 IT 敏捷性和质量。

自从 Das 开始做出这些改变后,IT 行业的气氛已经好转。人才保留增加了,会议减少了,IT 正在开展更多与业务目标相一致的战略项目。

Das 说,公司领导很欣赏 IT 采取了坚定的立场。 “但他们正在观察我们,看看我们是否能够兑现我们承诺的承诺,”他补充道。 “更高的责任感但更少的项目有助于我们更好地集中注意力。”

领导力建议:Das 说,让企业了解 IT 为何要减少项目数量——以更一致地交付——是至关重要的。 “大多数项目不会增加价值,”他说,在将项目发送给 IT 之前,责任需要转移到业务领导者身上,以证明 ROI。

此外,敏捷的心态和文化远比敏捷开发方法重要得多,Das 说。 IT 领导者必须在一头扎进 CI/CD 之类的事情之前创造一种紧迫感。敏捷性的其他关键要素包括建立数据仓库、API、适当的安全性和可扩展架构。 “没有基础块,IT 就无法敏捷,”Das 说。

通过集成框架和微自动化为业务赋能


赋权是理光美国的游戏名称。为了与专注于以客户为中心和创新的业务战略保持一致,技术团队必须做出快速决策并适应不断变化的业务条件。

技术高级副总裁兼理光美国数字服务中心负责人 Bob Lamendola 表示:“每个人都在各自为政的地方做自己的事情,这不可能是一个自由竞争的局面。” “但它也不能是单一的。”

这导致了理光 IT 的三个关键战略优先事项:微自动化、采用集成框架和支持公民开发人员。事实上,技术功能现在围绕自动化、集成和分析进行组织。

通过专注于通过微自动化逐步改进业务流程,IT 已经能够快速实现效率目标。 “我们继续拥有长期的大型项目,专注于更广泛的转型变革,但通过专注于较小的胜利,我们正在拥抱敏捷性并向组织证明我们正在倾听他们的迫切需求,同时也在努力实现长期目标,”拉门多拉说。

意识到在可预见的未来需要支持复杂的混合云基础架构,Lamendola 的团队开发了一个灵活的集成框架,可以在保持安全控制的同时实现更轻松的互连。 API 层允许理光的第三方合作伙伴连接公司的 ERP 和其他合作伙伴服务,从而以最少的运营支持创造更好的用户体验。

“我们认识到需要灵活地根据需要更改合作伙伴或混合模型的组件,”Lamendola 解释说。 “通过将我们的集成框架置于我们架构的核心,每次我们想要将新的解决方案整合到我们的组织中时,它就变得不那么繁重了。”

IT 还在数据聚合、工程和分析方面进行了投资,以释放公民开发人员的力量,他们可以使用集中开发的规则和业务流程框架将数据转换为驱动行动的信息。

“他们有权构建自己的仪表板和模型来实现团队的目标,”Lamendola 说。数据分析社区还促进思想分享、成就庆祝和一致性。 “这个社区的真实性质与数据聚合和可访问性的结构化方法相结合,在功能和企业层面提供了平衡的控制水平,”他说。

这是一个重大的文化转变,它要求 IT 适应不舒服。传统工作正在转变,需要新的思维方式。 “我们取得了成功,我们确保我们‘高度庆祝’这些胜利,”拉门多拉说。 “从长远来看,我们将专注于生产力,但我们必须从一开始就掌握文化,以释放潜力。”

领导建议:如果你建立它,改变就会到来。 “我们一直专注于基础,而不是最终产品。最终产品很重要,但它并不能推动我们前进,”Lamendola 说。 “我们正在旅途中,仍处于转型中期,但我们正在努力利用过去的投资来加速未来的基础战略。”此外,了解何时放松控制也很重要。 “是的,政策和控制必须存在,”Lamendola 说,“但你还必须拥有一种灵活性,才能让敏捷性发生。”

打破壁垒:围绕产品和流程进行重组


内容服务提供商 Hyland 正在进行重大系统改造,以推动公司发展并创建下一代基于平台的产品。首席信息官 Steve Watt 说,这也给 IT 带来了巨大的压力,要求它提供持续的价值。

“企业不能再等待所有项目都是大爆炸式交付,”他说。 “他们期望在整个项目生命周期中持续交付价值。”

对于瓦特来说,精简意味着消除员工绩效的障碍。在这里,自动化至关重要,使团队能够在 IT 内部和外部自助服务,并专注于结果。 “通过让正确的资源直接参与并专注于这些成果,团队成为一个运作紧密的单位,对成功的看法很狭隘,”他说。

这就是 Watt 将 IT 重组为产品或流程一致的团队的原因。每个部门都有自己的报告结构,包括来自各种学科的员工,包括解决方案和平台工程师、产品所有者、敏捷流程经理以及精通基础架构、应用程序开发和集成的 IT 员工。例如,一个团队完全专注于 Hyland 的“按订单报价”流程,使用敏捷框架持续完成工作,以针对持续积压的功能、改进和修复执行。

自重组以来,有更多的重点和更少的时间浪费在优先级或合理化可能永远不会完成的工作上。 “此外,我们已经更好地与业务保持一致,并且看到更快的实施和更少的返工,”瓦特说。

围绕这种新的工作方式与企业进行持续沟通至关重要。瓦特解释说:“我们已经寻求并获得了支持,即需要削减一些事情以专注于重要的事情,并确保我们专注于利用我们拥有的有限资源进行正确的工作。”

领导建议:如果企业没有准备好在正确的时间和有规律的节奏参与,IT 仍然会浪费时间和精力。 “确保您的业务利益相关者了解敏捷的真正含义以及您在该框架中的执行将如何发挥作用以及它们适合该流程的位置,”Watt 说。

恰到好处的技术:拥抱工作流程自动化


首席信息官 Juan Sanchez 说,对于非营利性医疗认证组织 Inteleos 的 IT 团队来说,提高速度和敏捷性的压力是自己施加的。

集成平台即服务 (IPaaS) 的实施是 IT 议程的首要任务,同时通过核心平台更新减少技术债务,为内部和外部客户构建数据科学能力,以及创建零接触员工入职和配置.

“如果我们利用这些工具和机会,我们可以产生巨大的影响,”桑切斯说,并补充说,“精简 IT 的最终方法是利用工作流自动化。”

通过利用具有完整 API 的成熟 SaaS 平台,Inteleos 的开发团队可以专注于工作流的关键操作,而不是代码的底层细节和永无止境的重构工作。基础架构团队还可以专注于构建为业务带来直接价值的工作流。例如,通过简化和自动化帐户和应用程序配置工作流程而不是保持域控制器运行,IT 可以为新员工提供更好的入职体验。 “如果做得好,技术团队将构建更像物流系统的系统,通过在 SaaS 节点之间建立最有效的路线来连接它们,”桑切斯说。

目前,Inteleos 的许多业务流程都需要人工干预。变更请求通常侧重于使流程对员工更好,但不一定对客户有利。 Sanchez 希望当业务流程所有者了解他们可以自动执行重复性任务时,这将释放他们以更集成的方式思考流程的能力,更加关注流程的受益对象和方式。

“我们将我们的运营视为一个弹性系统,”桑切斯说。 “我们试图确定我们交付价值的瓶颈在哪里,并考虑我们应该在哪里以及如何扩展该系统的不同部分。”

Inteleos 还采用“Goldilocks IT”原则——构建恰到好处的技术,不多也不少。根据桑切斯的说法,建立新技术几乎应该是最后的选择。 “虽然这似乎违反直觉,但每种新技术解决方案都有直接和长期的成本,”他说。 “我们必须小心,不要跳得太快,先用技术解决所有问题。”

到目前为止,KPI 得到了改进,传统的 IT 服务指标(如周期时间和 SLA 违规)有所减少。通过在 API 设计中使用更好的架构方法,开发团队已经超过了 250% 的并发请求性能目标。

将 IT 的形象从黑盒交易功能转变为业务合作伙伴并非易事。但 IT 与其利益相关者之间不断增加的对话正在推动 Inteleos 的发展。 “与以前相比,我们正在产生更大的战略影响,并在更宏观的层面帮助指导组织,”桑切斯说。 “小心地将对话视为协作而不是处方,这一点很重要,这是大多数技术团队需要培养的技能。”

领导建议:愿意在人才方面发挥创造力。 “没有这种成分,世界上最好的架构就会失败,”桑切斯说。 “我们必须快速了解在哪里找人、在什么技能水平上以及在什么类型的参与中最适合系统在任何给定时间的要求。”

桑切斯也同意,首先,敏捷是一种心态。 “它必须首先存在于技术团队的头脑中,然后让这种思维方式渗透到我们与业务互动的方式中。通过这些互动,您将看到业务中体现出的敏捷性,”Sanchez 说。 “如果作为一个团队,我们无法构思超出我们面前的想法,那么我们注定要保持交易性。”

本文:https://cio.ceo/streamlining-it-agility