关于企业信息化的53条“大实话”

ToB行业头条

+ 关注

2023-06-30 09:52

517次阅读

有关企业信息化建设的53条心得，看有没有引起共鸣的？

人们常说汽车就是件花钱的事，买车要钱，加油、保养、维修、上保险、过路费、停车费等等都需要钱，用车带来便利的同时都有相应的花费；那么其实信息化也一样，系统建设要钱，运维、定制化开发、厂商年费、系统升级、人员薪酬等等都需要钱，所以信息化就是一件花钱的事。

如果问信息化的价值是什么，建议可以设想一下企业如果没有信息化会怎样？也可以看看信息化做的好的企业是怎样的，在这个方面其实是可以比一比的。

甲方对乙方的唯一价值就是乙方可以从甲方这里赚到钱，这一点乙方肯定始终都是很清晰的，但有时甲方会有点模糊……。

如果乙方长期不能从甲方这里赚到钱，其实也就不存在甲乙方的关系了，所以有时甲方向乙方提出协助时，可能需要在商言商的换位思考一下。

这一条其实与第一条的意思类似，总结起来就是，对甲乙方来说，都是花钱才能办事。

社会和科技一直在发展，企业要想生存，就必须随着市场的变化而变化，企业在变，信息化也必须跟着变，因此信息化建设是动态的，所固化的只是当时的业务场景，所以后续每隔一段时间提出要变更系统功能和流程，或者需要升级和新建系统，不要觉得很意外，所谓“没完没了的信息化”就是这个意思。

一个企业搞不好信息化可能有人、财、物等多方面的因素或理由，那么没有独立的信息化部门肯定算是一个信息化搞不好的理由，因为不是独立的部门，说明信息化工作的专业性和重要性不被认可，自主决策权有限，因为组织和行政级别低导致话语权低，进而往往无法充分让专业的想法和意见被正视，不能有效以信息化专业的方式方法把握信息化工作……

总之，无法有效的调配资源，而最后，信息化又往往以背锅侠的身份频频现身。

一直的一个小“困惑”，信息时代，现在又在大谈数字化转型，财务和信息化都是专业性很强的工作，没有企业敢让非专业资深人士兼职CFO，但很多企业对CIO就很任性，“随意”安排人员担任CIO，CIO有时仅仅只是一个头衔，这是什么原因呢？企业真的要把对信息化的重视程度与希望通过信息化取得的成效达成平衡，而且，信息化真的是一项专业性工作。

甲方在评估乙方展示的项目案例时，一定要多方面落实准确当初实施那些项目的核心顾问是否还在乙方供职（企业信息化行业乙方顾问的流动性是很大的），因为如果核心顾问一旦离职，项目经验就跟着顾问走了，乙方相当于已经没有了那些项目的经验积累甚至能力。

乙方公司确实很重要，比如一些大型厂商还是让人更放心一点，但最关键的还是具体做项目的顾问，乙方是否有能力做甲方的项目，全看是否有对应的资深顾问，重点还是看人。

信息化建设中，有时借助咨询公司的专业能力和经验是好的选择之一，但是，虽然理论上咨询公司会帮助企业提出方案和解决问题，但企业自己还是需要去主动的思考和寻求解决方案，不带着问题看答案往往无法知道答案是否正确，很多事情企业还是必须自己要想清楚，而不能有完全依靠咨询公司完成全部工作的想法。

毕竟，真正最了解企业自身情况的还是企业自己，而对企业最上心的还是企业自己，这个谁也替代不了。

数据的准确程度由什么决定呢？答案是：数据的准确程度由重视程度决定。

当忽视岗位专业性或专职性随意指派人员输入数据时，当不花时间和精力去梳理业务流程随意采集数据时，当不花钱完善系统功能时……，真的就不好奢求数据准确程度了。

企业信息化中，软件真的只是工具而已。软件只是业务和管理的信息化承载物，通过软件固化和优化流程，覆盖流程中各种条件下的细枝末节以保障合规和协同，并通过自动化处理一定程度上尽量提高工作效率。

