高校数字离校系统的一种设计思路高校数字离校系统的一种设计

过去，每一个学生离开学校前，需要领一张转单，拿着转单到每一个部门盖章，全走过一遍后，便可以领证离开了。这个步骤的目的是为了确保学生在领证离开学校前，学校和学生两不相欠。
随着信息技术的发展，很多学校希望借助信息系统完成离校的工作，因而“数字离校系统”应运而生。我所在的学校也曾经采购离校系统，但实际运行情况却不尽人意，界面丑陋不说，某知名企业开发的系统在离校当天崩溃更是导致了离校工作的混乱。
在数年痛苦的经历之后，我们开始重新思考离校系统应该怎么做，并自主研发了新的数字离校系统。系统运行几年来，顺利地支撑了学校的工作。在此，仅将系统开发过程中的想法进行梳理，为系统重构做一下准备。
离校首先是简化流程
在转单横飞的年代，转单上的很多部门之所以要去，是因为当时信息系统还不普及，学校还仅仅把学生当成管理的对象而缺乏服务意识。当信息系统普及后，再拿起转单看，首先应该想到的是转单上很多部门实际上根本没有必要在离校环节中存在。这些环节可以分为两种：思路转变后可以取消、可以后台批量办理。
【高校数字离校系统的一种设计思路】思路转变后可以取消的环节，是这个环节在信息化的时代已经失去了过去的管理上的意义，比较典型的有：

学生证盖注销章：社会上对学生证的有效性是用注册章标识的，没有注册章就是无效，盖不盖注销章并无用。
收回学校医疗本：医疗信息化快速发展，学生是不是在籍在校医院的系统中难道不能查询么，学生在看病的时候不能用一卡通证明么，有什么必要收回医疗本呢？

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

网络账号注销：一个一个注销多麻烦，把该退的费用统一退到银行，然后一个命令就瞬间注销完了。
一卡通注销：同样的道理，把钱退了就行了。

同时，保留下来的环节也不要设置复杂的先后顺序，除了发毕业证学位证的环节作为最后环节以外，其它的环节完全可以并行办理。
离校环节的简化，并非系统之功，而是一批极具服务意识兼备管理智慧的管理人员长期努力的结果。而数字离校系统的建设，恰恰为他们实践自己的管理理念提供了一个契机。
离校系统解决什么问题？
学生是否获得了毕业资格，是否应该用离校系统计算呢？学生是否欠费，是否应该由离校系统计算得出呢？表面上看，这些事情都跟离校工作有一定的关系，但仔细分析一下就会发现，这些东西跟离校系统一点关系都没有，因为这些东西原本应该由教务、财务系统给出结果。
跟很多信息系统一样，离校系统本质上解决的是信息的及时共享问题。通过将学生办理情况的数据在业务部门、学院和学生之间共享，使得学生可以少跑路，业务部门可以少接待，而学院可以及时了解学生的手续办理情况。
离校应该是常态化的
很多人都把离校当成一个在特定时间的特定工作，这是因为事实上学校在毕业季才会把离校当成一个事情来做。但其实随着高校人才培养工作的不断发展，并非所有的学生都在七月毕业。譬如硕士很多是在三月份毕业，而博士的毕业就更是随着论文和答辩的进行每年可能有好几次。
在这样的情况下，把离校系统做成一种可以支持常态化工作的系统是很有必要的。要让系统的工作常态化，最重要的就是避免人工干预和配置。
也就是说，一个学生一旦成功进入学校，就应当将其数据自动同步到离校系统中。从系统的角度看，学生这时就可以办理离校了。当然哪个学生也不会傻到刚刚入学就跑去离校，工作人员也不会傻到真的给办了。
离校必须得有名单吗？
有很多公司的离校产品在使用时需要配置离校名单、初始化，而且离校名单不能随便修改，一个学生不能多次进入离校名单，这些都是对学校的实际工作不了解导致的。
过去在使用这样的系统时，我们向研究生管理部门要准确的离校名单，人家的答复是：“我怎么知道这些博士能不能毕业？他们能不能毕业要根据答辩结果确定，答辩结果还没出来呢！”
系统需要离校名单，往往是希望通过离校系统来标识出学生是不是可以离校，名单内的必须走，名单外的不能走。但从高校实际管理的现状来看，在管理没有达到一定的水平前，希望通过系统来判断学生能不能走并不现实。真正最了及时解学生情况的，恰恰是办理离校业务的学院辅导员、副书记，与其在系统里折腾一份难以准确的名单，不如把决定权留给最熟悉工作的人。
但离校名单真的没有用吗？当然不是，提供一份离校名单可以对工作人员起到提醒的作用，批量办理也需要通过名单完成，同时也可以作为生成统计报表的依据，只要不将其作为可否办理的依据就行了。
那么离校名单应该如何表示呢？一种最为简单的表示方法是在每条学生的数据上增加离校开始时间和离校终止时间两个属性，当前日期在两者之间，则学生在离校名单上，当前日期不在，则学生不在离校名单上。
办理状态如何表示？
如果离校是一个常态化的系统，那么在离校系统中的一个部门的状态项就不仅仅是是否办理完成的问题，而是有可能在多种状态之间多次转换。可能的状态包括：

