SEARCH

There are times when leadership sets their gaze on operations in order to better delight their customers, increase margins, or improve operational excellence. This gaze for many companies has translated into a journey of continuous improvement – the playground for LEAN. All across the world companies have embraced LEAN principles and practices in almost every business sector. In many cases, LEAN initiatives have produced remarkable results and for some created a new “way of organizational life.” Continuous improvement has become a centring force as a means for aligning a company’s workforce with management objectives. With this success, the mantra of continuous improvement has expanded, along with the LEAN tools and practices, to other areas of the business such as: quality, safety, environmental, regulatory and other compliance functions. However, in these cases, LEAN has not helped as much as it could and in fact in some cases has made things worse. The problem has not been with the translation of Japanese words such as “Gemba”, “Kaizen”, “Muda”, “Muri”, and others. Instead, the problem is with the translation of LEAN itself. The objectives, principles, and practices that have worked on the production floor where improvement is measured by cycle time reductions has not been as effective when applied to areas where improvement is measured by the reduction in risk. The following are key areas where inadequate translations have caused confusion resulting in a lack of effectiveness when applying LEAN: Value Improvement Uncertainty Objectives Translating Value When it comes to compliance programs the translation of such things as: “value”, “value stream”, “waste” , “flow” and “customer” are not as obvious or as easy to see compared to what happens on a production floor. Some LEAN practitioners chose not to do a translation and instead consider everything only from a “manufacturing” point of view. This means that everything that does not directly “touch a product” is considered as non-value added which makes almost everything else “waste.” Using a “narrow” definition has led LEAN teams to remove essential activities and outcomes such as: evidentiary artifacts needed to verify compliance risk measures needed to protect the value stream activities needed to meet compliance objectives preventive risk controls tasks that are occasionally used (ex. risk assessments) tasks where people have forgotten its purpose critical to compliance activities Translating Improvement Without an adequate translation for value some practitioners choose "simplification” as a guiding principle for process improvement. Unfortunately, after simplification has been completed what often remains is a process that does very little to advance any outcome, let alone those associated with compliance obligations. However, there is one outcome that is advanced and that is the possibility of risk. Over-simplification (a source of improvement waste) can create new or expose existing vulnerabilities that threaten value creation. Companies may end up with more risk than any productivity improvement they might have realized by the elimination of “waste.” Translating Uncertainty The value chain is responsible for creating value in the eyes of a company’s stakeholders and it does so in the presence of uncertainty. Productivity programs serve the value chain by improving margins through operational excellence and LEAN initiatives. Margins are necessary to mitigate the effects of aleatory (i.e. irreducible) uncertainty. It also affords an organization a degree of resilience against disruption. While the removal of waste can improve financial margins, many LEAN practitioners may not properly recognize the use of margins (extra time, extra capacity, extra resources, ..etc.) put in place to contend with uncertainty. As a result any gains in financial margins will be lost (and often more) to address the disruption when uncertainty does become a reality and there is no margin in place to attenuate its effects. Compliance is considered as necessary, but a waste from a LEAN perspective. However, compliance programs serve the value chain by mitigating the effects of epistemic (i.e. reducible) uncertainty. It does this by buying down risk through effective quality, safety, security, environmental, and regulatory systems and processes. Without margins or the buying down of risk companies are less resilient and are more vulnerable to threats to value creation. Translating Objectives LEAN can be applied to all processes provided that effective translations are made to the domain where LEAN is being applied. When it comes to compliance programs it is important to recognize that the primary objective is to eliminate and reduce risk rather than "waste". The following chart contains translations for other LEAN objectives as applied to the compliance domain: LEAN practitioners would do well to consider the impact of risk when engaged in process improvement that involves compliance obligations. Compliance processes will still contain traditional sources of "waste." Therefore, risk specialists would also benefit from applying LEAN to existing risk control processes to improve detection and response times to better prevent risk as well as mitigate its effects. You might say that since every process operates in the presence of uncertainty, LEAN practitioners should all be risk managers. You could say that risk is the cause of the waste which LEAN has traditionally focused on eliminating.

Compliance Effectiveness Gap Compliance has been heading in a new direction over the last decade. It's moving beyond paper and procedural compliance towards performance and operational compliance.   This change is necessary to accommodate modern risk-based regulatory designs, which elevate outcomes and performance over instructions and rules.   Instead of checking boxes, compliance needed to become operational, which is something that LEAN, along with Operational Excellence principles and practices, helps to establish.   As LEAN endeavours to eliminate operational waste, those who are accountable for mission success have noticed that such things as defects, violations, incidents, injuries, fines, and misconduct are also wastes that take away from the value businesses strive to create.   This waste results predominately from a misalignment between organizational values and operational objectives. You can call this business integrity, which at its core is a lack of effective regulation – The Compliance Effectiveness Gap. Total Value Chain The Problem with Compliance   In a nutshell, compliance should ensure mission success, not hinder it.   Over the years compliance has come alongside the value chain in the form of programs associated with safety, security, sustainability, quality, legal adherence, ethics, and now responsible AI.   However, many organizations experience that these programs operate re-actively, separately, and disconnected from the purpose of protecting and ensuring mission success - the creation of value. They are misaligned not only in terms of program outcomes, but also with respect with business value.   This creates waste in the form of duplication of effort, technology, tools, and executive attention. However, perhaps more importantly, the lack of effectiveness ends up creating the conditions for non-conformance, defects, incidents, injuries, legal violations, misconduct, and business uncertainty.   Closing – The Compliance Effectiveness Gap – is now a strategic objective for organizations who are looking to maximize value creation.   A Program by a New Name   To prioritize this objective, we have renamed our advanced program from: "The Proactive Certainty Program™" to "The Total Value Compliance Program™"   This program builds on our previous work and adds a Value Operational Assessment to identify operational capabilities needed to close – The Compliance Effectiveness Gap  – the gap between organizational values and operational objectives.   With greater alignment (a measure of integrity), uncertainty decreases, risk is reduced, waste eliminated, and value maximized.   The First Step   The first step toward closing The Compliance Effectiveness Gap  is a:   TOTAL VALUE COMPLIANCE AUDIT This is not a traditional audit.   Instead, this is a 10-week participatory engagement (4 hours per week investment), where compliance program & obligation owners, managers, and teams (depending on the package chosen) will actively engage in learning, evaluation, and development of a detailed roadmap to compliance operability – compliance that is capable of being effective. The deliverables you receive include: Executive / Management Education  (Operational Compliance) Integrative Program Evaluation  (Values Operations Alignment) Total Value Compliance Roadmap  (Minimal Viable Compliance Operability) The compounding value you will enjoy: Turning compliance from a roadblock into a business accelerator Aligning your values with your operations for better business integrity Creating competitive advantage, and greater stakeholder trust Enabling innovation and productivity instead of hindering them Are you ready to finally close The Compliance Effective Gap ?

