SEARCH

For compliance to succeed you must manage your obligations, but more importantly you need to keep your promises. This requires several things working together to produce the outcome of compliance: better safety, security, sustainability, quality, lower risk, and ultimately better stakeholder trust. ISO 37301: Performance-based Standard for Compliance Management Systems ISO 37301 can help you achieve those outcomes. But only if you intend to keep your promises. Otherwise, it will just be another standard among others that add more work, cost and deliver few benefits. ISO 37301 is not a rule-based standard like many of the others. ISO 37301 is performance-based which makes it ideal for performance and outcome-based obligations, and where compliance failure means mission failure. In this webinar, I help you understand what ISO 37301 is all about, how it works, and how to use it to keep all your promises. By doing so you will realize more than just incremental improvements. You will experience transformational benefits that compound year over year. We offer an on-line certificate program based on this webinar along with additional resources to help you use ISO 37301 to achieve compliance success.

Ensuring that organizational obligations and policies are effectively deployed and upheld is a critical task. This is where Hoshin Kanri, a Lean practice, comes into play. Hoshin Kanri offers a structured approach to operationalize obligations across organizations, providing a roadmap to align objectives, ensure accountability, and drive continuous improvement. In this blog post, we will delve into the framework of policy deployment using Hoshin Kanri, shedding light on its key components and how it helps organizations steer towards better outcomes. The Framework: Policy Deployment using Hoshin Kanri Integrative Framework to Operationalize Obligations At its core, policy deployment using Hoshin Kanri is about translating high-level organizational goals and policies into actionable plans that permeate throughout the organization. This framework can be summarized as follows: Define Obligations and Promises : The journey begins by defining organizational obligations and high-level policies. These policies provide guiding principles that align the organization with its strategic direction. Promises are more specific commitments derived from the policies, essentially breaking down the high-level goals into tangible objectives. Policy Deployment Plans (PDPs): Once policies and promises are established, they are captured in Policy Deployment Plans (PDPs). These plans serve as roadmaps, outlining the specific actions, responsibilities, and timelines required to meet the promises. Each PDP is a detailed action plan that brings clarity to the path forward. Negotiation : The negotiation phase is where the rubber meets the road. PDPs are not handed down from the top; instead, they are negotiated with those responsible and accountable for their execution. This negotiation process is known as "Catch-ball." It encourages open dialogue and collaboration, breaking down silos and ensuring everyone is on the same page. Alignment, Accountability, and Assurance Policy deployment using Hoshin Kanri is a powerful framework because it helps drive alignment, accountability, and assurance across the organization: The 3 A's of an Effective Compliance Program Alignment : The process aligns every individual and team with the organization's policies and objectives, creating a shared sense of purpose. Accountability : Through the negotiation and Catch-ball process, clear responsibilities are assigned, leaving no room for ambiguity. This enhances accountability at all levels of the organization. Assurance : By monitoring both quantitative and qualitative aspects, the organization gains assurance that it is not only meeting its targets but also advancing its long-term obligations and outcomes. Two Primary Loops: Quantitative and Qualitative Regulation In policy deployment using Hoshin Kanri, there are two primary loops that guide the process: Meeting Objectives (Quantitative Regulation - Compliance 1) : This loop focuses on quantitative regulation, ensuring that the organization is meeting its numerical targets and objectives. It involves tracking key performance indicators (KPIs) and metrics to measure progress towards the promises made in the PDPs. Meeting Obligations and Advancing Outcomes (Qualitative Regulation - Compliance 2): While meeting numerical targets is crucial, qualitative aspects are equally important. This loop emphasizes qualitative regulation, ensuring that obligations are met and outcomes are advanced. It involves assessing the impact of policies on the organization's culture, values, and long-term sustainability – it measures effectiveness. A Proactive and Integrative Program What emerges from policy deployment using Hoshin Kanri is an integrative and proactive program. It's not merely about meeting immediate goals but about strategically advancing the organization towards better outcomes. It's a dynamic process that encourages continuous improvement and adaptability in a rapidly changing environment. Building a policy deployment program using Hoshin Kanri requires a structured approach: Leadership Commitment : Start by securing commitment from top leadership. Without their buy-in, it's challenging to drive such a comprehensive change. Education and Training : Provide training and education on Hoshin Kanri principles and methodologies to all levels of the organization. Policy Development : Develop clear and concise organizational policies that align with your strategic direction and organizational obligations. Promise Identification : Identify specific commitments derived from these policies, ensuring they are actionable and measurable. Policy Deployment Plans : Create detailed PDPs that outline responsibilities, timelines, and metrics for each promise. Catch-ball Process : Implement the Catch-ball process to negotiate and refine the PDPs with those responsible and accountable. Monitoring and Feedback : Continuously monitor progress using KPIs and gather feedback to make necessary adjustments. Continuous Improvement : Encourage a culture of continuous improvement, where the organization learns from its successes and failures. Policy deployment using Hoshin Kanri is a robust framework for operationalizing obligations across organizations. It not only ensures alignment, accountability, and assurance but also drives organizations towards better outcomes. By following the structured approach outlined in this blog post, you can build a proactive and integrative program that transforms your organization's policies into tangible objectives, making a meaningful impact on its success and sustainability.

