论数据分析师的职业技能

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

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

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

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

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

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

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

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

用工具
数据分析方法是理论基础,数据分析工具就是实现数据分析方法理论的抓手。面对越来越庞大的数据,仅仅依靠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式民用车牌省、直辖市简称一致。

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

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

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

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

统一业务应用系统自动轮案功能优化建议

为适应司法责任制改革,全国检察机关统一业务应用系统升级了自动分案模块,实现了“随机分案为主、指定分案为辅”的案件承办确定机制。全国检察机关内设机构改革后,为适应捕诉一体等新的需求,自动轮案功能还有很多值得改进的地方,需要持续优化升级。

一、轮案规则

(一)组间平衡

当前,统一业务应用系统无法实现一名检察官在多个轮案组之间的办案数量均衡,轮案组设置越多,轮案均衡性越差。举个例子,内设机构改革后,基层院基本没有独立的未检部门,一般办理未检案件的检察官在一部,由于未检案件数量相对较少,员额相对紧张,所以,专门办理未检案件的检察官可能还会办理普通案件。按照现有规则,该检察官会加入普通轮案组和未检轮案组进行轮案,普通轮案组的轮案比例可能会略低一些。问题是:未检案件与普通案件的比例不是固定的,没有办法设定一个科学的普通轮案组的轮案比例。所以,组间平衡就非常重要了。本例中,将普通轮案组和未检轮案组设置为“组间平衡”,当检察官在未检轮案组分配一个案件后,普通轮案组自动轮空,停止一轮分案,确保其有足够时间审查案件,也保证办案的均衡性(否则,办理未检案件的检察官相对办理普通案件的检察官就多办理1件案件)。

(二)批量分案

当前系统是针对每件案件从轮案组中随机抽取一个办案团队(检察官办案组或者独任检察官)来承办的分案方式,不能一次批量分案。以业务量较大的检察院的一审公诉案件为例,可能在3天内陆续收到6~9个案件,每轮随机分配1个案件,所以案件可能不在同一天分配过来,由于告知、换押必须在3日内,致使检察官需要频繁往返看守所。特别是案多人少矛盾突出的部分检察院,为提高办案效率,提出了批量分案的需求。建议系统修改为既支持每件案件随机分配,也支持一批案件随机分配。案件管理部门或者业务部门某天统一登记受理多件案件后,可以每次2件或3件的方式一次性的批量分配案件,方便检察官合理安排时间赴看守所批量处理告知、换押等事宜。

二、轮案条件

(一)刑事案件专业类型

刑事案件专业类型是内设机构改革后的一个重要概念,会用于案件分配、案件查询、动态案卡项等具体场景。以未检“业务”为例,由于1.0架构不支持动态案卡项,迫不得已将未检作为“业务”处理。实际上,内设机构改革后,应当不存在未检“业务”,而是未检刑事案件专业类型(普通、重大、职务、经济、罪犯又犯罪、未检)。系统的案件流程应当通过事项、动态案卡项等具体设计,适应检察机关多种改革叠加对业务敏捷性的需求。系统通过同一个流程,同时适应普通刑事案件、重大刑事案件、职务犯罪案件、经济犯罪案件的需求,同时适应未成年人犯罪案件和罪犯又犯罪案件的需求,满足个性的办案需求和信息采集需求。否则,随着专业化建设的深入,刑事检察业务会面临分崩离析的危险(比如:职务犯罪检察部门完全有理由提出新建“职务犯罪检察业务”)。

言归正传,在轮案规则配置的“属性设置区”中,系统应当支持通过“刑事案件专业类型”来进行分流、分配,至少能够方便部门设置和高检院一致的检察院能够快速设置分流分配规则。

(二)案卡项条件

当前,统一业务应用系统只是提取案件受理向导中的数据信息来组合设置自动分案条件,无法满足实际条件时就用案件特性标签来解决,虽然这一定程度上可以实现随机分案,但也造成了一方面案件特性标签繁多,前台受案人员不好判断,另一方面随机分案智能化程度较低的问题。比如十厅设置了不服检察机关处理决定重大疑难案件轮案组,重大疑难的标识是“人大代表交办的不服检察机关处理决定的案件……”,是否人大代表这个数据项可以在分案前的案卡填录信息中获取到,但是系统只能提取案件受理向导中的数据信息,造成只能依靠受案人员人工判断来添加案件特性标签。

建议将系统分案条件提取数据信息的时间延后至案件分流前,这样既可以提取案件受理向导又可以提取案卡数据信息,分案条件支持按照案件类别进行扩展,各地提交需求后经高检院审核后统一发布,组合成灵活多样、满足实际的分案条件,减少人工干预,达到分案智能化。

三、同一规则

《人民检察院刑事诉讼规则》第八条为同一规则提供了法律依据:

第八条 对同一刑事案件的审查逮捕、审查起诉、出庭支持公诉和立案监督、侦查监督、审判监督等工作,由同一检察官或者检察官办案组负责,但是审查逮捕、审查起诉由不同人民检察院管辖,或者依照法律、有关规定应当另行指派检察官或者检察官办案组办理的除外。

(一)跨院问题

同一规则就是解决某件案件确定由办理过前面某案的同名检察官来承办的问题。当前系统适用同一规则的前提是两类案件存在提案关系。以市级院办理二延为例:市院的提请延长侦查羁押期限案件,是通过提取下级院的提请延长侦查羁押期限案件(而不是提取本院的批准延长侦查羁押期限案件)建立。所以,即便本院新建了批准延长侦查羁押期限案件→提请延长侦查羁押期限案件的同一规则,当前系统是不能生效的——因为没有直接的提案关系。所以,问题的关键在于,同一规则需要突破本院限制,站在全局角度以统一受案号来考虑同一规则。

(二)同一规则优先和专业化优先的问题

同一检察院内,当“捕诉一体”原则和“专业化分工”原则发生冲突时,以什么原则优先?目前高检院尚无明确意见。但目前系统只支持专业化分工优先。如果高检院明确“捕诉一体”原则优先或者将决定权交由地方自行确定,系统将无法适应。举例:犯罪嫌疑人以故意伤害罪报捕,根据专业分工,案件自动分流至普通犯罪检察部门办理,该案移送起诉时,罪名变更为故意杀人罪。如果是“捕诉一体”原则优先,那么该案应当根据同一规则分配至一部原审查逮捕案件承办检察官而不是根据专业化分工进入重大犯罪检察部门随机轮案。类似问题还有“诈骗罪”(普通)-“合同诈骗罪”(经济)等典型情况。