Why Is This Assessment Necessary? For compliance to be effective, it must generate desired outcomes. These outcomes may include reducing violations and breaches, minimizing identity thefts, enhancing integrity, and ultimately fostering greater stakeholder trust. Realizing these benefits requires compliance to function as more than just the sum of its parts. Unfortunately, many organizations focus solely on individual components rather than the whole system – they see the trees but miss the forest, or concentrate on controls instead of the overall program. Too often, compliance teams work hard and hope for the best. While hope is admirable, it's an inadequate strategy for ensuring concrete outcomes. To elevate above merely a collection of parts, compliance needs to operate as a cohesive system. In this context, operability is defined as the extent to which the compliance function is fit for purpose, capable of achieving compliance objectives, and able to realize the benefits of being compliant. The minimum level of compliance operability is achieved when: All essential functions, behaviors, and interactions exist and perform at levels necessary to create the intended outcomes of compliance. This defines what is known as Minimal Viable Compliance (MVC) , which must be reached, sustained, and then advanced to realize better outcomes. For this to occur, we need a comprehensive approach. We need: Governance to set the direction Programs to steer the efforts Systems to keep operations between the lines Processes to help stay ahead of risks All of these elements must work together as an integrated whole. To use an analogy, an effective compliance system may not need to be as complex as a car, but it should be at least as functional as a bicycle. The key point is that it must be more than just a box of disconnected car or bicycle parts. This holistic perspective on compliance operability allows organizations to: Identify gaps with their current compliance Prioritize areas for improvement Ensure that all components of the compliance system are working in harmony Continuously improve and adapt their compliance efforts to meet changing requirements and expectations By conducting a Compliance Operability Assessmen t, organizations can move beyond a piecemeal approach to compliance and develop a robust, systemic strategy that is more likely to achieve desired outcomes and create lasting value. Total Value Chain Analysis Total Value Chain Analysis Value Chain Analysis (VCA), introduced by Michael E. Porter in 1985, is a strategic tool that examines how a firm's activities contribute to its competitive advantage. Porter argued that competitive advantage stems from cost leadership and differentiation, and VCA helps understand how various activities affect a company's margin. This concept has been foundational in helping businesses optimize their operations and improve their market position. In recent years, the increasing complexity and demands of regulatory compliance have necessitated an adaptation of Porter's model. This has led to the development of Total Value Chain Analysis, which integrates compliance activities into the traditional value chain framework. Unlike the original model, which often viewed compliance as a separate, overhead function, this new approach considers compliance as a set of horizontal capabilities that span the entire value chain. The focus shifts from purely optimizing margin to also minimizing overall risk. Total Value Chain Analysis offers several key insights. It helps organizations understand the true cost of both compliance and non-compliance, illustrates how compliance activities affect risk across different business functions, and demonstrates the value of compliance in terms of cost avoidance, increased trust, and reduction in defects, incidents, and other negative outcomes. This holistic view allows companies to develop more comprehensive strategies for competitive advantage. Building on Porter's strategies for cost and differentiation advantage, Compliance Chain Analysis introduces the concept of compliance advantage. This new perspective suggests ten principles for driving compliance advantage, including keeping all promises, taking ownership of compliance obligations, integrating compliance into performance processes, and developing a learning culture around compliance. By adhering to these principles, companies can create a robust compliance framework that not only meets regulatory requirements but also contributes to overall business success. The Total Value Chain concept provides an integrated approach, combining traditional VCA with a strong focus on compliance. While this strategy may not always lead to immediate cost reductions, it offers significant long-term benefits. Companies can avoid future costs associated with non-compliance and differentiate themselves in the market through higher quality products and services, safer operations, and improved stakeholder trust. In today's highly regulated marketplace, this comprehensive approach to value chain and compliance management provides a powerful tool for creating and sustaining competitive advantage. Compliance Operability Assessment Process The Compliance Operability Assessment Process uses the Total Value Chain Analysis as its foundation. This comprehensive approach helps evaluate the level of compliance operability and maturity for all compliance obligations, both mandatory and voluntary. Compliance Operability Assessment Process The process consists of the following steps: 1. Identify Business Requirements This initial step involves understanding the core business needs, objectives, and strategic goals of the organization. It provides context for how compliance fits into the overall business model. 2. Create Operations Business Model In this step, we identify and map out the operational functions, behaviours, and interactions within the organization. This creates a clear picture of how the business operates on a day-to-day basis. 3. Identify Compliance Requirements Here, we determine all relevant compliance requirements that apply to the organization. This includes industry-specific regulations, general legal obligations, along with voluntary commitments made to stakeholders. 4. Create Obligations and Promises Register This step involves creating a comprehensive register that identifies: Legal and regulatory obligations along with voluntary commitments made to stakeholders Promises and policies created associated with meeting obligations and stakeholder commitments Areas of uncertainty in staying between the lines and ahead of risk Potential compliance and operational risk associated with meeting obligations and stakeholder commitments 5. Evaluate and Map Compliance Criticality In this step, we assess what is critical-to-compliance (description below). This helps prioritize compliance efforts and resource allocation to focus on those areas that matter most to staying between the lines and ahead of risk. 6. Create Integrated Operational Compliance Model This step involves integrating the compliance requirements into the operational business model. It shows how compliance obligations interact with and affect day-to-day business and how obligations will be met and keeping promises associated with them. T 7. Evaluate Compliance Operability The final step is to assess how well the integrated compliance model functions within the organization. This evaluation helps identify areas of strength and weakness in the compliance program, and guides future improvement efforts. By following this structured process, organizations can gain a holistic view of their compliance landscape and how it integrates with their business operations. This approach allows for: Better alignment between compliance efforts and business objectives Identification of potential gaps or overlaps in compliance activities More efficient resource allocation for compliance management Improved ability to anticipate and mitigate compliance risks Enhanced overall effectiveness of the compliance program The Compliance Operability Assessment Process provides a systematic method for organizations to move beyond a checkbox approach to compliance. Instead, it fosters the development of a mature, integrated compliance system that adds value to the organization while effectively managing regulatory and stakeholder obligations. Compliance Criticality Analysis The concept of compliance criticality is often encountered in various contexts, similar to other "Critical-to-X" frameworks: Critical-to-Quality (CTQ) Critical-to-Safety (CTS) Critical-to-Environment (CTE) Critical-to-Sustainability Critical-to-Value And others Critical-to-Compliance  refers to: essential structures, functions, behaviours, or interactions that directly impact an organization's ability to meet obligations or keep promises. Compliance Criticality Map Examples include organizational structure, roles, culture, governance, programs, systems, processes, procedures, protocols, resources, capacity, goals, priorities, and strategy. The importance of Critical-to-Compliance can be understood through several key benefits: Change Management : By identifying critical-to-compliance elements, organizations can prioritize efforts to mitigate risks and prevent non-compliance when implementing planned changes. Resource Optimization : Focusing on critical-to-compliance elements helps organizations avoid wasting time and resources on less significant areas, ensuring that compliance efforts are concentrated on what matters most. Risk Management: Understanding which elements are critical-to-compliance allows organizations to establish necessary controls, reducing the probability of non-conformance and mitigating high-impact risks. Comprehensive Coverage : Identifying critical-to-compliance elements helps organizations ensure that all essential capabilities are in place to meet relevant regulatory requirements and voluntary stakeholder obligations. Enhanced Confidence : Recognizing and addressing critical-to-compliance aspects demonstrates an organization's commitment to meeting obligations and keeping promises. To assess the importance of different elements, a criticality ranking can be applied: Critical : Discontinuing or substantially changing this aspect will result in a high likelihood of failure to meet compliance obligations or keep promises. Significant : Discontinuing or substantially changing this aspect will significantly affect the ability to meet compliance obligations or keep promises. Moderate : Discontinuing or substantially changing this aspect will moderately affect the ability to meet compliance obligations or keep promises. Not Significant : Discontinuing or substantially changing this aspect will not significantly affect the ability to meet compliance obligations or keep promises. By utilizing this framework, organizations can effectively prioritize their compliance efforts and ensure they are focusing on the most crucial aspects of their operations. Operational Compliance Maturity Regulatory bodies and standards organizations are increasingly expecting companies to utilize capability maturity models to enhance performance and progress towards ambitious targets such as zero incidents, zero fatalities, zero harm, zero emissions, and zero violations. While capability maturity models have been around for some time, their application in compliance improvement has been limited. However, this trend is beginning to change. One area where capability maturity models have been successfully employed is in software development, particularly in aerospace and defence applications. The CMMI (Capability Maturity Model Integration) Institute, building on research originally conducted by Carnegie Mellon University, continues to develop and publish maturity models. In response to the shift towards outcome and performance-based regulatory obligations, we have adapted the CMMI model to better support the capabilities needed to advance outcomes over time. It's important to note that certain minimum operability requirements must be met before any significant progress in outcomes can be achieved. Fundamentally, better outcomes are obtained when processes function more like a purposeful system rather than as individual components. This principle is derived from systems theory, which posits that outcomes are emergent properties resulting from the product of a system's interactions, rather than simply the sum of its parts. The following model provides a framework for organizations to assess their current compliance maturity level and identify areas for improvement, ultimately working towards more effective and efficient compliance management. Operational Compliance Maturity Operational Compliance Maturity Model: 5 - Leading: Advancing Outcomes Advancing overall compliance outcomes Reducing risk and ensuring value Continuous innovation and learning at all organizational levels 4 - Governing: Regulating Effectiveness Tracking compliance outcomes Introducing feed-forward processes to improve effectiveness Focusing on achieving outcomes and improving capabilities Continuous improvement is ingrained in organizational culture 3 - Managing: Regulating Performance Standards provide guidance and normative practices and behaviours Introducing feedback processes to improve consistency Focusing on compliance performance and risk management Continuous improvement is intentional and proactive 2 - Controlling: Regulating Conformance Planning, performing, measuring, and controlling compliance processes Defining and mostly following compliance procedures Focusing on inspections, audits, and corrective actions Continuous improvement is reactive 1 - Perceiving: Recognizing Obligations Developing obligation and risk awareness Focusing on prescriptive compliance and training Work is completed but often delayed or over budget Procedures are sometimes followed with unpredictable output or outcomes 0 - Avoiding: Unknown Lack of obligation and risk awareness Obligations may or may not be achieved Procedures are rarely followed Compliance risk is unknown Conclusion The Compliance Operability Assessment using Total Value Chain and Compliance Criticality Analysis provides organizations with a comprehensive framework to evaluate and enhance their compliance efforts. By integrating compliance into the broader business strategy and operations, this approach moves beyond traditional checkbox compliance to create a more robust, effective, and value-driven compliance system. The process outlined - from identifying business requirements to evaluating compliance operability - allows organizations to gain a holistic view of their compliance landscape. This systematic method helps align compliance efforts with business objectives, identify gaps and overlaps in compliance activities, optimize resource allocation, and improve risk management. Furthermore, the introduction of concepts like Minimal Viable Compliance (MVC), Compliance Criticality Analysis, and the Operational Compliance Maturity Model provides organizations with concrete tools to assess their current state and chart a path for improvement. These individual frameworks enable companies to prioritize their compliance efforts, focusing on the most critical aspects that directly impact their ability to meet obligations and keep promises. As regulatory environments continue to evolve and stakeholder expectations increase, this integrated approach to compliance management becomes increasingly vital. By viewing compliance as an integral part of the value chain rather than a separate overhead function, organizations can not only meet their regulatory obligations but also create competitive advantage. This shift in perspective transforms compliance from a cost centre into a strategic asset that contributes to overall business success, fosters stakeholder trust, and drives continuous improvement across the organization. The is now part of our Total Value Compliance Program.