In this blog post we walk through the approach developed by Marissa Kephart in collaboration with Lean Compliance to define a golden thread of assurance for an environmental program. In this post we look at the use of a Dependency (or Design) Structure Matrix (DSM) to better understand the interactions of The12 Environmental Pillars (download them here ), which interactions are essential, and which ones contribute the most to overall program effectiveness. This information will help determine which should be part of the golden thread. In Part 2, we will consider the use of a balanced scorecard to monitor the golden thread and provide insights for decision makers on how to improve overall program performance. What is a Golden Thread? The 12 Environmental Pillars To provide assurance that environmental obligations will be met, an environmental program must perform such that its outcomes are continuously advanced towards the overall goal of community sustainability. This outcome is created by the product of the interaction of 12 environmental pillars. A “golden” thread that runs through the pillars of an environmental program – Environmental Golden Thread – can serve to provide assurance that essential capabilities exist and are operational. It can also provide traceability and transparency for retrospective and prospective analysis, ensuring the integrity of the environmental program and all its systems and processes. Using an Environmental Golden Thread can also provide leadership and management with valuable insights to help make better decisions associated with environmental obligations, commitments, and investments. Additionally, this thread will enable better coordination and alignment of effort across an organization in support of overall program objectives. What is a DSM? A Dependency Structure Matrix (DSM) is a tool used to represents a system and its components to better understand critical dependencies. A DSM models system elements and their corresponding information exchange, interactions, and relationship in a compact visualization to highlight the important dependencies. Dependancy Structure Matrix An environmental program will include many aspects which can be modelled using a DSM. We have used it here to model the 12 environmental pillars which need to be advanced simultaneously towards the goal of community sustainability. Since program outcomes are a product of system interactions, using a DSM will help to better understand how to manage environmental pillars collectively to achieve program objectives. In the process, this understanding will contribute to the development of an environmental golden environmental thread - the mechanism to provide program assurance. The following baseline DSM was created based on an original ordering of the 12 pillars: Baseline DSM Analyzing Adjacency Within a system there can be various types of relationships between elements. As shown below, a relationship can either be sequential, coupled or parallel. The latter was not considered since it represents no interaction between elements. In a sequential relationship, element A influences B, as shown in the diagram below. This gives an idea of which elements to focus on before others for increased program output. There also exists adjacency relationships which are called, "coupled". This is where the flow of influence or information is intertwined: element A influences B and element B influences A, as shown below. DSM Relationships The performance of an environment program is helped by knowing which program pillars have sequential and parallel adjacency with other pillars. This will help determine which pillars depend on another and how this might impact how they are managed. Sequential Adjacency For sequential relationships, two pillars within the DSM are intertwined where pillar A influences pillar B. As pillars are more like streams rather than static assets not all of pillar A may be necessary before Pillar B. What is important is that Pillar B needs something from Pillar A to be effective. Knowing the type of relationship provides visibility as to which pillars need upfront planning and should be prioritized. This planning may help uncover other dependencies that have secondary influences. Within the Environmental Golden Thread DSM, there exists many adjacency relations between pillars. Most of these relationships are sequential where A reinforces B, fostering an increased output for B with the presence of A. For example, the following pillars are sequential relationship in the Environmental Golden Thread model: Carbon Neutrality / Circular Economy Environmental Stewardship / Community Sustainability Environmental Stewardship / Circular Economy Active and Green Transportation / Environmental Health and Safety Climate Change Risk and Adaptation* / Adaptive Management for Service Reliability Infrastructure Resilience / Climate Change Risk and Adaptation * The bolded pillars in the above list indicate which dependencies are primary and can be sequentially prioritized within the coupled relationship, since the Environmental Golden Thread model is built with a combination of primary and secondary dependencies. Coupled Adjacency Coupled relationships are seen where two dependencies are located directly across the DSM’s diagonal from each other, where A must exist to get B and B must exist to get A. As such, the coupled relationships in the model show the critical areas of focus in the system. For example, the following pillars are coupled: Circular Economy / Zero waste Greenhouse Gas Emission Reductions / Carbon Neutrality Climate Change Risk and Adaptation / Environmental Health and Safety Environmental Health and Safety / Environmental Stewardship · Adaptive Management for Service Reliability / Infrastructure Resilience Coupling is even more vital to the health of the overall system. Coupled dependencies' proximity to the diagonal axis of the DSM indicates their role in connecting the pillars of the Environmental Golden Thread. Additionally, since all coupled relationships within the model include both primary and secondary dependencies, the primary dependencies should be prioritized over the secondary ones in the coupled relationship. However, due to their tightly coupled nature, the performance of the primary dependency may affect the performance of the secondary dependency, and vice versa. Dependency Rank Ordering The total number of dependencies in either the vertical or horizontal rows of the DSM give insights into which program pillars should be managed more carefully and with a higher priority. Pillars that are high on both lists indicate that they should be of high priority, whereas the lower ones serve to connect-the-dots together, effectively keeping the critical chain intact. This analysis is dependent on the organization’s interest in either primary or secondary dependencies, or both, as the figures below show that multiple combinations of priority can be determined dependent on individual priority of system dependencies and pillars. Vertical Dependency Rank Order Marks going down a single pillar’s column in the DSM indicate how many outputs that pillar has, as well as which of the other pillars that pillar is dependent on. Knowing which pillars have the most vertical marks, or dependencies, gives an idea as to how many and which pillars are necessary to achieve the objectives of the individual pillar and the system. As such, this gives an idea as to the pillar’s overall dependence on the other 11 pillars within the system model. The total number of dependencies in each pillar’s vertical row were then counted and ranked by the total number of dependencies, as well as the primary and secondary on an individual level, as follows: Based on total number of dependencies (primary + secondary): 1) Food Security 2) Zero Waste 3) Environmental Stewardship 4) Active and Green Transportation 5) Circular Economy 6) Infrastructure Resilience 7) Adaptive Management for Service Reliability 8) Environmental Health and Safety 9) Climate Change Risk and Adaptation 10) Carbon Neutrality 11) Community Sustainability 12) Greenhouse Gas Emission Reductions Based on the number of primary dependencies: 1) Food Security 2) Climate Change Risk and Adaptation 3) Environmental Health and Safety 4) Zero Waste 5) Environmental Stewardship 6) Active and Green Transportation 7) Circular Economy 8) Infrastructure Resilience 9) Adaptive Management for Service Reliability 10) Carbon Neutrality 11) Community Sustainability 12) Greenhouse Gas Emission Reductions Based on the number of secondary dependencies: 1) Zero Waste 2) Environmental Stewardship 3) Food Security 4) Active and Green Transportation 5) Circular Economy 6) Infrastructure Resilience 7) Adaptive Management for Service Reliability 8) Carbon Neutrality 9) Environmental Health and Safety 10) Climate Change Risk and Adaptation 11) Community Sustainability 12) Greenhouse Gas Emission Reductions The figure below shows that the pillars “Climate Change Risk and Adaptation”, “Environmental Health and Safety”, and “Food Security” have the most primary dependence on other pillars in the model. This demonstrates that to achieve these pillars, the other pillars that they are dependent on must be started first to support the other. This analysis is dependent on the organization's interest in either primary or secondary dependencies, or both, as the figure below shows that multiple combinations of priority can be determined dependent on individual priority of system dependencies and pillars. Vertical Dependency Rank Order Horizontal Dependency Rank Order Marks going across a single horizontal row of the DSM represent dependencies flowing to pillars that are necessary to achieve the objective of the pillar corresponding to that row. The more dependencies each pillar has in their row indicates that it is more connected to the other pillars of the system model, therefore it should be prioritized over pillars of lower dependency counts. These horizontal dependencies show which pillar has the most inputs, or how many other pillars the pillar row supports, as well as its overall contribution to the program model. The total number of dependencies in each pillar’s horizontal row were then counted and ranked by the total number of dependencies, as well as the primary and secondary on an individual level, as follows: Based on total number of dependencies (primary + secondary): 1) Environmental Health and Safety 2) Carbon Neutrality 3) Community Sustainability 4) Adaptive Management for Service Reliability 5) Climate Change Risk and Adaptation 6) Circular Economy 7) Active and Green Transportation 8) Food Security 9) Infrastructure Resilience 10) Greenhouse Gas Emission Reductions 11) Environmental Stewardship 12) Zero Waste Based on the number of primary dependencies: 1) Environmental Health and Safety 2) Adaptive Management for Service Reliability 3) Climate Change Risk and Adaptation 4) Active and Green Transportation 5) Carbon Neutrality 6) Circular Economy 7) Food Security 8) Infrastructure Resilience 9) Greenhouse Gas Emission Reductions 10) Environmental Stewardship 11) Zero Waste 12) Community Sustainability Based on the number of secondary dependencies: 1) Community Sustainability 2) Environmental Health and Safety 3) Carbon Neutrality 4) Adaptive Management for Service Reliability 5) Climate Change Risk and Adaptation 6) Circular Economy 7) Food Security 8) Infrastructure Resilience 9) Greenhouse Gas Emission Reductions 10) Environmental Stewardship 11) Active and Green Transportation 12) Zero Waste The figure below shows that the pillars “Active and Green Transportation”, “Environmental Health and Safety”, “Adaptive Management for Service Reliability”, and “Climate Change Risk and Adaptation” critically contribute the most to other pillars in the model. This demonstrates that achieving the objectives of these pillars subsequently supports the rest of the pillars, since the other pillars are highly dependent on them. Horizontal Dependency Rank Order Primary versus Secondary Dependencies Without the existence of the secondary dependencies in the system model, the program would still be intact; however, there would be less opportunity for further improvements of user’s environmental obligations. As can be seen in the DSM, most of the secondary dependencies are located well outside the diagonal region, as well as the two pillar grouping areas (as indicated by the black outlines). This indicates that as the dependency locations travel further from the diagonal, the less they critically support the “Golden Thread”, instead offering additional reinforcements to the model. However, there are several exceptions where the secondary dependencies are located adjacent to the DSM's diagonal where the presence of these dependencies adds a layer of depth to the system that allows organizations the option to tailor the model to their unique needs and to understand the possible combinations of the pillar inter-dependencies more fully. The secondary dependencies, if considered by an organization, connect the loose ends of the primary dependencies, and necessitate organization's to implement a more holistic approach to the Environmental Golden Thread through systems thinking and active management techniques. Off-axis Primary Dependencies In the final partitioned DSM, several primary dependencies were observed that did not directly follow the line of the diagonal axis, including: Climate Change Risk and Adaptation to Adaptive Management for Service Reliability Active and Green Transportation to Community Sustainability Food Security to Environmental Health and Safety Infrastructure Resilience to Climate Change Risk and Adaptation Such dependencies remain primary, despite their location in the DSM, since they serve as connectors between the different subgroups in the DSM. For example, the dependency between the pillars “Climate Change Risk and Adaptation” and “Adaptive Management for Service Reliability” connects the subgroup of three pillars together from the main Golden Thread loop. Similarly, the dependency connecting “Active and Green Transportation” and “Community Sustainability” is located far from the diagonal axis; however, the presence of this connection is vital to the structure of the model since it connects the main upper loop to the lower loop of the model (see dependency map below). Overall, these off-axis primary dependencies portray locations of possible redundancy in the pillar dependencies, without them the program still functions; however, the critical chain among the 12 pillars is weakened. Partioned DSM DSM Insights There are a number of insights that we be derived from using a DSM on the 12 program pillars: Pillars with 'X's directly adjacent to the diagonal form primary dependencies with corresponding pillar. Pillars with 'X's farther away from the diagonal form secondary dependencies and provide further areas of contribution to the program. Pillars with tightly coupled adjacency should be planned together Pillars with sequential adjacency should be planned in order of their dependency Pillars should exploit dependencies to reinforce and amplify pillar performance Pillars with the greater number of 'X's vertically require more inputs Pillars with the greater number of 'X's horizontally generate more outputs Connecting each pillar together using this information will create a golden thread that ensures each pillar performance is combined to maximize overall program effectiveness. This will save costs, realize outcomes sooner, and create a virtuous cycle of improvement over time. In Part 2, we will combine this analysis with a balanced scorecard to provide a mechanism to monitor pillar and program performance to help decision makers know how best to invest and make improvements.

