收集IT运维管理流程信息
在项目正式启动之后，项目经理有责任确保项目成员对项目中出现的问题进行进一步的补充和确认。尽管在项目启动之前，项目组织者已经与部分关键岗位的人员就这些问题进行了初步的沟通，但那时沟通的主要目的是为了验证问题的真实性以及严重性，并没有对问题的详细描述提出过高的要求。这是因为当时的主要目标是分析项目的可行性和必要性。
例如，当分析预计会涉及到职责变更时，就需要确保项目成员中包含相关岗位的领导和人力资源部门的人员。然而，在那个阶段，具体会是怎样的职责变更并不十分明确，也没有必要过于具体化。相比之下，项目正式启动后，问题描述的质量和全面性就显得尤为重要，因为它们将直接影响到后续问题梳理的质量和效果。
项目组需要收集流程信息以完成流程梳理分析表，如表5-1所示。流程信息的来源通常包括已有的流程文件、实际运作的详细描述（通常比流程文件更具体、更准确）、工作记录文件、工作绩效分析报告、日常流程问题记录、客户调查报告以及与流程所有者的访谈等。
特别是对于那些尚未形成书面文件的流程，需要各相关岗位的人员同时填写《流程梳理分析表》。如果涉及多个分支机构的操作，应该让每个分支机构的岗位代表都参与填写，最后再进行整合。在必要的情况下，可以针对流程的现状描述专门召开研讨会，以便更深入地理解流程的细节。
表7-1流程梳理分析表
XXX流程梳理分析表
流程名称：
流程客户：
流程目的：
流程目标：
流程所有者：
岗位及职责：
流程的活动描述
序号
时间点
活动名称具体工作描述/管理原则/经验点/工作质量要求/异常处理
存在问题用到的相关文件（制度/指引/流程手册/模板/表格）
1
描述/证据原因分析重要度
2
3
4
5
6
填表说明：按工作的先后顺序填写，尽可能细化，至少应该细化到岗位。
当然，并不是每一个流程梳理项目都能够做到如此细致地收集流程信息。例如，如果梳理的流程相对比较简单，或者项目成员对流程的认知度已经相当高（有时这种认知可能是过于自信的），又或者项目经理对流程的把控能力很强，那么也可以直接填写流程梳理分析表，然后进行整合。
在某些情况下，如果梳理项目中的问题点非常具体和明确，并且已经存在成文的流程制度，那么可以直接基于现有的制度进行讨论。
流程梳理工作，就像其他流程管理模块的工作一样，是一个循序渐进的过程。我们不能期望所有的流程梳理项目都严格按照本章节所描述的方法进行，尽管这套方法已经被证明具有很高的可操作性。这与方法的成熟度、与特定组织的适应性以及宣传推广的力度有关。此外，项目经理也需要一定的时间来接受这种方法。因此，对于那些由流程所有者自主发起的流程梳理项目，我们通常会在关键环节上以建议的方式逐步推广方法论。
例如，在项目启动之前，我们可以建议项目经理是否需要进行一次培训；在项目启动后，如果项目组过早地陷入具体问题，我们可以及时建议他们再次收集信息，看看是否还有其他问题；当项目方向发生偏离时，我们可以及时提醒项目组关注目标；在流程梳理完成后，我们可以建议项目经理进行培训和推广，并在必要时提供一些样本和亲自协助推进这些工作。
我们始终认为，方法论的推广不是通过一两次培训课程就能完全实现的，培训课程更多的是传达一种理念，是一种松土的过程。具体的应用需要在实践中进行引导和巩固。只有在实践中，使用者才能真正意识到方法论的价值，下次他才会主动地应用。
在实际操作中，最终收集到的流程信息质量（包括详细度、完整性和准确性）往往并不尽如人意。即使你已经提供了流程梳理分析表，但仍然会有一部分成员无法填写完整。例如，他们可能会说他们无法清楚地描述流程的目的，或者他们对其他岗位的工作缺乏了解，又或者他们认为岗位工作描述无需太过详细，甚至有人干脆就不填写。
虽然这种情况并不符合我们的要求，但你仍然需要接受这些异常情况。因此，项目经理需要时刻注意把握重要岗位提供的信息质量，并确保目标导向。在这个时候，项目秘书的重要性就显得尤为突出。他们不仅需要负责工作的跟进和催促，还需要对工作的质量进行检查。
更重要的是，他们需要负责流程信息的整合，在整合的过程中，如果发现某些信息不够充分，还需要亲自与各岗位人员进行沟通。为了更好地完成这项工作，可以参考数字化IT运维管理体系建设指南等书籍资料。
页:
[1]