当前位置:CIO新闻中心 → 正文

数字化助力IT团队运营效率提升

责任编辑:cres |来源:企业网D1Net  2023-02-26 12:42:34 原创文章 企业网D1Net

2月26日,由企业网D1Net、信众智(CIO智力输出及社交平台)和中国企业数字化联盟联合主办的2023全国消费零售CIO大会在上海召开。本次大会围绕“企业承压,IT怎么干?”这一主题,分享交流CIO在新的环境和形势下的前沿实践与现阶段的困惑,探索数字化技术在消费零售行业的落地场景与未来发展方向。
 
以下是现场速记。
 


卓尚服饰CIO 桂益龙
 
桂益龙:今天非常开心,感谢范总的邀请做这场分享。
 
其实我觉得第一场刚开始的时候,王总在非常宏观和生态层面谈了他的看法。我觉得宏观是我们需要去看清楚的部分,但是今天我的分享更多是站在微观的层面去看,我们到底能做些什么事情。就像范总讲的我们的主题IT能做什么?
 
我们另外还有一个视角,IT部门始终是会去说我们能不能帮业务部门去做些什么事情,能够为业务部门做一些赋能?反过来我在这两年一直在思考,数字化能帮我们IT部门自己能不能提升我们的运营效率?如果自己都不行,还能说你帮别人吗?
 
我最近在这一段时间一直在思考并且也做了一些实践,所以趁着这个机会来跟各位做一个汇报。
 
我们会去分析看,我们在为业务部门数字化赋能方面,我们会帮助业务部门,不管是在零售还是在刚才讲的会员运营,或者是说我们的商品运营,在我们的销售到我们的供应链甚至人资和财务,我们都希望在各个方面帮助业务部门进行数据化、数据分析、找出问题,得到改善提升运营服务。
 
但是你会发现IT部门就不是这样,大家每天忙于日常运维。可能会因为一个工单没有完成,我们被业务部门投诉,或者因为一个需求没有及时交付,被业务部门表示不满。在项目管理方面是否能够很好的按期达成保质保量?包括我们的IT资产是否我们真正能管到每个人、每个IT资产的运营状态,整个全流程、全过程的管理?
 
以及我们IT部门在整个过程当中,我们会需要很多知识解决问题,我们这些知识是否得到沉淀?这个都是打问号的。我了解到我们很多还是用excel表管工单、需求、项目管理、IT资产,或者有些零星系统或者有着单独的工单系统去零星的管。所以我们IT部门很大的状态是手工化的,是零星的在管这些事情。
 
我们还是想站在业务端来看IT部门,我们IT部门在我们业务端里它应该是什么样的形象?我认为至少有三点。第一点是IT部门应该是很专业的,在IT方面;第二个方面我们是非常有态度的,业务部门对我们的满意度是比较高的;第三个方面是我们还要追求效率。我们不可能把我们团队永远越做越大,有可能的话用最少的人去完成更多的工作。就像刚才飞书郑总分享的,IT部门是叫效率工程部。效率工程部帮业务部门提升效率,IT部门的效率在哪里?有没有数据化进行展现?
 
所以如果从专业层面来讲,整个IT服务流程是否是规范的是否是高效是否是透明的是否是能形成闭环管理的?我们的客户满意度,我们在服务整个过程当中能够随时的了解客户对我们的态度以及最终的评价。
 
这是我们要去思考的部分,我们在想我们要专业,我们在软件研发里面的CMI就是成熟度,整个IT运营依然是有成熟度的。我们可以把成熟度分为五级:第一级是初始级(有工单就派人搞定),第二级是已管理级;第三级是已定义级,如果能做到定义级,我们所有的流程都是有标准流程和服务的,它能实现闭环管理的;作为IT管理人至少要达到三级,这样才对自己有个交代。第四级是量化管理级,第五级是优化管理级。
 
我们本身怎样提升业务效率或者工作标准?第一个是ITIL,它本来是个国际组织提供给我们作为IT服务里面的标准的组件。在这里应该是有34个组件,我大概把它归归类,有规划层面的,有执行层面,有服务层面,有效率层面的。这是我们做IT人去思考的,其实我们是有服务标准可以参考的部分。
 
第二部分是项目管理。我们会做很多项目,希望这些项目赋能我们的业务。其实项目里本身就有九五至尊,九大知识领域五大过程,我们第一能不能及时按项目当初规划的要求完成项目?这样我们在下面整个过程当中是否规范的推动,且能不能让这些知识得到沉淀?以及未来得到复用。这是关于项目管理。
 
作为IT主管或者IT人来讲,我们每天的工作,我们整个工作到底是哪一些?我们可以稍微划分一下。在我们整个分析里面,在左面部分是规划层面,右边部分是我们IT人要日常运营的部分,一个是规划一个是运营。
 
在规划层面,我们是会分几步去走。第一步是业务分析,第二步是服务组合,第三步是战略规划、架构设计、组织规划和IT运算。怎么去看?刚才王总讲我在业务层面我会要做一些创新,比如我要做预制菜,把它做强做大。
 
