离校系统应当常态化。一个学生一旦成功进入学校，就应当将其数据自动同步到离校系统中。

　　过去，每一个学生离开学校前，需要领一张转单，学生拿着转单到每一个部门盖章，之后，便可以领毕业证办理离校手续。这个步骤的目的是为了确保学生在领证离开学校前，学校和学生两不相欠。

　　随着信息技术的发展，学校希望借助信息系统完成离校工作，因而“数字离校系统”应运而生。但是理想的离校系统真的并不多。如北京理工大学之前所用的系统，除了界面不美观外，各种业务的设计也很不合理。

　　之后，我们开始重新思考离校系统应该怎么做，并自主研发了新的数字离校系统。系统运行几年来，顺利地支撑了学校的工作。那么，离校系统的核心是什么？离校系统涉及到哪些问题？这是我们能否设计一个好用的离校系统的理念支撑。

　　01  离校系统要解决的首要问题是什么？

　　这个问题的答案是简化流程。在过去，学生之所以要拿着转单去很多部门，是因为当时的信息系统还不普及，学校还仅仅把学生当成管理的对象而缺乏服务的意识。当信息系统普及后，我们再回头看，首先应该想到的是，转单上很多部门实际上根本没有必要存在于高校的离校环节中。这些环节可以分为两种：思路转变后可以取消的环节以及可以后台批量办理的环节。

　　思路转变后可以取消的环节，指的是这个环节在信息化时代已经失去了过去管理上的意义，比如，收回学校医疗本，医疗信息化快速发展，学生完全可以用一卡通看病，根本没有必要收回医疗本。

　　可以后台批量办理的环节，是过去需要面向个人办理的业务，现在完全可以通过系统数据统一办理，比较典型的有：

　　1.网络账号注销：让用户逐一注销是件很麻烦的事，把该退回的费用统一退回到银行，然后以一个命令瞬间注销。

　　2.一卡通注销：同样的道理，将资金退回即可。

　　同时，保留下来的环节也不要设置复杂的先后顺序，除了发毕业证学位证的环节必须是最后的环节以外，其他环节完全可以并行办理。

　　离校环节的简化，并非系统之功，而是一批极具服务意识兼备管理智慧的管理人员长期努力的结果。而数字离校系统的建设，恰恰为他们实践自己的管理理念提供了一个契机。

　　02  离校系统还能解决哪些问题？

　　学生是否获得了毕业资格，是否应该由离校系统判断呢？学生是否欠费，是否应该由离校系统判断呢？表面上看，这些业务都跟离校工作有一定的关系，但仔细分析，我们就会发现，这些业务跟离校系统几乎是没有一点关系，因为这些结果原本应该由教务、财务系统得出。

　　跟很多信息系统一样，离校系统本质上解决的是信息及时共享问题。通过将学生办理情况的数据在业务部门、学院和学生之间共享，使得学生可以少跑路，业务部门可以少接待，而学院可以及时了解学生的手续进展情况。

　　03  离校应该做成常态化的吗？

　　传统上将离校当成一项在特定时间内的特定工作，这是因为在操作中学校在毕业季才开始把离校当成一项重要的业务对待。但实际上，随着高校人才培养工作的不断发展，并非所有的学生都在七月毕业。譬如，有不少硕士研究生是在当年的三月份毕业，而博士研究生的毕业是随着论文和答辩的进行，每年可能有好几批学生毕业。

　　在这样的情况下，把离校系统做成一种可以支持常态化工作的系统是很有必要的。要让系统的工作常态化，最重要的就是避免人工干预和配置。

　　也就是说，一个学生一旦成功进入学校，就应当将其数据自动同步到离校系统中。

　　04  离校必须得有名单吗？

　　很多离校系统公司提供的离校系统在使用时必须配置离校名单，而且离校名单不能随便修改，一个学生不能多次进入离校名单，这些都是对学校的实际工作不了解导致的。

　　过去，在使用这样的系统时，我们向研究生管理部门要准确的离校名单，会听到类似的答复：“我怎么知道这些博士能不能毕业？他们能不能毕业要根据答辩结果确定。”

　　系统需要离校名单，往往是希望通过此标识出学生是不是可以离校，名单内的必须离校，名单外的不能离校。但从高校实际管理的现状来看，在管理没有达到一定的水平前，希望通过系统来判断学生能不能离校并不现实。真正最了解学生相关情况的，恰恰是办理离校业务的学院辅导员、副书记，与其在系统里要一份并不准确的名单，不如把决定权留给最熟悉此项工作的人。

