为知识库目录设计的时候在第二层级，第三层级设计的时候的一个详细展开的分解的思维角度。我们知道目录的设计是一套树状的结构。这个树状的结构有主干，有一级目录，二级目录，三级目录。刚才我们谈到的组织结构也好，专业职能的分工也好，可能比较适合于作为目录的一级目录设计。而作为一些特别具体的业务过程，比如说财务里面会涉及到的一些具体的业务过程，像出纳，财务里面资金的管理，整体的规划，现金的管理，报销的管理，具体的职能板块实际上都是可以落到目录职能设计的二级目录，三级目录。人力资源也一样。人力资源这个职能可能是作为一级目录，但是往下落的话可以按照职能分解落实到招聘、培训、绩效考核、人员发展，人才库建设等等一系列的职能。所以说职能和具体的业务过程可以成为目录设计的第二个层级。 还有一些专门的企业，比如说研发机构，研究院所，科研院所，他们的大量的知识主要是专业类的知识。专业类的知识实际上是可以按照知识的专业领域进行划分。比如说我们曾经服务过一家研发机构，他们的知识库目录在设计的时候更多的考虑的是专业的知识，比如说这是电学，这是光学，这是微电子，这是软件开发，这是硬件的某一个模块。把这些专业的领域细分，形成了研究院所的知识库目录结构设计。根据不同的企业业务特征到底是一个集团型企业，还是具体的生产工厂，还是说是一个研发部门？根据不同的层级，不同的业务特征在设计知识库目录的时候是可以从这些角度思考，帮助我们把这个目录库搭建得比较完
善，组织结构、专业职能和专业分工，业务的过程，业务逻辑，包括知识的一些专业领域，这些都可以成为知识库目录设计时候的一个思考维度。
总体上说，知识库目录要设计得必须好必须要符合几个原则： 第一，相互独立，完全重精。分类框架是科学的，是符合逻辑，符合人的思维习惯的。
第二，比较方便，让大家比较容易应约。 第三，稳定，不能经常变化和调整。
刚才我们讲组织结构不太适合作为知识库目录的思考方式是因为组织结构会变化，目录要相对比较稳定，不能经常调整。这个调整不管是从技术上还是从员工应用的习惯上都会引发一些问题。
还有一块要符合知识的呈现和重用的原则。通过查看知识库目录，查看整个的框架结构，管理者，领导可以从高层视角看待这个企业到底积累了哪些知识，到底哪些领域，哪些业务环节的知识非常丰富，哪些环节的知识非常少，非常欠缺，必须要进一步提升，进一步补充的，有一个高层的视角，否则从容的原则。这是在做目录设计的时候需要考虑的因素。 第二个概念是多维属性。
多维属性的核心是实现一个要求，使得我们的用户，我们的员工在目录库里面储存的大量的文档在调阅的时候非常方便，按照不同的视角，按照不同的维度能够快速的调阅，这里有一个多维
的概念。
一个维度，两个维度，企业里面一般为了帮助员工快速调阅这些知识的时候可以设计3—5个维度。当然这个维度也不能太多，如果超过8个，10个，这些文档在存储的时候要把多维的属性带上的话也会比较麻烦。所以维度有一个控制，比如说3—5个非常常用的。我们可以举几个例子来介绍一下，解释一下所谓的多维属性是什么意思。
比如说一个房地产企业大量的文档，项目型的文档全部放在知识库目录里面存储得很好。但是员工想从另外一个视角把相关的文档调阅出来。比如说我最近想看看跟别墅这种产品，跟这种物业性质相关的所有文档，我最近想看看跟经济适用房类型的物业相关的所有文档。所以我们必须为了要实现员工这样一个检索的要求，或者是调阅的要求，必须在文档设计的时候，在文档存储的时候把我们刚才谈到的经济适用房、酒店、别墅、高档住宅这些属性标注在文档上，以后在调阅的时候能够快速的调阅。所以说刚才我们讲的房地产企业产品是一个很重要的多维属性。 另外有一个企业是一个电力相关的研究院所。他们大量的知识都跟电场相关的设备有关系。所以他们就把整个设备作为一个非常重要的多维属性建立起来。建立起来之后他们的员工就可以非常方便的看，我想看一下跟所有的发电机有关的文档，跟所有变压器有关的文档。跟所有的接地网，组合电器有关的文档。都可以按照这个视角，这个维度把大量的知识调阅起来。这是多维属
性的作用。
一般来讲企业设计多维属性的时候思考的角度可能有这些。我们做一个罗列：
1、地理位置，尤其是对于一些全国性的企业。我想看全国这么多省，不同的省份相关的知识。不同得分公司，这是一个很重要的维度。
2、产品，每个企业都有产品，或者说服务，产品的类型，服务的类型可以作为一个很重要的多维属性设计的思路。我们可以通过这个多维属性了解不同产品相关的知识。
3、专业知识结构。如果说专业知识这个结构没有作为很重要的维度设计在目录里面，那么它也可以作为一个多维属性。 4、设备 5、客户 6、项目
等等，还有很多，这些根据不同的企业业务特征可以帮助我们把这些多维属性设计起来，使得员工在调阅海量知识的时候能够非常方便。还有一个维度也是非常方便，叫做企业里面的文档类型。这个文档类型，不同企业可能有所差异。但是本质上差异不大。比如说有些人想看我们公司的流程，有些人想看制度，有些人想看会议记要，想看通知，想看任命，我们就把这些文档的类型作为一个专门的维度设计起来，便于员工从不同的角度看这些知识。
像新闻、通知、制度、任命、决定、会议记要、最终报告、表单、模板、知识地图等等，这一套作为一个多维属性帮助员工在检索类似知识的时候非常的方便。
如何看待目录库设计得好坏？如何看待多维属性设计得好坏？这里有一些要求。
因为这些目录设计好了以后，多维属性设计好了以后最后是要通过软件系统实现的。如果我们从软件系统角度看的话，希望这个分类用户容易理解，系统比较稳定，不是特别复杂，比较方便。从内容这个角度来看的话，希望分类体系设计得比较好，内容方面的要求就是符合知识的分布均匀性。在每个目录，每个属性下分布的差不多，没有特别多的目录。如果这个目录做得不太好，有些目录下面的文档成千上万篇，有的目录下面的文档只有不到十个，这说明目录库设计得有点问题。
知识分布已经均匀，比较详尽，相互之间没有重复，互不交叉。 而且还有一个要求，目录和多维属性设计的时候涉及到的一些专门的术语，专业的术语应该能够让员工都能够理解。如果他不理解，他就不知道他的知识应该存在哪里。所以知识库的目录和多维属性设计好了之后需要做培训，让全员都明白这个目录是存这个知识的，那个目录是放那个类型的知识的，让大家比较容易理解。
当然有一些目录从字面上就比较容易理解，有些目录可能有些费解，需要做一些解释和说明。所以培训也很重要。
上面我们讲分类体系的时候谈到的目录和多维属性这两个概念是分开来谈的，但是实际上未来来看，由于不同的软件系统在功能实现上有所差异，在未来可能越来越多的把目录和多维属性也会存在一种合并，现在有很多软件是把目录和多维属性合并起来统一管理，都叫一套属性，叫做多维属性。目录也作为多维属性里面的某一个维度。只是说目录这个维度跟其他的属性相比存在一些差异，这个差异在于说，目录如果设计得比较完备的话，它跟其他的属性相比，最大的差异在于他能够把公司里面所有的文档，所有的知识都能够分割完毕，都能够全部包住，不会有漏项。而其他的一些多维属性，应用的一些多维属性，可能不能把公司所有的文档都包含进去。这是目录和多为属性其他维度属性相比的特点。
这是关于知识库分类框架涉及到的两个概念，以及他们在设计的时候表现出来的。