The software engineering and related domains are undergoing their most dramatic transformation in decades. In discussions I have had over the last year, IT product companies appear to be moving towards an AI first model. As AI capabilities rapidly advance, a stark prediction is emerging from industry leaders: AI Engineering may soon become the dominant—perhaps only remaining—engineering discipline in many IT domains. How Product Teams Are Already Changing Looking at how IT technology companies are adapting to AI uncovers an interesting pattern: teams of three to five people are building products that traditionally required much larger engineering groups. The traditional model—where product managers coordinate with software engineers, UI designers, data analysts, DevOps specialists, and scrum leaders—is being replaced by something fundamentally different. Instead, these companies operate with product managers working directly with AI Engineers who can orchestrate entire development lifecycles. These professionals are learning to master a new set of skills: AI system design (architecting intelligent solutions from requirements), AI integration (embedding capabilities seamlessly into products), and AI operations (managing and maintaining AI-powered systems at scale). Companies like Vercel, Replit, and dozens of Y Combinator startups demonstrate this model in action daily. What once required full engineering teams now happens through sophisticated prompt engineering and AI orchestration. A Pattern We've Seen Before This transformation feels familiar because I lived through something similar in integrated circuit manufacturing. In the early days, I worked for an integrated circuits manufacturing in Canada where they at first designed circuits by hand, built prototypes in physical labs, and painstakingly transferred designs to mylar tape for silicon fabrication. This process required teams of specialists: layout technicians, CAD operators, lab engineers—each role seemingly indispensable. Over the years, each function was improved as computer technology was adopted. We started using circuit simulation, computer-aided design with automated design rule checking, and wafer fabrication layout tools. This is not unlike how organizations are now adopting AI to improve individual tasks and functions. Then silicon compilers arrived and changed everything overnight. Suddenly, engineers could create entire circuit designs by simply describing what the circuit should accomplish using Hardware Description Languages like VHDL and Verilog. The compiler handled layout optimization, timing analysis, and fabrication preparation automatically. The entire process could be automated. From ideation to the fab in one step. Entire job categories vanished, but the engineers who adapted became exponentially more productive. ONE-SPRINT MVP Today's product development is following a similar pattern. AI Engineers translate application requirements through sophisticated prompts into working minimum viable products (MVPs) – one-sprint MVP. This approach is resulting in fewer people to deliver working solutions faster while supporting rapid iteration cycles that make even Agile development methodologies feel glacially slow. The Tools Driving This Shift The evidence surrounds us. GitHub Copilot and Cursor generate entire codebases from natural language descriptions. Vercel's V0 creates production-ready React components from simple prompts. Claude Artifacts builds functional prototypes through conversation. Replit Agent handles full-stack development tasks autonomously. These aren't novelty demos—they're production tools that engineers use to create real products for customers to use. However, this is just the beginning. Where Traditional Engineering Still Matters Now this wave won't wash away all engineering domains equally. Critical areas will maintain their need for specialized expertise: embedded systems interfacing with hardware, high-performance computing requiring deep optimization, safety-critical applications in aerospace and medical devices, large-scale infrastructure architecture, and cybersecurity frameworks. But the domains most vulnerable to AI consolidation—web applications, mobile apps, data pipelines, standard enterprise software, code creation, and prototype development—represent the majority of current engineering employment. The Economic Forces at Play The economics driving this shift are brutal in their simplicity. When a single AI Engineer can deliver 80% of what a five-person traditional team produces, at a fraction of the cost and timeline, market forces make the choice inevitable. This isn't a gradual transition that companies will deliberate over for years. Organizations that successfully implement AI-first methodologies will out-compete those clinging to traditional approaches. The advantage gap widens daily as AI capabilities improve and more teams discover these efficiencies. Venture capital flows increasingly toward AI-first startups with lean technical teams, while traditional software companies scramble to demonstrate AI integration strategies or risk irrelevance. Survival Strategies in an AI-First World AI represents a genuine threat to traditional engineering careers. The question isn't whether disruption will occur, but how to position yourself to survive and thrive as AI-first methodologies become standard practice. Critical survival tactics: Immediate actions (next 6-12 months): Master AI tools now  - Become proficient with GitHub Copilot, Claude, ChatGPT, and emerging AI development platforms Learn prompt engineering  - This is becoming as fundamental as learning programming languages once was Shift to AI-augmented workflows  - Don't just use AI as a helper; restructure how you approach problems entirely Build AI system integration skills  - Focus on connecting AI components rather than building from scratch Strategic positioning (1-2 years): Become an AI Engineer  - Align your engineering practice from traditional engineering to AI system design; adopt AI engineering knowledge and methods into your practice Specialize in AI reliability and maintenance  - AI systems need monitoring, debugging, and optimization Develop AI model customization expertise  - Fine-tuning, prompt optimization, and model selection Master AI-human collaboration patterns  - Understanding when to use AI vs. when human expertise is still required Why Waiting Is Dangerous Critics point to legitimate current limitations: AI-generated code often lacks production robustness, complex integrations still require deep expertise, and security considerations demand human judgment. These concerns echo the early objections to silicon compilers, which initially produced inferior results compared to expert human designers. But here's what history teaches us: the technology improved rapidly and soon exceeded human capabilities in most scenarios. The engineers who adapted early secured the valuable remaining roles. Those who waited found themselves competing against both improved tools and colleagues who had already mastered them. Understanding the Challenge This isn't another gradual technology transition that engineers can adapt to over several years. AI-first methodologies represent a substantial challenge to traditional engineering roles, with the potential for significant displacement across the industry. The reality:  Engineers who don't adapt may find themselves competing against AI-first approaches, systems and tools that operate continuously, require no salaries or benefits, and improve steadily. This will be an increasingly difficult competition to win. The opportunity:  Engineers who proactively embrace AI-first approaches will be better positioned to secure valuable roles in the evolving landscape. Leading this transformation offers better prospects than waiting for external pressure to force change. The window for proactive adaptation becomes smaller with time. Each month of delay reduces competitive advantage as AI capabilities advance and more engineers begin their own transformation journeys. The choice ahead is significant: evolve into an AI Engineer who works with intelligent systems, or risk being replaced by someone who does. Raimund Laqua, PMP, P.Eng is co-founder of ProfessionalEngineers.AI (ray@professionalengineers.ai) a Canadian engineering practice focused on advancing AI engineering in Canada. Raimund Laqua, is also founder of Lean Compliance ( ray.laqua@leancompliance.ca ), a Canadian consulting practice focused on helping orgnizations operating in highly-regulated, high risk sectors always stay ahead of risk, between the lines, and on-mission.

