从事企业信息化项目，或多或少都会遇到一些困难和矛盾。结合自己公司或者客户企业的实际案例，来讨论下大家从项目开始实施，以及的过程中遇到的最大冲突或困难是什么？

 再就是冲突或者困难是如何形成的？ 针对这些困难又是如何去解决的，实际效果如何？ 不知道大家又有什么更好的建议和经验的分享？

张三：

分几个层面来讲吧：
1、业务层面。
        ERP系统及概念在中国境内推广也有20年左右的时间了，俗话说“没吃过猪肉，还没见过猪跑吗”，大多数专业ERP顾问在面对新客户的业务需求、功能需求时，基本都能和标准功能或者过去的经验匹配的八九不离十，很多顾问都会拍胸脯保证没有问题，甚至于早早的就能做出完整的业务蓝图和系统开发配置方案，满心以为，终于碰到一个靠谱的项目了，但时间稍微一长，他们会发现，真正在等待他门并不完全是表面上所看到的。
        为了配合公司战略目标，客户的核心业务发生转移，关键业务流程因为目标的转变也发生了剧烈的变化，顾问门开始紧张，抓紧时间调整方案，关键用户也跟着忙前忙后，但这些看起来还都来得及处理；然后公司一纸通知，关键公司领导因更重要的需要调离原岗位，要专心经营业务，同时领导会带走部分中层管理人员，其中包含了ERP项目的几位业务责任人，顿时，关键用户们乱了阵脚：业务直属上级不在了，未来领导是什么风格？是否还重视信息化？绩效如何评定？是否又得回去老路？大量的不确定性会严重影响团队中甲方成员，特别是业务部门成员的积极性，这时候，顾问们坐不住了，大量的风险报告汇总到项目经理或更高级别的项目管理层，但项目管理办公室的主要成员都是信息管理部门的领导或公司分管信息化建设的领导，没有足够的权力平抑风险，只能继续上报。数周以后，风险报告汇总到公司总经理办公会，由于ERP项目资金占用不高、项目周期长，公司领导层认为几个月的阵痛期不至于影响企业经营，给出批示：视项目具体进展情况再做延期或中止处理，待议！此时，真正的问题摆到了项目团队面前。

2、数据层面。
        大家都知道实施ERP项目，特别是供应链管理，讲的是3分技术、7分管理加12分数据，为的就是强调数据的重要性。
        现在新上ERP项目的用户，多以大型央企，特别是传统行业为主。在经历了多年的业务沉淀以及多次世界范围的原材料升值之后，这些企业终于在业务规模上能赶上其他技术含量更高、战略水平更重要的兄弟单位了，在经历了多年的企业改制阵痛之后，公司级领导深知企业改革以及管理水平的提升为企业带来的价值会远远大于单纯的经营，为此，领导们积极组织各个职能部门负责人、各重点业务领域的带头人到各个兄弟单位学习、取经，这时候，他们学到的第一个课题可能就是赶紧上ERP，他们学到的第一个难题一般就是数据管理，特别是物料主数据管理。
        领导回到公司后，马上组织信息化专题讨论会，以最快的速度启动了信息化建设整体规划项目，更重要的是，同一时间，领导指示物资管理部门必须马上开始研究主数据管理规划，体现出了领导对主数据管理的重视程度。
        经过一年多的密集规划部署，大大小小的信息化项目马上启动，其中最引人注目的就是ERP项目。物资管理部门经过一年的讨论和研究，组织大量企业内部、外部的生产、经营领域相关专家参与，形成了公司统一的物料分类体系以及属性管理模板，部门领导满心欢喜的提报了最终的交付品。公司领导通览一遍后，邹紧了眉头：“为什么和同行业兄弟单位差异这么大？”“咱们的业务领域和他们差异较大，无法借鉴。”“分类体系也不能学习？”“。。。不能。”最终，公司领导带着疑惑签署了交付物，部门领导带着忐忑的心情回去启动项目了：“会一帆风顺吗？”
        按照主数据管理规划，物资管理部门牵头组建了公司级的主数据管理小组，由各生产单位、经营单位物资专家组成。带着公司领导的期望，数据专家们风风火火的开始工作了，看到如此强大的阵容，ERP顾问们心里的石头暂时放下了。
        随着项目的推进，数据专家们的工作也在有条不紊的进行，起初是整理通用材料，有大量的国标作为基础，一个月以内就整理完毕，然后是通用设备，虽然产品型号、技术参数让人很挠头，但经过几个月的磨合讨论，各方也都能认可，终于，数据专家们开始进入专用设备、专用材料的整理，首先，专用材料的专用特征决定了专家们不能在一起讨论、办公，必须按产业特征进行分组，其次，每位专家对自己所属的行业内专用设备、配件的属性也并不完全了解，需要和同行业的其他生产单位的专家进行沟通，这一沟通才发现，原来自己尚未涉足的领域是如此的庞大。
        几个月过去了，ERP整体进入上线前准备状态，会计科目标准化、内外部组织标准化、单据标准化、岗位职务标准化等等一些列工作都已就绪，但物料主数据标准化的成果却迟迟没有上报，部门领导询问进度，得到的答覆是，刚刚完成不到1／3的编码整理。在询问原因的时候，领导发现，原先得到几十万数量级的物料编码清理绝非一件简单的事情，生产单位要求所有配件属性必须包含厂商部件，但这违反了公司统一的属性模板规则，设备属性上包含了厂商型号，但这会导致招标时丧失公允性，各种各样的问题泛滥开来。这个时候，领导紧张了，因为大量的动态数据清理工作马上要开始了，没有足够的编码，如何进行？影响了对账怎么办？但数据属性代表了管理的方向，属性的精确性将影响未来供应链管理的精确性，绝对不能放松，必须得一步一步认真处理。此时项目经理也开始紧张，合同中虽然规定了数据工作是乙方自己的工作，但影响了上线，自己也脱不了责任，焦虑的氛围马上在项目办公室蔓延开来。

