IT运维管理流程分析和设计
在通过《流程梳理分析表》收集到充分的流程信息后，我们不能直接将汇总结果作为最终成果发布，而应对其进行深入分析，以设计出更为高效和适宜的流程。
（一）流程分析与设计的基本步骤
首先，必须识别流程的客户。
流程的客户通常包括内部和外部客户。不应仅将流程的上下游接口岗位视为客户，而应从整个组织流程系统的视角出发，全面审视本流程的客户。通过访谈客户代表，分析客户对流程的看法以及对流程价值的期望。
其次，讨论并明确流程的目的。
通常从流程产出的接受者即客户的需求和组织运营管理的要求两个维度进行分析。同一流程，不同的目的将决定流程路线的设计及其效果。
第三步，分解流程目标，识别关键控制点。
将流程的每个目标细化为可量化的具体目标，并确定关键控制点。要求具体可测量，通常可从质量、成本、速度、风险和数量等维度进行设定。目标可作为流程绩效评估的标准。
第四步，指定流程所有者。
首先，指定流程所有者是必要的，无论企业规模大小，因为流程所有者是流程体系闭环管理的核心责任主体，端到端流程的高效运作关键取决于流程所有者。
其次，流程所有者的指定是分层级的，通常包括一级流程所有者、二级流程所有者、三级流程所有者。不同层级的流程所有者定位不同，一级流程所有者负责端到端流程的最终结果，主要负责端到端一级流程的规划与管理。规划主要包括流程变革规划及流程架构规划，管理主要包括流程变革项目的实施管理及流程生命周期管理。一级流程所有者负责管理二、三级流程所有者。二级流程所有者同样负责规划与管理，不同之处在于管理范围，在一级流程所有者整体规划与管理要求下，负责对一级流程中的某个二级流程进行规划与管理。三级流程所有者定位为设计与管理，设计负责对管控级单个流程的设计（梳理），管理则是对管控级单个流程进行生命周期管理。
第三，流程所有者设置过程中，必须明确流程所有者与功能部门之间的区别，界定二者之间的定位与职责边界，以利于后续所有者机制的正常运行。
第五步，明确岗位职责。
职责分配原则如下：
① 确保流程整体效益最大化；
② 职责明确，避免重叠或遗漏，减少争议；
③ 权责利对等原则；
④ 让具备能力和最期望获得结果的人执行职责。
当职责界限模糊时，如何处理？这是最棘手的问题。我们曾参与多个流程梳理项目，涉及职责问题的项目难度最大，风险也最不可控。尽管HR与流程咨询顾问作为中立的第三方部门，但对于职责的定位可能并不比流程所有者更专业，职责的定位预示着某项工作及责任的长期担当，这可能是各部门都不愿意接受模糊职责的原因。中国文字的博大精深有时也会加剧分歧，尽管大家在工作配合上没有根本矛盾，但职责描述上的分歧却难以避免。
当职责不清的问题必须通过流程梳理项目解决时，应如何操作？或许有人认为直接上报给上级领导即可。这确实是一个可行的方案，但随着端到端流程管理的不断加强，部门间的界限越来越模糊，职责界定变得复杂。政府部门的职责界定可能清晰，但对市民而言，却需要在多个政府部门间进行频繁的沟通。因此，在客户导向和流程管理较好的企业中，遇到职责不清的问题更为频繁（这实际上是好事，总比为难客户要好），不能每次都提交给上级领导。总体原则是大家达成共识，若无法达成共识，则由上级领导做出决定。
在处理这类问题时，我们也总结了一些经验：
① 不追求前瞻性，不追求适用于未来很长一段时间的业务管理需求，而是解决当前问题，满足当前业务需求；
② 不将精力过多地投入到大的职责定位上，而是重点讨论具体的工作由谁负责，解决当前可能的争议或不顺畅；
③ 鉴于业务的不成熟，制定制度时不过分追求精细化、规则化，我们强调的是流程的基本走向、基本的分工与管理原则。
以上我们提出了处理职责不清问题的三条原则。尽管这些原则可以解决一些问题，但我们仍期望组织内各岗位能积极主动承担“模糊不清”的责任。毕竟，组织的外界环境瞬息万变，流程的调整永远落后于要求，因此需要每个部门主动站出来，不能过分计较。
第六步，确定流程线路，绘制流程图。
如何绘制流程图？这虽是一个简单的问题，却困扰着许多人。我们通常建议Windows平台用户使用微软Visio画图软件的“跨职能流程图”模板。MacOS用户建议使用亿图图示。有人建议直接用Word绘制，我们不赞同这种方式，因为用Word绘制流程图较为困难，且不易于后续维护，而Visio或亿图图示作为画图软件，其功能足以应对大多数流程图的需求。
下面提供了一个基本的流程图示例（如图所示），供参考。
绘制流程图本身并不困难，难的是如何绘制得当。这也是许多人困惑的原因。根据我们的经验，提出以下几点建议：
（1）流程图尽可能简洁明了：流程图最好不要超过一页范围，另外虽然流程绘制软件提供了大量的专业符号，但我们建议不要用过多的专业符号“吓唬”员工，毕竟他们都不是专业人士。
（2）活动按照发生的逻辑先后顺序从上到下，从左到右排放。
（3）流程图要符合逻辑。
（4）各节点的颗粒度大小要一致。这一点是最容易犯错的，把“送货”与“打印文档”放在同一流程图中是不合适的。我们一般建议节点的颗粒度以岗位划分，需要注意的是不同时点同一岗位的活动要分开，比如“A→B→C→A→D”就不能简单描述为“A→B→C→D”。
（5）各节点的颗粒度要适度，不能太大也不能太小。太大不容易被理解，太小流程主线就不突出。请看某网友的困惑：“梳理流程的时候我们发现，流程下面还可以定小流程，再下面甚至还可以定更小的子流程，那到底梳理到什么地方可以截止呢？”其实，梳理多细在于流程梳理的目的，也就是说是否能够解决你的问题。一直细化到工作时不会频繁出现大问题即可。如果一个工作成熟度不高，大家经常出现问题，就越细越好，反之梳理出主线即可。
（6）流程图中应该把与此流程相关的上下端流程嵌套进来，如图3-2中的第6节点嵌套新项目实施流程。
（7）验收标准：要求一个外行能看懂。
第七步：确定流程与上下游流程之间的接口以及与规范流程运行要求相关联的制度之间的关系。
完成以上七步后，项目组即可按组织流程制度模板完成流程文件编制。
（二）流程的内在逻辑，流程具有其本质特征
尽管性质相似的流程在最终呈现形态上存在差异，即使在同一行业内，业务模式高度相似的两家公司，其流程的展现方式亦可能截然不同。
我们常常被流程的表象所迷惑，许多人已经深受其害，反思一下，你是否也曾陷入这样的思维定势：“通常流程需要经过部门经理、总监、副总裁的审批，因此流程设计也应遵循此模式。”
为了设计出既高效又适宜的流程，必须深入理解流程原型，即我们所指的流程的内在逻辑。
因此，不同的流程背后存在着一个满足管理需求的最佳路径。然而，基于各种合理或不合理的管理要求，每个公司的流程都增加了许多环节。这些环节是流程梳理和简化的核心，流程设计的合理性分析必须回归到“正本清源”的原则。
流程背后的角色并非仅仅是岗位。通过研究流程原型，有助于提升流程设计的完整性和效率。
（三）流程梳理需注重实际应用
人们总是追求完美，这值得肯定。然而，对于流程设计而言，完美并不总是最佳选择。在一些流程梳理项目中，尽管大家都知道设计的流程难以实施和执行，但基于逻辑判断和对完美的追求，很难说服自己放弃。最终，大家相互鼓励：“虽然实施起来确实有难度，但工作理应如此要求，先发布流程，再观察实施情况。”这种看似合理的推理，却忽视了一个问题：项目结束后，是否真的有人持续关注流程的实施情况？更令人遗憾的是，项目的目标仅仅是梳理出一个流程，而非一个可执行的流程。结果是，项目组设计出了一个理论上完美的流程，但最终被实践所抛弃。
这并非个例，而是常见现象。当然，原因多种多样：可能是流程的可操作性不足，这属于流程设计的问题；也可能是流程的性质决定了它不易自动融入日常工作（如费用报销流程），需要大量的引导和推动才能启动（例如流程优化建议管理流程，尽管优化建议的处理机制已经建立，但如何激发员工主动提出建议呢），这属于项目组设定的目标未能包含建立动力机制的问题。无论何种原因，确保设计的流程能够落地是流程梳理项目最基本的要求。
再次强调，流程绝非仅仅是表面工程，更不是追求多方和谐的工具。
当然，这并不意味着可以降低流程设计的质量。我们曾遇到过类似案例，当发现流程未被执行时，流程所有者立即调整流程文件以符合实际运作。这绝非明智之举。强调流程落地的目的是为了让大家关注如何确保流程执行的问题，而不是强调流程制度应随实际运作调整，这颠倒了两者之间的逻辑关系。参考数字化IT运维管理体系建设指南等专业文献。参考数字化IT运维管理体系建设指南等书籍资料
页:
[1]