除了你说的那些,我认为岗位知识地图最重要的是在岗位工作中他需要别人输入什么信息\知识(从那里来);自己能输出什么信息\知识(到那里去);自己又能沉淀出什么知识;

因为一个岗位的工作是企业各个流程中组成部分,所谓"流程管道,知识活水",岗位就是接口,保证水流畅通的接口;还是小水库,是不断积累知识的源泉.

乱弹几句,供参考!

试着戴上UML业务建模的有色眼镜来看一下这个地图吧.

岗位是一个业务系统定义的内部动作者结点.这和KM实践者说的"接口"说法是一致的.

用面向的概念来说,岗位是业务人员的类型定义,在UML业务建模中,岗位会建模为业务系统内部的工作者(work)的定义.即:具体的业务人员是业务对象(Object),而岗位则是这种对象的"类"(Class);

在面向对象中,定义一个类,需要定义这个类的很多信息.用楼主的说法就是要画一张岗位的知识地图.面向对象的知识表达,只是提供了一种特定的坐标系来画这个地图.

首先,我们来看看,面向对象方法如何定义"类".

最基本的是属性和方法.

类的属性规定这种类型的对象所具备的性状特征(如玫瑰花的花瓣颜色是其本身的性状特征),以及与外部对象的关联投射在这种类型上的特征,比如:"门牌号"作为"住所"类型的一个特征,是住所和街道的关系投射到住所身上的特征.

类的方法规定这种类型的对象所具备的行为能力特征(如玫瑰花能开放,能用来表达爱情等),正是由于类同时结合了性状特征行为能力特征,而且其行为能力特征和性状特征存在相互的依赖性,使得"类"成为了连接静态结构和动态行为的枢纽.这是比结构化方法的,要么只能把实体定义为静态数据结构的结点,要么只能把实体定义为联系输入和输出的处理结点的模式是一大突破.

现实中的业务人员,更象一个对象,是信息和处理的有机结合,而不是割裂出来的要么是一个信息体,要么是一个处理模块.这就是面向对象知识表达方法和结构化方法表达的不同之处.

有了"属性"和"方法"这两个基本的维度,把岗位作为类来定义,不仅仅可以表达岗位是组织结构中的一个静态结构的实体元素,而且还是能在组织业务流程的运作中使用自身能力,调动友类能力的动态过程元素.

所以,从UML业务建模的观点看,岗位知识地图的基本参照系如下:

1.岗位上的人员应该具备怎样的属性(性别,年龄,学历.....).

2.岗位上的人员应该具备怎样的行为能力(方法)(工作能力1,工作能力2,工作能力3....);

从一个面向对象的系统来说,得到类的定义是远远不够的,最重要的是,要说明各种类的对象通过建立怎样的协作关系,来对系统外提出的服务请求做出响应.这就是面向对象的程序部分.

在面向对象的业务模型中,也需要建立响应的面向对象的业务程序,只有在业务程序中,我们才能检验设计的业务对象的所有属性和能力是否都能用上,在什么时候用上的.这些信息,应该会出现在组织的业务流程的定义中.

从对象的角度来看,和业务流程相关的信息除了对象的方法定义之外,还可以有:

1.对象的事件接口(消息接口):对象会响应哪些消息?对于岗位来说,就是岗位职责中定义的必须对哪些种类的业务事件做出反应和处理.

2.对象的状态转移关系:对象在生命周期中会处于多少种不同的状态下,对象从一种状态迁移到另一种状态下的条件是什么?对应岗位,就是对岗位人员的绩效评估和等级晋升的标准.

3.对象所实现的接口类型:这里的"接口"有特殊的含义,一个接口类型定义一组相关的处理能力,这组处理能力有固定的名称和外部约束条件,但可以由多种类型用不同的内部处理机制来实现.对于岗位来说,接口就是岗位员工可以根据需要兼任的其他岗位或所有岗位共同的部分职能的集合,这对应中小企业"一专多能"的岗位设置是非常适应的.

其实，业务知识地图可以建多深的问题同时也带来一个新问题，就是这个地图还可以建多广。

我觉得两个方面：1、理论上讲，知识地图的广度和深度都是我们要关心的东西，但是里面还有最核心，最基础的，也就是基本胜任这个岗位需要什么样的知识，应该如何管理这些知识，并如何发展的提升，或说方向在哪里；

2、资源是有限的，我们不可能招到全才的人，我们也不可能投入太多的资源把人都发展成全能的人，因此需要根据人的优势来确定有不同的发展方向。

是的

理解范围、细化过程；

