如果您读过我前一篇文章，那您知道，我们现有的部门就有一定的模块化思想，但是我们目前的部门职能划分主要存在两个方面的问题，部门的职能划分的界限不明晰、划分清晰的职能在后期运作时发生转移导致再次不清晰。这主要是因为我们在部门的职能划分时缺乏理论指导。

要详细讨论模块化的概念以及具有哪些性质，我们不妨到最早使用模块化概念的软件开发领域看看模块化如何诞生以及具体含义。对于软件开发领域来说，模块化早已是老掉牙的词汇，甚至在其后提出了更多更新颖的概念。但是在上世纪60年代以前，计算机刚刚投入实际使用，软件的规模比较小，软件开发往往是“私人小作坊”的方式，缺乏工程化的思想。到了60年代中期，软件的规模越来越大，复杂程度越来越高，软件开发领域出现了诸如，软件开发进度难以预测、软件开发成本难以控制、软件产品质量无法保证、软件产品难以维护、软件缺少适当的文档资料等问题，为此在1968年，北大西洋公约组织在联邦德国的国际学术会议上将软件开发爆发的众多问题称之为软件危机，为了解决问题，在1968、1969年连续召开了两次会议，提出了软件工程的概念，而模块化就是解决软件危机的重要方法之一。

会议上，对软件危机的原因进行了分析：

1. 软件开发过分依靠程序设计人员在过程中的技巧和创造性，加剧了产品的个性化。

2. 由于软件开发规模越来越大，大型软件开发项目需要组织一定的人力共同完成，而大多数软件开发人员又缺乏管理方面的经验，各类人员的信息交流不及时、不准确，所以软件开发人员不能有效地、独立自主地处理大型软件开发的全部关系和各个分支，因此容易产生疏漏。

3. 软件开发不仅仅是在规模上快速地发展扩大，而且其复杂性也急剧地增加，软件开发的特殊性和人类智力的局限性，导致人们无力处理“复杂问题”。

回到我们的工业领域，我们仔细思考，我们的企业面临的问题和当初软件开发领域的问题差不多：

1. 我们企业的运作过分依靠管理人员在管理中的个人技巧，各部门完成任务缺乏标准控制。

2. 企业的规模对于个人来说过于庞大复杂，因为部门还有人员之间信息交流不及时、不准确，各层级的管理人员不能快速地有效地理解整个公司的全部关系和各个分支。

这两大问题依然能使用模块化的思想来解决，在接下来解释模块化概念和属性前，为描述的方便，我将各部门所作的工作定义为服务，服务是接受一定的工作资料，完成一定必要的工作处理后产生工作成果这个整个流程的统称，负责完成工作的部门定义为服务提供者，委托其工作的部门定义为服务使用者。

从概念上来说，模块化是指解决一个复杂问题时自顶向下逐层把系统划分为若干模块的过程，有多种属性，分别反映其内部特性。每个模块完成一个特定的子功能，所有的模块按我们设想的生产流程组合起来，成为一个整体，完成整个生产系统所要求的功能。我们的部门从原始粗放的职能划分到设想的模块化应当具有以下几种基本属性：服务定义、服务描述、工作流程、服务状态。其中职能描述、工作状态与职能定义反映部门的对外展示的表象，工作流程反映内部工作细节。

1. 服务定义：我们在提到生产质量的时候，往往指的是生产部门的生产质量，但我认为管理部门的工作成果同样是产品，也会影响生产运作，就应当像生产部门一样具有生产质量管理，制定产品质量标准，职能定义这一属性则包含了完成服务所必须的资料、资料应满足的标准、服务完成后反馈的成果、成果的质量标准、预计耗费时间等，这就解决了各部门完成任务缺乏标准控制的问题。

2. 服务描述：向服务使用者说明服务所完成的任务，用作规范职能范围，同时也能简化新员工，新管理人员入职快速地进入角色，理解整个公司的全部关系和各个分支的问题，再搭配上服务定义属性简化了各部门之间信息交流不及时、不准确等问题。

3. 工作流程：在我看来工作流程则应该灵活些，根据部门的工作性质而定，有些工作需要规定详细固定的流程，有些工作的流程经常变化，如果进行详细规定，反而起不到提高效率的效果，这就落入形式主义的陷阱中。

4. 服务状态：服务状态用于监督工作的属性。(在后续的文章中详细说明)

也就是说，在进行了模块化改造后的部门的身上，应该具备以上四大属性，这四大属性配合我在后续的文章中将提出的两个新部门(服务路由部门，日志部门)起到工作质量监督、业务流程优化、为管理人员提供企业管理数据等效果。

模块化的思想如今并不仅在软件领域，引用国际经济学会主席、斯坦福大学经济学教授青木昌彦所说——“当今，模块化的概念不仅是经济学、经营学专家之间最热门的话题之一，而且它还有可能彻底改变现存产业、企业的结构，具有十分强大的冲击力。”