我的业务有变化了,或者我们从批发转向零售,从线上要加上线下,这些都是叫业务分析,我们发现业务有变化了。作为IT人要对服务组合进行调整,原来只需要批发系统,现在需要门店数字化的系统。原来做的是线下可能要更加注重线上更加注重会员系统,这些都是服务组合的调整。是因为来源于业务变化,所以需要调整服务组合。
 
有了这些东西才会谈到IT规划的调整。可以这样讲当我们业务没有变化的情况下,我认为IT规划每一年抄下去就可以了,因为业务没有太多变化,所以不需要调整太多的IT规划。有了这个东西之后,我们会再一步调整架构,我们要上什么系统。所谓组织规划是向公司要多少人,原来20人,现在需要增加5个人,这5个人专门针对会员运营的,组织要进行调整,接下来是IT预算。
 
所有起点来源于业务分析,但是这个事情第一是IT主管要做的,第二我认为大家都是行业专家,我认为一个月搞定了或者年底搞定或者年初把事情搞定了。我们更大部分的工作应该是在我们的日常运营,我们又把这些工作分成几个部分,第一部分是基础设施,电脑网络这些部分。然后是服务工单以及我们原有系统的需求变更,再往上是我们项目管理,另外还有是我们和业务部门陪跑做业务运营。
 
我认为每一个项目我们最终要拿成果一定要和业务部门陪跑,我深知认为在刚开始在这一项目里,我们是教练,业务部门是学生。因为这个工具,我们一定比业务更熟。我打个最最简单的比喻,在我2021年10月份之前我在羽绒服公司工作14年,2021年10月份来到杭州卓尚服饰,我很惊讶的发现我们竟然没有做O2O,但我们要开始推动的时候我们是陪着业务部门开始做O2O的操作手册,做O2O培训、奖励制度、规划,每周陪着他们一起去看我们O2O的运营数据,这些都是业务要做的,实际这部分是最能拿成果的部分。
 
在分析业务之后,我们就可以开始想我们该怎么干,我们怎么去把我们的业务进行数字化。我认为这部分不是太需要数字化的,可能用一张PPT就能搞定的事情。但是灰色部分是可以做数字化的,因为它是长期的循环的每天每周每日每月都要去做的事情,业务运营成果也是要的,但是我正在考虑怎么让它数字化。
 
所以我大概捋了一下,我们作为IT来讲,我们自己来讲怎么样数字化?大概是哪些内容?
 
第一项内容是日常服务。日常服务里面,第一项要做的事情第一把服务要进行清理,生成我们的服务清单。我们到一家餐馆点菜一定要有菜单,作为服务人员需要服务目录。第二针对不同的服务目录要制定不同的服务标准,你是去修个电脑还是响应个需求,我相信这个时间肯定不一样,或者你是开个邮箱,开个邮箱估计5分钟就搞定,修个电脑可能需要半个小时或者多长时间。
 
我们有服务目录,有服务标准,然后我们还希望我们的用户能够再查询到我们的服务,就像我们电商下订单要看得到有没有拣货、发出,我们也希望用户看到,最后服务得到用户的评价。
 
第二部分作为IT来讲一定会遇见的事件和故障,每一个事件和故障都希望得到记录、复盘。当我们下次遇到同样的事件或同样故障的时候,我们能够快速的把它处理掉。
 
接下来关于需求变更,我们如果公司规模比较大,可能一年有上千个需求,当然小的可能一两百个需求,我相信一定是有的。这些需求第一发起完了之后有没有方案?有没有得到业务部门的审批、通过?我把这些需求派给哪个开发的同事?哪个测试的?最后有没有发布,发布有没有成功?如果没有成功,没有成功的原因到底是什么?要进行全过程的记录。
 
接下来是项目管理。从项目准备、建设、上线运营以及我们的运营维护,这一部分我们也希望得到全程的记录和进度的管控以及最后形成我们IT资产。
 
最后要形成知识管理,知识来源于工单、需求、项目、事件和故障处理。
 
这个是我花了一年多的时间,我们自己部门自己开发的一套ITBOS系统,IT的运维系统。这个是我们整个IT部门用这套系统来管理我们的日常业务,在这套系统里是包含了基础管理、IT资料,IT资料包括所有的人员、服务目录、服务标准都要在这里设置,工单管理、事件管理、故障管理、需求管理、实现管理、发布管理、项目管理、资产管理、备件管理、知识管理以及统计分析报表。这三项就是一个项就是知识管理,但是我们要把它细分。
 
这个是框架,我们进入系统之后知道这是我们的界面,可以看到工单、事件、故障、需求以及IT资产大概的整体情况。
 
接下来我快速把每个模块进行简单的介绍。
 