四、优化不在位管理功能

实践中检察官因案件复杂程度、工作量等原因需要少办几件案件,往往也通过不在位登记来变相实现暂停轮案。建议系统将此功能细分为:中止轮案和暂停轮次两种。

(一)中止轮案申请(不在位申请)

中止轮案以起止时间登记。中止轮案申请主要针对检察官本人不在位情形,一旦申请检察官不在位,其参与的所有轮案组均不应当继续分案,故中止轮案申请(不在位申请)界面不用过于复杂,仅需选择其不在位起始日期、结束日期、中止轮案(不在位)原因等。系统应当支持上传不在位依据(请假条、文件等)。

(二)暂停轮次申请

暂停轮次以某轮案组或全部轮案组轮次登记。因工作分配、案件强度不一致等原因,导致检察官在法律时限内完成案件办理有一定难度的,检察官可申请在某些或所有轮案组申请暂停轮案一轮或多轮。

以上仅是实践中的典型问题,需求素材来源于基层。需要进一步加强需求调研、需求统筹工作,方能保持统一业务应用系统长久持续的生命力,成为检察官喜欢的不可或缺的系统。

 

直接来源地址:https://mp.weixin.qq.com/s/iRQgl9j7-dK_ILsuXJti8Q

关于侦查/审判阶段羁押必要性审查案件流程的规范使用和需求建议

统一业务应用系统1.0版执检业务下的“羁押必要性审查案件”,是检察机关对办案机关办理案件的犯罪嫌疑人羁押必要性进行审查的案件流程。内设机构改革后,原执检部门办理的羁押必要性审查工作由刑检部门办理,此次1.5版升级后,在刑检业务下新增了“侦查/审判阶段羁押必要性审查案件”。关于该流程的使用,提出以下理解和建议:

一、【诉讼监督职能】“侦查/审判阶段羁押必要性审查案件”承载的羁押必要性审查工作,是狭义的羁押必要性审查。羁押必要性审查的主体是人民检察院,时间为犯罪嫌疑人、被告人被逮捕后,人民检察院履行职责方式是向办案机关(公安机关、人民法院)提出释放或者变更强制措施的建议。(袁其国,《人民检察院办理羁押必要性审查案件规定(试行)解读》,人民检察,2016年第5期)如果案件刑事诉讼环节仍在检察机关,不应当新建“侦查/审判阶段羁押必要性审查案件”,自己给自己建议没有意义。目前统一业务应用系统1.5版刑检业务下的“侦查/审判阶段羁押必要性审查案件”,只适用于刑事诉讼规则第五百七十五第一款,对“依法对侦查和审判阶段的羁押必要性进行审查”(办案机关非检察机关)。

  第五百七十五条 负责捕诉的部门依法对侦查和审判阶段的羁押必要性进行审查。经审查认为不需要继续羁押的,应当建议公安机关或者人民法院释放犯罪嫌疑人、被告人或者变更强制措施。

审查起诉阶段,负责捕诉的部门经审查认为不需要继续羁押的,应当直接释放犯罪嫌疑人或者变更强制措施。

负责刑事执行检察的部门收到有关材料或者发现不需要继续羁押的,应当及时将有关材料和意见移送负责捕诉的部门。

二、【诉讼职能】案件尚处于审查起诉阶段的(办案机关为检察机关),即便收到了所谓的“羁押必要性”审查申请,也不应当创建“侦查/审判阶段羁押必要性审查案件”,严格来讲,应该通过辩护与代理业务中的申请变更(解除)强制措施方式的一种情形进入系统。由此,衍生出之前提出的需求,辩护与代理案件化或流程化的需求。应当适用新刑事诉讼规则第一百五十一条相关事项时限:

  第一百五十一条 犯罪嫌疑人及其法定代理人、近亲属或者辩护人向人民检察院提出变更强制措施申请的,人民检察院应当在收到申请后三日以内作出决定。

经审查,同意变更强制措施的,应当在作出决定的同时通知公安机关执行;不同意变更强制措施的,应当书面告知申请人,并说明不同意的理由。

犯罪嫌疑人及其法定代理人、近亲属或者辩护人提出变更强制措施申请的,应当说明理由,有证据和其他材料的,应当附上相关材料。

对承办检察官而言,依申请或者依职权对犯罪嫌疑人的强制措施进行审查,正确拟制相关文书(以高检院最新规范为准),并及时、准确填录“案件办理及审结情况”→“决定强制措施情况(强制措施审查情况)”、“羁押必要性审查”两张案卡。

三、目标考核相关问题。由于羁押必要性审查工作办理部门和工作模式发生很大变化,所以各地检察机关制定本项工作目标时(比如“羁押必要性审查建议被采纳予以释放或者变更强制措施人数达到批准逮捕人数的比例”)应当考虑具体工作情况,不能简单沿用之前的考核指标。另外,由于“羁押必要性审查情况基础表”没有配套升级,建议各地检察机关明确考核方式,不简单依赖统计案卡,可以考虑实际发出的《对犯罪嫌疑人、被告人变更强制措施(予以释放)建议书》的数量和质量(应当同步验证送达回证回传情况和办案机关采纳情况)。

以上是对统一业务应用系统1.5版规范使用的理解。

以下是关于广义羁押必要性审查案件的受理问题的需求建议(目前尚未实现在统一业务应用系统中)。

四、需求建议

刑事诉讼规则第五百七十五第三款“负责刑事执行检察的部门收到有关材料或者发现不需要继续羁押的,应当及时将有关材料和意见移送负责捕诉的部门。”由于派驻羁押场所检察院和办案单位或办案单位对应检察院不完全一致,系统应当给检察机关执检部门提供无差别的广义羁押必要性审查案件的受理途径,系统根据该犯罪嫌疑人关联案件的办案单位自动流转:

(一)【诉讼监督职能】如果当前案件办案机关非检察机关,则自动流转至办案机关对应的检察院,根据专业化分工进行自动分流至负责捕诉的部门,部门内勤接收并创建羁押必要性审查案件。

(二)【诉讼职能】如果当前案件办案机关为检察机关,则自动流转至对应的检察院案件管理部门,纳入“辩护与代理”流程。

