专家团｜蒋祎：自下而上HR数字化方案篇
上一篇我们聊到，HR要给业务需并排“高中低”优先级。
需求排优先级，常用方法是根据“价值”和“紧迫性”两个维度来评估。由于在小蒋的经验中，特别急的HR需求并不常见（主要法律规章/监管要求的变更），因此在举的例子中没有强调“紧迫性”，而是考虑从更多维度来量化“业务价值”。
HR从业务的角度评估完，HRIT还要从技术的角度再评估一轮。
结合两类评估，我们就可以排出每个需求在下面象限图中的位置，然后决定先实现哪些、后实现哪些。
量化法则：
技术评估同样要量化，比较暴力、粗俗的算法是：
技术实现成本≈软件工具采购、实施、使用费+人工成本
人工成本=人数×耗费天数×单日薪酬
首先去实现哪一类呢？
考虑到，自下而上的HR数字化是希望通过快速见效的成果，来赢得上上下下对数字化的信心。因此，我们优先去实现的，肯定是业务价值高、技术上也好搞的，也就是所谓的“快赢”。
业务上重要而技术难搞的，则要做长远的的规划，做长期战斗的准备，在启动之前，要确保上上下下已经攒足了信心、可以下定决心。
“举手之劳”这类，有空的话可以先做其中比较着急的，不着急的有空再慢慢做。
“吃力不讨好”这类，就应该和HR聊聊需求是否合理，或者双方的理解是否一致、清晰。
????低痛法则：
所有HR提出的需求都要被评估、有反馈。哪怕是明显价值低、投入高的需求，也要沟通可能的方案是什么、为什么优先级低、未来可能有什么相关的计划。
要让HR感受到自己的想法被尊重，也让HR学到需求评估和排期的方法，鼓励HR继续提出需求、参与到数字化的循环中。
“技术实现好不好搞？”HRIT在回答这个问题的时候，其实心中已经要有相应的方案了。
为了满足业务需求而提出的解决方案，通常包括要用哪些数字化工具，以及要如何实施落地。
数字化工具的选择可能是多样的：
因此，“技术上好不好实现”这个问题，其实是相对的，它取决于：
也正因如此，HR可能对HRIT评估的结果产生质疑：“这个应该不难实现吧？这个要不了这么久吧？”特别是当HRIT是外部乙方、按人天收费时。
这个时候，HRIT能否树立技术专家的权威、用自己的专业赢得HR的信赖就尤为重要了。HRIT要让HR相信，这样的评估结果，不仅是基于有过的成功经验，也是基于对潜在风险的预判。
专业的工作方法、高效的沟通、取得“快赢”，都可以增强HR对HRIT能力的信任。
????低痛法则：
选择方案时，要尽量减少用户使用的阻力（比如要安装开发环境、要下载新的APP），可以考虑使用用户熟悉的软件和操作方式（比如在Excel中批量编辑），减少学习成本。
HR日常最熟悉的软件是下面这些，最快的“快赢”往往是这些工具的优化和自动化：
????快速法则：
HRIT尽量选择自己趁手的兵器，选择较快的工具，而不是最新、最强的，任正非说过“把地种好才是好农民，不要本末倒置地四处炫耀锄头。”。
当HRIT大致确定了比较合适的方案后，就比较容易评估出技术实现的成本了。
我们说的“快赢”到底能有多快呢？
小蒋个人的经验中，如果是在HR系统的基础上配置新功能，或者用Python、VBA开发小程序，基本1-3天能确定基本方案，1-2周能完成“最小可行产品”并交付给HR，这个节奏比较合适，HRIT投入与HR收益的“性价比”相对较高。
当然，“快”不是衡量方案的唯一指标，HRIT要注意，方案不仅要突破“点”的效率瓶颈，也要在整个流程的“线”上保证顺畅，在数字化整体的“面”上起到更积极的作用。
在需求篇中说过，不要让HR陷入对功能设计的想象。同样，HRIT在提出方案时，也要拿出实物，不要让HR去脑补。
我们继续说相对简单、快速的情况：需求用一个简单的工具就能搞定。
如果方案是用一个现成的产品或已有的系统，做出个示意的页面或表单再去沟通，页面简陋、字段不全、功能没完全实现都不是问题，首先要让用户有个体感。
如果方案用编程实现，至少告诉用户输入、操作、输出分别是什么样子。比如我们之前做的加密offer批量生成程序，沟通方案时，我会先告诉HR你要准备什么数据、贴到一个怎样的Excel里，点一个按钮，就会在文件夹里生成什么样的PDF文件，文件都要做出示例。
再不成熟的实物原型也比拿着PPT、甚至全靠口头描述靠谱得多，这也可以让HR相信方案的可行性是HRIT确实初步验证过的。
基于这个原型，双方的沟通就能具体很多，HR可以据此反馈建议，HRIT也要告诉HR:
有时可能没有一个单独的方案能完全满足需求，而是有多种方案，各有千秋却各有不足。首先给用户演示最容易实现的，看看用户能不能接受；如果不能，再演示另一个。要从短期实现和长远使用等多个角度，说清楚不同方案的优劣势，让HR综合考虑。
按照方案沟通的结果，HRIT再去快速配置/开发出“最小可行性产品”（MVP）。
这个阶段，我会跟HR沟通：
▶ 第一版的MVP可能只能达到60分，但它已经能满足最核心的业务诉求
▶ 未来它有可能优化到90分，但考虑到60分到90分的边际成本，我只有确定HR会长期使用它之后，我才会去进一步优化。
▶ 优化需要与HR共创、由HR发起
此前介绍过一个薪酬通知信的例子，第一个版本让“不可能”成为了“可能”，但用户还有4个步骤要操作，而且还要修改Windows的语言设置；薪酬HR在之后的一年中不断使用这个程序，不断发现问题、不断提出建议；我也对这个程序做了数次优化，将4步缩减为2步，节约了30%的时间，并且大大降低了出错的可能性。
最快地做出MVP，就是为了最快地解决核心业务需求，最快地验证方案的方向是正确的，最快地得到反馈并评估收效，持续优化、循环往复。
????低痛法则：
把握HR对MVP的预期，并坚定他们未来会更好的信心。
当然，不是所有的优先需求都能在一两周内解决；HR描述起来轻而易举的需求，可能需要专门启动一个小型项目来实现，这种情况，要设法将项目拆解为快赢。
例如，有几张报表以前是在线下制作的，这几张报表的数据来源有线上有线下。业务痛点是报表整理复杂、耗时长，线下数据会出现质量问题，报表要分享给各部门时又要手动拆分。考虑用系统自动生成报表、按权限定时自动发送报表。
初步的方案如下：
这个方案要落地，不仅涉及数字化工具的制作，还涉及历史数据的迁移。落地过程就应该拆分，并分步验收确认：
这个方案当然还有优化空间，如果有自动抽取数据的工具，或者直接将数据源1、2相关的业务搬到线上，就可以进一步减少人工操作；但首先，要让HR看到这个基础方案的价值、要让HR看到进一步优化的价值。
本文经授权转载自微信公众号：Johnny HCM
