IT运营管理——IT与业务的和谐之道

IT 与业务，老生常谈，但历久弥新。IT 在变，业务也在变，业务环境更在变。这一切都让“IT与业务”之间只能作实证式的探索。

从应用的生命周期说开去

到目前为止，我们看到 IT 与业务之间的纽带多是“需求”、 “软件需求” 、 “系统规范”等。这些都是很重要的课题：无论是从目前项目的关键成功因素（CSF）上看，还是从客户与用户关系成功处理上看。如果放在整个应用交付过程中，这些课题显得尤其重要：一方面要对 “需求变更” 进行管理，避免范围蔓延，保证项目成功；另一方面要对业务进行“改善”，避免需求过度差异化，实现业务规范化管理。

但我们也应该认识到：这些只是开发阶段的重要课题；站在应用主导地位的甲方的立场上来说，需要从应用的整个生命周期去看——一个系统的整个生命周期包括启动、开发、建设、维护、再开发五个阶段，开发只是其中的一个重要环节。因此，如果仅仅是从“需求”和“规范”方面作出努力还是不够的。实践也表明，这些也都是乙方观点和概念，与甲方还有沟通鸿沟。

当前提的“可操作性”、“可维护性”、 “整体拥有成本（TOC） ”等概念也是从类似的一个生命周期的观念来看的。但具体到落实阶段，往往出现了很多偏差和问题，甚至随着项目的进展被有意忽视了。不可否认，这些概念是促成甲乙双方合作的有效市场宣传。但是，为了某笔交易、某个项目才存在甲乙方这种关系。因此，交易完成之后、项目结案之后的事情已经超出了甲乙方关系的共识范畴（当然也存在失去正常甲乙方关系的情况；但实践证明这也不是长久之计——一旦乙方资本获得满足或转移，真正给甲方提供服务的资源就失去了保障）。再加上这些概念模糊，很难根据 SMART 原则来处置；如果追着不放，就会导致交易或项目本身受到影响——这种类似“投鼠忌器”的状态是甲乙双方共同面对的难题和困境。因此，从应用的生命周期来看现在的甲乙方关系只是针对其中的几个环节。随着 IT 产业的发展和成熟，也提供了另一种选择：针对每一个环节都形成一种甲乙方关系；每一环节之间通过某种接口实现贯串（比如启动与开发之间通过“需求”或“规范”实现贯穿，“建设”和“维护”之间可以安排外包协议等）。但这对甲方也有要求：对每一个环节之间的接口要把握，以便能够顺利完结上一笔交易、上一个项目，开启下一笔交易、下一个项目；同时对于每一个环节都需要配置相关的资源，以便能够对应于每一个环节的工作，并在内部按照既定的工作流程进行各环节间的衔接，连续运转。事实上，有很多应用正是以这样的运作方式才得以完成其历史使命的。这样的要求和实践客观上提高了甲方对交易、对项目、对应用的把握能力（甚至有的项目中出现“甲方的技术实力和业务分析能力高于乙方”的颠倒现象），但尚无法把握其主导权；再加上开篇中提到的各种变化，使得“前期的积累能否成为后期努力的基础”成为悬疑。另外，这也提高了甲方的拥有成本和替换成本，尤其是替换成本——应用本身不具有工业产品的规模效益，无法通过简单的替换就可以实现应用目的；再加上应用本身的虚拟特性，从刚开始的宏伟蓝图到最后的客观现实之间的落差总是存在的。很自然的，在最初的环节上，甲方的机会成本是很高的，商务风险也是很高的。

当然，甲方也想尽办法来降低机会成本和商务风险，比如引入商业竞争机制、提出项目监理制度、加大后期投入等。但客观的信息不对称存在使得这些努力往往是弊大与利：有可能推迟了项目最佳时机，也有可能要面对“吃螃蟹” 、“吃苍蝇” 、 “如鲠在喉”的局面。弄不好“经济问题”容易升级成“政治问题” ；决策也容易失去应有的状态。

对当前一些共性问题和解决思路的反思和探索

由于工作的不同，我有时间去接触很多企业里的人。这也使我努力去发现一些共同现象，尝试总结成共性问题；同时也尝试解决各种相关问题。因此，对我来说，对共性问题的陈述是件容易的事情，通过实践和时间对解决思路的反思也不难，更重要的是对共性问题进一步的积极探索，而不是接受现状。

以下这些现象应该是很常见的：

—— 不管是做开发、建设，还是维护， “变化”“应急”“救火”都是人皆熟悉的形容，也是每天揪紧每个人神经的词汇。

——技术的发展、人员的发展、部门的发展等等都是需要认真考虑；而这些通常都是通

过很琐碎的一些事情所体现出来的，占用了每天绝大部分工作时间。

—— 到了年末，今年的总结、明年的规划无疑是重点；但也是最不容易处理好的事情。

有没有能够理顺这些的“银弹”？这是一个很正常自然的想法。但是，直觉告诉我们：没有。这样的直觉迫使我们接受现状，不去做其他的探索。

