关于加快构建全国一体化大数据中心协同创新体系的指导意见

发改高技〔2020〕1922号

各省、自治区、直辖市及计划单列市人民政府,新疆生产建设兵团,国务院各部委、各直属机构:

数据是国家基础战略性资源和重要生产要素。加快构建全国一体化大数据中心协同创新体系,是贯彻落实党中央、国务院决策部署的具体举措。以深化数据要素市场化配置改革为核心,优化数据中心建设布局,推动算力、算法、数据、应用资源集约化和服务化创新,对于深化政企协同、行业协同、区域协同,全面支撑各行业数字化升级和产业数字化转型具有重要意义。为进一步促进新型基础设施高质量发展,深化大数据协同创新,经国务院同意,现提出以下意见。

一、总体要求

(一)指导思想。

以习近平新时代中国特色社会主义思想为指导,全面贯彻党的十九大和十九届二中、三中、四中、五中全会精神,全面落实习近平总书记关于建设全国一体化大数据中心的重要讲话精神,按照国务院统一部署,以加快建设数据强国为目标,强化数据中心、数据资源的顶层统筹和要素流通,加快培育新业态新模式,引领我国数字经济高质量发展,助力国家治理体系和治理能力现代化。

(二)基本原则。

统筹规划,协同推进。坚持发展与安全并重。统筹数据中心、云服务、数据流通与治理、数据应用、数据安全等关键环节,协同设计大数据中心体系总体架构和发展路径。

科学求实,因地制宜。充分结合各部门、各行业、各地区实际,根据国际发展趋势,尊重产业和技术发展规律,科学论证,精准施策。

需求牵引,适度超前。以市场实际需求决定数据中心和服务资源供给。着眼引领全球云计算、大数据、人工智能、区块链发展的长远目标,适度超前布局,预留发展空间。

改革创新,完善生态。正确处理政府和市场关系,破除制约大数据中心协同创新体系发展的政策瓶颈,着力营造适应大数据发展的创新生态,发挥企业主体作用,引导市场有序发展。

(三)总体思路。

加强全国一体化大数据中心顶层设计。优化数据中心基础设施建设布局,加快实现数据中心集约化、规模化、绿色化发展,形成“数网”体系;加快建立完善云资源接入和一体化调度机制,降低算力使用成本和门槛,形成“数纽”体系;加强跨部门、跨区域、跨层级的数据流通与治理,打造数字供应链,形成“数链”体系;深化大数据在社会治理与公共服务、金融、能源、交通、商贸、工业制造、教育、医疗、文化旅游、农业、科研、空间、生物等领域协同创新,繁荣各行业数据智能应用,形成“数脑”体系;加快提升大数据安全水平,强化对算力和数据资源的安全防护,形成“数盾”体系。

二、发展目标

到2025年,全国范围内数据中心形成布局合理、绿色集约的基础设施一体化格局。东西部数据中心实现结构性平衡,大型、超大型数据中心运行电能利用效率降到1.3以下。数据中心集约化、规模化、绿色化水平显著提高,使用率明显提升。公共云服务体系初步形成,全社会算力获取成本显著降低。政府部门间、政企间数据壁垒进一步打破,数据资源流通活力明显增强。大数据协同应用效果凸显,全国范围内形成一批行业数据大脑、城市数据大脑,全社会算力资源、数据资源向智力资源高效转化的态势基本形成,数据安全保障能力稳步提升。

三、创新大数据中心体系构建

统筹围绕国家重大区域发展战略,根据能源结构、产业布局、市场发展、气候环境等,在京津冀、长三角、粤港澳大湾区、成渝等重点区域,以及部分能源丰富、气候适宜的地区布局大数据中心国家枢纽节点。节点内部优化网络、能源等配套资源,引导数据中心集群化发展;汇聚联通政府和社会化算力资源,构建一体化算力服务体系;完善数据流通共性支撑平台,优化数据要素流通环境;牵引带动数据加工分析、流通交易、软硬件研发制造等大数据产业生态集聚发展。节点之间建立高速数据传输网络,支持开展全国性算力资源调度,形成全国算力枢纽体系。(发展改革委、工业和信息化部、中央网信办牵头,各地区、各部门负责)

四、优化数据中心布局

(一)优化数据中心供给结构。发展区域数据中心集群,加强区域协同联动,优化政策环境,引导区域范围内数据中心集聚,促进规模化、集约化、绿色化发展。引导各省(自治区、直辖市)充分整合利用现有资源,以市场需求为导向,有序发展规模适中、集约绿色的数据中心,服务本地区算力资源需求。对于效益差、能耗高的小散数据中心,要加快改造升级,提升效能。(工业和信息化部、发展改革委牵头,各地区负责)

(二)推进网络互联互通。优化国家互联网骨干直连点布局,推进新型互联网交换中心建设,提升电信运营商和互联网企业互联互通质量,优化数据中心跨网、跨地域数据交互,实现更高质量数据传输服务。积极推动在区域数据中心集群间,以及集群和主要城市间建立数据中心直连网络。加大对数据中心网络质量和保障能力的监测,提高网络通信质量。推动降低国内省际数字专线电路、互联网接入带宽等主要通信成本。(工业和信息化部牵头,各地区负责)

(三)强化能源配套机制。探索建立电力网和数据网联动建设、协同运行机制,进一步降低数据中心用电成本。加快制定数据中心能源效率国家标准,推动完善绿色数据中心标准体系。引导清洁能源开发使用,加快推广应用先进节能技术。鼓励数据中心运营方加强内部能耗数据监测和管理,提高能源利用效率。鼓励各地区结合布局导向,探索优化能耗政策,在区域范围内探索跨省能耗和效益分担共享合作。推动绿色数据中心建设,加快数据中心节能和绿色化改造。(工业和信息化部、发展改革委、国家能源局牵头,各地区负责)

