别再错了，数字化转型与数据和应用程序无关，而与流程有关

不久前，我的同事们表示有兴趣使用我公司的数字业务流程平台来构建一个应用程序，以管理他们正在考虑做的筹款活动的赞助商。当他们通过远程网络聊天向我展示初步尝试成果时，我被两件事情震惊到了:

• 大量的字段。

• 在他们的工作流程中只有很少的几个步骤。我指出了这一点，问他们为什么会有额外的字段来记录谁批准了什么以及何时批准了什么，许多额外的多行文本字段，以及许多标记为“状态”的字段。他们回答说，他们需要知道步骤是否已经完成，是谁做的，每一步都发生了什么，等等。

我感到既困惑又好笑，回答说：“你是知道每个流程实例都有一个内置的审计跟踪，对吧？工作流的当前状态已经给了你想要跟踪的状态？内置的注释维护了一个线程，每个人的免费注释记录都带有时间戳？”

还不止这些。对于那些似乎超出了范围的数据，还有额外的列。当我问“你真的需要这个字段吗？它似乎与赞助没有任何关系”时，他们回答说：“我想不是，但我通常会在其他应用程序中为一个组织收集这些数据，而赞助商就是组织。”

有三件事情变得显而易见了：

1. 他们工作得太辛苦了，得让应用程序对平台已经提供的东西负责。

2. 结果，他们要求用户更加努力地工作。

3. 他们可能还有连他们自己都没有想到的数据需求，但由于他们在考虑使用数据流程之前对数据进行了建模，因此我们暂时还无法发现这一点。我的同事们并不愚蠢（过去不是蠢，现在也不是蠢）。恰恰相反。 但是他们长期以来一直以某种方式构建应用程序，以至于换其他方式会感到不自然。

这是“工具法则”在起作用，就像一个拿着锤子的孩子认为一切都是钉子一样。

业务流程解决方案通常是怎么构建的

以下的方式太常见了：

1. 创建一个数据模型。

2. 构建一些表单来编辑这些数据。

3. 创建一些触发自动化脚本/流程/zaps/方法来响应数据更改。换句话说，业务流程解决方案和任何其他应用程序一样。如果我们回顾过去几十年的业务应用程序，其中大多数都是围绕着数据管理展开的。如何处理这些数据是系统之外的事情，通常由管理部门的集体负责人来完成。

为什么要从数据开始，这是个问题

最明显的问题是它本末倒置了。想想看……

1. 在对流程本身建模之前，你如何知道需要哪些数据呢?

2. 人们不编辑数据，而是执行任务。表单应该能适用于用户被要求执行的操作。

3. 你如何知道该活动确实会以你所期望的方式被触发呢？就此而言，你怎么知道这是正确的活动呢？不管怎么说，这种偏见是真实存在的；我们中有多少人（如果不是大多数人的话）都接受过这样的教育。事实上，许多业务问题的核心就是数据管理问题。但还有很多不是；它们是流程问题，以数据为中心的方法并不能很好地解决它们。

它应该如何发生

很长一段时间以来，我们将应用程序分为多个层（通常至少三层）。有一个表示层负责用户界面，一个数据层负责访问和存储数据，还有一个逻辑层位于它们之间，决定向用户显示什么以及应该读取/存储哪些数据。它有助于重用，有助于支持利用相同逻辑和数据的多个 UI 选项。它有助于让 UI 专家、数据库管理员等承担项目，而不是每个项目都需要有全栈开发人员。

问题是，很多人倾向于从数据层开始，然后从数据层开始构建。相反，如果我们从逻辑层开始呢？事实上，如果我们在进入逻辑层之前，先从管理所有这三层的大图出发，会怎么样呢？它看起来是这样的：

1. 确定我们想要的结果是什么。

2. 找出实现这一结果所需的步骤。

3. 评估每个步骤需要参与的人员和方式。

4. 查看每个步骤将使用哪些数据以及由谁使用。有时候他们是需要检查数据。其他时候他们需要提供数据。

5. 创建表单和报告，将任务和结果展示给需要它们的人。这几乎与常规方式背道而驰，但这是构建成功流程解决方案的方式。公平地说，一个从数据模型开始的人可能已经在头脑中完成了前三个步骤，除了表模式和表单布局之外，他不必费心写下任何东西。这是可以理解的，但也很危险。

