一、什么情况下，适合写「对内业务白皮书」

白皮书支撑对内业务的核心，其实就是将业务的逻辑、操作方式、业务标准等内容，成体系地传递给相关的业务人员，使其能够在工作过程中正确运用。

判断是否适合写白皮书，可以参考业务是否具备以下属性：

涉及人员范围广

该业务涉及的部门数或人数是否较多。如果业务只涉及同一团队的三五个人，在业务并不复杂的情况下，基础sop+资料包+一对一口头对接更加适用。这种方式信息传递效率较高，且轻量化，多数情况下适合讲究「效率」和「灵活」的小团队。

如果业务涉及的人员部门较多（如横跨三四个部门，需要数十数百人操作）这种情况下，使用白皮书进行内部信息同步更加高效。它可以保证业务内容在低损耗的情况下更加稳定地传递。

业务可标准化

业务的流程、操作、结果指标等是否能够标准化。白皮书非常适合能够标准化的业务，比如产品使用流程、后台操作流程、到店服务流程、销售sop等，这些业务内容更偏向于操作执行，使用白皮书输出可以业务结果更稳定地实现。但对于难以标准化的业务而言（如涉及大量艺术设计、逻辑思辨、临场发挥的业务），白皮书并不能很好地帮助它扩散和复制。所以业务是否标可准化，也是我们需要考量的要素之一。

当然，并不是说业务一定要参与人员多、可以标准化，我们才能够去写，甚至可以说这些要素无论具备与否，白皮书都可以写。小规模业务团队可以用白皮书沉淀业务，做业务扩大的储备；需要大量个人化能力的业务，也可以用白皮书配合实操训练的模式，提升员工的能力。只是这二者对白皮书这一形式的依赖性，不如具备以上属性的业务那么高。

所以，个人推荐你在确认业务具备以上两种属性后，再行后续的撰写动作。

二、白皮书的0-1流程

白皮书的0-1流程，一般来说分为这三个大步骤：

前期准备

从0开始写一本白皮书，可能听起来像“写作类项目”，但其实它更偏向于“构筑类项目”。完成白皮书，需要的不仅仅是笔力，还得有清晰的框架、条理、各部门良好的分工协作等。这一系列的动作，我们都需要在开始撰写之前进行筹备，使后续工作能够有条不紊地展开。

开始撰写

在完成前期准备后，我们就要正式开始撰写内容了。这也是考察笔力和内部协作的核心环节。这一步结束，白皮书就成功了一半。白皮书成功的另一半，则是以下这步：

同步、追踪、迭代

以本人工作过程中的体感，大概有70%的内容沉淀，都没有发挥出相应的价值。它们并不是差在内容上，而是差在后续的环节：同步宣发、效果监测、持续维护。文档风风火火地写出来，大张旗鼓一丢，大家有没有用，用了效果怎么样，一概不知，这样的情况并不鲜见。所以写完白皮书只是开始，白皮书真正有用，还得看这一系列步骤做得如何。

接下来，我们就一起来聊聊这些步骤是如何一一完成的：

三、撰写前的准备

确立主题

首先，一定要先问自己三个问题：

1.业务的核心目的是什么？

2.业务现状如何，遇到了什么问题？

3.白皮书是写给谁看的？他们需要具备解决什么问题的能力？

部分同学在撰写文档之前，没有思考这三个问题，这样可能会给后续的工作带来风险：写着写着发现写偏了、文档的重点反复变化、核心业务动作传达不清晰……等等等等。

所以务必先思考这三个问题。当你得出互不冲突的答案，白皮书的主题就已经可以大致确立了。

预先策划

接下来，我们需要在上面三个问题的基础上，预先策划后续的落地流程。

白皮书应该包含哪些模块的内容？每一个模块由谁来写？怎么分工？

有的同学可能会说，不用分工啊，就我来写呗！我觉得一个月差不多就能搞定~

非也非也。

如果不分工，业务将面临以下问题：

一、你的认知上限，就是业务的认知上限

人人有专精，人人也都有局限性。如果所有内容均由你一人完成，你的专精可以赋能给他人，你的局限性也会“赋能”给他人。不同模块的内容，找到不同模块的专家来配合撰写，处处皆专精，业务的认知上限会更高。

二、你的精力上限，就是白皮书的完成效率上限

