在推进工作的过程中，有效的沟通至关重要。
一、背景
最近负责公司流程再造这个项目，这个项目的背景是：为了跟上公司业务的发展，要将公司已有内部系统中的业务流程功能全部梳理和重构，解决大部分历史遗留的混乱问题并增强扩展性。系统由两个ERP系统和一个CRM系统及一些独立工具构成，包含销售、运营、市场、财务、人事、客户管理等模块。
在推进工作的过程中，不断的遭遇了大量问题并努力解决，这次主要聊一个由于系统的复杂性，影响概念设计及沟通交流的问题。由于系统本身既庞大又结构复杂，且设计时需要协调沟通极多的的部门负责人与项目干系人配合，而他们对于软件工程或组织系统的认识水平又参差不齐，就导致很难在统一的概念上进行沟通，尤其是在业务层面到开发层面的鸿沟，着实给我造成了许多困惑。
二、问题分析
仔细细考后，基于易理解性和工作流合理性提出以下几点假设原因：
与业务部门来说，更多的关注从自己视点出发的内容，甚至可能完全忽视与自己工作相关的其他部门工作流程。例如，销售人员可能根本不在意财务人员怎么审核资金到账，而只在乎完成签约销售立刻获取自己的业绩。而于此相反，财务人员就更关注，资金到账的信息一定要自己牢牢匹配确认以致牺牲时间的延迟。
抽象的概念图表达方式并不容易被所有人理解。这些图抽象的能力让我们在设计上得心应手，却让一些没经过训练的非专业人员难以接受。
业务概念与系统概念的严重脱节。例如在现实业务流程中需要业务管理人员审核的过程，在系统内部的概念却是客服审核。类似的许多功能与概念极度脱节，以至于业务人员也仅熟悉常用的小部分功能。
我自己对于系统复杂程度的低估，没能完全穷举出系统内的所有相关流程。接手这种唯一的文档就是代码，又遍布历史遗留问题的复杂系统，真的就差把自己埋坑里了。
而其中第一点问题从解决真实问题的角度适合引入系统论思考，第三点问题则正是项目立项之初就明确需要解决的问题，第四点就只剩降低我的自我效能感这一个用处了。
（这里不聊为什么选择用图的形式表达，我认为信息可视化是在制作难度和可理解性中最平衡的沟通方式。）
三、问题研究
1、图的类型
先来熟悉一下惯用的几种作图方式，流程图、泳道图、时序图、用例图、原型图，不过下文的图并没有按照严谨的UML方式作图（现在连开发都不用严格的UML了吧？），仅作参考使用。好，开始一个个分析优缺点，仔细研究问题。
流程图
优点：逻辑、概念清晰，且很容易做颗粒度把控。
缺点：更多表达系统的行为，较为忽视人员角色与系统的互动，实际制图中更多是偏向开发侧表达，对跨部门沟通不够友好；表达数据、状态等信息时略显力不从心，因为如果引入其他形式表示会导致图表过于复杂，都用同一种形式展示又很难区分。
泳道图
优点：较为完整描述流程，相当于在普通流程图中加入角色，展示所有涉及模块的交互；能直观感受特定泳道内的所有行为。
缺点：系统高于复杂的时候，图极大极复杂，可读性很差；且信息展示方式不够直观，与常规认知习惯不匹配。
用例图
优点：好处是很容易理解，尤其是在遍历单角色任务时很实用，且容易按照颗粒度划分层次。
缺点：在概念设计上容易忽视整体，流程完整性难以直观感受。除了对单个角色做MECE分析的时候比较有用，其余用处不大，毕竟测试同学会自己处理用例。
原型图
优点：这应该是所有人都最喜欢看的图，好处很多，既直观，又能很好的展示功能，还可以做交互标记。按颗粒度可分低保证高保真，低保证便于沟通，高保真方便用户测试。
缺点：原型图已经很贴近实际开发的阶段了，而不是所有项目（甚至不建议任何项目）都是直接到原型阶段的，前期的思考和论证至关重要，原型只不过是之前所有阶段的结果总结，反复修改原型极易导致严重的项目进度管理问题，所以直达原型的设计流程是很成问题的。
2、表达元素分析
角色，表示场景下涉及的角色
行为，表示场景下作出的动作
数据，表示场景下信息数据的流动
状态，表示场景下引起的状态变化
界面，表示场景下位于什么界面及其样式
3、设计阶段
先细分几个设计阶段，方便明确在各个阶段的目标以选择需要的方案。
业务概念阶段，此阶段主要关注在现实业务场景下，需要做什么，和业务流程规范的设计
功能概念阶段，此阶段主要关注产品如何满足业务概念的要求，需要设计哪些功能，以及各个功能模块之间如何组织协调
交互原型阶段，此阶段主要关注产品具体实现的展示方案，用户如何操作，界面如何反馈
上文内容不用于商业目的，如涉及知识产权问题，请权利人联系博为峰小编(021-64471599-8017)，我们将立即处理。