Operational Compliance Organizations investing in compliance often have legitimate questions about how the Operational Compliance Model relates to their existing frameworks, tools, and investments. These questions reflect the reality that most organizations have already implemented various compliance approaches—ISO management standards, GRC platforms, COSO frameworks, Three Lines of Defence models, and others. Rather than viewing these as competing approaches, the Operational Compliance Model serves as an integrative architecture that amplifies the value of existing investments while addressing fundamental gaps that prevent compliance from achieving its intended outcomes. The following responses explore how Operational Compliance works with, enhances, and elevates traditional approaches to create the socio-technical systems necessary for sustainable mission and compliance success. Responses to Questions "Why can I not use an ISO management systems standard?" ISO management standards are excellent for procedural compliance  but fall short of achieving operational compliance . Operational Compliance defines a state of operability when all essential compliance functions, behaviours, and interactions exist and perform at levels necessary to create the outcomes of compliance. The fundamental limitation is that ISO standards focus on building parts of a system  (processes, procedures, documentation) rather than the interactions between parts  that create actual outcomes. Companies usually run out of time, money, and motivation to move beyond implementing the parts of a system to implementing the interactions which is essential for a system to be considered operational. ISO standards help you pass audits, but the Operational Compliance Model helps you achieve the outcomes those audits are supposed to ensure—better safety, security, sustainability, quality, and stakeholder trust. "Doesn't GRC cover this, at least for IT obligations?" GRC (Governance, Risk, and Compliance) platforms are tools, not operational models. Traditional "Procedural Compliance" is based on a reactive model for compliance that sits apart and is not embedded within the business. Most GRC implementations create sophisticated reporting systems but don't address the fundamental challenge: how to make compliance integral to value creation . The Operational Compliance Model recognizes that obligations arise from four types of regulatory design (micro-means, micro-ends, macro-means, macro-ends) that each require different approaches. GRC tools can support this model, but they can't create the socio-technical processes that actually regulate organizational effort toward desired outcomes. "I already have dozens of frameworks" This objection actually proves the need for the Operational Compliance Model. Having dozens of frameworks is precisely the problem—it creates framework proliferation  without operational integration . Lean TCM incorporates an Operational Compliance Model that supports all obligation types and commitments using design principles derived from systems theory and modern regulatory designs. The Operational Compliance Model doesn't replace your frameworks; it provides the integrative architecture  to make them work together as a system rather than competing silos. It's the difference between having a collection of car parts versus having a functioning vehicle. "What about COSO? This already provides an overarching framework?" COSO is excellent for internal control over financial reporting  but was designed primarily for audit and governance purposes. The Operational Compliance Model addresses several limitations of COSO: Scope : COSO focuses on control activities; Operational Compliance focuses on outcome creation Integration : COSO's five components work within compliance functions; Operational Compliance embeds compliance into operations Regulatory Design : COSO assumes one type of obligation; Operational Compliance handles four distinct types that require different approaches Uncertainty : COSO manages risk; Operational Compliance improves probability of success  in uncertain environments COSO can be a component within the Operational Compliance Model, but it's insufficient by itself to achieve operational compliance. "What about Audit 3 Lines of Defence?" The Three Lines of Defence model is fundamentally reactive —it's designed to catch problems after they occur. Operational Compliance is based on a holistic and proactive model that defines compliance as integral to the value chain. The limitations of Three Lines of Defence: Line 1  (operations) sees compliance as separate from their real work Line 2  (risk/compliance) monitors rather than enables performance Line 3  (audit) confirms what went wrong after the fact The Operational Compliance Model collapses these artificial lines  by making compliance inherent to operational processes. Instead of three defensive lines, you get one integrated system  where compliance enables rather than constrains performance. The Essential Difference For compliance to be effective, it must first be operational—achieved when all essential compliance functions, behaviours, and interactions exist and perform at levels necessary to create the outcomes of compliance. The majority of existing frameworks and models serve important functions, but they operate within the procedural compliance paradigm . The Operational Compliance Model represents a paradigm shift  from compliance as overhead to compliance as value creation—from meeting obligations to achieving outcomes.