所以，企业信息化很多内容根本就是管理范畴，当管理想到位时会发现信息化真是得力的工具，当管理没有想到位时发现系统或许都不好用……。

信息化建设项目在选择厂商方面有时很像结婚，因为系统上线后，需要甲乙方长期的在一起，日常解决各种问题，升级，优化，如果选择正确那么会是一段幸福的关系（双赢），如果选择错误，对甲方来说，如果不废掉系统，日子过得将会很糟心，而如果废掉一个系统，特别是关键的大系统，对业务和相关系统都有影响，已花掉的钱也都打了水漂，伤筋动骨。

所以，甲方在建设项目前，真的要好好准备准备，谨慎、全面、详细的评估各种方案。

项目的成交价格要合理。

对乙方来说，不建议抱着一口吃个胖子的思路报价，在市场价格范围中，根据项目情况给出实惠的价格肯定是甲方喜闻乐见的，一旦合作，大家坦诚相待，优质的甲方将是一块稳定的收入来源；

对甲方来说，最低价真的不一定是好事，因为要讲究经济规律，钱没有花到位，乙方提供的资源和尽心程度或许不得不也打了折扣，需要让乙方获得符合市场行情的收入，乙方也要赚钱养家的，与乙方一起良好的发展对甲方是有益的。

诸如ERP、EPM、CRM等管理类系统建设项目，从来都不是单纯的实施一个软件的事，企业一定是希望通过实施这类系统解决业务和管理问题，那么管理类软件的厂商也一定是需要一些咨询能力的，因为项目中，用户一定会问业务与系统结合的问题，也一定会请教厂商该怎么做更好，遇到问题时也一定会问其他用户怎么解决的。

关于这一点，从甲方角度，甲方要界定好管理咨询与信息化建设项目中流程梳理和轻量化咨询的边界，纯管理咨询还是找专业的咨询公司，而与系统应用密切相关的找实施厂商；

从乙方角度，比如实施人员，不仅仅要熟悉系统的技术性配置，也必须要掌握利用系统解决用户问题的能力，虽然不必成为咨询顾问那种彻底的业务专家，但确实需要熟悉业务以及与系统结合的应用方法。

不过现在跨界的咨询厂商也比较多了，咨询后一定会再以一个信息化方案落地解决客户问题，那么软件厂商要奋起直追了，适当建设一点咨询能力，况且，设计更为专业的软件也必须要有非常资深的业务专家才行。

数字化肯定是件好事，因为数字化至少或许是个提升信息化的机会。

很多企业的信息化还远远没有真正做完和做好，那么面对当下铺天盖地而来数字化大潮，一些企业如果希望数字化转型，是不是考虑先把此前归在信息化范畴的内容先补上？比如该上的系统是否都上了？已经上的系统是否已经充分用好了？业务和数据是否在多个系统中已经打通了？数据是不是需要先治理一下？……

中台是好的技术和组织方案之一，但中台并不是信息化的标准答案，即中台并不是信息化一定要做的内容。

是否要建设各类中台，单就技术方面，现在规模型企业的信息化是一张白纸的情况很少，那么建中台基本都要对已有系统架构做大规模调整，改变各系统的集成和应用方式，这需要综合考虑业态（复杂、变化快）、规模（大企业）、技术（多系统、烟囱类痛点）、组织形式、管理水平、信息化投资等多方面因素，完整评估后如果结论是需求强烈，那么以中台理念做重构或许是好的信息化升级方式，如果不是太强烈，也不用过度担心在中台潮流中落伍。

毕竟中台只是众多方案中的一种，中台也不是万能的，如果原有或者其他方案更适合就不需要建中台的。

归根结蒂还是那个永恒的原则：一切从客观的需求出发。

信息化建设中，系统初期建设肯定需要花不少钱，而上线后，只要企业在发展那么肯定就会有变化，有变化那么系统就要随需而动，一动就要花钱，所以系统在长期的使用中肯定有相应的费用。

如果企业经营的不足够理想（缺钱），只在初期花一些钱，而在使用中不投入，需要改进的不能改进，该升级不能升级，信息化日子过得紧巴巴的，系统使用的效果肯定也不理想，所以，信息化是有钱企业才能做的事。

