三、 参考方案其实，IT企业的管理需要实用的、容易执行的，而非高深的、复杂的规范和流程，同时所制定的管理规范和工作流程是为了帮助员工把工作做得更好，使员工乐于执行而避免流于形式。因此工具软件的设计需要以员工为中心，本着灵活、实用的原则，采用模块化的结构，使每个模块都相对独立、自成体系，同时融入协同的思想，使每个模块之间产生互动，以协助员工从众多繁复的日常工作中解脱出来，更有效的降低工作难度和提高工作效率，从而实现保障产品质量、改善服务态度、降低企业成本和保证运营安全的目的，最终帮助IT企业提高市场竞争力。
为此，对于目前IT企业所出现的症状，我们可以考虑从全局出发，将目前所使用的管理工具一一进行梳理和整合，同时认真倾听员工的意见和想法，尽量满足各种不同人员的需求，这样所产生的管理工具，才能被员工所欢迎和接受。
下面我结合自己的实践，提供一个参考的方案，以便明确各部门（或角色）的职责、理顺各部门（或角色）的流程和协调各部门（或角色）的关系，从而全面提高IT企业内部的合作力度和团队精神，希望能给大家带来一种“看得见、摸得着”的管理思想，同时也希望对还没有实施工具管理或已经实施了工具管理的IT企业有所启示，早日将管理工具的规划或发展纳入重要的议事日程。
总体模块流程图
如上面“总体模块流程图”所示，基本上是按从上到下、从左到右的次序流转，其中最下面的方框包括：公共管理、资源管理、培训管理、知识管理、外包管理和财务管理，这部分内容在总体流程上可以比较独立。公共管理是系统公共内容部分的管理，例如系统字典、系统参数、人员角色等。从图上可以看出，软件的开发主要可以分为构思和分析、立项和规划、设计和开发、测试和反馈、维护和总结这几个阶段，项目管理需要对上述内容都有所体现，以免监控出现盲点，至于软件开发的过程管理主要包括需求管理、变更管理、测试管理、缺陷管理、版本管理和问题管理，任务管理和质量管理需要渗透到里面的每个模块。另外，每个模块都相对独立，可以单独使用，模块之间的互动和关联情况可以从连线中看出。至于每个模块内部的流程和关联情况，由于篇幅关系，我以缺陷管理和问题管理为例来加以简单说明。
下面是缺陷管理模块的“缺陷管理流程图”和“缺陷状态变化图”。这里所说的缺陷包括软件设计、编程、制作中出现的错误，也可以包括有助于改善质量的提议、值得注意和跟踪的问题以及可能存在的潜在错误等。从“缺陷管理流程图”中可以看出一个缺陷从登记到关闭所经历的环节，其中缺陷裁定的含义是指由上级人员对开发人员所提交的有争议或无法定夺的缺陷进行最后拍板，例如开发人员和测试人员对同一个缺陷有不同意见的时候就需要上级人员来裁定。另外，缺陷一般是通过版本的发布来关闭的，当然，对于最终确定不是缺陷的也可以直接关闭。
那么如何体现出还未处理、正在处理和已经解决的缺陷呢？其实可以通过缺陷的状态来加以区分。请看“缺陷状态变化图”，待岗处理和待人处理表示缺陷登记后还没有人对此缺陷进行排查确认，其中待人处理表示已经指定了处理人，待岗处理表示还没有指定处理人；正在处理表示指定的处理人已经开始处理缺陷，但还没有最终确认原因或对策；对于已经确认原因并且需要修改内容的，就转入等待变更的状态，进入变更管理模块；以此类推，版本发布后，缺陷就自动关闭，从而解决上述疑问。另外，转待的含义是指同一类人员之间的互相流转。例如，转待处理就是表示当前处理人如果觉得该缺陷由另外一个开发人员来分析更合适的，就可以直接将该缺陷转给他（她）。当然，这种转交最好事先沟通，以免大家互相推拖。
缺陷管理流程图
缺陷状态变化图
下面是问题管理模块的“问题管理流程图”和“问题状态变化图”。这里所说的问题是指软件的使用者或维护者提出的各种咨询或反馈的各种现象，是需要软件的支持者最终给以解释或答复的。从“问题管理流程图”中可以看出一个问题从录入到关闭所经历的环节，其中问题监控的含义是指由上级人员对支持人员或处理人员处理问题时效性的一种监督，以保证问题得到及时有效的响应。另外，问题处理完毕后一般是直接关闭的，对于最终确定需要后续处理的问题可以通过其它模块来跟踪，直至最后关闭。
问题管理流程图
问题状态变化图
下面我简要介绍一下缺陷所包含的主要属性。请看“缺陷数据结构图”，所属单位字段主要是为了支持多单位的需要；所属类别字段是表示缺陷的类别划分，例如界面错误、文档错误、编码错误、设计缺陷和操作不当等，由于是逻辑外键，所以可以通过系统参数来维护；影响程度、严重程度和紧急程度这三个字段主要是为了从三个不同的角度来形容缺陷，并最终通过所属级别字段来确定。至于其它字段，注释已经给以简单说明。
缺陷数据结构图
至于系统架构采用什么模式（B/S还是C/S）？服务器选择什么操作系统（Unix、Linux还是Windows）？数据库又选什么（Oracle、SQLServer还是MySQL）？甚至中间件选什么？开发语言选什么？大家都可以根据数据规模、投入成本、开发周期、熟悉程度和使用习惯等因素来选择搭配。另外，每家企业的行政管理模式都不太一样，有些以部门的形式，有些以项目组的形式，但是上述设计已经将流程抽象出来，和部门或项目组没有任何关系。同时，用户的操作范围通过所属的角色来控制，而角色可以定义所执行的权限集合（权限是操作的最小单位），从而最终实现权限的控制。
综上所述，其实我最想引入的就是现在常说的协同思想。也就是说，怎样把软件开发所涉及的不同阶段和不同人员都联系起来，通过工具把工作流程化，通过流程把制度规范化。
四、 前提条件最后，我想简单的谈谈这些管理工具能真正发挥作用的前提条件。
第一，需要主管领导的关心和重视，这是关键前提，也是“环境”所迫，因为我们有一个“传统”，那就是凡事必须自上而下才可能推行，凡事必须领导重视才可能做好。
第二，管理工具的定位最好不要只是停留在操作流程的“电子化”程度上，尽量利用管理工具实施的机会对原有的内部管理模式和流程进行检讨和优化。同时，管理工具的设计要源于现实而又高于现实，需要仔细分析现状，发现问题所在，了解不同用户的需求，从而在实现的时候尽量人性化一些。
第三，管理工具的使用需要每个人的认真配合，认真对待每个需要输入信息的地方，因为就算有再好的工具，也没有办法完全控制所输入的内容。如果大家没有对所输入的内容负起应有的责任，那么所保存的数据可以说就是一堆垃圾，毫无利用的价值。
当然，还有很多其它因素会影响工具软件的最终实施，但是我觉得关键还是人，熟话说：成事在天，败事在人。因此人在整个过程中还是占有举足轻重的作用，绝不可轻视。
