关于业务编程的另一本教科书。
边境处理最好自动化。 听起来很老套，但是这样的建议远非总是得到执行。
当流程越过边界而不使用自动化系统时，情况仍然很常见。 在许多企业中，都在使用纸质便笺，应用程序，订单等。 当然，这不仅适用于部门之间的界限-从事同一服务的员工还犯有纸条。
如果一名员工以书面形式将流程移交给另一名员工，则跟踪此任务的状态非常困难。 失去这种任务的基本的，普遍的方法是用语“干净的衣服”来表达。 如果员工将这些文件堆放在桌面上很好，那么应用程序的数量至少是可见的。 从理论上讲，甚至可以找到该堆栈中的特定纸张，并确定该纸张在此队列中已经存在了多长时间。
通过电子邮件传输过程的常用方法。 las，这种方法也不是很好。 从某种意义上说，这甚至比一堆纸还要糟糕，因为 电子邮件客户端没有足够的功能来管理信件作为任务。 一个人只会有很多字母，这几乎不可能确定队列的状态。
关于口头转移任务，不值得一提。 正如他们所说，飞入一只耳朵，飞入另一只耳朵。
与边界知识有关的还有另一个不愉快的时刻。 当一个人以书面，口头或电子邮件的方式将任务移交给另一人时，任务携带者现在属于第二个人。 从形式，道德和技术角度来看，第一个不再能够深入研究第二个任务。 通过一定的从属结构，您当然可以更深入地研究一堆文件，但是阅读别人的电子邮件已经太多了。 仍然可能以某种方式找出一个或多个应用程序，流程实例的状态，但是几乎不可能在“边界”评估队列的一般状态。
因此，我们需要一个自动化的边境控制系统。 它有几个重要要求。
第一个要求是系统必须清楚地标识其中的队列和任务。 即使在发达的自动化系统中，也不总是可能的。 如果您要求某人在程序中显示其任务的轮换，他将能够演示一些内容-他将显示文档列表，应用一些过滤器和排序，并且您会获得任务列表。 如果您要求程序员，他将这样做，不仅不在文档列表中，而且很可能通过查询数据来实现。
这里的关键词是“如果你要的话”。 如果你不问？ 对于业务程序员而言，这个简单的问题（“您不问什么？”）可以作为正确识别边界的明确标准。 如果您是外部观察员，而无需询问员工，就可以看到他的任务清单，那么就满足了第一个要求-确定了队列。
有了这个标准的简单性，您会发现大多数自动化系统都不符合它。 即使在Tsar Gorokh和办公室备忘录的帮助下，仅在员工的脑海中仍能了解队列，仍然保留在自动化系统中。 这种情况是熟悉的，并且看起来很正常，因为“每个人都有它”。 但是，如果您作为业务程序员希望改进此过程，则必须进行队列识别。
第二个要求是必须在任务之前分解队列，即 到需要可理解的动作的简单实体。 碰巧似乎已识别出队列，但是其中混有来自不同进程的任务。 在这种情况下，队列的可控性和可控性是一个严重的问题。
标准很简单：如果您在不询问员工的情况下就每个特定任务告诉您需要做什么，那么队列就可以正确分解。 如果答案是“必须理解”，或“必须以某种方式解决”，或“尚未看过”，则分解是不好的。 系统和过程继续取决于员工。
第三个要求是应明确完成任务的优先级。 原理与先前的标准相同。 如果您从侧面看队列，看到任务的顺序，那么优先级就清楚了。 如果您或该过程的使用者需要每天询问员工有关优先级的信息，或每天重置这些优先级，则队列管理不善。
第四个要求是任务在队列中花费的时间，即 应用“冰山”原理 。 通常花费的时间与执行优先级相关，但是也存在冲突。
例如，优先级系统基于双重排序-首先是重要性，然后是任务日期。 在这种情况下，完成大量重要任务，将永远不会变得不重要。 如果该过程使某些任务永恒的不履行被认为是正常的，那么就可以了。 但是，通常，在流处理过程中，完成所有任务很重要。
因此，必须监视优先级和花费在队列中的时间的相互影响。 例如，指定了优先级系统后，将加权系数添加到队列中所花费的时间，以便使任务以一定的值浮动到表面，而不考虑其重要性。
因此，条件很简单：如果您看到每个任务在队列中都有时间，那么就可以满足要求。 一个典型的错误是认为知道并查看问题陈述的日期就足够了，因为在这种情况下，可以很容易地计算出在队列中花费的时间。 自动化真的很容易做到。 但是头脑中的计算要困难得多，而且没有一个理智的员工可以做到这一点。 因此，在工作中不会考虑花费在队列中的时间。
第五个要求无论多么陈旧，但必须知道任务的执行者。 如果承包商的选择由自动算法来调节，那么应该理解执行该算法的时刻。
只要任务没有执行者，就不会解决。 承包商不必分配给每个特定任务-足以了解将已识别队列的所有任务的解决方案分配给特定人员。
如果承包商在过程中未指定特定人员，而是指定职位或部门，则承包商的选择通常会导致队列空闲。 在这种情况下，建议执行者的选择作为一项单独的任务完成，经理或某个调度员应执行该任务。 尽管承包商的选择不是一项任务，而是一项特权，但此时队列会不断陷入困境。
标准很简单：从线的侧面看，您必须确切地知道谁将执行任务。
第六项要求来自更高层次的业务编程：系统必须能够查看和比较来自不同流程的队列。 在一般情况下，永远不会满足这样的要求，因此我们只能谈论合规程度。
通常，问题在于不同的队列，任务和流程是不同的系统实体，具有不相交的属性集。 一个队列中有一个流程实例，但另一个队列中没有。 一个任务有生产日期，而另一个没有。 等等
鉴于实体的多样性，通常没有人能够解决“在一个窗口中”控制所有队列的任务-既不是在自动化系统中，也不是在手动控制中。 因此，队列状态（每个周期的瞬时状态和度量标准）仍然是一个谜，这降低了管理和分析的效率。
可以部分帮助的是过程控制系统，该系统将各种主要文档“字符串化”为单个实体。 这就是过程卡，常见任务和寻址实体的显示方式。
但是，对于业务程序员而言，这种方法不是很适合。
首先，流程的应用通常会导致自动化的复杂化-与其说是开发周期，不如说是随后的变更。 具有卡，执行者，动作和条件的过程本身就是自动化的对象，具有随之而来的所有后果-需要维护，调试，协调等。
其次，通常由于“一对多”冲突而无法得出过程的真实情况。 大多数过程图系统希望一次运行一个对象，即使该对象是多个。
例如，执行购买应用程序的过程。 如果您绘制了此过程的端到端图，那么结果是同一应用程序从头到尾运行。 根据流程图判断，同一供应商必须作为流程实例的一部分分别与每个应用程序一起工作。
实际上，供应商根本不参与端到端过程。 他有自己的卡，入口处有一系列的应用程序。 此外，每天-数量不同（有时是空的）。 从第一个实例执行特定的应用程序后，管理返回到单个过程。
这样的过程只能使用嵌套过程来绘制，通常会成功，但是却失去了算法的简单性和清晰度-它变得技术性强，程序员可以理解，但不适合在职人员和管理人员。
第三，这些过程容易出现官僚主义-他们试图使它们成为“钢筋混凝土”，进行协调，印刷并将其搁置。 这种方法与快速自动化的原理相矛盾，因此不适用于业务编程。 具体的处理过程，尤其是在调试期间，与打印程序代码相同。
并且，第四，用于绘图过程的机制的开发人员仅在程序员逻辑的指导下，不提供队列管理工具。 因此，在移动过程中分析边界上的所有线，将它们相互比较是行不通的。 您仍然必须发明自己的工具。
绘制“钢筋混凝土”过程的方法可以用作辅助方法，不会有太大危害。 或者，可以在项目结束时使用它，以保留配置的过程。 直到下一个项目。
但是，不要忘了第三点-官僚化的趋势。 如果在您看来您可以保留该系统一段时间，那么其余的员工和管理人员则持有相反的意见：不要触摸有效的方法。 您创建，调试和实施的系统将开始抵抗您。
当系统具有可以“附加”到正在进行的流程并在队列中构建任务的实体时，最好使用“自动任务”或类似的原理。 该原理本身将在以后考虑。
一个用于管理边界处的队列的实体首先提供一个单一的坐标系-同一单元中所有流程的度量。 任何过程都可以以相同的规模进行评估，包括即时评估和回顾评估。
即时评估可以在例如公共过程控制面板中实现。 不是在传统的一般过程图中，如果不滚动就无法在一个屏幕上看到它，而是使用简单的列表形式，即使没有数字，也使用彩色显示屏（如交通信号灯）。 这将产生两列的列表：过程和状态。
该选项更加有趣-不是进程列表，而是问题点列表。 在这种情况下，重点是自动任务，它是特定过程的特定节点，与生命无疑具有可比性。 例如，“律师的合同协议”。 列出所有要点，显示其状态并对其进行排序就足够了，以便最有问题的要点显示在顶部。
尽管看起来很简单和明显，但对所有过程进行这样的即时评估却极为罕见。 现在您明白了为什么。
由于大多数系统根本不包含必要的数据，因此追溯队列分析的发生率甚至更低。 只有在充分利用Iceberg原理的情况下，不仅存储瞬时状态时间，而且还存储其历史记录，此类数据才可用。
如您所见，通常，自动执行边界控制没有什么复杂的事情。 重要的是不要使用“钢筋混凝土”工艺人为地制造困难，而忽略快速自动化的原理。 现在，您已经知道在自动化过程的边界状态时需要使用的方法和标准。