《盖雅工场:2023从HRTech到WorkTech:企业数字化系统选型建设指南(74页).pdf》由会员分享,可在线阅读,更多相关《盖雅工场:2023从HRTech到WorkTech:企业数字化系统选型建设指南(74页).pdf(74页珍藏版)》请在三个皮匠报告上搜索。
1、从项目规划到系统运维从业务蓝图到系统构建从业务蓝图到系统构建从业务蓝图到系统构建选型成功的底层逻辑选型成功的底层逻辑项目预算制订的关键点合同签约的细枝末节行业经验,实战心得行业经验,实战心得业务需求优先级评估业务需求优先级评估项目owner的关键能力项目owner的关键能力风险点和雷区预警风险点和雷区预警外采还是自研,SaaS还是OP?外采还是自研,SaaS还是OP?需求真假难辨,痛点还是痒点?需求真假难辨,痛点还是痒点?需求真假难辨,痛点还是痒点?功能差不多,谁才是我的乙方?功能差不多,谁才是我的乙方?如何不被供应商牵扯鼻子走?供应商过度承诺,无法判断?业务需求变来变去,怎么办?预算为何不停
2、在追加?预算为何不停在追加?预算为何不停在追加?成功上线,业务却不用?成功上线,业务却不用?成功上线,业务却不用?项目预算制订的关键点合同签约的细枝末节行业经验,实战心得行业经验,实战心得业务需求优先级评估项目owner的关键能力风险点和雷区预警外采还是自研,SaaS还是OP?需求真假难辨,痛点还是痒点?供应商过度承诺,无法判断?业务需求变来变去,怎么办?预算为何不停在追加?成功上线,业务却不用?成功上线,业务却不用?运营 IT HR实践者写给你的实战经验从HRTech到WorkTech企业数字化系统选型建设指南项目规划 P08前言:HR Tech到Work Tech P03目录Content
3、s1.明确项目价值和目标 P092.组建项目规划团队 P113.业务需求梳理与排序 P124.转型路径规划 P155.项目预算制定 P226.决策者审批 P231.关键需求梳理 P262.供应商选择 P303.招投标 P354.合同签订 P38系统选型 P24010201|企业数字化系统选型建设指南结语 P68实施上线 P401.项目准备 P422.蓝图设计 P433.系统实施 P444.系统验证 P515.系统上线 P561.组建运维团队 P612.运维工作规划 P62运维服务 P600304从HRTech到WorkTech|02扫码领取配套选型知识地图03|企业数字化系统选型建设指南前言:
4、HRTech到WorkTech如今,对大多数企业而言,HRTech(人力资源技术)一定不再是一个陌生词汇,毕竟数字化技术已经在人力资源管理的各个领域得到广泛应用,帮助着 HR 和管理者们简化工作流程,提高工作效率,优化工作体验。不过,人力资源管理对技术的需求并没有止步于 HRTech。伴随着 HR 角色和定位发生转变,企业对员工体验日趋关注以及工作方式的变化等,WorkTech 应运而生。WorkTech 是协作、生产力提升和人力资源计划的结合,更全面地提升组织整体的生产力、员工的工作体验,它代表着企业人力资源管理和组织管理对技术的新期待。换句话说,人力资源技术只是 WorkTech 的构成部
5、分之一。正如 Josh Bersin 在人力资源技术:权威指南中所述,“人力资源数字化转型已经发生了许多改变,其中最大的变化是从 HRTech 向WorkTech 的转变,它已经远远超出了招聘、培训、薪资等员工管理的范围。”正因如此,面对未来的“人力资源数字化转型”,企业需要跳出 HR 职能视角,站在组织整体效能的视角重新看待人力资源数字化,它将不仅局限于招聘、薪资等人力资源技术,还包括像飞书、Teams 等协作工具,以及直接促进时间利用率提升的劳动力管理技术,如排班、考勤。通过 HRTech 和WorkTech 的正确组合,组织才能创建一个全面高效的工作环境。前言从HRTech到WorkTe
6、ch|04企业也要从工具视角转变为综合解决方案来选择合作伙伴。人力资源“各自为政”的时代即将结束,未来的数字化转型并不仅意味着选一个工具或是选择一个系统,而是选择一套解决方案,帮助企业实现整体效能提升。除此之外,与 HRTech 时代不同的是,在 WorkTech 时代,企业还要站在员工视角而非管理者视角来思考数字化的价值。HRTech 的目标受众一般是 HR 管理者;相比之下,WorkTech 则与各种类型的员工相关,包括 HR 管理者和高管,也包括项目经理、团队成员或一线管理者。如果说 HRTech 注重于管理,那 WorkTech 则更致力于赋能。更重要的是,从 HRTech 到 Wor
7、kTech 后,企业需要从组织视角转向更广泛的生态视角。因为 WorkTech 所面对的用户将更为多样,他们分布于组织内外不仅涉及白领员工,全职员工,也涉及蓝领,合同工和零工;不仅涉及 HR 和高级管理者等办公室管理人员,也涉及车间、门店的一线管理者。他们与企业的生产力提升息息相关。从 HRTech 到 WorkTech 后,企业需要从组织视角转向更广泛的生态视角。总而言之,全局、多样和复杂是 WorkTech 带给 HR、IT、运营及其他相关管理者的新命题。面对新命题,如何选择好与企业业务和组织发展相契合的合作伙伴,这再次成为企业数字化转型过程中要面对的挑战。对于此,一些企业选择自行摸索,或
8、与同行企业交流经验,或依赖零散的网络信息来获取启发,这些方式有其存在的意义,但却并不是最有效的方式,单一过度地依赖于某种方式,都会让项目暗藏风险。这恰恰是我们筹备从 HRTech 到 WorkTech:企业数字化系统选型建设指南 的重要原因。需要提醒的是,即将为您呈现的不是一份完美的理想化的指南,而是实践者写给你的实战经验。内容创作过程中,我们邀请了 9 位在人力资源数字化领域拥有 10+年经验的实战派参与创作和指导。从项目规划开始,到系统选型、实施上线,再到运维服务,实践者们用最直接朴实的语言讲述他们在系统选型过程中的经验总结,希望它具备实际意义,对您企业未来的数字化转型有帮助。05|企业数
9、字化系统选型建设指南前言从HRTech到WorkTech|0607|企业数字化系统选型建设指南转型路径规划项目预算制定项目预算的8个构成部分业务需求梳理与排序业务需求优先级评估的6个参考维度组建项目规划团队业务变革的干系人通常有哪些?明确项目价值和目标决策者审批审批前的Checklist关键需求梳理需求梳理的5个关键步骤系统选型实施上线运维服务项目规划外采 vs 自研?SaaS vs 本地部署?一体化 vs 尖物组合?招投标合同签订业务与IT视角下成功选型的系统画像供应商选择初选与约谈阶段的评估维度招投标具体流程及注意事项系统验证系统实施系统实施的主要阶段与落地执行的24件事系统上线上线过程的
10、11个关键事项与5个常见风险点系统验证的主要阶段与落地执行的23件事组建运维团队运维工作规划运维服务的PDCA管理计划;4个阶段与15个关键事项项目准备蓝图设计蓝图设计报告要完成的2个使命目标HRTech到 WorkTech企业数字化系统选型建设之路项目规划项目规划的阶段性目标确定立项及项目的宏观目标,例如要实现的业务价值,要解决的主要业务痛点,以及各阶段的重要事项和时间周期。扫码领取配套选型知识地图项目规划可分为六个主要阶段,即明确项目价值和目标、组建项目规划团队、业务需求梳理和排序、转型路径规划、项目预算制定和决策者审批。对应这六个阶段,也将有一些阶段性产出,如:明确项目价值和目标通常来讲
11、,所有中后台投资都应落脚于支持前台“战役”打赢。所以HRIS 的规划也要以终为始,从业务痛难点来看业务需求,再分解成为项目的目标和价值,切忌“为项目而项目”,陷入职能部门自嗨状态。一般来说,中后台职能部门的价值锚主要包括提效、降本、合规、控风险这几个方面。提效:主要指通过优化业务流程或使用先进技术等方式,提高生产效率和交付质量,以实现资源最大化利用。例如业务现状是线56423总体规划系统需求文档需求矩阵技术设计文档项目计划预算和成本分析系统规划的总体方向、愿景和目标实现的路线图等内容。详细描述业务部门对系统的功能需求和技术要求。这是确定计划和预算的基础。将系统需求文档中的需求与实际的系统功能相
12、匹配的矩阵表格。包括系统架构、技术规范、数据模型、集成设计、安全设计等方面的详细设计文档。详细描述实施IT系统所需时间、人力投入、资源等各项计划,包括采购、实施、测试、培训、沟通和风险管理计划等。所有IT系统所需的实施费用,硬件、软件、培训、开发、测试、维护等。1项目规划的阶段性产出下手工核算员工工资,HR 需要加班加点采集数据、校验核算逻辑,往往要拖到 10 号才能发工资,导致员工体验较差,并影响财务关账,所以期望通过系统来实现薪酬核算提效。降本:主要指通过精益管理、创新技术解决方案等方式降低企业运营成本,包括人力成本、沟通成本、时间成本等。例如业务现状是业务部门各门店人力不均、排班不合理、
13、工时利用率低,不仅影响门店销售转化率,而且影响员工满意度,所以期望通过系统来优化工时管理,合理排班,降低工时成本和管理成本,同时提升销售转化率和员工满意度。合规:主要指通过建立完善的内部控制机制和制度,加强监管和培训,防范各种违规行为和风险,确保企业遵守各种法律法规和行业标准,符合公司内部管理制度要求,保护企业自身合法权益。例如业务现状是线下算薪、记录考勤和管理员工档案,存在不按国家规定核定薪资、工时超标、滥用员工个人隐私信息等违法违规操作的可能,所以期望实施系统来固化操作标准,保障业务合规合法。控风险:主要是指识别和管理企业可能面临的各种业务运营风险,并制定相应的风险管理策略和预案,及时应对
14、风险事件。例如业务现状是只能管理各下属单位的薪酬总额,无法管理到具体人员、职级、考勤及薪酬带宽,因此存在吃空饷现象,所以期望通过系统来提升管理精细度,落实管理抓手,控制业务运营风险。当然,随着企业业务发展,在战略规划上侧重点往往也会不同,因此我们需要以终为始,从业务战略规划出发来拆解业务目标,再细分成 HR数字化转型目标,并落地成 HRIS 建设目标,明晰此次数字化转型项目对公司的价值是什么。图1:项目规划的阶段性产出09|企业数字化系统选型建设指南下手工核算员工工资,HR 需要加班加点采集数据、校验核算逻辑,往往要拖到 10 号才能发工资,导致员工体验较差,并影响财务关账,所以期望通过系统来
15、实现薪酬核算提效。降本:主要指通过精益管理、创新技术解决方案等方式降低企业运营成本,包括人力成本、沟通成本、时间成本等。例如业务现状是业务部门各门店人力不均、排班不合理、工时利用率低,不仅影响门店销售转化率,而且影响员工满意度,所以期望通过系统来优化工时管理,合理排班,降低工时成本和管理成本,同时提升销售转化率和员工满意度。合规:主要指通过建立完善的内部控制机制和制度,加强监管和培训,防范各种违规行为和风险,确保企业遵守各种法律法规和行业标准,符合公司内部管理制度要求,保护企业自身合法权益。例如业务现状是线下算薪、记录考勤和管理员工档案,存在不按国家规定核定薪资、工时超标、滥用员工个人隐私信息
16、等违法违规操作的可能,所以期望实施系统来固化操作标准,保障业务合规合法。控风险:主要是指识别和管理企业可能面临的各种业务运营风险,并制定相应的风险管理策略和预案,及时应对风险事件。例如业务现状是只能管理各下属单位的薪酬总额,无法管理到具体人员、职级、考勤及薪酬带宽,因此存在吃空饷现象,所以期望通过系统来提升管理精细度,落实管理抓手,控制业务运营风险。当然,随着企业业务发展,在战略规划上侧重点往往也会不同,因此我们需要以终为始,从业务战略规划出发来拆解业务目标,再细分成 HR数字化转型目标,并落地成 HRIS 建设目标,明晰此次数字化转型项目对公司的价值是什么。项目规划从HRTech到WorkT
17、ech|10组建项目规划团队明确项目价值和目标后,我们就可以从顶层设计上明确项目范围及 To Be的业务版图,再基于 As Is 的业务现状,初步明确业务变革点及干系人,再根据变革需求组建项目规划团队,确保沟通到位,减少落地过程中的阻碍。例如一些大型跨国企业的组织比较复杂,启动一个项目时通常会发现“理想是美好的,现实是残酷的。”在本地看似一件简单的事情,但真正推进时,则会跳出很多平时可能都不认识的总部同事对项目“指手画脚”,让人措手不及。因此,在项目开始之前,我们最好充分做好干系人分析,了解到底哪些人可能会对项目产生重大影响以及他们的需求,从而提前做好计划。典型干系人通常包括决策者、业务负责人
18、、用户代表、系统管理员、IT 团队及合作伙伴。项目利益相关者(干系人)分析需对项目进行决策,并提供资源保障,确保系统顺利实施。需提供业务需求和流程设计,确保系统能够满足业务需求。参与需求分析、流程设计和测试等环节,提供反馈和建议,确保系统符合用户需求和期望。企业高层管理人员企业内负责系统运营和日常维护的人员各业务模块主管系统最终使用者企业内的技术开发团队,包括软件开发人员、测试人员、数据库管理员等为企业提供实施咨询服务的外部公司或人员负责系统配置、部署、权限管理、数据备份和恢复等工作。负责系统的技术研发、测试和维护,确保系统稳定运行。提供企业需求分析、流程设计和实施计划制定等方面的支持,协助企
19、业完成系统实施。业务负责人用户代表系统管理员IT团队合作伙伴决策者图2:项目利益相关者(干系人)分析11|企业数字化系统选型建设指南虽然从风险把控的视角来看,干系人覆盖范围宜大不宜小,但同时也要兼顾沟通效率,避免影响规划交付效率。例如,规划招聘系统,有HR负责人全程支持最好,但没有或部分参与皆可;再例如整体切换集团系统,就一定要有集团HR领导参与,还要下属各业态HR负责人参与。业务需求梳理与排序根据业务发展战略明确 To Be 愿景之后,接下来我们需要对照业务现状进一步明确业务需求,然后再分解成对系统的需求。这里的业务需求是指业务更高层面、更接近本质的业务收益和目标,而非具体的系统功能需求,例
20、如:激发员工潜能,促进销售目标提升 10%;实现业财人一体化管理,打破决策层单一维度的数据统计分析;人力成本降低 10%;数对人,发对工资,工资核算时间要减少 30%;人才盘点的时间缩短 50%;解决目前各系统数据不统一、不准确、不及时、格式不统一或信息孤岛问题;提升流程效率,增加对流程的监管;考勤统计耗费工时减半,准确率提升到 95%以上;.项目规划从HRTech到WorkTech|1213|企业数字化系统选型建设指南通过梳理得出业务本质需求后,可初步盘点背后需要的系统支持。原则上不推荐多系统全模块一起实施上线,这不仅对供应商的实施水平要求更高,而且业务人员压力也会变大,实施质量难以保证。一
21、般而言,人力资源系统转型过程中,考勤或薪酬为一期项目,待数据和基础业务流程理顺后再开始其他模块,如绩效、人才发展。当然也不排除老板特别关注绩效,先上绩效系统的情况。总之,每个公司都会产生很多需求,但系统部署和实施、让员工习惯使用系统,以及系统磨合都需要时间。所以面对业务提出的需求,我们需要评估优先级,分期解决。Tips业务需求优先级评估参考维度业务价值评估维度阐释权重(%)优先度(1-10分)可操作性实施难度紧急程度成本效益合规性系统带来的直接或间接商业价值,对业务流程和业务结果的影响程度。可操作性、易用性和易学性,对用户学习和使用成本的影响程度。实施成本、技术复杂度和风险程度,对周边系统稳定
22、性和安全性的影响程度。对业务运营的重要性和紧急性,对业务连续性和灵活性的影响程度。投入产出比和回报周期,资源有限的情况下是否是最优选择。是否符合法律法规和行业标准,对企业声誉和合规性的影响程度。图3:业务优先级评估参考维度项目规划从HRTech到WorkTech|14为了避免项目实施过程中业务不断增加很多新的需求,我们在最开始项目需求梳理阶段,就要非常明确需求的优先级,基于现实情况做删减。关键是如何判断优先级呢?每一个需求提出者肯定都会坚持自己的最紧急优先。我们的做法是,设定一个评估表,例如这个功能将影响多少用户、将节约多少时间、对客户的影响将是什么企业可以根据自己的关注点来设定评估维度,然后
23、大家一起开会评估,需求方阐述自己的需求并争取优先级,参与者一同评分。谁的需求最紧急?The consultant said顾问说某高端汽车品牌(BBA之一)组织发展部高级经理兼HR数字化负责人转型路径规划HRTech 也好,WorkTech 也罢,系统本质上依旧是 IT 系统,建设新的系统要纳入 IT 整体规划。因此每一次项目的实现路径都需要结合整体规划来权衡转型路径,例如是否需要咨询公司介入、外采还是自研、软件部署方式是云部署还是本地部署,以及需要与现有哪些系统对接等问题。关于这些问题的利弊权衡,下文我们为大家整理了一些需要考虑的因素。4.1 是否需要IT咨询公司?这个问题关系到项目预算、项
24、目计划、项目管理等关键成功因素。回答这一问题,我们需要考虑的因素主要包括:1.项目规模:项目规模越大,需求越复杂,技术难度越高,就越需要引入专业的外部咨询公司进行支持和指导。2.技术领域:项目所涉及的技术领域,如果企业内部缺乏相应专业人才或技术储备不足,可考虑借助外部咨询公司的力量提供专业技术支持。3.人员资源:企业内是否有足够人员来负责系统实施并保证公司正常运营不受影响。如内部力量无法完成任务,可考虑引入咨询公司来补充相关人员资源。4.时间和成本:系统选型和实施都需投入很多时间和精力,并可能带来昂贵的成本。如果企业无法承担这些成本,或想要在较短15|企业数字化系统选型建设指南时间内完成实施,
25、可考虑引入咨询公司来协助实施。5.行业经验和知识:外部咨询公司通常具有丰富的经验和良好的行业背景,可为企业提供更好的建议和指导,以确保项目能够顺利实施。6.风险分析管控:由于实施系统可能存在风险,因此必须进行风险分析并采取相应的措施。外部咨询公司通常具有更多的行业经验和途径来识别和处理潜在风险。项目规划从HRTech到WorkTech|16管理咨询和 HRIS 系统建设是不同维度的工作,对 HR 的业务促进方面既有相同之处也有不同之处,以目前市场HR 产品的成熟度来说很难将管理咨询的理念以及措施在系统中完全落地,或者说管理咨询的方案很多也未必需要系统落地,所以大可不必混为一谈。同时,管理咨询供
26、应商的选择、进场,调研,写方案又要一年半载,而在这期间系统的规划可能因为人员的变动或者新技术的产生又发生变化。因此,个人认为在选型阶段,选择具备行业实施经验的项目经理和资深顾问提供轻咨询服务会更加合算。项目规划是否要引入管理咨询公司?The consultant said顾问说李冲知名亚洲珠宝集团 HRIS 专家 17|企业数字化系统选型建设指南4.2 外采还是自研?这一问题决定了项目预算、项目周期。回答这一问题,我们需要考虑的因素主要包括:1.成本:采购成本较高,但自研系统的开发成本也不容忽视。企业需要对两种方案的总成本进行比较,并综合考虑相应收益。2.时间:采购系统可以省去研发和测试所需时
27、间,而自研系统可能需要更长周期。企业需要综合考虑实施期限和管理层的要求,以选择适合的方案。3.技术能力:自研系统需要企业拥有一定水平的技术团队,如果企业拥有相关技术人才,就可以考虑自研系统。否则就必须外包给专业技术公司,避免增加成本。4.功能:采购系统通常都会有很多常用功能,但可能无法满足企业特定的需求。自研系统可以根据企业的需求进行定制,但这需要消耗更多资源和时间。5.管理和维护:采购系统提供了一定的服务和支持,而自研系统需要企业自己负责后期的管理和维护工作。6.未来可扩展性:自研系统相比购买系统可以更好地满足企业未来的发展需求,可以随着企业规模和业务需求的变化灵活地升级和定制。项目规划从H
28、RTech到WorkTech|184.3 SaaS还是本地部署?这一问题关系到服务器的配置策略、信息安全策略及运维策略。回答这一问题,我们需要考虑的因素主要包括:1.成本费用:SaaS 系统通常是按订阅付费,不需要额外的硬件投入和维护成本,而本地部署则需要购买软件授权并支付额外的硬件费用。建议从长期角度来评估,因为 SaaS 的首年订阅费一般不高,可以计算三到五年的总成本,是否比一次性购买软件的费用加之后每年的维护费更划算。2.安全性:对于需要高度保密的数据和敏感信息的企业,本地部署可以提供更好的安全性保障,因为它能更好地控制数据存储和处理的环境,而 SaaS 系统则需要相信服务商的安全措施。
29、3.灵活性和可定制性:本地部署系统通常具有更高的灵活性和可定制性,可以根据企业的特定需求进行定制化开发。而 SaaS 系统则往往只提供标准功能以及有限度的开发,无法满足企业所有的个性化需求。4.可扩展性:SaaS 系统的可扩展性往往更佳,可以根据企业的业务需要和规模进行弹性扩展,而本地部署可能需要对硬件和系统进行升级或调整。5.集成问题:企业如果已经拥有了其他的系统,如 ERP、CRM 等,那么在考虑新的系统时需要考虑与这些系统的集成问题。本地部署和 SaaS 系统在这方面也有所不同,企业需要选择与现有系统相兼容的系统。19|企业数字化系统选型建设指南2012年开始,施耐德的HR主系统已经上云
30、,自此之后云系统上线速度大大加快。2020之后,施耐德本土云部署的速度也在加快,并成为主要趋势和首要选择除非涉及公司非常核心的知识产权或有高可用性要求的业务,才会考虑本地部署。“云部署”是施耐德全球的IT战略,对中国区来说则具体落地为“海外+本土”双云体系,我认为背后有几个原因推动着我们做出这样的选择。1.经济和政治环境的不稳定性:本土厂商能更好地帮我们避免接下来会产生一些非技术的风险,以免影响整个项目的推动。2.另外是个人信息保护法和数据跨境的法律法规越来越严格了,如同欧盟,北美,中国的数据安全管理强化也是趋势。这种情况下,本土软件是更合规的选择。选本土软件的基础上,为什么要选择 SaaS
31、而不是本地部署?这与施耐德资产管理方式和领先的ESG理念有关,SaaS对企业而言是一种更绿色更轻便的IT资产,不需要维持庞大的运维团队,也不需要很多的服务器硬件资产,能更好地适应环境和业务的调整和转向。所以除了公司核心知识产权和一分钟都不能中断的高可用类业务,在符合数据安全的前下,我们尽可能都采用SaaS模式。至于SaaS带来的数据安全风险,首先我们认为未来将是越来越安全的时代,这是国家管控和技术发展趋势带来的必然结果,当然目前仍会通过一些合同条款来约束,在服务合同中有将近30页都与数据安全条款相关。“本土云部署”为何成为施耐德的战略选择?The consultant said顾问说常晓东施耐
32、德电气 人力资源信息化高级经理 项目规划从HRTech到WorkTech|204.4“一体化”产品模式,还是“尖物组合”模式?这一问题关乎到企业接下来供应商选择的范围,以及评估维度。回答这一问题,我们需要考虑的因素主要包括:1.公司需求和规模:一体化产品模式适合中小型企业或对功能需求相对简单的公司,可以提供一站式解决方案,避免集成的复杂性,而大型企业或有特殊需求的公司则更适合选择“尖物组合”模式,以满足不同领域的专业需求。2.功能和特性:一体化产品通常提供各种综合功能,但可能在某些特定领域的深度和灵活性上有所限制,而“尖物组合”模式则可以选择最适合的专业系统,满足特定领域的高级需求。3.集成和
33、互操作性:一体化产品通常提供较为顺畅的集成体验,减少集成工作量,而“尖物组合”模式可能需要额外的集成工作,并确保各系统之间的互操作性。4.技术支持和服务:一体化产品通常提供全面的技术支持和培训,而“尖物组合”模式可能需要依赖多个供应商的技术支持,同时也需要确保他们能够有效地协同合作,因此对企业的供应商管理能力的要求也更高。5.长期战略和可扩展性:一体化产品通常更易于管理,能够提供整合的解决方案,而“尖物组合”模式可能需要更多的系统集成和管理工作,但也更有可能满足公司未来业务发展的特定需求。6.成本和预算:一体化产品通常具备较高的初始投入成本,但可能在后续使用中节省时间和资源,而“尖物组合”模式
34、可能需要分别购买和维护多个系统,但可以根据需求和预算相应地优先级和节奏调整。除上述这些常见问题之外,在系统转型路径规划过程中,我们还需考虑OA现有情况及升级改造计划,这关系到人力资源审批流的承载系统,例如是否对审批授权有统一管理、规范;审批入口是否有统一规划;审批结果是否对周边系统有较大影响。另外,还需要考虑的是系统之间的对接情况,这关系到系统集成的范围、集成难度、项目周期等,通常需要与人力资源系统集成的常见系统有OA系统、考勤终端系统、员工身份认证系统、财务系统等。系统转型路径规划过程中,我们还需考虑系统之间的对接情况,这关系到系统集成的范围、集成难度、项目周期等。21|企业数字化系统选型建
35、设指南项目预算制定作为项目规划阶段的一个重要阶段,项目预算制定既是前序准备工作的一个结果性动作,也是项目审批和推进的一个关键卡点。排除自研,我们以主流选择,即第三方软件实施为例来说明预算制定通常涵盖的几类成本,逐一测算后汇总后,我们即可得出项目预算的大概范围。需要特别说明的是,如果初次主导人力资源数字化转型或是企业处于转型比较初级的阶段,项目预算制定面临的最大困难则是无法准确地判断预算的合理性,以及无法预测哪些事情会产生额外费用。这种情况下,我们建议寻找专业人士的支持,通过三方审核来降低风险。项目预算构成设计、编码、测试和上线部署等方面的费用。服务器、存储器、网络设备、安全设备等费用。系统实施
36、过程中所需的人员工资福利、培训等方面的费用。实施过程中可能需要使用第三方服务和工具,如测试工具、云计算服务。系统上线过程中的培训和支持成本,如用户培训、文档编写、技术支持等方面的费用。包括项目计划和进度的制定、项目各阶段的跟踪和监控等方面的费用。如办公费用、宣传物料费用、差旅费等。不可预知风险的预留费用,如业务规模扩大导致临时增加新功能,实施延期或技术问题导致的额外成本。系统实施成本硬件和设备成本人力成本第三方服务和工具成本培训和支持成本项目管理成本其他杂项费用预算Buffer图4:项目预算构成项目规划从HRTech到WorkTech|22决策者审批在获得以上信息后,接下来我们便可以与关键决策
37、者沟通项目情况,以获得审批。在决策审批前,我们需要再次多维度评估目前的项目规划,避免决策信息不充分。通常情况下,需要评估的信息维度包括业务需求满足度、投资收益率、实施计划、安全性、可靠性等等,项目小组可根据项目目标选择和权衡哪些是最重要的,相对应的信息准备也要更充分。23|企业数字化系统选型建设指南具体审批过程中,项目规划小组仍要与老板充分地沟通,阐述系统假设步骤,不要让老板有短期的不切实际的期望,做好期望值管理,避免后期落地过程中带来不必要的阻碍。否则系统上线后很可能“绩效”不升反降。业务需求满足度规划的系统解决方案能否满足业务诉求,并具备高度的可操作性。投资收益率测算实施系统所需成本,并预
38、估可带来的收益,如成本节约、效率提升,以此佐证系统实施投入产出比是否满足公司要求。合理的实施计划进度安排、资源投入、质量保障等是否合理。可扩展性系统解决方案是否具备一定的扩展性,以满足业务发展需求,如支持更多员工、添加新模块以处理更多类型的业务。安全性系统是否具备高水平的安全性,以防止敏感信息泄露或黑客攻击。可靠性系统是否可长期稳定运行,支持业务波峰,并有良好的运维机制、风险防范机制。集成性系统能否与周边系统良好集成,保障数据一致性的同时提供良好的用户体验。用户体验系统易用性如何,员工和管理人员能否轻松地访问和操作。系统的报告和分析功能是否拥有强大的报告和分析功能,帮助业务更好地分析员工数据并
39、做出更明智的业务决策。项目审批前Checklist图5:项目审批前Checklist前言从HRTech到WorkTech|04扫码领取配套选型知识地图系统选型系统选型的阶段性目标识别出符合企业当前管理诉求的产品组合,为项目成功匹配到最有价值的合作伙伴,并确定项目的关键里程碑。在供应商选择阶段,我们要回答两个关键问题,一是哪些供应商的产品能够满足业务的关键需求,二是如何评价供应商的综合能力。就供应商选择范围而言,国际上有几家相对垄断的 HR 软件大厂,但由于价格、员工体验以及个人数据保护法、数据跨境管理,甚至政治和经济环境等,使得国内不少企业在系统选型过程中要考虑的因素变得更加复杂。与此同时,国
40、内人力资源数字化服务厂商目前也处于百花齐放的状态,没有一家人力资源软件厂商绝对垄断,各家厂商都各有所长,这就让企业挑花了眼,进一步为选型增加了难度。“如何合理选择供应商”也因此成为系统选型成功过程中非常挑战且关键的一步。辅助角色关键角色系统选型过程中最重要的角色之一,他们需提供业务流程、数据和功能等方面的详细信息,帮助评估系统是否符合业务需求。业务专家评估系统的技术适配性和可行性,包括系统架构、安全性、可扩展性等,以及为业务提供有关系统技术方面的建议和指导。IT专家制定采购策略和计划,并协调与供应商的合作。他们应熟悉市场、理解合同和法律等方面的知识。采购专家负责整个系统选型过程的协调管理,包括
41、制定项目计划、进度跟踪和风险管理,并确保所有参与者都清晰了解项目目标和需求。项目经理评估系统架构和技术方案的可行性,为IT代表提供技术指导和支持。系统架构师评估系统安全性,如身 份 认 证、数 据 加密、权限控制,并提出相关建议。信息安全专家评估系统的数据处理和分析能力,包括数据存储、备份、恢复等。数据库专家评估系统的用户界面和交互设计,以确保用户友好和易用性。用户体验设计师对系统进行全面的测试和验证,确保系统符合要求并达到预期效果。系统测试人员系统选型阶段的关键角色和辅助角色图6:系统选型阶段的关键角色和辅助角色25|企业数字化系统选型建设指南图7:项目关键需求梳理关键需求梳理进入系统选型阶
42、段后,我们首先要做的是梳理关键业务需求,这直接关系到系统选型的成功概率,因为在不明确业务需求的情况下就贸然进入供应商选择阶段,很可能会出现系统和业务实际需求不匹配的情况,无法达成预期目标。所以,需求梳理一定要保证与业务充分沟通,各方视角了解和共创。与项目规划阶段的需求了解相区别的是,此阶段的需求梳理目标是项目落地的具体解决方案,而不是还停留在项目规划阶段为了论证项目价值、汇报和申请预算的需求梳理。为避免项目实施阶段出现需求变更和扩充,我们通常需要走完需求梳理的几个阶段,尽可能保证需求的完整准确性。充分了解业务(研究行业标准、竞争对手、业务流程等);根据审批通过的项目目标和范围来进一步明确全流程
43、的利益相关者;组建专门的需求分析团队;准备需求访谈模板及相关工具(需求管理软件、原型设计工具等);制定访谈计划并获得领导支持等。与各利益相关者充分沟通和交流,了解他们的需求、期望和目前的痛点问题,可以通过面对面会议、问卷调查、访谈等方式来收集信息,并尽可能完整记录。将收集到的需求进行整理和分类,归纳分类相似的需求进行,以便更好地理解和分析。深入研究理解每个需求背后的意图和目的,识别优先级(哪些是核心需求,哪些是必须要实现的需求);排除不必要的或冲突的需求;初步评估需求可行性及所需资源。确保已经理解和记录的需求是正确且完整的,以便进一步验证和确认;可通过与利益相关者的再次确认、系统原型的验证、用
44、户测试等方式进行确认,也可要求关键用户签字确认。准备工作需求采集需求整理和归类需求分析需求验证和确认项目关键需求梳理系统选型从HRTech到WorkTech|26需要注意的是,在和业务探讨时,我们要从业务的当前痛点出发逐步链接到系统模块的相关需求,这样才能让业务充分认识到系统关键需求与业务工作日常之间的联系。同时也要避免探讨例如报表需要哪些字段等细节问题,正确的做法是要将人力资源管理场景化、具体化。在场景化的探讨中我们可以进一步找到需求的关键。下方我们也从常见的几个人力资源模块为例给大家参考。当讨论的关键需求比较多时,我们也需要引导业务部门探讨相关需求的重要程度和影响范围,以对关键需求进行优先
45、级排序。优先级评估的维度依然可以参考项目规划阶段提到的 6 个维度(业务价值、可操作性、实施难度、紧急程度、成本效益、合规性)。招聘招聘的本质是结合业务需求吸引合适的人在合适的时间点满足业务发展需求,结合这一终极目标我们可梳理出如下的关键需求。雇主品牌:人才竞争也是雇主品牌的竞争,优秀的候选人最后究竟加入哪家公司,一个很重要的决定因素就是候选人对公司的整体印象如何。校园招聘:校招一般是全年工作量的一个高峰,数字化系统需要有更多自动化功能,尽可能提升规划、传播、筛选、录用等环节的效率,降低 HR 包括面试官的工作量。技术提效:由于招聘数量一般比较多,因此各种场景中如何降本增效也是对数字化系统的基
46、本要求。灵活内推:内推一般是企业性价比最高的人才补给方式。数字化招聘系统也需要支持各种灵活内推的方式。人才库运营:数字化系统要帮助企业针对投过简历的候选人、已离职员工等进行人才库运营,以便在需要时能快速、精准且节约成本地找到候选人。27|企业数字化系统选型建设指南培训劳动力管理企业需要的培训系统绝不只是一个课程大杂烩的内容平台,而是要推动员工学习,为达成这个目标,我们可梳理出如下关键需求。能力模型:人才培训首先要基于业务需求看各部门员工需要掌握哪些能力,供应商要能结合行业经验共创能力图谱,确保各项能力都有课程覆盖。学习路径:为更好地引导员工学习,还需要设计学习路径,以最终的学习目标为导向,挑选
47、最适合的课程和顺序,通过合理的课程安排让员工能高效地完成整体学习。学习运营:为推动更多员工的学习,培训系统必须具有各项运营功能和数据分析功能来帮助 HR 随时了解员工学习动态。经验萃取:企业中的关键领导和人才的经验萃取并传承,这也是通过培训提升企业核心人才竞争力的关键。因此数字化平台也要能支持内部课程的开发和授课。课程迭代:学习平台要有能力持续迭代课程,不断引入新课程,同时确保课程质量和学员体验也非常关键。劳动力管理主要是对于工时管理进行管理和优化,是以降本增效为主要目的,因此所有的关键需求必定是以智能化为基础来提升效率,节约人力成本,通常会产生如下关键需求。人力规划:劳动力规划是人力成本控制
48、的源头。如果数字化系统结合未来业务的发展需求来预测未来的劳动力需求,就可以更好地帮助企业提前做好人才招聘和培养准备。排班优化:人力成本是企业重要的成本支出,借助数字化系统帮助企业优化员工排班、减少工时成本,也是人力成本优化的关键,并结合业务需求和员工体验找到最优的排班组合。有效及时的考勤数据:不仅要保证考勤数据真实精确,也能当天将工时、加班、出勤率等数据及时呈现于管理者,而且过程中要能确保用工合规性。另外需要注意的是,因考勤模块功能相对复杂,覆盖范围广,员工感知强,因此它也是 HRIS 项目里最能出效果也是最容易被吐槽的模块,系统选型千万不可掉以轻心。奖酬计算:基于考勤、休假数据,结合公司的政
49、策,奖金和薪酬的计算都能自动化处理,并与考勤数据打通,减少 HR 不必要的数据收集处理工作,提升薪资计算效率。系统选型从HRTech到WorkTech|2829|企业数字化系统选型建设指南在项目规划时,我们常常会将某个需求的实现想象得过于简单,以至于在项目交付过程中才发现一个需求又牵扯出其他许多需求。因此我认为在需求梳理和规划阶段需要尽可能投入精力,与供应商沟通需求时要尽可能落地,将场景落地到具体功能的实现,避免我们想象的实现过程非常简单,而供应商理解的场景与我们需要的却不同,结果在实施过程中需要不断追加预算来实现实际需求。紧接着老板不可避免地会疑问:“已经批了一大笔预算,为什么还在不断增加投
50、入?”这给我们带来另一个反思是:在预算制定过程中,需要增加一部分备用金,因为不可能有完美的规划。甲方与乙方,此需求非彼需求?The consultant said顾问说某高端汽车品牌(BBA之一)组织发展部高级经理兼HR数字化负责人2.1 供应商初选在明确核心业务诉求及选型边界后,我们需要多渠道了解潜在合作伙伴,通常的渠道包括。行业知名媒体:如人力资源智享会的红宝书、HRTechChina、36氪企服,可以初步了解对特定人力资源业务领域的供应商、业界先进实践,但也仅限于初步了解。同行业推荐:同行业使用的系统解决方案、类似场景下的系统解决方案,往往对选型有非常直接的指导意义。基于已有 IT 底盘
51、寻找生态合作伙伴:从已有系统的生态合作伙伴中选型,这种供应商往往与已有系统有天然的集成优势,有成熟的联合解决方案。供应商选择综合实力:公司规模、市场占有率和稳定性,以及人力和资源保障。行业能力:品牌知名度和影响力,行业内地位和口碑。产品战略:要采购产品是否是其未来要继续深入发展和投入的部分。产品力:用户体验、标准功能匹配度、客制化开发程度、系统安全性、系统集成性。服务能力:同数量级的成功案例、交付经验、售后持续服务水平。生态建设:和行业内细分领域厂商有广泛的生态合作,方便集成。增值服务:支持业务更好发展的额外资源。项目经理及成员资质技术方案和解决方案系统架构设计系统性能和可靠性数据库设计代码管
52、理和质量控制测试质量和方法可维护性和可扩展性安全性和隐私保护售后技术和服务支持信誉度风险把控价格和成本售后服务交货期限合同条款初选阶段约谈阶段技术评审商务洽谈供应商评估参考维度图8:供应商选择评估维度系统选型从HRTech到WorkTech|30基于业务痛点找供应商:很多供应商在解决特定问题上有独特优势,基于业务痛点来匹配厂商也不失为一个选择,比如业务要出海,就搜索主打海外的系统。引进专家意见:通过咨询机构引入专家,或与行业内的专业人士沟通,获取相关建议和推荐作为参考,给出诊断意见和潜在的产品组合。在软件采购选型过程中,施耐德主要从三个维度的评估开始,一是供应商的企业健康度评估;二是产品战略;
53、三是行业地位分析。企业健康度评估过程中,我们通常会通过如下几个信息渠道来获取信息:1.第三方分析报告:例如通过企查查的相关服务和报告来了解意向供应商的企业风险和系统情况。2.融资情况分析:对于很多初创高科技企业,目前比较大的资金来源仍依赖于融资,这也为我们了解意向供应商的资金链情况提供了公开渠道。3.与供应商的在职和离职员工沟通:网上和行业内的小道消息和“八卦”虽然是非正式的信息获取渠道,但有时也能暴露出企业的一些问题。不过,这些消息仅为我们下一步验证提供方向,并不能直接作为论据。4.人力资源相关信息获取渠道:例如从各个招聘渠道的信息来分析意向供应商最近在招聘什么类型的如何评估意向供应商的企业
54、健康度和产品战略?The consultant said顾问说常晓东施耐德电气 人力资源信息化高级经理 31|企业数字化系统选型建设指南员工,每年招多少人。这某种程度上也能反映他们未来的发展方向。产品战略评估也是我们供应商初选过程中的重要关注点,这关乎我们要采购的产品是否是未来还要继续发展和投入的方向。对于此,目前评估的方式主要包括:1.查阅了解意向供应商自身的宣传资料,例如官网、展会和论坛上的分享内容和产品资料。2.当了解到一定程度,切实可行的办法是实地拜访,参观供应商客户,同行业交流。3.也可通过供应商组织架构图和事业部划分和人数分布来分析他们产研规划。4.另外可通过第三方渠道的分析。遗憾
55、的是,目前国内还比较缺乏权威的、客观深度的第三方机构,可参考的主要来自国外的一些分析,Gartner 和Joshbersin 偶尔对国内一些产品的评价,但比较有限。行业地位是比较显而易见的,一般情况下比较偏向领域内的前三位PK。这种方式仅限于发展相对成熟的产品,对于某一类产品发展初期,行业内总共或许也没有三家供我们选择,这就需要我们花费更多精力深度分析产品演示和讲解,也可以选择成为对方的种子用户,试用和共创。系统选型从HRTech到WorkTech|322.2 供应商约谈初选确定多家潜在合作伙伴之后,我们可逐步开始约谈供应商,沟通业务细节和系统解决方案,比较典型的做法是访问供应商官网,留下联系
56、方式后建立联系并约谈,当然也可以通过朋友直接接触供应商的销售。此阶段是双方互相探讨、明晰需求和初步解决方案的过程,经验丰富的供应商往往对解决方案会有更广更深的思考,因此有助于修正我们的思路,进而也会影响后续需求清单和邀标书的制作。在约谈供应商过程中,我们可以根据企业关注的维度设定打分表(评估维度可参考下方的四个维度:产品力、服务能力、生态建设、增值服务),对所约谈的供应商进行打分,为后续考察评估提供参考。需要注意的是,许多产品的功能基本大同小异,差别往往体现在个性化需求和复杂需求的落地上。所以我们务必要明晰自己的“底线需求”,并要求供应商明确对应的解决方案,以及成功案例佐证,减少误判风险。33
57、|企业数字化系统选型建设指南约谈阶段,供应商评估的四个参考维度Tips1.产品力:用户体验是否良好、标准功能对业务的满足程度、客制化开发是否灵活、系统安全性是否足够、系统是否可以广泛集成。2.服务能力:有同数量级的成功案例、项目经理及成员的交付经验、售后持续服务水平。3.生态建设:和行业内细分领域厂商有广泛的生态合作,方便集成。4.增值服务:能支持业务更好发展的额外资源,例如:招聘系统:提供招聘活动的策划及实施;考勤系统:提供劳动力招聘和挂靠服务;培训系统:附赠大量免费或优惠的内容资源,如书籍、公开课、直播;激励系统:提供信托服务、税优筹划、合规咨询。系统选型从HRTech到WorkTech|
58、342.3 供应商考察完成供应商约谈后,我们需进一步明确要重点考察的供应商。考察时,一定要秉承“耳听为虚,眼见为实”的原则,例如:赴供应商公司现场考察,了解他们的技术、经济和研发实力,以及可持续服务能力等;也可请供应商安排“标杆案例”的交流、访谈,进一步了解供应商的实施能力、服务口碑,并评判相关解决方案是否可以在本企业落地;或直接询问供应商各自的优势是什么,以及竞争方的劣势是什么,进行反向验证;最关键的是在这个过程中亲身体验供应商是否站在客户角度洞察需求,在服务上是否为客户着想的态度。这不仅是体现在口头承诺上,还体现在供应商为客户定制方案的细节上是否考虑我们的业务痛点。完成以上工作后,我们基本
59、可以再次明确核心业务诉求、项目范围、系统解决方案、分期实施规划等关键决策因素,并可据此拟定招投标文件(包括并不限于对系统性能、质量、交付期等方面的要求),然后进入招投标流程。系统考察时,一定要秉承“耳听为虚,眼见为实”的原则。招投标发布招标公告:根据管理规范发布招标公告,向潜在投标人宣传招标信息,标书内容通常包括项目概要、招标条件(如是否高新技术企业、有同行案例)、技术要求、详细参数、资质要求、投标方式、截止日期,以及提交文件要求(包含哪些文件,准备多少份)等细节。需要注意的是,在招标书中,我们必须明确且清晰呈现业务需求,而且为帮助供应商更好地了解业务需求,减少信息误差,所以在此阶段往往会安排
60、投标答疑、业务用户访谈等。供应商投标:供应商根据招标文件的要求准备文件,包括商务和技术方案、报价单、质量保证书、资质证明(如 SOC 认证、软件著作权等)等,将准备好的文件按要求递交于我们,通常需要包括电子版和两份纸质版(纸质版一般要求盖骑缝章)。评标:针对供应商提交的投标文件,我们进行评审,主要包括技术和商务方案的评审(常用的技术评审维度参考图 9),以及资质和信誉的审核。常用的标评价维度包括项目团队资质、技术方案和解决方案、系统架构、系统性能和可靠性等。商务洽谈:进入商务洽谈阶段,我们可开始与符合资格的供应商进行商务洽谈,就价格、交付期限、售后服务等问题进行讨论(常用的商务评价维度参考图
61、10)。谈判过程中,作为甲方企业代表,我们需要具备的主要能力是专业能力和谈判能力,专业能力可以消除很多理解上的偏差,避免被供应商过度承诺。需要注意的是,谈判不只是采购的责任,很多公司完全由采购负责,业35|企业数字化系统选型建设指南务代表和 IT 撒手不管,这种做法不能说不对,但具有一定风险,因为采购缺乏专业能力,议价空间有限。如果业务代表或者 IT 具备一定谈判能力,效果可能要远胜于采购。在谈判阶段,最大的考验主要还是合同主要条款的共识,因为一旦确定中标,如果在有些合同的主要条款上出现争议,往往就非常被动。因此,我们建议关于 SOW 的沟通也提前到此阶段沟通,并做好文档化管理工作,以确保大家
62、就主要内容达成共识;除价格、交付期限、售后服务等比较显性的内容外,另外就通常的合作模式、验收及付款流程等事项也最好提前达成共识。发布中标通告:企业公布中标结果,向所有参与投标的厂商通知是否中标,并进行公示,公布中标供应商的名称和价格。评价内容评价维度范围控制、风险控制、时间控制、质量控制。产品组合、数据流向、集成、重点需求响应方案等是否提供符合采购要求的整体技术方案和解决方案,是否具有创新性和实用性,是否能满足项目核心诉求。是否符合业界标准、行业规范和安全标准;是否满足公司内部网络环境要求;是否契合公司现有IT架构;技术栈是否匹配现有资源。系统运行效率和可扩展性是否达到要求;系统稳定性、容错性
63、和可靠性如何;是否满足业务场景并发要求。数据库结构是否合理、高效;数据存储、备份与恢复策略是否健全;是否支持公司优选的数据库(尤其是公司使用云资源时,对数据库成本有要求)。代码管理、版本控制以及代码审查流程是否清晰有效;编码质量是否良好。测试计划和测试用例是否完善;测试覆盖率、测试深度和测试精度是否符合要求。是否提供详细的文档和相关的手册;系统升级和扩展的易用性如何。售后服务期限;售后服务组织架构、问题响应机制、SLA。项目经理及成员资质技术方案和解决方案系统架构设计系统性能和可靠性数据库设计代码管理和质量控制测试质量和方法可维护性和可扩展性安全性和隐私保护售后技术和服务支持信息安全资质证书及
64、如何保障数据合规;是否遵守相关法律法规和行业标准;是否具备针对性的安全保障措施。技术评审参考维度图9:技术评审参考维度系统选型从HRTech到WorkTech|36图10:商务评估参考维度图11:招投标流程示例37|企业数字化系统选型建设指南公司的声誉和口碑状况;是否有可信度、稳定性和可靠性等优势。评价内容评价维度是否有完善的风险管理体系、应急预案及相应的稽核措施。信誉度提供的产品或服务的价格是否合理;是否存在附加费用;是否符合预算要求。风险把控是否提供快速、高效的售后服务;是否有主动解决问题的意愿;是否满足客户需求。价格和成本是否能够按时交付产品或服务;是否具备及时通知采购方的能力。售后服务
65、交货期限是否合理、透明和完整;是否含义明确;是否满足采购方需求。合同条款商务谈判参考维度关键事项确认需求说明书、技术小组成员名单起草招标技术文件项目招标小组启动会议正式发出标书答疑投标截止供应商讲解标书和系统演示技术评标供应商按要求澄清和修改技术方案及最终商务报价,快递封标并寄送商务洽谈(如需要)招标小组会议评估拟定标汇总评估定标审批发布中标通告合同签订前期准备招标评标定标截止日期 沟通形式(线上或线下会议、邮件等)关键负责人或联系人招投标流程示例系统选型从HRTech到WorkTech|38合同签订此阶段,甲乙双方需要就系统价格、交付日期、售后服务、质保等问题在合同上达成协议,并签署正式合同
66、。值得注意的是,在签署正式合同之前,双方要就 SOW(工作说明书)、SLA(服务级别协议)等协商并达成一致,并将 SOW 作为合同附件。对于项目实施计划,一般在投标时会要求有初步的项目实施计划,若条件允许可以在签合同前敲定,也可以在项目成员进场后最终定稿。业务视角功能满足需求:系统功能满足业务场景需求,基本能帮助业务解决立项的业务需求。数据化管理:实现对相关数据的完善管理,实现信息化、数字化的管理方式,提高数据的准确性和可靠性。Tips业务视角业务视角功能满足需求数据化管理自定义配置用户友好可靠性协同性效率创新性灵活与扩展性成本效益安全保障IT视角IT视角HR与IT共同视角HR与IT共同视角业
67、务与IT视角下,成功选型的系统画像39|企业数字化系统选型建设指南自定义配置:支持自定义配置和灵活设置,以满足不同企业的需求和管理模式,进而使企业更好地适应不同的业务场景和组织结构。用户友好:系统简单易用,对用户友好,避免过于复杂的操作和使用方式,反应速度也要快,如果每次点击都要等几秒,则会影响使用率。IT视角可靠性:系统应当稳定、可靠,能够在长时间的运行中保持高效和稳定的表现,此外也需具备完善的安全措施,确保数据和信息的机密性和完整性。协同性:未来的数字化是协同的数字化,因此系统最好有标准接口,具备与各种系统对接协同的经验,便于进一步拓展。效率:具有高效的性能和吞吐量,支持海量数据的处理和分
68、析,同时也要保证速度和响应时间的快速性。创新性:具备创新性和前瞻性,包括新技术、新功能等方面的引入和实践,以及对未来发展趋势的关注和预测。HR与IT共同视角灵活性:具有良好的扩展性和升级性,满足企业未来业务发展和管理需求,且易于维护和升级,使得IT团队可以快速响应问题和更新需求。成本效益:具有良好的成本效益,保证系统质量和性能的情况下,最大限度地降低系统建设和运营成本,提高企业的效益。安全保障:具有良好的安全措施,包括身份认证、数据加密、权限控制等方面的保障,确保信息的机密性和完整性。实施上线实施上线的阶段性目标确保系统顺利过渡到正式运行阶段,并满足预期的业务需求,这包括试运行、纠错和优化、用
69、户培训和支持,最终正式上线,并持续改进系统以适应业务变化和发展。扫码领取配套选型知识地图41|企业数字化系统选型建设指南在系统选型完成之后,实施成为项目的新起点,上线则成为项目的新终点,能否成功实施上线是检验系统选型成果的试金石。相信主导过相关项目的你一定对此感同身受。正因如此,系统选型结束后,如何推动项目如期实施和上线将成为主要任务,我们将这个过程分为五个步骤,从项目准备到蓝图设计,再到系统实施、系统验证,直到系统上线。图13:实施上线阶段的关键角色与辅助角色实施上线阶段的关键角色与辅助角色辅助角色关键角色评估系统架构和技术方案的可行性,为IT代表提供技术指导和支持。系统架构师评估系统安全性
70、,如身 份 认 证、数 据 加密、权限控制,并提出相关建议。信息安全专家评估系统的数据处理和分析能力,包括数据存储、备份、恢复等。数据库专家评估系统的用户界面和交互设计,以确保用户友好和易用性。用户体验设计师对系统进行全面的测试和验证,确保系统符合要求并达到预期效果。系统测试人员负责整个项目进度、质量和成本管理,并协调各部门和参与者的工作。项目经理提供业务需求和流程信息,为系统设计和开发提供支持和指导。关键用户负责系统架构、设计、配置、测试和维护等方面的工作,并为关键用户提供系统技术方面的建议和指导。实施顾问负责系统设计、编码和测试等工作,以实现业务需求和技术规格。开发人员对系统进行全面的测试
71、和验证,确保系统符合要求并达到预期效果。测试人员负责控制系统变更和修复,以免影响系统正常运行。变更管理人员评估系统的数据处理和分析能力,数据存储、备份、恢复等,并主导数据的采集、清洗、转移和迁移。数据专家对最终用户进行培训和支持,使其能够熟练掌握新系统的操作和功能。培训师系统的日常运行和维护,保证系统稳定、可靠地运行。系统管理员实施上线从HRTech到WorkTech|42项目准备在项目准备阶段,需要与各相关方就项目价值、时间节点、资源投入达成共识,并正式宣布项目启动,授权项目负责人统筹资源。一般在合同签订和项目准备阶段也会安排支付项目首期款,比例由甲乙方双方协定,通常为 30%。该阶段主要涉
72、及项目团队组建、项目计划制定、项目管理规范制定、计算资源预订等工作。项目准备阶段的关键事项成立项目组织机构,明确各角色权责以及汇报关系。明确项目成员奖惩设计,项目组的工作分配和奖励,以及项目结束后安排规划等。需要将任务明确到人,例如项目经理是明确且唯一的,各业务的接口人是明确且唯一的,项目管理委员会成员,以及哪些必须出席的会议有哪些等等。需将最终用户的意见持续引入项目工作中,引导用户尽快熟悉系统后再进行优化,而且要确立以解决用户需求的思维方式来优化功能,避免管理端用户自嗨。项目管理机制一定要落地,即使没有特别重要的内容,例会仍要召开但可以快速结束,要保持各方对项目的重视程度不会降低并持续投入,
73、以及项目组内外的信息一致性,及时发现变更风险。/具体行动关键事项明确项目范围、时间计划和资源投入,澄清数字化价值的兑现时间节点。成立项目组明确实施原则和变更机制,保证实施过程中的资源投入方向。明确沟通机制,如项目周度跟踪、冲刺阶段日会、重要里程碑的委员会会议。明确交付方式,如以两周为一个迭代周期进行敏捷交付。明确项目计划遴选业务关键用户、准备开发及测试服务器、安排项目集中办公场地等。建立项目管理机制其他1234图14:项目准备阶段的关键事项蓝图设计43|企业数字化系统选型建设指南确定IT系统运维的目标和关键性能指标包括问题响应时效、需求响应时效、系统全年可用率、系统中断修复时效等。分析当前运维
74、流程的瓶颈和问题包括缺乏运维奖惩机制、运维团队资源瓶颈、新技术应用熟练度瓶颈、计算资源瓶颈、问题提报通道不完善、问题解决协同机制不完善、问题升级机制缺乏等典型问题。制定改进计划和时间表根据项目整体安排,在关键里程碑前完成相关改进,比如系统正式上线前要完成系统知识转移、运维流程设计、运维团队搭建、运维机制宣贯、运维工具准备等。分配资源和职责明确所属的人力资源、技术资源,甚至系统运营预算。比如在传统ITIL的3级运维体系中,服务台层次是IT服务管理的前沿,需快速响应客户的需求,及时解决故障并提供帮助,可能需要配置自助报障平台、智能客服,安排初级系统运维顾问响应客户问询;技术支持层次是更深入地分析和
75、解决问题,并提供更高级别的技术支持,可能需要配置问题工单调度平台,安排中高级系统运维顾问、业务关键用户来配合解决问题;运营支持层次是全面管理整个IT基础设施,并提供对业务的持续支持,可能配置系统运营监控平台,安排资深系统运维顾问、外部供应商CSM团队、业务专家来协同运维等。蓝图设计报告主要为达成两个目标:一是保证业务方对需求质量负责;二是项目变更时有依据。蓝图设计阶段主要涉及业务需求分析、解决方案制定及技术说明书编写等工作。通常会先安排实施顾问培训系统标准解决方案,在拉通系统理解的基础上,由实施顾问主导分析业务需求、制定业务流程,并明确系统化解决方案(包括并不限于系统间集成方案、线上线下协同方
76、案、报表统计分析方案等)。蓝图设计是保证交付结果的关键阶段,双方需约定明确的交付物,无论何种形式的合作,均需要签字版的需求文档作为开发基础。蓝图验收因此往往也是项目的里程碑,通常会支付一定比例的进度款。项目组在此阶段应输出蓝图设计报告,并汇报给项目经理,通过后签字验收(关键用户及项目领导在蓝图设计文档、开发计划等文档中签字确认),主要为达成两个目标:一是保证业务方对需求质量负责;二是项目变更时有依据。尤其是人事流程变更,不仅需要提供制度依据,还需要规范的流程图,若无制度支撑,项目过程中的变更风险极大。另外,流程变更时需要将流程变更带来的沟通成本和数据清洗成本一并带入考虑。3.1 根据业务蓝图设
77、计构建系统1.设计系统架构和功能a.设计系统的整体架构和模块划分,确定各个模块之间的关系和交互方式。b.定义系统的基本功能和特性,例如员工档案管理、招聘申请、培训计划制定、绩效考核等。实施上线从HRTech到WorkTech|44系统实施该阶段主要涉及“系统构建”“系统集成、定制开发”“用户培训,反馈迭代”“历史数据采集”四个阶段。下文我们归纳了每个阶段需要涉及的具体工作,供大家参考。系统实施关键环节与具体事项1.设计系统架构和功能2.设计系统配置方案3.设计数据模型4.用户界面设计5.明确定制开发点6.与利益相关者确认1.系统集成2.定制开发3.报表开发4.测试与验证5.调整与优化1.用户培
78、训2.各模块的单元测试3.测试反馈4.系统迭代与改进5.回归测试和验证1.数据源识别和准备2.数据采集计划制定3.数据采集工具和方法选择4.数据采集执行5.数据验证和校验6.数据清洗和转换7.数据导入和加载8.数据验证和回归测试根据业务蓝图设计构建系统按计划推进系统集成、定制开发等用户培训、模块单元测试和系统迭代系统初步定型后,历史数据采集图15:系统实施关键环节与具体事项确定IT系统运维的目标和关键性能指标包括问题响应时效、需求响应时效、系统全年可用率、系统中断修复时效等。分析当前运维流程的瓶颈和问题包括缺乏运维奖惩机制、运维团队资源瓶颈、新技术应用熟练度瓶颈、计算资源瓶颈、问题提报通道不完
79、善、问题解决协同机制不完善、问题升级机制缺乏等典型问题。制定改进计划和时间表根据项目整体安排,在关键里程碑前完成相关改进,比如系统正式上线前要完成系统知识转移、运维流程设计、运维团队搭建、运维机制宣贯、运维工具准备等。分配资源和职责明确所属的人力资源、技术资源,甚至系统运营预算。比如在传统ITIL的3级运维体系中,服务台层次是IT服务管理的前沿,需快速响应客户的需求,及时解决故障并提供帮助,可能需要配置自助报障平台、智能客服,安排初级系统运维顾问响应客户问询;技术支持层次是更深入地分析和解决问题,并提供更高级别的技术支持,可能需要配置问题工单调度平台,安排中高级系统运维顾问、业务关键用户来配合
80、解决问题;运营支持层次是全面管理整个IT基础设施,并提供对业务的持续支持,可能配置系统运营监控平台,安排资深系统运维顾问、外部供应商CSM团队、业务专家来协同运维等。45|企业数字化系统选型建设指南2.设计系统配置方案a.根据业务需求,配置系统的各项设置,包括组织结构设置、岗位设置、权限设置等。b.设计和配置表单、工作流程、报表和通知等,以满足特定的业务需求和流程。3.设计数据模型a.根据业务需求,设计数据模型,包括员工信息、招聘数据、工时数据、绩效数据等。b.确定数据字段、关联关系和数据存储方式,以支持后续的数据录入、查询和分析。4.设计用户界面a.设计系统的用户界面,使用户能够方便地使用系
81、统进行操作。b.考虑用户体验和界面易用性,确保系统界面设计符合用户期望和最佳实践。5.明确定制开发点a.如有需要,进行系统的定制开发,以满足特定的业务需求,如开发自定义功能、报表和集成插件等,确保系统能更好地适应组织的特殊需求。6.与利益相关者确认a.与业务部门和其他相关利益相关者沟通确认蓝图,确保系统设计和配置符合他们的期望和需求。b.反复验证和调整系统设计,以确保系统能够满足业务要求和组织的目标。确定IT系统运维的目标和关键性能指标包括问题响应时效、需求响应时效、系统全年可用率、系统中断修复时效等。分析当前运维流程的瓶颈和问题包括缺乏运维奖惩机制、运维团队资源瓶颈、新技术应用熟练度瓶颈、计
82、算资源瓶颈、问题提报通道不完善、问题解决协同机制不完善、问题升级机制缺乏等典型问题。制定改进计划和时间表根据项目整体安排,在关键里程碑前完成相关改进,比如系统正式上线前要完成系统知识转移、运维流程设计、运维团队搭建、运维机制宣贯、运维工具准备等。分配资源和职责明确所属的人力资源、技术资源,甚至系统运营预算。比如在传统ITIL的3级运维体系中,服务台层次是IT服务管理的前沿,需快速响应客户的需求,及时解决故障并提供帮助,可能需要配置自助报障平台、智能客服,安排初级系统运维顾问响应客户问询;技术支持层次是更深入地分析和解决问题,并提供更高级别的技术支持,可能需要配置问题工单调度平台,安排中高级系统
83、运维顾问、业务关键用户来配合解决问题;运营支持层次是全面管理整个IT基础设施,并提供对业务的持续支持,可能配置系统运营监控平台,安排资深系统运维顾问、外部供应商CSM团队、业务专家来协同运维等。实施上线从HRTech到WorkTech|463.2 按开发计划推进系统集成、定制开发等1.系统集成a.确定系统需要集成的其他系统或组件,如薪酬系统、考勤系统、培训系统。b.设计和开发集成接口,用于数据传输和信息共享。c.进行集成测试,验证各系统之间的数据流动和功能交互是否正常。2.定制开发a.根据业务需求,进行系统的定制开发,以满足特定的业务流程或功能需求。b.开发自定义模块、功能或工作流程,以适应组
84、织的特殊需求。c.编写代码并进行单元测试,确保定制开发的功能按预期工作。3.报表开发a.根据业务部门和管理层的需求,设计和开发各种类型的报表,用于人力资源数据分析和决策支持。b.确定报表的数据源和指标,选择合适的图表和格式展示数据。c.使用报表开发工具或编程语言,根据需求创建和配置报表,并进行测试和调试。4.测试与验证a.进行系统集成测试,验证系统在集成环境中的功能和性能。b.进行定制开发的测试,确保定制的功能与系统的其他部分协调一致。c.进行报表测试,验证报表的准确性和可用性。确定IT系统运维的目标和关键性能指标包括问题响应时效、需求响应时效、系统全年可用率、系统中断修复时效等。分析当前运维
85、流程的瓶颈和问题包括缺乏运维奖惩机制、运维团队资源瓶颈、新技术应用熟练度瓶颈、计算资源瓶颈、问题提报通道不完善、问题解决协同机制不完善、问题升级机制缺乏等典型问题。制定改进计划和时间表根据项目整体安排,在关键里程碑前完成相关改进,比如系统正式上线前要完成系统知识转移、运维流程设计、运维团队搭建、运维机制宣贯、运维工具准备等。分配资源和职责明确所属的人力资源、技术资源,甚至系统运营预算。比如在传统ITIL的3级运维体系中,服务台层次是IT服务管理的前沿,需快速响应客户的需求,及时解决故障并提供帮助,可能需要配置自助报障平台、智能客服,安排初级系统运维顾问响应客户问询;技术支持层次是更深入地分析和
86、解决问题,并提供更高级别的技术支持,可能需要配置问题工单调度平台,安排中高级系统运维顾问、业务关键用户来配合解决问题;运营支持层次是全面管理整个IT基础设施,并提供对业务的持续支持,可能配置系统运营监控平台,安排资深系统运维顾问、外部供应商CSM团队、业务专家来协同运维等。47|企业数字化系统选型建设指南5.调整和优化a.根据测试结果和用户反馈,调整和优化系统。b.修复集成问题、定制开发中的缺陷,并确保系统的稳定性和可靠性。c.改进报表布局、数据源和性能,以提供更好的数据分析和展示效果。3.3 用户培训、模块单元测试和系统迭代等1.用户培训a.根据系统设计和功能,制定培训计划和材料,为系统的最
87、终用户提供必要的培训和指导。b.培训用户熟悉系统的基本操作,例如登录、数据录入、查询、报表生成。c.介绍系统各个模块和功能,帮助用户了解如何使用系统来支持他们的日常工作。2.系统模块的单元测试a.将系统按照不同模块进行划分,对每个模块进行单元测试。b.设计测试用例,覆盖各种典型和边界情况,确保每个模块的功能符合预期。c.参照测试用例开展测试,记录测试结果和发现的问题。3.测试反馈a.收集测试人员的反馈和建议,包括系统的缺陷、功能不完善或需改进之处。b.根据测试结果和反馈,整理和归类问题,确定优先级和紧急程度。确定IT系统运维的目标和关键性能指标包括问题响应时效、需求响应时效、系统全年可用率、系
88、统中断修复时效等。分析当前运维流程的瓶颈和问题包括缺乏运维奖惩机制、运维团队资源瓶颈、新技术应用熟练度瓶颈、计算资源瓶颈、问题提报通道不完善、问题解决协同机制不完善、问题升级机制缺乏等典型问题。制定改进计划和时间表根据项目整体安排,在关键里程碑前完成相关改进,比如系统正式上线前要完成系统知识转移、运维流程设计、运维团队搭建、运维机制宣贯、运维工具准备等。分配资源和职责明确所属的人力资源、技术资源,甚至系统运营预算。比如在传统ITIL的3级运维体系中,服务台层次是IT服务管理的前沿,需快速响应客户的需求,及时解决故障并提供帮助,可能需要配置自助报障平台、智能客服,安排初级系统运维顾问响应客户问询
89、;技术支持层次是更深入地分析和解决问题,并提供更高级别的技术支持,可能需要配置问题工单调度平台,安排中高级系统运维顾问、业务关键用户来配合解决问题;运营支持层次是全面管理整个IT基础设施,并提供对业务的持续支持,可能配置系统运营监控平台,安排资深系统运维顾问、外部供应商CSM团队、业务专家来协同运维等。实施上线从HRTech到WorkTech|48c.与开发团队和项目经理共享测试反馈,以便修复和改进问题。4.系统迭代和改进a.针对测试反馈中的问题,迭代和改进系统。b.缺陷修复,解决已发现的问题和异常行为。c.对功能不完善或需改进之处进行优化,以提升系统的性能和用户体验。5.回归测试和验证a.迭
90、代和改进后,重新执行相关的单元测试用例来验证修复和改进是否有效。b.进行系统的回归测试,确保修复问题不影响其他功能,并保证整体稳定性和可靠性。3.4 系统初步定型后,历史数据采集1.数据源识别和准备a.确定历史数据的来源,例如现有的管理系统、Excel 表格、纸质档案等。b.收集并整理历史数据,确保数据的完整性和可用性。2.数据采集计划制定a.制定数据采集计划,明确采集目标、范围和时间表。b.确定采集方式,例如手动输入、批量导入或数据集成。3.数据采集工具和方法选择。确定IT系统运维的目标和关键性能指标包括问题响应时效、需求响应时效、系统全年可用率、系统中断修复时效等。分析当前运维流程的瓶颈和
91、问题包括缺乏运维奖惩机制、运维团队资源瓶颈、新技术应用熟练度瓶颈、计算资源瓶颈、问题提报通道不完善、问题解决协同机制不完善、问题升级机制缺乏等典型问题。制定改进计划和时间表根据项目整体安排,在关键里程碑前完成相关改进,比如系统正式上线前要完成系统知识转移、运维流程设计、运维团队搭建、运维机制宣贯、运维工具准备等。分配资源和职责明确所属的人力资源、技术资源,甚至系统运营预算。比如在传统ITIL的3级运维体系中,服务台层次是IT服务管理的前沿,需快速响应客户的需求,及时解决故障并提供帮助,可能需要配置自助报障平台、智能客服,安排初级系统运维顾问响应客户问询;技术支持层次是更深入地分析和解决问题,并
92、提供更高级别的技术支持,可能需要配置问题工单调度平台,安排中高级系统运维顾问、业务关键用户来配合解决问题;运营支持层次是全面管理整个IT基础设施,并提供对业务的持续支持,可能配置系统运营监控平台,安排资深系统运维顾问、外部供应商CSM团队、业务专家来协同运维等。49|企业数字化系统选型建设指南a.根据数据源的类型和数量,选择适当的数据采集工具或方法。b.如果需要手动输入数据,提供数据采集模板或指导来规范数据录入。4.数据采集执行a.执行数据采集计划,按照设定的时间表和采集方式进行数据采集。b.按照预定的数据字段和格式采集数据,确保数据的准确性和一致性。5.数据验证和校验a.验证和校验采集的数据
93、,确保数据的完整性和合法性。b.检查数据的有效性、一致性以及与其他系统或数据源的匹配性。6.数据清洗和转换a.对采集的数据进行清洗和转换,处理无效数据、重复数据和缺失数据。b.转换数据为系统可接受的格式,进行必要的数据映射和转换。7.数据导入和加载a.将经过清洗和转换的历史数据导入系统中的相应模块和表格。b.数据导入测试,确保数据导入的准确性和完整性。8.数据验证和回归测试a.对导入的历史数据进行验证和回归测试,确保数据导入不影响系统其他功能和流程的正常运行。确定IT系统运维的目标和关键性能指标包括问题响应时效、需求响应时效、系统全年可用率、系统中断修复时效等。分析当前运维流程的瓶颈和问题包括
94、缺乏运维奖惩机制、运维团队资源瓶颈、新技术应用熟练度瓶颈、计算资源瓶颈、问题提报通道不完善、问题解决协同机制不完善、问题升级机制缺乏等典型问题。制定改进计划和时间表根据项目整体安排,在关键里程碑前完成相关改进,比如系统正式上线前要完成系统知识转移、运维流程设计、运维团队搭建、运维机制宣贯、运维工具准备等。分配资源和职责明确所属的人力资源、技术资源,甚至系统运营预算。比如在传统ITIL的3级运维体系中,服务台层次是IT服务管理的前沿,需快速响应客户的需求,及时解决故障并提供帮助,可能需要配置自助报障平台、智能客服,安排初级系统运维顾问响应客户问询;技术支持层次是更深入地分析和解决问题,并提供更高
95、级别的技术支持,可能需要配置问题工单调度平台,安排中高级系统运维顾问、业务关键用户来配合解决问题;运营支持层次是全面管理整个IT基础设施,并提供对业务的持续支持,可能配置系统运营监控平台,安排资深系统运维顾问、外部供应商CSM团队、业务专家来协同运维等。实施上线从HRTech到WorkTech|50首先,在前期需求调研的过程中,真正的用户是否参与了调研,而不是他们的需求被转述被加工,以至于真正的需求在交付过程中才爆发。其次,关于招标书的撰写。在需求调研真实完整的情况下,是否清晰完整地在招标书中呈现了。对于此,我们建议在写招标书过程中也要与内部的利益相关者充分沟通,确保是大家一致认可的,同时也要
96、明确梳理出哪些是系统功能性需求,哪些是非功能性需求,这关乎到供应商报价,如果交付过程中再重新谈判商务,也会影响项目交付周期。其三,对于项目交付过程中无法避免的新需求的取舍,首先确定需求的优先级,哪些是 must have,哪些是nice to have,哪些放在一期,哪些放在二期,避免后期交付时候产生争议;其次对于当下必须“加塞儿”的需求,我们需要平衡好业务需求和供应商的关系。如果认为新加的需求是 must have,那能否暂时放弃其他次要需求,保证一期项目顺利推进,而不是一直处于失控状态。业务需求总变来变去,如何控制好项目的范围?The consultant said顾问说常晓东施耐德电气
97、人力资源信息化高级经理 确定IT系统运维的目标和关键性能指标包括问题响应时效、需求响应时效、系统全年可用率、系统中断修复时效等。分析当前运维流程的瓶颈和问题包括缺乏运维奖惩机制、运维团队资源瓶颈、新技术应用熟练度瓶颈、计算资源瓶颈、问题提报通道不完善、问题解决协同机制不完善、问题升级机制缺乏等典型问题。制定改进计划和时间表根据项目整体安排,在关键里程碑前完成相关改进,比如系统正式上线前要完成系统知识转移、运维流程设计、运维团队搭建、运维机制宣贯、运维工具准备等。分配资源和职责明确所属的人力资源、技术资源,甚至系统运营预算。比如在传统ITIL的3级运维体系中,服务台层次是IT服务管理的前沿,需快
98、速响应客户的需求,及时解决故障并提供帮助,可能需要配置自助报障平台、智能客服,安排初级系统运维顾问响应客户问询;技术支持层次是更深入地分析和解决问题,并提供更高级别的技术支持,可能需要配置问题工单调度平台,安排中高级系统运维顾问、业务关键用户来配合解决问题;运营支持层次是全面管理整个IT基础设施,并提供对业务的持续支持,可能配置系统运营监控平台,安排资深系统运维顾问、外部供应商CSM团队、业务专家来协同运维等。51|企业数字化系统选型建设指南系统验证我们可将系统验证分为跨模块集成测试、跨系统集成测试、系统性能测试和最终用户测试四个部分,每个部分的具体执行流程如下文总结。系统实施关键环节与具体事
99、项1.确定集成测试范围和目标2.设计集成测试用例3.准备测试环境4.执行集成测试用例5.检查数据一致性和正确性6.测试报告和问题追踪7.回归测试验证与其他关联系统(如财务系统、身份认证系统等)之间的数据传输、功能交互和流程协同是否正常,确保与外部系统有效集成。1.确定性能测试目标和指标2.设计性能测试场景和负载 模型3.设置测试环境和工具4.编写性能测试脚本5.执行性能测试6.收集和分析性能数据7.性能调优和优化8.性能测试报告和总结1.确定验收标准和目标2.编写验收测试计划和用例3.配置验收测试环境4.进行验收测试5.反馈问题和改进意见6.回归测试和确讪7.用户验收测试报告和总结跨模块集成测
100、试跨系统集成测试系统性能测试最终用户验收测试图16:系统验证关键环节与具体事项4.1 跨模块集成测试1.确定集成测试范围和目标a.确定需要跨模块集成测试的模块和功能。b.确定集成测试的目标,例如验证数据传输、功能交互和流程协同等。2.设计集成测试用例a.根据系统设计和业务需求,设计跨模块的集成测试用例。b.考虑不同场景和可能的异常情况,覆盖各种典型和边界情况。确定IT系统运维的目标和关键性能指标包括问题响应时效、需求响应时效、系统全年可用率、系统中断修复时效等。分析当前运维流程的瓶颈和问题包括缺乏运维奖惩机制、运维团队资源瓶颈、新技术应用熟练度瓶颈、计算资源瓶颈、问题提报通道不完善、问题解决协
101、同机制不完善、问题升级机制缺乏等典型问题。制定改进计划和时间表根据项目整体安排,在关键里程碑前完成相关改进,比如系统正式上线前要完成系统知识转移、运维流程设计、运维团队搭建、运维机制宣贯、运维工具准备等。分配资源和职责明确所属的人力资源、技术资源,甚至系统运营预算。比如在传统ITIL的3级运维体系中,服务台层次是IT服务管理的前沿,需快速响应客户的需求,及时解决故障并提供帮助,可能需要配置自助报障平台、智能客服,安排初级系统运维顾问响应客户问询;技术支持层次是更深入地分析和解决问题,并提供更高级别的技术支持,可能需要配置问题工单调度平台,安排中高级系统运维顾问、业务关键用户来配合解决问题;运营
102、支持层次是全面管理整个IT基础设施,并提供对业务的持续支持,可能配置系统运营监控平台,安排资深系统运维顾问、外部供应商CSM团队、业务专家来协同运维等。实施上线从HRTech到WorkTech|523.准备测试环境a.搭建适应集成测试的环境,包括模拟生产环境或使用真实数据。b.配置必要的硬件、网络和软件环境,以确保系统正常运行。4.执行集成测试用例a.根据设计好的集成测试用例,执行跨模块的集成测试。b.模拟用户操作和交互,验证不同模块之间的数据传输和功能交互是否正常。5.检查数据一致性和正确性a.检查不同模块之间的数据一致性,确保数据在各模块之间能够正确传递和同步更新。b.验证数据在跨模块操作
103、后的正确性,如员工信息在薪酬模块与人事模块的一致性。6.测试报告和问题追踪a.记录集成测试的执行过程、结果和发现的问题。b.编写集成测试报告,总结测试结果和风险评估。c.跟踪和解决发现的问题,确保问题及时修复。7.回归测试a.在修复集成测试中发现问题后,进行回归测试,确保修复不影响其他模块的正常功能。b.验证集成测试中通过的功能仍然正常运行,并检查其他模块的影响范围。确定IT系统运维的目标和关键性能指标包括问题响应时效、需求响应时效、系统全年可用率、系统中断修复时效等。分析当前运维流程的瓶颈和问题包括缺乏运维奖惩机制、运维团队资源瓶颈、新技术应用熟练度瓶颈、计算资源瓶颈、问题提报通道不完善、问
104、题解决协同机制不完善、问题升级机制缺乏等典型问题。制定改进计划和时间表根据项目整体安排,在关键里程碑前完成相关改进,比如系统正式上线前要完成系统知识转移、运维流程设计、运维团队搭建、运维机制宣贯、运维工具准备等。分配资源和职责明确所属的人力资源、技术资源,甚至系统运营预算。比如在传统ITIL的3级运维体系中,服务台层次是IT服务管理的前沿,需快速响应客户的需求,及时解决故障并提供帮助,可能需要配置自助报障平台、智能客服,安排初级系统运维顾问响应客户问询;技术支持层次是更深入地分析和解决问题,并提供更高级别的技术支持,可能需要配置问题工单调度平台,安排中高级系统运维顾问、业务关键用户来配合解决问
105、题;运营支持层次是全面管理整个IT基础设施,并提供对业务的持续支持,可能配置系统运营监控平台,安排资深系统运维顾问、外部供应商CSM团队、业务专家来协同运维等。53|企业数字化系统选型建设指南4.2 跨系统集成测试跨系统集成测试主要为验证与关联系统(如财务系统、身份认证系统等)之间的数据传输、功能交互和流程协同是否正常,确保与外部系统的有效集成。4.3 系统性能测试1.确定性能测试目标和指标a.根据业务需求和用户预期,确定系统性能测试的目标和关键性能指标,如响应时间、吞吐量和并发用户数等。2.设计性能测试场景和负载模型a.基于真实的业务场景和使用情况,设计合适的性能测试场景。b.创建负载模型,
106、模拟用户行为和操作,以及预估的并发用户数。3.设置测试环境和工具a.搭建符合性能测试要求的测试环境,包括硬件、软件和网络等资源。b.选择合适的性能测试工具,如 LoadRunner、JMeter 等,用于执行性能测试脚本和收集性能数据。4.编写性能测试脚本a.根据设计好的性能测试场景和负载模型,编写性能测试脚本。b.脚本包括模拟用户行为、请求发送和数据处理等步骤,以验证系统在不同负载下的性能表现。5.执行性能测试确定IT系统运维的目标和关键性能指标包括问题响应时效、需求响应时效、系统全年可用率、系统中断修复时效等。分析当前运维流程的瓶颈和问题包括缺乏运维奖惩机制、运维团队资源瓶颈、新技术应用熟
107、练度瓶颈、计算资源瓶颈、问题提报通道不完善、问题解决协同机制不完善、问题升级机制缺乏等典型问题。制定改进计划和时间表根据项目整体安排,在关键里程碑前完成相关改进,比如系统正式上线前要完成系统知识转移、运维流程设计、运维团队搭建、运维机制宣贯、运维工具准备等。分配资源和职责明确所属的人力资源、技术资源,甚至系统运营预算。比如在传统ITIL的3级运维体系中,服务台层次是IT服务管理的前沿,需快速响应客户的需求,及时解决故障并提供帮助,可能需要配置自助报障平台、智能客服,安排初级系统运维顾问响应客户问询;技术支持层次是更深入地分析和解决问题,并提供更高级别的技术支持,可能需要配置问题工单调度平台,安
108、排中高级系统运维顾问、业务关键用户来配合解决问题;运营支持层次是全面管理整个IT基础设施,并提供对业务的持续支持,可能配置系统运营监控平台,安排资深系统运维顾问、外部供应商CSM团队、业务专家来协同运维等。实施上线从HRTech到WorkTech|54a.使用性能测试工具,按照设定好的负载模型和性能测试脚本,执行性能测试。b.监控系统各项性能指标,在不同负载下进行压力测试、负载测试和性能度量。6.收集和分析性能数据a.在性能测试过程中,收集系统各项性能数据,如响应时间、吞吐量、错误率等。b.分析和评估性能数据,找出系统存在的性能问题和瓶颈,并提出优化建议。7.性能调优和优化a.分析性能测试结果
109、,针对性能问题进行调优和优化。b.采取一些优化措施,如数据库索引优化、代码改进、系统配置调整,以提高系统的性能表现。8.性能测试报告和总结a.编写性能测试报告,总结性能测试的结果,评估系统的性能表现。b.提供给相关团队和决策者参考,用于优化系统和制定性能调整方案。4.4 最终用户验收测试1.确定验收标准和目标a.与业务代表和最终用户沟通,明确系统的验收标准和目标。b.定义系统功能、界面、性能和安全等方面的验收要求。确定IT系统运维的目标和关键性能指标包括问题响应时效、需求响应时效、系统全年可用率、系统中断修复时效等。分析当前运维流程的瓶颈和问题包括缺乏运维奖惩机制、运维团队资源瓶颈、新技术应用
110、熟练度瓶颈、计算资源瓶颈、问题提报通道不完善、问题解决协同机制不完善、问题升级机制缺乏等典型问题。制定改进计划和时间表根据项目整体安排,在关键里程碑前完成相关改进,比如系统正式上线前要完成系统知识转移、运维流程设计、运维团队搭建、运维机制宣贯、运维工具准备等。分配资源和职责明确所属的人力资源、技术资源,甚至系统运营预算。比如在传统ITIL的3级运维体系中,服务台层次是IT服务管理的前沿,需快速响应客户的需求,及时解决故障并提供帮助,可能需要配置自助报障平台、智能客服,安排初级系统运维顾问响应客户问询;技术支持层次是更深入地分析和解决问题,并提供更高级别的技术支持,可能需要配置问题工单调度平台,
111、安排中高级系统运维顾问、业务关键用户来配合解决问题;运营支持层次是全面管理整个IT基础设施,并提供对业务的持续支持,可能配置系统运营监控平台,安排资深系统运维顾问、外部供应商CSM团队、业务专家来协同运维等。55|企业数字化系统选型建设指南2.编写验收测试计划和用例a.根据系统需求规格和用户需求,编写详细的验收测试计划。b.设计验收测试用例,覆盖核心业务流程和常见的用户操作场景。3.配置验收测试环境a.搭建适合最终用户验收测试的环境,包括硬件、网络和软件设备。b.确保测试环境与实际生产环境尽可能接近,以提供真实的用户体验。4.进行验收测试a.根据编写好的验收测试用例,执行各项测试,并记录测试结
112、果和问题。b.对系统的功能、界面、性能、数据准确性等进行验证,确保系统满足用户需求和预期。5.反馈问题和改进意见a.记录发现的问题,并及时反馈给项目团队和开发人员。b.提供改进意见和建议,帮助优化系统的功能和用户体验。6.回归测试和确认a.问题修复后,对已修复的问题进行回归测试,并确保问题得到解决。b.确认系统是否达到了用户的验收标准和目标,满足使用要求。7.用户验收测试报告和总结a.撰写用户验收测试报告,总结测试结果和评估系统的质量。b.提供给相关团队和决策者参考,以便决策和推进系统上线或进一步改进。确定IT系统运维的目标和关键性能指标包括问题响应时效、需求响应时效、系统全年可用率、系统中断
113、修复时效等。分析当前运维流程的瓶颈和问题包括缺乏运维奖惩机制、运维团队资源瓶颈、新技术应用熟练度瓶颈、计算资源瓶颈、问题提报通道不完善、问题解决协同机制不完善、问题升级机制缺乏等典型问题。制定改进计划和时间表根据项目整体安排,在关键里程碑前完成相关改进,比如系统正式上线前要完成系统知识转移、运维流程设计、运维团队搭建、运维机制宣贯、运维工具准备等。分配资源和职责明确所属的人力资源、技术资源,甚至系统运营预算。比如在传统ITIL的3级运维体系中,服务台层次是IT服务管理的前沿,需快速响应客户的需求,及时解决故障并提供帮助,可能需要配置自助报障平台、智能客服,安排初级系统运维顾问响应客户问询;技术
114、支持层次是更深入地分析和解决问题,并提供更高级别的技术支持,可能需要配置问题工单调度平台,安排中高级系统运维顾问、业务关键用户来配合解决问题;运营支持层次是全面管理整个IT基础设施,并提供对业务的持续支持,可能配置系统运营监控平台,安排资深系统运维顾问、外部供应商CSM团队、业务专家来协同运维等。实施上线从HRTech到WorkTech|56系统上线首次上线若没准备充分通常会导致用户第一印象非常不好,进而影响下一阶段的配合度。因此,虽然系统上线是实施阶段的最后一步,但最后一公里的工作中仍存在一些不可忽视的风险,例如,数据丢失或损坏:在数据迁移过程中,可能会出现数据丢失、损坏或转换错误的情况,导
115、致生产环境中的数据不准确或不完整。系统兼容性问题:在目标生产环境中,可能存在与系统不兼容的硬件设备、操作系统或网络配置,导致系统无法正常运行。性能问题:在生产环境中,系统可能面临更大的负载和并发操作,如果未经过充分的性能测试和优化,可能导致系统响应变慢或崩溃。用户培训不足:如果用户没有得到足够的培训和指导,可能会导致对新系统的使用困惑和错误操作,影响正常的业务运行。运维支持不足:缺乏有效的系统监控、故障排除和技术支持,可能导致对系统问题的响应和解决不及时。为此,我们也整理了在系统上线阶段的一些关键事项,以及对应的具体行动和注意事项,以最大限度地降低潜在风险,并确保顺利将系统引入到生产环境中,提
116、供稳定和高效的系统服务。确定IT系统运维的目标和关键性能指标包括问题响应时效、需求响应时效、系统全年可用率、系统中断修复时效等。分析当前运维流程的瓶颈和问题包括缺乏运维奖惩机制、运维团队资源瓶颈、新技术应用熟练度瓶颈、计算资源瓶颈、问题提报通道不完善、问题解决协同机制不完善、问题升级机制缺乏等典型问题。制定改进计划和时间表根据项目整体安排,在关键里程碑前完成相关改进,比如系统正式上线前要完成系统知识转移、运维流程设计、运维团队搭建、运维机制宣贯、运维工具准备等。分配资源和职责明确所属的人力资源、技术资源,甚至系统运营预算。比如在传统ITIL的3级运维体系中,服务台层次是IT服务管理的前沿,需快
117、速响应客户的需求,及时解决故障并提供帮助,可能需要配置自助报障平台、智能客服,安排初级系统运维顾问响应客户问询;技术支持层次是更深入地分析和解决问题,并提供更高级别的技术支持,可能需要配置问题工单调度平台,安排中高级系统运维顾问、业务关键用户来配合解决问题;运营支持层次是全面管理整个IT基础设施,并提供对业务的持续支持,可能配置系统运营监控平台,安排资深系统运维顾问、外部供应商CSM团队、业务专家来协同运维等。57|企业数字化系统选型建设指南确定IT系统运维的目标和关键性能指标包括问题响应时效、需求响应时效、系统全年可用率、系统中断修复时效等。分析当前运维流程的瓶颈和问题包括缺乏运维奖惩机制、
118、运维团队资源瓶颈、新技术应用熟练度瓶颈、计算资源瓶颈、问题提报通道不完善、问题解决协同机制不完善、问题升级机制缺乏等典型问题。制定改进计划和时间表根据项目整体安排,在关键里程碑前完成相关改进,比如系统正式上线前要完成系统知识转移、运维流程设计、运维团队搭建、运维机制宣贯、运维工具准备等。分配资源和职责明确所属的人力资源、技术资源,甚至系统运营预算。比如在传统ITIL的3级运维体系中,服务台层次是IT服务管理的前沿,需快速响应客户的需求,及时解决故障并提供帮助,可能需要配置自助报障平台、智能客服,安排初级系统运维顾问响应客户问询;技术支持层次是更深入地分析和解决问题,并提供更高级别的技术支持,可
119、能需要配置问题工单调度平台,安排中高级系统运维顾问、业务关键用户来配合解决问题;运营支持层次是全面管理整个IT基础设施,并提供对业务的持续支持,可能配置系统运营监控平台,安排资深系统运维顾问、外部供应商CSM团队、业务专家来协同运维等。确保系统已经过开发、测试和用户验收等阶段,并通过相关测试和审批。确保系统的部署包已准备就绪,包括软件安装文件、数据库脚本、配置文件等。关键事项与行动关键阶段确保目标生产环境已准备好:包括硬件设备、网络连接、数据库服务器等。配置和调整生产环境:确保它能够满足系统的运行需求和性能要求。系统准备将系统的部署包进行生产环境的安装和部署。配置系统参数、启动服务和应用程序,
120、确保系统能够正常运行。环境准备测试范围:主要包括功能、性能、安全测试等,减少上线后出现严重缺陷的可能性。测试的完整性和准确性:在测试前需制定全面的测试计划,避免出现遗漏测试用例、测试环境与生产环境不一致;也需建立与生产环境相似的测试环境,确保测试结果准确。测试周期:针对关键功能还需选取试点区域单独进行一个周期的试运行,通常为一个月。系统配置和参数设置:在生产环境中根据实际负载和使用情况调整系统配置和参数,优化系统性能和稳定性。压力测试和负载测试:验证系统在高并发和大数据量场景下的性能表现。培训资源:提供使用指南、培训视频和培训材料,在UAT阶段的实际操作和示范。在线帮助中心:提供定期的培训和支
121、持,让最终用户能够更好地理解并正确使用系统。运维机制:建立系统监控和运维支持机制(包括培训甲方运维团队、做好知识转移,设计运维机制等),确保及时检测系统问题并提供支持和维护。监控预警:配置监控工具和报警系统,以便在系统出现异常或故障时能够及时发现和响应。数据迁移:将现有的数据迁移至生产环境,确保数据的完整准确性。数据备份:设计数据迁移策略,根据数据量和迁移方式,进行数据迁移操作。确定上线时间:与相关团队和用户协商确定适合各方的上线时间,最好选择非核心业务期间或低峰时段上线。制定上线策略:根据实施过程中的项目进展和风险评估,确定适当的上线策略,如全面上线、分阶段上线或并行运行新旧系统。定义上线步
122、骤:列出实施阶段剩余的工作和任务,如数据迁移、系统部署、功能验证等,并将这些工作安排到具体的上线步骤,以及每个步骤的时间估计。确定责任人和资源:确保负责每个上线步骤的责任人具备相关技术能力和知识,充分安排和准备上线所需的资源(人员、设备、软件)。风险评估和应对:评估每个上线步骤可能存在的潜在风险、可能的问题和故障,并制定相应的应对措施,规划补救、回滚和恢复计划。沟通和培训:向相关团队、用户和利益相关者传达上线计划和时间表,确保每个人都了解上线的重要性和影响。上线节奏:确保系统从开发或测试环境平稳过渡至生产环境,避免影响用户和业务流程。上线策略:设计合适的上线策略,如逐步上线、灰度发布,逐渐将流
123、量从旧系统转移到新系统。风险管理:制定相应的规避策略,例如制定备用计划,确保在出现问题时能够快速回滚。验证监督:系统上线后进行验证和监督,确保系统正常运行,数据正确录入和处理。用户反馈跟踪:及时收集用户反馈和问题,并跟进和解决。系统部署功能验证上线前测试性能优化终端用户培训系统监控及运维支持数据迁移制定上线计划按计划切换上线上线验证和监督监控与优化12345 67891011系统上线关键阶段与具体事项图17:系统上线关键阶段与具体事项实施上线从HRTech到WorkTech|58确定IT系统运维的目标和关键性能指标包括问题响应时效、需求响应时效、系统全年可用率、系统中断修复时效等。分析当前运维
124、流程的瓶颈和问题包括缺乏运维奖惩机制、运维团队资源瓶颈、新技术应用熟练度瓶颈、计算资源瓶颈、问题提报通道不完善、问题解决协同机制不完善、问题升级机制缺乏等典型问题。制定改进计划和时间表根据项目整体安排,在关键里程碑前完成相关改进,比如系统正式上线前要完成系统知识转移、运维流程设计、运维团队搭建、运维机制宣贯、运维工具准备等。分配资源和职责明确所属的人力资源、技术资源,甚至系统运营预算。比如在传统ITIL的3级运维体系中,服务台层次是IT服务管理的前沿,需快速响应客户的需求,及时解决故障并提供帮助,可能需要配置自助报障平台、智能客服,安排初级系统运维顾问响应客户问询;技术支持层次是更深入地分析和
125、解决问题,并提供更高级别的技术支持,可能需要配置问题工单调度平台,安排中高级系统运维顾问、业务关键用户来配合解决问题;运营支持层次是全面管理整个IT基础设施,并提供对业务的持续支持,可能配置系统运营监控平台,安排资深系统运维顾问、外部供应商CSM团队、业务专家来协同运维等。系统成功上线,业务部门却不用?杨洋某民企数据中心总助 15年集团化企业数字化转型建设经验深度参与开发、实施的项目100+The consultant said顾问说这是企业系统实施上线常常发生的问题,直接关系到项目能否成功体现最终的价值。很多企业上线系统的时候十万火急,买了系统之后半年不会登录一次,也不及时更新数据,运用数据
126、时候发现是错乱的。因为错乱更不愿意用,陷入恶性循环,最后得出结论项目没有价值。问题背后,我认为原因在于企业没有完善数字化运营机制保证系统的使用率,如使用者是谁?用得怎么样?用得不好怎么办?数据时效性和有效性能否保障?除运营机制外,我们还要从项目全局角度来分析这一问题,例如需求共识、业务部门参与度、业务部门对项目的期望值、上线过程中的“意见领袖”管理。需求达成共识:业务需求的可行性和实现策略需要达成共识,部门提出的需求哪些可以实现,哪些暂时无法实现,需要放置二期项目,“什么都想要”带来的结果可能就是“什么都得不到”。保证业务的参与度:需求达成共识后,有的业务部门会认为,公司有专业的技术团队,也找
127、了专业厂商,他们也都清楚了解我的需求,所以就不参与了,你们看着办。但是当项目最终交付时发现,需求不是我想要的。要不重新调整,项目拖延,成本增加,要么不使用,最后项目很可能不了了之。管理业务的期望值:在业务部门的脑海中,系统上线成功后,立即就能够快速帮他们解决问题,但实际上,大多数系统上线之后都要与原来的管理流程、管理模式磨合,经历一段磨合期并优化之后才能慢慢达到理想状态,而且也并非完美状态。这段磨合59|企业数字化系统选型建设指南确定IT系统运维的目标和关键性能指标包括问题响应时效、需求响应时效、系统全年可用率、系统中断修复时效等。分析当前运维流程的瓶颈和问题包括缺乏运维奖惩机制、运维团队资源
128、瓶颈、新技术应用熟练度瓶颈、计算资源瓶颈、问题提报通道不完善、问题解决协同机制不完善、问题升级机制缺乏等典型问题。制定改进计划和时间表根据项目整体安排,在关键里程碑前完成相关改进,比如系统正式上线前要完成系统知识转移、运维流程设计、运维团队搭建、运维机制宣贯、运维工具准备等。分配资源和职责明确所属的人力资源、技术资源,甚至系统运营预算。比如在传统ITIL的3级运维体系中,服务台层次是IT服务管理的前沿,需快速响应客户的需求,及时解决故障并提供帮助,可能需要配置自助报障平台、智能客服,安排初级系统运维顾问响应客户问询;技术支持层次是更深入地分析和解决问题,并提供更高级别的技术支持,可能需要配置问
129、题工单调度平台,安排中高级系统运维顾问、业务关键用户来配合解决问题;运营支持层次是全面管理整个IT基础设施,并提供对业务的持续支持,可能配置系统运营监控平台,安排资深系统运维顾问、外部供应商CSM团队、业务专家来协同运维等。期的工作效率甚至还不如原来高,系统因此也容易在这被判了“死刑”,然后业务部门又继续用原来的Excel 处理,系统搁置一边。管理“意见领袖”:每一个管理变革都会有先锋代表,他们愿意尝试,愿意容忍变革之初的“瑕疵”,但与此同时,每一个变革团队中,也有“天生”的阻碍者,他们不愿意接受新事物,不愿意进化,而且很可能特别强势,因为不愿意接受改变,“想办法”破坏项目。因此在项目上线后,
130、我们需要尽可能让先锋代表发声,让他们的声音成为主流,并留意变革中的阻碍势力,提前预防应对。扫码领取配套选型知识地图确定IT系统运维的目标和关键性能指标包括问题响应时效、需求响应时效、系统全年可用率、系统中断修复时效等。分析当前运维流程的瓶颈和问题包括缺乏运维奖惩机制、运维团队资源瓶颈、新技术应用熟练度瓶颈、计算资源瓶颈、问题提报通道不完善、问题解决协同机制不完善、问题升级机制缺乏等典型问题。制定改进计划和时间表根据项目整体安排,在关键里程碑前完成相关改进,比如系统正式上线前要完成系统知识转移、运维流程设计、运维团队搭建、运维机制宣贯、运维工具准备等。分配资源和职责明确所属的人力资源、技术资源,
131、甚至系统运营预算。比如在传统ITIL的3级运维体系中,服务台层次是IT服务管理的前沿,需快速响应客户的需求,及时解决故障并提供帮助,可能需要配置自助报障平台、智能客服,安排初级系统运维顾问响应客户问询;技术支持层次是更深入地分析和解决问题,并提供更高级别的技术支持,可能需要配置问题工单调度平台,安排中高级系统运维顾问、业务关键用户来配合解决问题;运营支持层次是全面管理整个IT基础设施,并提供对业务的持续支持,可能配置系统运营监控平台,安排资深系统运维顾问、外部供应商CSM团队、业务专家来协同运维等。运维服务运维服务的阶段性目标明确项目各成员的任务分工,在项目资源有限的情况下,能承接更多工作,保
132、证上线前期平稳过渡以及平稳之后仍能高效协同。扫码领取配套选型知识地图61|企业数字化系统选型建设指南确定IT系统运维的目标和关键性能指标包括问题响应时效、需求响应时效、系统全年可用率、系统中断修复时效等。分析当前运维流程的瓶颈和问题包括缺乏运维奖惩机制、运维团队资源瓶颈、新技术应用熟练度瓶颈、计算资源瓶颈、问题提报通道不完善、问题解决协同机制不完善、问题升级机制缺乏等典型问题。制定改进计划和时间表根据项目整体安排,在关键里程碑前完成相关改进,比如系统正式上线前要完成系统知识转移、运维流程设计、运维团队搭建、运维机制宣贯、运维工具准备等。分配资源和职责明确所属的人力资源、技术资源,甚至系统运营预
133、算。比如在传统ITIL的3级运维体系中,服务台层次是IT服务管理的前沿,需快速响应客户的需求,及时解决故障并提供帮助,可能需要配置自助报障平台、智能客服,安排初级系统运维顾问响应客户问询;技术支持层次是更深入地分析和解决问题,并提供更高级别的技术支持,可能需要配置问题工单调度平台,安排中高级系统运维顾问、业务关键用户来配合解决问题;运营支持层次是全面管理整个IT基础设施,并提供对业务的持续支持,可能配置系统运营监控平台,安排资深系统运维顾问、外部供应商CSM团队、业务专家来协同运维等。组建运维团队在合适的时间节点组建运维团队,储备合格的运维人才,才能保证系统平稳运行。运维团队中的关键角色通常包
134、括:1.HRIS:负责为管理端用户提供技术支持和运营需求池。2.IT 相关负责人:负责保障服务连续性(数据库、服务器的备份、容灾)和信息安全管理。3.合作伙伴 CSM:来自合作伙伴的客户成功团队,赋能 HRIS 和IT 相关负责人,解决场景问题,必要时协调合作伙伴的产研资源解决问题。4.热线座席:负责为最终用户答疑,一般由 IT 的基础运维团队担任。由于不同角色承担的责任、对项目的了解深度存在差异,因此融入项目的时间也需要注意,HRIS 和 IT 相关负责人、承接后台模块和基础平台的人员至少需要 45 周时间培训和融入;承接前台模块的人员情况稍好,约 24 周;CSM 因熟悉产品,时间上会适当
135、提前;热线座席上手较快,经过培训即可。除此之外,另外一些角色也可酌情考虑,如 HR 各业务方,其中 COE 需要各模块对应负责人、SSC 各团队的,以及全部的 BP 或 BP 代表,参与功能迭代的优先级评审。运维服务从HRTech到WorkTech|62运维工作规划确定IT系统运维的目标和关键性能指标。分析当前运维流程的瓶颈和问题。制订改进计划和时间表。分配资源和职责。实施运维流程中的各项任务和活动。建立监控和报警机制,及时发现和处理故障。对系统进行更新和补丁安装等操作。变更管理和配置管理。定期收集和分析系统数据,评估运维效果。与用户或客户交流并收集反馈意见。发现和记录已知问题和待解决问题。制
136、订改进计划和方案。推广最佳实践和标准。培训团队成员,提升技能水平。持续监测和评估运维流程。制订IT系统运维的目标和计划,并确定实现这些目标所需的资源和时间表。计划阶段P根据计划执行运维工作。执行阶段D评估反馈运维效果,并分析系统中存在的问题,进一步改善运维流程。检查阶段C根据检查阶段的结果采取行动,改进运维流程,提高系统的效率和稳定性。行动阶段A运维服务的PDCA管理计划图15:系统实施关键环节与具体事项(P)计划阶段制定IT系统运维的目标和计划,并确定实现这些目标所需的资源和时间表。确定IT系统运维的目标和关键性能指标包括问题响应时效、需求响应时效、系统全年可用率、系统中断修复时效等。分析当
137、前运维流程的瓶颈和问题包括缺乏运维奖惩机制、运维团队资源瓶颈、新技术应用熟练度瓶颈、计算资源瓶颈、问题提报通道不完善、问题解决协同机制不完善、问题升级机制缺乏等典型问题。制定改进计划和时间表根据项目整体安排,在关键里程碑前完成相关改进,比如系统正式上线前要完成系统知识转移、运维流程设计、运维团队搭建、运维机制宣贯、运维工具准备等。分配资源和职责明确所属的人力资源、技术资源,甚至系统运营预算。比如在传统ITIL的3级运维体系中,服务台层次是IT服务管理的前沿,需快速响应客户的需求,及时解决故障并提供帮助,可能需要配置自助报障平台、智能客服,安排初级系统运维顾问响应客户问询;技术支持层次是更深入地
138、分析和解决问题,并提供更高级别的技术支持,可能需要配置问题工单调度平台,安排中高级系统运维顾问、业务关键用户来配合解决问题;运营支持层次是全面管理整个IT基础设施,并提供对业务的持续支持,可能配置系统运营监控平台,安排资深系统运维顾问、外部供应商CSM团队、业务专家来协同运维等。63|企业数字化系统选型建设指南确定IT系统运维的目标和关键性能指标包括问题响应时效、需求响应时效、系统全年可用率、系统中断修复时效等。分析当前运维流程的瓶颈和问题包括缺乏运维奖惩机制、运维团队资源瓶颈、新技术应用熟练度瓶颈、计算资源瓶颈、问题提报通道不完善、问题解决协同机制不完善、问题升级机制缺乏等典型问题。制定改进
139、计划和时间表根据项目整体安排,在关键里程碑前完成相关改进,比如系统正式上线前要完成系统知识转移、运维流程设计、运维团队搭建、运维机制宣贯、运维工具准备等。分配资源和职责明确所属的人力资源、技术资源,甚至系统运营预算。比如在传统ITIL的3级运维体系中,服务台层次是IT服务管理的前沿,需快速响应客户的需求,及时解决故障并提供帮助,可能需要配置自助报障平台、智能客服,安排初级系统运维顾问响应客户问询;技术支持层次是更深入地分析和解决问题,并提供更高级别的技术支持,可能需要配置问题工单调度平台,安排中高级系统运维顾问、业务关键用户来配合解决问题;运营支持层次是全面管理整个IT基础设施,并提供对业务的
140、持续支持,可能配置系统运营监控平台,安排资深系统运维顾问、外部供应商CSM团队、业务专家来协同运维等。运维服务从HRTech到WorkTech|64(D)执行阶段根据计划执行运维工作。实施运维流程中的各项任务和活动问题管理:问题提报、响应、解决交付及持续改进。需求管理:需求采集、分析、确认、排期、上线和需求绩效评估等。建立监控和报警机制,及时发现和处理故障包括确立监控指标、选择合适的监控工具、配置监控服务、实施监控操作、建立预警及故障处理机制等。系统更新和补丁安装等操作包括审核补丁和更新、制定更新计划和时间表、系统备份和恢复、执行补丁和更新、测试验证及更新文档和记录等。变更管理和配置管理包括确
141、认变更管理和配置管理规范、提交变更请示、审核变更请求、实施变更操作、测试验证和执行配置管理等。确定IT系统运维的目标和关键性能指标包括问题响应时效、需求响应时效、系统全年可用率、系统中断修复时效等。分析当前运维流程的瓶颈和问题包括缺乏运维奖惩机制、运维团队资源瓶颈、新技术应用熟练度瓶颈、计算资源瓶颈、问题提报通道不完善、问题解决协同机制不完善、问题升级机制缺乏等典型问题。制定改进计划和时间表根据项目整体安排,在关键里程碑前完成相关改进,比如系统正式上线前要完成系统知识转移、运维流程设计、运维团队搭建、运维机制宣贯、运维工具准备等。分配资源和职责明确所属的人力资源、技术资源,甚至系统运营预算。比
142、如在传统ITIL的3级运维体系中,服务台层次是IT服务管理的前沿,需快速响应客户的需求,及时解决故障并提供帮助,可能需要配置自助报障平台、智能客服,安排初级系统运维顾问响应客户问询;技术支持层次是更深入地分析和解决问题,并提供更高级别的技术支持,可能需要配置问题工单调度平台,安排中高级系统运维顾问、业务关键用户来配合解决问题;运营支持层次是全面管理整个IT基础设施,并提供对业务的持续支持,可能配置系统运营监控平台,安排资深系统运维顾问、外部供应商CSM团队、业务专家来协同运维等。65|企业数字化系统选型建设指南(C)检查阶段评估反馈运维效果,并分析系统中存在的问题,进一步改善运维流程。定期收集
143、和分析系统数据,评估运维效果包括确定关键运营监控指标、收集相关运行数据、使用工具分析数据、根据分析结果评估运维效果并发布分析结果和评估报告给相关干系人等。与用户或客户交流并收集反馈意见明确沟通计划、按计划定期与客户沟通、通过不同渠道收集用户/客户反馈意见、响应和处理用户/客户反映的问题、分析问题以发现潜在问题和改进机会并制定相应的改进方案、将分析和处理结果反馈给用户/客户。发现和记录已知问题和待解决问题定期回顾、复盘已发现问题的解决情况;对于逾期未解决问题,要及时与用户或客户沟通变通解决方案(甚至调整业务)。确定IT系统运维的目标和关键性能指标包括问题响应时效、需求响应时效、系统全年可用率、系
144、统中断修复时效等。分析当前运维流程的瓶颈和问题包括缺乏运维奖惩机制、运维团队资源瓶颈、新技术应用熟练度瓶颈、计算资源瓶颈、问题提报通道不完善、问题解决协同机制不完善、问题升级机制缺乏等典型问题。制定改进计划和时间表根据项目整体安排,在关键里程碑前完成相关改进,比如系统正式上线前要完成系统知识转移、运维流程设计、运维团队搭建、运维机制宣贯、运维工具准备等。分配资源和职责明确所属的人力资源、技术资源,甚至系统运营预算。比如在传统ITIL的3级运维体系中,服务台层次是IT服务管理的前沿,需快速响应客户的需求,及时解决故障并提供帮助,可能需要配置自助报障平台、智能客服,安排初级系统运维顾问响应客户问询
145、;技术支持层次是更深入地分析和解决问题,并提供更高级别的技术支持,可能需要配置问题工单调度平台,安排中高级系统运维顾问、业务关键用户来配合解决问题;运营支持层次是全面管理整个IT基础设施,并提供对业务的持续支持,可能配置系统运营监控平台,安排资深系统运维顾问、外部供应商CSM团队、业务专家来协同运维等。运维服务从HRTech到WorkTech|66(A)行动阶段根据检查阶段的结果采取行动,改进运维流程,提高系统的效率和稳定性。制定改进计划和方案包括根据分析结果和业务需求确定改进目标和指标、制定改进方案(综合考虑方案的可行性和实施难度,并与相关团队协调配合)、按计划实施改进方案、评估及复核改进效
146、果等。推广最佳实践和标准包括确定适用于团队和行业的最佳实践和标准(技术、流程、管理等方面)、将最佳实践和标准向团队成员培训和推广、制定相应的指导手册/文档/模板、将最佳实践和标准推广到业务用户(如有条件可参与行业SPO的制定和推广工作)。培训团队成员,提升技能水平根据团队成员的工作内容和职业发展需求确定合适的培训方向和计划、设计相应的培训课程(理论知识、实践操作和案例分析等内容)。根据培训课程和人员数量选择合适的培训方式(如在线培训、面对面授课、研讨会)。根据团队成员的工作安排和学习需求来合理安排培训时间、按照培训计划实施培训并进行考核和反馈、通过评估和反馈持续改进培训计划确定IT系统运维的目
147、标和关键性能指标包括问题响应时效、需求响应时效、系统全年可用率、系统中断修复时效等。分析当前运维流程的瓶颈和问题包括缺乏运维奖惩机制、运维团队资源瓶颈、新技术应用熟练度瓶颈、计算资源瓶颈、问题提报通道不完善、问题解决协同机制不完善、问题升级机制缺乏等典型问题。制定改进计划和时间表根据项目整体安排,在关键里程碑前完成相关改进,比如系统正式上线前要完成系统知识转移、运维流程设计、运维团队搭建、运维机制宣贯、运维工具准备等。分配资源和职责明确所属的人力资源、技术资源,甚至系统运营预算。比如在传统ITIL的3级运维体系中,服务台层次是IT服务管理的前沿,需快速响应客户的需求,及时解决故障并提供帮助,可
148、能需要配置自助报障平台、智能客服,安排初级系统运维顾问响应客户问询;技术支持层次是更深入地分析和解决问题,并提供更高级别的技术支持,可能需要配置问题工单调度平台,安排中高级系统运维顾问、业务关键用户来配合解决问题;运营支持层次是全面管理整个IT基础设施,并提供对业务的持续支持,可能配置系统运营监控平台,安排资深系统运维顾问、外部供应商CSM团队、业务专家来协同运维等。67|企业数字化系统选型建设指南和课程等。持续监测和评估运维流程根据业务需求和服务水平协议,确定合适的监测指标(如故障率、响应时间、可用性)、配置相应监测工具、收集运维流程相关的数据和信息,并分析和汇总。分析和评估运维流程找出瓶颈
149、和问题,并制定相应的改进计划和方案;实施相应的改进措施,并跟踪处理过程和效果。持续监测和评估运维流程,以确保其稳定性和可持续性,并不断提高运维效率和服务质量。扫码领取配套选型知识地图确定IT系统运维的目标和关键性能指标包括问题响应时效、需求响应时效、系统全年可用率、系统中断修复时效等。分析当前运维流程的瓶颈和问题包括缺乏运维奖惩机制、运维团队资源瓶颈、新技术应用熟练度瓶颈、计算资源瓶颈、问题提报通道不完善、问题解决协同机制不完善、问题升级机制缺乏等典型问题。制定改进计划和时间表根据项目整体安排,在关键里程碑前完成相关改进,比如系统正式上线前要完成系统知识转移、运维流程设计、运维团队搭建、运维机
150、制宣贯、运维工具准备等。分配资源和职责明确所属的人力资源、技术资源,甚至系统运营预算。比如在传统ITIL的3级运维体系中,服务台层次是IT服务管理的前沿,需快速响应客户的需求,及时解决故障并提供帮助,可能需要配置自助报障平台、智能客服,安排初级系统运维顾问响应客户问询;技术支持层次是更深入地分析和解决问题,并提供更高级别的技术支持,可能需要配置问题工单调度平台,安排中高级系统运维顾问、业务关键用户来配合解决问题;运营支持层次是全面管理整个IT基础设施,并提供对业务的持续支持,可能配置系统运营监控平台,安排资深系统运维顾问、外部供应商CSM团队、业务专家来协同运维等。迄今为止,数字化仍是“热搜”
151、词汇,网上各种解读百花齐放。其中,我个人比较认可 Gartner 的解读:数字化是利用数字技术来改变商业模式并提供新的收入和价值创造机会,这是转向数字业务的过程。从这个角度看,技术驱动、数据驱动、数字孪生都是促成“改变商业模式”的工具,最终致力于产生新的收入和价值,并且这个过程远不止于上几个系统而已,实际应该是一把手深度参与的变革工程。在这种变革中,我认为不管是企业运营管理者,还是 HR 和 IT,都应努力尝试跳出专业看业务,以生意思维、数据驱动思维、流量思维及长尾思维来设计变革、推动变革。生意思维(也可以理解成产品思维):把数字化转型当生意来做,搞清楚投入什么、内外部供应商是谁、怎么采购,产
152、出什么、客户是谁、怎么卖给客户、客户为什么要买单,从什么渠道来获取客户反馈、响应客户声音、迭代产品。数据驱动思维:即通过业务数字化,更方便快捷地采集到足够的支撑数据,进而基于数据分析指导决策。在可预见的未来,基于数据的决策将逐渐超过基于经验的决策,也许随着业务数字化变革的深入,数据分析建模、数据分析技能对业务的重要性将持续增加,算法将是业务运营中不可或缺的一环,执行复杂任务将更依赖高阶的算法和 PDCA 方法论,而非高阶职员的个人经验。结语从HRTech到WorkTech|68确定IT系统运维的目标和关键性能指标包括问题响应时效、需求响应时效、系统全年可用率、系统中断修复时效等。分析当前运维流
153、程的瓶颈和问题包括缺乏运维奖惩机制、运维团队资源瓶颈、新技术应用熟练度瓶颈、计算资源瓶颈、问题提报通道不完善、问题解决协同机制不完善、问题升级机制缺乏等典型问题。制定改进计划和时间表根据项目整体安排,在关键里程碑前完成相关改进,比如系统正式上线前要完成系统知识转移、运维流程设计、运维团队搭建、运维机制宣贯、运维工具准备等。分配资源和职责明确所属的人力资源、技术资源,甚至系统运营预算。比如在传统ITIL的3级运维体系中,服务台层次是IT服务管理的前沿,需快速响应客户的需求,及时解决故障并提供帮助,可能需要配置自助报障平台、智能客服,安排初级系统运维顾问响应客户问询;技术支持层次是更深入地分析和解
154、决问题,并提供更高级别的技术支持,可能需要配置问题工单调度平台,安排中高级系统运维顾问、业务关键用户来配合解决问题;运营支持层次是全面管理整个IT基础设施,并提供对业务的持续支持,可能配置系统运营监控平台,安排资深系统运维顾问、外部供应商CSM团队、业务专家来协同运维等。长尾思维:对于管理系统,使用频率少的用户占绝大多数,但他们也能产生价值,集腋成裘,就是天文数字。这反映在 HR 数字化中,就是系统用户的泛化,以前只有专业人士使用的系统,现在渐渐变成了全民应用。流量思维:对于用户而言,只有注意力总量是不变的,谁掌握更多的用户时间,谁就有更多的流量,谁就可以基于流量做更大的文章,基于流量生态变现
155、,也许可以成为新收入新价值的温床,比如招聘流量是否可为业务所用?本企业的流量是否可为合作伙伴所用,创造更大价值再反哺于企业?我认为,一切数字化业务皆可长尾,一切业务皆可流量。但这些高大上的理论终归是要落到具体操作的系统,到底该用什么系统来落地呢?过去受限于技术实现能力、供应商服务能力,甲方不得不把端到端的业务碎片化后交给不同的供应商来落地,然后自己做集成,并为最终结果买单。随着技术和市场的发展,客户的需求也在不断进化,如果说以前是信息化需求(通过单点技术应用解决业务问题),那么现在的数字化需求,则是以数字化技术为底盘来解决业务端到端问题的需求,对供应商的要求是端到端的业务服务,而不仅仅是系统这
156、个工具、这个点的服务。这就客观要求供应商具备生态交付能力,客户选系统已进化成选生态。另一方面,现在很多系统厂商都在谈一体化,把一体化当作核心竞争力。不过很多厂商所谈的主要还是底层平台的一体化,不同模块之间的集成更丝滑、用户体验更一致、运维更便(bian)宜。这是极好的,但这种一体化并不是唯一解,“一体化”的理解和玩法有多种可能:69|企业数字化系统选型建设指南确定IT系统运维的目标和关键性能指标包括问题响应时效、需求响应时效、系统全年可用率、系统中断修复时效等。分析当前运维流程的瓶颈和问题包括缺乏运维奖惩机制、运维团队资源瓶颈、新技术应用熟练度瓶颈、计算资源瓶颈、问题提报通道不完善、问题解决协
157、同机制不完善、问题升级机制缺乏等典型问题。制定改进计划和时间表根据项目整体安排,在关键里程碑前完成相关改进,比如系统正式上线前要完成系统知识转移、运维流程设计、运维团队搭建、运维机制宣贯、运维工具准备等。分配资源和职责明确所属的人力资源、技术资源,甚至系统运营预算。比如在传统ITIL的3级运维体系中,服务台层次是IT服务管理的前沿,需快速响应客户的需求,及时解决故障并提供帮助,可能需要配置自助报障平台、智能客服,安排初级系统运维顾问响应客户问询;技术支持层次是更深入地分析和解决问题,并提供更高级别的技术支持,可能需要配置问题工单调度平台,安排中高级系统运维顾问、业务关键用户来配合解决问题;运营
158、支持层次是全面管理整个IT基础设施,并提供对业务的持续支持,可能配置系统运营监控平台,安排资深系统运维顾问、外部供应商CSM团队、业务专家来协同运维等。后台一体化:例如肯耐珂萨这种数字化底盘一体化;中台一体化:基于数据中台集成多套业务系统(典型的是支持海外业务的本地化系统)、插件级系统数据,实现数据层的一体化,再辅以 BI、工作台等前端应用来打造一致的用户体验;前台一体化:基于 WorkTech 封装中后台系统打造统一服务界面。综上,我认为选供应商就是选生态,基于生态合理来搭建适合业务和企业 IT 架构的“一体化”方案才是最优解。曾服务德勤、顺丰、TCL等企业结语从HRTech到WorkTec
159、h|70国内某知名物业服务公司 IT总监 吴伦确定IT系统运维的目标和关键性能指标包括问题响应时效、需求响应时效、系统全年可用率、系统中断修复时效等。分析当前运维流程的瓶颈和问题包括缺乏运维奖惩机制、运维团队资源瓶颈、新技术应用熟练度瓶颈、计算资源瓶颈、问题提报通道不完善、问题解决协同机制不完善、问题升级机制缺乏等典型问题。制定改进计划和时间表根据项目整体安排,在关键里程碑前完成相关改进,比如系统正式上线前要完成系统知识转移、运维流程设计、运维团队搭建、运维机制宣贯、运维工具准备等。分配资源和职责明确所属的人力资源、技术资源,甚至系统运营预算。比如在传统ITIL的3级运维体系中,服务台层次是I
160、T服务管理的前沿,需快速响应客户的需求,及时解决故障并提供帮助,可能需要配置自助报障平台、智能客服,安排初级系统运维顾问响应客户问询;技术支持层次是更深入地分析和解决问题,并提供更高级别的技术支持,可能需要配置问题工单调度平台,安排中高级系统运维顾问、业务关键用户来配合解决问题;运营支持层次是全面管理整个IT基础设施,并提供对业务的持续支持,可能配置系统运营监控平台,安排资深系统运维顾问、外部供应商CSM团队、业务专家来协同运维等。71|企业数字化系统选型建设指南作者(排序不分先后,按姓氏首字母排列)关键国内食品制造500强企业的HRIS负责人曾服务大型央企负责推动财务ERP系统上线10年财务
161、管理和7年HR数字化转型经验主导过两家万人规模企业的人资数字化项目郭雨琛某新能源车企People系统与数据分析总监曾服务于奔驰、理想、美团等企业7年人力资源数字化转型经验主导过两次HR全模块数字化建设,及多次垂直领域的系统选型李冲知名亚洲珠宝集团HRIS专家 15年行业经验,曾任职于埃森哲、广东电信等知名企业从甲、乙双方项目经理的不同视角落地HR数字化项目吴伦国内知名物业服务公司 IT总监15年HR数字化转型项目经验曾服务德勤、顺丰、TCL等知名甲乙方徐刚人力资源数字化转型行动指南作者复旦MBA同学会人力资源协会主理人现任世界500强企业人力资源运营总监深蓝信息公众号主理人确定IT系统运维的目
162、标和关键性能指标包括问题响应时效、需求响应时效、系统全年可用率、系统中断修复时效等。分析当前运维流程的瓶颈和问题包括缺乏运维奖惩机制、运维团队资源瓶颈、新技术应用熟练度瓶颈、计算资源瓶颈、问题提报通道不完善、问题解决协同机制不完善、问题升级机制缺乏等典型问题。制定改进计划和时间表根据项目整体安排,在关键里程碑前完成相关改进,比如系统正式上线前要完成系统知识转移、运维流程设计、运维团队搭建、运维机制宣贯、运维工具准备等。分配资源和职责明确所属的人力资源、技术资源,甚至系统运营预算。比如在传统ITIL的3级运维体系中,服务台层次是IT服务管理的前沿,需快速响应客户的需求,及时解决故障并提供帮助,可
163、能需要配置自助报障平台、智能客服,安排初级系统运维顾问响应客户问询;技术支持层次是更深入地分析和解决问题,并提供更高级别的技术支持,可能需要配置问题工单调度平台,安排中高级系统运维顾问、业务关键用户来配合解决问题;运营支持层次是全面管理整个IT基础设施,并提供对业务的持续支持,可能配置系统运营监控平台,安排资深系统运维顾问、外部供应商CSM团队、业务专家来协同运维等。从HRTech到WorkTech|72顾问常晓东施耐德电气人力资源信息化高级经理20年企业数字化转型经验杨洋现任湖南某集团数据中心总助15年集团化企业数字化转型建设经验曾服务于建筑施工、地产、物业、制造等行业深度参与开发、实施的项
164、目100+湘江数评公众号主理人李品伟盖雅工场解决方案副总裁20+年劳动力管理的解决方案和实践经验主导参与过数百家企业的信息化项目实施、管理咨询,涉及制造、连锁零售、现代服务、餐饮、仓储物流等行业。盖雅工场是一家提供全球劳动力管理云服务的中国公司,以科技让劳动力更高效为使命,通过劳动力管理和灵活用工云平台,助力下一代劳动力的数字化转型。盖雅工场专注于解决企业在劳动用工方面的四个问题:需要多少人实际多少人干得怎么样怎样找到人。目前,盖雅工场的客户分布在全球24个国家与地区,每天,全球1,700余家客户的600余万员工使用盖雅提供的服务。盖雅工场成立2009年,总部位于苏州,在北京、上海、广州、深圳、杭州、武汉,及新加坡等地设有分支机构。投资方包括GGV纪源资本、腾讯、老虎、华平、经纬、EDBI 等。更多信息请访问www.GaiaW或拨打 400-629-6868。劳动力管理,盖雅搞得定。外采还是自研,SaaS还是OP?需求真假难辨,痛点还是痒点?功能差不多,谁才是我的乙方?需求真假难辨,痛点还是痒点?热线 400-629-6868邮箱 网址 http:/A GREAT WORKFORCEGAIA WORKS劳动力管理 盖雅搞得定扫码领取配套选型知识地图