今年 3 月中旬, 随着美国普遍要求人们保持社交距离, LogMeIn 公司的 IT 部门注意到了一些变化. LogMeIn 为那些不在办公室工作的员工提供远程访问和对视频会议软件 GoToMeeting 的支持, 因此对于这种情况的出现并不感到惊讶. 但是, 远程工作需求如此的急剧增长还是带来了一些挑战.
LogMeIn 的首席信息官兼高级副总裁 Ian Pitt 介绍说:"IT 部门负责我们客户服务和销售部门的所有联络中心. 我们注意到我们的呼叫队列变得越来越长了." 他说, 最重要的是, 有些主要的指标显示, 销售将大幅上升.
必须行动起来, 而且要快. Pitt 与负责全球销售, 业务运营和客户服务的高级副总裁们进行了交流. 他们 4 人每周召开一次会议, 并设立了一个 Slack 渠道, 专门处理与新冠病毒相关的激增需求. 这既是问题也是机遇, 需要把技术和非技术解决方案结合起来才能应对. Pitt 说:"我们一直在跟踪全球的产品销售情况. 这相当于要求 IT 部门对所有客服中心基础设施进行检查." 当时, 和很多客户一样, LogMeIn 刚刚将其客户服务部门调整为居家办公, 这给公司带来了一系列挑战.
客户服务高级副总裁报告说, 很多打给客服中心的电话都是来自非常失望的客户, 他们想尽快购买更多的许可, 但由于来电太多, 无法接通销售部门. 为了解决这个问题, 新冠病毒需求响应部门着手将公司的销售队伍从大约 800 人增加到约 1000 人左右.
这些新来的销售人员中约有 60 人以前在其他领域工作, 自愿转到销售部门工作. Pitt 解释说:"当我们让员工居家办公时, 我们不想解雇任何人, 我们的很多员工以前只在办公室工作 -- 从前台到咖啡师, 等等. 我们为他们提供了接受销售技巧培训的机会, 他们中的很多人都欣然接受了."
IT 部门增加了电话容量, 并为新的销售人员提供了所需的软件许可. 总的来说, 公司在不到两周的时间里就部署好了新扩容的销售队伍. Pitt 说:"我们看到客户服务量开始下降, 因为线上有更多的销售人员来处理更多的客户电话. 情况逐步趋于平稳, 没有再出现尖峰."
虽然他们可能没有使用这个词 -- 携手创造(co-creation), 但这是一个完美的携手创造的例子, 业务部门领导和 IT 部门领导齐心协力, 平等地工作, 共同确定, 定义并解决业务问题. 专家们说, 携手创造是业务部门和 IT 部门关系发展的下一个阶段. 曾经的 IT 领导成为订单接受者, 按照业务部门的要求进行交付. 他们变成了同事, 在确定业务问题时相互倾听, 相互学习, 然后找到解决问题的方法. 但要实现最大价值, IT 部门还必须帮助确定和定义需要解决的业务问题, 而不仅仅是解决这些问题. 在技术能够提高利润并创造竞争优势的世界里, 这是重要的下一步.
Gartner 首席信息官研究小组研究副总裁 Monika Sinha 表示, 并不是每家企业都准备好了这样做. 她解释道:"部分原因在于文化, 在这种文化中, 技术的运用使得我们超越了专注于交付设备和应用程序的旧工厂模式. 企业必须将技术视为一种战略能力, 而不是需要进行成本控制和管理的东西. 一旦我们理解了这一点, 我们作为企业就可以开发运营模型, 因此我们将用于携手创造的人员, 流程和工具."
如果你认为自己的部门已经准备好了, 那么需要做什么才能与业务部门携手创造呢? 下面是一些经验之谈.
以产品为中心的敏捷方法
携手创造经常和敏捷一起被提及.
利宝互助保险公司 (Liberty Mutual Insurance) 首席信息官 James McGlennon 说:"敏捷是携手创造的必要条件 -- 它是第一要素. 需要由业务人员和技术人员组成的团队一起工作, 分清轻重缓急, 并理解他们所做的工作会产生怎样的影响."
利宝公司推出的 Workgrid 便采用了这种方式, Workgrid 是一种数字助理, 可帮助员工完成提交开支报告以及检查他们及其直接下属的休假情况等任务. Workgrid 是由公司的人力资源和 IT 部门携手开发的, 最初被认为是利宝公司 5 万名员工的内部工具. 他说:"现在它本身就是一家公司."
ERP 套件有很多好处, 但不太容易收集, 汇总和分析供应链和物料需求数据. 解决之道在于基于云的供应链解决方案.
Gartner 的 Sinha 说, 携手创造还可以引导部门朝着产品而非项目的方向发展. 她说:"当我们开始谈论携手创造的时候, 意味着我们不再单独地交付技术, 而是将其作为更像产品的东西进行交付. IT 产品的定义是在业务中拥有技术和转型的能力. 一些业务流程或者客户体验之所以出现了改变, 是因为我们把一些技术交给了客户. 我们正从通过自动化和工具实现业务数字化, 转向切实增强或者提供客户需要的产品和服务."
扁平化, 多样化,"双披萨" 团队
IT 创立伊始, IT 高管和他们的业务伙伴就一直以跨职能部门的形式一起工作. 是什么让携手创造与众不同?
埃森哲首席信息官 Penelope Prett 表示:"传统上, 我们有业务部门和 IT 服务部门, 我们通过配备的技术人才来解决问题. 这使得 IT 部门和业务部门只能针对眼前的问题就事论事. 这既高效又有效, 但并不是每次都能帮助你实现新的价值." 对于携手创造, 她说,"你寻求的是扩大自己的业务范围, 以创造新的净价值. 所有部门都在朝着一个完全相同的目标努力, 那就是让公司变得更好, 让自己与众不同." 她说, 要做到这一点,"你要与自己的业务伙伴建立一个亲密的, 扁平化, 多样化的工作团队, 鼓励发表各种观点."
这种方法催生了 ALICE(Accenture Legal Intelligent Contract Exploration), 这是 IT 部门和公司法律部门携手创造的成果. ALICE 今年获得了 CIO 100 万, 利用人工智能来搜索公司数以万计的客户合同, 找出有问题的条款, 并帮助埃森哲 2800 名律师了解公司对客户应尽的义务. ALICE 还能让公司发现其所服务行业的发展趋势.
Prett 说, 在组建一个携手创造团队时, 最重要的是要包括各种级别的员工."会有一位资深的业务领导, 但我也会鼓励他引进同一领域非常初级的员工."
几年前, Prett 在一次客户研讨会上学到了这一点, 其中 1 人刚来公司三天, 还是 1 名非常初级的员工. 在讨论一个面向客户的解决方案时, 这位年轻的女士站了出来."我不会那样做的. 如果是和银行谈判, 我会这样做."Prett 回忆说, 研讨戛然而止. 她说:"她其实是站在消费者的角度, 她成长在技术唾手可得的环境中. 如果没有各个级别的员工和各个业务部门的员工参与, 就不可能发挥企业的全部力量."
但是, 即使应该包括不同级别的员工, 一个携手创造团队的规模也应该很小. Sinha 建议遵循 Jeff Bezos 的 "双披萨规则", 即每个团队都应该足够小, 两个大披萨就够了. 胃口, 披萨和配料可能会有所不同, 而遵循这条规则, 建议携手创造团队的成员人数最多应为 8 人, 至多不超过 10 人.
Sinha 说, 实现这一目标的一个方法是让员工们不要再依附于团队中的某个特定角色."当我们谈到携手创造团队时, 业务和 IT 部门并不是按照他们所扮演的角色来划分的, 他们只是以不同的身份开展工作. 会有同时也是业务架构师的开发人员, 还有参与共同开发的业务人员 -- 因为他们可以直接使用技术来开展工作. 团队成员不一定有什么头衔, 也不用交付特定的技术. 他们要做的是实现客户体验."
平等基础上的 IT
携手创造是行不通的 -- 那些曾经这样做过的人说, 除非 IT 领导与其他业务领导完全平等. 利宝公司的 McGlennon 说:"我直接向首席执行官汇报." 他补充道, 这种报告结构实际上表明 IT 再也不仅仅是订单接受者了. 事实上, 他的公司以这种方式看待 IT 已经有很多年了, 他说他几乎记不起那些担任支持角色的日子了. 他说:"我们已经从订单接受者变成了服务提供商, 值得信赖的合作伙伴, 再变成了把握机遇的批判性思想家."
让首席信息官直接向首席执行官汇报是成功携手创造的先决条件吗? 他说:"不, 但也无妨."
应用与外包公司 CGS 负责数字化转型与创新的执行副总裁 John Samuel 表示:"除非把首席信息官和 IT 提升到与其他业务职能相同的位置, 否则携手创造是行不通的."Samuel 曾是该公司的全球首席信息官. 他说:"大约一年半前, 我们创建了这个新角色." 当时, 他和首席执行官都认为, 作为业务部门合作伙伴的最佳方式是将这一角色与其他 IT 角色分开. 因此, Samuel 聘请了一位首席信息官来填补他原来的角色, 并创建了一个全新的团队.
他说, IT 领导应了解业务领导所面临的挑战, 反之亦然."业务部门的人员可能会认为某个想法不错, 但不知道其中的挑战. 技术部门的人员也会认为某个想法不错, 但不知道其中的细微差别."
考虑到这一需求, CGS 于 2019 年召开了一次峰会, 约 40 名来自公司各部门的 IT 和业务高管参加了会议, 目的正是要建立这种对话机制. 这导致了一个在公司各个领域使用机器人过程自动化 (RPA) 的大型计划. 其中一个被称为 "转椅(Swivel Chair)" 的项目解决了这样一个问题, 即呼叫中心坐席不得不在多个系统之间频繁切换以回答客户的问题, 这经常会产生错误. Samuel 说:"我们使用 RPA 来研究不同的系统, 并将信息整合在一起."
转移项目的最初想法来自 IT 部门和业务部门领导们在峰会上的对话. 他说:"作为 IT 领导, 我们很少这样做. 我们等待请求的到来. 业务部门有时真的很有远见, 但他们不知道我们能做什么. 我们应帮助他们让一切皆有可能."
来源: http://news.51cto.com/art/202010/629285.htm