关于受理,实践中还比较复杂,不考虑办案机关属性问题,除了执检部门会收到相关申请外,控申部门、案管部门均可能收到,是在系统中统一考虑,还是在线下移交,均需要具体业务规范和系统实现。

 

直接来源地址:https://mp.weixin.qq.com/s/oLEXDlZQDdfY21OHza2m-Q

统一业务应用系统基础之关系单位管理

一、问题引出

市级案管部门的同学可能会遇到这样一种现象:在进行流程监控时,发现下级院某案件没有填录“侦(调)查机关”和“侦(调)查机关类别”,打电话通知下级院案管部门,下级院大呼冤枉,他们自己看是正常的,绝对有填录,然后给市院的同学来个“有图有真相”。

二、问题分析

事实上,这是统一业务应用系统设计的一个“痛点”。统一业务应用系统的前身是深圳市院研发的,当时也没想着拓展全国,就把关系单位纳入了“本院代码管理”,这是什么意思呢?这代表着每个检察院都要去收集和配置公安、国安、海关、监委、检察院、法院、监狱甚至部分行政机关的关系单位名称、关系单位代码等。实践中,每个检察院的配置标准不一、代码不一、完整程度不一,上级院用户在查询下级院案件时,此处的关系单位代码“翻译”为关系单位名称时使用的“码表”是上级院用户单位的。当下级院和上级院配置不一致时,下级院的关系单位代码在上级院的“码表”中找不到对应项,就显示为空,甚至,如果上下级院的相同代码配置了不同的单位,就会出现下级院填录的是“某某公安局”,上级院显示“某某监狱”的情况。

这是统一业务应用系统经典的“老问题”。实践中,为了避免这种情况,市级院案管部门会履行统一业务应用系统管理职责,辖区内新增关系单位的管理由市级院案管部门负责,统一调研、统一标准、统一配置。统一管理自然是一种办法,但还是应该从根本上进行解决。

三、问题拓展

(一)侦(调)机关内设、派出机构配置问题

在大数据和人工智能的今天,很多检察院特别是基层检察院,亟须细化关系单位,比如:虽然是成都市公安局东部新区分局移送的案件,希望能够细化到派出所,比如是“养马派出所”的,还是“草池派出所”的,如果完成此类采集,就可以将整个东部新区的发案情况,细化到乡镇一级,进行更加精准的数据分析研判。

但是,统一业务应用系统1.0中,侦(调)查机关案卡项绝对不能擅自添加派出所,因为很多文书是直接调用该案卡项,如果受案时选择派出所,文书内就会出现不适格的单位名称。

(二)受理向导侦(调)机关填录问题

实践中,有些单位创建立案监督案件时,如果立案监督案件类型选择的是“监督行政执法机关移送案件”,会在受理向导中的侦(调)机关中错误的选择对应的行政执法机关!注意:侦(调)机关就是刑事案件的侦查机关(如公安、国安)、调查机关(监察委),普通行政执法机关的调查不属于此处的“调查”。比如立案监督案件(两法衔接),是在两法衔接案卡的行政执法机关类别、行政执法机关名称处填录!

(所以对于受理向导的升级建议,一是受理向导的侦(调)机关读取关系单位配置时,只显示侦查机关、监察机关;二是具体到立案监督案件这种流程向导,一旦选择立案监督类型是“监督行政执法机关移送案件”,在受理向导处即新增行政执法机关类别、行政执法机关名称的采集项。)

四、需求建议

建议统一业务应用系统实现统一的关系单位管理!

统一业务应用系统内的关系单位不再纳入“本院代码管理”,由高检院统一规范、分级管理。系统包括侦查机关、监察机关、审判机关等,以及执检业务相关的监狱、看守所等,辩护与代理业务相关的律师事务所等,都使用统一关系单位进行管理。

系统内关系单位编码使用全国组织机构统一社会信用代码,关系单位名称为正式全称,关系单位类别、类型高检院统一制定。关系单位的内设机构、派出机构,由对应的检察院负责收集、核对、管理,对全国适用。

为提高工作效率,系统内调用关系单位的案卡项时,默认显示本院本级对应的机关,支持逐级扩选、支持快速查询。

系统增加侦(调)机关内设、派出机构的案卡项(不作为必填项),有需求的单位可以在受案时细化,便于后期数据分析研判时使用。

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

关于案卡和系统,来听听案管部门的声音(CU检)

CU检说法

昨天,推送了一篇题为《关于案卡和系统,可以开一场三天三夜的吐槽大会》的文章。

文章推出后,引起了很大的反响。截至目前,后台已经涌入了835条留言。

但由于微信公众号只允许放出100条留言,所以还有很多评论无法放出,也请大家理解。

昨天文章里的很多内容,都来自于微信群内的聊天,有些问题没有经过核实和验证。

今天在跟案管部门的同事们经过深入的交流之后,发现有些是片面的、错误的。

虽然CU检说法是一个自媒体,但也要遵循客观、公正的传播要求,要尽可能地尽到核实求证的义务。

所以,首先要向案卡和系统的设计者,以及案管部门的同志诚挚地道歉。

在看了昨天那篇文章之后,尤其是看了评论区的留言之后,案管的小伙伴们表示很受伤,也很委屈。

他们也希望能有机会就文章中提到的一些槽点,以及对案卡、数据统计、以及统一业务应用系统谈谈自己的看法、意见。

正所谓:“兼听则明、偏信则暗。”因此,今天就将案管同志的意见在这里发表出来,让大家也能听到关于同一件事不同的声音:

 

一、关于昨天文章中提到的问题

A

1.不是所有空案卡都需要填上是否,只有很少一部分作了必填控制的是否项案卡需要填录,否则可以空着,这种情况等同于“否”。

2.从最近几次补填案卡的情况来看,对于已经办结的案子,除非在补填范围内,且必须填录为是的,否则是不需要补填的。

3.手工统计的数据大部分都是系统内未填录过的内容,大统一内填录的内容大部分都能通过不同的查询或者分析模块统计到,当然统计不到可能是因为你不太会使用系统。

4.每个项目的设计都经过高检研发人员多次的讨论,都有相应的填录标准,如果觉得标准不清或者不对的,完全可以层报高检进行修正。

5.对于看不到自己以前办理的案件,那完全是系统后台权限配置没有到位,不是大统一设置内设机构改革故障问题。

