跳转到主要内容

新闻中心

News Center
业务服务VS产品思维

业务服务VS产品思维

2020年5月20日 593次admin

多年前,我曾受邀作为ITIL 3.0版初稿的审稿人,记得我甚至在度假时都不忘随身携带业务策略手册,我太太正沉浸于爱情小说动人心弦的情节中,不明白区区一本“技术手册”何以令我如此兴奋。最终,作为业务策略专家,我提出了大量审稿意见和建议,但其中大部分并未被采纳。

 

但我记得在业务服务思维的时代拉开序幕后不久,“数字化时代是否仍然需要业务服务思维”的问题便应运而生。这正是我最近在和一些CIO和意见领袖的对话中国向他们提出的问题,对于IT价值链各个环节的参与者而言,他们的答案颇值得玩味思索。

 

数字化时代是否仍然需要业务服务思维?

 

毫不意外地,这个问题并没有唯一的答案。担任CIO的Rick Osterberg是给出肯定回答的人之一。他表示只要存在业务价值,就几乎可以确定有IT作为支撑,无论是否以数字化的形式。前CIO Tim McBreen也表达了相同的观点,他补充道:“一旦将IT方法调整为运行—成长—变革模式,(与业务方法相对应),IT工作便将驱动业务价值。运行意味着保持工作状态,成长意味着在现有组合基础上新增,而变革则提供全新的价值。”

 

分析师Dion Hinchcliffe则持不同观点,他认为:“ITIL模型已经不再适用(充其量是曾经适用)。ITIL的一些部分还是有可取之处的,应当取其精华定义一个基于价值的IT模型。我们并不缺好的框架,实际上,前不久我和许多ITSM经理坐下来,以现代客户体验、自助服务和设计思维为基础,重新思考了ITIL实践。” 此时,Osterberg进一步发言“欧林工程学院的重点是敏捷和sprint,我从来没有把ITIL看作是一个严格意义上的模型,而是工具箱和词汇库。对于任何IT组织而言,完美的模型都是不存在的。成功的诀窍是有效利用各种适应不断演进的环境的工具。”

 

作为回应,Hinchcliffe坦言:“干得漂亮!在很多地方,ITSM曾经是,并且现在仍严格保持IT/ICT的正统概念,从我的实践经验来看也不怎么好用。”Dion接着谈到:“个人观点:影子IT已经庞大到必须将其视为一个完整的ITSM机会,但目的并不是将其彻底摒弃,而是打造成一个性能优越的创新池和缩小服务质量差距的策略。”担任CIO的Milos Topic表示赞同:“对于越来越多的组织而言,IT已成为业务不可或缺的一部分,一个真正的伙伴和领导者,由此可见,IT的重要性不言而喻。技术以多种多样的方式将几乎所有功能领域联系在一起,为其赋能,助其创新,提供驱动力和支持。”

 

随着IT向数字化产品转移,项目组合和服务管理思维的原有价值是否继续存在?

 

Forrester的分析师Charles Betz称:“这个问题很难回答,因为这直接催生了一个语义问题。服务(service)和产品(product)是否有意思上的差别?在一周之内我听到过以下两个表述:1. 我们从产品转向服务模式;2. 我们从服务转向产品模式。只要组织理解人们使用的定义之真正内涵,两种说法便都讲得通。如果产品仅仅指作为商品的软件,那么服务将更受欢迎;如果服务意味着初级的技术层面工作,那么产品无疑更具吸引力。ITSM 和SOA在定义上的意见不统一由来已久,也在这个问题上起到了推波助澜的作用。”

 

Hinchcliffe说:“只有产品没有服务是不可能的,但除非把服务视为产品,否则就不可能有好的服务质量。”关于前述问题,Hinchcliffe回应:“是的,项目组合和服务管理仍然有价值,但面向运营和产品化的趋势日益明朗。” CIO David Seidl赞同Dion的意见,他提到:“我们在线指导规模的大幅增加,以及应对会议、软件电话和协作技术增长的方式,为之前从未经历过在家办公的人们提供远程支持,甚至是远程工作解决方案的重建。这全都需要规划和运行。我们必须为所有这些——及其集成——提供支持。我们要了解它们的生命周期,以及与其他运行中的项目产生哪些交集。没有全局眼光就意味着失败。”

 

