在成为应用开发经理之后，我所学到的最重要的一项技能是维护组织的列表。我所维护的（虽然不是正式的）一个列表是我的“专家”列表，包括在某一领域我可以寻求帮助的主题专家的姓名地址录。
制作和维护这个列表费了我很多时间，但是当我遇到关键问题需要及时的答案或者需要主题专家的投入的时候，这个东西就成了无价之宝。维护这样一个列表非常地困难，因为职员改变角色的频率一般比我需要他们帮助的频率高。然而在分析我应该怎样以一种更加正式的方式维护这个列表的时候，我发现了社交网络分析（SNA）。
SNA 映射和度量个人、组和其它实体（定义为节点）之间的关系。通过分析节点间相互作用的程度，我们可以决定信息流或知识流的路径。
例如，John 是一位项目经理，而 Martha、Tom 和 Bill 是 Oracle DBA。当 John 有一个与 IT 相关的疑问的时候，他请教 Tom。当 Tom需要帮助的时候，它请教 Martha。当有人问 Bill 问题而 Bill 又不知道答案时，他也向 Martha 寻求帮助。
如果我们要映射这些关系，那么我们就可以在 John 和 Tom 之间画一条线，在Tom 和 Martha 之间画一条线，在 Bill 和 Martha 之间画一条线。如果我们假设 Martha 能够为请教她的人提供正确答案，那么我们可以假设 Martha 是真正的主题专家。
现在我们假设 John 遇到一个网络问题然后找 Tom 帮忙。Tom 找网络专家 Brenda 帮忙，因为她认为 Brenda 是解决棘手网络问题的最好人选。另外几个网络专家出于同样的原因联系Brenda 请求帮助。映射这些关系可以知道 Brenda 是一位网络方面的主题专家。
新的映射还会得出更多有趣的事实：虽然 Tom 不能回答 John 的问题，但是他能够“代理”或者帮助 John 找到他需要的信息。以这种方式，Tom 看起来提供了价值——不是作为 DBA，而是作为信息通道。
通过映射组织内部的个人之间的日常相互关系（也是所谓的组织网络分析的过程），你可以快速地看到出现在社交相互作用中的模式。有很多连接都终止于主题专家。社交代理（比如说 Tom）表现为几个映射组之间的一个连接点。有内部连接的节点可以确定哪些职员需要额外的培训，可能还可以确定出系统内哪些专家的需求量比较小。
SNA 确定了社交关系的三个属性：度、闭合状态和中间状态。度表示一个节点具有的连接的个数。Martha 和 Brenda 的度最高。连接的距离或者跳段（hop）数表示特定的信息，也就所谓的闭合状态。看一下这个例子，John 所能得到的信息要比 Tom 多。Tom 也在两组节点（DBA 和网络）之间，因此其中间状态的值比较高。
另外一种使用这样一个映射的方式是确定组织内部的知识点。组织内部的知识点可以通过确定每个节点所提供的信息来确定。例如，我们假设 Martha 在一个极富竞争力的组织谋得了一个职位。快速地浏览（从社交映射派生而来的）知识映射可以知道 Martha 是一个关键的损失而且要想得到她需要费一番力气。从知识映射还可以确定出你的组织是否有其他人可以担任她的角色。
你可以直观地知道哪个人的连接状态好，然后就可以寻求他作为合作者，还可以确定出谁是某一领域的专家。通过在组织内部开始社交网络并经常地对其进行映射，那么你可以得到一个直观的认识。这样组织内的每个人都有一个最新的专家列表，而且这个专家列表来自真实数据。