6.一案多人有诉有不诉或者撤回的,每个人的文书都是单独拟制审批的,个人案卡也是单独的,办案至今没有听说有没法审批和案卡没法填录的情况。

B

总体而言,信息填录负担重是客观的。文中相对客观的说法有:是否项较多,填录负担重,特别是案件有关情况案件中的专门调查项目。

1.文中认为应当把所有是否项都默认为“否”以减轻负担。但客观地讲,只要系统自动默认成“否”,很怀疑有多少承办人会去自觉、主动修改为“是”,并且这是在实际工作中证明了的。

而之所以设计默认为空,并在某种条件下必填,就是为了解决承办人不愿意填录的问题,以及压实填录责任。

至于文中列举出的“是否人大代表”、“是否政协委员”本身就是默认为“否”的。而且系统中没有文中列举的“是否民营企业家”项目。

2.文中认为一案如有N人,是否项的填录工作量就得是N人乘以57个是否项。

我们估且不论其中不少是否项只设计在案件表单中,一个案件中只填录案件表单即可,不存在都要乘57的夸大问题,并且即使部分是否项设计在嫌疑人案卡中,本也是实现以人为单位进行调查,一案多人每个人的情况不一致,当然需要分别填录。

3.非公经济、扫黑除恶、三大攻坚战、涉民营企业、涉疫情等,多属于检察机关落实国家政策要求的专门调查内容,经济在发展,国内、国际形势在变化,

检察工作重心随时在调整、适应,数据需求、数据调查当然要同步跟进,不仅案件信息、数据的采集要跟进,承办人本身的办案难道不需要适应政策性的要求吗?

4.如果新增的是否项设计为必填,升级后对于已经办结的案件(流程结束甚至已归档),承办人如果只是要查看一下原案件,系统是不会要求承办人补填“否”的!

当然,如果仍为在办案件或者回退流程结束节点并激活案件,则需要补录。这个现象,是系统设计技术因素,系统在技术上是否能实现新增项目不涉及已办结的既往案件,需要专门研究。

同时,每次新增的项目,都是经过部门研究后决定的,而且要对一段时期以来的案件进行调查,项目的改造一定是滞后于相关制度或政策性要求的。

升级项目后,势必需要就一段时期以来的案件进行补充调查,这是决策、管理的客观需要,不是为了和承办人过不去、找麻烦。

5.文中认为“填报了那么多信息,需要统计时还得靠手”。这恰恰说明信息调查、统计数据是滞后于决策、管理需求的,不可能把所有数据需求都事先预设成系统项目信息。

上级院的数据、信息需求是多元的,都是为了服务于管理和决策。承办人一边在叫喊着案卡信息填录负担很重,一边却对不需要填案卡只要求填报表叫苦不停,只能说明不愿填、不想填,认为填录不是办案,认为管理是案管的事,决策是领导的事,与承办人无关。

6.文中提出的单位犯罪年龄为0分案的问题确实存在,属于系统简单改造问题。

7.文中提出的民营经济、非公经济问题定义问题。民营经济至少在目前系统中没有此项目,非公经济属于政策性概念,高检院也下发了填录标准,承办人不去学习文件只吐槽。

8.精神病鉴定开始日期填写后,系统会暂停计算审查起诉期限,填写精神病鉴定结束日期后,系统恢复计算审查起诉期限。根本不存在吐槽所说情况。

9.至于卡顿问题、升级问题,客观存在,只能通过技术升级、加强管理来实现。

10.系统中的项目,确实存在只做加法,减法做的少或没有做的现象,剖分项目存在的逻辑性问题,属于历史项目、新增项目之间的统筹改造问题,需要通盘研究处理。

11.系统项目智能化填录问题,需要技术有突破,也需要实践中去完善,即使在2.0版本中,也不可能解决全部案卡信息的智能化填录问题。

 

二、关于评论区吐槽的问题

CU和评论区一水的吐槽可以归结为三类问题:

一类是对系统运行效率等硬件的吐槽;二类对系统操作设计不够优化的吐槽;三类对系统操作和项目含义的问题。

综合来看,绝大部分吐槽或问题是对系统操作流程不熟悉不了解引发的误解,部分问题实际是最基本最基础的系统操作或业务程序问题。

相信对系统稍有了解的人应该不会有这种误解。不太确定这些问题是哪地的检察官或检察官群所说,但这种吐槽反而占据大部篇幅,所以反面也说明当地对系统的基础培训可能还需要进一步加强而不是减弱。

希望CU可以全面搜集各类这种问题,并分门别类处理:

一是对于操作类和程序类问题统一编发系统常见问题100问或答疑之类的;

二是对于系统设计优化问题进一步上报,以期系统升级改造更加契合基层承办人需求。

最后一句:没有调查就没有发言权。

 

三、关于压力和辛苦的问题

1.承办人只要对自己的案卡负责,数据管理员要对全院的案卡负责,每个月底对照着185个核查点审核案卡是怎样一种体验,CU检要不要来统计群感受一下眼睛看瞎,电话打爆,嘴皮子说破,最后案卡还是错了,被通报,年底扣案管的分数,心碎……

2.每个检察官填的案件信息是一个个“细胞”,总公司汇总的信息是一个个“有机体”,“有机体”是否正常仰仗着“细胞”的健康,当总公司需要数据分析的时候,需要准确的“有机体”数据,这个准确的数据一方面依赖承办人辛苦的填录,另一方面也少不了数据管理员们眼睛都要瞎了一样的核查,大家都不容易,相互理解。

3.作为一名案管人员,承载了太多,不断加厚的眼镜片,案卡内容不断在增多,系统不断在升级,但检察官只用填自己的案件,还有助理帮忙,可案管人员要一个一个,一项一项看完所有案件案卡,同时还要承受大家的吐槽和不理解……

承办人看到的只是一个一个的必填项,但在这背后是庞大的数据库,是一个个让人又爱又恨的天使与恶魔化身。承办人不易,案管人员更不易,且行且珍惜。

好了,以上就是来自案管部门的同志的声音,受到版面的限制,就暂且放出这么多吧。

其实,案管部门也是案卡和统一业务应用系统的使用者,他们和一线的承办检察官一样,也承担着巨大的工作压力,也希望软件更好用、统计更便捷。

正如一些案管的同事所说:

不管是案管还是业务部门,最终的目标都是规范案卡填录和检察数据,只有齐心协力,才能进一步提高办案质效,也希望在2.0系统中能看到更智能更完善的案卡填录和数据使用模式。