为什么“数据优先”思维不适合

首先，数据优先的方式不会检查（更不用说质疑）流程本身；它立即开始自动化活动。如果流程不理想，甚至无效怎么办呢？

我们经常对流程进行建模，以记录它们，与利益相关方一起验证它们，并将其传授给其他人——最重要的是，改进它们。在太多的公司里，他们所做的事情以及他们为什么这样做是含蓄的，没有很好地沟通，并且就其真正含义引发了大量的相互竞争的观点。

在尝试自动化任何任务之前，你需要先处理流程。不这样做的话，就像是用起重机而不是铲子挖洞，但却没有考虑这些洞是否挖在了正确的位置上（或者根本不应该挖）。

光考虑节省时间和金钱是不够的。自动化一个流程（不仅仅是它的活动）记录它，使它具有可教性和可伸缩性，并有助于大大地减少或消除错误（引人注目的错误可能是流程自动化的主要催化剂）。它还能使流程更易于审核和监控，并且有助于更容易地弄清楚如何改进你所看到的流程......

改进是必须的；如果说在流程自动化方面有一件事情是可以期待的，那就是更改。从一开始就完美是不可能的。 异常会被忽略。假设会被省略。可以自动化的步骤仍然是手动的。这还不错，顺便说一句，持续的改进允许早期的不完美。即使今天一切都很完美了，需求也会随着时间而改变。流程自动化的座右铭应该始终是“发布、审查、修改、重复”。

高级用户经常犯类似的错误

高级用户，或者公民开发人员，如果你愿意的话，也会遭遇“我拥有一个锤子，所以一切都是钉子”的问题。在他们的案例中，他们首先考虑的通常是他们想要查看的表单以及他们可能需要收集的数据。

对于许多（如果不是大多数）高级用户来说，表单就是数据（而不是进入其他地方获取数据的窗口）。尽管如此，他们很少会在一开始时就花一点时间来思考为什么表单会首先存在，以及我们将用它做什么。直到解决方案开发周期的后期，才会考虑该表单应该发生什么。

当我们做的时候，首先应是流程自动化，其次是活动自动化

流程逻辑会考虑流程决策，比如将请求路由到哪里、应该获取哪些信息以做出决策、如果请求被批准/拒绝会发生什么，等等。例如，处理休假时间请求的流程类似于“向员工经理发送提出批准或拒绝的请求。确保经理知道员工是否已节省了足够的假期来满足请求的时间。如果经理批准，则从用户节省的假期中扣除该时间，并让所有人都知道他将在这段时间内离开。”。

这就是我们应该做的。还有怎么做的问题。活动自动化，与流程自动化相对。比如：

• 通过使用特定的服务帐户调用特定的 API 以访问保存休假余额的人力资源业务线应用程序来检查休假余额。

• 计算请求中的小时数，忽略周末和节假日。

• 根据所请求的小时数来评估可用余额。

• 使用 Microsoft Graph API 访问 Microsoft 365 中的用户和团队日历，同样使用特定的详细信息。

• 格式化请求以添加或更新日历项，并使用正确的凭据进行正确的 REST 调用以执行更新。

• 使用 Trello 短信网关向管理员发送 SMS 请求。流程逻辑和活动逻辑都很重要。但是数据优先的思维方式，我们中的许多人对每个业务问题都带有的偏见，几乎都要求我们首先解决活动逻辑。这将是一个错误。

如果你从活动开始，那么在应用程序快完成之前你无法对其进行测试。用户必须等到一切都完成。幸运的是，在这段时间内，情况没有太大的改变，但如果发生了改变，你可能只是把工作浪费在了不再合适的活动上。

但是，如果你从流程开始，你就可以让用户进行快速测试。即使最初的步骤仍然是手动的，这个流程也可以自动化。任务得到分配和监控。通知会发出。步骤不再被遗忘，错误也会越来越少。

现在，当用户尝试整个流程逻辑时，你可以自动化活动，在活动准备就绪时将其折叠到整个解决方案中。用户和利益相关方看到了一些即时的结果和稳定的改进，而不是为他们不确定是否合适的东西等待很长时间。