企业都在竭力追求差异化来体现自身的核心竞争力，如果与友商一模一样是很难胜出的，企业需要有个性，但个性也是有代价的。

比如在信息化方面，要区别什么是个性，什么不是真正的个性，就像在管理理论领域很不容易再有创新一样，对一些非常成熟的套装系统来说，很多很多常规该有的功能和流程已经内置了。

这些也体现的是系统应用多年所积累的一些最佳实践，充分利用系统固有的标准功能解决问题或许是性价比更好的思路，免去了自定义开发带来的费用和多种不确定性，特别是费用，定制化开发的费用是挺高的，代价大。

而对于ERP、HR、OA等系统，如果干脆完全放弃市场上成熟的商业软件去全新自开发，就更需要慎重评估一下了，比如自己的个性真的是合理的吗？自己的行业积累是否真的够？真的有足够的预算吗？后续的投入产出比是否真的合适？……

信息化建设中向卓越企业学习和借鉴是比较重要的，因为可以快速获得一些正确的方法，规避掉部分已知的风险，不过互联网企业或者IT企业的信息化建设经验往往是很难参考的，不仅仅是因为业态可能不一样，还因为这些企业有着太强大的开发能力了，可以买到的系统感觉不好用，或者买不到自己想用的，或者觉得购买比自己开发更贵，那么干脆自己开发一套，无论是快速迭代还是试错，都有强大的开发能力做支撑。

而传统企业一般没有互联网或者IT公司那么充足的开发资源，没有那么好的条件，传统企业只能在一定范围内去掌控系统，即便系统或许可配置性很高，或许有低代码平台，但超过一定范围还只能转由专业厂商和系统原厂支持了。

所以传统企业或许可以借鉴互联网和IT企业自开发系统的思路，但在具体系统建设和应用方面可能就不太行了。

举个例子，当医生给出治疗方案后，患者一般会提很多问题把情况弄清楚，而不太会去与医生讨论治理方案本身是不是应该那么做，这是因为一般的患者不懂医学，所以需要请医生用通俗的语言把情况讲明白，同时也因为患者知道医学太专业太深奥了，所以无法与医生讨论。

同样是面对专业性的信息化工作，部分用户对信息化的态度有时就不太一样，比如用户会提到在大学也学过编程，当前问题不就是一个判断或者赋值的事吗？其实，管理员比用户更希望问题是这样的简单。

术业有专攻，IT类工作确实也是非常专业性的工作，看看书店里或者电商网站上IT相关图书的种类和数量……。

正视信息化的专业性，或许是很多企业信息化工作需要先解决的问题。我此前讲解材料时还会举例说企业花巨资建设的系统就像豪车，信息化部门就是豪车驾驶员，用户使用豪车完成业务，现在不这么比喻了，而把豪车改为了飞机，原因就是担心再遇到用户说汽车我也会开……

新系统建设项目有个显著的特点是用户和厂商信息不对称，即在系统建设的短短几个月时间内，用户对新系统不够熟悉，厂商对用户的业务不熟悉，系统建设就成了一个信息逐步对称并且无限逼近一致的过程。

因为这种客观存在的，在短时间很难避免的信息不对称，导致当期交付的某些功能与实际需求往往存在差距，而后续用户通过一段时间的使用会逐渐熟悉系统，自然就会发现一些问题。

所以有个建议是，项目一期结束后，可以适时启动一个优化项目，目的就是优化项目一期的内容。

为什么要专门立个项目，而不是通过常规运维来小修小改，一则是通过项目化的管理能更好的推进相关工作，还有一点是，项目会让甲方项目组与乙方团队再次驻场一起开展工作，而在现场工作的效率要远远高于一来一往的远程方式，特别是涉及多系统集成的项目，往往把多家厂商再聚在一起才能快速高效的彻底解决问题。

信息化项目常常都有主导的部门，主导部门既是新系统的用户，往往同时也是系统的重要建设者，所以主导部门对项目的积极性是很高的，而其他相关部门在项目中的内容可能比较少，于是感觉系统本身也不是给他们用的，所以积极性略低。

