从我的工作经历，以及与同行和厂商学习交流的感觉看，我个人认为企业信息化部门如果期望把工作尽可能的做到位，企业如果期望获得更多的信息化价值，在机构设置等因素之外，就信息化部门内部而言需要把三种能力做实。
技术能力
信息技术是信息化部门安身立命之本，技术就是信息化部门的业务能力，与研发、生产、财务等部门在企业中需要体现出的业务能力是一个意思。在常规宽泛的层面看，信息化部门需要掌握信息化领域的主流技术，也要跟进新出现的技术和概念，还要留存过往技术方面的能力（许多企业应用多年的重要系统都是多年前开发的），这些是共识。
我想重点说的是一些或许“偏细节”的内容，即
对技术和系统的驾驭能力与实践深度是有极大关系的
，如果不直接参与到系统及业务信息化的设计中（包括成熟产品在实施时的设计），不深度投身系统的实施和开发，不实际完成相关系统配置和运维，那么对技术、系统、应用，对业务的理解、把握、体会，对未来的构想、前瞻性考量的能力都是有限的。

因角色和分工的不同，虽然说信息技术部门对技术的驾驭程度大部分时候并不需要像乙方厂商一样，但也必须掌握到相当的一定程度，很多时候工作必须深入到技术细节才能体会到系统在技术或业务方面的优势和局限，必须通过在建设和使用中解决大量问题才能真正理解系统和技术，也才能保持与行业和厂商的信息对称，有效的与厂商对接，否则厂商给的方案或者问题结论是否准确是难以评估的，很多时候
因为懂，所以才踏实
。

上述感觉都是来自于工作，比如实际做过才知道某系统增加一个项目需要7个步骤的一系列操作，实际做的时候才发现某系统居然有那么丰富灵活的配置，实际做的时候才知道某系统居然有各种各样的毛病和缺陷，……。
有些企业的信息化部门定位为信息化管理部门，所谓管需求、管宏观上架构设计、管信息化规划、……，在系统应用层面，基本思路也是只做管理，即主要管理乙方厂商，问题都由乙方解决，这种思路或许需要探讨。因为如果只是文档式的记录形式上较大的问题，督促厂商解决，再单纯记录厂商的处理过程和结果，一是形式上的大问题的根源或许定位不准，其实大量实质性的小问题都沉在厂商，甲方对系统和业务存在的问题体会有限，而且厂商因为立场不同，反馈的信息可能有限或不对称，一切都浮在面上。这种情况下，甲方的管理其实很难到位，信息化能力的基础是镂空的。没有相当的技术实践，只有理论和表面上的应用经验，没有经过产业或者项目的历练，那么所谓的管理是否到位？规划是否准确？都是要打问号的。

一句话，技术方面始终都是实践出真知，没有足够实践的信息技术部门其技术并未做实。
业务能力
这里的业务能力是指对企业的业务是否足够的懂，懂业务是企业信息化部门区别于外部IT资源最核心的一点，信息技术可以脱离业务纯技术性的学习，而信息化则是信息技术与业务的融合，必须足够熟悉、深刻理解业务，最关键的是还要从信息化角度上的理解，这种能力只有通过对业务进行信息化这样的过程才能获得。
具体的，怎样把业务流程在系统上跑起来？各式各样需求的背景和目的是什么？怎样在落实在系统上？业务管控点在系统上怎样体现？怎样解决“千奇百怪”的特例业务？……，只有在解决上述这类问题的过程中，才能深刻的理解业务和业务信息化。