(四)拓展基础设施国际合作。持续加强数据中心建设与使用的国际交流合作。围绕“一带一路”建设,加快推动数据中心联通共用,提升全球化信息服务能力。加速“一带一路”国际关口局、边境站、跨境陆海缆建设,沿途积极开展国际数据中心建设或合作运营。整合算力和数据资源,加快提升产业链端到端交付能力和运营能力,促进开展高质量国际合作。(中央网信办、工业和信息化部、发展改革委牵头,各地区负责)

五、推动算力资源服务化

(一)构建一体化算力服务体系。加快建立完善云资源接入和一体化调度机制,以云服务方式提供算力资源,降低算力使用成本和门槛。支持建设高水平云服务平台,进一步提升资源调度能力。支持政企合作,打造集成基础算力资源和公共数据开发利用环境的公共算力服务,面向政府、企业和公众提供低成本、广覆盖、可靠安全的算力服务。支持企业发挥市场化主体作用,创新技术模式和服务体验,打造集成专业算力资源和行业数据开发利用环境的行业算力服务,支撑行业数字化转型和新业态新模式培育。(发展改革委、工业和信息化部牵头,各地区、各部门按职责分工负责)

(二)优化算力资源需求结构。以应用为导向,充分发挥云集约调度优势,引导各行业合理使用算力资源,提升基础设施利用效能。对于需后台加工存储、对网络时延要求不高的业务,支持向能源丰富、气候适宜地区的数据中心集群调度;对于面向高频次业务调用、对网络时延要求极高的业务,支持向城市级高性能、边缘数据中心调度;对于其它算力需求,支持向本区域内数据中心集群调度。(各地区、各部门按职责分别负责)

六、加速数据流通融合

(一)健全数据流通体制机制。加快完善数据资源采集、处理、确权、使用、流通、交易等环节的制度法规和机制化运营流程。建立完善数据资源质量评估与价格形成机制。完善覆盖原始数据、脱敏处理数据、模型化数据和人工智能化数据等不同数据开发层级的新型大数据综合交易机制。探索有利于超大规模数据要素市场形成的财税金融政策体系。开展数据管理能力评估贯标,引导各行业、各领域提升数据管理能力。(发展改革委、中央网信办、工业和信息化部牵头,各有关部门按职责分工负责)

(二)促进政企数据对接融合。通过开放数据集、提供数据接口、数据沙箱等多种方式,鼓励开放对于民生服务、社会治理和产业发展具有重要价值的数据。探索形成政企数据融合的标准规范和对接机制,支持政企双方数据联合校验和模型对接,有效满足政府社会治理、公共服务和市场化增值服务需求。(中央网信办、发展改革委牵头,各地区、各部门按职能分工负责)

(三)深化政务数据共享共用。充分依托全国一体化政务服务平台,发挥国家数据共享交换平台数据交换通道的支撑作用,建立健全政务数据共享责任清单机制,拓展政务数据共享范围。加快建设完善数据共享标准体系,解决跨部门、跨地区、跨层级数据标准不一、数据理解难、机器可读性差、语义分歧等问题,进一步打破部门数据壁垒。(国务院办公厅、发展改革委牵头,各地区、各部门按职责分工负责)

七、深化大数据应用创新

(一)提升政务大数据综合治理能力。围绕国家重大战略布局,推动开展大数据综合应用。依托全国一体化政务服务平台和国家“互联网+监管”系统,深化政务服务和监管大数据分析应用。支持各部门利用行业和监管数据,建设面向公共卫生、自然灾害等重大突发事件处置的“数据靶场”,定期开展“数据演习”,为重大突发事件期间开展决策研判和调度指挥提供数据支撑。(国务院办公厅、发展改革委牵头,各部门、各地区按职能分工负责)

(二)加强大数据公共服务支撑。聚焦大数据应用共性需求,鼓励构建集成自然语言处理、视频图像解析、数据可视化、语音智能问答、多语言机器翻译、数据挖掘分析等功能的大数据通用算法模型和控件库,提供规范统一的大数据服务支持。(各地区、各部门负责)

(三)推动行业数字化转型升级。支持打造“行业数据大脑”,推动大数据在各行业领域的融合应用。引导支持各行业上云用云,丰富云上应用供给,加快数字化转型步伐。推动以大数据、云服务促进新业态新模式发展,支持企业线上线下业务融合,培育数据驱动型企业。(各地区、各部门负责)

(四)推进工业大数据平台建设。支持工业互联网大数据中心标准建设,加强工业互联网数据汇聚、共享和创新应用,赋能制造业高质量发展。鼓励构建重点产业、重大工程数据库,为工业发展态势监测分析和预警预判提供数据支撑。(工业和信息化部牵头,各地区、各部门按职能分工负责)

(五)加快城市大数据创新应用。支持打造“城市数据大脑”,健全政府社会协同共治机制,加快形成统一规范、互联互通、安全可靠的城市数据供应链,面向城市治理、公共服务、产业发展等提供数据支撑。加快构建城市级大数据综合应用平台,打通城市数据感知、分析、决策和执行环节,促进提升城市治理水平和服务能力。(各地区负责)

八、强化大数据安全防护

(一)推动核心技术突破及应用。围绕服务器芯片、云操作系统、云数据库、中间件、分布式计算与存储、数据流通模型等环节,加强对关键技术产品的研发支持。鼓励IT设备制造商、数据中心和云服务提供商、数字化转型企业等产业力量联合攻关,加快科技创新突破和安全可靠产品应用。(发展改革委、工业和信息化部、中央网信办牵头,各地区负责)

(二)强化大数据安全保障。加快构建贯穿基础网络、数据中心、云平台、数据、应用等一体协同安全保障体系,提高大数据安全可靠水平。基础网络、数据中心、云服务平台等严格落实网络安全法律法规和政策标准要求,开展通信网络安全防护工作,同步规划、同步建设和同步运行网络安全设施,提升应对高级威胁攻击能力。加快研究完善海量数据汇聚融合的风险识别与防护技术、数据脱敏技术、数据安全合规性评估认证、数据加密保护机制及相关技术监测手段等。各行业加强上云应用的安全防护,保障业务在线安全运行。(中央网信办、发展改革委、工业和信息化部牵头,各地区、各部门负责)