然而毕竟是同一家企业，业务流程是一体和连续的，当期项目很可能需要相关部门的数据，甚至可能需要相关部门根据新系统做出相应的改变，如果相关部门因主观原因导致参与度不高，消极敷衍，很可能导致项目与其相关的内容做的不全面不彻底，完全有可能大大影响到新系统的效能。

表面上是主导部门所做项目留下了一些不足，似乎影响的是项目主导部门，但实质上影响的是整个企业。所以希望的是无论是主导的还是非主导的部门，所有部门都应站在整个企业的高度，对企业负责，争先出力，打破部门墙，摒弃小格局，无论承担多少项目内容，每个部门都最大化的为项目贡献价值。

一个部门是否重要，真正实质的就在于这个部门能够贡献出多少价值。

无论甲方还是乙方，项目经理都是份非常不容易的工作。

在信息化项目上，项目经理要懂业务、懂技术、懂管理……，还要情商高，因为可能需要搞定上上下下、左左右右、形形色色的项目干系人，对外有可能需要完成让用户高层由零基础变为信息化专家的碟中谍任务，对内可能需要摆平项目组内顾问之间的性格不合……；

工作更是五花八门，一会儿在需求调研、一会儿又在培训用户，再过一会儿可能干脆亲自敲代码做配置，白天忙项目，晚上写总结做计划……；所以，请善待每一位辛劳的项目经理。

另外，如果项目有一定规模，甲方项目经理建议是让具有一定职务级别的管理人员担任，因为项目上的很多很多事并不是一个项目经理岗位可以推动和解决的，有时各种正副总经理职务才有说服力。

并不是说需要级别形成压力，而是面对级别，项目干系人的耐心有时是不一样的，比如与领导的沟通往往会更有耐心；再比如同一件事，领导交办与同事需要协助这两种效果有时也是不一样的；还有厂商的重视程度也很不一样啊。当然，领导具备的更高能力才是项目管理最需要的。

无论是信息化建设项目，还是数字化转型项目，亦或是数据治理项目，一定都是业务驱动的，即主要是由业务部门推进才行，或者说只能由业务部门才能驱动。

如果对驱动两个字感受不强烈，举例来说，汽车的驱动力来自于发动机，没有业务驱动的上述项目就像没有发动机的汽车，动不了。换言之，用户自己都不着急，谁着急也没用，要不就再来一把手工程？

在刚开始接触还不太了解一家企业的时候，怎样可以初步判断这家企业对信息化的重视程度呢？看企业是否设立有一级的、独立的信息化部门即可，如果没有独立的信息化部门，基本说明这家企业并不真正的重视信息化，或者不懂得应该怎样重视信息化。

关于专业性，举例来说，比如虽然都是专业的医生，但不能让牙医做心脏手术，再比如虽然都是专业厨师，但不能让西餐厨师去做川菜，……。

而信息化相关的工作中，各领域都有其相当的专业性，需要让专业的人去做对应领域的事，跨领域要有一个度，合理配置专业资源是挺重要的。

比如让网络管理员去组织建设一套财务系统，让OA系统管理员去做数据治理，……，类似这些安排往往都会出现各种不必要的问题。部分程序员或许可以修电脑，但程序员并不是修电脑的。

当一款新（版）软件产品推出后，产品在初期的问题一般都比较多，企业用户在厂商的推销和承诺下选择了新产品，其实也承担着相应更高的成本和风险，比如某业务流程在成熟产品中可能两三次就能跑通，但在新产品中可能会遇到各种Bug和不适应，跑通一个流程或许会需要数十次的尝试，这个过程中，用户的人员投入、工作量、耗费的时间、影响业务的程度都更多，用户要克服更多的困难。

对（被）愿意成为小白鼠的用户，厂商虽然不一定非要抱有感激之情，但不要辜负用户的重托，至少要理解用户为了新产品也付出了很多，帮助了产品和厂商的成长。

甲乙方要相互理解彼此的不易，比如，乙方厂商投入到项目上的每一位人员，乙方都要按时支出真金白银的人工薪酬，所以甲方还是要按合理的市场价格采购厂商的产品和服务，并且所有交给厂商的工作都要考虑背后的成本，等价交换。