并且，对业务的掌握深度很大程度上依赖于足够多的经历，而问题不是都在短时间内集中出现的，问题的产生往往有一个长期的过程，那就需要时间，需要长时间的沉浸在企业中经历各式各样的情况才能理解业务和问题，甚至包括对行业和企业的背景、发展过程、组织演变、文化和人文环境等等的熟悉和理解。
关于时间这个因素前几年我还没有足够充分的认识，后来通过在一些项目上与一些厂商顾问的合作发现，多数有缘的顾问在所在领域内都是非常专业的，也有很多行业其他用户实施经验，尽管如此，在几个月内的项目周期中也是很难完全充分的理解企业业务的，很多业务场景不是找领导、资深业务员或者关键用户聊几次就能彻底理解的，一些企业信息化人员如数家珍般谈及的业务种类和过程，对初来乍到的外部资源来说往往不一定是可以迅速掌握的。

对一些新建系统项目这种表现尤为典型，这类
项目的特点是甲乙方信息不对称
，甲方对系统不够熟悉，乙方对业务不够熟悉，虽然肯定在项目过程中解决了大部分信息不对称的问题，系统才能得以上线，但经过使用，甲方有了足够多的时间熟悉了系统，或许会真切意识到乙方当时的顾问在系统本身方面确实资深，但当时项目给顾问的时间太短，甲方后续可能会逐步发现顾问对业务的理解还是不那么透彻，一些落在系统上的方案存在局限。

所以，希望临时性的借助或者引入外部高级的资源，以期迅速解决经营多年企业的问题现实有时很骨感，还是需要用足够长的时间拥有一部分懂企业自己的信息化人员，而成为IT型企业业务专家，这种与众（厂商、其他企业）不同的能力应是信息化部门坚持努力的方向。
项目管理能力
这里谈企业信息化领域的项目管理是基于上述两种能力（技术和业务），再加上项目管理本身一些理论和技术（比如PMP和IPMP）之后的一种综合能力。我们因为此前逐步形成了一定的这种能力，所以后续做较大规模项目时重点都在项目本身，比如解决技术、业务、项目组织、协同、进度管理等问题，承担来自项目工作本身的压力，没太意识到这种能力的意义，直到后来。

后来在做一个多系统整合应用的信息化推广项目时，涉及SAP ERP、费控、预算、OA等系统，这些核心系统从最初建设项目时即注意积累，信息化部门掌握了一定的技术，在推广项目范围内可以自主实施，而另外两个专业化的子系统，因为系统特点和运维需求不同（以及没有人员配置），没有能够充分建立自己的技术能力，在推广项目当时的情况下，只能依靠参与建设项目时业务部门关键用户牵头对接厂商。
项目中，主体精力基本都在核心系统上，进展顺利，待后来再看另外两个子系统时，发现与厂商落实的结果距离预期差距很大，相当于统一纳入信息化部门管理的内容是靠谱的，唯独没有纳入的两个子系统都无法满足上线要求，好在核心内容已基本完成，抽出时间后马上按信息化的方式开展工作，问题得以解决。遇到这次的项目风险，原因根源并不在关键用户身上，因为关键用户毕竟不是信息化人员，就如同不能马上让一位会计去搞网络防火墙一样，大家的分工和技能是不同的。

而更近的一次，是一位非信息化工作的朋友按领导指示编写了一份信息化建设项目管理办法，目的是希望管好他们当前的一个有规模的项目，看完文档后，首先感觉这位朋友在文档编写方面确实花了很多心思，关注到了很多细节和流程，但整个思路与信息化工作不是一个套路，如果按信息化的方式，这份文档只能重写。
后边这次的问题原因也不在于这位朋友，让他做所在领域的工作他是专业的，比如可以成为很好的关键用户，可以提供非常准确的业务需求，但毕竟信息化项目最后是落地在系统上，一定要与技术结合，那么没有系统、技术等等这些基础，就如同一盒拼图中一部分拼图根本不在他的手里一样，而拼图最终完成，需要来自信息化部门、厂商等多方面大家手里的那部分拼图，所有的拼图。
由以上的两个例子可以看出，信息化项目的管理也是一种事实上的专业能力，既然是信息化部门分内的工作，那就也需要打造扎实的能力。
以上仅是个人观点，供大家探讨。
继续阅读
阅读原文