When a technology can reshape entire industries, automate critical decisions, and potentially act autonomously in the physical world, how we define it matters. Yet our current approach to defining artificial intelligence is fundamentally flawed—and this definitional confusion is creating dangerous blind spots in how we regulate, engineer, deploy, and think about AI systems. We can always reduce complex systems to their constituent parts, each of which can be analyzed further. However, the problem is not with the parts but with the whole. Consider how we approach regulation: we don't just regulate individual components—we regulate systems based on their emergent capabilities and potential impacts. Take automobiles. We don't primarily regulate steel, rubber, or microchips. We regulate vehicles because of what they can do: transport people at high speeds, potentially causing harm. A car moving at 70 mph represents an entirely different category of risk than the same steel and plastic sitting motionless in a factory. The emergent property of high-speed movement, not the individual components, drives our regulatory approach. The same principle should apply to artificial intelligence, but currently doesn't. Today's definitions focus on algorithms, neural networks, and training data rather than on what AI systems can actually accomplish. This reductionist thinking creates a dangerous category error that leaves us unprepared for the systems we're building. The Challenge of Definition Today's AI definitions focus on technical components rather than capabilities and behaviours. This is like defining a car as "metal, plastic, and electronic components" instead of "a system capable of autonomous movement that can transport people and cargo." This reductionist approach creates real problems. When regulators examine AI systems, they often focus on whether the software meets certain technical standards rather than asking: what can this system actually do? what goals might it pursue? How might it interact with the world? And, what are the risks of this impact? Defining AI properly is challenging because we're dealing with systems that emulate knowledge and intelligence—concepts that remain elusive even in human contexts. But the difficulty isn't in having intelligent systems; it's in understanding what these systems might do with their capabilities. A Fundamental Category Error What we have is a category failure. We have not done our due diligence to properly classify what AI represents—which is ironic, since classification is precisely what machine learning systems excel at. We lack the foundational work needed for proper AI governance. Before we can develop effective policies, we need a clear conceptual framework (an ontology) that describes what AI systems are and how they relate to each other. From this foundation, we can build a classification system (a taxonomy) that groups AI systems by their actual capabilities rather than their technical implementations. Currently, we treat all AI systems similarly, whether they're simple recommendation algorithms or sophisticated systems capable of autonomous planning and action. This is like having the same safety regulations for bicycles and fighter jets because both involve "transportation technology." The Agentic AI Challenge Let's consider autonomous AI agents—systems that can set their own goals and take actions to achieve them. A customer service chatbot that can only respond to pre-defined queries is fundamentally different from an AI system that can analyze market conditions, formulate investment strategies, and execute trades autonomously. These agentic systems represent a qualitatively different category of risk. Unlike traditional software that follows predetermined paths, they can exhibit emergent behaviours that even their creators didn't anticipate. When we deploy such systems in critical infrastructure—financial markets, power grids, transportation networks—we're essentially allowing non-human entities to make consequential decisions about human welfare. The typical response is that AI can make decisions better and faster than humans. This misses the crucial point: current AI systems don't make value-based decisions in any meaningful sense. They optimize for programmed objectives without understanding broader context, moral implications, or unintended consequences. They don't distinguish between achieving goals through beneficial versus harmful means. Rethinking Regulatory Frameworks Current AI regulation resembles early internet governance—focused on technical standards rather than systemic impacts. We need an approach more like nuclear energy regulation, which recognizes that the same underlying technology can power cities or destroy them. Nuclear regulation doesn't focus primarily on uranium atoms or reactor components. Instead, it creates frameworks around containment, safety systems, operator licensing, and emergency response—all based on understanding the technology's potential for both benefit and catastrophic harm. For AI, this means developing regulatory categories based on capability rather than implementation. A system's ability to act autonomously in high-stakes environments matters more than whether it uses transformers, reinforcement learning, or symbolic reasoning. The European Union's AI Act represents significant progress toward this vision. It establishes a risk-based framework with four categories—unacceptable, high, limited, and minimal risk—moving beyond purely technical definitions toward impact-based classification. The Act prohibits clearly dangerous practices like social scoring and cognitive manipulation while requiring strict oversight for high-risk applications in critical infrastructure, healthcare, and employment. However, the EU approach still doesn't fully solve our category failure problem. While it recognizes "systemic risks" from advanced AI models, it primarily identifies these risks through computational thresholds rather than emergent capabilities. The Act also doesn't systematically address the autonomy-agency spectrum that makes certain AI systems particularly concerning—the difference between a system that can set its own goals versus one that merely optimizes predefined objectives. Most notably, the Act treats powerful general-purpose AI models like GPT-4 as requiring transparency rather than the stringent safety measures applied to high-risk systems. This potentially under-regulates foundation models that could be readily configured for autonomous operation in critical domains. The regulatory framework remains a strong first step, but the fundamental challenge of properly categorizing AI by what it can do rather than how it's built remains only partially addressed. Toward Engineering-Based Solutions How do we apply rigorous engineering principles to build reliable, trustworthy AI systems? The engineering method is fundamentally an integrative and synthesis process that considers the whole as well as the parts. Unlike reductionist approaches that focus solely on components, engineering emphasizes understanding how parts interact to create emergent system behaviors, identifying failure modes across the entire system, building in safety margins, and designing systems that fail safely rather than catastrophically. This requires several concrete steps: Capability-based classification:  Group AI systems by what they can do—autonomous decision-making, goal-setting, real-world action—rather than how they're built. Risk-proportionate oversight:  Apply more stringent requirements to systems with greater autonomy and potential impact, similar to how we regulate medical devices or aviation systems. Mandatory transparency for high-risk systems:  Require clear documentation of an AI system's goals, constraints, and decision-making processes, especially for systems operating in critical domains. Human oversight requirements:  Establish clear protocols for meaningful human control over consequential decisions, recognizing that "human in the loop" can mean many different things. Moving Forward The path forward requires abandoning our component-focused approach to AI governance. Just as we don't regulate nuclear power by studying individual atoms, we shouldn't regulate AI by examining only algorithms and datasets. We need frameworks that address AI systems as integrated wholes—their emergent capabilities, their potential for autonomous action, and their capacity to pursue goals that may diverge from human intentions. Only by properly categorizing what we're building can we ensure that artificial intelligence enhances human flourishing rather than undermining it. The stakes are too high for continued definitional confusion. As AI capabilities rapidly advance, our conceptual frameworks and regulatory approaches must evolve to match the actual nature and potential impact of these systems. The alternative is governance by accident rather than design—a luxury we can no longer afford.

Lean Compliance Reflections I often think about the future of Lean Compliance, especially lately as I feel compliance is approaching a turning point, where we’ve always been heading but now faster due to AI. In this article, I consider the future of Lean Compliance in the context of where regulators are heading, where industry is at, what industry now needs, and what Lean Compliance offers. Navigating this space has not only shaped our company's direction but also highlighted the fundamental challenge facing compliance professionals today: an industry caught between old habits and new realities. The Vision Behind Lean Compliance I founded Lean Compliance (2017) because I saw an industry trapped in an outdated paradigm. Too many organizations treat compliance as a documentation exercise—paper-based, procedural, reactive. They've built systems around checking boxes rather than meeting obligations and managing actual risk. Now, this was not necessarily their fault. Regulations, a significant source of obligations, were for the most part rules-based and prescriptive enforced by adherence audits. However, obligations were changing and organizations needed a different approach to how compliance and risk should be managed. Our goal was to support the inevitable transition toward performance and outcome-based obligations, helping companies move beyond mere documentation toward demonstrating real progress in advancing obligation outcomes. We recognized that compliance should be integrated into business operations right from the start, rather than treated as a separate function in need of future integration. In addition, we saw how effective compliance could enable organizations operate with greater confidence when they genuinely understood and managed their risks, which is primarily a proactive and integrative behaviour. Where Regulators Are Leading Regulators have been signalling a clear direction for several decades, particularly in high-risk sectors. They're moving away from prescriptive, one-size-fits-all requirements toward performance and outcome-based obligations that focus on effectiveness over process, assurance over documentation, and managed risk over compliance theatre. This paradigm shift presents opportunities for organizations that can adapt to these changing expectations. Those that can demonstrate real effectiveness in realizing obligation outcomes—rather than just following procedures—will find themselves better positioned as regulations continue to evolve. Where the Market Remains Yet most organizations (along with external auditors) are still entrenched in paper-based and procedural compliance even when performance and outcome-based obligations are specified. While there is comfort in the known, viewing everything through a prescriptive lens prevents organizations from realizing the benefits of being in compliance. This contributes to why many who pass audits and achieve certifications seldom improve the object under regulation: safety, security, sustainability, quality, legal, and now responsible AI obligations. The market reflects this reality in what it's asking for: technology-first solutions that promise productivity improvements without fundamental change. Companies want tools that take away reactive pain—the scramble to respond to audit findings, the stress of regulatory examinations, the endless documentation requirements. They're looking for ways to do what they've always done, just faster and with less manual effort. This creates both opportunity and challenge. While there's clear appetite for improvement, there's resistance to the deeper transformation that truly effective compliance requires. The Territory We Inhabit Operational Compliance Lean Compliance operates in the space between regulatory direction and market reality. Rather than being another consulting company promising incremental improvements, we focus on bridging this gap through awareness, education, transformation, and community building. We've found that many organizations simply aren't aware of how significant the gap has become between their current practices and regulatory and stakeholder expectations. Our work often begins with helping them understand where they stand and what opportunities exist. The educational component has proven essential because many don't know what being proactive, integrative or operational looks like in practice. Sustainable change requires obligation owners who understand both the rationale behind obligations along with how to operationalize it. We're not just implementing disconnected controls—we're building systems that deliver on compliance. The transformation programs we created provide structured approaches for moving from procedural to operational compliance. This involves more than new tools—it requires rethinking governance, programs, systems, and processes, and often rebuilding organizational culture around continuously meeting obligations and keeping promises. We're also working to build a community of practice among compliance professionals who are navigating similar challenges. This community serves as a source of continued learning and peer support as the profession evolves. Looking Ahead The gap between regulatory expectations and current market practices continues to widen. Organizations that remain focused on paper-based, procedural approaches will continue to struggle as regulators increasingly demand evidence of effectiveness rather than just documentation.   This challenge becomes particularly evident when considering emerging obligations from AI regulations and stakeholder expectations. Meeting these obligations using paper-based, procedural compliance simply won't be enough. Compliance will require demonstrating actual performance and outcomes—how AI systems behave in practice, not just what policies exist on paper. This reality further highlights the need for operational compliance approaches.   There seems to be increasing recognition that compliance needs to evolve toward operational approaches—where organizations invest in building systems that deliver on promises to meet obligations rather than on documentation alone. Increasingly more are beginning to view compliance as increasing the probability of meeting business objectives rather than simply constraining them.   The question is not whether, but rather how long will industry continue in its reactive, siloed, and procedural ways before it embraces the shift toward operational compliance? And will this now be shortened due to AI?   The organizations that embrace operational compliance now will be better positioned to turn meeting obligations into business advantages while preserving value creation. This shift offers an opportunity to move from reactive to proactive approaches, where compliance supports rather than hinders business objectives. This transformation needs informed leadership and new approaches to compliance, which we’ve been preparing for over the past decade. This is why Lean Compliance is uniquely positioned to guide organizations through this critical transition. At Lean Compliance, we're always looking to connect with organizations and professionals grappling with these same tensions. If you're interested in exploring what operational compliance means for your specific context, let's start the conversation.