逐渐丰满！

目前我司正在请美世咨询开展人力资源咨询项目，其中部分即是部门职责、岗位职责（其实也就是部门和岗位知识地图），感觉专业公司的确不同，目前正在美世指导下进行jobmapping的整理。

回过头来再看看，岗位知识管理的作用：

1、让新人更快的熟悉业务；

2、让同样的事情再次发生时有样可学；

3、让类似的问题发生时能有借鉴；

    现在只能提出一些目标，我想目标清楚了，再去规划岗位知识管理的内容以及原则，可能就会比较容易了。

要多深能做多深，看你想要什么，当然，越细越有价值

不太认同求道的看法。

并非越细越有价值。无过之，无不及，才是适中。

是的，关键还是需要在目前的企业中达到了哪个层面，事实上应该来讲是没有最好的，而是随着企业的发展或者变动，随着配套的知识体系跟进上来才能真正辅助到。

这也是很多做知识管理的一个难点，需要对目前的一个分析，并根据公司的发展前景来进行具体工作的展开。

所以对于一开始的知识管理，简单反而是件好事，起码可以逐渐应用起来，也就是知识管理本身就是一个长期的过程，而不仅仅是一个短期的项目

做知识地图，别忘记做员工知识掌握的评价方法。在岗位的设计中也要明确提出，否则知识地图也是空的。

另外，要注重应用，将知识地图建设一个初稿之后，要开展如何应用的探讨或者说是设计。从另外一个角度讲，知识地图的设计要“动态”化，掌握什么知识就可以进行基本的操作和承担基本的职责，然后在实践和工作中，掌握深入的知识。

既然是刚起步KM的企业，不建议从建立岗位知识地图开始。国内大多数企业的岗位职责本身就描述不清楚，在这样的基础之上建立知识地图效果不会好，而且很容易被员工拿来说事，如既然我的岗位需要这些知识，企业是否应该提供更多的培训等，同时一旦效果不好，知识管理的推进就会受到质疑，影响整个KM实施。

个人建议可从流程角度梳理知识地图，即找一、二个经常应用的但又容易出问题的流程，分析流程中会用到哪些知识，再整理出相应的知识地图，好处可以解决企业的一些实际问题，另一方面提高这些流程的执行力，容易产生效果和价值，容易得到管理者的支持。

关键是先评价一下企业目前大部份人员的素质状况和发展力战略，并非越全、越细才好,适可现而止，重点体现一定的牵引性，和持续提高的过程。

相当同意叶的建议！

其实知识地图从字面理解就是一种地图，可以按图索骥，方便查找知识，通过多种纬度查找知识。

具体做多深要和企业的实际发展阶段相结合，才能相得益彰！

岗位的知识地图可以做成岗位的信息地图、岗位能力素质地图、岗位的文挡参考地图。。。等。最终什么样才是真正有价值的岗位知识地图？具体应该怎么样调研？下个月就要给客户做岗位的知识地图了，心理还是很虚以前的案例总觉得最后结果和之前预想的岗位知识梳理有差距。岗位的知识地图要是梳理成信息知识的输入输出外加知识参考的话，那样企业自己就能完成了。

我不太同意叶的观点。 

我认为岗位知识地图应该是在岗位设立之初就需要设定的。

不能因为怕员工拿事说事就不实施了。

既然员工拿事来说，就证明这其中存在问题，而作为企业的管理者不应该规避这些敏感的问题。

应该以问题为导向，通过对问题的分析得出知识地图建立的错误之处。

当然岗位知识地图是不可能一次性到位的，是叠代式研究的过程。

我认为新成立的公司可以根据公司的性质，公司的战略定位，公司的客户，员工素质。

找咨询公司根据类似企业的实际经验设定基本的岗位知识地图。

然后在日后的工作中，对以前制定的地图进行完善和修改。

我的信仰是，遇到问题就要解决，不管是直接了当的解决还是曲线式的救国，但是逃避就不对。

毕竟遇到问题不完全是坏事情：）

大凡涉及到尺度拿捏的問題﹐都不存在絕對的對錯好壞﹐僅有適合與不適合的區分
崗位知識地圖﹐先保証"必要條件"﹐再不斷進步改善去滿足"充分條件"
至于何為必要﹐何為充分﹐這又要放到具體的公司環境中動態掌握了
關乎到員工素質﹐企業規模﹐管理及制度成熟度...

当然,岗位是建立在流程之上的,梳理岗位首先要梳理好流程.岗位容易被拿来说事情,其根本原因还是流程不清.