九、保障措施

(一)完善工作机制。各地区、各部门要提高认识,加强跨地区、跨部门、跨层级协同联动。依托促进大数据发展部际联席会议制度,发展改革委、工业和信息化部、中央网信办会同有关部门建立一体化大数据中心协同创新体系工作机制,充分发挥专家决策咨询的作用。各地区要建立工作协调机制,统筹相关力量,积极推动大数据中心体系建设。(各地区、各部门负责)

(二)抓好任务落实。各地区、各部门要结合实际,坚持小切口大带动,在大数据机制管理、产业布局、技术创新、安全评估、标准制定、应用协同等方面积极探索,积累和推广先进经验。鼓励各地区创新相关配套政策,制定符合自身特点的一体化大数据中心建设规划和协同创新实施方案,并加快推进落实。(各地区、各部门负责)

 

国家发展改革委

中 央 网 信 办

工业和信息化部

国 家 能 源 局

2020年12月23日

 

直接来源地址:https://mp.weixin.qq.com/s/HC389_7OqCcCuEKTmpkwfA

应该流转什么?从审查报告文书模板升级说起……

一分钟阅读:

刑检业务下新增三份审查报告文书。检察官在审查报告入卷前,务请先确认一下眼神:根据案情和本省检察官权力清单,该案自己有没有决定权(逮捕权、起诉权)。如果系检察长(副检察长)决定事项,即便审查报告的最低审批权限为检察官,也应当拟制流转签发单进行流转。

 

正文:

虽然检察机关现在是“四大检察”“十大业务”,但最重要的还是刑检案件,最实质的还是捕诉案件流程,而捕诉案件的审查报告就是最核心的文书之一。刘哲检察官曾经说过:“审查报告就是司法工作的里子,思考审查报告就是反思司法工作本身。”。

审查报告是检察机关案件承办人制作的全面反映案件办理情况的综合性工作文书。《人民检察院刑事诉讼规则(试行)》(2012年修订)第376条规定:“办案人员对案件审查后,应当制作案件审查报告”(2019年修订后的《人民检察院刑事诉讼规则》对2012 年版第 376 条的内容进行了压缩,没有明确提及制作审查报告,但第五百零六条、第六百零九条明确将审查报告列入报告、调取的内容,而且从其后发布的《人民检察院工作文书格式样本(2020年版)》、统一业务系统的文书配置及结案要求来看,制作审查报告仍然是应当开展的一项工作)。本文无意去论述审查报告本身的重要性,只打算结合此次统一业务应用系统审查报告升级和司法责任制相关的问题谈一些思考。

 

一、升级内容

刑检业务下新增三份审查报告文书:《×××案审查报告(适用捕诉一体案件)》、《×××案审查报告(适用速裁程序/认罪认罚简易程序案件)》,设置在审查逮捕案件的审查节点与一审公诉案件的审查起诉节点;《×××案审查报告(适用非羁押直诉案件)》,设置在一审公诉的审查起诉节点。

刑检业务下的审查逮捕案件中,停用原来的《审查逮捕意见书(提请逮捕用)》/《审查逮捕意见书(移送逮捕用)》。

二、升级背景

(一)流程一体的观点

捕诉一体改革后,刑检部门有同志提出将审查逮捕案件和一审公诉案件合并,这当然有一定的道理,但是实践中,以公安机关报捕报诉案件为例,从层级上看,审查逮捕案件和一审公诉案件由两级检察机关审查并不少见,如果合并在一起,公安报诉时,是新建案件还是改变管辖?从时间上看,审查逮捕案件和一审公诉案件间隔时间并不短,如果合并在一起,检察官完成逮捕案件后发生调岗、调离等情况,公安报诉时,是新建案件还是变更?所以说,重量级的“捕诉案件”,难以应对实践中复杂的情况。我们不能机械的执行“捕诉一体”,有独立价值的案件流程,应该独立存在。

所以,统一业务应用系统中,公安机关提请批准逮捕案件和检察机关自侦部门移送审查逮捕案件,有独立的审查逮捕案件流程;刑检部门检察官在审查起诉过程中决定逮捕的案件,则融合在了一审公诉案件中(当然,融合的不是那么完美,见后文的检察事项建议)。

(二)文书一体的观点

刑检部门有同志提出,都是检察官的“案子”(案-件比中的“案”),有一份审查报告即可,应当“一书到底”,这当然有一定的道理,但是当前系统架构,没有这样的“全局变量”,能够支持一份文书绵延在两个案件流程中持续使用。所以,研发单位开发了“一键复制”的功能,实现在一审公诉案件中可以快速复制审查逮捕案件共享的审查报告。

三、存在问题

统一业务应用系统中,文书的最低审批权限是独立设置的。此次升级方案,将同一份文书配置在不同的流程上,而这些流程对应着不同的检察权。根据各地的检察官权力清单,逮捕、起诉的决定权很有可能不一致,就只能设置为最低的审批角色,往往就设置为检察官。以S省为例:

(一)升级前

1.逮捕案件:S省的权力清单明确,所有的逮捕案件均由检察长(副检察长)决定,所以,将审查逮捕案件的审查报告(《审查逮捕意见书》)最低审批权限设置为副检察长。检察官生成审查报告报副检察长,检察官根据副检察长的决定生成批准逮捕决定书或不批准逮捕决定书(文书最低审批权限均是检察官)。

2.起诉案件:S省的权力清单明确,一审公诉案件,满足某些条件的由检察长(副检察长)决定,其他的由检察官决定,但是不起诉决定均由检察长(副检察长)决定。所以,将一审公诉案件的审查报告最低审批权限设置为检察官,检察官生成审查报告后,检察官审查认为需要起诉的,根据案情自行决定;检察官审查认为需要起诉但根据权力清单需要报检察长(副检察长)决定的,以及审查认为应当不起诉的,将审查报告报副检察长,检察官根据副检察长的决定生成起诉书或不起诉决定书(文书最低审批权限均是检察官)。