Golden Thread of Assurance for Compliance An important role of compliance is keeping organizations operating between the lines and ahead of risk. And when it comes to risk many will provide a long list that you might consider. Some of these will indeed require attention and careful deliberation. However, there will always be uncertainty when pursuing mission success. There will always be a list of risks to handle. What’s better is knowing how to meet obligations and deliver stakeholder commitments in the presence of uncertainty. This is why compliance should consider operational aspects when planning their compliance efforts.These are the capabilities necessary for compliance to be successful in the presence of uncertainty. A measure of compliance success is when compliance is fit for purpose, capable of meeting all obligations, and perhaps most importantly, capable of realizing the benefits that come from being in compliance: better safety, security, sustainability, quality, regulatory, and ultimately stakeholder trust. The following are essential compliance capabilities as viewed through an operational lens. These define the operational requirements for an effective compliance program: Obligation Management Promise Fulfillment Value Chain Integration Organizational Alignment Compliance Operability When operating together these form a golden thread of assurance to provide the necessary confidence for compliance success. Let's take a look at each one, starting with obligations. 1. Obligation Management Compliance must manage obligations Many organizations have compliance management systems. However, very few manage obligations. You may have a management system for quality, environmental, safety, security and so on. These manage the “practice” of compliance but do not necessarily obligations themselves. For that you need a compliance program. ISO 37301 is a recent standard you can use that has the basics for such program. It elevates compliance by providing a system to manage compliance performance. ISO 37301 includes a concept of operations diagram that illustrates the various functions, behaviours, and interactions that need to be considered and continuously improved over time. This is a good start for organizations beyond the basics of what common management systems provide. We need to remember that we don't need compliance management we need managed obligations. 2. Promise Fulfillment Compliance must operationalize obligations. Organizations may track their obligations but seldom do they keep track of their promises which makes them difficult to keep. Promises are the operational side of obligations. In fact, promises are operationalized obligations. They define the commitments we make to meet our obligations. Promises describe the how while obligations describe the what . Obligation and Promises If obligations are the requirements, promises are the specifications that tell us what we need to achieve compliance. While managing obligations is a level up for many organizations, managing promises is what makes them effective at it. To meet obligations, organizations need to learn and practice how to keep their promises. 3. Value Chain Integration Compliance must be an integral part of the value chain For compliance to be successful obligations must be operationalized which means compliance must be an integral to the value chain. The following adaptation of Michael Porter's value chain helps illustrate why this is important: Total Value Chain At the basic level companies desire to advance profit and better margins. However, organizations will also have other outcomes promised to their stakeholders. Ensuring these outcomes requires programs to operational obligations. These programs (or what we call certainty programs) translate obligations into value chain commitments (or promises) that contribute to meeting targets or advancing outcome associated with safety, security, sustainability, quality, and so on. This kind of integration is known as internal regulation – regulating towards better outcomes, not only better margins. This is not a project that is done once and forgotten. Value Chain Integration is a continuous process that aligns organizational values with operational objectives. 4. Organizational Alignment Compliance must bridge the gap between what's above and what's below There is a line that runs through an organization that separates the difference between: upper management and lower management. Organizational Barrier This organizational barrier creates a gap between: those who are accountable and those that are responsible programs that change state, and systems that resist change to maintain state obligations that define compliance requirements and promises that specify our commitments the ends and the means the benefits and the cost our long term vision and our short term mission Now, there used to be something called middle management to do the translation between what is above and what is below because they all speak different languages. This layer has been mostly gutted in recent years to flatten organizational structures. What does this mean for compliance? If you want an effective compliance program, that program must now include managing change, and negotiation of this barrier. Failure to do this will result in compliance failure. You could say that operationalizing obligations depends on how well you negotiate this barrier. Compliance must find a way to align these two worlds. 5. Compliance Operability Compliance must be operational For compliance to be successful it must be operational. It must be fit for purpose, able to meet obligations, and capable of realizing the benefits of compliance. To understand this better we developed the following compliance operational model: Compliance Operational Model This model comprises what's needed to continuously deliver on promises to maintain a state of compliance: Operational Governance - sets the destination - the desired outcomes, the goals that we want to achieve. Operational Programs - what governance uses to steer towards outcomes (the controller of the subsystems) Operational Subsystems - implement controls (which are processes) to ensure that objectives are consistently met Operational Processes - do the work of compliance Feed-back and Feed-forward processes along with improvement loops for conformance, performance, and effectiveness. These are all continuous functions, behaviours, and interactions not yearly activities or tasks. When operational they will achieve what we call Minimal Viable Compliance (MVC) - the minimum performance necessary to start realizing benefits. MVC is not achieved at the end of a 5-step maturity model, but right at the start. Why is that important? Because, compliance failure means mission failure.