如果所有内容都是你来完成，项目的完成速度将会大大拖慢，你在独自做功的过程中也会更快地进入疲惫状态。分工出去，大家一起完成，更加稳定高效。

三、兄弟部门被动配合，降低宣发效率

如果由你一人撰写，直接同步给各相关部门。在自己没有参与，反而被“压”下来一份白皮书的情况下，大家的接受度都会有所折扣。如果分工交给各部门协同完成，不但能保证内容质量，更能让所有人都有参与感。这种情况下，后续大家对于白皮书的接受度会更高，极大地提升宣发效果。

好，说回正题！

在厘清以上三个问题之后，你会得到这样的一个预策划案：

业务目的

业务现状，为什么要写白皮书

白皮书内容模块

白皮书分工，需要哪些同学参与

完成周期（可以先根据业务经验自己拍一个时间，后续评审会可继续划定时间范围）

预策划案完成之后，我们并不能直接开始推进，而是要先进行下一步：

高层评审

将预策划案和老大过一下。目的有三：

1. 职场常识，涉及多个部门协作的工作，老大必须知晓；

2. 老大的认可和推动，不但会让这个项目可以开始进行，更能让各部门同学的配合更高效；

3. 避免和接下来预定的其他业务排期发生冲突，项目报上去，老大来宏观调控；

这里注意，预策划案的颗粒度个人建议不要太高。因为这波和老大沟通，主要目的是「商讨项目可做与否」，如果做得太落地，反而可能扰乱双方的聚焦点。业务的具体细节在下个环节和大家商讨敲定，会更加合理且高效。

会议评审、立项

在项目通过老大审批之后，务必组织所有白皮书项目相关人员进行一场评审立项会。

这场会议需要达到三个目的：

1. 老大做好kickoff，大家达成项目共识；

2. 完成所有人都认可的任务分配，时间确定；

3. 充分同步项目流程，在落地层面达成参与者同频；

当这三点共识达到，我们就可以正式开始后续的撰写流程啦！

四、白皮书的撰写流程

如图所示，一般来说撰写流程分为四个大步骤。

这个过程与其说考验文笔，不如说是对我们统筹、协调能力的一次大考。它的核心是大家能够及时配合，完成自己的进度。那么接下来我们就来一起看看，如何完成撰写步骤。

进度管理

先说最重要的进度管理。这里我们把进度管理分为「撰写进度的管理」和「成员情绪的管理」，在实际项目进行的过程中，这二者都相当重要。

撰写进度的管理

在分工完毕之后，各个协作部门的同学会领会自己的任务，开始撰写自己的部分。

我们一定要在撰写完毕之前持续追踪与push进度，使自己对撰写进度心中有数，也能及时对各个异常的进度做好干预。

首先，推荐用甘特图进行进度管理表的搭建与同步。这里强烈推荐使用云同步的甘特图工具（避免广告嫌疑，就不说具体的工具名字了）

有的同学习惯只用文字记录分工和时间节点，文字同步，这样不够可视化，会提升协作中的理解成本；有的同学自只在自己的本地建一张甘特图，需要同步时在工作群、周报里反复一个个版本地手动发送，其他同学就只能一张一张地下载观看。这样不但会让大家的工作文件冗杂，也可能使一些同学弄混版本，贻误进度。

所以这里一定要使用云文档进行甘特图的同步。（一个小细节，为了避免项目成员手滑，或者其他不必要的风险。云文档的修改权限一定要设置成仅自己，其他人的权限为只读）

成员情绪管理

这个是容易事先忽略，但是很影响项目推进状态的部分。

作为项目负责人，我们需要记住两点：

1.每一个参与项目的同学，都有自己的本职工作要处理。大家都很辛苦。

在与项目成员沟通时，不要用命令的，强硬的语气。大家是人，不是输入指令就埋头执行的机器。

你需要让大家感觉到你不只是一个监工，更是一个陪他们一起完成项目，一起成长的pm角色。

有以下动作可以参考：

项目群的消息第一时间回复，如果因为忙暂时没有回复，也要在群里说清楚没回复的原因。否则大家会觉得“他一个总负责人都不重视这个项目，消息半天回，我们重视干嘛？”

必要时请大家喝杯奶茶，或者一起聚个餐。当然，经费提前找老大申请一下；

在沟通、汇报等场合，多肯定大家完成的工作，让项目组同学感知到你的关心与自己的进步；