第一块是关于工单管理。业务部门所有的工单提交的话直接扔到服务台,在服务台里,我们可以用派单模式也可以用抢单模式。提交完之后进入工单池,然后接单然后进行过程跟踪,甚至可以跟踪到一线、二线、三线、四线,有的工程师基本上一接单都能处理掉,有的工程师要转单,因为能力不够,我们要去记录下来。当然有的可能还会转三线、四线,所以进行跟踪管理,完成之后最终用户要评价,评价完之后要形成知识沉淀。所以在这里整个工单形成了管理闭环。
 
在这里会记录每个部门每个用户所提交的工单,我们也会记录每个工程师什么时候接单,什么时候完单,最后用户打分评价。
 
再一个是事件,所谓事件是未来要形成故障可能的那些东西。比如说我们的CPU,我们使用率已经达到80%了,再往上负载高的话系统要卡掉了,这是事件。比如硬盘容量已经使用了80%了,我们再往下可能也跟系统一样。所以我们要把这些事件记录下来。
 
而且我们可以通过事件的登记,可以看到我们工程师有没有监控,如果一年到头没有这个事情,这是不可能的事情,一定会有事件发生。如果很好的把这些事件进行登记处理形成我们知识沉淀之后,它一定会预防我们的故障。所谓的故障就是整个系统不可用,整个系统就挂掉了。说实话我们在去年一年我们自己公司也遇到两三起的故障。
 
这些故障第一我们要登记,第二我们一定要把它快速处理,还要分析原因,然后是解决方案,形成我们的知识沉淀,中间我们还要做可用性分析。因为我们经常会说我们做IT部门,我们要保证业务运营系统,可用率是99.9%,我们的数据呢?如果我们没这个登记,没这个数据,那只是拍脑袋或者跟领导吹牛而已,如果有这些数据完全可以跟领导去讲,我的这个系统我们今年可用率是100%,因为这套系统从来没出过问题,那套的可用率是99.6%,我们中间发生过一个问题,停机了一个小时。我想这个都是我们可以量化的工作。
 
接下来是需求。第一部分是当我们业务部门提交需求之后,一般正常来讲会有内部的业务顾问,对接业务顾问,给他做方案,我大概多长时间完成,给到之后要业务主管审核,这个非常关键。
 
以前我们曾经遇到过业务主管都不知道下面提了需求,结果我们改了发布上线之后,业务主管说怎么改了?他说我是主管我们怎么不知道?我们有了这样的规划方式,可以更好的合理控制这些需求,而且能保证这些需求得到落地。
 
我不知道同事有没有遇到过这种情况?最后这个需求改完没人用,因为没有得到业务部门主管的确认,也没有审核推动这个事情,他认为这个东西不重要。我们希望完成这个需求之后,用户进行打分评价,最后形成我们的知识。
 
这个是从需求提交到审核的过程,我们现在需求还有一个实现的过程。很多公司用的都是接纳,就是做需求管理。在需求管理里,需求完了之后我要派工,然后我还要做测试,有没有测试,有没有OK。过程当中,我们还可以做工作量登记,满足这个需求的时候,我们哪个公司有多少工作量?以及我们在测试的过程当中还可以看得到我们到底开发完给到测试,给测试人员打回来多少次,我们通过这个是可以知道每个开发人员的开发质量是多少。
 
当我们一个部门开发人员有20个的时候,实际是很难知道每个开发人员的真正开发质量。如果没有数据,只能是拍脑袋感知这个人大概水平可以。什么叫水平可以?如果真的有这些派工资料、测试数据,我们的完工工单情况,而且当初我们讲这个需求开发需要5天,最终交付的是5天还是6天还是几天?我们也可以看到他的整个效率是多少。
 
测试完成之后我们就会进到发布池进行发布,作为系统进行发布还是非常重要的。第一有的发布是不需要停机,有的发布需要停机。如果我们的发布需要停机,而业务部门不知道,业务部门认为是个故障,系统坏掉了,因为他不知道。所以做IT系统来讲,当我们真正要停机的时候一定要通告我们的业务部门,我大概是在晚上的10点到12点,我要停机发布我们的系统,甚至发布完之后我们告诉一声发布成功大家可以正常使用了。
 
只有这样才能表现出我们作为IT人是非常专业的,要不然他不知道,他什么时候系统不能用,他不知道到底是真正系统挂掉还是你在发布一个系统。而且我们在发布之后,还需要去登记,发布有没有失败还是成功。因为我们只有这样才能知道到底我们的交付质量是什么。我以前一年总归好多次发布失败,我们要去做回滚。
 
接下来重要的一块是关于项目管理。我们讲项目管理本身有九五至尊,以我现在的经验我们只需要四个阶段,第一个阶段是项目准备,就是到项目启动会开始之前都叫项目准备,包括项目合同、项目章程、项目启动会等,大的项目应该有这些流程,小的项目可以没有。但是有的东西一定要有,包括项目组成员、项目计划,甚至开项目启动会也可以,一个项目至少有两个必须要有的。
 