相反，从流程的框架开始。一份大纲。甚至是一份清单。即使这些步骤仍然是手动的，这个流程也可以更快地得到管理和自动化。早在你能够自动化每个步骤之前，你就能够跟踪正在进行的工作的状态，确保不会遗漏步骤，减少错误，并在事后审核几乎所有内容。

事实上，大多数航空业的飞机维修都是这样工作的；即使许多步骤仍然是手动的，流程也是自动化的。在引入术前检查清单之后，手术室的“意外结果”开始减少了。

当然，在时间允许的情况下，各个步骤也可以而且通常也应该实现自动化。但时间就是一切，如果你从一开始就只考虑如何连接到数据以及如何自动化手动活动，那么你就没有抓住要点。

流程优先的方法对更改更友好

如果你首先设计流程，并通过手动步骤尽早开始测试，那么你将获得可以用于更好地自动化活动的信息。如果你从数据建模开始，你就不一定会拥有这些信息。早期的航向修正并没有那么困难。

特别是当工作从数据建模和应用程序集成开始，并且在这些步骤上投入了大量的时间时，这些组件很可能在以后被视为约束。更改会被认为是代价高昂的。由于它们是首先完成的，所以整个应用程序被认为是很难更改的。

流程驱动的解决方案可以保持这样的观念前置：条件将会更改，应用程序将需要适应它们。我们实际上应该希望它以这种的方式工作，因为当用户和业务利益相关方需要审查、批评和编辑时，我们可以从他们那里得到更好的信息。它每次都能胜过抽象的想象。

流程驱动的 UI 也更有意义

用户考虑的不是维护数据——他们考虑的是执行任务。我们给他们的申请应该是有目的的，以适应真实的用户故事。

当你打开一个表单时，你有一项工作要做。该表单应该提供你需要了解的信息，并收集你需要提供的信息。然后它就应该消失了。

虽然你可能只是想浏览一条记录，但通常有一个原因。如果你说你只想知道某人的电话号码，我明白了。但我也知道，如果你这样做，我们可能会记录下你要打的电话，让你记下发生了什么，这样我们就有了你下次打电话的记录。事实上，这就是公司投资客户关系管理技术的原因。

更重要的是，显示什么信息，哪些字段是只读的，哪些是必需的，等等？这因任务和用户而异。表单或任何用户体验都应该适应用户当前的需求，而不是他们将要接触的数据。

表单可以获取和发布数据，但表单是用于任务的。活动，它们代表动词，而不是名词。是方法，而不是对象。

流程是思考这个问题的一个好方法，也是构建它的一个好方法。

有时，数据管理解决方案仍然有意义

这并不意味着每个应用程序基本上都是流程应用程序。数据优先的方法绝对可以最好地满足许多业务需求。例如，任何涉及商业智能的东西。很多特殊的客户关系管理都可以通过这种方式进行。在某些案例管理场景中，如果没有两个案例彼此相似，那么最好将数据提供给参与者，然后让他们自己处理。

在这种情况下，没有流程可以自动化。它太特殊，太特定于情况了，甚至看不到模式，更不用说尝试建模和重复它们了。

在这种情况下，我们在构建解决方案时所能做的最好的事情就是找出如何最好地呈现用户可能需要的数据（这正是我的同事在构建筹款应用程序时所做的）的方式。

如果我们擅长这类工作，我们就会与他们保持联系，寻找任何新兴的可重复流程，这些流程将会成为自动化的良好候选项。

结论

形式应该遵循功能。数据和 UI 应该遵循流程。并且应该在适当的时间部署适当的工具、技术和专业知识，以便按照这种方式构建解决方案。

组织和团队最好记住，当涉及到流程自动化时，这一切都与流程相关。正确使用工作流逻辑，数据活动和展示就会自然而然地随之而来。

作者介绍：

Mike Fitzmaurice 是 WEBCON 的首席布道师兼北美副总裁，他拥有超过 25 年的产品、咨询、布道、工程和 IT 管理经验，在工作流/业务流程自动化、公民开发、低代码/无代码解决方案平台和策略方面拥有丰富的经验。他在微软工作了十年，为 SharePoint 产品和技术创建了技术产品管理以及开发人员布道。

原文链接：

https://www.infoq.com/articles/data-application-process/