如果有同学进度跟不上，及时和他以及他的leader沟通，确定问题所在，寻找解决方案。（注意，不推荐绕过leader单独和项目成员沟通。任何沟通都要让对方的直属上级知晓。紧急项目除外）

在白皮书中加入对所有参与者的致谢，这个可以先不说，宣发了之后作为彩蛋发出去，惊喜感max！

总之，就事论事，真诚地对待每一位同学，同时尽可能提升大家的参与感与成就感！

2.我是项目的负责人，我要为项目完成度负责。

如果项目有成员反复拖延，进度迟迟赶不上，反复沟通也无效。

这种情况下，我们不能什么都不做，只是单纯地无效鼓励；也不推荐自己亲自下场去把他的活帮他干了；绝对不能上来就push，或者怒喷。

无效鼓励只会拖慢项目进度，你不是babysitter，而是要按时交付项目的人。

亲自下场帮别人干活，只会加重自己的负担，其他辛苦按时完成业务的同学也会不满。慎用，除非项目火烧眉毛。

上来就喷：绝对不能做的事情。喷不能解决任何问题，只会加剧工作配合过程中的矛盾。

这种情况下，你需要及时找到对方的leader，厘清他的工作量，寻找调和方式。必要时可以直接换人。总之，既不要纵容无下限地拖延动作，也不要和当事人产生进一步强硬的沟通。直接和其上级确定弥补方案，让项目回到正轨，才是唯一要考虑的事情。

内容撰写

接下来我们说说内容撰写。

一般来说，白皮书中在描述工作内容步骤时，我们需要尽量确保内容能够「由思路到解法」完整地传达给对方。

白皮书中较高频出现的内容有如下三类。每一类都有一些可以参考的要点和格式：

操作类

不需要动脑，一步一步跟着做的内容。

这部分的内容一定要图文并茂。每一步，点击哪个按钮，会弹出什么界面。修改了这个数据，会产生什么影响。这些内容每一句话都要搭配一张示例图，保证直观。

说明类

同样，说明类内容也需要搭配图片。如果说明的是数据，可以搭配数据的可视化效果图；如果说明的是流程结构，可以附上流程图。

QA类

在阐述问题及解决方案的时候，尽量避免直接一问一答，而是陈列出一个解析框架：

问题主干：

问题逻辑：

解决思路：

解决流程（话术参考）：

把每一个问题拆解开，不但让业务部门的同学清楚问题的表层解法，更要清晰地传达面对问题的核心解决思路。

这些内容产出标准，尽量在白皮书的立项会议上及早同步，确保各个项目成员都能写出符合质量要求的内容。

内容整合

在所有项目成员都完成自己部分的撰写之后，我们可千万不能直接复制粘贴拼起来，就当作完成版！

每个人的行文风格，叙事风格都不同。但是白皮书作为后续业务的操作指南，一定不能太“精分”，太有割裂感。我们需要对所有的内容用统一的语言和视角进行梳理整合，使白皮书内容通顺，前后统一。

审核敲定

在完成了撰写、整合之后，白皮书需要最终交付给相关部门leader及总业务老大进行审核。

这一步一定要记住：

1.务必让所有相关部门的负责人审核到位，书面确认；

2.无论其他人审核是否认真，你自己一定要从头到尾精读两遍以上，确保内容准确无误；

当最终的审核通过，我们的白皮书就彻底制作完成啦。撒花！

五、白皮书的同步、追踪、迭代

同步与宣发

白皮书完成之后，是不是我们的项目就ok了？

当然不是。产品做出来了，如果只是闲置，无人问津，依然是白忙活。

所以在白皮书产出之后，我们第一步就是要对它进行宣发，让大家把它用起来！

宣发策划

在正式开宣发之前，我们仍然要先对宣发内容进行规划。

一般来说，我们要先考虑这么几点：

宣发人：可以是你，可以是业务老大，可以是bp，或者其他业务高管（级别越高，效果越好）

宣发形式：大群通知，会议通知，集体宣讲等

宣发时间：推荐在上午十点或者下午五点，这两个时间段大家的工作节奏都比较平缓，有时间参与宣发过程。

好的，宣发策划到这里就结束了。

……NONONO！

这里我要强调一下，宣发和同步，不是仅仅发一次通知，做一次宣讲的事！