　　但离校名单就没有用吗？当然不是，提供一份离校名单可以对工作人员起到提醒的作用，批量办理也需要通过名单完成，同时也可以作为生成统计报表的依据，只要不将其作为可否办理的依据和系统运转的必要条件即可。

　　那么，离校名单应当如何表示？一种最为简单的表示方法是在每条学生数据上增加离校起始和终止时间两个属性。

　　05  办理状态如何表示？

　　如果离校是一个常态化的系统，那么在离校系统中的一个部门的状态项就不仅仅是是否办理完成状态，而是有可能在多种状态之间多次转换。可能的状态包括：待核准：当学生进入学校时，系统自动为其初始化的状态。需办理：表示学生真的需要办理这项手续。

　　无需办理：表示学生不需要办理这项手续。

　　已办理：表示学生已经将手续办理完毕。

　　可办理：表示学生可办理也可不办理，由本人决定。

　　如果一个项目处于待核准和需办理状态，学生是需要去办理相关手续的，显示为红色；而如果处于无需办理、已办理、可办理状态，则显示为绿色。

　　离校系统中的其他要点

　　系统的整合

　　在系统没有整合前，为了实现学生少跑路，业务部门少接待的任务，就必须要进行需办理状态预置和批量办理，这背后是工作人员对名单的手工处理。不仅耗时费力，而且容易出错。

　　一旦做好系统整合，每一个状态的变化随着业务系统中的数据变化而自动变化，十到十五分钟左右的延迟也都是可以接受的，只要数据的到达比学生稍微快一点就可以。

　　在我们的实际工作中，已经完成了三个环节中两个环节的整合：

　　图书馆：图书馆工作人员完成必要的工作后，将读者信息注销，此时离校系统自动将用户置为已办理状态。

　　财务处：通过财务系统的学生欠费信息视图，将欠费学生标记为需办理，其余标记为已办理。

　　移动端的支持

　　通过将离校系统与微信企业号整合，可以方便地为学生提供状态查询和状态变化通知，让学生走在路上也能及时了解自己的情况。

　　离校是一个与其他业务系统高度整合的系统，但现实的情况是，整合未必一开始就能成功。而对于没有整合的环节，在设计时需考虑手工办理可能带来的问题。对于一个没有做系统整合的环节，“已办理”这个状态是有一定风险的。譬如一个博士生进入了离校名单，财务处核查其并不拖欠费用，就通过批量办理功能将其置为已办理。碰巧该博士生并未通过答辩延期一年，期间住宿舍却并未缴费。当该博士生再次办理离校时，如果宿管中心与财务处已核查其是否存在拖欠费用，就不会有问题。但毕竟人工操作难以保证时效性，就很有可能出现一个空档期。这时实际上学生欠费，可因为状态未能及时改变，会显示错误结果。

　　为了避免这种情况，对于“已办理”这一状态应该设置一个有效期，譬如办理之后三个月，当有效期过去了，则已办理状态就无效了。

　　对于没有整合的环节，导入需办理名单和批量办理就是非常有用的功能了。前者将名单内的学生设置为需要办理，同时可以将名单外但却在离校名单内的学生设置为已办理。后者则直接将大批学生置为已办理。

　　系统运转时各个部门的工作

　　在离校期间，与离校系统相关的各个部门的工作如下：

　　教务处、研究生培养处：在离校开始前提供一份大致准确的名单。

　　网络信息技术中心：将名单导入离校系统，设置学生的离校大致时间。之后若宿管中心能够提供住宿名单，则导入系统将相关学生置为需办理。

　　后勤宿管中心：根据离校名单整理学生住宿情况，提供给网络服务中心和财务处。财务处：根据宿管中心名单计算住宿费，难度较小。学生补交费用后更新财务系统中学生的欠费情况。图书馆：自学生答辩后便开始收取电子版论文和纸质论文，收纸质论文时如无借书则注销学生读者信息。

　　各学院：使用离校系统查询学生手续办理情况，并在所有前置环节办理完毕后将学生置为已离校状态。

　　总之，数字离校系统相比于数字迎新系统而言更复杂一些，但系统之间的关系理清楚，其实也并不难。

　　信息化的目的是把事情变简单，而且也只有事情简单了，才能让系统好用。在信息化的建设中，做加法很容易、做减法很难，可很多时候恰恰是减法才有意义。

　　（作者单位为北京理工大学）