什么是客户？——运维管理杂谈之二

就爱抬杠 · 发表于 2012-3-3 11:22:47

要解决IT黑洞的问题，还是要从IT本身的属性谈起。IT本身有很多属性。IT是技术，IT是资源，IT是服务，IT更是成本。对于IT以外的其他部门来说，他们并不关心具体的IT技术，也未必关心IT的资源情况，他们真正关心的是对信息储存和处理的需求是否能够得到满足，关心的是能够得到什么样的IT服务。换句话说，从需求部门的角度来看，IT的产出就是IT服务。

服务也可以是一种商品，可以被计量，可以估算成本。IT部门生产这种服务，服务的消费者就是企业自身，就是需求部门或者领导者，以下我们简称“需求部门”。换句话说，需求部门是IT部门的客户。

这当然不是什么新概念。在《IT领导力》一书中对此有如下的表述：“IT部门的一些麻烦，特别是有关项目完工的麻烦归咎于一个宣传了相当一段时间的概念——业务部门是IT部门的客户。对应这个概念有一些价值观，它使IT团队接受‘客户永远是正确的’的哲学，没有谈判，没有反对。一旦出现问题，就会有人来提醒IT，他们是“客户”。

听上去很有道理，似乎“需求部门是IT部门的客户”这个概念是万恶之源。问题是，客户当然永远是正确的，客户也确实是上帝；但总是不断提出要求而不付钱的客户还是上帝吗？还是永远正确的吗？

其实，客户这个概念有两个方面的含义：一方面来说客户永远是对的，服务提供者要为客户提供良好的服务；另外一方面，客户要付钱，要使服务提供者能够获得自己提供服务的价值。如果单纯强调某一方面，肯定是不对的；如果两方面都有，但没有互相联系，使得提供的服务和体现的价值不相匹配，肯定也会出问题。

对于企业内部的IT服务来说，还有另外一个问题，企业内部的IT服务是一个垄断的市场。尤其对大型企业来说，把关系到自己核心竞争力的IT服务外包，是一件很难想象的事情。这好比城市里的水电等自然垄断行业，要在这些行业建立自由市场竞争几乎是不可能的。

胖子 · 发表于 2012-3-3 12:02:34

非常同意抬杠兄的观点，用户部门和IT部门的关系，应该看成纯粹的business.

“需求部门是IT部门的客户” 这一概念，仅适用于已有的，且有明确服务质量定义的IT服务或系统。

例如企业内部的Helpdesk业务，通常没啥价钱好讲，用户说体验不好，速度慢，那IT部门就得无条件解决。

又举一例，拿邮件服务来说，IT部门有义务保证每个用户可以正常快速地收发邮件，这是责任。
但如果用户有对邮箱空间扩容的需求，却往往不能得到满足，因为这是超出预定义的服务质量的，得花钱。

所以，即便是企业内部，对新增的IT业务诉求也应该遵循一般商业模式，用户提出需求------IT部门给出成本（报价）------用户部门评估ROI------决定是否执行。看起来很简单吧？除了如何评估IT部门的报价是否合理------因为正如抬杠兄所说，企业内部的IT部门是垄断的，总会因为这样那样的因素给出很高的报价。

就爱抬杠 · 发表于 2012-3-3 12:26:01