(二)升级后

现在审查逮捕和一审公诉的审查报告是同一份文书模板,不能根据本省的权力清单,分别对逮捕权(审查逮捕案件)和起诉权(一审公诉案件)分别设置最低审批权限,目前的现状就是,新的审查报告,最低审批权限,往往只能设置为“检察官”。实践中只能靠检察官提高认识并熟悉检察官权力清单,系统已经不能辅助控制。这种背景下,检察官一定不能认为,达到最低审批权限就可以入卷、可以决定,如果检察官不提高警觉,会发生“无权”决定的情况。

四、应该流转什么?

有同志认为,这个无所谓的,可以根据本省权力清单对《批准逮捕决定书》《逮捕决定书》《不批准逮捕决定书》《起诉书》《不起诉决定书》等文书分别设置最低审批权限。可是,正如案管派前文提及,审查逮捕案件、一审公诉案件中,逮捕权、起诉权流转审批的对象是审查文书,而不是决定文书,决定文书是检察长(副检察长)、检察官决定后的自然产物。

需要注意,统一业务应用系统的文书是挂接在节点下面的,审查报告挂接在审查节点,决定文书挂接在审结虚节点的对应节点下,如果按照以上方案,会产生几个后果:

(一)回退节点

检察官经审查拟不起诉,则检察官生成审查报告后并直接入卷,继而进入不起诉节点制作《不起诉决定书》报送检察长(副检察长)决定。但是,检察长审查认为应当起诉(实践中这很正常),但在系统中,检察官就要回退到审查节点,重新修改审查报告,重新入卷,再进入起诉节点,制作《起诉书》。

(二)多次报批

检察官很自觉,根据本省检察官权力清单,在审查节点提前把审查文书报送检察长(副检察长)决定,如果领导不同意检察官审查意见,检察官可以在当前环节直接更改,完美。但是,检察官根据检察长(副检察长)决定制作《不起诉决定书》,该文书的最低审批权限却配置为副检察长,导致需要再报送审批,否则无法入卷生效——除非,审查文书和决定文书的最低审批权限均设置为“检察官”,但这显然就架空了最低审批权限对规范检察权行使的作用。

五、建议

(一)不改系统就改习惯

在当前系统功能下,审查文书和决定文书的最低审批权限均设置为“检察官”,根据案情和本省检察官权力清单:

1.在审查节点:(1)属于检察官自行决定的,对审查报告直接入卷,(2)属于检察长(副检察长)决定的,流转后入卷;

2.根据决定情况进入对应的审结节点,检察官直接生成决定文书。

(二)基于现有功能最低代价的改良建议:“镜像”

《×××案审查报告(适用捕诉一体案件)》、《×××案审查报告(适用速裁程序/认罪认罚简易程序案件)》,分别复制出适用审查逮捕案件和适用一审公诉案件的版本(内容一致),“一键复制”功能针对适用审查逮捕案件版本进行即可。

(三)动态审批权限

检察人员执行文书入卷时,系统进行如下审查:1.是否满足文书最低审批权限;2.是否触发动态审批权限规则;3.是否通过统一业务规则库校验。通过后,系统分配文书文号,可进行后续的用印、打印操作。

此处的动态审批权限规则,除了包括之前建议的案情规则(罪名、犯罪嫌疑人身份等)外,还需要增加流程规则(如审查逮捕、一审公诉等),甚至,从长远看,还可能涉及刑事案件专业类型(如普通刑事案件、职务犯罪检察案件等)。

(四)检察事项

通过“检察事项”封装文书、案卡。

检察官决定逮捕,之前是“流程”级,捕诉一体改革后,降格为“文书”级,即检察官在一审公诉案件中,制作逮捕文书、填录对应案卡项即可。但这个跨度太大,主要原因,笔者认为是在案件和文书、案卡之间,缺少了一个“检察事项”模型。承办人总体是在办案、具体是在办事,这个办事,对于具体的案件而言,可能是要告知、可能是要换押、可能是要讯问,当然,也可能是“决定逮捕”……在这个层级之下才是采集相关的结构化数据(对应的案卡项)和生成相应的非结构化数据(对应的文书),通过这种模型,解决案卡平铺在承办人面前、数据采集项目过多过频繁,增加工作量的不良体验。

检察事项场景:检察官在拟制审查报告时,旁边就是该审查报告对应的案卡项,包括但不限于犯罪嫌疑人的审结结论。检察官手工填录对应嫌疑人的(拟)审结结论(甚至通过AI从审查报告中分析自动填录),流转检察长决定后,审查结论(案卡)和结论文书(文书)自动匹配、控制。检察长决定对某嫌疑人不起诉的,检察官也无法对该嫌疑人生成起诉书。

数据分析师要去数据部门还是业务部门?

在企业中数据分析师岗位一般归属于两个部门,一个是数据部门,一个是业务部门,而在招聘的时候,统称都叫数据分析师,从岗位JD中很难看出这个岗位的归属部门,需要我们在面试中需要去沟通确认的。由于我比较“有幸”两种架构都待过,分享下自己的拙见。

数据组vs业务组之间的差异

数据组是由一些数据分析师组成的专门组织,而业务组是长在业务部门里的数据分析师。我自己根据我经历过的两种组织的差异性,做了个简单的对比。

数据组也有是随着业务的发展,需求的增长,由数据分析师独立壮大出来的组。专门的数据组最大的好处是有高级数据分析可以学习与指导,然后接触数据面比较广,缺点是离业务较远。