历史的车轮滚滚而来势不可挡,信息化的发展带来的阵痛必须承受,我们要有足够思想准备,对社会进程中已经出现和可能出现的问题,困难要一个个克服,问题要一个个解决。

我们应以积极的心态来应对系统升级更新,要坚信道路是曲折的,前途是光明的,而不是一味抱怨、退缩,唯有联合起来团结一心,才能更快的克服当下的困难。

当然,对于业务部门检察官的吐槽和怨气,也希望案管的同志们能多一些理解。

一线承办检察官填报案卡的压力很大。关于这一点,是业务部门和案管部门同志的共识。

业务部门的同志之所以会意见那么大。是因为在案件法定办案期限没有增加,人员没有增加的情况下,他们要承担的工作量比以前增加了太多。

而当现有的软件无法在节约时间、提高效率上提供帮助,甚至会增加他们的工作量时,他们自然会有抵触的心理。

但正所谓:责之深,望之切。他们不是不愿意填报案卡,在做好案件的同时做好数据的填报工作。

他们只是希望能有更加智能、更加便捷、更加好用的工具。

业务部门的同志也要和案管部门的同志多交流,多反馈。其实他们很多时候也默默地为你们做了很多。

今天,读到了一篇题为《共建巴别塔,而不是被变乱了口音》的文章,更加深入地了解了统一案件业务应用系统研发背后的故事。

最后一句:吐槽不是目的,发现问题并促使问题得到解决才是意义和价值所在。

 

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

共建巴别塔,而不是被变乱了口音

>他们决定在这里建一座城,造一座通天的高塔……上帝看了之后,说:“他们是同一民族,使用同一语言,今天能建成这城和通天塔,那么今后就没有他们做不成的事了。”于是上帝变乱了人们的口音,使他们的语言彼此不通,无法继续建造新的城市,并且还使他们从此分散到世界各地。

一个有生命的系统,要有一群有情怀的人参与建设。
大约是2009年,深圳案管一位孕妇挺着大肚子穿着防辐射服,在机房嗡鸣中、在电脑线丛中腾挪,参与研发深圳院的案管系统——她的女儿,叫“管管”。2012年,最高检决定以深圳案管系统为基础,吸收各地检察业务软件的优势开发全国检察机关统一业务应用系统。由此,在深圳观澜拉开系统需求的大幕,来自全国各地100多名各个条线的业务专家和骨干云集,这时候,无数有情怀的人抛家舍业,无论是侦监、公诉,还是案管、技术,说的都是一样的语言,为的都是一样的目标——打造检察机关的巴别塔1.0。(此时的管管,已经会豪迈地说“妈妈的工作要紧,管管会管好自己的!”)最终,在各路大神的努力下,建成了统一业务应用系统1.0!(背景知识:公检法中只有检察机关的生产系统做到了四级统一)
一直以来,一直有一群被统一业务应用系统“绑架”的年轻或不年轻的听雨者(TYYWer),虽居江湖之远,却饱含着对检察事业的热爱,不惧上帝发笑,深度思考着统一业务应用系统业务需求……
但是,昨天,智慧如CU检,通过“检察官工作能力的扭曲,责任心的沦丧”的反语和“罄竹难书、令人发指”的指控来“吐槽”统一业务应用系统。言之草率,一时间,案卡填录、统一业务应用系统,恍惚成为“公敌”,这让这一群有情怀的人,难免神伤。笔者还是想结合几年前“吐槽”的旧文和现在了解的情况,记录一些文字,希望将来终不至于,因为某些事情,“一别两宽,各生欢喜”……

# 一、检察机关核心业务系统“简史”
检察机关核心业务系统的信息化,始于最高检需要了解全国的案件情况。自检察机关成立之初,就一直在进行数据的统计汇总。1978年检察机关恢复重建以来,分为填录纸质报表、填录计算机报表、填录统计案卡生成报表、信息导入生成报表、系统自动生成报表等五个阶段(王拥政,《检察业务统计实务》,中国检察出版社,2019年),每个阶段都代表着业务信息化程度的一次跃升,最显著的特点是成立案件管理部门以来,依托统一业务应用系统的全国部署,打通了生产数据和统计数据通道,实现了手工到集中、自动、高频、多元的数据采集和统计。相信资深一点的检察人员,对统计AJ2003以及之后适应统一业务应用系统改造的统计AJ2013是耳熟能详。由于统计系统用户广、影响大,也影响了检察机关若干后续系统的思路。最核心的影响莫过于,统计系统的业务需求第一位的是:上级机关需要了解数据,下级机关需要填录数据。换言之,统计系统设计的出发点本就是管理者思维而不是用户思维。
统一业务应用系统的前身是深圳院与ZC57合作开发的系统,其架构成型于2006~2009期间,多多少少受到了统计系统的影响,最高检决定研发统一业务应用系统时,由于时间紧任务重的原因,也没有机会对系统架构进行重新的设计。2006年,微软发布了Windows Vista系统,历经Windows 7(2009)、Windows8(2012)、Windows10(2015)等版本后,2018年,Windows已经不再作为微软独立的事业部存在(取而代之的是人工智能和云),一个伟大的时代结束了——而统一业务应用系统的核心架构,从2006年一直沿用到14年后,2020年,言必称人工智能、大数据的今天。

# 二、统一业务应用系统1.0的几个问题
统一业务应用系统基础架构能够从2006年坚持到今天,期间还经历适应司法责任制改革升级、适应内设机构改革等大版本升级,不得不承认其可配置性相当优秀。但由于当初基础架构设计时并没有考虑全国部署的计划,系统缺乏统一的“基因”。要论吐槽,值得吐槽的事情还非常多,各岗位“人工的智能”工作也还很多。案卡填录,估计还排不到前面。同是统一沦落人,执手相看泪眼,竟无语凝噎……

## (一)权限管理模型不适应省级集中统一部署
统一业务应用系统采用了RBAC(基于角色的访问控制)模型和ACL(访问控制列表)模型实现权限管理。权限编辑器是技术信息人员非常熟悉的:很多功能点都有权限编辑器,却需要逐一配置。举一个实际的例子:1.S省J县级市改由C市代管,在统一业务应用系统中需要新增J院,随之而来的权限配置工作就是同步调整所有有对下级单位访问权限的角色。其工作量是:C市市院的检察长、副检察长、所有业务部门的处长、案管办相关人员等角色,需要对所有具有权限编辑器的功能点进行补充授权!2.适应内设机构改革版上线后,新增了刑检业务,那么,所有对刑检业务具有查询权限的用户的相关功能点,都需要在权限编辑器配置一遍。
人工智能不够,人工来凑,技术信息部门的同学看到这里估计只能苦笑了。