3、技术层面。
        技术是信息系统项目的基础，全新的技术和架构不仅能提升信息系统的运行效率，还能打打提升用户满意度；差的基础设施与落后的架构，很可能会导致整个项目建设成果因为效率问题而付诸东流。因此，信息部门的领导在基础技术设施上的投入从来都不吝啬。
        世界级的软硬件产品供应商在年初刚刚发布了新一代一体机，其理论性能报告上的数字让几乎所有的首席信息官都垂涎三尺。公司领导刚作出批示，要给予信息化建设充足的资金支持。既然有如此强大的一体机，为什么还要花费相同的成本去部署传统的服务器模式而且还要背负后续更庞大的维护成本呢？带着信心，信息部领导给新部署的所有主要系统的正是环境部署了一体机，其中ERP系统采用物理安装模式，其他直接集成系统采用时下流行的虚拟机部署模式，既使用了高新产品，又有效节约了硬件资源，两全其美。
        项目进行到中期，大规模集成测试已经完成，技术团队开始大面积部署正式环境，从ERP系统开始，技术团队的专家们发现，这台一体机不一般。经过多轮安装尝试，技术专家们发现系统始终无法完成安装，为了节省资源，测试环境使用的传统服务器，由于是新技术，同行内还没有成型的技术文档可以借鉴，把厂商技术专家请过来，发现他们也仅是在研发阶段做过测试，但都停留在理论基础上，对与新出现的问题，也是一愁莫展。更糟糕的是，后面还有好多套虚拟机模式的系统等待安装，眼看着在过一轮测试就要开始模拟运行，本来一切都看似简单的事情，突然变成了整个项目唯一的瓶颈。信息部门领导的自尊心受到前所未有的冲击。

 借着上面三个案例阐述一下本人对问题的观点，这仅仅是抛砖引玉，相信同行的兄弟们看到这些问题一定会有同感。更重要的是借此机会，和更多的朋友分享问题演变的过程以及预防、解决方法，欢迎扔砖头。

李四：

一、基础数据的整理：没上系统之前，很多数据都是部门各自为政，五花八门，同一供应商或客户在不同部门的记录都不一样，物料编码不系统，可识别性不强。 这就需要大量的时间和协调各部门的人员进行数据整理

二、业务流程的变更：之前很多部门的操作只图操作简单，不符合内控和管理需求，也不考虑部门之间的协同合作，只挣部门利益，忽略公司整体利益。规范流程之后，会带来不少的抵触，这时候沟通很重要不但要跟部门老大沟通，他下面的人沟通更为重要，因为做具体事的人是员工，当然，肯定离不开一把手的大力支持，可以把内部审计绑上船，一起做这些事情，有时候他们比IT部门更管用，比如，当部门之间有利益冲突的时候，要把几个部门和直管领导，内部审计一起叫上站在整个业务流上来谈变更。当然适当的考虑业务人员的难处，改加人的时候，该换台电脑的时候，IT部建议和主动给他们换，也可以说跟领导申请项目奖金，但不做承若。