同时，厂商也应体现出足够的专业价值，用户之所以找厂商，大部分时候是因为厂商更专业，用户希望借助厂商的专业能力解决问题，如果项目上很多事都需要用户教给厂商怎么做，用户把甲乙方的工作都做了，那么甲方也太难了。

行业内外对ERP系统的讨论一直非常多，时不时会有一些新的观点，一会儿说ERP不能满足某某需求所以ERP不行了，一会儿说ERP脱离了时代，……。

其实ERP系统的概念与核心功能相对是比较明确的，也有些随着业务和技术发展而升级的新功能，那么ERP能把大部分企业最核心的业务过程（采购、生产、销售、财务）管起来，可以把花钱和赚钱这个过程管起来或许就已经实现了其基本使命，本来就是一个软件，寄希望于上一个软件解决很多问题或许有点不容易。

ERP就像一辆家用轿车，一会儿希望它拉货，一会儿希望它越野，一会儿甚至希望它是坦克，……，对ERP来说也挺难的。ERP就是ERP。

信息化往往就是管理本身，各种软件系统实质都是经营和管理的工具之一，所以，无论信息化也好，数字化也好，需要先把业务怎么做和怎么管本身想清楚，而且要自己先想，想不透彻时可以部分借助外部厂商的能力，然后找个工具落地。

所以，如果不思考管理和提升，就没有真正有成效的信息化结果，干脆就不要做信息化。

现在行业内外都在热议数字化，甚至部分企业和厂商都不愿再谈信息化，凡事都是数字化，数字化确实是现在可以开始努力的方向，只是在具体工作层面，或许会发现很多是与此前做信息化的内容一样，还有更甚，想要数字，发现系统还没有建、没有建全、没有打通。

所以，现在可以按数字化的要求和角度务实开展工作，但还是希望给信息化留一线空间，希望在媒体上能再多看到信息化三个字。

一些大型企业的内部IT公司，核心定位通常首先是服务好企业自己的信息化（数字化）建设，如果还有余力，也可以对外输出能力，并且在市场上磨砺了产品和服务之后可以更好的服务企业自己，但还是要不忘初心，即首先服务于企业自己。

另外，企业内部专业IT公司的存在还有两个重要的价值点，一个是内部IT公司是全职专业的甲方，如果企业内部多个部门或者单位各自去推动信息化项目，先不说非IT部门是否专业，主要是企业这些组织往往不是全职的甲方，而信息化项目如果没有人一直盯着，往往很难有效推进。

另一个价值点是内部IT公司使信息化建设工作的责权利更为清晰，比如投资路径就很清楚，企业的信息化投入都经内部IT公司支出，总部该给内部IT公司拨款就拨款，成员企业该分摊就分摊，把钱都打给内部IT公司，虽然是集团内部，但都是企业间交易，信息化资金结算路径清晰。

什么是好的甲方？能够让乙方赚到钱的甲方才是好的甲方。

什么是好的乙方？能够解决甲方问题的乙方才是好的乙方。

还有就是，不想赚钱的乙方是不存在的。

信息化是管理的镜子。信息化做的好，管理肯定做的好；管理做的好，信息化一般也会相应的好；信息化做的不好，管理水平反而高的可能性就很低了。

所以，从“功利”的角度上讲，或许也应该把信息化做好，起码可以让管理看起来做的很好，况且，信息化是有其实实在在价值的，持续的把管理和信息化做好，应该是积极向上永不懈怠的追求。

关于专业性，业务部门对信息化部门的态度有时是飘忽不定的。

比如，系统不好用或者出了问题，业务部门可能会说系统是专业的，信息化部门应该也是专业的，如果系统没有被管好，说明信息化部门不专业；而在系统规划、建设和使用中，信息化部门提一些信息化专业意见时，业务部门又觉得信息化也并不一定是什么专业的事，按业务部门的想法做就行……

有的业务部门可能把懂业务和懂信息化两件事搞混了。在业务和需求方面，肯定是业务部门最懂、最专业，并且在信息化项目中，一定需要业务部门参与规划、明确需求和驱动项目。

