长篇经典：People Analytics的运营模式探讨作者：Richard Rosenow 来自Medium 阅读需30分钟
我看到很多文章都是围绕着People Analytics的 "为什么 "展开的，也看到了很多关于People Analytics数据科学 "如何 "的文章，这是一个令人鼓舞的趋势，但是探索People Analytics功能运营的文章并不多。
我认为现在是挖掘这一领域的关键时刻，即我看到了整个People Analytics的发展趋势，这表明很多团队的运营模式即将发生转变。
在下面的文章中，我将触及到最初启动许多People Analytics团队的运营模式，深入到现在许多团队运营的服务运营模式，并为下一阶段的运营模式--平台运营模式铺设一个框架。
请大家审视一下下面的论点和观点，并取其精华，为自己对外界趋势的理解加油。我非常期待在文章后的评论中的对话（评论、批评和质疑）。
初步的运营模式 Initial Operating Model
虽然PA职能的某些部分可以追溯到40年代（IO心理学 IO psych），但在2000年代，人们第一次被招聘到正式的HR分析、员工洞察或People Analytics的 "职能"。我之所以把 "职能 "放在引号里，是因为这些早期团队的预算大多只有一个人，如果运气好的话，两个人。这些早期的职能部门做的是全面服务和白手起家的人员分析。他们处理从数据收集到清理，到报告，到合作，甚至从头到尾的研究项目。
对于小团队或新团队来说，这种运营模式是由全能型的领导者来定义的，他们在People Analytics中戴着每一顶帽子。几乎所有的团队都是从这个模式开始的（你必须从一个雇佣者开始），我听说在这种模式下运作的团队仍然是快速了解People Analytics领域各方面知识的最佳方式之一。
当职能的前十年是由精干团队定义的时候，有几个超级团队出现了（Google的People Operations/People Analytics小组，详见《工作规则》“Work Rules”），其他公司的投资也开始开放。在接下来的十年里，完整的职能部门开始从这些一体化的团队中涌现出来。
服务职能 The Service function
从这些一线团队中，我看到大多数团队在未来十年（2010-2020年）成长起来的运营模式，最终形成了我所说的报告、合作关系、研究和运营等松散的子部门。报告是一个一线团队，负责生成定制化和规模化的报告，合作伙伴关系是指基于客户的决策支持，研究是解决深层次的问题，需要博士和重度数据科学家，而最小的投资是运营....滚动......运营的功能（项目管理、工具化，有时还有HRIS）。
如果说我在这里急于描述这种功能的安排，那是因为很多其他的人都讲过这种模式。我也猜想，对于大多数要找到这篇文章的读者来说，你至少对这个模式有一点熟悉，因为它已经成为了一个相当广泛的领域。
对于好奇的人来说，从我所看到的情况来看，似乎有两条共性的路径，那些全能型的团队成长为这种模式。
一、报告开始Reporting start
1人力资源信息系统的报告分析员开始收到越来越多的请求，因此开发了一个正式的报告功能，以了解收到的请求，并使报告的产出和质量标准化。
2随着该报告功能越来越复杂，研究人员也被请来处理开始出现的较难的问题。
3高管们最终提出的要求越来越多、越来越具体，要求的白手起家的方法与大多数博士或数据人培养的白手起家的方法不同，于是顾问们被请来做为分析合作伙伴。
4一旦团队规模扩大，就会发展出一个运营小组来操作内部的职能部门或支持整个团队的技术推广（Tableau、Visier等）。
调查开始Survey start
1 一个1-2人的人才、接洽、IO心理或调查职能部门开始越来越多地要求进行复杂的下游分析，这也是一个复杂的下游分析的要求。
2 他们带来了更多的研究人员，最终开始与其他HR和业务职能部门建立起更紧密的合作关系。
3 随着越来越多的高管需要分析支持，团队会引入顾问或研究项目经理来支持研究人员。
4 最终，该职能部门建立了强大的声誉，成为人力资源数据的首选资源，但为了保护研究人员不受所有数据请求的影响，他们建立了一个报告功能，作为第一道防线，以应对传来的请求。
5 运营再次出现在最后，以帮助稳定功能和管理整个团队的项目。
服务模式还有很多其他途径，但这两条路径是我见过的最常见的（最近我甚至看到HR团队推出了全额预算，并计划在前面成长）。这可能是一个自然平衡的PA功能，报告团队保护研究人员并提供可扩展的洞察力，分析合作伙伴协调资源到战略位置，并为关键领导提供白手套支持，研究人员交付大赌注，而运营则支持整个团队。
或者，也许这种看似 "自然 "的结构是一个紧密的PA社区的结果，领导者之间相互支持，分享笔记，并经常在公司之间跳来跳去组建团队。不管是哪种情况，这种运营模式已经大量涌现，并为People Analytics提供了很好的服务。
我会把这种运营模式归类为服务功能。有时人们会对 "服务 "这个词反感，认为听起来不太有战略意义，但我却会反推这一点。在我看来，在人力资源部门内部（在成熟的团队中，在人力资源部门外也有成熟的团队），有的客户需要帮助做出与劳动力相关的决策，而People Analytics功能提供的是一种服务，即生成数据、报告、分析或研究，以支持决策。这仍然是一个高度战略性的职能，但我们必须承认，这项工作是根据客户的需求来进行的。在PA内部可能会有独立的研究工作，与客户的要求分开，但最终这些研究总是需要到客户手中去影响业务。
服务职能的事情是，服务职能本来就是依赖人力资本的。如果你想扩大支持规模，你需要更多的人。许多PA职能部门很快就发现了这一点，因为工作需求迅速超过了人才供给（后面会有更多的介绍）。理想情况下，被支持的客户和人员分析团队成员的比例应该大于1:1（比如一个合伙人可以支持多个领导，或者一个研究员可以支持L&D研究），但对于VIP客户（CHRO、招聘主管等），可能需要1:1或更多的合伙人支持，随着时间的推移，合伙人的支持量开始变得很重。
我说的也只是核心的People Analytics功能，因为很多团队可能会拥有People Analytics+其他HR功能。我见过把People Analytics和HR战略、HR技术、劳动力规划、人才或薪酬结合在一起的，在这些情况下，能够管理好多个职能部门，是那个领导的功劳。在这个框架下，整个超级功能可能更多的是提供混合服务支持和运营主导权，但如果你能把People Analytics的工作和其他功能分开，People Analytics作为一个服务功能来运作，由SME个人为需要决策支持的客户提供服务。
有什么变化？What’s changing
你可能会说："理查德，这个运营模式似乎可行"，"理查德，听起来很不错！"或者 "理查德，你疯了。如果我们能获得构建你描述的功能所需的投资，我们会杀人灭口"，你说的完全正确（除了在诉诸暴力之前，有更好的、尽管速度更慢的方法来获得这种投资之外）。
上文详述的People Analytics服务运营模式，在全球许多公司都取得了巨大的成功。全文到此为止。如果你想建立一个People Analytics功能，现在的服务运营模式很好用，而且在很长一段时间内，这种服务运营模式的投资回报率会高于成本。也有很多小公司，精简版的服务运营模式甚至是最初的模式，可能是无限期的最佳模式。
我甚至不希望提出一个论点，说这个模式在今天已经被打破或没有兑现承诺。我希望强调的是，在某些风向标公司，我看到这种模式正在积极改变，我相信这种转变告诉我们一些关于功能的东西。如果我们能找出这种转变的一些根本原因，那么我们就能从这些公司身上学到什么，从而更好地让其他团队为未来做好准备。
在这里埋下伏笔，引起我注意的趋势是最近出现在人力资源和人员分析职能部门的产品角色的增加。我所说的产品角色是指创造软件产品所需的角色集合（如产品经理、数据工程师、软件工程师和机器学习工程师）。
我在下面的Google drive链接中收集了一些这些产品角色的例子。这些职位描述都是在某一天拉出来的，但这篇文章已经有好几周的时间了，因为我看到越来越多的公司发布和招聘产品角色到他们的PA团队中。
例子 PA 产品职位描述（均为2/15/20日发布)
PA团队转入产品的例子（如果PAFOW拿下谈话，链接可能会断裂）。
Al Adamsen分析认为，未来的人脉分析是在产品上
为什么People Analytics需要像初创企业那样行事 - Dirk Jonker
Example PA Product job descriptions (all pulled on 2/15/20)
Example of PA team moving into Products (link may break if PAFOW takes down talk)
Analysis by Al Adamsen that the future of People Analytics is in Products
Why People Analytics needs to behave like a startup — Dirk Jonker
如果你看上面的服务运营模式和上面的例子，这些产品角色在前两次迭代的PA运营模式所需要的角色中脱颖而出。在HR中，我们需要这么重的火力是什么？这些角色在服务运营模式中的地位在哪里？它开始讲述一个不同类型的PA运营模式的出现或者说是PA运营模式的演变。
是什么在推动着这种变化--规模化 What’s driving the change — Scale
在这里谈一下驱动因素，我认为推动这种运营模式转变的一个主要因素和促成这种转变的两个因素。我认为这些角色的出现背后的驱动力是人们分析的规模化需求。
驱动因素:服务模式的规模化成本较高 Driving factor: Service models are expensive to scale
我听人说过，有一个支持People Analytics的飞轮。
People Analytics Flywheel
1 人力资源部门的团队不知道他们需要People Analytics。
2 他们可以从一个PA团队中领略到了他们的真知灼见。
3 他们的要求更多
4 PA职能获得更多投资
5 飞轮旋转（返回步骤2)
这就是PA职能部门如何在短短几年内从少数几个报表分析员或调查博士，变成巨型团队的原因。HR作为一个整体，一直以来都在渴求数据支持，当他们终于得到数据支持时，就会立刻想要更多的数据支持。
这个飞轮可能从支持一个关键的利益相关者开始。这有时是CHRO，有时是拥有分析能力的母机构（通常是Comp或Talent）。PA团队可能会将该利益相关者与分析业务合作伙伴配对，指导他们之间的关系，并由研究人员挖掘利益相关者的问题，以了解驱动他们业务的杠杆。
当利益相关者开始看到成功的时候，他们不仅会要求获得更多的支持，其他的HR团队也会向PA职能部门寻求帮助。HR把数据带到桌面上是成功的秘诀，成功的消息传得很快。那些已经看到了那第一个行动者的成功的其他职能部门会渴望得到同样的支持，并将数据驱动的洞察力带入关于自己的组织和业务伙伴的决策中。
但是，研究和定制分析需要时间和难得的技能。每个人力资源部门都希望自己独特的最后一公里问题得到解决。报告最终会被运行和重新运行，并进行小的调整，而分析工作也在进行，然后对某一行的业务进行剪裁，然后对新的业务进行重做和重新切割。新客户，他们的直接报告，以及他们的直接报告，都要向PA团队寻求支持。一段时间后，所有的白手起家的工作都开始加人头。在这种模式下，增加人头是满足额外需求的唯一途径。
在增加人头以满足飞轮的需求时，服务模式的投资开始变得沉重，因为它反映了HR，或者更现实的是，投资停止了。当这种投资停止的时候，人分析团队就不得不发出一个号召，优先考虑客户，停止提供超过组织中某一层次的分析支持，或者将自己的资源泡沫化，留给一组特殊的客户。
那么，这些产品工作到底是什么东西可以帮助扩大规模呢？事实证明，服务职能的规模化问题不仅仅发生在人力资源部门。我们已经在许多被打乱的服务行业中看到过这样的情况：Airbnb的一个车库里坐满了软件工程师，就能让一个旅行社的代理商行业倒闭；Uber的一个软件工程师创业公司，就能让一个过去接电话要求告诉出租车司机去哪里的行业倒闭。
当人分析的服务运营模式在企业中达到一定规模后，投资软件来进行规模化的洞察，开始变得更有意义。好消息是，在过去的十年里，有一些外部因素在后台转移，使得PA和HR能够进入软件驱动规模化的下一个阶段。虽然HR之前在自动化方面落后于合作伙伴，但由于技术领域的进步，现在有机会跃升为平价。
有利因素Enabling factors
如果我跳过那些让HR能够跳槽到开发产品的有利因素，那我就太失职了，但同时，我可以写一篇关于这些因素的文章，而这篇博客已经很长了。所以，以下是我的速战速决论点，说明为什么环境已经发生了变化，让HR能够实现产品的这一跳。
总结了一下:数据科学、数据工程和机器学习人才以及计算能力，过去是非常昂贵的，但近几年来，成本的暴跌让HR现在可以进入这个空间。
导致用软件扩大人力资源规模成本下降的因素
1 其他职能部门开始冲击数据科学和数据工程人才的规模效应 (你不需要第10个数据科学家，就像你需要第1个数据科学家一样)。
2 这导致了产品人才市场的人才市场趋于正常化和饱和。这意味着，HR对产品人才提出的要求不再离谱，而随着教育在这个领域的发展，产品人才的供给开始向HR这个职能部门看齐，将其作为进入该领域的一种途径.
3 开源数据科学、编程和自动化工具（如R/Python包）也出现了爆炸式增长，这大大降低了HR开始开发产品的成本门槛。
4 通过AWS、谷歌云和Azure等服务，将开源运动与廉价的云处理和存储的大量增长相结合，意味着一个有能力的人现在可以在几个小时内为产品打下基础。
5 我们看到HR技术能力的急剧上升，这也是有道理的，以前的计算和人才壁垒的下降，这也是有意义的。在过去十年里，像Workday和SAP这样的现代人力资源管理系统的价值已经被广泛接受，我们看到了像Visier、Swoop Talent、OrgVue、One Model这样以数据为导向的人力资源科技公司的出现，这些公司的介入，做了很多硬性的工作，将洞察力组织化和民主化。这些公司中的许多公司不仅提供数据报告，还提供标准化的数据录入，充当数据仓库，提供清理，并提供自己的分析。
这种计算人才和产品人才进入门槛的下降，为HR们打开了进入产品领域的大门。
平台运营模式 Platform Operating Model
如果你是一家企业技术公司的一员，你会发现以下职能部门在企业内部工作，为客户提供技术服务
企业技术模式
1 产品 - 构建技术产品和提升产品以满足客户需求的人员（研发、SWE、数据工程师）。
2 解决方案 - 解决方案团队与买家合作，确保他们从产品中获得最大价值。
3 培训 - 培训团队由专家组成，帮助客户学习如何使用产品。通常是规模化支持（视频、讲座）和一些定制化支持（现场设置）。
4 客户获取 - 客户获取（有时被称为营销和销售）的工作是增加市场占有率，加入新客户，并跟踪当前客户的使用组合，以确保续约协议。
5 专业研究 - 没有任何产品能100%满足客户的需求，所以有些商店有一个定制研究或定制工具组来完成最后一公里。
6 运营--人力资源科技公司需要一个运营团队来运营公司的业务。项目管理、项目管理、项目管理、业务分析人员、内部运营。
Product — People who build the tech product and enhance the product to meet customer needs (R&D, SWE, Data Engineers)
Solutions — Solutions teams work with buyers to ensure that they are getting maximum value out of the product.
Training — Training teams consist of specialists who help customers learn how to use the product. Usually scaled support (videos, lectures) and some custom support (on-site setup).
Client acquisition — Client acquisition (sometimes referred to as marketing & sales) works to increase market share, onboard new clients, and track portfolios of current client’s usage to ensure renewal agreements.
Specialty Research — No product serves 100% of client needs, so some shops have a custom research or custom tooling group to go the last mile
Operations — HR tech firms need an operations team to run the business of the firm. Project management, program management, business analysts, and internal operations.
在未来十年，我相信People Analytics正在向类似的运营模式转变，尤其是在专注于产品的时候。通过支持一个产品，你可以对一个核心的软件进行增量改进，然后把这个软件卖出一万倍的规模化支持，而不是依靠人力资本的增加来扩大团队规模。
我把一个平台人员分析团队可能是什么样子的松散的草稿放在下面。还记得我之前提到过要谨慎对待这些论点吗？现在是一个很好的时机，你可以适当的加点盐。我很想听听你对下面这个模式的看法，我特别期待听到你是否在实践中看到过这种模式，或者你是否认为这是一个可以让你的团队运作的模式。
平台Platform
平台团队是People Analytics机器的引擎。这种模式中的People Analytics平台团队是一个由内部和外部构建的产品集合，为整个业务和支持人员提供分析服务。这涉及到像Visier和One Model这样的工具，将报表或定制化的仪表盘扩展到HR技术产品中内置的内部分析，一路走来。在这种模式下，你甚至可以将一些100%的人力流程作为 "产品 "来管理，但这是另日的文章。
平台内的每一个产品都有自己的产品经理，而内部产品则由开发人员、数据工程师、研究科学家和分析师组成的团队。用户体验技能组将作为整个团队的集合资源，支持产品团队更好地了解业务中的客户。这个子职能部门将构建、维护、支持和理解将人员分析扩展到业务中的工具。
我在图中列举了一个例子，说明哪些类型的工具可以归入人员分析平台的工作领域。
由于冗余的原因，一个People Analytics团队不太可能拥有上面列出的所有工具，但我想举例说明一下平台团队所拥有的工具。未来，一些People Analytics团队可能会决定拥有并构建一个单一的全栈产品，将数据采集、数据仓储，并将数据和洞察力反馈给用户，但由于所需的大量前期成本和外部人力资源技术的进步，团队似乎更有可能拥有一个由内部构建和外部购买的人力资源技术混合的生态系统。
支持这部分运营模式所需的人才类型：数据工程师、产品经理、数据科学家、开发人员、可视化专家、前HRIS、用户体验等。
解决方案Solutions
解决方案团队是专注于提高HRBP、HR线、财务、业务从平台中获得的价值的团队。它不同于合作伙伴团队的服务模式，因为它是一个集合资源的团队，而不是客户分配的团队。这个团队的加入是为了让企业客户和平台团队之间的用户体验价值最大化。
这个团队的工作可以包括直接教育生态系统（去哪里找什么），帮助HR团队成员启动需要生态系统中的数据或洞察力的项目（带着让团队自助服务的心态），或者根据需要对平台进行技术调整（与平台组合作），让平台为终端用户服务。
解决方案团队通过建立一个资源池，而不是1:1的合作关系，直接为客户提供支持，也有助于规模化的PA，但也有助于规模化的PA，让平台团队专注于80-90%的需求，并为10-20%的客户需求填补空白。如果没有解决方案团队，平台团队就会被客户直接要求对核心产品进行定制化修改，导致技术欠账、系统分叉、产品开销增加，平台团队就会被客户的直接需求挤占。
人才类型：技术咨询、项目经理、投资组合负责人、人力资源分析合作伙伴、企业技术解决方案合作伙伴。
培训Training
培训团队对新客户或整个公司的新客户进行入职培训，让他们了解如何与平台上的产品互动。虽然解决方案团队仍然需要人力资本与业务互动（虽然比合作伙伴模式少），但培训团队可以与精干的团队一起运营，创建规模化的资源，如视频培训、互动演示或常见问题解答等，通过自助服务工具访问。
培训通过努力抢先于向解决方案团队提出请求，帮助扩展People Analytics。向解决方案团队提出的请求是培训团队应该开发什么内容的重要数据来源，但培训团队也可以通过向解决方案组提出的常见问题减少多少票量来衡量成功与否。这有助于提升解决方案团队所推动的价值，这反过来又进一步保护了平台团队。
在大多数公司中，PA获得专门的L&D/培训职能可能并不现实，但在那些无法实现的情况下，与L&D直接合作是至关重要的。
人才的类型。L&D专业人员、顾问、培训师、设计师、制作人员。
客户获取 Client Acquisition
构建一个内部营销和销售团队的想法似乎很奇怪，但交付一个People Analytics平台所需要的技能组合与销售People Analytics的工作是不同的。很多时候，我看到People Analytics团队会请一个STEM背景的博士来向企业的高管推销一个项目的想法或潜在项目的影响，虽然有一些罕见的人可以做到这一切，但更多的时候，数据科学团队中的销售技能并不具备。
Ian O'Keefe在最近的PAFOW西部论坛上的一次演讲中说了以下几句话:
我经常遇到的一个问题是，你们是靠什么来招聘的？你们看中的是什么样的技能？技能和技能的组合是我加入时首先看中的东西之一，随着时间的推移，我们也会继续看中。
通常情况下，我们会看到有人从四个不同的领域来找我们，他们在一个领域很深，而且在另一个领域足够危险，足够优秀。我还没有遇到过这样的人，他们有数学专业的高学历，有在技术栈管理的时间，也有在顶级战略咨询公司工作的时间，也有在IO心理研究或团队领导力方面深入的人。如果你是这样的人，请在讲座结束后来找我。
A question I get a lot is what do you hire for. What kind of skills do you see in this space? Skills and the combination of skills is one of the first things I looked at when I joined and that we continue to look at over time.
Typically we see people come to us from four different areas and they’re deep in one and dangerous enough to be good enough in another one. I’ve yet to meet someone who has an advanced degree in mathematics, spent time managing a tech stack, has also spent time at a top tier strategy consultancy, and has also gone deep on IO psych research or team leadership. If you are one of those people, come see me after the talk.
当我们让人发挥自己的优势，我们就会打造出更强大、更多元化的团队。所以要想把平台扩大到整个企业，有一个专门的团队，专注于如何把People Analytics平台内的产品卖给100%的HR或企业，这是一个关键的技能。
这也是一个一举两得的团队。他们会向新的潜在客户推销平台，并向这些客户推销培训和解决方案支持结构，但他们也会充当平台的眼睛和耳朵，做竞争分析，了解客户的痛点。在企业技术领域，市场和销售都在第一线，每天与客户交谈，并将这些信息反馈给从事产品研发的人员是至关重要的。
另外，值得注意的是，People Analytics的飞车式采用也可能意味着，那些在早期就能获得使用权的职能部门也是今天获得最多的部门。当People Analytics团队的投资额度达到极限时，他们就会开始优先考虑和关闭新客户，因为他们的规模化，这可能并没有实现业务战略价值的最大化。建立一个客户获取团队可以确保PA为战略客户组合提供服务。
人才的类型。用户体验、市场营销、销售团队、内容创作、投资组合管理
专业研究 Specialty Research
即使有了一个完整的、运转良好的产品平台，一次性的、定制化的项目也不会消失，但如果平台团队、培训团队、解决方案团队都在做自己的工作，那么剩下的来自业务的需求就会变得非常复杂。这就是最后3%的项目，有时会消耗整个PA团队的能力。总会需要有人去解决那些不太适合平台的战略项目或高关注度的项目（还没有或永远不会），而专业研究团队就像一个特警队一样，去解决这些需求。
专业研究团队的存在，也让平台的科学家们可以研究规模化的解决方案，而不是陷入一次性的高优先级请求的循环中。通过将这些团队分为平台数据科学和专业研究，平台团队可以修复根本原因，而专业研究则可以专注于高关注度的火候。同样，建立一个培训和解决方案团队，可以确保这个专业组织不会被定期报告或教育请求所困住。
从长远来看，专业研究的另一个目标也应该是作为平台的外部研发职能。如果他们发现自己重复做同一个项目3次，就应该有一个与平台的连接点，找到一个HR技术解决方案，或者构建一个可扩展的产品，支持那个重复的问题向前推进。
人才类型：全栈swat团队、IO心理学、数据科学、项目经理、咨询师、数据工程师
运营Operations
最后，人员分析功能需要运营来维持所有的齿轮运转。在服务模式的今天，我们才刚刚开始看到运营角色的出现，我认为这种缓慢的出现可以追溯到服务模式的根源。运营角色有时会让人觉得是团队可有可无的 "自顾之忧"，当你的客户要求更直接的服务支持时，你很难选择投入到看似运营开销的事情上。
然而，运营角色是杠杆式的角色，可以提高人脉分析的整体运营效率和效果。一个强大的运营团队来跟踪各小组的项目和优先级，可以帮助平衡整个团队的工作量。虽然每个子团队可以专注于自己的孤岛，但运营团队应该是跨孤岛的分析，以保持团队的平衡，并与跨职能伙伴合作。
平台运营模式可视化
平台运营模式示例Platform Operating Model Example
为了说明，我在下面的例子中把平台操作模型的一个小单元的例子放在了一起。我们很容易想象这个运营模式在一个围绕Visier实例构建的平台上工作的情景。
团队成员:
1 名数据工程师（平台
1 名数据分析员（平台）
1x 客户获取/培训 (客户获取/培训)
1x 解决方案合作伙伴/培训 (解决方案/培训)
1名研究员（专业研究人员）
1名组长（业务）
软件:
Workday
招聘系统（ATS）
视觉效果
Tableau
Team members:
1x Data Engineer (Platform)
1x Data Analyst (Platform)
1x Client Acquisition / Training (Client Acquisition / Training)
1x Solutions partner / Training (Solutions / Training)
1x Researcher (Specialty research)
1x Team Lead (Operations)
Software:
Workday
Recruiting System (ATS)
Visier
Tableau
在本例中，该平台将由Workday和ATS组成，直接输入Visier。数据管道和数据质量/完整性将由团队中的一名数据工程师管理。数据分析员将与人力资源团队及其客户获取同事合作，根据客户的需求，为人力资源职能部门开发可扩展的报告。由于团队是精益化的，所以数据工程师也会和数据分析员合作，直接从Workday和其他HR系统中拉取数据，在Tableau中生成更多的缩放报表。
而本着保持精干团队的精神，企业如何使用 Visier 和 Tableau 报告的培训将由解决方案员工和客户获取员工分担。在这个团队精简时，独立的培训角色可能没有意义，但如果/当平台的复杂性增加时，可以将其添加到团队中。
客户获取员工将负责跟踪、监控并在全公司范围内推广 Visier，而解决方案员工将与新加入的团队合作，教他们如何构建自定义报告，并管理与团队扩展后的 Visier 和 Tableau 仪表板相关的问题和请求的基于票据的队列。
专业研究人员将直接从所有系统和 Visier 中提取数据，以生成自定义分析。他们将从事从薪酬研究到多样性分析等项目的工作。他们的工作将听从CHRO的指导，为整个企业的决策提供支持。
团队领导将管理团队，管理系统合同，与数据分析员和数据工程师合作，为规模化报告制定战略方向，确保整个团队的工作量平衡，并衡量整个团队的KPI指标。
随着团队的成长，你可以看到数据分析师转变为Visier的产品经理角色，为他们工作的数据分析师或可视化报告的少数数据分析师或可视化报告。额外的产品，如 ONA 工具或劳动力市场工具，也可以添加到平台上，增加对额外产品团队和客户获取小组的需求。
随着产品的复杂性增加，对独立的数据仓库的需求可能会增加，将开发人员、数据工程师和自动化专家纳入其中，以简化数据的摄取、清洗和向产品交付数据的过程。随着PA项目的飞轮旋转，一个集中化的解决方案团队可能会站起来，并建立起一套票务系统来更好地服务于企业，而独立的培训功能可能会出现。
虽然当你把这种模式发挥到前面，池化的客户端模式和通过软件专注于规模化的服务，让这种运营模式能够规模化地支持整个企业。
变化The shift
这并不是理论上的转变。我相信我只是对这种模式进行了阐述，因为实践者们已经开始将其付诸实施。在一些团队中，有一些团队正在朝着这个方向进行彻底的改革，但在其他团队中，这是一种微妙的转变，他们更加关注数据解决方案、自动化和HRIS。我看到今天的团队都在朝这个方向发展，而且在未来几年内，这个步伐会加快。
总结一下，如果我们想在所有企业客户中推广People Analytics，那么让我们走到这里的东西可能并不能让我们走到今天。当他们准备好冲击下一个规模的时候，People Analytics团队可能会开始从支持白手套定制报告和分析的运营模式转向支持白手套定制报告和分析的运营模式，并将更多的精力投入到支持软件的规模化平台的运营模式上，并帮助HR参与到软件中来。
我很高兴看到这个未来的发展，并在未来十年内帮助这个未来的发展，我希望你也是如此。
以上由智能的AI翻译完成，HRTech仅为传播交流。来源medium.com
原文标题：People Analytics: Platform Operating Model
运营模型
扫一扫 加微信
hrtechchina