## (二)检察官权力清单模型不适应省级集中统一部署
根据最高检规定,检察官权力清单的制定主体是省级人民检察院,文书审批权限是检察官权力体现的最主要的载体。理论上,文书最低审批权限应当由各省级院(部署点)统一配置,下发至所有下辖检察院,以利于检察权的统一行使。文书最低审批权限只能通过对每个“检察院”手工调整、单独配置且无法统一监控。全国几千家检察院、系统千余份文书,全靠人力堆啊~笔者基层院技术科的小妹,本在休假,在没有领导安排的情况下,拖着高烧的身体,就开始对照着清单开始配置……有同学可能会说,高检院或者省院应当统一设置嘛——审批角色代码在系统上线之初就是各院自行配置的,统一配置,谈何容易……

## (三)检察事项管理模型缺失
统一业务应用系统比较优秀的是将纷杂的检察业务提炼出四个基本要素:流程、案卡、文书、卷宗。就目前应用情况看来,共性提炼的很好,但个性功能欠缺。以案卡为例,统一业务应用系统以传统的案卡、案卡项等扁平的方式来组织结构化数据的采集,对具体承办人而言,日常工作并非如此,使用统一业务应用系统时就会认为,“系统增加了我填录的工作量”。
那么,是否是在案件和案卡之间,缺少了一个模型?笔者认为,是检察事项模型。承办人总体是在办案、具体是在办事,这个办事,对于具体的案件而言,可能是要告知、可能是要换押、可能是要讯问……在这个层级之下才是采集相关的结构化数据(对应的案卡项)和生成相应的非结构化数据(对应的文书),通过这种模型,解决案卡平铺在承办人面前、数据采集项目过多过频繁,增加工作量的不良体验。举一个简单例子:我们拟制《起诉书》,其文号是由系统生成的,为何还需要承办人去填写起诉书文号这样的案卡项?

## (四)统计查询功能不适应管理需求
统一业务应用系统因“管理”而生,却随着时代的发展越来越不适应“管理”需求。这听起来挺像悖论,其实不是,而是管理需求发生了翻天覆地的变化。类似张军检察长提到4分之于满分5分、8分之于满分15分的关系,系统的确在进步,但需求增长更为迅速。仍然从统计系统说起,20年前的管理需求,相对简单和静态,就是要数据报表。目前,统计功能虽然全面融合进统一业务应用系统,但其设计理念仍然是检察机关多年来的传统习惯。传统的数据管理分析方法已经不能适应大数据快速增长的趋势。在大数据浪潮的今天,软件研发要敏捷,检察业务分析研判也要“敏捷”。这些静态的数据报表,如何适应飞速发展的社会、如何满足多样的数据及调研需求?
(以上内容主要来自之前的吐槽旧文,这类问题还挺多,包括执检业务、未检业务等,有兴趣的同学可以索取完整版)

笔者是想表达:吐槽容易、提需求容易,但系统架构是2006年的,很多需求不是不做,而是不能。实践中很多需求和实现,看起来很弱,其实是“需求妥协”的产物啊!从统一业务应用系统全国上线起算也是7年过去了,为了让这条大船继续航行,期间多少检察同仁充当“人肉燃料”,有多少同仁深夜围坐在汤逊湖宾馆简陋的茶几前讨论,有多少同仁凌晨两点还在回家的路上,有多少同仁看着视频里发烧的儿女流泪,有多少同仁的孩子对父母的离别处之泰然……这些,却被轻率的一句“智商”概括了?CU检说“设计系统的人不办案,使用系统进行监督的人不办案”,参加统一业务应用系统1.0建设的不乏全国十佳公诉人、全国检察业务专家、全国五一劳动奖章获得者,这些前辈要不要办案笔者不太清楚,至少笔者知道很多基层院案管主任,是要办案的,CU检可能要多加调研再行评述为好——至少,不要用人工智能来要求统一业务应用系统1.0,它从2006年开始就没有所谓人工智能的基因。

# 三、CU检提及的一些问题
针对CU检以及评论区提及的一些问题,笔者尝试表达一下自己的理解:
## (一)专业背锅侠——“总成”的烦恼
谁面向用户、谁接受吐槽,这就是“总成”的烦恼。实践中存在“使用统一业务应用系统,则问题均是统一业务应用系统的”的错误认识。比如:评论中提及的“系统内做好的报告突然闪退”,在全国只统一系统不统一字处理软件,甚至各地字处理软件是难以言状的版本背景下,这锅让统一业务应用系统背,有点过了。

## (二)臣妾做不到——架构的老旧
“假如你办理的是单位犯罪,系统默认的犯罪嫌疑人年龄是0。你要是不手动给他改成18岁,系统会默认这是一个未成年人案件”。正常思维,自然人当然是填自然人信息(身份证号码等),单位犯罪当然是填单位信息(社会信用代码等),放在2020年的今天,统一业务应用系统1.0没有动态案卡项的确匪夷所思,但如果参考上文阐述的背景,2006年的C/S架构的软件,似乎又是可以理解的。

## (三)本领的恐慌——培训不到位
“假如你需要对嫌疑人进行精神病鉴定,必须把案子退回给公安,否则系统就开始要闪烁红灯,提示你案件超期了!”这是典型的错误认识导致的错误办案行为。小伙伴总结的很到位:综合来看,绝大部分吐槽或问题是对系统操作流程不熟悉不了解引发的误解,部分问题实际是最基本最基础的系统操作或业务程序问题,相信对系统稍有了解的人应该不会有这种误解。不太确定这些问题是“哪地”的检察官或检察官群所说,但这种吐槽反而占据大部篇幅,所以反面也说明当地对系统的基础培训可能还需要进一步加强而不是减弱。