目前造成业务部门内自己招数据分析师而不是用数据组,业务的老板觉得手下用的更顺手,不用等待别人的需求排期,有时也是排外心理不愿意让别的部门插手自己部门的事情。业务部门最大的优点是接地气。缺点就是多数情况下,没有高级的数据分析师指导你,只能自己摸索着发展。

面试中需要确认的问题

关于数据分析师,很多时候可能是Excel或者SQL取数的人资源不够,来招个人做取数机,以及业务领导看很多部门都有数据分析师,没想清楚为什么要招这个分析师。所有这些需要大家在面试中进行确认。

首先跟面试官确认这个岗位汇报的对象是谁,业务老大还是数据的老大,然后就能判断出来组织架构。

——数据组,需要确认的问题是否大部分时间是在取数和对接报表需求,是自己取数还是也有IT(数仓)支持?有无更多接触业务的场景与机会。

——业务组,可以确认是否可以自己取数或者服务对象,决定自己获取数据是否受制于他人;老大中的分析具体是解决问题的场景是什么,确认老板是否只是头脑发热。

数据组与业务组

数据组和业务组各有利弊,那么如果有机会可以给你选择,你可能会困惑。曾经的我在数据组面临转岗机会时候,也犹豫了很久,最后决定试下新的机会。最终我的体验的结论是倾向于长在业务组里的数据分析师。

真正在业务部门,你才对这些数据更敏感,才能知道更多数字背后的故事。说白了,就是你和业务部门同事‘混’在一起。

在业务部门,业务结果为导向,建立更多的合作机会。

其实在业务部门,大部分是实际应用场景的分析,如果给出一个浅显的结论,是很容易被老板diss的。当然随着跟业务接触时间长了,你可以知道业务目前现阶段关注的重点以及目前遇到的问题,主动出击与业务人员合作,容易出成果。

注意点:避免成为新的取数机,自己闯出一片天

由于你是业务里的数据分析师,业务里的很多需求就会砸向你,我觉得首先得跟业务老板协商好自己的主要工作职责,首先是过滤掉单纯的取数需求,精力集中于能产生行动的分析上,靠自己努力成为业务的分析专家,打造竞争壁垒。

数据组同学怎么办

那么现在在数据组的同学,可能会说,我已经在数据组怎么办呢。

我觉得在数据组的缺点是远离业务,所以就是要跳出自己的舒适区,和自己老板协商,对接具体业务产线,参加业务的会议,知道业务关注什么,寻觅合作机会。

文源:数据氧气

直接来源地址:https://www.wukong.com/question/6899633546828185864/

数据分析不只是一个岗位,更是一种职场必备能力

从事数据分析十年以来,我越来越感知到数据分析的学习与成长从来都不是纸上谈兵,不是理论空谈,也不是拿工具说事,而是不断在实践中迭代理论、磨炼经验。

近十年来,我先后在零售、电商等行业工作,一直专注钻研数据分析,包括数据分析技术、业务赋能、数据分析平台建设,以及数据分析团队的组建与管理等。

在整个过程中,我主导搭建过企业数据底层架构,通过统一化业务系统数据资源,从数据提取、集成,到数据清洗、加工、可视化,实现了一站式分析,帮助公司解决了数据混乱、业务系统孤岛等“老大难”问题。我也曾主导搭建上层 BI 项目级应用,让企业实现了营销模式全覆盖和数据流通。

实践的过程,就是我个人历练成长的过程。这一路走来,我在数据分析领域积累了丰富的业务经验和踩坑经历,并越来越深刻地感知到数据分析的重要性。

数据分析能力在不断“破圈”

任何岗位都要体现自身价值,数据分析最重要的就是给企业和业务带来价值。不过事实上,从我接触的数据相关的同学来看,大部分却专职做着利用 SQL 取数、写数据报告等枯燥、机械、低价值感的工作,导致自己越做越没动力。深究其原因,很重要的一点是:只是被动完成需求。

我刚开始做数据分析的时候,也是完全被动地接受来自业务和 IT 部门的需求。比如帮业务人员取一些零售数据等,但是怎么从客户维度、销售维度、门店维度去分析差异数据,该怎么做客户画像、产品规划、投入预算等,却不是随便跑跑 SQL、做几张 Excel 报告就能够完成的。只有真正挖掘数据背后隐藏的价值,才能够帮助你脱离低价值感的机械数据岗位。

如果你在分析业务需求时具有了这样的思维,那么恭喜你,你成功找到了普通数据工作与数据分析的分水岭——主动寻找数据价值,这也是数据分析会大火的原因之一。

如今,各企业都在数据化进程加快的激流中,谋求突破用户增长瓶颈、开展精细化管理的方法,数字化转型的大潮让数据分析人才供不应求。

无论是专业的数据分析岗位,还是运营、产品、财务、人力、销售等岗位,都开始关注从业者的数据分析能力:运营需要通过数据分析来解决流量、用户增长问题,产品需要利用数据分析解决业务增长需求,财务更要通过数据分析支持业务分析与管理……数据分析技能“不断破圈”。

无论你处于什么岗位,具备数据分析思维、懂得利用数据挖掘价值,便可以更客观地审视公司业务并优化流程,创造更高的企业与个人价值,成为职场的佼佼者。特别是在互联网公司中,反观对数据分析还没有丝毫概念的人,往往很快就遭遇瓶颈,在职业发展的道路上停滞不前,甚至被边缘化!

怎样才能学好数据分析?

跃跃欲试者众,但学好、用好一门技术并不简单。

我是一名典型的转行者,最初学习数据分析完全是个人兴趣推动,但问题和困惑也随之出现。自学的过程中,我发现一些知识开始越学越乱,明明看了很多资料,却还是很难搞懂实际业务场景,处于盲人猜象的迷茫阶段。在后来面试招人、搭建团队的过程中,我也深切感受到这是很多入门数据分析的初学者必然会遇到的问题。

于是,我决定深入行业去体会实际场景。在掌握了一些简单的数据分析基础技能(如利用 Excel 进行数据分析)的情况下,我毅然转行进入了电商行业,做一名数据分析专员,从最简单的报表、取数等工作开始了我的数据分析从业生涯。

