• Chase Rowbotham
    企业如何创建一个People Analytics部门? 作者:Chase Rowbotham & Jamie Ostheimer 公司应该在什么时候建立一个PA的部门? 答案很简单。越早越好 People Analytics主要是关于变革管理。我们要求人们以不同的方式来经营他们的业务(从假设开始!),这样就可以捕捉到数据,以推动数据驱动的决策(即,什么项目最有效,我应该继续资助什么项目,什么项目推动什么结果等等)。相对于执行一个项目,然后想知道这个项目是否有效(通常没有捕捉到你所需要的数据来回答这个问题),将数据采集带入项目设计是更好的。与解除和/或改变一个企业多年来的运行方式相比,从一开始就奠定这个基础要容易得多。 哪些数据对于为下一代洞察力提供信息至关重要? People Analytics不知道什么样的数据组合会产生下一代洞察力,所以在你还没有接触到数据之前,你需要创建一个数据访问模型,允许持续和不受限制地访问数据(想要利用人员数据的力量的公司应该致力于实现这一点)。执行这一点,同时与您的人力资源主管、数据隐私官和雇佣法主管密切合作(我们在设计阶段就将其纳入项目中),将最大限度地提高机器学习和人工智能产生下一代洞察力的成功概率,使整个公司取得更好的成果。这些能力可以实现个性化、推荐、自动化,并让各种人力资源系统的互操作性大大提高。想象一下,如果一名员工在Workday中收到了关于某方面机会的反馈,第二天,同一名员工就得到了来自Cornerstone强烈推荐的在线学习机会?这在今天是不可能的,但People Analytics可以实现这种互操作性,从而更好地服务客户。 今天People Analytics使用了以下数据集。(1)人力资源系统核心数据。HRIS、LMS、ATS等;(2)Google日历与地图数据;(3)我们通过定制的调查平台采集的情感数据,该平台是为开箱即用的分析而调整的;(4)EMSI;(5)LinkedIN。 往前想,有大量的数字痕迹数据存放在整个公司,但不属于上述数据集:胸卡数据、志愿服务数据、健身房数据等。这些数字痕迹将使我们能够更好地 "倾听 "员工的声音,当与机器学习相结合时,我们可以建立 "员工体验措施",而无需调查员工来获取这些数据。这就是我们如何从周期性的倾听(即脉冲调查)发展到持续性的倾听。 People Analytics成功的关键要求是什么? 我想到的三个成功要素是:1: (1)高管支持;(2)人才;(3)基础设施.....,依次类推。 我们成功的原因之一是来自CHRO的直接支持,对该职能进行投资和 "保护",使其能够执行先进的分析和实验。我们很容易被事务性的报告要求所困扰,而这些报告要求永远不会让你拥抱真正有趣和创新的机会。因此,拥有高管支持,对这些类型的请求说 "不 "是至关重要的。作为基因泰克HRLT的一员,People Analytics能够有更多的机会影响我们的同行和他们的战略,这一点非常重要,如果我们不是一个高层团队,就很难做到。 许多组织将People Analytics职能置于另一个人力资源中心内。这种组织结构使得People Analytics很难获得同样的成功。 当我们说到人才时,我们指的是持久性和多才多艺等方面。我们稍后将讨论一些硬性技能,但当你启动一个People Analytics功能时,你不会有干净的数据,也不会有能够实现自动化和规模化的关键基础设施元素,而且会有很多从未用证据来领导的人力资源领导者的健康怀疑。所以,你需要的是有拼劲的人,也许是那些曾经在初创企业工作过的人,他们习惯于 "边干边建 "的背景。而且由于一开始你不会有一个强大的团队,所以多才多艺、能身兼多职的人是非常有价值的。可能是一个能进行数据科学和工程的人。可能是一个既能带来商业头脑又能进行变革管理的人。这种多面性在旅程的早期是至关重要的,坦率地说,甚至在规模上也是如此。 PA应该先招聘什么角色? 我们的第一个员工是来自医药组织中产品开发的数据工程师。这位员工不仅带来了围绕大规模管理大型数据的能力,还带来了商业敏锐度和来自潜在客户群的即时可信度。而此后她又转到了多样性与包容性方面(People Analytics可以从业务上获取人才进入人力资源部门的好方法),但她在将People Analytics从一个概念提升到一个创造价值的组织中起到了至关重要的作用。 我们不知道这里有一个 "正确 "的答案,但如果你假设数据访问和基础设施将是不成熟的,那么雇佣一个习惯于在更成熟的数据环境中工作的数据科学家,很可能会导致重大挫折和高概率的流失。同样,如果你雇佣一个更有咨询背景的人去开发客户关系和项目队列,这些项目将以人工方式交付,你的扩展能力将受到很大的限制。 因此,我们真的认为雇佣一个数据工程师(最好是懂得一些数据科学的人)是我们会去的地方。这样一来,你就可以创建自动化的基础设施,让洞察力得到扩展,同时,创建开发下一代洞察力的能力。以规模化的方式提供机器学习洞察力,是People Analytics快速展现价值的好方法。 PA团队需要哪些能力才能成功? 我们认为有四大能力是每个People Analytics团队应该 "拥有 "的,而不是从IT等合作机构 "租用 "的。其中有些东西可以 "灵活",取决于你能接触到的一些能力和人才......但大体上,如果一个People Analytics职能部门拥有以下能力,它将以更高的效率和效果服务于客户。(1)技术与数据管理;(2)概率与统计;(3)商业敏锐度;(4)主题专长。 注:此示意图主要来自与基因泰克People Analytics合作的Ian O'Keefe。 正如你所看到的,当你把这四种能力结合起来,你就实现了一个成功的People Analytics功能的关键属性。(1)数据科学与机器学习;(2)解决方案开发;(3)客户咨询与问题制定;(4)讲故事与可操作的见解 如果有谁能做到以上四点,请直接发邮件给我,这样我们就能给你一个无法拒绝的报价!如果有谁能做到以上四点,请直接发邮件给我,这样我们就能给你一个无法拒绝的报价。 采用什么机制来操作高效的sprint? 我们认为今天整个人力资源行业对sprint有一些非常大的误解。我们对spring有很多了解,因为它是软件开发出来的,而我们的团队中恰好有软件开发人员。我们听到 "6个月的sprint "和 "流向工作 "这样的说法,坦率地说,这些对于敏捷性和敏捷软件流程来说是不合时宜的。 Sprints其实是关于从长的(即6个月)开发周期转向更短的开发周期(即2-3周),这将允许客户在更早更快的周期内进行投入/反馈,最终服务于产品/市场的匹配。最好的办法是在3周后就将一个功能转入或取消,而不是低头呆6个月后才知道客户没有兴趣。 在People Analytics中,我们使用以下机制来操作我们的spring。 Asana - 这是一个在线项目管理工具,它能促进透明度、组织和协作。还有许多其他工具提供类似的功能,如JIRA和Trello。 冲刺周期--我们以3周为一个冲刺增量,让同事们在3周内保持专注的执行状态,然后再上来和客户进行沟通。我们不会偏离这个时间增量。如果一个任务需要的时间超过3周,那么我们就会把这个任务分块,以便它能适应我们的冲刺周期。这种专注需要纪律(因为需求会来),但一旦你发展出保护这些资源的肌肉,产出就会很显著。转换成本极其昂贵 产品所有者--对于我们的每个产品,我们都有一个所有者。他/她的工作是对产品积压进行优先排序,这些积压包括客户的请求,我们将其转化为 "用户故事"(这个过程被称为积压整理)。有时产品所有者是我们咨询团队的成员,有时是实际的客户。一个用户故事的内容是这样的:"作为一个HRBP,我希望能够在我所服务的组织中,将离职调查数据结果可视化到两个层级,这样我就可以更好地了解各个团队的流失情况。" Backlog Sizing - 产品负责人与技术团队合作,对backlog中的每一个用户故事进行大小调整。我们使用XL(7天)、L(5天)、M(2-3天)、S(1天)和XS(半天)。这些都是方向性的估计,以帮助我们确保我们带到3周冲刺中的东西是适合的。每一次冲刺,我们都会在估算方面变得更好。 优先级--PALT(People Analytics领导团队)将对积压项目中的哪些项目进行优先级排序,并将其推入冲刺。我们在冲刺结束时这样做,这样当一个冲刺结束时,下一个冲刺就会开始(冲刺之间没有延迟)。 PA团队的结构和报告线可能是什么样的? 如果你想一想上面的维恩图,那四个圆圈可以组织成更注重技术的人和更注重咨询的人。因此,我们的团队是这样组织的。(1)数据科学与工程;(2)战略与解决方案。 数据科学与工程团队负责管理我们的技术堆栈(Github、Amazon Web Services、Workday的Pipelines等),并创建解决方案(数据产品),使我们的洞察力得以扩展、使用和执行。 战略与解决方案团队负责与客户沟通,作为我们解决方案的产品所有者,管理项目接收和变更管理与特性和功能增强(包括培训),并促进我们的战略工作(包括People Analytics和整个人力资源)。 从报告线的角度来看,我们认为People Analytics应该坐在HR领导团队中。对于HR来说,分析一般不是一个舒适和熟悉的地方(业务领导也同样不熟悉在HR内部接入People Analytics的能力来共同创造实验和解决方案)。当People Analytics被安置在另一个人力资源组织内时,这种不舒服和不熟悉的感觉一般会持续更长时间。通过这种结构,变革管理一般会被减速。 你们的项目入驻流程是什么? 我们希望它是算法,但那是非常理想的,也是不完美的。并非所有的背景都能被编纂,这就是为什么数据能提供信息,但不能做出决策。下面是我们使用的一个框架。 我们发现以下项目维度是最能预测成功的。 (1) 决策权。拥有一个有权将项目见解付诸实施和行动的执行赞助人; (2)战略意义拥有一个公开声明的项目目标的执行赞助人; (3) 激励一致性。有一个愿意为工作提供资金的执行赞助人。 尽管如此,我们在决定承接一个项目时,会考虑以下因素。 (1)与人力资源/公共关系战略的一致性;(2)可解决的市场;(3)可重用性/可扩展性;(4)洞察力的可操作性;(5)所需的努力;(6)可发布性。 如何创建自动化的管道来站立和扩展数据产品? 在一个完美的现代架构世界里,应该有一个数据湖,它的存在的唯一目的就是为了执行分析(预测模型、机器学习、人工智能等)。这个数据湖是不断更新的,并且可以直接查询,这样就可以将数据连接到现代编程语言,比如Python。从数据湖中,我们可以设置自动化的数据管道,让模型、仪表盘和应用程序持续更新/刷新,从而使它们保持与客户相关且有意义。根据数据速度和决策频率,这些产品可以每天、每周、每月等进行更新。 在站立数据产品方面--当你验证了一个实验假设,现在你想扩大这些洞察力的交付规模,以便它们可以被消费以告知决策时,就会发生这种情况。要做到这一点,通常情况下,我们会站立一个服务(AWS让这一切变得非常简单),它可以支持所需的吞吐量(取决于数据的大小和预期的安装基础)。 今天,我们有5个数据产品,我们已经建立或购买并整合了。(1)CalPal;(2)Visier;(3)Surveyor;(4)Exit Survey;(5)People Insights Portal。我们通过冲刺流程培育现有产品并打造新产品(事实上,我们有第6个产品,将在2020年第一季度与我们的竞争情报团队合作推向市场,该产品将WD数据与LinkedIn数据相结合,以便我们能够更好地了解整个公司的人才流动情况)。 你们利用了哪些技术栈/基础设施,为什么? 我们的技术(不包括核心人力资源系统)包括以下内容。 (1)Amazon Web Services ; (2)GitHub; (3)Python; (4)Plotly-dash(用于仪表盘); 5.) MariaDB(安全数据库);6)TypeForm 以上由AI翻译完成,仅供参考。版权归作者
    Chase Rowbotham
    2021年01月12日