企业应用的基本活动
企业应用虽然品类繁多，但是万变不离其宗，它们所完成的基本活动却没有那么庞杂，而是数量有限的。我们可以将各种企业应用要完成的使命抽象为以下五种基本活动要素:
1)数据的采集(Data Collection)
2)数据的传输(Data Transfer)
3)计算(Computation)
4)数据的呈现(Data Presentation)
5)控制(Control)
每一个基本活动所包含的要素非常清晰，它可以帮助我们快速厘清一些企业需求，并找到设计实现的重点。设计企业应用的过程就是将纷繁复杂的客户需求与这五个基本活动匹配起来的过程。当需求过于繁杂或者不清晰的时候，可以思考一下用户实质上想要完成的基本活动是哪些。应用设计者可以边梳理需求，边列举这些基本活动。在最终投入产品架构和交互设计的时候，这些基本活动要素就能够起到检查清单的作用，确保没有丢失重要细节，也避免了不必要的过度设计。
数据的采集
第一类应用基本活动就是数据的采集。比如 ERP 系统需要录入订单，CRM 系统需要采集客户资料和记录销售行为数据，项目管理应用需要获得任务信息和资源信息等。这些数据可能是已经存在于其他系统中的信息，也可能需要用户录入。
在企业应用中，数据采集的手段大概包括由表单录入(格式化数据)，通过 API 或者 Webhook 等接口获得，通过文件批量获得，以及通过影像、声音等多媒体渠道获得。数据采集的过程也可能不是一次性的，而是通过多个流程将一条数据记录逐步完整化;数据的获得方式可能是按照条目逐条获得的，也可能是整批获得的，还有可能是通过一个连续不断的数据流(例如日志)获得的。
如果你发现用户需求中包含了数据采集的基本活动，那么可以通过以下问题清单来帮助启发设计思路，这对于将企业应用的需求落地到设计有很好的启发作用。
• 谁需要通过什么形式，在什么时候，采集什么数据?
• 什么样的数据采集是有效的?
• 数据采集发生的频度如何?
• 有多少人将会采集这个数据?
• 数据采集工作可以通过软件自动进行吗?
• 数据采集中最大的挑战是什么?
• 数据采集容易出错吗?最容易发生的错误形式是什么?
• 最高效率的采集手段是什么?
• 成本最高的采集形式是什么?
• 采集的数据将会有哪些用途?
• 如果通过移动设备采集数据会有什么效率和质量上的风险?
数据采集活动中的这些问题能够帮助我们设计出可用性更强的企业产品。例如，在第 3 章中提到的募款管理软件，当了解到募款经理的募款形式经常是和第三方合作的活动时，我们就会将募款记录的采集功能设计为以批量导入为主的交互形式;同时会更加灵活地设计募款记录的数据结构，以便容纳来自不同渠道的自定义属性。
最经典的数据采集形式当属条形码的读取了。零售业在客户结账的时候当然需要采集顾客购买的商品列表信息，在这个场景下，时间就是金钱，一位收银员每分钟需要输入三十多个商品的信息，才能保证客户的排队时间不至于太长。所以为商品设计条形码并利用光学输入设备快速读取信息，就是在这个需求场景下被催生出来的。
数据的传输
在云计算时代，数据传输并非指数据从物理空间的A点传到B点，而是指数据的查看权和编辑权在不同用户之间的转移，因为数据的物理转移已经没有那么重要了。最典型的数据传输应用就是即时通信:用户A将文字、语音、图片等数据传输给用户B或者更多的用户。
在数据传输活动中，基本的形式包括有明确收件方的转移和无明确收件方的转移。有明确收件方的转移在企业应用中可以覆盖数据的提交审核、转让所有人、流程节点的移动等环节;无明确收件方的转移可以分为特定范畴的公开和完全的公开，也就是社交软件常说的“分享”。
面对数据传输的基本活动，我们也可以通过一系列的提问来帮助启发设计:
• 什么形式的数据，在什么条件下，由谁传输给谁?
• 传输前后的数据有什么差异?
• 传输特定数据的同时是否要传输关联数据?
• 在传输数据的同时，还需要对数据进行什么改变?
• 传输要求实时吗?可以异步传输吗?
• 传输的结果是否要通告发件人?
• 传输的结果是否要通知收件人?
• 传输的对象是特定的用户，还是特定的用户范围?还是不设任何范围?
• 传输的数据是否需要加密?
• 传输给不同收件人的数据是否有不同的形式?
• 数据传输是逐条进行，还是整批进行?数据的规模有多大?
CRM 应用是数据传输密集的应用。企业通过某个渠道采集潜在客户的信息，通过营销活动和用户的反馈不断更新，直到将信息变成销售活动的线索。在销售管理中，线索被分配给销售代表，销售代表和客户进行沟通，如果需要，线索还可能被转移给其他的销售代表。在成功销售后，客户的购买信息被流转到财务部门，他们负责接收账款和开具发票。客户支付成功的信息还将依次传递给财务、运营和业务人员。与此类似，管理供应链的采购管理、企业的生产计划管理等应用，也都有大量结构化信息的传输。
在数据传输活动中，管理好数据传输的整合性、防止丢失和不完整、建立合理的通知体系、校验传输的正确性、在传输过程中对数据属性做准确的修订，以及保留完整的数据传输日志，是让这类应用更加健壮的必要工作。
计算
计算是让企业应用价值升华的活动。它基于输入的数据，通过某种算法给出用户期望的计算结果。这个计算过程理应能够帮助用户节省时间或减少差错，甚至替代人工计算工作。企业应用中的数据采集和传输活动本质上都是为了给计算活动创造条件，如果不能给用户提供有价值的计算服务，用户所享受到的就只有记录和共享服务，这会大大降低用户的使用黏性。
计算活动有很多具体的应用案例。比如，在制造业的生产排程应用能够基于已经采集的员工信息、机器设备和工单来自动给出一个周期的生产计划，它综合考虑了机器设备的资源成本、生产的工艺逻辑次序、员工的班次安排、工单交付的优先级要求。这个过程如果让人来计算，难度是很大的，而且工单需求和员工资源是容易变化的因素，一旦有任何更改，需要立即对生产计划全部重排，依靠人工计算是不 现实的。
再举一个影院收益管理系统(Yield Management System)的例子，系统需要影院的历史客流信息、影片的票房预测信息和天气预报信息来预测未来的潜在客流量，实现动态的排片和定价，从而利用价格杠杆来实现最大化的收益。此类计算在产品价值速朽的行业中将起到至关重要的优化收益作用，所以，在酒店、航空等行业中应用得更加广泛。
除了这两个比较典型的例子，其他常见的企业应用计算活动还包括对数据的搜索(筛选)、排序、分类、推荐和一般意义上的统计。在机器学习技术开始普及后，这些计算活动的实现算法有了革命性的变化，但它解决的计算目标本身并没有变化。例如，在知识管理应用中，基于机器学习的算法可以更准确地帮助分类和推荐，但这两个活动一直以来就存在于相关应用中。当然，机器学习所带来的性能和准确度提升也催生了一些新的企业应用，比如自动的内容摘要、智能的非正常状态报告、语音和图像的识别和处理等。举两个更具体的例子:在客户服务应用中，针对顾客的自然语言提问，提供高相关度的回答或内容列表已经是一个日益普及的应用;在营销和销售自动化应用中，已经有很多产品开始基于客户属性和行为记录来智能评估客户价值，识别销售机会，甚至在部分环节实现自动化的客户沟通。
在研究计算活动时，可以通过以下问题来启发设计思路：
• 计算活动的实质是什么?是分类、排序、统计还是推荐?
• 计算所需要的输入信息是什么?
• 计算过程需要人为干预吗?还是完全自动进行的?
• 这个自动的计算过程能够给用户带来什么价值?可以从经济角度进行衡量吗?
• 在计算过程中，是否可以通过人为干预提高计算的质量?
• 计算的结果如何呈现?
• 计算的结果需要存储吗?连续存储的计算结果能否对未来的计算带来帮助?
• 计算要求的准确度有多高?它可以被其他计算方法的结果校验吗?校验结果能否继续优化未来的计算结果?
• 计算的过程和机制是否要向用户公开?
• 需要在多短的时间内完成计算?
• 如何获得计算所需的软件技术?需要多高的成本?
设计企业应用的计算活动需要一定的领域知识和计算机软件知识，产品设计人员如果无法掌握这些专有知识，则需要通过团队合作来完成任务。比如，金融应用中的利息和费用的计算、财务应用中的财务指标分析、建筑和制造业中的估价计算、服装制造业中的开料计算等都离不开专有知识。当涉及复杂的检索和推荐需求时，计算活动的实现则离不开优异算法的帮助。这时候，产品设计人员应该掌握下面两个原则。
• 通过和专业人员的沟通将需求理解和记录准确，并通过一个机制来确认需求描述的正确性。
• 在面向开发者沟通时，厘清需求和实现的边界，永远描述需求本身，而不是描述算法解决方案。
虽然拥有跨界知识是一件难得的事情，但是在复杂企业应用中，软件产品设计人员几乎不可能同时掌握行业专有知识和计算机算法。如果把边界搞含糊了，反而容易损害应用最后交付的质量。总结起来，产品设计人员应该努力向需求方确认需求，努力向开发方阐述需求。
数据的呈现
基于用户直接采集的数据和计算的结果，将信息呈现给用户的过程就是数据呈现的基本活动，它几乎贯穿于企业应用的全部环节。数据呈现活动大致可以分为两类任务，一类是为用户构筑合理的数据视图(View)，另一类是为量化数据构筑可视化界面(Visualization)， 如下图所示。
数据视图是企业应用设计中的焦点问题。它依据不同用户和不同场景的需要，将有价值的数据抽取出来，用一个合理的格式呈现给用户。比较基础的数据呈现方式形如 Excel 的工作表和数据透视表，可以用来加强数据呈现效果的形式有很多，读者可以参阅本书的第 8 章。数据可视化则是为了把数值用图形方法来呈现，让用户快速识别要点、非正常情况、分布或趋势。
数据呈现在有些企业应用中扮演着更加重要的角色，因为此类应用的核心目标就是为了有效地为用户呈现数据。其中商业智能(BI)应用当然属于最密集的门类。除此以外，有些行业的运营管理中需要用独特的视图来提升操作准确度和效率，这时就有必要为数据呈现活动设计专有视图。例如，在餐饮业的点餐系统中，一般允许用户专门绘制与店堂桌位排布一致的平面图，将桌次和状态以可视化的方式显示在店堂平面图上(如下图所示)，这样，服务员就可以非常直观地了解目前的桌位忙闲状态。饭店的前厅人员只要扫视一眼屏幕就能够快速知道现在是否有六人位，而不需要进行复杂的检索操作，这大大 提高了饭店的运营效率。
在 IBM 和苹果公司为航空业设计的 iOS 应用中，每个环节都根据用户需求进行了专有的视图设计(如下图所示)，比如乘务组查看航班乘客舱单、机务查看航班状态、公司运营查看机场信息等环节都有完全不同的视图。
数据呈现在金融行业应用中的重要性更突出。各种金融产品的报价和交易系统需要为不同类型的交易者提供数据翔实的信息面板，用什么版式来组织报价信息、公司信息和交易信息，抽取哪些信息来呈现，正是这些应用系统需要考虑的核心问题。
数据呈现活动要考虑的一些设计问题如下:
• 针对不同用户和场景，需要呈现哪些信息?这些用户之间的数据呈现需求有哪些是一致的?
• 在这些数据中，哪些是主要和常用的，哪些是次要和不常用的?应该如何安排数据的主次关系?
• 需要实时反映数据的变化吗?
• 数据的呈现篇幅是怎样的?如果过大，怎样缩减?
• 原始的数据是什么格式?在呈现时需要进行可视化吗?
• 最佳的可视化形式是什么?
• 典型用户需要多长时间才能从数据呈现结果中找到自己所需要的信息?这个速度能够满足用户的需要吗?
• 用户在获得呈现的数据时，需要介入操作吗?怎样减少这些操作?
• 用户获得呈现的数据后，下一步最可能进行的操作是什么?
• 用户获得呈现的数据后是否需要打印?
• 用户会在什么样的设备上获得呈现数据?如果是移动设备，数据的显示友好吗?
数据活动的实现和交互界面设计息息相关，所以来自此类活动的设计实现更多依靠的是前端界面。产品设计者掌握的与数据呈现相关的设计范式越丰富，就越容易满足用户的需求。广泛学习各个行业和场景的产品界面设计最佳实践是提升此能力的最好办法。
同时，在企业应用中，单独完成数据呈现的场景并不多见，很多密集的数据呈现活动都连接着进一步的用户输入活动。成功的呈现设计也要能够引导用户进入下一步操作界面，让用户不必费力地思考。这个从呈现到继续操作的流程本身也应该在用户需求调研中明确，否则很容易导致用户操作的断层。我们用得不爽的很多企业应用都带有这个通病——某个操作带来了一些结果，当需要连续操作的时候，不得不通过导航回到另一个起点再次开始，缺少流畅的用户体验。比如 一个CRM应用常常需要查看客户公司的关联联系人信息，当这些数据被呈现后，用户可能需要立刻与联系人进行沟通，那么，在所呈现数据的旁边加入沟通操作的动作入口就是必要的。
控制
控制活动是企业应用中最难抽象，也是最具价值的要素，它带来的直接成果就是“自动化”。我们前面讲到的数据采集、传输、呈现都是由用户直接进行的操作;计算活动帮助我们减少了人工劳动，提高了准确度，并把计算结果提供给用户;而控制活动能够帮助用户实现无须人员参与的自动运行。是否含有围绕自动化的控制设计是衡量企业应用价值的标准之一。
在企业应用中，需要实现自动控制的场景有很多，比如在比较简单的费用控制应用中，需要根据费用的类型和金额分发给不同的审批节点;在项目管理中，需要根据延期任务是否在关键路径上决定是否要向项目和任务成员发出警报。在更加专业的 IT 管理应用中，自动化的需求更加强烈，比如测试中的自动化测试，运维中的自动部署和流量分发。
软件的自动化控制设计和实现都不容易，需要高度抽象的数据结构设计和质量可靠的代码，它从具体的场景出发，但又必须从具体细节抽离出来，通过一个通用的抽象框架来支持所有的具体场景。在种类繁多的企业应用中，很少在具体应用内部设计流程控制方案，而且，很多自动控制的需求会横跨多个应用之间的数据，所以，控制活动经常出现在专门的工作流平台上，商业流程管理(BPM)门类因此而产生。
尽管如此，很多垂直类的企业应用产品和企业的定制开发应用也都需要内部的自动化解决方案。在销售、营销、生产等应用领域，也都有自己的自动化模块。比如营销自动化就是一个基于客户属性和活动变更而自动触发营销活动的应用系统。在面对流程控制和自动化需求时，到底是基于具体的应用直接设计控制模块，还是整合通用的商业流程管理应用，这取决于流程自动化在这个应用中的价值比重，以及自动化需求是否集中在某些场景上。而且，通过开放 API，这两种解决方案也可以并行存在。一般而言，垂直应用的控制活动设计得比较简单，包含初始化的预设流程，增加用户开箱即用的能力。
我们可以举一些更加具体的例子来说明控制活动在企业应用中的价值。
例如，一个营销应用希望持续地对即将流失的用户进行干预，通过 E-mail 或者短信推送产品新特性，那么就需要有一个控制活动持续监控所有用户集，搜寻在过去 N 天内没有使用、而在 N 天前还在使用的用户，然后根据他们的特征和属性，个性化地推送不同内容的E-mail，这样的推送可能要持续三次，但是只要用户再次开始使用就立刻终止。这个看似简单的应用需求实际上就需要一个要素完善的控制引擎，包括触发器(Trigger)、行动(Action)、流程分支判断(Judge)和宏观条件控制(Macro Control)等模块。这个通用的设计能够保证营销自动化引擎可以服务多元化的触发条件和行动内容。
除了这个封闭的垂直应用例子，还有很多企业的流程需求需要在多个 IT 系统之间建立桥梁。比如，在收到客户的E-mail后，系统需要分析这个 E-mail 的发件人在 CRM 系统中的记录，从而决定是记录在销售管理系统中，还是为现有客户增加一个客服支持工单。这个控制场景横跨了通信、CRM和客户支持三个应用。在美国市场出现的 Zapier就是一个通用的流程引擎平台，它能够帮助用户在多个应用之间建立从触发器到行动的自动化程序，这个程序被称为 zap。
要设计好一个控制活动，需要明确数据流程的起点和终点。为了实现自动化，流程的起点需要依赖某一个逻辑条件的判断，一旦为真，就立刻启动流程(有时候这个逻辑条件就是到达预定时间);在流程执行的过程中还会存在基于不同条件的分支，有的分支执行完会回到主流程，有的分支则在满足一个条件后终止。当流程按照预定的逻辑往下执行的时候，通常会发生一系列的预定义动作，这些动作可能全部自动完成，也可能在执行时需要用户的参与。高级的流程控制还叠加了更加复杂的逻辑层次，比如满足特定条件就立刻终止流程，或者利用本流程的数据采集和输出开始执行另一个流程，甚至利用流程产生的数据来修订流程本身。
为了设计好复杂的控制活动，在设计过程中可以考虑这些问题：
• 这个自动控制流程替代的人工流程涉及哪些用户和数据?
• 这个流程中涉及的人是确定的用户，还是只是一类角色?
• 这个流程使用的频度如何?
• 流程是完全自动的，还是中途需要用户介入的?如果需要用户介入，用户需要输入哪些数据?
• 这个流程在执行过程中一旦发生意外，会产生什么后果?是否需要另一个监控服务来保证流程执行的准确性?
• 这个流程的复杂度如何?谁能够通晓这个流程的具体内容?
• 是否需要为用户建立可视化的流程编辑器?
• 流程是否需要经常变更?
• 流程是否需要经常新增?
• 是否有过多的流程被积累下来，从而需要归档?
• 流程应该按照什么维度分类才比较易于管理?
• 流程中的数据和文档是仅仅服务这个流程，还是需要在其他应用中同步使用?
• 这个流程是否需要连接不同应用中的数据?应该怎样实现整合?
设计控制活动是一项颇具挑战的设计工作。当面临具体设计任务时，可以尝试拆解成熟的商业流程管理产品，理解它们是怎样抽象数据和流程的，还可以将具体的控制要求通过标准流程图绘制出来，从具体要求中进行总结提炼。下图就是营销自动化应用 HubSpot 允许用户自己创建的工作流，它就是直接通过可视化的流程图来体现的。图中激活的If/then branch就是一个流程条件判断节点。
小结
设计企业应用是一项复杂度十分高的工作。如果直接从具体细节出发，初学者的上手速度会非常慢，设计时往往顾此失彼。面对复杂，最好的学习办法就是回归简单，找到复杂工作背后的基本要素，循序渐进地掌握。无论你要设计的对象是一个大型的企业应用产品，还是一组改善效率的企业内部工具，它们的背后都是由基本的活动组成的。为了建立有序的设计思维，可以通过这些基本活动的关联案例激发灵感。
这些基本活动就包括本章逐个介绍的数据采集、数据传输、计算、数据呈现和控制。每一个企业应用设计项目都可能包含这些基本活动，但不同的应用偏重的活动不同，它们所偏重的活动便是软件产生使用价值的主要源泉。理解企业应用的基本活动，帮助我们将应用设计的目标和用户的目标保持一致，如果用户需要软件帮助采集数据，我们就会专注地解析这个活动的背景和要求;如果用户需要传输数据，我们就会厘清传输的数据对象和参与的用户。这个活动组合也是我们设计应用的需求检查列表，帮我们找到重点，并且不忽略任何细节。
上文节选自《现代企业应用设计指南》（作者/明道创始人任向晖），点击即可购买