## (四)惊奇的发现——减少主观对立
“在内设机构改革以后,原来的侦查监督和公诉变成了捕诉一体,你会惊奇的发现你看不到自己以前办的案子了,只有案管的人能看到”。这种叙事风格,明显存在对立情绪。但是,内设机构改革版本身就有一个“案件导航”功能,通过建立“案—件”的关联关系,便于检察长和检察官快速全面了解刑事案件全业务流程(包含跨院)的基本情况,辅助承办检察官查询和办理案件。检察官已经可以了解到上级院的承办检察官是谁,谈何看不到自己以前办的案子?

## (五)生产与统计——办案和管理本就有区别
笔者不是没有参加过各种档次各种规模的吐槽会,除了少数问题能涉及核心外,大部分笔者能给予的反馈就是:摇头。当然,CU检文章的N个“是否项”,恰恰就是少数能涉及核心的问题:关于生产和统计的关系。“案件其他有关情况”的处理方式,笔者是不赞成的。为了完成1%案件的统计调查任务让100%的案件去填录统计调查项,有点过了。
当今的数据处理大致可以分成两大类:联机事务处理OLTP(on-line transaction processing)、联机分析处理OLAP(On-Line Analytical Processing)。在大数据浪潮下,在管理需求日益复杂和专业化分工的背景下,统一业务应用系统1.0无法实现复杂的统计分析操作,究其原因,是对OLAP应用开发重视不够,没有重量级的应用。

# 四、关于案卡的建议
速度和案卡,是统一业务应用系统1.0最大的两个槽点(插播一句,笔者单位千兆到桌面,从来没有因为速度吐槽)。关于案卡,笔者一两年前也曾建议从六个方面予以考虑:自动记录、智能回填、政法协同、专项活动、自动校验、批量采集等,拣几个重点的说说。

## (一)案卡项
1.0系统文书和案卡项之间缺乏关联(比如:即便文书文号是系统生成的,但仍需要检察人员手工填录文书文号案卡项),案卡项采集缺乏技术手段,造成检察人员需要填录大量案卡项。统一业务应用系统应对现有案卡项进行全面梳理,目标是检察官尽量少的填录案卡项。检察官应当侧重审查具体办案过程中产生的数据,不应当履行类似大数据产业的“数据标注员”的职责对案件的特征信息进行填录(比如:是否项)。案件的“标注”工作,应当通过技术手段或书记员集中采集、填录方式进行。
案卡项分为基础案卡项、动态案卡项和自定义案卡项。
### 1.基础案卡项
对各类案件都适用的案卡项是基础案卡项,如部门受案号、受案日期等。
对案件特征采集的基础案卡项(比如:是否影响非公有制经济发展案件、是否涉外犯罪案件、是否涉台犯罪案件、是否涉港澳犯罪案件、是否涉侨犯罪案件、是否涉医犯罪案件、是否利用电信实施犯罪、是否利用网络实施犯罪、是否涉及校园暴力、是否涉及家庭暴力),系统需要依托新技术对案件的数据项、文书、电子卷宗等内容进行分析,预先填录,提醒检察人员审查确认,切实减轻一线办案人员填录压力。
### 2.动态案卡项
将案件类型、诉讼程序、办案事项需要的案卡项作为动态案卡项,其他案件不要求填录也不显示。比如:案件被识别为毒品相关罪名,才出现毒品类别、毒品数量等案卡项,其他案件不会出现这两个案卡项。
需要注意的是:案卡项是有生命周期的,应当建立生命周期管理制度;案卡项是有管理目的的,其内容应当支持Alt属性显示供检察人员查阅。

## (二)专项活动
办案过程中的信息和对案件特性描述的信息应当适度区分,做到检察人员遵循办案规律进行案件办理,不因为办案以外的因素回退流程节点。但是,为满足数据分析、检察决策需要,对案件特性描述的信息进行及时准确采集并由检察人员进行审核确认又是必须的,系统应设置专项活动案卡项。
专项活动案卡项是指高检院根据不同时期司法政策要求、长期或当前关注重点,发布的对专项活动(比如:扫黑除恶专项斗争、三大攻坚战、扫黄打非类相关案件等)相关案件进行信息采集的案卡项。
系统建立一套全新的信息采集系统:专项活动管理子系统。专项活动管理子系统参考并吸收现有的统计报表功能部分功能,应当满足个性化、多元化、不断变化的数据统计报表需求和业务分析研判需求,满足为发布单位提供专项数据需求模板发布、专项数据汇总分析工具;为填报单位提供专项数据智能填录、批量填录、审核上报等功能。
高检院新增专项活动时,应当明确牵头部门、附加的数据项及填录规则,设置自动识别和错填检查规则,定期更新,通过系统采集、上报相关数据,减少甚至杜绝实践中线下手工上报类案数据的现象。专项活动可以对全国发布,也可以对部分省份发布。专项活动侧重于某一特定时期,在专项活动结束后或者转化为基础案卡项,或者不再填录。
各级检察院可指定专项活动的牵头部门、具体负责的检察人员,比如:高检院第一检察厅高级检察官被设置为专项活动负责人时,可实时查阅全国范围内该专项活动案件统计表,并支持下钻查询,便于进行业务指导。

## (三)标签(Tag)
系统应当支持检察人员根据案件特点、案件要素添加自定义标签,系统可根据自定义标签主动推送类案、文书等内容,可以根据自定义标签进行案件检索、统计。通过自定义标签,检察人员可以自己给案件画像,而系统可以根据干警的对自己个案的画像去进行类案推送,干警对自己的案件描绘的越准确,类案推送也就越准确。自定义标签功能应当支持热点标签显示,检察人员添加自定义标签时可以参考。标签标注功能,可在个案办理界面标注,也可进行批量标注。应当支持个案流程结束后仍可进行标注。应用场景举例:检察人员正在办理盗窃案件,添加自定义标签“入室”,系统就推送入室盗窃相关类案,或者检察人员点击“入室”标签,调用数据应用平台检索具有相同标签、相同罪名的案件。

# 五、结语
作为全国检察机关核心业务系统的统一业务应用系统,其生命周期是非常长的,不是一蹴而就的,像所有的信息管理系统一样,需进行长期演进。系统的长期演进就离不开长期的需求统筹管理、长期的研发力量支持、长期的研发经费投入。
目前,在系统完善和需求演进方面,需求反馈链条过长,一线办案人员的需求无法及时汇聚、分析整理、反馈(干警使用问题)、修正(系统缺陷问题)或研发(新增需求问题)。如果我们不正面应对,不沉下心来分析问题、解决问题,统一业务应用系统划时代意义就会被淹没在反复的吐槽中,系统也会在新时代浪潮下无奈老去。
也许CU检只看见了案卡的问题,笔者却看见了被变乱“口音”的问题。唯愿研发、信息、案管、业务不要“被”变乱了口音,彼此语言始终相通,共建巴别塔,让统一业务应用系统成为“它本来该有的样子”!

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