我们在项目实施阶段一定会有需求调研,调研完了之后需求规格说明书以及我们的设计或者蓝图,详细设计,我们的开发文档以及我们整个功能实现,最终下面的是叫用户接收报告。用户接收非常重要,如果一个系统在上线之前没有用户接收报告,未来上线不成功,可能只能IT部门自己一个人背了。如果有了我们业务部门的上线验收报告的话,如果不成功,至少来讲有50%是业务部门跟我们一起背的。我相信通过这种方式可以让业务部门更加非常重视这个项目,非常重视这次上线。
 
上线前还需要一系列的动作,包括上线方案、上线发布、上线通知、操作手册、培训记录、上线数据准备以及上线报告。甚至有的时候上线之后发现有人不会做,你可以说有操作手册、培训记录。
 
上线方案也很重要,因为上线前会牵扯到业务很多的调整,比如说上一些大的项目的时候,甚至我们的仓库、物流包括生产方面都要做调整,包括财务都要做调整。我们以前上一个大项目的时候,我们财务提前五天结账,我们停止五天原副材料领清,为了盘清原副材料等。上线一定会有问题,出上线清单,最后验收总结。
 
不是每个项目都要这么去做,这些东西可以裁减,我这个项目如果是小项目,我哪几个阶段需要,或者我的项目比较大,哪几个阶段是比较需要的。最大的区别是有的是外购项目,有的是自己内部的项目。外购项目有项目合同,内部就没有项目合同。
 
接下来是关于IT资产,我们有一系列的动作。包括我们的资产入库、资产领用、资产归还、维修登记、更换登记、资产盘点、报废、处置,它是有一系列这些动作的。
 
包括我们备件,IT部门有很多备件。我们的备件到底用哪里去了,有时候说不清楚,如果有备件台账就可以知道备件的用法,或者有了台账之后发现我们的备件不需要用那么多。
 
最后我们是知识管理。知识管理不是单独做的知识管理,而是在各个阶段让它沉淀下来的。比如工单、事件、故障、需求和项目管理,这些所有的动作都是有很多东西自然而然就形成了我们的知识。
 
举个最简单的例子,我们在前一段时间发现我们BI服务器突然卡住了,怎么办?要不然换服务器,换服务器来不及,后来我们就查知识里发现把服务器关掉,把两颗CPU拔下来重新兑换开机就OK了,如果没有知识管理,我们肯定是不知道的。我只是举这个小例子,实际知识管理对业务服务效率提升是有帮助的。
 
我们还是做了两个面向用户的移动端,这一块我们放在钉钉上,当然也可以放在飞书上。我们作为用户来讲,它在手机端可以提交它的需求,提交工单管理个人的IT资产以及我们的需求提交,所以我们用户部门可以提交需求、查看进度、评价服务以及知识应用,可以自己做知识转出或者知识转入确认,以及他提交需求、评估需求、审批以及交付之后的评价。
 
这是移动端,我们在PC端也做了一个,提交工单、需求以及知识查询。其实对用户来讲很简单,刚才那个复杂的管理都是给IT部门要去使用的。
 
我想作为IT主管来讲,我们可能重点要关注哪几部分?
 
第一部分关注异常。我的工单有异常,我的需求有异常,超期了,我的有事件、有故障,我的项目我要关注这些异常。第一个要关注异常。
 
第二个关注效率。IT自己部门的效率,要看到接单、完单、转单的情况。
 
第三个是关于客户满意度。客户对我们的评价到底是什么?
 
第四个是综合分析。
 
我们一年做下来之后我们作为IT部门自己的成果是什么?我们通过数字化运营是不是有进步了?以工单举例,工单接单时间原来需要2.9小时,现在需要1.3小时。完单时间也缩短了,原来基本要平均3.98个小时才能完成一单,现在只要2.15个小时以及最终客户满意度,我们是五分制,如果客户不打分不评价就是四分,客户主动打分评分,我们会加上去,我们整体下来是4.2几分,其实也是不容易的。
 
因为我们效率提升之后,我们花了比较多的时间和业务部门陪跑。所以我们在其他项目方面,我们其实帮助业务部门实现了比较好的业务价值。比如说我们在机器人项目里面,我们和电商的一个部门就用机器人一年替代40几个人的工作人天。
 
作为数字化部门来讲,业务部门有那么多数字化,作为IT部门应该也有这么多数字化,去管控我们异常,提升我们效率。我认为IT和业务就在一条船上,我们要把业务部门从这边渡到那边,我们自己也要做,所以我叫做自渡&渡人。
 
我们要做有专业、有态度、有成果,做业务和领导信赖与尊重的IT人。对我们感兴趣的甲方,请扫那边,乙方同学请扫这边。
 
非常感谢大家!

关键字:数字化转型

原创文章 企业网D1Net

x 数字化助力IT团队运营效率提升 扫一扫
分享本文到朋友圈
当前位置:CIO新闻中心 → 正文

数字化助力IT团队运营效率提升