如果要总结一下这些共同现象之后的共性问题，大致可以分为如下三类：

——投资决策问题：IT投入产出是否合理？再投入是否必要？

——组织结构问题：如何定位IT部门？如何考核？

——部门管理问题：怎么确定IT员工绩效？怎么留住 IT人才？

为了解决这些问题，长期以来，IT 业界、一些机构组织、企事业单位都做了巨大的努力。在这些努力中，IT 治理和 ITSM 尤其耀眼；而且通过广泛地宣传和实践，也得到了企事业单位的逐步认同和认可。

对于 IT治理，现阶段来说还是有点早。因为谈到治理一定是以存在“委托-代理”关系为前提的：比如公司治理，那是因为公司的所有权和经营权分离，通过“委托-代理”关系才能得以持续经营。不过有一点可以肯定的是：IT治理头一次从 IT应用所有者（也就是甲方）的角度来考虑问题——这很大程度上解决了体制方面的问题。但目前在 IT 治理方面提出的几个框架在机制方面还缺失，对甲方的能力和资源局限性估计不足。类似的情况在公司治理上也同样存在。

对于 ITSM，现在提的最多是ITIL，实践得最多的也是 ITIL。对于什么是 ITSM，反而到提得很少了。不过，为了探索，还是需要先明确“什么是 ITSM”。 ITSM 是通过一套确定的必要措施，使 IT 组织以最适宜的方式支持业务流程；ITSM 以客户和服务为导向，保证并监控IT服务。应该说，ITSM在 IT业界头一次以体系的形式提到了客户和服务这两个业务部门最熟悉的字眼。

通过这个定义，有几点是可以得到确认的，ITSM：

——讲究“确定的必要的”投入得到“最适宜”的产出

——以客户和服务为导向

—— 支持业务流程

这正好对应了我们提出的三个共性问题：投资决策问题，组织结构问题，部门管理问题。

但是问题接踵而来：IT服务是一个什么样的服务？IT服务的客户是什么样的？IT服务如何实现其本身的价值并获得收益？我相信正是这些问题催生了 ITIL，并不断推动 ITIL自身的发展，尽管ITIL一直强调自己是“a comprehensive and consistent set of best practices for IT service management”。

而说到 ITIL，实践中除了仍然是乙方概念这么一个感觉之外，更重要的是对其提出的一些疑问：

—— ITIL是不是过于理想：比如任何 IT服务都可以市场化么？显然不是。ITIL也提出了名义收入的概念以方便内部结算；但这种概念仍然无法解决有很多 IT 服务无法定价的困绕，甚至商业沟通在 IT 服务这个

层面有的时候也很难进行下去——买的没有卖的精（信息不对称是永远存在的；为了寻求信息对称也许要花费很多不必要的成本）。

——ITIL 本身是否可行：比如是否存在唯一的优先级别以确定在 IT 服务上的投资比例？显然不存在：一个客户的 IT 服务所对应的每一个用户都会觉得自己很重要，同时又看不到在这个服务上发生在其他用户身上的成本。ITIL 更偏向于提出了业务部门与 IT 部门之间客户关系协调的机制，但并没有指出该如何落实到每一个用户身上；另外，IT 部门是一个多服务对象的发散型辅助部门，而不象财务部门等集中型辅助部门那样可以实现资源的集中利用（最经典的情形就是：财务部门的人员主要坐在办公室里工作；而 IT部门的人员一般都要在用户现场工作）；再加上 IT本身是存在多种缺陷的，而多种缺陷在什么时候出现导致问题并不能完全准确预期。更不用说应用系统远比机器要复杂得多，而 ITIL 更倾向于要先掌握所有这些复杂性。另外产品的质量只要是在质量保证范围内的波动就合格，即使有不合格的也可以用合格的产品进行等价替代；但 IT 服务的质量只有两个状态（online， offline），而且替代的成本往往很高——更重要的是，概率计算并不可行——这往往也造成质量保证流程并不能被适用。从用户层面来说，IT 服务质量是由用户与IT服务提供方在IT服务提供的时候共同形成的；但用户是不受控制的，这也就使得质量控制成为很大的挑战。

—— ITIL是否适用：比如业务部门真的了解 IT服务么（一个巴掌拍不响的）？再比如要部署ITIL又要再投资多少钱（IT部门来掏钱么？）？成功地部署了 ITIL的机构对我们的借鉴意义又有多大？

也许 ITIL 自身的定义中所潜在的含义是：只借鉴对你有利的地方，而不是全部；尽管我自身也自成体系？

另外，对ITSM的一大悬疑来自对“业务流程”的定义和理解。事实上，在实践中经常碰到这样的困境：

—— IT部门：业务部门有没有业务流程？

—— 业务部门：IT部门懂不懂业务流程？

尽管有很多人在往复合型人才的道路上前进，但这个困境仍然无法有效破解。

有没有可能跳到圈外去，把这些有用的东西给结合起来呢？

跳到圈外的思索得到 IT运营管理

什么是IT运营管理？IT运营管理：

