摘要：今天开了个MES系统的年度规划和沟通会。会议后的内容有些意思，这里贴出来和大家分享。

　　公司的MES系统于2008年开始实施，系统接近完成的时候，公司的总体经营环境变差，于是开始人员调整优化和重组，对项目的冲击很大，原支持项目的业务部门经理离职，关键用户也走得走，散得散，靠信息技术部的同事支撑。2009年花了很大的精力，产品终于导入系统执行，运行基本正常。到2009年底时，终于出了个系统的问题，故事从这里开始了。
　　
　　2010年几乎整整一年信息技术部的MES组都在解决这个问题，过程中联系了产品厂商，第三方支持公司，自己查资料等等。问题开始的时候，从问题的表象根本看不出是哪里的问题。怀疑是windows系统或数据库或应用某个地方有BUG，反复测试，反复否定，用户遭受一次又一次的异常停机，高峰时甚至一天有2，3次。也有时，我们自己做的某个修正就把系统弄死了。采取的行动包括：
　　
　　1.优化数据库结构，调整索引
　　
　　2.优化部分应用代码
　　
　　3.添加新的硬件设备
　　
　　4.产品补丁建议（产品厂商）
　　
　　5.windows部分参数调整
　　
　　折腾了一年，最后，在2011年元旦后，开了一次会议，会议决定：
　　
　　1.制定严格的宕机SLA
　　
　　2.和业务约定，定期重起服务器；并定期检查系统的状态
　　
　　3.任何系统的调整，必须测试验证后提交变更报告给最高IT负责人，批准后在生产系统中执行
　　
　　4.添加了一台更强劲的服务器作应用服务器
　　
　　以上执行后，该问题不出现了！？
　　
　　这里不讨论技术，CIO如何考虑以下几个问题：
　　
　　1.系统出问题了，我们应该如何对待它，当一个技术问题，还是一个管理问题？
　　
　　2.上例中，技术似乎没有解决问题，通过管理手段后，问题不在出现了。我们应该当作问题关闭了吗？
　　
　　3.上例中，产品唯一有意义的建议是打补丁。其余是第三方和信息技术部的同事摸索出来的，但整个过程中，产品厂商一直在强调要先买服务（公司当时一方面没钱，另一方面这个问题最初出现时服务并未过期，但产品厂商一直未解决），再调资源研究，注意强调一下，是研究，意味厂商自己都没有方案。那产品的服务还有意义吗?
　　
　　欢迎大家就以上几个问题讨论，或者就上例提出新的问题。
　　
　　责任编辑：Honey