责任编辑:cres |来源:企业网D1Net  2023-02-26 12:42:34 原创文章 企业网D1Net

2月26日,由企业网D1Net、信众智(CIO智力输出及社交平台)和中国企业数字化联盟联合主办的2023全国消费零售CIO大会在上海召开。本次大会围绕“企业承压,IT怎么干?”这一主题,分享交流CIO在新的环境和形势下的前沿实践与现阶段的困惑,探索数字化技术在消费零售行业的落地场景与未来发展方向。
 
以下是现场速记。
 


卓尚服饰CIO 桂益龙
 
桂益龙:今天非常开心,感谢范总的邀请做这场分享。
 
其实我觉得第一场刚开始的时候,王总在非常宏观和生态层面谈了他的看法。我觉得宏观是我们需要去看清楚的部分,但是今天我的分享更多是站在微观的层面去看,我们到底能做些什么事情。就像范总讲的我们的主题IT能做什么?
 
我们另外还有一个视角,IT部门始终是会去说我们能不能帮业务部门去做些什么事情,能够为业务部门做一些赋能?反过来我在这两年一直在思考,数字化能帮我们IT部门自己能不能提升我们的运营效率?如果自己都不行,还能说你帮别人吗?
 
我最近在这一段时间一直在思考并且也做了一些实践,所以趁着这个机会来跟各位做一个汇报。
 
我们会去分析看,我们在为业务部门数字化赋能方面,我们会帮助业务部门,不管是在零售还是在刚才讲的会员运营,或者是说我们的商品运营,在我们的销售到我们的供应链甚至人资和财务,我们都希望在各个方面帮助业务部门进行数据化、数据分析、找出问题,得到改善提升运营服务。
 
但是你会发现IT部门就不是这样,大家每天忙于日常运维。可能会因为一个工单没有完成,我们被业务部门投诉,或者因为一个需求没有及时交付,被业务部门表示不满。在项目管理方面是否能够很好的按期达成保质保量?包括我们的IT资产是否我们真正能管到每个人、每个IT资产的运营状态,整个全流程、全过程的管理?
 
以及我们IT部门在整个过程当中,我们会需要很多知识解决问题,我们这些知识是否得到沉淀?这个都是打问号的。我了解到我们很多还是用excel表管工单、需求、项目管理、IT资产,或者有些零星系统或者有着单独的工单系统去零星的管。所以我们IT部门很大的状态是手工化的,是零星的在管这些事情。
 
我们还是想站在业务端来看IT部门,我们IT部门在我们业务端里它应该是什么样的形象?我认为至少有三点。第一点是IT部门应该是很专业的,在IT方面;第二个方面我们是非常有态度的,业务部门对我们的满意度是比较高的;第三个方面是我们还要追求效率。我们不可能把我们团队永远越做越大,有可能的话用最少的人去完成更多的工作。就像刚才飞书郑总分享的,IT部门是叫效率工程部。效率工程部帮业务部门提升效率,IT部门的效率在哪里?有没有数据化进行展现?
 
所以如果从专业层面来讲,整个IT服务流程是否是规范的是否是高效是否是透明的是否是能形成闭环管理的?我们的客户满意度,我们在服务整个过程当中能够随时的了解客户对我们的态度以及最终的评价。
 
这是我们要去思考的部分,我们在想我们要专业,我们在软件研发里面的CMI就是成熟度,整个IT运营依然是有成熟度的。我们可以把成熟度分为五级:第一级是初始级(有工单就派人搞定),第二级是已管理级;第三级是已定义级,如果能做到定义级,我们所有的流程都是有标准流程和服务的,它能实现闭环管理的;作为IT管理人至少要达到三级,这样才对自己有个交代。第四级是量化管理级,第五级是优化管理级。
 
我们本身怎样提升业务效率或者工作标准?第一个是ITIL,它本来是个国际组织提供给我们作为IT服务里面的标准的组件。在这里应该是有34个组件,我大概把它归归类,有规划层面的,有执行层面,有服务层面,有效率层面的。这是我们做IT人去思考的,其实我们是有服务标准可以参考的部分。
 
第二部分是项目管理。我们会做很多项目,希望这些项目赋能我们的业务。其实项目里本身就有九五至尊,九大知识领域五大过程,我们第一能不能及时按项目当初规划的要求完成项目?这样我们在下面整个过程当中是否规范的推动,且能不能让这些知识得到沉淀?以及未来得到复用。这是关于项目管理。
 
作为IT主管或者IT人来讲,我们每天的工作,我们整个工作到底是哪一些?我们可以稍微划分一下。在我们整个分析里面,在左面部分是规划层面,右边部分是我们IT人要日常运营的部分,一个是规划一个是运营。
 
在规划层面,我们是会分几步去走。第一步是业务分析,第二步是服务组合,第三步是战略规划、架构设计、组织规划和IT运算。怎么去看?刚才王总讲我在业务层面我会要做一些创新,比如我要做预制菜,把它做强做大。
 
