2023从HRTech到WorkTech企业数字化系统选型建设指南

需求真假难辨，痛点还 SaaS还是OP？ 选型成功的底层逻辑 成功上线，业务却不用 项目owner的关键能 从业务蓝图到系统构建 选型成功的底层逻辑 风险点和雷区预警 能差到不W多，o谁r才k是Te我c的h乙方？ 从业务蓝图到系统构建 如何不被供应商牵扯 是我的乙企业方数字？化系统 预算为何不停在追 务蓝图到系统选构建型建设指业务南需求优先级评估 从项目规划到系统运维预算为何不停在追加 供应商过度承诺，无法判断 却不用？项目预算制订的关键点 外采还是自研，Sa ，实战心得 业务需求变来变去，怎么 业务需求优先级评估 合同签约的细枝末节 还是痒点？ 行业经验，实战心得 项目owner的关键能力 预算为何不停在追加 风险点和雷区预警成功上线，业务却不用？ 供应商过度承诺，无法判断 却不用？ 外采还是自研，Sa ，实战心得 业务需求变来变去，怎么 业务需求优先级评估 合同签约的细枝末节 还是痒点？ 行业经验，实战心得 项目owner的关键能力 预算为何不停在追加 键点风险点和雷区预警 成功上线，业务却不用？ 求真从假难辨，痛点还是痒点？HRTech 运营IT HR实践者写给你的实战经验 目录Contents 前言： HRTech到WorkTechP03 01 项目规划P08 1.明确项目价值和目标P09 2.组建项目规划团队P11 3.业务需求梳理与排序P12 4.转型路径规划P15 5.项目预算制定P22 6.决策者审批P23 02 系统选型P24 1.关键需求梳理P26 2.供应商选择P30 3.招投标P35 4.合同签订P38 03 实施上线P40 1.项目准备P42 2.蓝图设计P43 3.系统实施P44 4.系统验证P51 5.系统上线P56 04 运维服务P60 1.组建运维团队P61 2.运维工作规划P62 结语P68 扫码领取 配套选型知识地图 前言：HRTech到WorkTech 如今，对大多数企业而言，HRTech（人力资源技术）一定不再是一个陌生词汇，毕竟数字化技术已经在人力资源管理的各个领域得到广泛应用，帮助着HR和管理者们简化工作流程，提高工作效率，优化工作体验。 不过，人力资源管理对技术的需求并没有止步于HRTech。 伴随着HR角色和定位发生转变，企业对员工体验日趋关注以及工作方式的变化等，WorkTech应运而生。 WorkTech是协作、生产力提升和人力资源计划的结合，更全面地提升组织整体的生产力、员工的工作体验，它代表着企业人力资源管理和组织管理对技术的新期待。换句话说，人力资源技术只是WorkTech的构成部分之一。 正如JoshBersin在《人力资源技术：权威指南》中所述，“人力资源数字化转型已经发生了许多改变，其中最大的变化是从HRTech向WorkTech的转变，它已经远远超出了招聘、培训、薪资等员工管理的范围。” 正因如此，面对未来的“人力资源数字化转型”，企业需要跳出HR职能视角，站在组织整体效能的视角重新看待人力资源数字化，它将不仅局限于招聘、薪资等人力资源技术，还包括像飞书、Teams等协作工具，以及直接促进时间利用率提升的劳动力管理技术，如排班、考勤。通过HRTech和WorkTech的正确组合，组织才能创建一个全面高效的工作环境。 从HRTech到WorkTech后，企业需要从组织视角转向更广泛的生态视角。 企业也要从工具视角转变为综合解决方案来选择合作伙伴。人力资源“各自为政”的时代即将结束，未来的数字化转型并不仅意味着选一个工具或是选择一个系统，而是选择一套解决方案，帮助企业实现整体效能提升。 除此之外，与HRTech时代不同的是，在WorkTech时代，企业还要站在员工视角而非管理者视角来思考数字化的价值。HRTech的目标受众一般是HR管理者；相比之下，WorkTech则与各种类型的员工相关，包括HR管理者和高管，也包括项目经理、团队成员或一线管理者。如果说HRTech注重于管理，那WorkTech则更致力于赋能。 更重要的是，从HRTech到WorkTech后，企业需要从组织视角转向更广泛的生态视角。因为WorkTech所面对的用户将更为多样，他们分布于组织内外——不仅涉及白领员工，全职员工，也涉及蓝领，合同工和零工；不仅涉及HR和高级管理者等办公室管理人员，也涉及车间、门店的一线管理者。他们与企业的生产力提升息息相关。 总而言之，全局、多样和复杂是WorkTech带给HR、IT、运营及其他相关管理者的新命题。 面对新命题，如何选择好与企业业务和组织发展相契合的合作伙伴，这再次成为企业数字化转型过程中要面对的挑战。对于此，一些企业选择自行摸索，或与同行企业交流经验，或依赖零散的网络信息来获取启发，这些方式有其存在的意义，但却并不是最有效的方式，单一过度地依赖于某种方式，都会让项目暗藏风险。 这恰恰是我们筹备《从HRTech到WorkTech：企业数字化系统选型建设指南》的重要原因。 需要提醒的是，即将为您呈现的不是一份完美的理想化的指南，而是实践者写给你的实战经验。 内容创作过程中，我们邀请了9位在人力资源数字化领域拥有10+年经验的实战派参与创作和指导。从项目规划开始，到系统选型、实施上线，再到运维服务，实践者们用最直接朴实的语言讲述他们在系统选型过程中的经验总结，希望它具备实际意义，对您企业未来的数字化转型有帮助。 HRTech 到WorkTech ●企业数字化系统选型建设之路 项目规划 明确项目价值和目标 组建项目规划团队 业务变革的干系人通常有哪些？ 项目预算制定 项目预算的8个构成部分 决策者审批 审批前的Checklist 转型路径规划 外采vs自研？SaaSvs本地部署？ 一体化vs尖物组合？ 系统选型 业务需求梳理与排序 业务需求优先级评估的6个参考维度 关键需求梳理 需求梳理的5个关键步骤 合同签订 业务与IT视角下成功选型的系统画像 招投标 招投标具体流程及注意事项 供应商选择 初选与约谈阶段的评估维度 实施上线 项目准备蓝图设计 蓝图设计报告要完成的2个使命目标 系统上线系统验证系统实施 上线过程的11个关键事项与5个常见风险点 系统验证的主要阶段与落地执行的23件事 系统实施的主要阶段与落地执行的24件事 运维服务 组建运维团队运维工作规划 运维服务的PDCA管理计划；4个阶段与15个关键事项 项目规划 项目规划的阶段性目标 确定立项及项目的宏观目标，例如要实现的业务价值，要解决的主要业务痛点，以及各阶段的重要事项和时间周期。 扫码领取 配套选型知识地图 项目规划可分为六个主要阶段，即明确项目价值和目标、组建项目规划团队、业务需求梳理和排序、转型路径规划、项目预算制定和决策者审批。对应这六个阶段，也将有一些阶段性产出，如： 项目规划的阶段性产出 1总体规划 2系统需求文档 3需求矩阵 系统规划的总体方向、愿景和目标实现的路线图等内容。 详细描述业务部门对系统的功能需求和技术要求。这是确定计划和预算的基础。 将系统需求文档中的需求与实际的系统功能相匹配的矩阵表格。 4技术设计文档 5项目计划 6预算和成本分析 包括系统架构、技术规范、数据模型、集成设计、安全设计等方面的详细设计文档。 详细描述实施IT系统所需时间、人力投入、资源等各项计划，包括采购、实施、测试、培训、沟通和风险管理计划等。 所有IT系统所需的实施费用，硬件、软件、培训、开发、测试、维护等。 图1：项目规划的阶段性产出 明确项目价值和目标 通常来讲，所有中后台投资都应落脚于支持前台“战役”打赢。所以HRIS的规划也要以终为始，从业务痛难点来看业务需求，再分解成为项目的目标和价值，切忌“为项目而项目”，陷入职能部门自嗨状态。 一般来说，中后台职能部门的价值锚主要包括提效、降本、合规、控风险这几个方面。 •提效：主要指通过优化业务流程或使用先进技术等方式，提高生产效率和交付质量，以实现资源最大化利用。例如业务现状是线 下手工核算员工工资，HR需要加班加点采集数据、校验核算逻辑，往往要拖到10号才能发工资，导致员工体验较差，并影响财务关账，所以期望通过系统来实现薪酬核算提效。 •降本：主要指通过精益管理、创新技术解决方案等方式降低企业运营成本，包括人力成本、沟通成本、时间成本等。例如业务现状是业务部门各门店人力不均、排班不合理、工时利用率低，不仅影响门店销售转化率，而且影响员工满意度，所以期望通过系统来优化工时管理，合理排班，降低工时成本和管理成本，同时提升销售转化率和员工满意度。 •合规：主要指通过建立完善的内部控制机制和制度，加强监管和培训，防范各种违规行为和风险，确保企业遵守各种法律法规和行业标准，符合公司内部管理制度要求，保护企业自身合法权益。例如业务现状是线下算薪、记录考勤和管理员工档案，存在不按国家规定核定薪资、工时超标、滥用员工个人隐私信息等违法违规操作的可能，所以期望实施系统来固化操作标准，保障业务合规合法。 •控风险：主要是指识别和管理企业可能面临的各种业务运营风险，并制定相应的风险管理策略和预案，及时应对风险事件。例如业务现状是只能管理各下属单位的薪酬总额，无法管理到具体人员、职级、考勤及薪酬带宽，因此存在吃空饷现象，所以期望通过系统来提升管理精细度，落实管理抓手，控制业务运营风险。 当然，随着企业业务发展，在战略规划上侧重点往往也会不同，因此我们需要以终为始，从业务战略规划出发来拆解业务目标，再细分成HR数字化转型目标，并落地成HRIS建设目标，明晰此次数字化转型项目对公司的价值是什么。 组建项目规划团队 明确项目价值和目标后，我们就可以从顶层设计上明确项目范围及ToBe的业务版图，再基于AsIs的业务现状，初步明确业务变革点及干系人，再根据变革需求组建项目规划团队，确保沟通到位，减少落地过程中的阻碍。 例如一些大型跨国企业的组织比较复杂，启动一个项目时通常会发现“理想是美好的，现实是残酷的。”在本地看似一件简单的事情，但真正推进时，则会跳出很多平时可能都不认识的总部同事对项目“指手画脚”，让人措手不及。 因此，在项目开始之前，我们最好充分做好干系人分析，了解到底哪些人可能会对项目产生重大影响以及他们的需求，从而提前做好计划。典型干系人通常包括决策者、业务负责人、用户代表、系统管理员、IT团队及合作伙伴。 项目利益相关者（干系人）分析 决策者 业务负责人 用户代表 系统管理员 IT团队 合作伙伴 企业高层管理人员 各业务模块主管系统最终使用者 企业内负责系统运营和日常维护的人员 企业内的技术开发团队，包括软件开发人员、测试人员、数据库管理员等 为企业提供实施咨询服务的外部公司或人员 需对项目进行决策，并提供资源保障，确保系统顺利实施。 需提供业务需求和流程设计，确保系统能够满足业务需求。 参与需求分析、流程设计和测试等环节，提供反馈和建议，确保系统符合用户需求和期望。 负责系统配置、部署、权限管理、数据备份和恢复等工作。 负责系统的技术研发、测试和维护，确保系统稳定运行。 提供企业需求分析、流程设计和实施计划制定等方面的支持，协助企业完成系统实施。 图2：项目利益相关者（干系人）分析 虽然从风险把控的视角来看，干系人覆盖范围宜大不宜小，但同时也要兼顾沟通效率，避免影响规划交付效率。例如，规划招聘系统，有HR负责人全程支持最好，但没有或部分参与皆可；再例如整体切换集团系统，就一定要有集团HR领导参与，还要下属各业态HR负责人参与。 业务需求梳理与排序 根据业务发展战略明确ToBe愿景之后，接下来我们需要对照业务现状进一步明确业务需求，然后再分解成对系统的需求。这里的业务需求是指业务更高层面、更接近本质的业务收益和目标，而非具体的系统功能需求，例如： •激发员工潜能，促进销售目标提升10%； •实现业财人一体化管理，打破决策层单一维度的数据统计分析；