熟能生巧 CIO如何正确制定IT政策

需要注意的是，你的IT管理规则必须源自于和这些规则息息相关的人。

丹尼以前是个军人。他的同僚发牢骚说，他的行径就好像自己是个司令官一样。丹尼很喜欢纪律与掌控，尤其是当他有参与到那些管控事项时更是如此。丹尼在担任CIO助理时，被指派负责信息政策的制订。他被取了一个绰号叫做“政策沙皇(policy czar)”。丹尼一开始就违反了我的“组织设计之指导原则(Golden Rule of Organizational Design)：绝对不可逾越职权。这样做的话，这个人就是把自己树立成政策的决策者，而不是他本来应该成为的政策促进者。”

该由谁来决定IT政策？

政策对我们工作具有约束力，通常是一个告诉我们“如何做…”的程序步骤，或是“你必须…”的规定。字典中对政策的定义是，从许多可选择的办法中，为将付诸的行动挑选出明确的方向或是方法，以及依照所赋予的条件予以领导，并且为现在与未来的决策做判断。

政策一旦建立，就会限制住一个人的选择；他要做什么、如何做，或者哪一个才是另外的选择。如同以下你将看到的介绍，丹尼享受着他职务上的权力，帮他的组织未来制定规范。

在一个领导团队会议期间，我以顾问的身分出席。我问丹尼：“哪个政策是他认为必须负责的？”他的回答是“全部！”(当时我感到相当困窘，在他精简的回复中没有称我为“sir”。我想那也是政策。)

“全部？”我怀疑地问他。

“全部。”他自信地再次回答我。

“甚至是那些单一营运线的应用？像是哪个部分必须与网络链接的政策？”我质疑着。

“一点也没错！”丹尼回答。对于我的蛮横，他好像有点恼怒。不过他没让我怯步，我继续逼问“那么你是如何着手建立政策的？”

丹尼描绘了一个进程，意思如下：

1.丹尼决定下一个要处理的政策为何，他不仅要从他所制定的潜在政策清单中，决定轻重缓急的优先级，同时得将此部门其他人的要求列入考虑。

2.丹尼设计政策；可能会利用他同僚的专业领域专家来协助进行。

3.在丹尼个人简报之后，经由CIO批准此政策(在有些状况下，会有指导委员会代表营运单位共同参与)。

4. 由丹尼执行规范的遵从。

由上而下之政策制定的问题点

我环顾丹尼的同事办公室，然后问了他最后一个问题：“丹尼，你说你负责所有的政策，甚至是那些只会对单一营运线产生影响的部分。那么在这里，谁来对网络的安全、信赖关系，以及有效率的操作负责？”

丹尼毫不迟疑地指向Rob，他是网络操作团队的首长。

现在，我们看到了问题关键：当丹尼决定的政策，是在对Rob下命令他该如何执行他的业务时，那Rob如何为他的网络服务质量善尽职责呢？

这是有违指导原则的。有其责却没有相对职权，Rob并未被准许以自己的方法运作他的业务；可是他仍必须为结果担起责任。评论者可能会嘲讽地说，他是被设置来当牺牲品和代罪羔羊的。

另一方面，即使丹尼接受了Rob在政策上的参与，但是最后还是得由丹尼来制定政策与促使它通过高层批准，因此丹尼实际的职权远远大于Rob。而有权无责的丹尼，很快就可以变成一个暴君了。总而言之，该负责的人没有职权来建立他们执行业务所需的政策。而丹尼成了“瓶颈”，阻碍许多事务的进行；他只可以一次处理一点点政策的问题，而他选择了他最迫切处理的事项。任何他认为不够重要的事项，就被搁置于清单的最后。

例如，Allie的工作是负责企业内部网络服务。她的客户要求她设置一个企业实时通讯服务，但是已经延迟两年了，有关它的使用还在等着政策的制定。她提议的政策，现在仍然痴痴地等着丹尼将它列入考虑。

政策的需求并没有被拿出来讨论。这个IT部门的规模已经发展得越来越大，也越来越错综复杂之时，它需要的是变得更臻成熟。它必须改善它的强度、安全性、信赖关系、效率、资源管控以及营运重点。因此，有必要运用政策去达成这全部的目标。但是丹尼实行这些政策的方法，却使员工们感到士气低落，而且威胁到整个IT组织的绩效展现。

政策制定可采分散方式