而信息化是做什么的呢？从某种角度上讲，就是信息化部门把需求通过多种技术予以实现（基础设施、应用系统、开发集成、……），需求和实现结果之间还有着一个信息化，作为一系列很专业的领域，信息化本身应该是信息化部门更懂，现实需要信息化部门按信息化的方式开展工作。

服务于企业自己的内部IT公司，初心一定是做好自己企业的信息化工作，那么怎么保证这个初心呢？

就是内部IT公司一定只能是成本中心，企业只需要拨款支付合理的员工薪酬和公司运转必要的费用即可，常规情况下这样的信息化成本会较低；而如果内部IT企业有利润中心的成分，哪怕背一点点经营绩效压力，那么内部IT公司不想方设法赚钱反而是内部IT公司的不对了，一旦考虑要赚钱，对内也是一个自然的方向了。

所以，如果企业希望有更低的信息化成本，那么让内部IT公司只做成本中心或许就好了。

信息化项目的最大风险往往来自于甲方，特别是甲方决策层，如果甲方的项目决心不足、驱动力不大、组织机制不畅、责权利不清、想法不一致、目标不准确、需求不清晰、……，都将成为项目的致命伤，影响程度远远超过业务和技术本身复杂度所带来的影响，轻则让项目变得超级复杂，重则导致项目失败。

由此，甲方启动项目前，真的要认真评估和认真准备。

人天合同或者需求不确定的开口合同是土豪才能拥有的。因为现实中，无论是任务复杂程度或者实际工作量往往都是甲方难以判断的，无论是乙方有意还是无意，很多实际人天并一定会如甲方在工作量单上看到的那样，使得本身签一个固定范围和固定金额的合同可以更好验收的项目，变得难以完成和验收，而多一天就是一天的钱，最后甲方还不得不花一大笔钱。

之所以有各式各样的信息化项目，之所以有被建设成为各式各样的系统，往往是对管理、组织、技术、资源等各方面不断妥协的结果。规划设计或许很好，但在各种现实面前不断妥协和改变，结果就是各式各样了。

企业信息化项目中，需要考虑各方的各种立场，例如甲方与乙方的立场（甚至还有丙方等，比如咨询公司后来还做系统建设监理的情况），例如集团总部与所属企业的立场，例如领导与员工的立场，例如业务部门与管理部门的立场，例如成本中心与利润中心的立场，例如项目中不同团队之间的立场.……

立场不同，导致追求的目标不同、行事风格不同、结果不同，所以需要关注各方立场，关切各种立场的诉求，达成在一定范围内的平衡，才能更好推进项目。

另外，立场不同，效果的差异往往是颠覆性的，很多工作就内容本身来说或许乙方也可以协助甲方做，但事实上只能是甲方自己来做才行，因为只有甲方是真正为自己，特别是一些涉及管理的内容。

企业信息化项目从来都不只是一个技术内容，常规情况下都包括或多或少、或深或浅的管理内容，既然有管理，相当于信息化项目承载了一定的管理任务，即通过信息化支撑一定的管理进而得到多方面的价值。

那么很多工作，比如统建系统、数据治理等，是有很多管理职能的，例如集团一体化和差异化的判断与决策、标准的贯彻和日常管控等，这些都需要按管理职能来对待，需要有组织和机制的保障，成为管理工作的一部分行使管理的职能，而不能仅仅当做信息化项目阶段性的做，也不能完全依靠非管理立场的组织或者方式来做。

关于定制化开发，用户与厂商的考虑有时或许是不一样的，比如软件中的某个界面上有表格，表格中有金额列或者数量列，一般情况下，表格下方应该有合计，别看只是一个小小的合计，但往往可以给用户的工作带来很大方便。

这种表格的合计显示，我理解应该算厂商软件开发基本规范的内容，或者是开发人员的基本习惯，如果没有合计，客户提出需要的时候，类似这种“客户需求”，此时如果厂商认为也属于需要另外花钱的定制化内容，就有些离谱了。