三、需求变更控制：很多部门老大只图自己方便，要求增加这功能，那功能的，首先还是让他说清楚需求，然后看对其他部门的影响，再看变更的难度和代价，想其他可变通的影响最小的方案，有时候还是可以拿内控来说事。总之，较大的改动，除非万不得已。

王五：就拿去年一个项目：公司为解决ATO编码过多问题，想搞的一个类似淘宝订单管理系统，当时是一位领导高层头脑一热，就决定开始，我们IT就是根据需求做好了框架和相关的开发，由于产品的复杂性，产品信息、相关配置信息及定价信息没有一个成熟的方案，所以连这些基础信息都没有建立起来，。每次领导提出来要用系统，业务部门组织人就召开会，提一点需求，我们IT满足一下。后来他们干脆提出一个根本无法实现的需求，说我们做不到而结束。

赵六：最近一个项目上，我感受最深的是数据和流程问题；我所处的行业是一个高速发展的行业，因为业务发展太快，很多流程跟不上，系统也疲于应付，在上ERP项目的时候，我花了一半以上的时间在数据梳理和核对上；
 大家可能在很多项目上都有感受，因为业务系统不完善，所以数据经常被从后台数据库修改，这个就直接导致很多数据来回变动，这个給核对数据带来了很大的挑战；我花了很多时间去給技术部门普及财务流水账模式的数据记录方式，目前看正在起一些效果；

我认为最大的困难为：数据和流程；

我觉得在作出决定之前，更多的要倾听客户的需求以及客户的问题，只有对需求和问题了解清楚才能解决好问题；
 甲方的客户对自己行业的业务比乙方更了解，对容易出问题的地方了解更清楚；所以先学会倾听，且我认为方案都是在互相讨论之中得出的；

品号编码是在实施过程中遇到的一个难点，客户使用ERP系统很多年了，有自己的一套编码规则，但是由于当初给予编码的含义太多，而编写规则的说明比较简单，品号的扩展变得很差，在执行过程中又不是很严格(多人多口径新增编码-这是比较禁忌的)，造成现在无号可用和一物多号、一号多物，现在要换新系统，客户已经看惯了原来的编码，想换套新的编码困难丛丛。转变客户的观念很关键。

很多时候项目组内部的矛盾相对来说还比较好处理，因为无论是甲方还是乙方的项目组成员，大家都在同一条船上，至少说有着共同的目标和利用。
 如何协调好项目组外部的资源才是最困难的，ERP这样的大型项目涉及到企业的方方面面，其中的各种利益交织错综复杂，有的业务部门往往就会消极对待，重视不够，投入不足，不配合等等，这些问题对项目的推进影响是非常大的。
 通常的做法是拉企业的一把手做虎皮，建立定期汇报或者考核机制，带有一定强制性的去推动外部资源的配合。但如何能使业务部门能自发自愿的投入到项目，协助项目工作的开展，这更是需要思考的。

不管你的东西有多好，最终是要交给别人使用的，而只要使用的人说你一句不好，你前面的辛苦和努力会全部都白废。为什么他们说你的东西不好，可能是因为他昨晚他没睡好，上班路上狗屎踩一脚。永远别去和用户去争吵你做的东西好不好，他有一万种方法证明你的东西不好。高层领导的重视度和配合度的确很重要，否则项目别想开始，更别想往下做。可越往后，下面的抱怨会越来越多，刚开始抱怨的时候，高层还能去分析一下，并且往往还是支持的，因为的确看到了产生的效益。但时间往后推，只要抱怨不停止，高层没那个时间和精力去调查，他们最终会和下面的用户一样，就认为是你做东西不对了。一般这种情况发生的时候，一个新的项目就会开始了。所以要感谢那些抱怨的人，是他们使你订单源源不绝的。
 我觉得做项目时我最大的困难不在于外界，而在于自己的心态，只要心态是积极的，总归是有解的，否则相反。

来源：巨灵鸟 欢迎分享本文