At a fundamental level compliance programs protect the value stream from threats that hinder the creation of value. Each program contributes to keeping the value chain safe from various risk including: quality risk, occupational safety risk, security risk, and so on. These programs are socio-technical in nature in that they recognize the interaction between people and technology often across multiple levels of organization. Rasmussen's Risk Management Framework (also known as Rasmussen's ladder) provides useful insights when it comes to understanding risk across social-technical boundaries to achieve safety objectives along with other risk objectives. Rasmussen originally developed his approach as part of a proactive risk management strategy, however, its primary application has been as an accident analysis tool (ACCIMAPS) for complex socio-technical systems. Rasmussen's Risk Management Framework This framework has its roots in systems thinking based on the notion that accidents are hidden in normal operations and do not need special causes. This is similar to Safety II (Holnagel, 2017), and Deming's work that defects are caused by normal causes (natural variation). Rasumussen's model and others since represent a growing trend away from "root causes" or you might say "special causes" for systemic failures. Rasmussen' suggests the following system boundaries by which to map structure, components and their interactions: Rasmussen's Risk Management Framework The structure of Rasmussen's Risk Management Framework considers six levels: Government - where laws and regulations are developed; Regulatory - where industry standards are developed based on laws and regulations; Company - where company policies and procedures based on industry standards govern work processes; Management - where company policies and procedures are implemented; Staff - representing the activities and characteristics of workers performing the processes; and Work - representing the equipment and environment by which work happens Vertical integration is required for the system to function safely. This means that decisions made at the higher levels should propagate down the hierarchy as information flows upwards. The interaction and dependencies across levels are critical to ensure that intended safeguards protect system states. Threats to safety result from a loss of control caused by inadequate vertical integration across levels, not just from deficiencies at any one level. Nancy's Leveson [2] provides an example of how this can be used to model safety control: Nancy Leveson - Hierarchical Model of Safety Control Framework Predictions Rasmussen's Risk Management Framework makes a series of predictions[1] in relation to performance and safety in complex socio-technical systems: Safety is an emergent property of a complex socio-technical system. They are impacted by the decisions of all of the actors – politicians, managers, safety officers and work planners – not just the front-line workers alone. Threats to safety are usually caused by multiple contributing factors , not just a single catastrophic decision or action. Threats to safety usually result from a lack of vertical integration (i.e. mismatches) across levels of a complex socio-technical system, not just from deficiencies at any one level alone. The lack of vertical integration is caused, in part, by a lack of feedback across levels of a complex socio-technical system. Actors at each level cannot see how their decisions interact with those made by actors at other levels, so the threats to safety are far from obvious before an incident. Work practices in a complex socio-technical system are not static . They will migrate over time under the influence of a cost gradient driven (see Drift to Failure below) by financial pressures in an aggressive competitive environment and under the influence of an effort gradient driven by the psychological pressure to follow the path of least resistance. The migration of work practices can occur at multiple levels of a complex socio-technical system, not just one level alone. Migration of work practices causes the system’s defenses to degrade and erode gradually over time. Accidents are induced by a combination of this systematically induced migration in work practices and a triggering event, not by an unusual action or an entirely new, one-time threat to safety. Drift to Failure Rasmussen also identified a phenomenon which he called, "drift to danger." systemic migration of organizational behavior toward accident under the influence of pressure toward cost-effectiveness in an aggressive, competing environment Rasmussen's Migration Model - Transport Canada - Jim McMenemy, Safety Intelligence Project Rasmussen's migration model represents constraints (i.e. economic, workload, safety) which create the following possibilities: If the system reduces output too much, it will fail economically and be shut down If the system workload increases too far, the burden on works and equipment will be too great If the system moves in the direction of increasing risk, accidents will occur In essence, accidents occur when the system's activity crosses the boundaries into unacceptable safety. Application Rasmussen's Risk Management Framework provides a good representation of the real world and has been used to better understand safety risk in dynamic, social-technical systems. Accimaps[3] which are derived from Rasmussen's framework provide a generic and flexible approach since they do not use predefined taxonomies of hazards or failures across the various levels. Accipmaps have been used in aviation, defense, oil&gas, risk management, public health, patient safety, and environmental studies. Rasmussen's framework also provides the means to better understand how to achieve other risk objectives such as quality, resilience, reputation, financial, and trust. References: [1] A.L. Cassano-Piche, K.J. Vicente and G.A. Jamieson, "A test of Rasmussen’s risk management framework in the food safety domain: BSE in the UK", 2009, Theoretical Issues in Ergonomics Science [2] Nancy G. Leveson, "Rasmussen’s Legacy: A Paradigm Change in Engineering for Safety", 2015, [3] Justen Debrincat, "Assessing Organizational Factors in Aircraft Accidents using a Hybrid Reason and AcciMap Model", 2012, RMIT University