对于厂商来说，怎样才能吸引客户？怎样才能保持与客户的长期合作关系？或许挺简单的，就是做客户喜欢的事，比如产品好，比如服务好。在合理范围内，客户喜欢什么，厂商就做什么。

类似ERP系统一类的应用需要有厂商生态，比如有软件开发厂商，也有咨询实施厂商，后者常被称为生态伙伴。

而对部分国产系统，厂商生态目前可能是最大的短板之一，咨询实施生态建设不足，就效果来说，缺乏足够多的、足够强的咨询实施资源。

造成这种现状有多方面的原因，挺复杂的，否则也不会这么多年得不到更好的改变，其中软件厂商比较复杂的咨询实施体系可能是一个原因，软件原厂既做产品也做实施，并且把实施当做主业之一，大量项目，特别是高级的项目（比如大型集团型项目）很多是原厂做，并且，部分情况下可能还存在软件原厂与生态伙伴的竞争，……，生态体系是挺不容易发展起来的。

部分国产系统的顾问生态也是最大的短板之一，无论原厂还是生态伙伴，由于多方面原因，所沉淀的资深顾问数量相对比较少，特别是比较缺乏可以有效驾驭大型复杂集团型项目或者国际化项目的资深顾问。

在部分项目上的具体现象可能是，部分顾问不太能充分理解用户的需求，不太能够做出好的方案设计，不太能够把系统配置到位，……，甚至部分出现问题的项目，很多时候不太是软件本身的局限，而是顾问配置的有问题。

部分国产系统的顾问流动往往是脱离式的，包括上边厂商生态建设不足在内的一些原因，顾问离开原厂体系后，往往也并没有流动到生态伙伴，而是开始从事其他工作了，加上相对较高的流动率，导致确实不太容易沉淀到足够多的资深顾问。

好飞机还需要好的飞行员，顾问对项目的重要性不言而喻，那么软件原厂或许真的需要更多好好考虑考虑顾问生态建设的内容了。

我一直都说信息化或者数字化建设都是花钱的事，而且是持续的花钱，所以开展工作前确实要想好钱方面的事，钱的重要性毋庸置疑了，但后来发现，缺人的问题或许比缺钱还严重，在一些情况下，即便理论上有钱，但并不能解决人员不足的问题（比如人员编制问题），各种项目都需要人去执行，需要有人才能把钱花出去，才能把事情办成，特别是一些要求比较高的项目，没足够多、足够专业的人，也不能把人放到正确的位置上，工作是很难快速开展的。

对不少企业管理类的国产软件厂商，顾问生态长期以来都是一言难尽的状态，较突出的现象是中高级顾问数量太少，顾问不熟悉业务以至不能与客户有效沟通需求，顾问不熟悉自家的软件产品以至于难以实施，顾问经验不足无法解决复杂问题，顾问缺乏大项目历练所以不能提出整体和综合的解决方案，……。

总的来说，能弄懂需求然后驾驭软件解决问题的专业顾问太少。我甚至有比较“极端”的想法，就是这些厂商现在甚至都可以放缓产品的迭代，不用急着一味的推出新架构和新概念，而是投入更多精力和资源去解决好顾问生态的问题。

对不少失败的信息化项目，主要原因往往不是软件功能本身，而是顾问没有实施好，甚至是软件本身就有的功能，因为顾问不熟悉，所以“不得不”做定制化开发去满足需要，造成了不必要的工作量和费用，也破坏了软件本身的功能体系。

软件厂商让自己的顾问熟悉自己的产品，这个本来不应该是个问题的问题，需要软件厂商们重视和解决。

怎样形成好的顾问生态以及实施伙伴生态？其实有一个直白的效果就比较好达成，就是在这个生态下，对合格的顾问能让其获得比较理想的收入，无论顾问是在软件原厂还是在生态伙伴中。

但做到这一点想来也是很不容易的，项目总价中不仅仅是实施顾问的钱，厂商的销售、研发等等各个部分都有，其实，各个职能的人员都需要有符合市场和预期的收入，达成这个效果确实是个行业难题，但也是软件厂商管理者自己的一道必答题。