再后来,我在业务工作中又不断掌握了 Python、SPSS、Hadoop 和各种 BI 工具等技能,能够利用各种工具或者编程语言对数据分析进行清洗、加工和可视化处理等操作。这时我开始尝试分析业务,想要进阶高级数据分析师。

但此时,我发现自己对业务的了解只浮于表面,脑海中没有具体场景,很难突破瓶颈,于是一直无法摆脱“工具人”的定位。这一点,我想大部分数据分析师都有切实的感受:盯着满屏的数据,半天分析不出一点结论和建议,只能做着低价值感的工作。职业生涯的天花板触手可及,这不是我选择这条路的初衷!

后来,我专门拿出时间学习业务部门的知识,包括流程梳理、业务模型、指标体系建立等。再后来,又逐渐承接业务部门的数据项目分析需求。比如采集人力数据做销售人员绩效分析,为此我专门学习了 HRDA(人力资源数据分析)中关于绩效管理、TOP 模型等知识,最终依靠数据模型优化了公司销售人员的绩效算法,提升了业务流程。

就这样一步步经历挫折、误区与摸索之后,我也终于从一个一无所知的纯小白,成长为一名略有成就的数据分析师。在这个过程中,我愈发感知到数据分析对于全行业的重要性,因为任何一家企业都需要利用数据资源创造利益价值,而我们数据分析从业人员就是为了挖掘数据价值而存在的。

(略,见原文)

我建议你多去了解业务、熟悉业务、解剖业务,只有以长时间积累的业务经验作为赋能基础,数据分析工作才能长远地发展下去。

最后请记住一句话:学习任何一种知识,坚持到底可以打败 99% 的人!

直接来源地址:https://www.toutiao.com/i6893406066017567240/

论数据分析师的职业技能

笔者作为一个有幸在数据分析与建模领域摸索过的数据从业者,有一些总结与思考。成为优秀数据分析师的道路千万条,其中比较扎实的一条便是从最底层的数据开始做起,积累对数据的认识,了解整个数据生命周期的全貌以及数据生态链都有哪些环节。

当理解了数据是如何产生、存储、使用和销毁的,就会知道为什么公司的数据会有一定的存储周期,为什么有价值、高质量的数据会这么稀缺,为什么数据处理环节如此耗时却又至关重要等等。而这些,恰恰是一名优秀的数据分析师需要懂得的。

以下就抛砖引玉,简单分享一下我所理解的数据分析师成长之路和必备知识技能。先上一份数据分析师成长的路线图,看看在不同阶段的数据分析师都应做到什么。

那么从数据分析的菜鸟,一路升级到优秀的数据分析师,需要哪些知识和技能呢?

知业务
数据分析不是无源之水,具体的业务场景才是数据分析的初始目标和最终归宿。要做到从业务中来,到业务中去,就要求数据分析师熟悉行业知识、公司业务及流程。

比如做一个信贷相关的数据分析项目,如果对相关信贷产品的设计,贷款的申报、审批、发放、风控等业务流程,以及流程内诸如客户经理、审批人员、放款人员、贷后监督人员的职责分工和工作内容有一定的了解,便可以从庞杂的业务信息流中有的放矢地选取分析目标和有用数据,产出真正业务人员用得上、用得好的数据分析模型、策略和产品。

会分析
需要掌握数据分析基本原理与一些有效的数据分析方法,并能灵活运用到实践工作中,以便有效的开展数据分析。在知识库中提前储备一些如对比分析法、交叉分析法、综合评价分析法等基本的分析方法,以及回归分析法、聚类分析法、其他机器学习与人工智能算法等高级的分析方法,做到心中有数,随时可用。

而想要在数据分析之路上走得更远,成为专家乃至数据科学家,对各类方法的理解不仅要知其然,更要知其所以然。比如,构建评分卡常用到的逻辑回归模型,可以了解它的基本假设、损失函数、优化方法是什么,如何处理数据才能提高该类模型的稳定性和准确率,与其他可替代方法相比的优缺点等。

用工具
数据分析方法是理论基础,数据分析工具就是实现数据分析方法理论的抓手。面对越来越庞大的数据,仅仅依靠Excel等基础工具已无法满足需求,掌握更强大、专业的数据分析工具或编程语言(如BI、SQL、SAS、Python等)以及常用的数据分析库(如Python中的Pandas和Scikit_learn等),辅助完成数据分析工作,可以达到事半功倍的效果。

擅表达
虽然常常被忽略,但这可能是最为关键的一部分。一方面,多数分析成效不佳的问题都和前期同业务与开发人员沟通不足、理解不够有关。和相关业务人员、开发人员的沟通涉及业务术语与技术术语的翻译与转化,不同角色间思维方式和表达习惯的差异对数据分析师的沟通表达能力提出了很高的要求。

另一方面,撰写分析报告,将数据分析的结果和得出的观点借助文字、图表甚至影像简明而高效地传递给目标受众(经理、客户等),也是优秀数据分析师的必备能力。

懂管理
从一个数据分析项目的规划和启动,到中间的执行和监控,直至项目的报告和收尾,每一个环节都需要一定的管理协调能力。比如,在项目规划启动阶段,需要协调业务人员对需求进行分析,对现状进行评估,也需要组织分析人员对项目进行可行性分析,形成计划书,还需要协调开发人员进行数据完备性调研。在合适的时间、以恰当的方式将有限的资源调配到各项工作上,持续推进项目直至按时保质保量完成,无不考验着管理能力。

知业务、会分析、用工具、擅表达、懂管理,这些技能的磨练难以一蹴而就,最为直接的途径就是多参与项目,可以是手头正在参与的各种数据分析类工作,可以是Kaggle竞赛上的项目,甚至可以“无中生有”,就一些日常工作生活中的小事做一点探索,比如研究一下车牌拍卖数据来做一个竞拍策略,或利用Excel的宏模块做一些数据的自动化可视化展示。总之,get your hands dirty,行动起来,踏上成为一名优秀数据分析师的道路。

