他们决定在这里建一座城，造一座通天的高塔……上帝看了之后，说:“他们是同一民族，使用同一语言，今天能建成这城和通天塔，那么今后就没有他们做不成的事了。”于是上帝变乱了人们的口音，使他们的语言彼此不通，无法继续建造新的城市，并且还使他们从此分散到世界各地。
一个有生命的系统，要有一群有情怀的人参与建设。
大约是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检只看见了案卡的问题，笔者却看见了被变乱“口音”的问题。唯愿研发、信息、案管、业务不要“被”变乱了口音，彼此语言始终相通，共建巴别塔，让统一业务应用系统成为“它本来该有的样子”！
