对面的乙方看过来

某部门想做一套以数据维护为重心的信息系统，真好，相当于认领了一个领域内数据的维护责任，最喜欢这种有主动作为精神的职能部门了，毕竟有人协助驱动推进数据准确性总是好的。

理想的方案

理想情况下，该部门的业务系统以学校核心数据库为中转站，把相关的所有数据都同步过来，形成一份拷贝，通过实际应用来发现源头数据存在的问题，倒逼源头部门解决问题。通过这种方式，核心数据库内容不断丰富的同时，准确性也必将逐步提升。按照我的想法，这样一套信息系统应该是一个相对轻量级的系统，它的主要功能包括这几个方面：

1. 完善的用户权限管理
2. 运行时创建、修改关系型数据库内的数据表及视图
3. 对数据库中的表进行CRUD
4. 实现外部系统数据读写API
5. 实现该职能部门少量的、固定不变的核心业务
6. 详细的日志

虽然上面几方面功能已经在网络中心现有技术体系里实现得简直完美，但毕竟人手有限，触碰规模较大的业务系统容易搞死自己。至于该部门需要更多的业务需求，应该以学校公共的流程平台来实现，这对于用户来说是最理想的方式，也可以更好结合校务服务大厅推进 “只进一扇门”。

流程平台通过业务系统的API来读写数据。至于为什么通过API，而不直接读写数据库？举个奖学金申请的例子：成绩合格才可以申请某种奖学金……如果不是通过API，就需要流程平台读取成绩进行计算，再决定是否允许申请，显然这些事儿不应该是流程平台做的。

现实的产品

理想要落地并不容易，几乎没有公司会做这样一个纯粹的系统，或许是理念问题，也有可能是盈利模式问题。

传统的信息系统，都是以实现业务逻辑为重心，需求分析的时候也关注的是每个业务的流程，最终把流程以硬编码方式实现，系统就算建成了。还有一种极致的作法，把流程引擎进行封装，封装得像一个功能完备，又能灵活配置业务流程的信息系统，看起来简直完美。可惜，两种方式都不是我想要的，前者还能将就，至少通过改造还有可能维护好核心的数据集，并且与现有公共流程平台进行整合，但后者就已经严重偏离了初衷。

理念的转化

对于职能部门，需要不断传递理念，比如：要抛弃“一部门一系统”甚至“一事一系统”的思维；要推进学校公共平台，给师生一个统一的入口；管理需求不等于用户需求；要转变重视管理流程上线，轻视数据产出责任等等……

企业合作伙伴的理念和产品也要不断培养，乙方应该清楚，我需要的不是一个看起来完整，但实际被限制住的系统，我需要的是各类系统各司其职，做好自己该做又能做得好的那一部分工作，彼此按照开放的接口和我们甲方的思路来整合。既然是业务系统，就不要说你们里面可以有流程引擎，那个是应该在你系统之外的独立存在。

总之，要单点，不要套餐，谢谢！

PS，数据管理能力成熟度模型都出国标了，这样一个套餐应该挺香。