As AI systems evolve from simple tools into autonomous agents capable of independent decision-making and action, we face a fundamental choice in how we approach AI safety and reliability. Current approaches rely on guardrails—external constraints, rules, and control mechanisms designed to prevent AI systems from doing harm. But as AI agents increasingly become the actual means by which organizations and individuals fulfill their promises and obligations, we can consider a different approach: promise fulfillment architectures embedded within the agents themselves. This represents a shift from asking: "How do we prevent AI from doing wrong?" to "How do we enable AI to reliably meet obligations?" Promise Theory , developed by Mark Burgess and recognized by Raimund Laqua (Founder of Lean Compliance) as an essential concept in operational compliance, offers a powerful framework for understanding this fundamental transformation—where AI agents serve as the operational means for keeping commitments rather than simply entities that need to be controlled through external guardrails. The Architecture of Compliance Promise Theory reveals that compliance follows a fundamental three-part structure: Obligation → Promise → Compliance This architecture exists, although it is not often explicit in current compliance frameworks. Obligations create the need for action, promises define how that need will be met, and compliance is the actual execution of those promises. Understanding this helps us see that compliance is never just "rule-following"—it's always the fulfillment of some underlying promise structure. When we apply this lens to AI agents, we discover something significant. Consider an AI agent managing customer service operations. This agent isn't just "following business rules"—it has become the actual means by which the company fulfills its promises to customers. The company has obligations to resolve issues and maintain service quality. The AI agent becomes the means of fulfilling promises made to meet these obligations through specific commitments about response times, solution quality, and escalation protocols. Compliance is the AI agent's successful execution of these promises, making it the operational mechanism through which the company keeps its commitments. Unlike current AI systems that respond to prompts, agentic AI agents must serve as the reliable fulfillment mechanism across extended periods of autonomous operation. The agent doesn't just make its own promises—it becomes the operational means by which organizational promises get kept. From External Constraints to Internal Architecture Traditional AI safety approaches focus on external constraints and control mechanisms. But understanding AI agents as promise fulfillment mechanisms highlights the need for a fundamental shift in system design. Instead of guardrails as external constraints, we need promise fulfillment architectures embedded in the AI systems themselves. This perspective shows that effective AI agents require internal promise fulfillment architectures—systems designed from the ground up to serve as reliable promise delivery mechanisms. When AI agents are designed as promise fulfillment mechanisms, they become the operational means by which promises get kept rather than entities that happen to follow rules. This becomes crucial when organizations depend on agents as their primary mechanism for keeping commitments and meeting obligations. For agentic AI, promise fulfillment architecture becomes the foundation that enables agents to serve as reliable operational mechanisms for keeping promises. Instead of relying on external monitoring and control, we build agents whose core purpose is to function as the means by which promises get fulfilled autonomously and reliably. Promise Networks in Multi-Agent Systems When multiple AI agents work together, Promise Theory helps us see how they can serve as the operational means for fulfilling complex, interconnected promises. Rather than monolithic compliance, we see networks of agents serving as fulfillment mechanisms for interdependent promises. An analysis agent serves as the means for fulfilling promises about accurate data interpretation, while a planning agent fulfills promises about generating feasible action sequences, and an execution agent fulfills promises about carrying out plans within specified parameters. Each agent's function as a promise fulfillment mechanism enables other agents to serve as fulfillment mechanisms for their own promises. System-level promise fulfillment emerges from this network of agents serving as operational means for keeping commitments. This becomes especially important in agentic AI systems where multiple agents must coordinate as the collective means for fulfilling organizational promises without constant human oversight. In fact, they must operationalize the commitments the organization has made regarding its obligations, particularly with respect to the “Duty of Care.” Operational Compliance Through Promise Theory Raimund Laqua's work in Lean Compliance emphasizes Promise Theory as essential to understanding operational compliance. In this framework, operational compliance is fundamentally about making and keeping promises to meet obligations—operationalizing obligations through concrete commitments. Operational Compliance This transforms how we analyze AI agent compliance. Traditional approaches view AI agents as executing programmed constraints and behavioral rules. The promise-keeping view shows AI agents operationalizing their obligations through promises and fulfilling those commitments while making autonomous decisions. The difference helps explain why some AI agents can be more reliable and trustworthy—they have clearer, more consistent promise structures that effectively operationalize their obligations and guide their autonomous behavior. AI Agents Enabling Human Promise Fulfillment Understanding AI agents through Promise Theory also helps us understand how AI agents function as reliable promise fulfillment mechanisms, they can enable human agents to meet their own obligations more effectively. This creates a symbiotic relationship where AI agents serve as the operational means for human promise-keeping. Consider a healthcare administrator who has obligations to ensure patient care quality, regulatory compliance, and operational efficiency. By deploying AI agents designed with promise fulfillment architectures, the administrator can rely on these systems to consistently deliver on specific commitments—maintaining patient records accurately, flagging compliance issues proactively, and optimizing resource allocation. The AI agents become the reliable mechanisms through which the human agent fulfills their broader organizational obligations. This relationship extends beyond simple task delegation. When AI agents are designed as promise fulfillment mechanisms, they provide humans with predictable, accountable partners in meeting complex obligations. The human can make promises to stakeholders with confidence because they have AI agents that reliably execute the operational components of those promises. This enables humans to take on more ambitious obligations and make more significant commitments, knowing they have trustworthy AI partners designed to help fulfill them. The key insight is that AI agents with embedded promise fulfillment architecture don't just complete tasks—they become part of the human's promise-keeping capability, extending what humans can reliably commit to and deliver on in their professional and organizational roles. Measuring Promise Assurance Understanding AI agent behavior through promise keeping enables evaluation approaches that go beyond simple reliability metrics to include assurance—our confidence in an agent's trustworthiness during autonomous operation. Promise consistency (promises kept / promises made) measures how reliably the agent fulfills its commitments across extended autonomous operation. Promise clarity examines how well the agent's commitments are communicated and understood. Promise adaptation evaluates how well the agent maintains its core commitments while adapting to new contexts during independent decision-making. Promise-keeping becomes not just a measure of performance, but a foundation for assurance in autonomous AI systems operating with reduced human oversight. This provides a more nuanced view of AI agent trustworthiness than simple rule-compliance measures. Promise Architectures: The Future of Agentic AI Promise Theory provides an analytical framework for understanding why compliance works the way it does. By revealing the hidden promise structures underlying all compliant behavior, it helps us design, evaluate, and improve AI systems more systematically. Rather than asking "Is the AI agent following the rules?" we can ask more nuanced questions about what obligations the agent is trying to fulfill, what promises it has made about fulfilling them, and how consistently it executes those promises across independent decisions. As we make AI agents more autonomous, we need to understand how they function as the operational means for fulfilling promises and design agentic systems with embedded promise fulfillment architecture. In a world of increasingly autonomous AI agents, understanding compliance through Promise Theory offers a path toward more reliable, predictable, and assured agentic behavior where agents serve as the primary operational mechanisms for fulfilling organizational and individual promises. Compliance is never just about following orders—it's always about keeping promises. Promise Theory helps us see those promises clearly, providing a foundation for building AI agents that function as effective promise fulfillment mechanisms where assurance comes from their demonstrated capability to serve as reliable means for keeping commitments rather than from imposed constraints. As AI systems become more agentic, this embedded promise fulfillment capability may prove to be the most effective approach to maintaining reliable, ethical, and trustworthy autonomous behavior that actively delivers on commitments.

