GJB5000A（以下简称“5000A”）体系建设是组织的事，对于个体——包括个人和项目——难有直接、直观的意义和好处，因此，不能指望个体自发、自主地推动，只能依靠组织有计划、有套路地开展。在这个过程中，没有充分条件，只有以下必要条件：一支队伍，一套体系，一样工具，若干资产。
一、一支队伍
有一支什么样的军队，决定了能打到黄河以南（祖逖），还是打到红海沿岸（成吉思汗）。
对于5000A体系建设而言，过程组（EPG，Engineering Process Group）就是那支军队。EPG要管理组织过程定义并推动过程改进，其理论知识和业务经验的丰富程度，与所建软件研制体系的健全和有效程度成正比，与组织的软件研制能力成正比。对于EPG的组建与管理，组织高层应该高度重视、充足投入。
EPG是制定规矩、提供业务支持的机构，其规模由组织对5000A的认可和重视程度以及所能承担投入的能力决定，但至少应覆盖项目管理、质量保证、配置管理、软件以及工程等专业；同时，应根据其成员工作量的饱满程度动态调整。
EPG成员要有能力和威望，应该是圈内的领袖、师傅。口碑之外，不妨设置一个硬性指标：从事相关业务工作五年以上。组织应有计划、持续地向EPG成员提供学习和外出取经的机会和条件。如果EPG成员在一段时期或者某个领域持续地抱怨或者工作推进不力，说明需要充电或者对外求助了——这一点十分值得组织高层注意并解决。
EPG成员要有吃苦精神和奉献精神，其希冀和作为，应该是修路，不是自己而是成就别人到延安。不过，个人的高觉悟往往难以稳定、可靠，这就需要组织对EPG成员的任务 、绩效进行设计并考核、兑现。尤其在5000A体系建设初期，EPG一般需要专职成员。随着组织软件研制能力的提高，EPG的构成可逐渐包括专职、兼职、顾问，并各司其责。随着个人能力的提高，组织可以安排和推荐EPG成员参加内部、外部软件研制能力成熟度评估/评价，成为名副其实的专家——这可以作为EPG成员成长通道的一种形式。
5000A体系建设那些事，大到生存周期模型，小到产品/过程检查单，绝大部分是枯燥、无趣的。指望EPG始终充满激情是不现实的，但EPG成员做事、对人要热情，并结合日常作为修养师者之风，如传道，如授业，如解惑，要善问更要经得起问，要能解释 更能解决问题。
一支队伍，当如涓涓源水，不雝不塞。
二、一套体系
成熟的组织有规矩，优秀的员工守规矩。
规矩，堪称中华文明的精粹。相传规和矩原是禹发明的两种工具，以规画圆、以矩画方，后演变成标准，继而制度。对于软件研制而言，规矩就是5000A体系文件。经历过军用软件研制能力成熟度评估/评价的人都知道，弱项、待改进项不外乎两类：一类是体系文件的问题，如未理解5000A含义、未覆盖5000A要求、可操作性差等；一类是执行的问题，如不按体系要求执行或执行不到位、弄虚作假等。科学地讲，问题是绝对的，也是让人难堪的事，但循着问题探索方法以改正、改进，经常成为快速提升的捷径，故有“闻过则喜”。
5000A体系建设两部曲：“组织过程定义（OPD，Organizational Process Definition）”与“组织的过程焦点（OPF，Organizational Process Focus）”，也就是建立体系与改进体系。
在《GJB5000A-2008 军用软件研制能力成熟度模型》之外，还有一个《GJB2786A-2009 军用软件开发通用要求》。从标准的名称就应该读出来建立体系的策略：依据2786A建立体系，按照5000A强化重点。具体而言，2786A中关于软件开发过程26个活动的划分，是科学、严谨的，可以保证体系的完整性、系统性；5000A对过程域（PA，Process Area）的划分，是分等级的，即二级7个、三级11个、四级2个、五级2个，均有所侧重但未覆盖软件开发所有活动，并不适合作为建立体系的直接依据。因此，推荐以下思路：以2786A中的26个活动为桩，参照5000A的成熟度等级、过程域对相应的桩进行加固，再结合组织已有的管理模式、工作习惯，编制一架完整、系统、有效的篱笆，为软件研制和组织发展保驾护航。
组织高层在战略层面上论清楚5000A与2786A的关系之后，体系文件分几层、编制多少个，工程、支持、管理活动如何在体系文件中统一、单独体现，管理部门所负责的这些战术，方可有的放矢，所建立的体系才能具备完整性、系统性。再之后，具体的仗怎么打，就看EPG的了。前文已有交代，EPG应代表组织在理论知识和业务经验方面的最高水平，但要保证所建立的体系能够覆盖国军标要求而且简捷、实用，还有一些工作要做，也有一些技巧可循，比如咨询专家、老师，比如走出去取经。
鞋子舒不舒服，脚最清楚。5000A鼓励“本地化”，并专门划分出“验证（Ver，Verification）”这个过程域，自有其道理。订国军标的人、编体系文件的人、执行体系文件的人，对文字这种媒介的理解和表达不可能无缺，这就会导致文件与执行之间出现偏差。为尽量减少这种偏差，在体系文件颁布实施之前，有必要演练、验证一番，看看是否走得通，能否走得便捷，提前发现并解决问题。当然，演练和改进不能无休止，因为还有OPF。
关于OPF，5000A中如是说：基于彻底理解组织的过程和过程资产的现行强项和弱项策划、实施和部署组织的过程改进。想要“彻底理解”，必须基于充足而真实的数据深入分析，主要渠道是“测量与分析（MA，Measurement and Analysis）”。成熟度评估/评价提出的强项、弱项和待改进项，产品和过程检查中发现的缺陷、问题，则是更高价值的来源。“没有调查就没有发言权”要在OPF落地。“欢迎专家老师帮忙查找问题”不应只是一句套话。
组织把规矩定好了，要实现人人守规矩，远非一蹴而就。规矩的意义，首先是让组织收益，然后才能回报个人贡献。这种过渡和延迟，是体系执行过程中各种阻力产生的根源。认识到这一点，就可以从两个方面去化解矛盾：一是减少过渡，缩短延迟，灵活、及时地奖励“胡萝卜”——匹配地设置一些“大棒”也未尝不可，通过激励政策的同步来促进体系执行；二是加强与职工的沟通和交流，消除误解、误会，以理以德服人，让职工自发、自主地站得高一点、看得远一点，奉献多一些、计较少一些，从企业文化的角度为体系执行挖掘稳定、长久的动力。
三、一样工具
工欲善其事，必先利其器。
相较GJB9001B和之前的软件工程化，5000A最显著的特点是精益化，极力提倡文档化、可视化。尤其是MA这个过程域，需要采集和处理大量的原始数据，组织有必要提供工具支持，也就是一个软件平台。说到工具，回顾一下照相机的历史，得出一个结论：对于一个懒得写游记却又想留点纪念的人而言，傻瓜相机不但好使而且够使。再回想一下DOS系统和Windows系统，得出又一个结论：如果不是用来创造、创作，需要专业、专门知识和技能的工具，不是好工具。更通俗地讲，莫拿大炮打蚊子，莫让工具成负担。为了更大可能地满足多个利益相关方的要求，研制或选购一个最合适的软件平台，职能部门不妨组织一次简化版的“决策分析和决定（DAR，Decision Analysis and Resolution）”。
有了称手的工具，绝不等于不再劳动，反而会对劳动提出更高的要求，并附加一些约束，如按部就班、工作量化、按时完成等。劳动者需要认识到：自己的劳动结果不只是自己用，本项目用，其他人和组织也要用，标准化自有其必要性。在这一点上达成共识，有助于用好工具，以充分发挥其作用。
关于工具的维护，必须保证一点：与体系保持一致。体系是工具的基础和依据，体系的稳定性与工具的维护难度成反比。因此，软件平台任务需求的制定，应该在体系基本稳定之后；制定软件平台任务需求的人，必须是对体系有足够了解的人，比如EPG。否则，工具投入应用之后，捉襟见肘将不可避免；在组织贯标的整体计划下，如果来不及对工具进行更改而硬赶鸭子上架，削足适履也将不是笑话。一旦体系文件发生更改，如涉及工具，应有计划地予以调整，这反过来又给OPF设置了一条限制。可见，EPG、体系、软件平台，包括下文将提到的“资产”，相互关联，构成5000A体系建设这个整体。这四个方面的系统性，将决定5000A体系建设的顺利程度。
四、若干资产
前人栽树，后人乘凉。
组织过程资产就是“树”。编制某份文档，可能存在以下四种情况：凭个人经验编制，按照模板编制，参考优秀样例编制，由工具软件生成。四种情况下，完工进度不同，文档质量不同，所需成本不同。由此可以得出一个结论：过程资产的规模、数量和质量，与组织的软件研制能力成正比。
组织过程资产库的设计，有经可取，而且取经不难。对库的管理维护，踏实肯干即可，都不需要加班。问题：资产从哪里来？回答：积攒。一个健康的资产库，要经历从无到有到盈到溢到精的过程。组织应制定相应的策略和政策，以支撑和维持这个过程。入库的，都是先进技术或成功经验的总结，应该回报以相应的奖励，以消除“教会徒弟饿死师傅”的顾虑，尤其是在库里空空如也的初始阶段。同时，除了大小之外，奖励越直观，越及时，越公开，效果越好。
既是资产，就该像银行一样，一边吸引存款，一边发放贷款，让钱活起来，以钱生钱。随着资产的日渐丰富，组织过程资产库会慢慢变成图书馆，成为员工学习并快速成长的一条通道；从中汲取的技术和经验，可以帮助员工更好地回报组织，组织便具备了让图书馆扩大、扩容的能力：这是组织、资产库、员工之间的一种良性循环。
五、结束语
如果把5000A体系建设作为一种管理改进，推荐华为的“七个坚决反对”为鉴：坚决反对完美主义，坚决反对繁琐哲学，坚决反对盲目创新，坚决反对没有全局效益提升的局部优化，坚决反对没有全局观的干部主导变革，坚决反对没有业务实践经验的人参加变革，坚决反对将没有充分论证的流程进行实用。
联系客服
