每个人都知道什么是冰山-漂浮在海洋中的一大块冰。 每个人都记得冰山出了什么问题-冰山只有一小部分可见，它在水面之上，其余的则隐藏了。 剩下的还有多少，没人知道。
自动化系统中的数据也存在类似情况。
我们通常会看到数据本身。 文件，例如送货或收据发票，转移，付款等。 目录-术语，交易对手，单位。 我们看到了普通任务和处理任务。 我们看到了残留物-库存多少商品，谁欠我们钱，我们有多少赤字等等。
任何数据，单独地或组合地，都形成某种状态。 例如，我们的仓库在任何时候都处于某种状态。 我们这么说-仓库的状态。 或应收款或应付款的状态，或任务的状态，或流程的状态。
我们非常有能力在自动化系统和生活中即时评估病情。 估计，逃跑了，忘了。
然后，一段时间后，我们再次遇到相同的数据或情况。 我们再次对状态进行即时评估-我们说“一切都很好”或“一切都不好”。 第二，第三，一百二十五次重复此操作。
如果我们将情况评估为紧急情况，则可能会以某种方式进行纠正。 如果没有呢？ 是的，情况不是很好，但是看来您可以活下去。 这通常在业务会议上发生-有人提出问题，告诉情况，进行评估。 每个人都吟，或者拍手说话……什么？ 通常，他们会忘记。 直到下一次，直到别人关注。
每次放任消极情况时，都是因为我们第一次看到这种情况。 当然，有人记得-哦，它已经发生了，我不记得了，就像一个月前，甚至六个月。 他们戳记记忆力太强，无法保持沉默-让情况像婴儿一样干净。
为什么会这样呢？ 负面情况信息中缺少什么？ 有一个即时评估，相当高质量且详尽。 如何继续使用“这里的一切都不好”这一短语，使她以新的色彩玩耍并变得更加有见识？
继续这句话很简单：“这里一切都不好，而且时间长了。” 状态的时间或持续时间是做出适当决策所需的信息。
在生活中，每个人都明白这一点。 让我举几个例子。
“我没有足够的钱”-立即评估，需要进行手术干预。 “我一年没有钱了”-哇，我们这里有一个系统性问题，我们需要认真思考并改变生活中的某些事情。
“有些东西伤了我的腿”-好吧，你永远不知道，他可能已经服役了，或者天气影响了关节炎。 “我的腿已经疼了六个月了”-立即去诊所。
“一个孩子带来了演绎”-做得好，现在是时候了，保持平衡需要演习。 “一个孩子整个季度只能赚两分。”-噢，白痴是未成年人，您在那儿做什么，明天我要去上学，您的班主任的电话号码在哪里。
在业务系统中类似。
“客户欠我们一百万”-好吧，付清您所欠的款项。 “客户现在欠我们六个月一百万美元”-您的母亲，您在哪里看？
“赤字声明中有五个紧急立场”-采购商将下达命令，这就是为什么不应拉扯人们的原因。 “现在有五个紧急状态已经处于赤字状态了两个月”-这就是为什么销售下降的原因！ 紧急将所有人拖到地毯上，立即购买！
“程序员已经过期了我的任务”-是的，他们都完成了任务，不用担心。 会做。 “程序员已经把我的任务拖延了两个月了”-该死，我很想分散这些混蛋，他们在那里到底在做什么？
如您所见，条件的持续时间（尤其是负面条件）为信息提供了新的维度。 好像有平坦，乏味的信息，不清楚该怎么做，但获得了三维图像。 分析情况并做出决定变得容易得多。
这里的一切是如此明显，我什至都不敢相信-这样的平庸值得在教科书中单独写一章吗？ 要回答这个问题，请看一下您的信息系统。
您是否发现许多持续时间可测的状况？ 传统上，有两份基于Iceberg原则的报告：流动性较差的资产和欠款。 顺便说一句，您是否看到流动性差的资产？ 并非所有情况，即使是通用系统，也可以看到流动性很差的资产。
不幸的是，在信息系统中甚至没有“状态”的概念。 有数据和从不同角度查看它们的方法。 对于喜欢在大量数字中四处摸索但又没有足够明智信息做出决策的分析师而言，这是一种别致的享受。 而且，谁来做决定-人还是系统本身都没有关系。
有多种方法可以实施Iceberg原则。 传统-批处理记帐，将分隔符添加到信息数组时-批处理文档。 例如，货物到达仓库-我们不仅记住术语和数量，还记得收据-发票。 发票有一个日期，我们可以从中始终计算截止日期。 例如，他们对应收账款做同样的事情-他们不仅存储交易对手和金额，还存储产生此债务的单据-例如交货发票或向供应商的预付款。
从技术上来讲，当事人文件会带来很多困难。
首先，它增加了表中的记录数量。 一个条目“袖子，十件”可以变成十个条目-“袖子从2017年9月1日起1件”，“袖子从2017年9月9日起一件”等。
其次，需要批量取消算法。 例如，在运输（即注销商品）时，您需要知道从哪个批次中减去剩余的金额。 或者，在从买方付款时，您需要指明款项来自哪个装运单据。 使用两种方法：自动计算批次或手动指示。 自动批次选择是FIFO（第一，最早的批次）和LIFO（第一，最新的批次）的众所周知的注销策略。 手动批次标识通常用于过帐付款。
第三个问题，而不是方法论上的问题，是现实生活中没有遵循批量取消算法。 仓库管理员将从货架上拿走零件，而不是程序选择的零件。 他不知道什么是先进先出。
事实证明，这是一个技术复杂的系统，其结果很少使用。 我不是在谈论会计或管理会计，这要花费大量时间来计算冲销成本。 我说的是衡量负状态-非流动资产的持续时间。 您必须查看多少个真正，定期且有效的非流动资产工作流程？
第二种方法不是存储所有状态的持续时间，而是在必要时进行计算。 这是持续时间的即时估计。 例如，人们可以在仓库中找到没有流动性的资产而无需大量存储。 有很多方法-例如，了解当前的余额，回顾性地查看货物的流动。 如果没有动静，那么摆在我们面前的是流动性很差的资产。
此方法没有批量记帐的缺点-它不需要存储大量数据，并且不会使当前工作复杂化。 但是批处理记帐的主要优点-持续时间的存储-不在其中。 您只能在特定时间点立即看到持续时间的估算值。 我们进去，看着，欣赏，出去了-持续时间的评估消失了。
一方面-好的，没关系。 您可以采用一种算法来计算持续时间，并将其嵌入到流程中-让系统在负状态持续时做出反应。 但是，可惜的是，持续时间的瞬时估算并不是那么瞬时的-系统的资源都花在了计算上，这样就不会浪费每分钟的噪音。
持续时间的即时估计可用于不是很重要的过程，不需要每天进行监视。 例如，在建立处置流程时，相同的非流动性资产-每个月进行一次计算，确定积累最多的物料清单，形成处置它们的任务（例如，以折扣价或报废出售）。
第三种方法是计算，分离，存储和跟踪裁剪状态。
例如，您有一个赤字报表-您需要购买的商品清单。 用于生产，销售，维修等 监视整个赤字声明（过期的头寸）没有任何意义。 这些过去的职位值得强调，因为其中没有多少人？
只需在系统中的单独位置保存过期物料清单，其中包含数量以及最重要的是发生日期。 毕竟，那里不总是有过期的职位吗？ 一旦它们出现-请记住，出现的日期将是持续时间的起点。
然后，系统自行执行所有操作。 定期查看赤字-检查是否有过期的头寸。 如果不是，则为极好，则否定状态已停止。 可以保存已保存的过期职位清单并将其从系统中删除（在此情况下，您可以自行决定将其保留在内存中，例如用于回顾性分析或激励系统）。 如果到期的头寸仍然供不应求，那么这对系统也有好处，因为您无需执行任何操作，时钟在滴答作响，持续时间越来越长。
一个监督逾期赤字的人将很高兴。 首先，他不再关注-只是设置有关延迟的通知。 其次，您不再需要弄清楚延迟是否早已出现-持续时间将自动显示。 第三，没有必要追踪延迟消失的时刻-系统会在一切顺利时通知您。
作为业务程序员，您将更容易在业务系统中构建响应流程。 虽然不了解持续时间，但是一旦出现负面状态，您就必须立即拉扯该人。 而且，您的“抽搐”会像红色的抹布一样不断悬挂在您的鼻子前。
有持续时间时，设置会更精细-您自己选择向他人显示问题的时间。 您还可以根据负状态的持续时间选择彩色显示。 例如，黄色-一天，红色-两天或更长时间，等等。
同时，您可以构建上游响应系统。 例如，首先向供应商显示赤字延迟。 一天后，即使没有消除，也要交给供应总监。 三天后，交给商务总监。 在一个星期内-给导演。
此外，您了解：它的本质取决于任务完成的级别。 您要求供应商消除延迟-他必须订购该职位。 您要求供应商经理注意，并可能将职位转移给其他供应商。 您对主管说，整个供应服务在某种程度上工作异常，需要更改系统。
此方法的主要功能：状态数据的独立存储及其自动更新。 使用“自动任务”原理在技术上实现，稍后将进行讨论。
在此过程中，您肯定会找到其他方法来确定状态的持续时间，即 水下冰山的大小。 您可能正在其中我列出的方法不起作用的系统中进行编程-然后您必须寻找自己的方法。
最主要的是-在对业务系统进行编程时，请不要忘记“ Iceberg”的原理。
特别是如果您要使用分摊计帐-需要在设计过程中对其进行后退，因此追溯性部署起来非常困难。
可以随时包括对持续时间的即时评估，例如“ AutoTasks”。 好吧，也将其关闭。 因此，轻便是他们的优势。
我将通过实践给出一些使用Iceberg的示例。
第一个示例是任务管理系统。 有任务，任务或备忘录。 有一个发起人，有一个表演者。 当任务被接受到工作中时，一切都变得很清晰-有最后期限，您可以快速确定任务中的一切是否良好。
但是问题也有一些中间状态。 例如，发起者编写，发送了它，执行者必须接受它才能工作。 接受工作是一项任务的必然标志。 在承包商将其放下之前，任务的状态是冰山的水下部分。 当他最终打算这样做时，还没有该死的事情。
我的行为很简单-我添加了接受日期，以在任务中作为单独的字段工作。 已接受-日期被记住。 并且将任务发送给执行者的日期已经存在。 因此，我们得到了两个负面状态的持续时间。 在任务被接受之前，持续时间是当前日期与发送日期之间的差。 但是，当承包商接受时，会出现接受和发送之间的确切间隔，该间隔将永久存储在系统中，并用于进一步分析。
承包商进行工作并将其发送给发起人进行验证时，会发生类似的情况，持续时间无法理解。 当他检查那里时，未知。 直接与最终用户合作的任何体面的程序员都会确认任务经常在测试中冻结。 而且，从物理上讲，它已经可以被检查，用户喜欢一切，但是他不必费心登录系统并做笔记。
解决方法是相似的。 我们在任务中添加了两个日期-承包商发送要求进行验证的日期，发起者做出响应时，承包商接受结果或返回以进行修订。 因此，验证状态的持续时间总是在手边，我们可以将任务的验证时间标准化。 好吧，事实并非如此。
我最喜欢的例子是采购。 使用任务，一切都很简单-总是有一个特定的对象记录了这个任务，您可以向该对象添加存储有关状态持续时间数据的字段。
采购是一条流。 在他们中间，没有人会提出任何单独的任务。 好吧，想象一下自己-一个女孩坐在那里，正在订购衬套。 每一天 相同的衬套。 以及轴，螺栓，螺母，金属，锻件，冲压件等。
只有关于需要订购的信息。 是的，它发生在不同的详细级别上-有时只是收件人和承包商，订单，单位等的物料清单和数量清单。 但是，此信息始终是瞬时的，例如闪烁。 我进去了-您知道，您需要订购1020件。 一分钟后，他进入-哇，已经是1200了，因为情况已经改变了。
采购商了解这一点并加以利用。 在会议，汇报会和特工上，买家经常被试探到底，但从他们那里像鸭子下水一样。 他们告诉他们-伙计们，缺少什么衬套？ 所以昨天，只需要出现！ -回答那些。 昨天怎么样？ 好，昨天。 我发誓我昨天早上没钱了，没有灌木丛！
为了证明袖子是昨天，您只能提高后备。 当然，生活中的人们不会每天都拿起备份，因此疲倦的销售商和制造商会提出他们自己的Iceberg版本-打印输出。 例如，他们在星期一进入系统，查看赤字并打印出来。 当出现问题或与供应商打交道时，请给他们看这张纸。
但是很容易躲开这张纸。 推销员说-您在这里溜我什么？ 是的，星期一袖子不够，那又如何呢？ 周二已经有这么多，每个人都会有很多！ 今天您在系统中看到的只是昨天才出现。
然后，他们还被迫参加纸张事务-他们不仅印刷短缺，而且还给供应商签名。 并要求注明交货日期。 您了解，该过程在效率方面非常一般。
Iceberg原理在工作中起作用，但在供应方面却不起作用。 卖方知道必须做些事情，他们开始为购买设置任务-他们直接创建了对象，在其中放置了位置清单，并等待执行。 最初，它开始工作，然后，供应商开始愚蠢地拒绝此类任务，并带有诸如“我们不需要为日常工作准备单独的说明”之类的评论。 通常，正确的评论是，如果您为每个人都设置了任务，则清洁程序将必须连接到系统。
该问题已通过自动任务和Iceberg（默认情况下存在）解决。 自动任务只是出现一些缺陷，分解表演者的缺位，并形成一些对象，这些对象包含有关需要从供应商那里订购什么的信息。 自动任务形成日期以及执行日期即自动固定。 与供应商的职位安排。
例如，如果有必要，例如，需要100个衬套，而供应商订购了70个，那么自动任务不会关闭，而是可以简单地进行调整-现在您需要放置30个位置。 重要的是否定状态的开始日期，即 赤字保持不变。 一个人在一个时间间隔内订购了70个职位，在另一个时间间隔内订购了30个职位。
随着Iceberg的应用，该问题得以很快解决，因为不可能隐藏任何东西。 首先，在头寸和数量的背景下核算赤字的持续时间，其次，参考承包商。
当然，立即为供应商确定了一个关键绩效指标-他按时订购的职位比例是多少（从出现需求的那一刻起，他似乎必须满足这一天）。Iceberg在会计方面表现良好。毕竟，对于那些人来说，总有些地方出问题了。负余额出现在各种帐户或它们讨厌的寄存器中。尽管采用了恢复定居顺序的措施，但没有计算进展。更不用说没有数量的总余额，反之亦然。在系统正常状态下，如果没有冰山，很难到达会计部门。证明缺点已经挂了一个月的唯一方法是备份。但是它们也不是傻瓜-他们会说是的，一个月前有缺点，然后我们将其删除，现在又出来了，是您的程序员把某些东西弄混了。如果供应商只是简单地原谅自己而不将问题转移给其他人，那么会计人员就会长久想-我不知道，有意识或无意识-这样一种人为的时间压力方法。企业中有一位体面的程序员来照顾会计状态。他看到了背后的弊端，并告诉会计师-亲爱的阿姨们，您在做什么，让我们消除它！首先，他们说-是的，我们当然会消除，这符合我们的利益。缺点将在关闭本季度时极大地阻碍我们，请务必消除。此刻-假设是五月-没有时间压力，即没有人有有限的时间来解决问题。因此，恢复订单的任务按预期方式被推迟到远处。通过监测当前日常工作的方法来防止产生负残留物几乎是不可能的。即使您禁止负数冲销，教区也会得到纠正。因此，我们体面的程序员感叹并等待。例如，在6月底之前，程序员多次提醒会计师，删除弊端会很不错。截止日期越近，答案就越激进-滚开，这不是您的事，不要教我们如何工作，最后完全无视。然后是七月，有必要关闭该季度。现在，必须在时间压力模式下解决问题-尽快高效地进行，因为除了缺点之外，还有很多事情要做。如果您在工厂担任程序员，那么您会知道此时此刻正在发生的事情-任务迅速而美观地从会计转移到了程序员。尽管程序员正在尝试，但现在激怒已经为时已晚。但是会计师们提出了有力的论据-一切都必须交出报告，而且公司将被罚款，这实在太小了。对于领导者而言，没有什么东西可以减轻程序员和会计师如何滥用后者的负担了-威胁听起来太真实了。程序员有些抱怨，就像这是一名会计师的工作，他们知道该怎么做，总的来说，程序员花费公司的钱是会计师的三倍，这一切都是错误的，但为时已晚-造成了人为的时间麻烦。它通常以这种方式结束：程序员同意用自己的双手解决这些弊端，经理和会计师发誓要消除时间压力后再解决这一系统性问题。如此-每次。该问题的解决方案类似于供应。我们为门框的每个变体执行自动任务-例如，我们计算并显示周转中的负号，设置负责任的任务，最重要的是，确定任务出现的日期以获取Iceberg。现在，减号一出现，就会出现一个自动任务，它可以用作争执中的论据。显然，会计将忽略这些任务。但是，随后会出现程序员在与管理层会面中缺少的一些事实。这是门框，这是发生日期，这是负面状态的持续时间-例如一个月。最主要的是正确提交信息-亲爱的领导者，您好，我们的会计状态已经无法控制一个月了，我们不知道我们的仓库成本是多少，产生的成本是多少，因为我们有缺点。亲爱的领导者，您知道的重点不是缺点，而是与会计有关。减号是一种极端情况，一个显而易见的错误。并且仍然存在一些肉眼看不到的隐性变量，但却剥夺了您使用数据的机会。等等。
甚至Iceberg也直接要求达成协议的任何流程。花费，无限期，花钱，合同，规格，预算，计划，特殊服装的发行等等的申请。官僚们喜欢协调，但不是需要完成的过程，而是可以无休止地延迟的过程。幼稚的程序员负责向合同添加总会计师或财务总监的批准，其行为举止简单而毫不掩饰-在此合同中添加了一个特定领域，例如“同意”。他对冰山一无所知，因此他为缓慢而痛苦的死亡谈判协议的过程注定失败。如果合同不是很重要并且不在主管的视野之内，那么协调将是无休止的。条约的发起者别无选择，只能定期跑到总会计师那里，找出何时举行大圣礼。Iceberg立即迅速解决了问题。在这种情况下，知道两个日期就足够了-发送日期和批准日期。在这种情况下，不一致状态的持续时间是基本计算得出的，您可以对此时间进行平凡归一化。我是通过合同协调来做到这一点的，合同链由几个人组成-部门负责人，财务人员，会计师和律师。每个人都有一天的审批时间，而Iceberg在此期间的点击率达到了90％。但是，另一方面，问题开始了：当协议达成一致并在纸上签名后，两份副本都被发送给交易对手以签字并盖章。因此，该张纸应该再回到法律部门的档案中。但是以前抱怨长期批准的人并不急于将合同原件交给律师。他们通常会忘记它-对他们来说签订合同就足够了，您可以与交易对手合作。律师们在这里大吼大叫-没有原件是不可能的，任何支票都将适合奥斯威辛这样的公司，这似乎还不够。因此，另一个冰山似乎交出了合同的正本。普通分配一个月，外贸协议分配100天。一切正常。特别是当律师开始拒绝新合同，直到旧合同移交为止。系统中不断提供失败合同的数量和时间安排的图片，并且鉴于此问题的重要性，它始终处于管理层的控制之下。没有人愿意太频繁地进入导演的兴趣范围，因此他们几乎总是按时交出原件。