有时似乎只有一个极端或另一个极端：要么忙碌的节奏主导了公司的日常活动，要么决策像口香糖一样拖拖拉拉，没有任何进展。速度对于公司各个方面的安全来说都是绝对关键的因素，尤其是在安全流程中。我想用两个例子来说明我的意思，特别是在 SAP 领域：
1. SAP系统定期接受风险分析。该分析揭示了需要解决的弱点。每当这些风险得到纠正时，相关部门和 IT 部门的许多同事通常都希望参与其中。这意味着可能会有大量的投票轮次，进而导致越来越多的延迟。
2. 授权团队因请求而不堪重负。每天必须进行数百次角色转换。因为有时事情必须快速发生，所以更改也是按需实施的。一个电话就足够了，因为你认识以前的同事。每个人都知道，随后的问题会经常出现，而且拼凑的问题会越来越大。概述？没有任何。但时间压力大，人员紧缺。还剩下什么？
这些例子已经表明，速度因素与公司的安全性相关。但真的有“最佳速度”这样的东西吗？而这个速度如何才能达到呢？实施的三个技巧：
正确的视角
正如这两个例子已经表明的那样，在速度方面存在两个 民主捐助者电子邮件列表 绝对的极端。一种极端的结果就是无所作为。例如，由于某种粗心，在科隆人们会说“Et hät still jot jejange”。然而，更常见的是过度计划和过多协调，以免发生错误。
另一个极端可以用“忙碌”来形容。话虽如此，一切都必须完成——最好是尽快完成。尽管共同目标尚不明确，但它“只是在做”。积极性很高，很多工作成果都付之东流，离既定目标还很遥远。
两种极限速度及其对安全的影响
一方面，这种观点不必要地是长期的，另一方面，它又是非常短期的。你要么寻找无限的完美解决方案，要么日复一日地疯狂工作。
诀窍是关注中期。这意味着一段时间可以进行概览，同时可以清楚地划分为进一步的步骤。这个时期甚至不需要完全计划。在最好的情况下，这会导致针对以下情况的问题：
授权概念应该是什么样子才能在未来两到三年内存在？
访问流程应该是什么样子并在六个月内实施？
哪些控制措施可以在下个季度与部门讨论并纳入控制周期？
开始速度测量
一旦观点清晰，你就可以立即开始。或者？几乎。一方面，必须澄清速度的含义，另一方面，如何确定团队或流程是变得更快还是更慢。
为了澄清这些问题，可以提到三种不同类型的速度，它们在许多（安全）过程中发挥作用。根据流程的不同，其他因素也可能相关。
反应速度：专业部门的要求被明确表达或弱点自发出现。团队能够多快做出反应并迈出第一步？
决策速度：对于某些主题，目前还不清楚到底应该发生什么。这里需要多长时间才能确定下一步的方向？
执行速度：一旦做出决定，就开始执行。这意味着实施开始和实施结束之间的时间。
通过这种方式，所有进程都可以分为不同的速度，并且很明显，对其他参数的依赖性 - 例如主题的数量。
在频繁使用的流程中，例如用户请求，有必要将这些速度作为关键数据进行实际测量。一旦记录了此类速度，也可以对其进行优化，如以下实际示例所示：
SAP GRC 作为管理工具引入，用于控制 SAP 环境中的安全流程。每天通过自动控制和 SAP GRC Process Control 中的相应作业报告漏洞。然而，员工的工作收件箱中收到了大量的工单，他们花了很长时间来处理这些工单。一旦票被接受，实施并不需要很长时间。
如果我们只看一天的纯响应时间，这是非常好的，因为GRC系统可以立即快速地检测到漏洞。如果解决问题之前的整个时间更重要，那么肯定还有优化的潜力。
通过将作业频率从每天更改为每周解决了这个问题。因此，员工现在会以收集的形式收到结果。决策时间缩短至平均三天，从而缩短了整体处理时间。更重要的是：员工的纯粹处理时间也大幅减少了 73%，从而能够专注于新主题。
缩短决策和处理时间
自觉发展动力
为了在操作中达到正确的速度，动力是必要的。这并不意味着随意的加速，而是启动了一定量的动量。可以通过多种不同的方式为这种势头提供推动力：
通过良好的设计提高速度：在流程的开发阶段应牢记可能的吞吐量。一旦完成所有流程（而不仅仅是最重要的流程），差距很快就会变得明显，否则稍后就会出现。
再次以SAP GRC Access Control的实施为例：以后是否可以了解哪些风险是从哪些应用程序进入系统的？或者申请中是否有可以缩短或自动批准的子步骤？通过这种方式，可以在设计阶段消除不必要的障碍，这些障碍随后会导致挫败感和速度减慢。