但其他CIO的视角有所不同。Topic表示:“有效管理项目、项目集和项目组合至关重要。此外,提供阻力最小化甚至畅通无阻的客户体验也不可或缺,这一点不会改变”。Martin同意这一观点并补充道:“我看到了前所未有的价值,当然,价值不可能变魔术般凭空产生,我们必须搭建相应结构去挖掘价值。”前CIO Joanna Young也表示认同,她说:“应当削减组合管理的精力和成本,随着优先事项愈来愈明确,项目数量和复杂化工具都将精简。更少的跟踪和监控,更多的决策,归根到底该做的工作要完成。关于ITSM,我们需要在DevOps构建中走一条以客户为中心的ITSM之路。”这个想法具有重要意义,为接下来的讨论奠定了基础。

 

产品方法以DevOps为导向,是否意味着规划-建造-运行模式已退出历史舞台?

 

Topic称:“最佳实践和建议一直存在,但并非在任何时候均适用于一切组织、一切技能和一切文化。重要的是立足现实,并与目前状况和未来理想状况保持一致”。与此同时,McBreen坦承自己“博采众家之长,从每个最佳实践中取其精华,打造在现实中对业务和IT均行之有效的实践。我发现每个新的最佳实践大多基于已有的最佳实践,只是添加了一些新词汇,作了一些细微调整。我尽量不追求标新立异”。而Seidl则表示自己“很不幸有一些古老的IT遗产仍然要保留。只要条件允许,我们尽量应用敏捷方法。至于关键的下一步,从DevOps到DevSecOps意味着重要的渐进发展。即使如此,我尽量避免像化石收集者一样拘泥于古老的遗产,只要有机会,我就尽量将墨守成规者排除在外。但出于财务、合规要求、特殊需求,以及任何合理合法却让人沮丧的理由,在某些方面我们不得不维持现状。”

 

Betz和Seidl同样坦诚:“我最近负责审阅一些大公司的IT政策框架,这些框架中暗藏的瀑布数量之多让我震惊。分层的假设——大批量build在上线之前需要详尽无遗的清单检查(checklisting)——必须停止,以此为基础的监管、风险和合规策略也需要变革”。Dion赞同Betz的说法,认为敏捷将与DevOps联结,而DevOps将与DevSecOps联结。他接下来关注的重点是AIOps和AnalyticsOps。

 

产品思维方法是否需要CIO个人的颠覆性改变?

 

Milos相信:“不仅仅是CIO的团队,所有团队都需要调整,但具体变化将取决于过程中团队扮演的角色和作出的贡献。并不一定是颠覆性变革,而是变化、调整、演进和进步”。Seidl表示同意,但他同时提出:“这是我们工作的一部分,我们必须避免固步自封,满足于最熟悉的模式。我们的职责是响应组织需求并帮助组织找到妥善的解决方案和前进道路。”

 

McBreen认为:要成功实现这一点,需要“向组织注入新鲜血液,让能够挑战旧有习惯和旧有模式的新人加入,这一点对于IT团队和业务领导团队均适用,我加入过的最优秀的组织都经历过领导层和董事会成员变更,给我鼓励也向我提出挑战”。Seidl认同“勇于唱黑脸,有健康的行动习惯的团队必不可少”,这一点与管理理论家Gary Hamel提出的“管理实践需要脱胎换骨的改变”不谋而合。Hamel认为“向长久以来稳坐权威位置,扼杀创新的管理模式发出挑战,此时不动更待何时”。Dion与Hamel也所见略同,他表示“CIO亟需成长、演进和彻底转变为战略业务领导者,这或许是2020年IT界的头等大事。而产品思维正是其中的一部分。”

 

结束语

 

显然,林林总总的框架和产品思维等新方法的采纳正令CIO们绞尽脑汁。许多人正在尝试并最终证实有效的方法——包括产品管理思维方法在内——从来不是自古华山一条路。当然,对新事物保持开放态度的CIO取得显著进展并愈来愈成熟。

 

 

The Open Group推荐阅读

The Open Group正式发布《ArchiSurance案例研究,版本 3.1》

IT4IT™ 标准助力打造更智能的 DevOps 文化