文源:数据治理周周谈

直接来源地址:https://www.wukong.com/question/6903334291250495752/

大数据从业10年,从一个BI项目的失败,看到数据治理的重要性

很多企业在做BI项目时,一开始的目标都是想通过梳理管理逻辑,帮助企业搭建可视化管理模型与深化管理的精细度,及时发现企业经营管理中的问题。

但在项目实施和验收时,BI却变成了报表开发项目,而报表的需求往往和个人习惯有关,一旦人员发生变动,尤其是新入职的高层,会把前公司的内容搬过来,这就需要重新开发一大堆报表。

如果不从源头进行控制,被动服务模式下的IT不可能满足所有人的报表需求。接下来我们要讲的这个案例就真实反应了这个过程,同时也为大家解析问题产生的原因并找到解决问题的方法,建议所有有计划或已经实施BI项目的企业,认真阅读本文。


一、2011年底至2012年初,笔者在某女装公司组织实施BI系统,项目第一期就花了100多万,长达6个月的周期,经历了业务需求调研、数据清理、指标体系梳理、数据模型构建等等一系列中规中矩的项目实施过程。

从业务个性化需求报表到以经营指标为导向的数据模型、数据驾驶舱等等,在项目组看来,除移动化展现,几乎覆盖了当前所有业务需求。在多次宣导并召开上线动员大会后,BI终于正式运行了。

然而现实却给了项目组一个响亮的耳光,在BI系统上线后,3个月内不仅使用次数屈指可数,就连最初要求的月度经营分析和绩效考核必须从BI中取值这两点都没有实现,依然需要业务部门从各个系统中导出数据再自行计算统计。

第一期项目很快就被宣判失败,这让整个项目组深受打击,实施方法论是没有问题的,也针对上述状态的可能性做了很多短期过渡的报表,还有最大自由定义的万能报表,但最后用户们依然不满意。这究竟是什么原因呢?

二、项目组进行反思,并用一周时间去做了用户调研,进行深入地讨论总结。

1、大部分用户反馈BI系统操作缺乏便利性,使用起来特别麻烦。因为每个用户只需查看自己日常工作的数据即可,这第一期BI系统实施把所有业务特性进行了归纳,按照其基础职能设置指标组合与自主选择的时间跨度栏位。

用户因此产生一个印象就是需要的报表全部堆砌在一起,你需求什么自己去找,而且部分派生指标取值需要重新计算后产生,报表展现的效率低下,BI操作起来就很痛苦。

其实每一项体系既要有决策层的视角,也要有管理层的视角,虽然按照操作层的指标体系与时间自定义几乎涵盖一切,但这样并没有针对每一个岗位进行相应的配置,要想得到用户认可,首要要素需要满足各层级用户在某一时间周期内的数据所见即所得

2、指标体系的管理逻辑梳理不清晰,需要用户凭经验去寻找数据背后的逻辑。BI的价值是提升管理的精准度,通过数据构筑一个企业管理模型。

BI系统实施的最大能力就体现在如何梳理管理逻辑,帮助企业可视化展现管理模型与管理的精细度。

3、主数据定义的一致性问题,用户经常反馈业务系统与BI数据报表中相同维度的数据会出现的一些差异,导致大家对BI数据的信任度严重下降。

综合上述调研的问题,项目组征得公司信息决策委员会的同意,于2012年8月启动了第二期的BI系统实施,项目组经过商讨决定改变实施思路,先暂停技术性工作,首要任务是进行公司的数据治理。

三、那么数据治理要怎么开展呢?

第一个就是主数据的治理,也就是说企业经营管理过程会用到哪些主数据?这些主数据是如何产生、如何进行分发、会标记哪些维度形成派生主数据?随后在BI中单独搭建一个主数据中心库,抽取业务系统的主数据按照分类原则存放,并开发主数据一致性校验程序与主数据分发日志表。

第二个是指标的梳理,建立指标体系,定义每个分析过程中的使用的业务指标,建立评价标准,以及计算方法,将业务管理逻辑进行更加直观的呈现,销售环节出现了数据波动就可以直观的呈现出来,通过指标的呈现,可以追踪哪部分业务发生的问题。

第三个就是规范数据产生的入口,以及数据取值的出口的标准。明确所有数据的录入产生的作业标准,建立各个系统到BI的接口规范,企业经营活动中产生的几乎所有数据都要进数据仓库,并由BI系统统一进行数据抽取与数据加工;

另外针对所有业务部、职能部提交的月度经营分析、月度绩效考核、年度关键考核指标、日常管理分析的全部数据需求进行综合评估分析,搭建相应的数据模型,要求任何所有应用数据都从BI系统取值,有了入口与出口的规范才能保证数据的一致性与唯一性。

四、完成上述三个动作后由项目组协同企管部门编撰公司数据管理制度,进行全公司范围的发文,数据管理制度定义了主数据产生、指标体系的结构与算法、数据录入与输出的标准等,是一项公司完整数据管理规范。

发文同时还明确了公司数据治理小组的组织架构与职能,治理数据小组有4种角色:

第一个是数据操作员,是业务部门的操作人员,主要发起主数据的调整、BI系统的维护、指标体系的修改申请等等;
第二个是数据审核主管,往往是部门领导。每个数据是由不同部门负责的,首先由数据操作员提出第一级的申请,其次是数据负责的部门进行审核。
第三个角色是数据的分析员,他对数据审核主管的审核进行分析,看修订的要求是否合理?是否影响其他主数据、指标和数据模型。
第四个角色是BI系统的管理员,经过审批审核后修订要求必须由系统管理员操作才能进行调整。即使这样每隔一个时段还是会有很多业务指标需要调整,比如新的业务出现或是新业务发生变化,甚至要调整公司组织架构,这个流程申请就是项目管理形式进行。
公司OA中也配置相应的三个流程,一是主数据的修订流程、二是管理指标和KPI指标调整的流程、三是报表优化的流程。通过数据治理实施过程,IT团队的数据中心部门基本实现公司数据的统筹工作,整体上也形成了PDCA的循环。