A simple test to bust through the hype These days, AI providers, leaders, and evangelists claim that AI technology will transform any organization's operations. Just add AI to what you're doing, and everything gets better – like adding ketchup to your food. But here's what I discovered after reviewing AI implementation plans: most aren't actually about AI at all. They're generic digital transformation playbooks with "AI" replacing whatever technology was trendy last year. ⚡ The Ketchup Test The Ketchup Test I recently reviewed an AI plan from a major organization. It looked comprehensive at first – clear values, comprehensive strategies, concrete actions. Then I tried an experiment: I replaced every occurrence of " AI" with “ KETCHUP .” Original: Accelerate the integration and utilization of AI at scale Empower staff with knowledge, skills, and tools to rapidly deploy AI Grow an AI -first workforce to oversee and integrate AI throughout the enterprise After the Ketchup Test: Accelerate the integration and utilization of KETCHUP at scale Empower staff with knowledge, skills, and tools to rapidly deploy KETCHUP Grow a KETCHUP -first workforce to oversee and integrate KETCHUP throughout the enterprise Both versions read like legitimate strategic initiatives. That's the problem. ⚡ Why This Matters Real AI strategy requires addressing AI-specific challenges that don't apply to other technologies: How will you handle AI hallucinations in critical decisions? What's your approach to algorithmic bias detection? How will you maintain explainability for regulators? What happens when your models degrade over time? If your strategy doesn't address questions like these, you're not planning for AI – you're planning for generic technology that happens to be called AI. ⚡ AI Isn't Ketchup Too many organizations treat AI like a condiment – something you add to existing processes to make them "better." But AI isn't ketchup. It fundamentally changes how decisions are made and how humans interact with systems. It requires new governance, different risk management, and entirely new expertise. Adding AI to a poorly designed process doesn't improve it – it amplifies existing problems at machine speed. Ketchup won't turn a badly cooked steak into a good one. It just makes it worse, faster. ⚡ The Challenge Try the Ketchup Test on your AI strategy today. Replace "AI" with "KETCHUP and read it again. If it still makes sense, you have boilerplate, not an AI plan, and you have work to do. What you need is deep understanding of what AI actually is, how it works, its limitations, and its genuine benefits. Not everything is better with ketchup – and not everything needs AI. The organizations that succeed with AI won't be the ones with comprehensive plans taken from last year’s playbook. They'll be the ones that understand the technology well enough to know when and how to use it appropriately.

The distinction between Enterprise Resource Planning (ERP) and Governance, Risk, and Compliance (GRC) platforms reveals a fundamental difference in operational philosophy that has significant implications for organizational effectiveness. While both systems aim to ensure organizational obligations are met, they approach this goal from opposite directions. Proactive versus Reactive Compliance ERP: The Feed-Forward Compliance System Enterprise Resource Planning ERP systems exemplify feed-forward compliance architecture. They are operational systems designed around planning, forecasting, and ensuring product delivery by orchestrating all necessary resources at the right time, with the right specifications, and through the right processes. This forward-looking approach means ERP systems actively prevent problems before they occur. The feed-forward nature of ERP manifests in several ways. Production planning modules ensure materials are ordered and available before manufacturing begins. Financial planning components forecast cash flow needs and trigger procurement decisions. Human resource modules anticipate staffing requirements and initiate hiring processes. Each function is designed to identify requirements and deploy resources proactively, creating a continuous cycle of planning, execution, and adjustment that keeps operations flowing smoothly. GRC: The Feed-Back Compliance System Governance, Risk and Compliance In contrast, most GRC platforms operate as feed-back systems, focusing primarily on reporting and monitoring what has already occurred. These systems are fundamentally reactive rather than proactive, concentrating on audits, compliance reporting, and risk assessment after events have transpired. While this backward-looking approach provides valuable insights for accountability and learning, it often fails to prevent compliance failures or operational disruptions. The feed-back nature of traditional GRC systems creates inherent limitations. By the time a compliance violation is detected and reported, the damage may already be done. Risk assessments become exercises in documenting past failures rather than preventing future ones. Governance frameworks become bureaucratic reporting mechanisms rather than operational guidance systems that actively steer organizational behavior. The Operational Gap What becomes apparent when examining many GRC implementations is that they are not operational in the systems sense of the word. They lack the forward-looking, resource-orchestrating capabilities that make ERP systems effective operational tools. Instead of ensuring continuous meeting of obligations through proactive planning and resource allocation, GRC platforms often become elaborate documentation and reporting systems that react to problems after they manifest. This reactive posture explains why many organizations struggle with GRC effectiveness. When compliance and risk management are treated as reporting functions rather than operational imperatives, they become disconnected from the daily flow of business activities. The result is often a compliance program that exists parallel to, rather than integrated with, actual business operations. A Path Forward: Operational Compliance Operational Compliance GRC would benefit significantly from adopting more ERP-like characteristics. An Operational Compliance system would function as a feed-forward compliance engine, using planning and forecasting to ensure all obligation requirements and commitments are met, risks are mitigated before they materialize, and governance objectives are achieved through proactive resource allocation and process design. Such a system would anticipate compliance deadlines and automatically trigger necessary actions, allocate resources for risk mitigation activities before threats become critical, and integrate governance requirements directly into operational workflows. Instead of asking "Are we in compliance?" an Operational Compliance system would continuously ask "How do we meet all our obligations in the presence of uncertainty?” What's Next? The fundamental difference between feed-forward ERP systems and feed-back GRC platforms reflects deeper philosophical approaches to organizational management. While ERP systems actively shape future outcomes through proactive planning and resource orchestration, traditional GRC platforms remain trapped in reactive reporting cycles. Organizations seeking more effective governance, risk management, and compliance outcomes should consider how to make their GRC capabilities more operational and forward-looking, drawing inspiration from the proven effectiveness of ERP system design principles. The most successful organizations will be those that transform GRC from a backward-looking reporting function into a forward-looking operational capability that actively ensures continuous compliance and proactive risk management.