我的业务有变化了,或者我们从批发转向零售,从线上要加上线下,这些都是叫业务分析,我们发现业务有变化了。作为IT人要对服务组合进行调整,原来只需要批发系统,现在需要门店数字化的系统。原来做的是线下可能要更加注重线上更加注重会员系统,这些都是服务组合的调整。是因为来源于业务变化,所以需要调整服务组合。
 
有了这些东西才会谈到IT规划的调整。可以这样讲当我们业务没有变化的情况下,我认为IT规划每一年抄下去就可以了,因为业务没有太多变化,所以不需要调整太多的IT规划。有了这个东西之后,我们会再一步调整架构,我们要上什么系统。所谓组织规划是向公司要多少人,原来20人,现在需要增加5个人,这5个人专门针对会员运营的,组织要进行调整,接下来是IT预算。
 
所有起点来源于业务分析,但是这个事情第一是IT主管要做的,第二我认为大家都是行业专家,我认为一个月搞定了或者年底搞定或者年初把事情搞定了。我们更大部分的工作应该是在我们的日常运营,我们又把这些工作分成几个部分,第一部分是基础设施,电脑网络这些部分。然后是服务工单以及我们原有系统的需求变更,再往上是我们项目管理,另外还有是我们和业务部门陪跑做业务运营。
 
我认为每一个项目我们最终要拿成果一定要和业务部门陪跑,我深知认为在刚开始在这一项目里,我们是教练,业务部门是学生。因为这个工具,我们一定比业务更熟。我打个最最简单的比喻,在我2021年10月份之前我在羽绒服公司工作14年,2021年10月份来到杭州卓尚服饰,我很惊讶的发现我们竟然没有做O2O,但我们要开始推动的时候我们是陪着业务部门开始做O2O的操作手册,做O2O培训、奖励制度、规划,每周陪着他们一起去看我们O2O的运营数据,这些都是业务要做的,实际这部分是最能拿成果的部分。
 
在分析业务之后,我们就可以开始想我们该怎么干,我们怎么去把我们的业务进行数字化。我认为这部分不是太需要数字化的,可能用一张PPT就能搞定的事情。但是灰色部分是可以做数字化的,因为它是长期的循环的每天每周每日每月都要去做的事情,业务运营成果也是要的,但是我正在考虑怎么让它数字化。
 
所以我大概捋了一下,我们作为IT来讲,我们自己来讲怎么样数字化?大概是哪些内容?
 
第一项内容是日常服务。日常服务里面,第一项要做的事情第一把服务要进行清理,生成我们的服务清单。我们到一家餐馆点菜一定要有菜单,作为服务人员需要服务目录。第二针对不同的服务目录要制定不同的服务标准,你是去修个电脑还是响应个需求,我相信这个时间肯定不一样,或者你是开个邮箱,开个邮箱估计5分钟就搞定,修个电脑可能需要半个小时或者多长时间。
 
我们有服务目录,有服务标准,然后我们还希望我们的用户能够再查询到我们的服务,就像我们电商下订单要看得到有没有拣货、发出,我们也希望用户看到,最后服务得到用户的评价。
 
第二部分作为IT来讲一定会遇见的事件和故障,每一个事件和故障都希望得到记录、复盘。当我们下次遇到同样的事件或同样故障的时候,我们能够快速的把它处理掉。
 
接下来关于需求变更,我们如果公司规模比较大,可能一年有上千个需求,当然小的可能一两百个需求,我相信一定是有的。这些需求第一发起完了之后有没有方案?有没有得到业务部门的审批、通过?我把这些需求派给哪个开发的同事?哪个测试的?最后有没有发布,发布有没有成功?如果没有成功,没有成功的原因到底是什么?要进行全过程的记录。
 
接下来是项目管理。从项目准备、建设、上线运营以及我们的运营维护,这一部分我们也希望得到全程的记录和进度的管控以及最后形成我们IT资产。
 
最后要形成知识管理,知识来源于工单、需求、项目、事件和故障处理。
 
这个是我花了一年多的时间,我们自己部门自己开发的一套ITBOS系统,IT的运维系统。这个是我们整个IT部门用这套系统来管理我们的日常业务,在这套系统里是包含了基础管理、IT资料,IT资料包括所有的人员、服务目录、服务标准都要在这里设置,工单管理、事件管理、故障管理、需求管理、实现管理、发布管理、项目管理、资产管理、备件管理、知识管理以及统计分析报表。这三项就是一个项就是知识管理,但是我们要把它细分。
 
这个是框架,我们进入系统之后知道这是我们的界面,可以看到工单、事件、故障、需求以及IT资产大概的整体情况。
 
接下来我快速把每个模块进行简单的介绍。
 