待核准：当学生进入学校时系统自动为其初始化的状态。
需办理：表示学生真的需要办理这个手续。
无需办理：表示学生不需要办理这个手续。
已办理：表示学生已经将手续办理完了。
可办理：表示学生可办可不办，由本人决定。

如果一个项目处于待核准和需办理状态，学生是需要去办理相关手续的，显示为红色；而如果处于无需办理、已办理、可办理状态，则显示为绿色。
做好系统整合，才能事半功倍
在系统没有整合前，为了实现学生少跑路，业务部门少接待的任务，就必须要进行需办理状态预置和批量办理，这背后是工作人员对名单的手工处理。不仅耗神，而且容易出错。
一旦做好系统整合，每一个状态的变化随着业务系统中的数据变化而自动变化，哪怕有十到十五分钟左右的延迟，也都是可以接收的。毕竟学生办理离校时经常走在路上，只要数据跑的比学生稍微快那么一点，就可以了。
在我们的实际工作中，已经完成了三个环节中两个环节的整合：

图书馆：图书馆工作人员完成必要的工作后，将读者信息注销，此时离校系统自动将用户置为已办理状态。
财务处：通过财务系统的学生欠费信息视图，将欠费学生标记为需办理，其余标记为已办理。

在移动端为学生提供个人状态查询
离校时，学生大多处于紧张而兴奋的状态，个人行李已经打包，这时如果学生只能通过 PC 查看个人状态，就非常不方便了。
通过将离校系统与微信企业号整合，可以方便的为学生提供状态查询和状态变化通知，让学生走在路上也能及时了解的自己的情况。
这样做，也减少了学生因不了解情况对管理人员的不必要咨询。
两个对未整合环节的设计
离校是一个与其它业务系统高度整合的系统，但现实的情况是整合未必一开始就能成功。而对于没有整合的环节，在设计时需考虑手工办理可能带来的问题。
已办理状态的有效期对于一个没有做系统整合的环节，“已办理”这个状态是有一定风险的。譬如一个博士生进入了离校名单，财务处核查其并不拖欠费用，就通过批量办理功能将其置为已办理。碰巧该博士生并未通过答辩延期一年，期间住宿舍却并未缴费。当该博士生再次办理离校时，如果宿管中心与财务处已核查完其是否拖欠费用，就不会有问题。但毕竟人工操作难以保证时效性，就很有可能出现一个空档期。这时实际上学生欠费，可因为状态未能及时改变，看上去却是已办理。
为了避免这种情况，对于“已办理”这一状态应该设置一个有效期，譬如办理之后三个月，当有效期过去了，则已办理状态就无效了。
设置状态和批量办理对于没有整合的环节，导入需办理名单和批量办理就是非常有用的功能了。前者将名单内的学生设置为需要办理，同时可以将名单外但却在离校名单内的学生设置为已办理。后者则直接将大批学生置为已办理。
离校系统运转时各个部门的工作
在离校期间，与离校系统相关的各个部门的工作如下:

教务处、研究生培养处：在离校开始前提供一份大致准确的名单。
网络服务中心：将名单导入离校系统，设置学生的离校大致时间。之后若宿管中心能够提供住宿名单，则导入系统将相关学生置为需办理。
后勤宿管中心：根据离校名单整理学生住宿情况，提供给网络服务中心和财务处。
财务处：根据宿管中心名单计算住宿费，没什么难度。学生补交费用就收一下，然后更新财务系统中学生欠费情况。
图书馆：自学生答辩后便开始收取电子版论文和纸质论文，收纸质论文时如无欠书则注销学生读者信息。
各学院：使用离校系统查询学生手续办理情况，并在一切搞定后将学生彻底置为离校状态。

结语
数字离校系统相比于数字迎新系统而言更复杂一些，但把管理想清楚、把系统之间的关系想清楚，其实也并不难。
信息化的目的是把事情变简单，而且也只有事情简单了，才能让系统好用。在信息化的建设中，做加法很容易、做减法很难，可很多时候恰恰是减法才有意义。
Unix 是世界上最成功的操作系统之一，其哲学是：