背景
最近参与了一个部门内部的基于数字化转型大背景下的的课题竞赛评审工作，各个科室自主上报课题一年来完成的亮眼课题，评审小组制定一套打分系统进行评估，这套打分系统的侧重点是
- 数字化人才培养（从技术与独立承担任务的维度）
- 技术难度
- 客户贡献（是否站在其他部门的角度设立场景，是否惠及多个部门）
- 数据资产贡献
- 内部改善（从降本增效到风险发现到最后的工作方式革新）
这个评分系统本身值得进一步思考，从中可以看出设计者是如何看待部门甚至公司的数字化转型成果的。
数字化人才培养
数字化人才培养。评估的是在课题中，培养了多少专业技术人才，同时培养了多少能够独当一面的全方位人才。这套规则暗示，在课题里，要尽量避免搭便车的存在。因为数字化转型的根基，是基层人员能力与思维的转型。这要求所有参与者，都需从业务设计到技术架构，均要有所涉猎。这对于传统课题的开展方式提出了挑战。在传统的课题推进里，经理，项目推进人，技术人员，权责往往是分开的。他们的隔阂相当大。哪怕是现在的互联网企业，这种分工依然是存在的。那么如何培养这种独当一面的人呢？或者说，培养的工作是如何与课题结合的呢？这是一个制度设计与方法论设计的问题。需要明确两个问题
- 传统的课题推进方式是否依然有效与高效
- 多项目经理培养需要在工作中加入怎样的工作机制
个人认为，课题是实战的地方，对于项目经理的素质培养，应该放到中台工作中，也就是中台需要设计一整套BA的方法论，培养专业的数据经理，从一个到多个，要为中台工作设计一套学院与交流的功能。 在这里，不同的课题的负责人互相交流经验，逐渐形成可行的技能体系，并继续往下发展。
不过对专业技术要求极高的课题，就比较不友好。举个例子，两个涉及领域差不多的课题，一边全员技术水平相当，做出了来的整体课题水平也相当，另一边有一个技术特别强的人，他们的课题技术先进度也因为此人有所提高。那么，在技术难度和技术带来的价值点上，必须做到有效补偿，才能相对公平。所以技术难度分的权重有些偏低了。
这里又涉及到另外一个问题，那就是技术人员归属于哪里？前台，中台，后台都有。理论上他应该属于前台，因为做了具体业务，但他承接的又是中台的责任。所以这个组织架构一定要明确。
技术难度
如上所说，其实技术难度的权重偏低了。而且技术难度应当有具体标准。它是否应当包括业务逻辑上的难度，比如会计专业知识，还是只侧重于IT技术，这些其实比较欠考虑。数字化转型绝对不是对硬技术的探索，对业务的理解永远都是重中之重。因此如何评估技术，技术的权重应当有细分。从前台而言，专业技术与业务技术应该是核心，对于中台而言，BA管理能力，硬技术应当是核心。对于后台而言，业务能力是核心。不同职责评估的技术难度不太相同。
不过有趣的是，虽然评估重点不同，但是内容却是总是在一个框架范围内的。所以一个人的总技术分数是可以被评价出来然后相互比较的。只是针对每个岗位，都有自己的技术分标准而已。中台要设计的技术评分系统，会与实际业务脱节。更侧重硬技术。
客户贡献
客户贡献。这也是释放了一个信号，就是为客户着想，也是“工作产品化”的雏形。将工作做成为客户服务的产品，对外输出的是产品，那么自然就能做到业财融合，提升价值。这在数字化转型工作里也没有任何问题。
放在前中后台的框架中，每个位置的客户定义是不一样的。前台是客户是业务，中台的客户是本部门内的内部客户，后台则涉猎较少。所以产品化的先锋，一定是前台。脉络逐渐清晰，财务的前台，需要一个组织去梳理与定义，他要有产品化的思维以及相配套的工作方式。梳理这个的组织，通常是职能部门。不过当前最困难的，依然是如何把前台的工作与后台的工作区分开来。以及，为公司做事，算不算前台？
数据资产贡献
本身没问题，只是对科室的职能与数据保密性上存在不公平性。原则上应该是属于加分项而不是放在评分中。
要想将数据资产运营起来，一个实体化的中台体系是必须的。所有权限控制，数据梳理，都需要经过中台。他要掌握数据的“生杀大权”。但更重要的是，中台同时是数据技术的服务商，稍微管理不好，就会成为阻碍转型的X因素
内部贡献
内部贡献多集中于在后台与前台，老问题，如何区分这2者？
以上讨论，都是基于财务现在正在规划的前中后台+职能部门的九宫格体系所做的思考。本文章会持续迭代，继续探索数字化转型下组织机构会走向何方。