跨部门项目总在交接处断线，CRM协同空间正好把责任缝隙补上
跨部门项目总在交接处断线，CRM协同空间补上责任缝隙
一、跨部门推进难在哪
一件跨部门的事，难点很少落在专业能力上。多半落在协调的节奏上。销售希望方案尽快出来，方案人员手上还排着别的活；交付想知道客户到底确认了哪些范围，销售自己也记不全。每个人都对，事情就是推不动。
之所以难，是因为跨部门的事没有天然的负责人。部门内部的活儿有人统筹，跨出部门之后。责任就落进了缝隙里。靠开会同步能补一阵子，会一散，进度又回到各自的记忆里，下一次开会先花半小时对齐上次的结论。
真正的解法不是催得更紧，而是让这件事本身有一个大家都能看到的位置。位置一旦固定，谁做了、谁没做、卡在哪一步，就不再需要靠追问来确认。
还有一层原因容易被忽略：跨部门的事情往往没有明确的完成时点。部门内部的活儿有节点，跨出去之后就变成了尽快、抓紧这类说法。没有时点，优先级就排不出来；手上同时压着几件事的时候，最先被推迟的一定是那些说不清什么时候要交的。
要改变这一点，得先把时间点定下来。不是把每个环节都卡死，而是给关键环节一个承诺的时点。有了时点，参与者自己就知道该什么时候动手。
- ● 难点在协调的节奏，不在专业能力
- ● 靠开会补不长久，会一散就回到各自记忆
图1：多方同时推进，信息要放在同一处
二、把项目当成一个共享的空间
协同的第一个动作，是把一件事从聊天记录里搬出来。放进一个有固定位置的空间。
这个空间里至少要有四样东西：这件事的目标是什么、当前推进到哪一步、下一步由谁负责、相关的资料放在哪里。说穿了，四样齐全，一个新加入的人不需要问任何人。看一遍就能接手。
共享空间还有一个隐性作用：它把口头承诺变成了书面安排。过去在会议上说好的事，时间一长容易各自有各自的理解；写进同一个空间之后，理解的分歧会提前暴露，而不是等到交付当天才发现。
空间放在哪里也有讲究。放在项目下面，看到的是这件事本身的推进；放在客户下面，看到的是这家客户的全部往来。两种视角都有用，所以比较理想的做法是让同一件事既能从客户那里进入，也能独立查看。
搬到空间里之后，还有一个习惯要跟着调整：不要再靠私聊推进。私下里说好的事，回到公共空间里看不到，过一段时间就没人记得。习惯的养成需要一点时间，但一旦养成。协同的成本会明显下降。
- ● 目标、进度、责任人、资料，四样齐了才算空间
- ● 口头承诺落到书面上，分歧才会提前暴露
图2：订单推进的每一步，都要有人看得见
三、任务要有归属，也要有判断的节点
空间搭好之后，接下来要把事情拆成一个个任务。
拆分的关键不是拆得细，而是每个任务都要有明确的归属和一个能被判断的完成标志。「准备方案材料」这种说法就没法判断完成，改成「方案初稿已发出并收到客户回复」，完成与否一目了然。
除了完成标志，还需要设置几个判断节点。判断节点的作用是让团队在关键处停下来做一次取舍：范围要不要调整、资源要不要追加、这件事还值不值得继续。没有判断节点，项目会一路跑到资源耗尽才被发现偏了方向。
任务之间的先后关系也要写清楚。哪些必须等前面完成才能开始、哪些可以并行，如果不在系统里标明，推进的时候就要靠人反复确认。容易在等待中空转。
另外，任务的数量要控制住。一次挂在同一件事上的任务太多，参与者会分不清主次。把当前阶段真正需要的列出来，其余的放在后面。注意力才能集中。
还有一个验收上的细节：让对方在配置时使用你们自己的字段名称和阶段名称，而不是演示环境里的通用模板。往实里说，看上去只是称呼不同，其实能反映对方是否真的理解了这套业务的结构。
- ● 每个任务配一个能被判断的完成标志
- ● 关键处留出判断节点，不要一路跑到底
图3：在哪儿打开，看到的都是同一份数据
四、信息在交接处最容易断
项目推进里出问题最多的地方，是岗位与岗位之间的交接。
交接处容易断，是因为交接双方对「交出去了没有」的判断标准不一样。交的人觉得资料已经发过去就算完成。接的人觉得还没确认口径就不算。两边都没错，事情就悬在半空。
减少这类问题的办法有两个。一个是把交接动作写进流程，明确交付什么、由谁确认。另一个是让交接的过程在系统里留痕，谁在什么时候把什么交给了谁。事后可以回看。留痕不是为了追责，而是为了让下一次交接有参照。
还有一个容易被忽略的交接，是项目结束时的交接。项目收尾后，客户后续的服务、续约、复购往往会换一批人接手，如果前期的沟通记录没有完整保留。后面的人只能重新建立信任。
减少交接环节的遗漏还有一个不太被提起的办法：让双方在事情开始时就把各自的交付物写下来。事前约定比事后解释成本低得多，而且约定本身就会让双方想清楚自己到底要交什么。
交接留痕还有一个附带的好处：它让流程可以被改进。哪一类交接反复出问题，看几次记录就能看出来，然后针对性地调整，而不是笼统地要求大家注意配合。
还有一个办法可以降低交接的成本：把常见的交接场景整理成几套固定的清单。方案移交、合同移交、服务移交，各有一套固定的内容项。清单固定之后，双方不必每次重新商量交什么，只需按清单走一遍。遗漏的概率会明显下降。
清单也不是写完就固定不变。每遇到一次遗漏就补一项进去，几轮之后就基本覆盖了常见情况。这个过程本身就是团队经验的沉淀，比任何现成的模板都更贴合实际。
- ● 交接双方判断标准不一致，事情就会悬在半空
- ● 项目收尾时的交接最容易被忽略
图4：合同相关的信息，最好跟着业务走
五、怎么验一套系统的协同能力
验证协同能力，不需要等到上线之后，选型阶段就能试出来。
第一个办法是拿一条正在进行的跨部门事项，让厂商当场把它配成一条可跟踪的任务链。看看需要多少动作。实话讲，动作少、业务人员自己就能配的。说明这套能力交到了业务侧。
第二个办法是问清楚权限的边界。跨部门协同要求信息在参与方之间可见，但同时不能让所有人都看到全部内容。能不能按项目、按参与角色分别设置可见范围，这一条决定协同会不会因为顾虑而退回到私下沟通。
第三个办法是看移动端的完成度。跨部门协同里有一半以上的动作发生在离开办公室的时候，审批、确认、上传资料这些动作能不能在手机上完成。直接影响推进速度。
海软CRM在协同上的做法是把项目、任务、资料与沟通都收在同一个客户空间下，参与方按角色看到各自该看的部分，审批与提醒可以顺着办公平台流转，不必额外换一套习惯。这套安排适合需要多方参与、又不想让信息散开的场景。
还有一项可以顺手验证：项目与客户资料之间的关联。项目里的往来、合同、回款能不能挂回同一家客户，这决定了后面复盘时能不能把所有信息拼起来看。
- ● 拿真实事项当场配一条任务链，看要多少动作
- ● 权限要能按项目与角色分别设置
- ● 移动端能完成多少动作，决定推进速度
六、大家最关心的几个问题
1、问：任务拆分要多细才合适？
答：以「能有一个人负责、能有一个完成标志」为准。拆到无法指定负责人，就说明拆过了；拆完仍然要开会才能推进，就说明拆得还不够。
2、问：跨部门配合时，职责边界怎么定？
答：把每个任务的负责人写清楚，同时写明需要谁配合。责任有主次，配合有对象，模糊地带就会少很多。
3、问：项目结束后，资料要不要归档？
答：要，而且要和客户资料放在一起。归档的价值不在留档，而在后面接手的人能顺着时间轴看懂这段往来的来龙去脉。
4、问：协同功能会不会让流程变得更繁琐？
答：繁琐通常来自动作设计得太多，而不是协同本身。先按最少必要动作跑一遍，跑顺之后再考虑补充，比一开始就设计得很完备更容易落地。
5、问：参与方看到的信息要不要完全一致？
答：不必完全一致，但要保证各自看到的部分足以完成自己的任务。看得太多会带来顾虑，看得太少会拖慢判断。