IT组织的问题集中在“谁有权力决定政策”。假如Rob必须对他的网络服务质量负责，那么Rob就应该被授权，得以决定相关操作上与使用上的政策。

一般而言，根据指导原则，政策应该由任何受该政策约束的业务负责人，或团队来决定。

例如，有些政策是适用于整个企业的。像是密码的安全政策，还有企业内部网络的使用规则；那些会对整个企业产生整体影响的政策，应该由企业多位领导者产生的共识来决策。虽然要实现很困难，但这是唯一可以确认政策是否有“反射到每一个人参与和投入”的方法。

其它有些则是适用于IT部门的政策。一个要能让IT人员为你的计划发挥作用的政策，政策上可能需声明—假如你希望和IT人员合作，你的计划就必须透过一个现存的文件管理程序处理，以提供相关资金上的支持，或者，你必须先把白花花的钞票拿在手上。像这样会影响一个部门的政策，应该由该部门的首长来决策，最理想的状态是，由他或是她的领导团队所产生出来的共识来决定。

第三类的政策是适用于部门中某一个特定营运线。举例，网络操作团队可以建立一个政策声明—假如你不符合确切的安全规定，你就不能连结到企业防火墙内部的骨干网络。甚至任何人都可以用“政策”这个字眼，去解释一个团队中的操作程序。

影响一个单一团体的政策(例如网络操作)，应该由该团队的领导者作决策。而会影响到一个部门里的数个团体的政策，虽然不至于是整个部门，也应该由那些受影响的团队领导者，所产生的共识来做决策。

政策团队的任务

那么丹尼的方法，有没有在任何情况下是可能发挥作用的？仔细想想那些涉及整个部门的政策，顺理成章地那些政策则是应该由CIO，以及更理想化地由她的领导团队来决定的。

在此，丹尼甚至是把它本末倒置了。对于政策发展，他宣称自己是个“一流的承包商”，而且能将专业领域的专家纳入考虑，成为他的“分包商”。实际情形是，丹尼觉得他应为政策的产生负责，而其他人则是在那边等着协助他完成的人。丹尼以政策内容之型式，出卖了其他人的专业知识和技能。

然而，政策团队的目的是协助其他人，将他们的专业知识和技能转化至政策中，并不是为了制定政策本身而将专业知识纳入。一个有影响力的政策团队，会“卖”以下的产品与服务给它的同僚：

1、政策程序之促进作用

政策团队可以协助组织的领导团队累积经验或知识、依优先级处理事项，并且达成整个部门政策上的共识，它也可以促进整个企业在公司政策上的共识形成。基于此任务目标，严格来说，政策团队是一个程序的促进者，而不是创造者、决策者或是独裁者。

2、政策编撰与通知

它可协助专业领域的专家在撰写政策时，用字遣辞更加完善严谨；以专业知识用词与定义一个有效的政策。此专业知识可协助每个正在撰写实用与有效政策的人，在管理时避免流于八股、没有弹性、丧失职权或是索价昂贵。

3、政策图书馆

它可以作为一个政策的陈列室，传递它们的可用性，以及协助人们存取、引经据典现存的政策。一个政策团队不应该为政策的内容承担责任，或是拥有任何职权是超越那个政策内容的。而且绝不能把政策稽核的相关法规遵循业务给牵涉进来。这样将会产生利益上的冲突。没有人可以一方面提供别人促进政策的服务，同时又能站在批判的角度来捍卫稽核的立场，而且还能够无伤政策团队与其同僚之间团队工作的气氛下进行。

政策制定为何事在必行

政策本来就是有风险的。它会减少人的选择条件，而且会让组织更没有弹性、更加制式化而且更少创造力。

但是，在许多情况中，政策是必须存在的。

透过建立一个从一而终、一丝不茍的程序或是必要的规范，一个选择适当而且撰写杰出的政策，将是利多于弊，它可以协助领导人运作一个有效率、客户导向、而且安全以及可信赖的商业营运。

一个有效方法的关键在于，让所有的部门或团队为他们各自的业务承担政策上的责任；而且提供他们政策促进作用的协助，这样的政策，即是在为它的同僚提供服务，而不是企图控制他们。

转载：感谢您对网站平台的认可，以及对我们原创作品以及文章的青睐，非常欢迎各位朋友分享到个人站长或者朋友圈，但转载请说明文章出处。