第一块是关于工单管理。业务部门所有的工单提交的话直接扔到服务台,在服务台里,我们可以用派单模式也可以用抢单模式。提交完之后进入工单池,然后接单然后进行过程跟踪,甚至可以跟踪到一线、二线、三线、四线,有的工程师基本上一接单都能处理掉,有的工程师要转单,因为能力不够,我们要去记录下来。当然有的可能还会转三线、四线,所以进行跟踪管理,完成之后最终用户要评价,评价完之后要形成知识沉淀。所以在这里整个工单形成了管理闭环。
 
在这里会记录每个部门每个用户所提交的工单,我们也会记录每个工程师什么时候接单,什么时候完单,最后用户打分评价。
 
再一个是事件,所谓事件是未来要形成故障可能的那些东西。比如说我们的CPU,我们使用率已经达到80%了,再往上负载高的话系统要卡掉了,这是事件。比如硬盘容量已经使用了80%了,我们再往下可能也跟系统一样。所以我们要把这些事件记录下来。
 
而且我们可以通过事件的登记,可以看到我们工程师有没有监控,如果一年到头没有这个事情,这是不可能的事情,一定会有事件发生。如果很好的把这些事件进行登记处理形成我们知识沉淀之后,它一定会预防我们的故障。所谓的故障就是整个系统不可用,整个系统就挂掉了。说实话我们在去年一年我们自己公司也遇到两三起的故障。
 
这些故障第一我们要登记,第二我们一定要把它快速处理,还要分析原因,然后是解决方案,形成我们的知识沉淀,中间我们还要做可用性分析。因为我们经常会说我们做IT部门,我们要保证业务运营系统,可用率是99.9%,我们的数据呢?如果我们没这个登记,没这个数据,那只是拍脑袋或者跟领导吹牛而已,如果有这些数据完全可以跟领导去讲,我的这个系统我们今年可用率是100%,因为这套系统从来没出过问题,那套的可用率是99.6%,我们中间发生过一个问题,停机了一个小时。我想这个都是我们可以量化的工作。
 
接下来是需求。第一部分是当我们业务部门提交需求之后,一般正常来讲会有内部的业务顾问,对接业务顾问,给他做方案,我大概多长时间完成,给到之后要业务主管审核,这个非常关键。
 
以前我们曾经遇到过业务主管都不知道下面提了需求,结果我们改了发布上线之后,业务主管说怎么改了?他说我是主管我们怎么不知道?我们有了这样的规划方式,可以更好的合理控制这些需求,而且能保证这些需求得到落地。
 
我不知道同事有没有遇到过这种情况?最后这个需求改完没人用,因为没有得到业务部门主管的确认,也没有审核推动这个事情,他认为这个东西不重要。我们希望完成这个需求之后,用户进行打分评价,最后形成我们的知识。
 
这个是从需求提交到审核的过程,我们现在需求还有一个实现的过程。很多公司用的都是接纳,就是做需求管理。在需求管理里,需求完了之后我要派工,然后我还要做测试,有没有测试,有没有OK。过程当中,我们还可以做工作量登记,满足这个需求的时候,我们哪个公司有多少工作量?以及我们在测试的过程当中还可以看得到我们到底开发完给到测试,给测试人员打回来多少次,我们通过这个是可以知道每个开发人员的开发质量是多少。
 
当我们一个部门开发人员有20个的时候,实际是很难知道每个开发人员的真正开发质量。如果没有数据,只能是拍脑袋感知这个人大概水平可以。什么叫水平可以?如果真的有这些派工资料、测试数据,我们的完工工单情况,而且当初我们讲这个需求开发需要5天,最终交付的是5天还是6天还是几天?我们也可以看到他的整个效率是多少。
 
测试完成之后我们就会进到发布池进行发布,作为系统进行发布还是非常重要的。第一有的发布是不需要停机,有的发布需要停机。如果我们的发布需要停机,而业务部门不知道,业务部门认为是个故障,系统坏掉了,因为他不知道。所以做IT系统来讲,当我们真正要停机的时候一定要通告我们的业务部门,我大概是在晚上的10点到12点,我要停机发布我们的系统,甚至发布完之后我们告诉一声发布成功大家可以正常使用了。
 
只有这样才能表现出我们作为IT人是非常专业的,要不然他不知道,他什么时候系统不能用,他不知道到底是真正系统挂掉还是你在发布一个系统。而且我们在发布之后,还需要去登记,发布有没有失败还是成功。因为我们只有这样才能知道到底我们的交付质量是什么。我以前一年总归好多次发布失败,我们要去做回滚。
 
接下来重要的一块是关于项目管理。我们讲项目管理本身有九五至尊,以我现在的经验我们只需要四个阶段,第一个阶段是项目准备,就是到项目启动会开始之前都叫项目准备,包括项目合同、项目章程、项目启动会等,大的项目应该有这些流程,小的项目可以没有。但是有的东西一定要有,包括项目组成员、项目计划,甚至开项目启动会也可以,一个项目至少有两个必须要有的。
 