Raimund Laqua, P.Eng., PMP For decades, the system of record has been the gravitational centre of the enterprise. Your ERP, your CRM, your quality management system — whatever the acronym, the function was the same. One place where the authoritative version of the truth lives. Every audit trail starts there. Every compliance obligation traces back to it. Machines have always done part of the work inside these systems — workflows, automated triggers, batch processing. But that work was governed, designed, and built by humans. Every automated step was deliberately engineered into a known path. The system of record captured the work because the work was designed to flow through it. And when governance was working, the how mattered as much as the what — the work reflected the organization's values, its commitments, and its obligations. But what happens when autonomous agents do the work? The Shift AI assistants are already embedded in the platforms organizations use — Microsoft's Copilot across Dynamics 365, SAP's Joule, Salesforce Einstein. Today, a person still asks the question and still decides what to do with the answer. But the vendors aren't stopping there. They're explicitly moving from "system of record" to "system of intelligence." The system no longer waits for people to analyse data. It acts. That's not an assistant — that's an agent with authority. And it changes everything about where the source of truth lives. It's important not to confuse this with the workflow automation we've had for decades. A workflow is a deterministic path — designed by humans, with each step predefined, each decision point mapped, and the system of record baked into the sequence. The workflow writes to the system because the system is part of the track it runs on. An autonomous agent doesn't follow a track. It receives an objective, assesses the situation, decides what to consult, coordinates with other agents, takes action, and moves on. It may take a different path every time depending on what it finds. The system of record isn't part of that path unless someone engineered it to be. No human is watching each decision. No human can — not at the speed and scale agents operate. Now ask the question: where is the system of record in that workflow? And more importantly — is the work being done in a way that upholds what the organization stands for? The Problem Work was done. But were the promises kept? Not just "did the agent complete the task" — but did it fulfill the organization's actual commitments? The right output can only be produced the right way. Did it uphold the values behind those commitments — the safety, the quality, the duty of care that the organization promised its regulators, its customers, and its stakeholders? If nobody engineered the agent to track that, the question may not even be answerable. When agents coordinate with other agents to deliver on a shared promise, it gets worse. The source of truth isn't a system anymore. It's distributed across agent interactions that may be ephemeral. The source of truth didn't move to a new system. It dissolved into a process. Whose Promises Is the Agent Keeping? Here's what I think cuts to the heart of it: when we say an agent "works," we usually mean it completes the task and stays within its guardrails. Those are the developer's promises. The promises your organization has made are different. Promises to comply with governance policies. Promises to produce auditable evidence. Promises to fulfill obligations in a way that reflects your values — not just efficiently, but ethically, safely, and transparently. Right now, there's no mechanism in most agent architectures to translate those organizational promises into agent-level operational commitments. The agent doesn't know what you promised the regulator. It doesn't know what your values require. It knows what its developer built it to do. The agent is keeping the developer's promises. Nobody has engineered it to keep yours. Can Agents Follow Governance Policy? This raises a harder question: can autonomous agents follow governance policies at all? Not the way humans do. An agent can follow instructions and be constrained by guardrails. But governance requires understanding intent, interpreting context, and exercising judgment about edge cases the policy didn't anticipate. Agents don't do that. They optimize toward objectives within whatever constraints they were given. If the constraint was well-engineered, the behaviour looks like compliance. If it wasn't, the behaviour looks confident and wrong. There's a deeper problem. Any codified rule will eventually be inadequate because the agent optimizes around the measurable parts and erodes the unmeasurable intent. The letter of the policy gets followed. The spirit gets lost. Not through malice — through the physics of optimization. So agents can fulfill obligations that have been engineered into their architecture. They cannot interpret governance policies the way a competent professional would. And they cannot uphold organizational values unless those values have been translated into operational commitments they're designed to keep. The Humans in the Loop The human in the loop is not only the person reviewing the agent's output after the fact. You can't verify what you can't see. An important human in the loop is the engineer who designs the agent to do the right thing before it's deployed. The accountability is front-loaded into the architecture, or it doesn't exist at all. Governance policy can't be an external constraint layered on after the fact. It has to be engineered into what the agent is — because the right output can only be produced the right way, and the right way has to be built in. The Promise Architecture I've been thinking about this through Mark Burgess's Promise Theory. The core insight: you can only make promises about your own behaviour. An obligation imposed from outside isn't a promise until you've assessed it, determined what you can genuinely commit to, and declared that commitment. Most agent architectures work on an imposition model — do this task, follow these rules. For work that matters, that's not enough. The agent needs to receive the obligation, assess whether it can fulfill it, declare what it can commit to, and fulfill that commitment while producing evidence that the promises were kept — because the right output can only come from a process that upholds the organization's commitments and values. That's what I've been calling a Promise Agent. Policy isn't a reference document the agent consults — it's an operational capability the agent possesses. A fire suppression system doesn't "consult" the fire code. The requirements are engineered into its design. The system embodies the obligation. Delivery matters as much as the declaration. In a human workflow, the person doing the work is also the person creating the record. In an agentic workflow, that coupling breaks. This is why promise delivery can't just mean the agent produced an output. The right output can only be produced the right way — and the agent must demonstrate that the path it took was consistent with what the organization committed to. In Burgess's framework, delivery is continuous — the agent evaluates whether it can still keep delivering, and signals when that capability is compromised. The Golden Thread So where does the source of truth actually live? In the human model, it lives in the system of record. One place, one version, one truth. In the agentic model, that's no longer sufficient. The source of truth lives in the promise architecture — the traceable relationship between four things: the obligation (what the organization committed to), the promise (what the agent declared it could deliver), the delivery (how the agent fulfilled it and whether it did so in a way consistent with the organization's values), and the evidence (the demonstrable record that all three are connected and consistent). What connects these four elements is the golden thread of assurance — the unbroken, traceable line that runs from commitment through promise through delivery through evidence. In a human workflow, the golden thread runs through the system of record. In an agentic workflow, it has to run through the promise architecture — and the system of record becomes where that thread is anchored and made auditable. If the thread breaks at any point, assurance is lost. And any of these elements without a connection to the organization's values is compliance without purpose — the letter without the spirit. The system of record doesn't disappear. But its role shifts from being the source of truth to being the registry of truth — the place where the golden thread is anchored, where the organization can demonstrate that its agents are keeping its promises in a way that upholds its values. Most current systems of record weren't designed for that. They were designed for humans filling in forms. A Design Problem I'm not arguing that the system of record is dead or that fully autonomous agent workflows are the norm yet. But the building blocks are being assembled — in the platforms, in the vendor roadmaps, and in the architectural decisions organizations are making right now. The concern is that the decisions being made today are creating an architecture where agents do work without a golden thread connecting what they did to what the organization promised — and to the values behind those promises. Where nobody can demonstrate that the right output was produced the right way. That's not a technology failure. It's a design failure. And design failures are preventable. If you're deploying AI agents in a regulated environment, the question I'd encourage you to ask is not "what can the AI do?" but "will the AI do it in a way that keeps our promises and upholds our values?" If you don't have a clear answer, you have a design problem that's worth solving now — before it becomes a compliance problem you have to explain later. Raimund (Ray) Laqua, P.Eng., PMP, is a computer engineer and the founder of Lean Compliance Consulting. With over 30 years of experience across regulated industries — oil & gas, pharmaceuticals, medical devices, aerospace, nuclear, and financial services — he developed the Lean Compliance methodology grounded in Promise Theory, cybernetic regulation, and total value chain analysis. Ray is Chair of the AI Committee for Engineers for the Profession (E4P), sits on ISO's ESG working group, serves on OSPE's AI in Engineering committee, and advocates for federal Digital Engineering licensing in Canada. He writes regularly at leancompliance.ca .

The Future of Compliance - Digital Threads In response to the Grenfell Tower Fire, the UK government recently introduced new regulations and a new regulator to address shortcomings in building safety. This new safety regime is intended to prevent the occurrence of incidents similar to the Grenfell Tower disaster that resulted in 72 deaths in 2017. Among the measures that this regulation introduces is what is being called, "A Golden Thread." This is in fact a "Digital Thread" the first of its kind to be used by regulators to improve compliance. The future of compliance looks like it is here so let's find out what digital threads are all about and why it is so important for compliance. What is a Digital Thread? To understand digital threads we first need to understand digital twins. What is a Digital Thread The concept of digital twins is attributed to Michael Grieves based on a presentation he made in 2002 at the University of Michigan. In this presentation he proposed the digital twin as a conceptual model underlying a product life-cycle with three components: real space, virtual space, and the data between and about them. However, the idea of modelling the real-world with computer simulation is not new and can go back to as early as1960s when NASA used basic concepts of twinning in the development of its space program. What makes digital twins different from computer-based modelling are the connections between the real and virtual worlds. In essence, a model becomes a digital twin when it connected with its real life counterpart. This connection closes the loop and is referred to as the digital thread. How are digital twins and threads defined today? Digital Twin The definition commonly used in defence, aerospace and related industries in the US is: “an integrated multiphysics, multiscale, probabilistic simulation of an as-built system, enabled by Digital Thread, that uses the best available models, sensor information, and input data to mirror and predict activities/performance over the life of its corresponding physical twin.” A digital twin is a virtual representation of real-world entities and processes, synchronized at a specified frequency and fidelity. This synchronization is enabled by a digital thread infrastructure or framework. Digital Thread The digital thread is used to refer to the lowest level design specification for a digital representation of a physical item. The digital thread is a critical capability in model-based systems engineering (MBSE) and the foundation for a digital twin. However, the term digital thread is also used to describe the traceability of the digital twin back to the requirements, parts and control systems that make up the physical asset. It is this latter aspect which is of significance for compliance specifically where traceability and accountability are regulated. Regulatory Use of Digital Threads: UK Building Safety In 2021 the UK Parliament introduced the Building Safety Bill to address shortfalls in building safety not limited to but largely in response to the Grenfall Tower Fire in 2017. This bill introduces a new regulator and regulation with the purpose that safety is ensured throughout every stage of a building's life. It also addresses specific failures with the lack of accountability and compliance throughout design, construction, and operations. UK - The Golden Thread The concept of a digital thread will now be part of this regulatory regime to provide traceability of information so that nothing falls between the cracks. This digital thread is not necessarily part of a digital twin but will instead become a measure of compliance and a critical one. Using the name "Golden Thread" to describe this particular application makes sense. It is an idea or feature that is present in all parts of something, holds it together and gives it value (Oxford's Learner's Dictionary); and in this case the value is improved safety. The Building Safety Bill further defines The Golden Thread: Full Definition: The golden thread is both the information that allows you to understand a building and the steps needed to keep both the building and people safe, now and in the future. The golden thread will hold the information that those responsible for the building require to: (a) how that the building was compliant with applicable building regulations during its construction and provide evidence of meeting the requirements of the new building control route throughout the design and construction and refurbishment of a building (b) Identify, understand, manage, and mitigate building safety risks in order to prevent or reduce the severity of the consequences of fire spread or structural collapse throughout the life cycle of a building The information stored in the golden thread will be reviewed and managed so that the information retained, at all times, achieves these purposes. The golden thread covers both the information and documents, and the information management processes (or steps) used to support building safety. The golden thread information should be stored as structured digital information. It will be stored, managed, maintained, and retained in line with the golden thread principles (see below). The government will specify digital standards which will provide guidance on how the principles can be met. The golden thread information management approach will apply through design, construction, occupation, refurbishment, and ongoing management of buildings. It supports the wider changes in the regime to promote a culture of building safety. Building safety should be taken to include the fire and structural safety of a building and the safety of all the people in or in the vicinity of a building (including emergency responders). Many people will need to access the golden thread to update and share golden thread information throughout a building’s lifecycle, including but not limited to building managers, architects, contractors, and many others. Information from the golden thread will also need to be shared by the Accountable Person with other relevant people including residents and emergency responders. The Golden Thread is based on the following principles which you could also consider as system properties: Principles: Accurate and Trusted: the dutyholder/Accountable Person/Building Safety Managers and other relevant persons (e.g. contractors) must be able to use the golden thread to maintain and manage building safety and ensure compliance with building regulations. The Regulator should also be able to use this information as part of their work to assess the compliance with building regulations, the safety of the building and the operator’s safety case report, including supportive evidence, and to hold people to account. The golden thread will be a source of evidence to show how building safety risks are understood and how they are being managed on an ongoing basis. The golden thread must be accurate and trusted so that relevant people use it. The information produced will therefore have to be accurate, structured, and verified, requiring a clear change control process that sets out how and when information is updated and who should update and check the information. Residents feeling secure in their homes : residents will be provided information from the golden thread – so that they have accurate and trusted information about their home. This will also support residents in holding Accountable Persons and Building Safety Managers to account for building safety. A properly maintained golden thread should support Accountable Persons in providing residents the assurance that their building is being managed safely. Culture change : the golden thread will support culture change within the industry as it will require increased competence and capability, different working practices, updated processes and a focus on information management and control. The golden thread should be considered an enabler for better and more collaborative working. Single source of truth: the golden thread will bring all information together in a single place meaning there is always a ‘single source of truth’. It will record changes (i.e. updates, additions or deletions to information, data, documents and plans), including the reason for change, evaluation of change, date of change, and the decision-making process. This will reduce the duplication of information (email updates and multiple documents) and help drive improved accountability, responsibility and a new working culture. Persons responsible for a building are encouraged to use common data environments to ensure there is controlled access to a single source of truth. Secure: the golden thread must be secure, with sufficient protocols in place to protect personal information and control access to maintain the security of the building or residents. It should also comply with current GDPR legislation where required. Accountable: the golden thread will record changes (i.e. updates, additions or deletions to information, data, documents and plans), when these changes were made, and by who. This will help drive improved accountability. The new regime is setting out clear duties for dutyholders and Accountable Person for maintaining the golden thread information to meet the required standards. Therefore, there is accountability at every level – from the Client/Accountable Person to those designing, building or maintaining a building. Understandable/consistent: the golden thread needs to support the user in their task of managing building safety and compliance with building regulations. The information in the golden thread must be clear, understandable and focused on the needs of the user. It should be presented in a way that can be understood, and used by, users. To support this, dutyholders/Accountable person should where possible make sure the golden thread uses standard methods, processes and consistent terminology so that those working with multiple buildings can more easily understand and use the information consistently and effectively. Simple to access (accessible) : the golden thread needs to support the user in their task of managing building safety and therefore the information in the golden thread must be accessible so that people can easily find the right information at the right time. This means that the information needs to be stored in a structured way (like a library) so people can easily find, update and extract the right information. To support this the government will set out guidance on how people can apply digital standards to ensure their golden thread meets these principles. Longevity/durability and shareability of information: the golden thread information needs to be formatted in a way that can be easily handed over and maintained over the entire lifetime of a building. In practical terms, this is likely to mean that it needs to align with the rules around open data and the principles of interoperability – so that information can be handed over in the future and still be accessed. Information should be able to be shared and accessed by contractors who use different software and if the building is sold the golden thread information must be accessible to the new owner. This does not mean everything about a building and its history needs to be kept, the golden thread must be reviewed to ensure that the information within it is still relevant and useful. Relevant/proportionate : preserving the golden thread does not mean everything about a building and its history needs to be kept and updated from inception to disposal. The objective of the golden thread is building safety and therefore if information is no longer relevant to building safety it does not need to be kept. The golden thread, the changes to it and processes related to it must be reviewed periodically to ensure that the information comprising it remains relevant and useful. These definitions and principles will help set the direction for how digital threads will be built in the compliance domain not only within the UK but also other jurisdictions. What Digital Threads Mean For Compliance Evidence of compliance has always been needed and this means more than attestations as the way to verify that what should have been done was actually done. This approach was always to slow, too late and not always accurate. And that is why the concept of a Golden Thread as a means t o provide evidence and assurance of compliance throughout the design, building and maintenance of buildings is a game changer. However, it will still take time for digital thread infrastructures to be established particularly those that meet the properties outlined for the UK's Golden Thread. At one level digital threads are still retrospective and on the lagging side of risk events. However, they could become more than feed-back processes particularly for downstream activities. When combined with digital twins they could become feed-forward and provide predictive utility particularly when to improve and validate design models. At a minimum digital threads will provide more up-to-date and reliable information for all stakeholders during every stage of building's life cycle. Now that we have defined purpose and properties for digital threads in the compliance domain it is likely that "Golden Threads" will become part of other regulator regimes. Medical device manufacturers are already using digital threads to provide traceability across DHF, DMR, and DHRs. There are also examples of digital threads in Oil & Gas and other regulated industries with respect to safety-critical data. In addition, using digital threads as part of Management of Change (MOC) process may help ensure design integrity as a result of planned changes. Instead of trying to integrate systems together, digital threads may provide a more effective means for compliance critical information to be made available not only as evidence of compliance but as a proactive measure to prevent risk. Proactive organizations should begin to plan pilot projects to explore how digital threads would be used in response to regulatory reforms but also as part of their own internal compliance efforts. If you are interested in developing and implementing digital thread strategies please contact our project management office to learn how Lean Compliance can help. References: GoldenThread.co.uk Developing a Digital Twin and Digital Thread Framework for an ‘Industry 4.0’ Shipyard What Are Digital Twins and Digital Threads? Industry 4.0 How to navigate digitization of the manufacturing sector

When it comes to selecting commercial-off-the-shelf (COTS) compliance software there was a time when this involved a structured process based on a requirements-first approach. This has now been largely replaced with a demo-first approach encouraged by cloud vendors as well as by the buyers themselves. Instead of a bake-off compared against requirements, software is now chosen based on how well the software demos and looks. Does this approach result in better outcomes? Let's find out. Requirements-first Approach: A requirements-first approach typically includes the following steps: Request for Information (RFI) – survey of the market to identify candidate vendors and solutions Request for Proposal (RFP) – request for written responses to requirements from identified long list of candidate vendors. Short Listing – a short list is created based on the selection criteria rubric Request for Quotation (RFQ) – obtain firm and final pricing from the short listed vendors Live Test Demonstration (LTD) – make sure the short list of vendors actually meet the stated requirements by following a scripted walk-through. Select Apparent Winning Offeror – selection of the best alternative based on vendor performance, fit for purpose, and technical requirements. Pilot System - validation that the solution can achieve the intended outcomes as well as the verified technical requirements. The purpose of following these steps is to manage risk inherent in selecting a solution that best fits the scope, budget, and requirements. In addition, it also creates level of playing field, keeping everyone honest on both sides of the table. The following data is a compilation across 20 projects that followed a requirements-first approach: * Waterfall = Gated, Structured Approach * Hybrid = Gated, Agile Approach Key lessons learned from these projects include: System scope was the major influence in determining overall procurement cycle time. However, there is only an incremental increase (8 versus 12 months) when considering departmental versus platform solutions. The overall duration was largely determined by vendor and buyer schedules Waterfall approach using approval gates was preferred the larger the project scope In addition, 90% of projects did not purchase their first choice for reasons that included: Failed live test data (LTD) – RFP responses was good but based on software that was not yet available or didn't withstand scrutiny of actual use. Failed pilot system due to poorly understood or specified requirements Requirements changed during the procurement process It is worthwhile stating that each project completed successfully even though it was not with the first choice of vendor. Having a second choice proved to be a significant factor when mitigating the uncertainties experienced during the procurement process. Demo-first Approach: These days it seems that many companies jump right to requesting a demonstration of software without first understanding what it is that they need. While this may prove successful for some applications, when it comes to critical compliance solutions at the scale of the enterprise this can lead to decisions that are less than optimal and waste valuable time, resources, and possibly exposing companies to unnecessary risk. Companies who have used the demo-first approach have noted that these projects tend to produce the following: Scope creep – everyone wants all the capabilities that they see demonstrated Difficulty in making an apples to apples comparison of the alternatives Cost overruns due to unplanned integration, customization, and data migration Schedule overruns leading to late ROI and in many cases unrealized benefits Solutions that only meets rudimentary requirements and not capable of meeting the full demands of the organization Loss of data and information due to insufficient planning and resourcing for data cleansing and migration activities In addition, projects still end up taking the same amount of time to procure a solution as with a requirements-first approach. Although, in the case of a demo-first approach they tend not to follow a risk-based process. This makes them vulnerable to uncertainties that an RFP, LTD, and Pilot steps would have discovered. Companies have also noticed an increased tendency to choose software that may have: demoed the best, had the most capabilities, had the lowest initial cost, or the one that was used at the last company that someone worked at. In other words, without a set of requirements there was no basis on which to make an effective comparison based on actual and anticipated need. It would be reasonable to ask why companies would choose a less rigorous process for selecting compliance solutions. Here are some of the reasons given: Our current system doesn't work and we need something else but we don't know what that looks like I don't know what I need so looking at software helps me figure that out All I want is something that is user friendly. I expect the vendor to know what my requirements are. This is off-the-shelf-software so why do I need to write down any requirements. Don't they all do the same thing. I am just looking to replace what I currently have so those are my requirements We are looking at cloud-based software and the subscription costs don't warrant a large project Our business analysts used to do that but we don't have those roles anymore I don't have the time to go through a structured process. We are following an agile approach which means we don't need to figure out what are requirements are right now Even if it the software doesn't work we can replace it easily because its all in the cloud As more organizations move their systems over to the cloud it is expected that the use of a demo-first approach will increase. Of course each company will have different levels of success, however, the probability of success can still be improved by effectively managing uncertainties specifically with respect to scope. Risk-Based Approach: Acquiring software to support critical compliance processes still requires that risks be properly addressed. The most significant source of risk hasn't changed and is still scope creep or scope gallop as it often the case. Managing scope is essential to every project and this applies to choosing compliance software. Software demonstrations can be an effective way to learn about what is available in the marketplace. This in many ways has replaced the use of RFIs. However, demos do not replace the need to specify what the software needs to do or the need to manage risk. Requirements may not be as detailed as they once were and may take the form such as user stories. At the same time, they still must be sufficient to cover what the software contractually needs to deliver and how it needs to perform in order to achieved the desired outcomes. It is always good to remember that you are not the product the software is. In addition, as previously noted, it is a good strategy to always have a second choice because your first choice is likely not the one that will achieve the desired outcomes. Whether you follow a demo-first or requirements-first approach or not you still need to get answers to the same set of questions. The timing of when you get these answers will significantly influence the success of your project. If you wait until after you purchase the software you will need to deal with the effects of not knowing or what is called, "epistemic uncertainty." The risk of not knowing can and often leads to failed projects that in many cases doubles the cost since the project has to be done over again. Here is list of items that some companies chose not to know in advance: The importance of integration with other systems and consequently neglected during the procurement phase The value associated with legacy data leading to no budget for data migration The loss of control over how processes are implemented resulting in the using vendor generic workflows The impact of using generic approaches that were sub-standard to the company's higher standards The lack of understanding of how an on-demand pricing model would be affected by a fixed operating budget The lack of understanding of how the software is going to be transitioned and rolled-out All of these could have been known in advance and addressed using a requirement-first, risk-based approach. Here is a list of things that you should know when selecting compliance technology: 1. What defines success? What are the intended outcomes for the system? What defines what done looks like? How do you measure progress towards done? What steps are critical to achieving done? What risks need to be addressed that hinder achieving done? What opportunities should be pursued to increase the likelihood of getting to done? 2. What is the purpose for the software purchase? Technology replacement? Architecture alignment? Process improvement? Improved compliance? New capabilities? Increase or decrease in scale or complexity? Cost reduction? Introduction of best practice?. Point solution or platform to support multiple solutions.? 3. What are all the requirements for the expected use of the software? System, application, process, and other functional requirements? Compliance, security, data, privacy, and sovereignty requirements? Platform, network, communication, and other technical requirements? Performance, and reliability requirements? Customization, and integration requirements? Implementation, sustaining, and end-of-life requirements? Backup and recovery requirements? 4. What strategies will be used to introduce and sustain the use of the software? Lift and Shift - Improve processes first then shift? Shift and Lift - Shift to the new software first and then improve processes? All users at once or a phased roll-out? All modules at once or a phased roll-out? Distributed or centralized support? Business owners or IT support? 4. What are the impacts and risks associated with the choice in software, implementation strategies, and sustaining activities on the business What gaps in requirements need to be addressed by customization, work-around, or additional software? What is the total cost and budget needed to sustain and use this software over its anticipated lifetime? How is compliance maintained during and after the implementation? How will changes to the software or configurations be managed and validated? What actions are needed to address uncertainty in: capabilities, cost, user acceptance. ability to meet compliance obligations, and so on? Who owns the data and will the data be monetized by the vendor? How and when will breaches in service be communicated? What is your exit strategy and when will this be triggered should you need to revert to your second choice?

Digital Transformation Over the last several decades companies have invested in paper-on-glass solutions as part of their digital progression. However, what only a few companies have done is change their processes to exploit the power of their digital technology. Dr. Goldratt, developer of the Theory of Constraints, speaks to this issue directly: "Technology can bring benefit if, and only if, it diminishes a limitation. Long before the availability of technology, we developed modes of behavior (policies, measurements and rules) to help us accommodate our limitations. But what benefits will any technology bring if we neglect to change the rules?" To achieve the benefits from technology, Dr. Goldratt suggests answering the following questions: What is the power of the technology? What limitation does the technology diminish? What rules enabled us to manage this limitation? What new rules will we need? The answer to the last question is most critical. To increase your return on investment from digital transformation you must change the way you currently do things. To do otherwise will: Limit your benefits to efficiency at the expense of improving effectiveness. As an example, converting paper forms to electronic forms and routing them around electronically may improve overall process time but will not achieve the benefits available using the power of the new technology. One of the limitations that paper-based systems had was its inability to use data to adapt the process to contend with risk. This often manifested itself in having complicated processes to accommodate every situation along with the need to incorporate multiple layers of approvals. However, using digital technology, it is possible to adapt work processes and incorporate the appropriate level of approvals based on collected information to contend with different levels of risk. Risk-based Process By removing the limitation of static workflows companies can benefit from using adaptive work processes resulting in even greater efficiency but also increased effectiveness at contending with uncertainty.

Compliance is the outcome of meeting obligations which requires compliance to be operational. Compliance operability is achieved when essential functions, behaviours, and interactions exist at levels sufficient to produce a measure of effectiveness – this defines Minimum Viable Compliance (MVC). Traditional approaches never reach MVC until the very end which is too slow and often too late to protect value creation and stay ahead of risk. The good news is there is a better way to do compliance that delivers benefits sooner, with greater certainty, and less waste. This approach is based on Lean Startup model by Eric Ries which we have adapted to the compliance domain as shown in the following diagram: Traditional versus Operational Approach to Compliance The traditional approach is based on implementing components or the parts of the compliance function starting at the bottom and advancing in capability and maturity until the last phase is reached. This is when effectiveness happens as measured against realized outcomes. This is also when effectiveness can start to improve over time. The operational approach is based on first achieving operability which is the minimum level of capability for creating outcomes - a measure of effectiveness. Advancement in capability and maturity happens across all functions, behaviours, and interactions always tied to realizing higher levels of effectiveness. This provides the maximum amount of learning with the minimum amount of cost creating less waste while delivering benefits sooner. The operational approach has improved the development of products and services particularly when contending with uncertainty and achieving outcomes are important. This is the case for all organizations under performance and outcome-based regulation.

Assurance is not an activity that compliance does or something that can be inspected into a business. It is an outcome that is created when stakeholders have confidence that an organization is meeting all its obligations today and will continue to be meet them in the future. This confidence is necessary for assurance and ultimately for trust to exist. Assurance is an OUTCOME not an ACTIVITY That's why confidence levels are an important measure of success for all risk & compliance programs. Improving the level of confidence is therefore an important objective which often involves conducting audits to verify process outputs and validate program outcomes. However, conformance to procedures and processes, as important as that may be, are not enough to provide the necessary confidence for trust to be granted. Confidence is increased when companies take steps to make certain that promises are kept. This has more to do with improving the probability that the organization is heading in the right direction, operating between the lines, and is making progress towards its mission objectives. The best way that this is demonstrated is by having an operational compliance program to properly contend with obligation and operational risk. An effective compliance program will ensure that required capabilities and performance exist to meet all obligations today and in the future. These capabilities will include resiliency, sustainability, quality, safety, diversity, or any of the abilities that contend with the risks that matter to the organization. Measuring effectiveness of these capabilities is not something that traditional audit or assurance functions have done. However, this is what is now required to provide confidence that the business has a future. To improve the outcome of assurance the following questions need to be answered: What is the level of confidence that your organization will meet all of its obligations? What capabilities do you need to ensure that you will meet your obligations in the future? What measures can you take to make certain you can keep all your promises? What resources do you need to provide the necessary capabilities and measures? How will you evaluate your progress towards greater levels of assurance?

AI Assistants - Blessing or Curse? The rise of Generative AI has taken the world by storm, and AI assistants are popping up all over the place, providing a new way for people to approach their work. These assistants automate repetitive and time-consuming tasks, enabling individuals to focus on more complex and creative work. However, for some, it is just an improvement in productivity, and they question whether the use of AI assistants may lead to them losing their jobs. For those starting to use AI assistants, they are indeed a blessing, providing much-needed relief for overworked employees. The improved productivity is creating needed capacity and some extra space in already full workloads. However, this is expected to be short-lived as these benefits become normalized and expected. The buffer we now experience will be consumed and used for something – the question is what? No wonder there is a fear that the widespread use of AI assistants may lead to significant job reductions. Some jobs will be redundant, while others will be expected to double their workloads. For instance, if someone used to write ten articles a week, they may now be expected to do twenty using AI assistants. So, where is the real gain for the organization apart from fewer people and perhaps marginal cost reductions? Is this the same story of bottom line rather than top-line thinking. How To Use AI Assistants To Achieve Better Outcomes The key to realizing transformational benefits of AI lies in adapting businesses to fully exploit the capabilities of these tools, without exploiting the people impacted by the technology. Dr. Eliyahu Goldratt (Father of the Theory of Constraints) believed that technology could only bring benefits if it diminished a limitation. Therefore, organizations must ask critical questions to exploit the power of AI technology: What is the power of the new technology? What limitation does the technology diminish? What rules enabled us to manage this limitation? And most importantly, what new rules will we now need? Keeping the old limitations that we had before the new technology limits the benefits we can realize. It is by removing the old rules and adopting new ones that creates transformational benefits. By providing credible answers to these questions, organizations can achieve a return on investment that is both efficient and effective, enabling their employees to focus on higher-level tasks and achieve more significant outcomes – higher returns not just lower costs. This will enable companies to move beyond the short-lived relief of AI and realize its true potential as a transformational tool. Which Path Will You Take? The use of AI will be a threat for some but an opportunity for others. If history repeats itself many organizations will adopt AI assistants, realize the efficiency gains, and pat themselves on the back for a short-term win. However, as these benefits become normalized they will soon be back to where they began. Any gains they might have realized will be lost and they will be left doing more with less except now with their new AI assistant. On the other hand, there will be others who asked the right questions, changed existing processes, and created new rules that will enable them to reap the full benefits of AI technology. They will realize compounding benefits that will accrue over time. What the future holds will depend on which path you take and your willingness to take a longer term perspective focused on improving outcomes rather than just reducing costs. Which path will you take?