—— 其运营管理对象是作为无形资产的 IT应用。

——业务服务是业务部门与IT部门的共同沟通语言——IT应用以其能够提供经济、有效、安全的业务服务为其成熟的衡量标准。

—— IT应用由业务服务的收入获得者资助 IT部门引入或开发。

得到IT运营管理，首先是基于我们所面对的实际情况：

—— 以应用为主；IT 部门有机会直接接触业务和应用，而不是简单的后台部门；同时IT部门有权力引入新的技术（甚至应用），而不是简单的维护部门。

—— IT 取得了很大的进步，尤其是互联网的发展和应用；IT 产业也获得了发展，产业链上的实体更加丰富，同时有新的实体、甚至新的产业链加入到 IT 产业中；硬件成本急剧下降，IT 越来越平民化（这样 IT 也就无孔不在了），变成改变人与人关系实现方式的主要载体。

—— 人员流动加速；信息安全、知识产权、商业机密逐渐成为人们关注的话题。

—— 没有深厚的IT积累；新生力量很多，接受变化的能力较强。

—— 业务上的商业模式也更多，同时竞争也更激烈。

其次在实践过程中，我们有了如下的一些新见解：

—— 在引入应用的时候就根据各自的能力确定好相互之间的职责关系；参与对象不仅仅包括业务部门和IT部门，也包括外部合作伙伴。

—— 在应用过程中，尽量降低复杂性；在既定目标下朝着“更简洁、更安全、更富价值”的方向努力，不断完善各个参与对象之间的责任关系。

—— 先在业务“体制、机制、流程”上创新，以 IT作为支撑手段开发新的应用。

——掌握简洁实用的 IT 技能成为安身立命之本；在培养的同时，新应用尽量复用现有的IT技能，以便顺利交付使用。

—— IT应用作为无形资产，充分有效发挥其特殊资产的作用和价值。

最后，也是最重要的是：前人和其他人的工作成果，不管是观点、概念、方法、体系，还是经验教训以及新的实践和探索。

IT 运营管理实际上就是沿用了很多的东西，来更好地回答我们所面对的问题，解决碰到的一些困难：

—— 首先是在沟通上：考虑到应用的特殊性以及服务概念的一般化，把应用用“业务服务”的概念进行了封装，实现沟通的统一口径、统一标准或统一语言。

——“业务服务”其价值是显性的，从而为实现“业务服务”的手段和方式的选择提供了依据和标准。

—— 随着外部的变化， “业务服务”本身也要不断发展变化，相关的决策过程跟传统业务领域的决策过程是相同的。

从这些方面来说，企事业单位在一开始的时候就可以决策，把握主导权，控制商业风险；而之后的一切都不用过度操心，专注与自己的业务就可以了——除非有了新的业务可能或者“业务服务” 本身需要发展才会引起企事业单位的重新关注。这样就衍生出两个生命周期的概念：“业务服务”自身的生命周期，与一般工业产品的生命周期是一样的，由企事业单位（也就是甲方）负责；IT 应用自身的生命周期，仍然遵循开篇提出的五个阶段，由内部机构或外部合作伙伴（也就是乙方）负责。

我们提出的三个共性问题也可以在“体制、机制、流程”方面得到支持，比如更灵活的甲乙方关系：

—— 投资决策问题上，可以直接基于“业务服务”进行甲乙方关系考虑；也可以通过内部机构将“业务服务”分层形成自己需要的“业务服务”，再进行甲乙方关系考虑。

——组织结构问题上，完全可以根据自身的发展战略需要决定组织结构的设置和调整策略，具体落实上则以“业务服务”自身的发展来决定；并且可以准确知道何时应该如何调整相关的甲乙方关系。

——部门管理问题上，以“业务服务”为导向集中进行创新，在管理上将创新劳动和标准劳动进行分离，达成有效激励；在甲乙方关系中可以灵活地进行资源整合，满足“业务服务”发展的需要。

尽管“IT 运营管理”所得属于偶然，接受这种观念的人还比较少；但是目前大家都是按照这种理念在做——只是缺乏总结而已。另外，IT 运营管理还需要成功案例来支撑，尽管很多成功的机构也是这么做的——只是缺乏交流而已。这些都是 IT 运营管理作为一种理念或咨询服务在推广过程中需要解决的。当然，还会有更多的问题；但正是这些问题推动了IT 运营管理本身的发展。尤其是考虑到各个企事业单位（甲方）各自的特殊情况，更需要有针对性的策略与安排去解决实际问题。

“IT运营管理”是“银弹”么？不是。但我们相信：

—— IT部门作为一个管理部门出现需要一个配套的 IT运营管理体系。

—— IT 运营管理本身就是朝“简洁、安全、有价值”方向不断努力，是一个循序渐进的过程。

——不断实践、不断总结、不断交流保证了 IT运营管理过程的开放性。

文章来源 E-works

本文来自互联网，仅供参考

发布：2025-10-21 21:53 编辑：泛普软件 · xiaona [打印此页] [关闭]