我们在项目实施阶段一定会有需求调研,调研完了之后需求规格说明书以及我们的设计或者蓝图,详细设计,我们的开发文档以及我们整个功能实现,最终下面的是叫用户接收报告。用户接收非常重要,如果一个系统在上线之前没有用户接收报告,未来上线不成功,可能只能IT部门自己一个人背了。如果有了我们业务部门的上线验收报告的话,如果不成功,至少来讲有50%是业务部门跟我们一起背的。我相信通过这种方式可以让业务部门更加非常重视这个项目,非常重视这次上线。
 
上线前还需要一系列的动作,包括上线方案、上线发布、上线通知、操作手册、培训记录、上线数据准备以及上线报告。甚至有的时候上线之后发现有人不会做,你可以说有操作手册、培训记录。
 
上线方案也很重要,因为上线前会牵扯到业务很多的调整,比如说上一些大的项目的时候,甚至我们的仓库、物流包括生产方面都要做调整,包括财务都要做调整。我们以前上一个大项目的时候,我们财务提前五天结账,我们停止五天原副材料领清,为了盘清原副材料等。上线一定会有问题,出上线清单,最后验收总结。
 
不是每个项目都要这么去做,这些东西可以裁减,我这个项目如果是小项目,我哪几个阶段需要,或者我的项目比较大,哪几个阶段是比较需要的。最大的区别是有的是外购项目,有的是自己内部的项目。外购项目有项目合同,内部就没有项目合同。
 
接下来是关于IT资产,我们有一系列的动作。包括我们的资产入库、资产领用、资产归还、维修登记、更换登记、资产盘点、报废、处置,它是有一系列这些动作的。
 
包括我们备件,IT部门有很多备件。我们的备件到底用哪里去了,有时候说不清楚,如果有备件台账就可以知道备件的用法,或者有了台账之后发现我们的备件不需要用那么多。
 
最后我们是知识管理。知识管理不是单独做的知识管理,而是在各个阶段让它沉淀下来的。比如工单、事件、故障、需求和项目管理,这些所有的动作都是有很多东西自然而然就形成了我们的知识。
 
举个最简单的例子,我们在前一段时间发现我们BI服务器突然卡住了,怎么办?要不然换服务器,换服务器来不及,后来我们就查知识里发现把服务器关掉,把两颗CPU拔下来重新兑换开机就OK了,如果没有知识管理,我们肯定是不知道的。我只是举这个小例子,实际知识管理对业务服务效率提升是有帮助的。
 
我们还是做了两个面向用户的移动端,这一块我们放在钉钉上,当然也可以放在飞书上。我们作为用户来讲,它在手机端可以提交它的需求,提交工单管理个人的IT资产以及我们的需求提交,所以我们用户部门可以提交需求、查看进度、评价服务以及知识应用,可以自己做知识转出或者知识转入确认,以及他提交需求、评估需求、审批以及交付之后的评价。
 
这是移动端,我们在PC端也做了一个,提交工单、需求以及知识查询。其实对用户来讲很简单,刚才那个复杂的管理都是给IT部门要去使用的。
 
我想作为IT主管来讲,我们可能重点要关注哪几部分?
 
第一部分关注异常。我的工单有异常,我的需求有异常,超期了,我的有事件、有故障,我的项目我要关注这些异常。第一个要关注异常。
 
第二个关注效率。IT自己部门的效率,要看到接单、完单、转单的情况。
 
第三个是关于客户满意度。客户对我们的评价到底是什么?
 
第四个是综合分析。
 
我们一年做下来之后我们作为IT部门自己的成果是什么?我们通过数字化运营是不是有进步了?以工单举例,工单接单时间原来需要2.9小时,现在需要1.3小时。完单时间也缩短了,原来基本要平均3.98个小时才能完成一单,现在只要2.15个小时以及最终客户满意度,我们是五分制,如果客户不打分不评价就是四分,客户主动打分评分,我们会加上去,我们整体下来是4.2几分,其实也是不容易的。
 
因为我们效率提升之后,我们花了比较多的时间和业务部门陪跑。所以我们在其他项目方面,我们其实帮助业务部门实现了比较好的业务价值。比如说我们在机器人项目里面,我们和电商的一个部门就用机器人一年替代40几个人的工作人天。
 
作为数字化部门来讲,业务部门有那么多数字化,作为IT部门应该也有这么多数字化,去管控我们异常,提升我们效率。我认为IT和业务就在一条船上,我们要把业务部门从这边渡到那边,我们自己也要做,所以我叫做自渡&渡人。
 
我们要做有专业、有态度、有成果,做业务和领导信赖与尊重的IT人。对我们感兴趣的甲方,请扫那边,乙方同学请扫这边。
 
非常感谢大家!

关键字:数字化转型

原创文章 企业网D1Net

电子周刊
回到顶部

关于我们联系我们版权声明隐私条款广告服务友情链接投稿中心招贤纳士

企业网版权所有 ©2010-2024 京ICP备09108050号-6 京公网安备 11010502049343号

^