定制管理系统：员工需要在同一个工作界面完成什么？

客户来电，要求修改某个订单的收货地址。同事找到订单、核实请求、修改地址，再告诉客户处理结果。听起来是一项工作。完成它需要打开多少个系统？

规划内部管理系统时，先从这样一项工作入手。确定员工需要看到什么、可以修改什么，以及如何知道修改已生效。这比先列出一串仪表盘更能说明需求。

选一项能从头跟到尾的工作

假设有一家虚构的维修工坊，负责把修好的设备寄还给客户。客户要求改寄到另一个地址。工坊在一个系统里管理维修订单，在另一个系统里预约配送。

在这个例子里，维修订单系统保存该订单确认采用的寄回地址；配送服务保存运单预约，并确认地址是否还能修改。更新客户的一般联系信息是另一项决定。

先写清每项信息应由哪个系统保存。如果两个界面显示不同的地址，员工该相信哪条记录？由谁解决差异？把两条信息放到同一页面，并不会自动回答这些问题。

微软的模型驱动应用构建指南把数据、业务流程、应用界面和安全角色视为不同的工作部分。它讲的是 Power Apps，但提醒我们：决定界面长什么样，只是定义工作的一部分。

让每个人只处理自己负责的部分

设计工作界面之前，先列出角色、任务和允许的操作。以这家虚构工坊为例，可以这样分工：

这些只是拟议的职责，不是现成的权限规则。你的规定可能要求某些修改先获批准，或限制员工查看特定客户的记录。界面上的控件和实际接收修改的系统，都应遵守这些规定。

经理查看的概要和办事人员处理的队列，可以放在同一个应用里，同时服务于不同目的。让具体工作决定视图。

逐步检查地址更正流程

找到请求。把地址修改请求放进有人负责的队列。显示它对应的维修订单、收到的时间，以及是否已有同事处理。埋在客户历史记录里的备注，很容易迟迟得不到处理。

确认现在还能改什么。显示订单当前的寄回地址和运单最近一次已知状态。标明信息来自哪里、何时核查。如果配送信息暂时无法获取，或已过时而不足以作为依据，员工在承诺改址前就需要知道。

执行获准的修改。完成工坊要求的客户身份核查和必要审批后，有权限的同事可以提交新地址。设计中应说明这一步是更新维修订单、请求修改现有运单，还是分别执行两项操作。

等待正确的确认。维修订单中的地址保存成功，并不代表配送服务接受了修改。分别显示两个结果。如果请求还在等待答复，就保持待处理状态，并提供足够的信息，让员工向客户解释情况。

留下有用的历史记录。明确需要记录哪些事件，例如谁提出和批准更正、修改前后的值，以及配送服务的回复。确定谁能查看这些记录、如何核对。单凭一个“历史记录”标签，无法知道里面究竟记了什么。

让异常有明确去处。如果包裹已经发出、配送服务拒绝修改，或连接失败，就把未解决的请求交给指定人员或团队。说明再次尝试前应核查什么，避免因回复不明确而重复操作。

确定系统之间需要对齐什么

不同系统对订单状态或地址的理解可能不同。微软关于系统间信息转换的架构指南说明了这个问题，以及维护转换所需的工作。它介绍的是一种技术模式，并非每套管理系统都必须采用的组件。

对这家工坊来说，实际问题很简单：每个系统所说的“已修改”到底是什么意思？先约定字段、状态含义、确认方式和失败处理，再把系统连接视为完成。同一个工作界面，仍可能依赖多个系统各自完成自己的工作。

把完整流程写成需求说明

对每项准备纳入的工作，记录负责角色、起始队列、信息来源、允许的操作、确认方式、历史记录和异常负责人。既写正常流程，也写棘手情形，例如运单地址已经不能修改。

我们开发定制业务软件。带上员工需要完成的工作流程，包括目前容易卡住的环节。我们就可以围绕这些实际工作讨论可能的项目范围和条款。

关于共用管理界面的常见问题