五、数据治理进行了一个月时间后,项目组又重新针对BI系统进行了优化,关键点有以下几个:

梳理业务分析体系:先从纯业务角度总结和梳理,分析各个业务中的流程和思路、常用角度、导向、评价标准,以及业务背后的原因。此体系的建立,是业务分析的总览,也是业务流程环节的真实需求,为后续的指标体系、系统实现打下基础,同时在业务分析体系建立的过程中,收集分析业务、数据的痛点和需求。

重新整理分析需求:根据收集的需求,业务分析的流程和思路,以及系统中的报表进行匹配和提炼,形成新的分析需求。

针对公司零售业务的变化特性,以月度为单位记录业务调整导致的指标比重系数发生调整和变化的历史数据,比如新店变成次新店、次新店升级为老店的时间维度差异。

将指标体系的业务管理逻辑进行更加直观的呈现,销售环节出现了数据波动就可以直观的呈现出来,清楚的知道到底是哪部分业务发生的问题。

更加细致精准划分管理层级的数据展现,针对业务操作层的用户也可在日常应用、周度汇报、月度绩效、年度关键指标上进行数据的直观呈现,所见即所得,虽然开发工作量增加,但是用户体验直线上升。

六、公司的管理理念也发生了深刻的变化,从上至下不再用定性的语言表达,形成了用数据说话习惯。当管理维度与经营业务发生变化的时候,也形成了通过数据治理体系来进行相应修订调整的习惯。

IT团队的数据中心部门设置5个岗位,数据中心经理负责管理工作,数据分析师负责数据模型的设计以及指标的分析,有两个BI系统开发师负责数据仓库维护与数据模型开发,一个H5开发工程师负责移动端开发。

七、从整个BI项目的实施价值上来讲,有这样几点内容可以分享:

从公司经营决策者角度来讲,通过驾驶舱可以快速看到企业的业务全局,及时掌握公司的经营状况,通过数据钻取透视看到整体业务的变化过程。经营层面出现的任何问题,都能透过数据预警反馈到业务管理逻辑上,也非常容易找到关联的业务动作,也就是哪些业务出现了问题。

管理者透过驾驶舱与关键考核指标组合报表可以快速阅读自己的KPI指标以及关注和的经营指标的变化,因为每个管理岗位应该关注的什么内容在体系上梳理很清晰了。

数据仓库,通过建立数据仓库,进行企业的数据治理,将企业的数据打通,形成可以分析和复用的数据资产。

整个操作层用户的工作效率提高了很多,大家都在一个频道,用同一种数据来源做汇报,再也不需要像过去需要临时加工一些乱七八糟的报表了。

BI系统第2期的实施大大丰富了IT团队的知识结构,尤其是数据中心团队的归纳总结、分析问题以及对公司主营业务的认知和理解能力有很大进步。

也让业务部门清楚地认识到IT对企业管理的价值,更加配合今后信息系统的实施与部署,IT部门的影响力得到了直观体现。

直接来源地址:https://www.toutiao.com/i6894172975424078340/

人民检察院单位简称规范建议

一、单位简称首位,为该省、直辖市地区简称,与92式民用车牌省、直辖市简称一致。

二、单位简称第二位,为地级市、县(县级市)、直辖市的市辖区地区简称,本级简称冲突由省级院负责调整,报高检批准;直辖市的分院,统一采用“京一分检”格式;各省的铁路分院,统一采用“云昆铁分检”格式。

三、单位简称第三位,为地级市的市辖区院地区简称,本级简称冲突由设区的市级院负责调整,层报上级检察机关批准。

全国检察机关统一业务应用系统关联案件提案同一及互斥规则配置表

被提案件 新案件 规则
提前介入案件 审查逮捕案件(适用于捕前介入) 同一规则
立案监督案件 审查逮捕案件(适用于监督后报捕) 同一规则
审查逮捕案件 提请批准延长侦查羁押期限案件 同一规则
审查逮捕案件 提请批准重新计算侦查羁押期限案件 同一规则
审查逮捕案件 侦查活动监督案件 同一规则
审查逮捕案件 一审公诉案件 同一规则
提前介入案件/立案监督案件(未报捕) 一审公诉案件(诉前介入,直诉) 同一规则
一审公诉案件 证据合法性调查 同一规则
一审公诉案件 发回重审案件 同一规则
一审公诉案件 法院决定再审 同一规则
审查逮捕案件 立案监督案件(适用于办案中发现) 同一规则
审查逮捕案件 (不)批准逮捕申诉案件审查 互斥规则
审查逮捕案件 不逮捕复议案件 互斥规则
立案监督案件 立案监督复议 互斥规则
侦查活动监督案件 侦查活动监督复查 互斥规则
一审公诉案件 不起诉复议 互斥规则
二审抗诉案件 撤回抗诉复议 互斥规则
不逮捕复议案件 不逮捕复核案件 跨院不涉及
不起诉复议 不起诉复核 跨院不涉及
一审公诉案件 撤销(不)起诉 跨院不涉及
一审公诉案件 二审抗诉案件 跨院不涉及
一审公诉案件 二审上诉案件 跨院不涉及
立案监督复议 立案监督复核 跨院不涉及
提请批准延长侦查羁押期限案件 批准延长侦查羁押期限案件 跨院不涉及
提请批准重新计算侦查羁押期限案件 批准重新计算侦查羁押期限案件 跨院不涉及
立案监督案件 商请督促立案监督 跨院不涉及
一审公诉案件 审判监督抗诉案件 跨院不涉及
侦查活动监督复查 侦查活动监督复查结果的审查 跨院不涉及