关于案卡和系统,可以开一场三天三夜的吐槽大会(CU检)

CU检说法

最近在好几次会议上,都听到某地的某检察官因为案卡填报出现问题被通报的消息。

一张小小的案卡,为什么会让多地的检察官栽了跟头,这到底是检察官工作能力的扭曲,还是他们责任心的沦丧,抑或是有什么其他不为人知的原因呢?

带着这些疑问,我走进了一些检察民工的微信群,就“办案系统里的案卡到底怎么了?”的话题,与小伙伴们展开了讨论。

话题一开,只见群聊天界面里的信息瞬间更新了上百条,每个人似乎都对它充满了愤怒。

案卡的槽点之多,罄竹难书;承办人所受到的折磨,令人发指。

我把群聊里收集到的一些内容,简单展示在这里,让大家感受一下,也欢迎大家在评论区里进行补充。

1.点到让你怀疑人生的“否”

嫌疑人是否是未成年人,是否是人大代表、政协委员、是否是民营企业家……

据一位不愿意透露姓名的检察官统计,假如一个案件只有一名犯罪嫌疑人的话,你需要点击57个“否”。

如果这个案件有两名甚至更多的嫌疑人,那么恭喜你,你需要点击的“否”则要按照人数乘以57,缺少一次你都进不了下一步。

而且这个“否”还时不时的会增加。

比如疫情来了,你需要在再点一下这个案子是否属于涉疫案件。

比如要六稳六保了,你需要再点一下这个案子是否涉及民营企业家。

比如最近医闹案件多了,你需要再点一下这个案子是否属于涉医案件。

所以,如果你想要知道最近有什么属于社会热点,来我们的办案系统看一下又新增了什么需要点击“否”的项目就可以了。

更神奇的是,不但新发生的案子需要点击“否”。而且那些已经办结的案件,你还需要补点“否”。如果你不补,你就看不了之前的案件了。

真的不能理解案件管理系统的设计者,你为啥不能把所有的项目默认为“否”,而让检察官有选择点击“是”呢?

非要检察官们瞪大眼睛去点击几百个“否”,然后万一要是点错了,再去通报批评他们。真想问一句:你们,是故意的吗?

2.填报了那么多信息,需要统计数据的时候还是靠手。

每一个案件,每一个犯罪嫌疑人,每一个被害人,从受案时间到办理结果。办案系统设计之繁密,让人叹为观止。据说一个案子全流程下来,监督的点有几百个。

但就是这么牛逼的系统,填报了那么多数据之后,你会悲伤的发现,上级院依然需要下级院上报各种数据。

这些数据怎么来呢?需要承办人或者内勤再一手拿着笔,一手拿着纸,再进行人工的统计。

一位被数据统计折磨的在焦虑和抑郁间徘徊许久的检察官发出了这样的灵魂之问:

如果填报的信息从来都生成不了有用的数据,我们一次次填报的意义到底又在哪里?

3.有些项目的设计让你填报时不仅怀疑人生,甚至质疑设计者的智商

假如嫌疑人是一名农村进城务工的理发师,请问他到底算不算农民工?

按我的理解,应该算。但对不起,系统不认为他是。

到底什么样才算是民营经济,非公经济,没有人告诉过你明确的定义。

你去问案管,案管告诉你他们也不知道,需要自己去理解。但是如果系统填错了,你要承担责任。

假如你办理的是单位犯罪,系统默认的犯罪嫌疑人年龄是0。你要是不手动给他改成18岁,系统会默认这是一个未成年人案件。

在内设机构改革以后,原来的侦查监督和公诉变成了捕诉一体,你会惊奇的发现你看不到自己以前办的案子了,只有案管的人能看到。

能想出几百个监督项目的系统,在设计的时候竟然没意识到还会发生案件在审查起诉中可能发生中止的情形。

假如你需要对嫌疑人进行精神病鉴定,必须把案子退回给公安,否则系统就开始要闪烁红灯,提示你案件超期了!

涉及多人的案件,有起诉的,有不起诉的,还有撤回的,但是系统默认所有人都进入起诉环节。在这种情况下,该怎么发起文书审批?没有文号又怎么去填案卡?

上述的这些问题,只是检察官们海量吐槽中的冰山一角,至于升级就卡顿、卡死就重来等等司空见惯的问题,大家似乎都已经习惯了。

据一位头发已经快掉光的助理说:看卷半小时,填报案卡和系统要弄一整天。如果一不小心搞错一步,对不起,换个姿势,再来一次。

真真的是:

原本以为走进了人工智能,万万没想到碰到的是人工智障。

面对填报案卡出现的错误,有的可能确实是不认真不仔细,但案卡和系统本身到底好不好用,是否存在着增加承办人负担等问题,也值得引起关注。

没有人不想成为一名合格的工匠,大多数人也都愿意去求极致,成为大师。

但再好的技艺,再多的耐心,在点击了无数个“否”和经历了无数个始终伴随左右的BUG之后,也会感到烦躁和崩溃吧。

设计系统的人不办案,使用系统进行监督的人不办案。对他们来说,能通过系统、案卡发现问题,发出通报,也许才是成绩。

而那些真正在一线办案的人,这些每天使用系统、填报案卡的人呢,没有享受到所谓的智能系统带来的便利,只感受到越来越多的繁琐,和越来越大的害怕出错的压力。

总说要不忘初心。那我们是不是也要想一想,投入了巨资研发的办案系统,初心到底是什么?

希望设计者和监督者,到一线实际办几个案子,去体验一下办案检察官的生活和工作。

检察官们的工作是让人民群众在每一个案件中感受到公平正义,请先让他们在办案系统和案卡中感受到便捷和善意。

最后一句:实践是检验真理的唯一标准。


①CU检《关于案卡和系统,可以开一场三天三夜的吐槽大会》原文链接已失效。

②Robin《共建巴别塔,而不是被变乱了口音》

③CU检《关于案卡和系统,来听听案管部门的声音》原文链接,已失效。