不少信息化项目承载了太多的使命，例如希望通过信息化一蹴而就的解决一些困扰工作多年的问题，又例如希望在信息化项目中得到更多创新，……，不是说信息化项目不能完成这些使命，常常还真是信息化倒逼了管理的提升和工作的优化，也因为有了更好的技术基础，从而为创新提供了更好的条件。

但其实信息化项目本身的内容往往已经很有挑战了，基本都有大量管理和技术问题要解决，那么不妨第一步先按常规或者典型最佳实践先把基本的流程跑通，先让业务在系统上转起来，总结之后再提优化或者创新，本身信息化项目就应该是动态发展的，更多的使命留在适应性调整项目或者优化项目时做可能更稳妥。

信息化项目一定是一把手工程才能做好（这是一个老生常谈的话题）。

首先，因为信息化就是花钱的事，如果不重视，资金和人员不到位，就很难做。

同时，企业信息化项目一定会涉及管理内容，很多线下工作流程中存在的问题，在上系统时是绕不过去的，这些问题往往牵扯多方，非常非常复杂，如果不重视，就没有足够的动力和资源去解决，而常规情况下，二把手、三把手、……，一定向一把手看齐，一把手不重视，下边的人也不重视，问题就很难解决，信息化项目做起来就非常困难，很难取得更好的效果。

企业信息化是以技术为基础的专业性工作，信息化部门如果不是专设的、独立的一级部门，是在某个大部门下的二级部门，工作往往是很难有效开展的。

例如，很多事项需要由部门负责人决策，而大部门负责人不是信息化领域的，所以首先需要向大部门负责人讲清楚事项，而把很多技术性内容向非信息化领域的管理者讲清楚是非常不容易的，这样至少就增加了额外的沟通成本；

而非信息化领域的管理者对技术内容的认识和判断可能不够准确，所以决策可能就是不准确的；进而，如果大部门负责人在不熟悉和不理解事项的情况下，再向高层汇报，信息可能进一步失真，无形中给信息化工作带来了更大的不确定性和风险。

总的来说，信息化部门如果不能对信息化工作做主，就会带来各种不必要的问题。

在企业信息化工作中，与ERP、财务共享服务、主数据管理等已较成熟（产品、方法、案例、顾问等）的领域不同，企业数据治理在现阶段可能还不是太成熟，虽然也有了理论体系和大量的产品和项目，但因为业务和数据的“千企千面”，同时与管理思路、业务、系统、数据基础关系密切，使得在企业数据治理领域目前很少有特别成熟的东西可以被直接拿来套用。

这个情况是双方面的，一则部分甲方现阶段对数据怎么管怎么用还比较模糊，不容易想清楚；二则供应商此前实际深度参与企业业务的机会较少，对数据的技术能力强，但在业务理解和解决方案方面偏弱。所以现阶段的企业数据治理，可能会有各种各样的项目，也会存在较多的试错成本。

数据的靠前治理和靠后治理同样重要。所谓靠前治理是指重视在数据产生的源头让数据质量更高；靠后治理是不太关注数据产生源头的情况，拿到数据后再治理。

在企业中，财务、生产、人力等各领域都有各自专业的应用系统（模块），这是合理的，各自领域的数据往往聚焦本领域，从专业性上讲也不一定会完全照顾到相关领域，那么最理想的情况下，各个领域的数据质量都很高，此时数据靠后治理或许就比较合适，数据治理的重点任务就变成把各个专业领域的数据汇聚到一起，然后建立各种联系，形成跨领域的、不同角度的、整体的数据结果用于数据分析、挖掘以及提供数据服务。

但实际情况往往不是这么理想和简单，常见的是数据源产生的数据质量不高，但从数据治理角度去对应用系统产生影响有时又很难，所以数据不得不靠后治理，比如直接把各种各样的数据先收集到一起，然后做数据清洗、建立映射等等，而这些靠后治理基本都非常复杂、成本很大但效果不理想，就像在用脏水洗手一样。

所以主要希望强调的是，数据的靠后治理往往是不得不做的，是妥协后的方式，而不能当做实质和理所当然的，真正要坚持的原则是尽量靠前治理，大部分问题力求靠前就解决掉，靠前治理应该是原则。