胖子发表于 2012-3-3 12:02
/ T: O8 z1 D. b; J( c非常同意抬杠兄的观点，用户部门和IT部门的关系，应该看成纯粹的business.. G; s( F' m/ ~. J' [: `& v8 ?

; x1 s3 f9 [& p" N+ j“需求部门是IT部门的客户” 这 ...

"例如企业内部的Helpdesk业务，通常没啥价钱好讲，用户说体验不好，速度慢，那IT部门就得无条件解决"。其实，我们现在也在试着建立服务水平管理，体验，速度等等都可以量化。倒不是跟用户讲条件，而是向公司要资源。

胖子 · 发表于 2012-3-3 13:03:17

就爱抬杠发表于 2012-3-3 12:26 # X# h- L, [8 f3 A K6 D; b+ J
"例如企业内部的Helpdesk业务，通常没啥价钱好讲，用户说体验不好，速度慢，那IT部门就得无条件解决"。其 ...

恩，是的。

"可以量化"是评价服务的重中之重，所以我描述中的前提也是“已有明确服务质量定义”

事实上，很多大公司的Helpdesk业务已经建立起很规范的体系，包括问题记录，问题追踪，考评，工时管理等。有点类似于CRM。这东西对于IT团队来说其实是紧箍咒，但却能为“要资源”提供有效的数据支撑。

河蚌 · 发表于 2012-3-10 22:16:20

   关于业务部门是IT部门的客户，这个在广义上是对的。但也可以说，在大企业的发展蓝图里面，这已经是昨天的观点。大企业内部的IT部门的定位，不单是对企业IT系统的运行维护，更承担着本企业的业务流程的电子化再造过程，因此，IT部门往往是随着企业的成长而共同成长的。
   由于在业务流程电子化再造中，IT部门的作用，是将业务部门的需求变成为可以操作的系统，在此过程中，业务部门所提出的需求往往是零散的不相关的，而IT部门的需求分析人员，则要将这些需求变成边续的流程的可操作的设计，进尔做出能够完全适应业务需要的电子系统来。
   整个电子化流程再造，经历了数十年时间，而且至今不但没有停止，反而产生了新业务科技依赖症，即，任何的新业务，都必须有相应的电子系统来作为支撑，否则根本无法开展。这种模式，已经将科技变成了至关重要的地位上，这种业务与科技的关系，已经不是客户与供应的关系，而且一种共生。科技对于业务新产品的推出，甚至拥有一票否决权。
   而在电子化流程再造的过程中，科技部门培养了一批对于业务流程十分熟悉，甚至远比业务部门的人还要熟悉的技术骨干，由于科技人员的工作性质，使得他们对于业务流程具有天生的敏感性，可以将复杂的业务归结为一个固定的流程，从而能够让业务运营支撑体系更加完善。
   这一变化，可以从银行的组织体系中看出来，在10年前，科技人员的位置十分固定，只是做科技工作，无法去业务部门，而在近几年，银行的科技部门的骨干和主管，已经频繁被调到业务运营部门，去做主管领导。这就是因为银行管理者，发现这些出身科技部门的人，由于其工作性质和思维模式，实际上比业务口的人更有条理性和大局观。
   因此，在现代银行的框架中，很多科技部门已经在做企业整体业务规划这样的全局性职能的工作了，虽然做的并不好。但放眼银行的各个部门，似乎也只有科技部门能做这件事情。

就爱抬杠 · 发表于 2012-3-11 10:34:57

河蚌发表于 2012-3-10 22:16 9 ^4 A2 @" S3 E- t" F2 }
关于业务部门是IT部门的客户，这个在广义上是对的。但也可以说，在大企业的发展蓝图里面，这已经是昨 ...

客户对IT的需求，有功能需求，有性能需求，大概来说，分别对应研发和运维，这个我后面还会谈。功能需求承担再造职责，性能需求承担保证运行职责。这两方面其实也会越来越专业化。可能你主要考虑的是前一方面的问题，而我主要谈后一方面。

河蚌 · 发表于 2012-3-11 20:41:55

就爱抬杠发表于 2012-3-11 10:34 ! E$ _: L, C2 ]8 K1 A4 g' J0 w
客户对IT的需求，有功能需求，有性能需求，大概来说，分别对应研发和运维，这个我后面还会谈。功能需求承 ...

   在银行的IT的视角里，往往部门就分为两个，科技部门和业务部门，这个其实是一个本位的概念，其实质就是“我们”和“他们”，不是“我们”的都归于“他们”，其实“他们”的范围是“我们”的很多倍。
   在我的职业经历中，无论是以前在银行，还是现在作为产品商与银行的“科技部门”打交道，其实都可以看出科技部门领导的困惑。他们被银行的业务部门视为另类，他们做的任何事情（甚至是自己觉得很有成就的事情），都几乎得不到业务部门的赞扬，能听到业务部门提到科技部门时，就知道，肯定是系统又出了什么错误了。
   无论是站在研发的角度，还是在运维角度，实际上最好的科技部门，就是被人完全忽视的科技部门。前者，业务部门希望科技部门是土地爷，能够有求必应，而后者，则希望科技部门完全是空气，只有出了怪味时才会被人提出。
   在2000年之前，很多银行的科技部门都在进行改革，就是希望以公司制方式来运作，希望业务部门与科技部门的关系，是一种类似于“客户”和“运营商”的关系，前者提需求，后者完成，希望通过公司方式来优化科技的IT服务，甚至干脆将科技完全外包。
   但，这条路，可以说，并不成功，因为关键点在于，科技部门对于企业来说，实际上是不可选择的，甚至比公司更难以选择。任何对科技部门的差评，所得到的，只会是科技部门更消极的服务，而且由于业务部门无法知道科技部门的技术细节，科技部门绝对可以控制这种消极服务的范围，而让业务部门无法找出麻烦的。
   而上述的困境，不但存在于银行，也存在于很多企业的IT领域。因此，将业务部门和IT部门的关系，看成纯粹的商业，这一作法，只会让问题继续存在，并且越发严重。
   所以，更好解决办法，是让科技部门与业务部门互动起来，能进行正常的人员交流。实际上，在过去，有大批科技人员因为特殊原因转岗成为业务人员，这些人在与科技的交流中，就远远要好于纯粹的业务人员。科技人员在经历过多次IT系统建设之后，实际上对于业务的理解是十分深的，他们缺少的是业务办理的实务，但由于科技人员的学历一般都比较高，视野比较宽阔，对于这些实务，反而是很容易学会的。
   现在的银行体系里，已经出现了上述的正常人员流动，过去那种科技经理做死在这个岗位上的现象，已经发生了变化。在建行、交行中，科技经理，经过若干年的转岗，已经有成为分行行长的，也有更多的技术骨干，成为一些业务支撑部门的主管领导，比如电子银行部、个银部等，他们在新岗位上做的很好，而且在与科技部门的交流中，也能够做到很好的互动。
   这种变化的实质，是让科技部门脱离本位意识，自觉地将自己视为银行体系中不可或缺的一个组成部分，在IT建设中，不再是被动的接收业务部门的需求，而是更为主动，甚至通过预判来满足银行的业务需要。
   俺觉得，在科技工作中，采用上述的方式，要比客户模式更为有效，其实这种方式的执行其实很简单，就是为资深科技人员寻找出一条出路，打破过去的科技业务不可逾越的界线。当然，这种模式也需要多年的磨合才能生效。

就爱抬杠 · 发表于 2012-3-13 09:16:15

河蚌发表于 2012-3-11 20:41 - X Y% G2 Q& N4 Y
在银行的IT的视角里，往往部门就分为两个，科技部门和业务部门，这个其实是一个本位的概念，其实质 ...

这个事情上，我有不同的想法，专门发一贴吧。

“科技部门对于企业来说，实际上是不可选择的，甚至比公司更难以选择。任何对科技部门的差评，所得到的，只会是科技部门更消极的服务，而且由于业务部门无法知道科技部门的技术细节，科技部门绝对可以控制这种消极服务的范围，而让业务部门无法找出麻烦的。”

这就是我所说的，IT是企业内部的垄断市场。没错，业务部门无法而且并不需要知道科技部门的技术细节，但业务部门完全可以知道并且评价科技部门提供的服务水平，科技部门内部管理的事情就让科技部门自己去解决好了

我这个系列其实就是想打开这个死结。

		自动登录	找回密码
密码			注册

[信息技术] 什么是客户？——运维管理杂谈之二