在这篇文章中，笔者就BI项目文档的制作提一些自己的建议，以供各位读者参考。

　　一、事无大小，项目文档都需要一一记录

　　不少用户在书写项目文档时，就捡重要的内容来写。一些细枝末节的内容就忽略不计了。笔者认为，这种做法是不合适的。因为从整个BI项目来看，事无小事。有时候一个小的细节如果没有做好的话，就会给BI项目带来致命的影响。举一个简单的例子。如新建一个报表，其中可能含有比较敏感的信息。企业一般对此都有比较严格的权限限制。如果在BI中实现这个报表时，只考虑到了报表本身的内容，而没有考虑其数据的访问权限，那么就可能会给企业带来比较大的损失。

　　为此笔者认认为，对于BI项目来说，事无大小，都必须在项目文档中进行记录。如对于基础数据整理格式的要求、每个字段的最大长度限制等等，都必须有明确的说明。以后如果关键用户离职，那么新接手的用户仍然可以凭借这个项目文档来顺利的接替其工作。那么用户也需要文，项目文档到底该详细到什么样的程度呢？笔者认为，一个简单的判断标准就是，在项目文档中应该包含用户对于BI系统的所有操作说明包括相关的注意事项。这个项目文档在后续的工作中，就可以作为一份教科书来供用户使用。

　　二、失败是成功之母，要重视失败经验的分析与总结

　　笔者在实际工作中还发现，不少用户在做项目文档时，喜欢将一些顺利实施的内容记录在内。而将一些失败的内容不反映在项目文档中。笔者认为这种做法也是不合适的。如现在某个用户在实施BI项目时犯了一个错误，已经交了一次学费。可是项目管理员并不能够保证，以后用户（如有新员工接替原用户的工作）并不会犯类似的或者相同的错误。如果在项目文档中不将以前犯的错误记录下来，那么企业就有可能多次在同一个地方摔倒，多次为同一个问题教学费。显然这是很多企业都无法忍受的。总之，项目文档要能够起到一个警示的作用。具体的来说，需要注意以下内容。

　　1、需要注意，项目组成员在解决某个需求时，可能有多种解决方案。最终用户根据自己企业的实际情况，选择了一种合适的方案。在项目文档书写时，不应该只反映最后选择的实施方案。笔者认为应该将以前考虑到的多种解决方案都一一的列出来。然后再在后面说明为什么选用了某种解决方案、不选择其他解决发方案。因为BI项目是一个持续改进的过程。随着工作的深入，或者员工的调动，用户可能会对原有的解决方案产生疑问。此时查看这个项目文档，估计可以打消他们的顾虑。或者说，为用户后续作业的优化，节省时间。

　　2、对于无法实现的需求，也要一一反映在项目文档中。在需求调研中，项目团队会收集到很多需求。但是在实际工作中，BI系统并不是能够百分之百的解决所有的问题。其实在实际工作中，大家都有这样的感受。有个问题提出来之后，如果第一次没有解决，那么用户在后续的时间内仍然会不断的提出，直到他们找更好的替代方案。

　　如果没有相关的书面记录，那么每当用户提出一次需求，项目管理员员就需要从头开始对这个需求进行调研分析。最终仍然得出否定的答案。显然这会浪费大家的时间与精力。另外一种情况是，随着系统像深入化推进，原先无法实现的需求可能会在后续可以实现。针对这种情况也需要有相关的说明记录。因为在后续考虑这个需求时，前期的需求调研、需求分析等相关的数据能够为后续的工作所用。

　　三、利用图形来说话

　　在文字记录中，配一些插图有时候更加能够说明问题。不过可惜的是，很多项目管理员并没有养成这个好习惯。他们在描述问题时，更加喜欢使用文字，而不是图形。可是现在遇到的问题是，某个需求或者流程，如果利用文字的话，即使使用一千个字，可能也无法将问题描述清楚。但是如果使用图形的话，那么这个问题就会变得简单。有时候一幅图话可能比千言万语还有用。

　　笔者在日常工作中，总是提醒用户，要在项目文档中配有插图或者其他更能过说明问题的附件，如表格等等。一般来说，在说明一下情况下以插图代替文字，或者插图与文字交叉来描述能够起到不错的效果。

　　1、跟流程相关的内容。如从基础数据的整理、到导入到BI系统中有一个操作的规范。其中包括用户数据的整理、数据导入前的核对、数据导入、导入后的检验等多个环节。如果要将这个环节讲解清楚，比较费力。但是如果以流程图的形式来反映这个操作环节，并配相关的文字说明，就能够比较容易将这个流程说清楚。

　　2、跟操作失误相关的问题。在BI系统使用过程中，会因为用户的误操作而产生一些不利的影响。对于这些误操作或者相关的结果最好能够通过截图的形式反映在项目文档中。这能够更加直观的反映问题的本质，从而有利于用户减少犯同类错误的几率。另外值得一提的是，如果有针对这个错误的预防措施，那么最好能够将预防措施、以及采取这个预防措施所取得的效果等内容也添加上去。

　　四、多种解决方案要如实的一一记录

　　在需求实现的过程当中，可能有多种解决方案，企业用户可以根据自身的特点来选择其中的一种。同理，用户在使用过程中为了避免某种错误，也会有多个预防措施。当然最终可能只需要选择一个预防措施就能够避免错误重复发生。这就关系到一对多的问题。但是最后实施的则是一对一。现在用户需要考虑的问题时，先在用户选择的是A这种解决方案。可能在当时的背景下，选择这个解决方案是比较合适的。但是随着系统使用的深入，或者环境的变化，用户能够保证A这个方案还符合现有的应用环境吗？是否其他的方案更加适合企业呢？

　　如果在制作项目文档时，能够将原有的解决方案与利害关系都记录下来。那么在遇到这种情况时，只需要找出原有的纪录，然后对照现在的实际情况进行分析即可。即企业项目组成员可以独立的解决这问题。而不需要再去寻找实施顾问来重新思考这需求。这可以节省企业不必要的项目开支。

　　笔者最后需要强调的一点是，在制作项目文档时，是为了说明问题，而不是为了摆设。故在制作时要尽量的反映实际内容。或者说，不要再项目文档中掩饰自己的过错。从长远来看，这么做是得不偿失的。