即使你请动了CEO宣讲，如果除此之外没有别的动作，白皮书还是会被业务部门快速遗忘……

所以这里我先问一下各位，你们觉得怎么样的宣发才是有用的呢？

“让大家知道我们白皮书写好了。”仅仅是知道白皮书吗？

“告诉他们，看白皮书能提高你的业务能力。可以来看看。”只是「可以」来看看？

不！

白皮书的内部宣发一定要分成两个部分：

1. 发出去

2. 推下去

发出去，即让业务相关同学知道我们有了白皮书，了解白皮书的重要性，并且知道如何去看白皮书。

推下去，是让业务同学清晰地认知到，白皮书是他们工作重要的底层指导。怎么样才能认知到呢？借力业务老大和各部门leader，持续地推进。

打一个最简单的比方：原本在工作中，业务同学遇到问题，leader可能会面对面手把手。但是有了白皮书之后，凡是里面教过的，leader一律让业务同学先去看白皮书，看不明白的再教；

所以，宣发不止要考虑如何发出去，更要提前充分和各部门leader通好气，让他们做好后续的「推下去」。

高层评审

这里就不赘述了，还是那句老话，绝大多数涉及范围广的业务动作，需要提前让老大审核，获准再落地。

宣发落地

按照预先计划的流程进行宣发。相同的逻辑，在宣发正式开始之前，务必和各关联部门及业务老大一起开一次宣发启动会，在大家充分清楚目标、意义、流程的情况下开始宣发，更加有条不紊。

效果追踪

在宣发完成后，我们需要对白皮书在各个业务部门的使用效果进行评估，以便进行后续的优化迭代。

这里我介绍几个可以用的方式：

内部问卷

可能大部分同学会觉得内部问卷根本没用。大家都是同事，怎么好意思差评，肯定都是拍彩虹屁的啦～确实如此，大部分公司内部问卷中，大家碍于同事关系，遇到类似问卷都会无脑好评支持。

但实际上，彩虹屁固然多，也一定会有一小部分同学诚实地提出建议。咱们一定要搜集好这些建议，一一仔细做确认，是个例还是普例？影响大不大？

诚然，不要看到内部问卷的高评分就觉得白皮书很成功。但是毫无疑问，内部问卷可以洗出一部分业务同学有价值的反馈。

工作抽查

不定时随机对业务同学的工作进行抽查。比如白皮书中有关于客服同学的业务内容，咱们就可以抽查白皮书推广后，客服同学的工作情况，有没有按照白皮书的内容进行操作？在遇到问题的时候，是否可以使用正确的思路和话术进行回答？

小测验

如果你觉得上面的内容都无法量化，我拿不数据结果！

那么咱们可以通过试卷来测验大家的掌握情况。

预先将白皮书中的知识点出成题目，放进题库。确保每个人的试卷都是从题库中随机抽题，并且题目和答案的顺序打乱，降低作弊因素。

我们不但可以通过分数量化学习结果，而且可以通过观察错题分布，来定位白皮书中讲得不够到位的知识点进行修改。

注意，不建议把这个测验和绩效考核挂钩，也不要强行干巴巴地push，否则会增加大家的抵触情绪。

我们可以用趣味活动的方式去做测验，比如部门专业知识大pk，平均分最高的部门每人一杯奈雪！用趣味活动调动大家的积极性，活跃工作氛围同时拿到我们想要的追踪数据，双赢～

定时会议

定时组织白皮书相关业务部门leader进行会议，相互同步白皮书的使用情况。leader的可以提供另一个白皮书的使用效果视角，发掘出更多可供优化的点。（建议刚开始两周一次会议，后续可以每月或者三个月进行一次会议）

内容迭代

在拿到了以上的追踪结果后，我们需要对结果进行分析，定位到需要修改的部分，进行进一步修改。

这个过程需要持续进行。

另，与其自己一个人分析，更推荐在白皮书的定时会议上进行。所有部门的人都在，可以及时提出问题，脑暴解法，完成分工，效率更高。

持续迭代下去，你的白皮书一定会越来越好！

最后附上完整的流程图

六、写在最后

原本只想简单讲一讲流程，没想到下笔之后就想起了过去项目的种种，进了心流，不知不觉写了这么多。篇幅很长，如果你看完了之后有任何想讨论的，欢迎私信评论。感谢阅读！

互相成就，互相成长。我是阿蛙，我们下期再见～

-END-