总的来说，高校信息化的发展成果取决于应用系统的应用深度，而不是IT投资，但应用深度则取决于业务需求，与管理的思路和管理水平紧密联系。对于各个业务部门而言，信息化对业务的支撑或者说推动，是由业务需求到了一定程度来决定的，这其中夹杂着很多非技术因素。
现存问题
高校的典型问题是，业务部门想到要上系统了，向信息化部门提需求和落实经费来源，信息化部门张罗着立项、论证和组织实施，业务部门使用、评价并验收项目，信息化部门开始接管日常系统维护，日常的使用问题和需求变更则是业务部门直接与建设方进行沟通。
这样做的负面效果不少，例如系统跟不上业务的发展；业务部门不愿意用而成为摆设；一个人开始抱怨不好用时，所有人都站出来呼应和指责建设方；一部分功能使用了，一部分功能未使用，因为内在和外在的数据关联性无法贯穿，导致对系统的批评声音一浪高过一浪；个别工作人员不断要求变更功能或流程，以适应所谓的我们的做事方式，从未以信息化的方式进行思考和设计，以致改到最后却发现变成了系统初始提供的样子；在各种大小会议上，系统的缺点印象被无限放大，而系统带来的积极改变和正面提升较少被量化和共鸣。当这一个系统以失败的例子结束生命周期，似乎是给相关人员上了一堂生动的培训课，让大家在过程中积累了经验教训，然而当大家欢天喜地迎接下一个新建系统后，难免不是重走一遍老路。
在上述的例子中，信息化部门也并非是局外人，通常在项目立项前后就会做需求调研，与业务负责人签字确认，在项目初始实施中，尽可能避免产生需求变更，因为这可能影响执行时间，也可能造成费用变化。但现实却又让信息化人无奈。有的功能需求因人事变动而改变；有的因为受其他事情影响和启发提出新的想法；有的纯粹是一开始就对付了事，迫于强制使用压力又不得不勉强自己。这样一来，初始的需求分析与上线时的状态普遍存在偏差，如果项目比较复杂，信息化部门也难免被卷入批评和诟病声浪，被逼到既不能专业指导和服务，又夹板受气的尴尬境地。
因此，不管是为了推进高校信息化建设，还是信息化更好适应业务发展需要，必须采取一些策略，让业务部门与IT建设更深入协调的作为对方的支撑，激活业务人员、IT人员在信息化进程中的主观能动性。
策略1
选择一两个业务部门，所选的部门可以有迫切的信息化需求依赖于信息化部门，可以有关系较好的同事或领导在信息化建设中愿意听取信息化部门的建议，从而首先传递一些理念，信息化不是照搬线下流程到线上；信息化并不一定减少工作量，但要看减少师生的还是工作人员的；信息化系统能否运转如意，核心在工作人员自己有没有想清楚需求；工作人员不从数据源头更新变化的数据，不能怪系统。因为必须给系统确定的判断条件，否则永远达不到大家口中的“智能”，但条件的增多会带来使用上的不便，流程再造正是时机。业务部门一旦接受这些理念，就容易引导他们按照信息化的方法和思路来重新考量现有的工作及工作方法，进而让需求分析和最终完成的系统更符合用户的实际，业务部门从中才真切感受到技术带来的好处。
由这一两个部门试点显现的成效，在校内逐步带动形成信息化素养和信息化意识，让业务部门知道自己需要的是什么以及如何才能得到最想要的，从而在信息化项目立项之初就能准确找到平衡点。
策略2
信息化项目的实施完成并不是结束，它只是生命周期的开始，无论是软件bug还是功能需求变更，信息化部门若能积极地参与到需求管理，并根据情形对系统进行优化完善，则对业务系统应用起到推波助澜的作用。
尝试建立厂商、信息化部门和用户三方沟通机制，一方面，信息化部门站在全校信息化全局的角度，把握和评估用户方的需求是否可行，是否有现成的信息化手段解决，以及与哪些数据发生交互等等，结合厂商现有技术架构合理分析需求实现方式，另一方面以甲方立场和专业技术角度向厂商进行沟通和要求，使用户的需求能更准确传递给厂商，也使用户和厂商对同一个问题有了一致的看法和认识，同时对问题的处理进展和结果有了鉴证。
信息化部门在日常的运维中，还可通过技术手段或厂商的配合，建立一套量化方法，对用户的使用日志、功能使用的情况进行监控和分析，掌握系统使用频次细节，与经常抱怨的问题进行对比，从而也能客观反映出系统用得如何，哪些问题是需求设计的原因，哪些是没有好好使用的原因。这样客观分析积累越多，越能够使信息化部门和人员获得支持与理解，也能让众多的需求变更自然地分出轻重缓急，厂商也能更好回应。
策略3
对于信息化部门，有一类头疼的需求并非项目型，而是用户平时的零散需求，有时还可能说不清需求，只有一个大概的想法框架。
对于前者零散需求，有的是对现有某一项功能的改进，有的是急需对一部分数据进行处理，有的是提供一个查看或填报的渠道等。面对这些零散需求，信息化部门更应该尽其所能去满足用户，因为一个小功能和响应速度能够让用户更贴心地感受到信息化的魔力，例如，对于技术人员可能只是一个雕虫小技，但对用户则是解决了很大的事情，更容易提升对技术和对信息化人的好感，在今后遇到问题时，愿意到信息化部门来寻求解答和帮助，这比从零开始做需求分析的体验要好很多。一个完整的信息系统与业务部门的磨合都是不断地小修小改中逐渐变得完善，反之，既不修改也不使用就成了摆设。
对于后者，在业务需求不清晰的情况下，信息化部门应和业务部门继续研究和保持沟通，在条件允许的情况下，搭建一些原型系统或开源平台进行实验，引导业务部门思考，不断发掘和理清需求方向，对技术人员也是难得的学习和积累过程。
策略4
高校信息化人员短缺是各校都普遍面临的难题，部门地位不高，人员编制少，可以独当一面干活的人更少，平时还免不了一些事务性工作牵制，在这种情况下，依然要坚持保留开发人员，哪怕只有一人兼职。信息化建设中，网络工程师和系统工程师相对都容易培养，也容易从外包服务中获得人员补充，但想要开发人员留得下，干得好却弥足珍贵。信息化项目的实施，信息化人不能只当“包工头”监督乙方的进度，还要作为IT领域和业务领域的专家，对业务把控需求和管理艺术，对技术要把控系统内部设计细节和技术路径，由开发人员承担这一角色将使信息化应用更有的放矢，偶尔亲自敲几行代码也能更加凸显IT服务的价值，可能化解的是厂商与用户之间莫大的仇怨。从长远来看，信息化在高校的应用归根结底还是发展面向师生服务的应用，信息化部门的任务也会由架构和基础设施管理维护为主逐渐转变到与应用并重上来，没有通用的软件和外包服务能解决应用运维的全部问题，但高校信息化人可以。
信息化是一个持续的过程，有使用就有需求，有发展就会有变化，业务应用与IT服务之间的矛盾并不是绝对的对立，有众多的师生愿意用和喜欢用，才是信息化人最值得欣慰的地方，从这一共同目标来看，信息化人的专业性其实就是破解矛盾，减少不必要的损耗与反复，为了技术理想而少留遗憾。
（作者单位为中南民族大学现代教育技术中心）