Minimal Viable Compliance / Performance Outcomes are the effects of capabilities which means that if you want to advance your outcomes you need to advance your capabilities. The purpose of a management program is to adjust system set-points to the values needed (i.e. Minimal Viable Performance - MVP) to achieve the desired outcomes. This works the same way that a thermostat works in your home. If you want to feel warmer you need to increase the thermostat to a higher value. It is then the responsibility of the heating system to first achieve and then maintain that value. This is called a persistent achievement obligation. You may find your compliance systems do not have the capabilities you need to achieve and then to maintain your higher standards. There are three categories of measures to help you know if your systems are operating at levels to meet persistent achievement obligations. These are: Measures of conformance - evidentiary artifacts that demonstrate conformance to requirements Measures of performance - abilities to meet compliance objectives Measures of effectiveness - progress against compliance outcomes towards zero: non-conformance, injuries, violations, emissions, etc. Internal and external audits mostly focus on verifying conformance. However, the purpose of the compliance function goes further to ensure that safety, quality, environmental, and regulatory systems are operating at the levels needed to achieve targeted outcomes. This requires an integrated approach focused not only on conformance to each element but also how each element performs in the context of the entire system.

Understanding compliance mindsets using set theory TLDR Those involved with compliance will eventually observe two different mindsets at work. Each one is concerned about compliance yet differ in their focus, goals, objectives and almost everything else. Both of these groups have something to offer but when not understood can create confusion and misalignment with respect to compliance. The first one is concerned with protecting the organization by staying between the lines. This one follows Compliance 1 practices as discussed in our recent post . The other wants to change the lines to achieve higher standards and better outcomes for all stakeholders. This one follows Compliance 2 practices. The first is all about following the rules and keeping things the same, the second one invites change to make progress. This has all the makings of conflict unless a way can be found for each to work together. Organizations that desire to meet all their stakeholder obligations will need to effectively contend with each compliance group. An integrative approach offers a path forward that recognizes the benefits of both when combined may increase the probability of an organization keeping all its promises. In this article, we will use the concept of social sets to better understand these two groups to see how they might work as one for the benefit of the organization as a whole. Social Sets Bounded-Set and Centred-Set The concept of sets and set theory is well established and used to describe collections of objects from which much of our mathematics is derived. Set theory is also used to better understand social groups and communities specifically using the concepts of bounded and centred sets. Roughly speaking, bounded-sets are defined by boundaries and our relation to them (in or out). Whereas centred-sets are defined by a centre (e.g. values) and our direction of movement relative to it (advancing towards or retreating away). For the purpose of discussion bounded and centred sets can be mapped to Compliance 1 and Compliance 2 practices as shown in the next figure: Bounded-Set Compliance versus Centred-Set Compliance We will explore each one in turn except the Fuzzy-set (C0) which describes a group not concerned about compliance. Bounded-set Compliance (C1) A bounded-set can be defined by these characteristics: A focus on boundaries - are we in or out? Static - evaluated at a fixed point in time Homogeneous practices, variety of values "Adherence” mindset Some say we tend to think mostly in terms of bounded-set categories. We think of characteristics that define one group compared with another. This seems to be the case for Compliance 1 which thinks of compliance in terms of passing a boundary (e.g. an audit) that defines whether or not we are in compliance or out. Boundaries in compliance consist of such things as: inspections, controls, management reviews, governance, obligations & risk registers, and so on. Evaluation is done at a point in time by identifying minimum thresholds and standards with respect to these characteristics. The bounded-set is hard at the edges and soft in the middle. It requires substantial training and discussion to create consistent behaviours conforming to desired standards. It also requires an “adherence” mindset. Community is created by adhering to common practices. Improvement is hard to define in the bounded-set. There is no change to see. Once you are "in compliance" what else is there to improve? Transformation if it exists at all is more about repairing the fences than moving the boundaries towards a higher standard or ideal. All this makes getting "in compliance" a barrier that is difficult for many to obtain. However, once it is achieved many consider the hard part to be done and what is left to do is only maintenance. Monitoring the boundaries and making repairs (i.e. closing gaps) are key activities for bounded-set compliance that are in the "in" group. Centred-set Compliance (C2) A centred-set can be defined by these characteristics: A focus on a centre (values, an ideal, etc.) - are we heading towards or away? Dynamic - evaluated using multiple points over time Homogeneous values, variety of practices “Progress” mindset Centred-set compliance is concerned by the direction you are heading towards or away from the centre or ideal. For compliance the direction either advances or hinders the creation of compliance outcomes identified by goals, targets, and objectives to create what we don't already have. Evaluation is based on measuring progress towards an ideal over a period of time. This requires multiple data points to confirm direction and progress. The centred-set is soft at the edges and hard at the middle (the ideal). Community is created by bringing people together based on commonly-shared interests and values. You might call this a “missional” mindset. Centred-set compliance requires educating stakeholders who are assumed to have a “bounded-set” mindset which creates additional challenges. Centred-set compliance is all about change which is necessary to make progress. However, transformation is less about improving what is and more about creating what isn't which is a riskier endeavour. Centred-set compliance has lower barriers to get started. All you need is a group of people who are passionate about creating stakeholder value. However, that is harder than it might seem. Passion alone is seldom enough. Trying to achieve ambitious (perhaps, even necessary) goals without a critical mass of support often will lead to failed initiatives. In addition, without structure and discipline these initiatives are often poorly managed which also contributes to failure. Is it one or the other or both or something else? When organizations begin to take ownership of their obligations they start their compliance journey usually with bounded-set compliance. The belief is that organizations benefit from structure and discipline to change values and behaviours. By repeating common practices a compliance culture and community is created. As organizations mature in their compliance they may find that they don’t need the structures as much to be their tutor. Organizational and personal conscience informed by previous habits and practices may replace adherence to prescriptive rules. Organizations may also now benefit from having a community to help keep them in line. However, a key problem is that values, beliefs, and community have all been shaped by practices around the boundaries. Organizations in the bounded-set face the wrong direction for advancing compliance outcomes. They are looking for holes in the wall and are not facing the direction they should be heading to meet all their obligations. No wonder this can be a source of conflict with centred-set compliance groups. Bounded-set compliance groups often do not realize that passing and maintaining the boundary was never the end but rather the beginning. There is a higher standard to obtain. Unfortunately, those in the bounded-set are often overwhelmed and preoccupied maintaining the boundaries (the walls) that they don’t have the resources to make any progress towards a "centre" no matter how important that may be. Conversely, organizations that start with a centred-set approach have their own advantages and disadvantages. One key advantage is that it attracts those who are passionate about the end goals although perhaps not so much about how to get there. Nevertheless, centred-set compliance groups can bring needed energy and enthusiasm to drive compliance to higher levels and achieve more. Centred-set compliance largest challenge is contending with bounded-set compliance groups. Centred-set compliance groups are often asked to metaphorically fit a square peg in a round hole with the hole being in the boundary and nowhere near the centre that they want to move towards. You may as well be speaking a different language. Transforming one group to the other appears to have many challenges many of which are similar to the challenges associated with combining two cultures. Left to themselves they will operate as silos independently and not benefit from the other. The solution for compliance may not be to add one to the other but have something else altogether. Integrative-set Compliance (C3) Clearly, compliance needs to stay between the lines AND change the lines simultaneously if it wants to meet all of its stakeholder obligations: mandatory and voluntary. What is needed is another set that is integrative in nature focused on the whole. Integrative means combining two or more things to form an effective unit or system – precisely what compliance needs. We can define this set by: A focus on the connections - are we working as a whole? Continuous assessment Integrative values and behaviours “Holistic” mindset It is by managing connections that organizations can harness the power of both bounded-set and centred-set compliance. This is not about achieving balance or adding one to the other. Instead, it is about establishing essential capabilities that work together to reinforce each other to achieve the objectives of both. Not simple, but not impossible either. Organizations that desire to meet all their stakeholder obligations will need to effectively contend with bounded-set and centre-set compliance groups. An integrative approach offers a path forward that recognizes the benefits of both when combined may increase the probability of an organization keeping all its promises.