中化集团统一化公文管理场景分享

　　中化集团是一家集团化央企，业务遍布全世界业态众多，由于之前使用的慧点综合办公系统和门户系统比较老旧，无法适应当前业务发展，所以更换为泛微OA产品，以保证全集团公文系统统一化，综合办公管理系统部署一体化。

技术层面：经过十几年的沉淀，慧点项目人员的变更和项目执行的深度，导致部分问题慧点无法及时解决，导致系统体验很差并且技术风险不可控。

发展层面：中化集团早已计划成立信息公司，慧点无法把公文功能落地形成固定的实施手册，以便中化信息公司可以自行实施公文固化的功能，并且仅把新功能、开发和运维交付给慧点落地。

运维层面：之前是一家公司一套系统，建设出了基于NOTES很多子节点使用不同的数据库，导致后续运维困难，每家公司都可能找第三方进行搭建自己公司系统，导致集团无法统一运维，也无法预知系统到底上线了哪些模块，无法做到集中管控。

2.1 公文管理之领导手写签批模板应用场景

在央企上了年纪的集团领导基本不会使用电脑或手机对公文进行审批，他们习惯使用纸笔进行线下实物审批，但是为了保证线上审批的完整性和档案传输的完整性，需要在特定的节点领导的专职秘书把流程表单、正文、附件一并打印给公司领导，由公司领导进行线下审批，审批完成后由专职秘书录入到系统中。

客户之前的系统是使用铜版纸作为底板，然后在系统中数据打印出来，类似打印发票的模式。

公文管理之秘书替领导审批应用场景

由于央企的集团领导可能需要线下批单，那么他的专职秘书就得根据线下的审批意见录入到系统中，并且落款不能保留秘书的名字。专职秘书提交等同于领导提交。

2.2 公文管理之两级审批场景

在央企中阶级划分很敏感，集团总部的人员他只考虑总部职能部室的行文和直属公司的行文，不能够跨级行文，也不能跨级上报公文。

2.3 公文管理之总经理责任制使用场景

央企有严格权责手册，但是每一个部门针对人员或岗位的变动可能导致线下执行和权责手册不一致，在大部分时候制度的更新没有人员、岗位更新快，那么在央企中一件事落到某个部门后首先由这个部门的总经理或者公司的总经理选择其他人员处理。

2.4 公文管理之收文库场景

中化原有的公文系统操作是：

1. 在公文系统中行文，审批完成后到办公厅文书归档。

2. 办公厅文书岗在门户系统上传发文，然后选择不同的群组共享这个文档。

2.5 公文管理之公文上报场景

根据权责手册中的职权划分，职能部门、下属公司针对有些请示无法在当前级别进行判断，他们需要请示上级乃至上级的上级确认当前事项是否可以执行，下属单位通过逐级公文上报，等到上级的领导确认后再执行。

2.6 公文管理之加签场景

部门或公司总经理收到流程待办后，他们往往无法直接操作，他们可能需要让助理提供素材、职能部门提供佐证材料、风控部门论证事项的风险性，一个流程会签给几个领导的时候会衍生出N个人来参加这个流程审批。

2.7 公文管理之公文大类搭建场景

中化集团公司发文大类就有17种，老系统分别做了17个流程，例如公司发文、公司发文（特殊）、股份发文、股份发文（特殊）、党组发文、党组发文（特殊）、党委发文、党委发文（特殊）、直纪发文、直纪发文（特殊）等，针对这样一个大类我们应该如何构架我们的表单和流程？

2.8 公文管理之多文号搭建场景

在中化集团公司发文中存在两个编号，一个是公文编号，一个是办公厅序号。

公文编号是某个文种的编号，每一类公文或子类都有自己独立的编号相互独立，支持部门、公司独立流水混合编号。例如：公司发文：中化集办[2018]16号 下一个 股份发文：中化股办[2018]16号。

办公厅序号是针对于某一大类文种进行大流水编号。例如：公司发文： 16下一个股份发文： 17。

实现细节见《最佳应用场景：中化集团统一化公文管理场景分享【OA系统选型网】》