SEARCH

If you're a compliance director or manager, you've probably noticed something frustrating: organizations can have excellent compliance documentation, pass audits, and still get surprised by violations. The gap isn't in what they document—it's in how regulatory obligations are embedded in operational capability. This is where integrative compliance  transforms everything. While traditional compliance creates separate activities that run parallel to operations, integrative compliance embeds regulatory obligations directly into operational capability itself. When you achieve integrative compliance, regulatory fulfillment becomes inseparable from value creation. Integrative Compliance What Is Integrative Compliance? Integrative compliance embeds regulatory obligations directly into operational capability rather than creating separate compliance activities. It's the difference between having environmental procedures that get referenced during audits versus having environmental obligations embedded in every production decision and automated control system. Compliance streams in integrative compliance represent the flow of promises (commitments) through your organization—and these promises can be fulfilled by humans, machines, or combinations of both.  A promise to "encrypt all personal data" might be fulfilled by automated systems. A promise to "conduct safety inspections" might be fulfilled by human operators. A promise to "maintain equipment reliability" might be fulfilled by predictive maintenance algorithms combined with human technicians. The Lean Compliance Operational Model  provides the framework for building integrative compliance through four essential dimensions that map to organizational levels: Governance Level → Compliance Outcomes:  What compliance results must we achieve? Program Level → Compliance Targets:  What performance measures demonstrate progress? System Level → Compliance Practices:  What standardized methods ensure capability? Process Level → Compliance Rules:  What specific actions must be taken? From Parallel Activities to Embedded Capability Lean Compliance Operational Model Here's the key point: integrative compliance only works when obligations are embedded in operational capability across all four dimensions.  You can't just add compliance activities alongside operations—you need to embed obligations into organizational capability itself. Consider environmental compliance for a manufacturing facility. Traditional compliance creates separate environmental activities: quarterly emissions monitoring, annual environmental training, periodic waste audits. These run parallel to production operations. Integrative compliance embeds environmental obligations directly into organizational capability through both human and machine promises: Process rules:  Automated systems continuously monitor emissions and classify waste in real-time, while operators follow specific handling procedures System practices:  Production scheduling systems incorporate environmental constraints using ISO 14001 practices, with human oversight and decision-making Program targets:  Monthly production targets include environmental performance metrics tracked by both automated monitoring and human verification Governance outcomes:  Business performance includes sustained environmental permit compliance demonstrated through machine-generated evidence and human attestation Now environmental compliance happens naturally as production happens. Regulatory obligations and operational capability are embedded together. The Power of Integrative Streams When operational compliance powers your compliance streams, you don't just get integrated activities—you create integrative streams  where value creation and compliance delivery become inseparable. This is the double helix of organizational DNA in action. Integrative Streams Synergistic Performance: with integrative streams, improving one stream automatically strengthens the other. Enhanced production processes simultaneously improve compliance outcomes like safety and quality. Better operational methods create both more efficient operations and stronger compliance capability. Investment in one stream pays dividends in both. Emergent Capabilities : Integrative streams create capabilities that neither stream could achieve alone. A manufacturing process with embedded compliance monitoring doesn't just meet regulatory requirements—it creates real-time visibility that enables faster optimization, predictive maintenance, and proactive risk management. Adaptive Resilience : When compliance and value streams are truly integrative, they adapt together to changing conditions. New regulations don't break operations—they become opportunities to strengthen both compliance and competitive advantage simultaneously. Real-Time Visibility: I nstead of discovering compliance problems weeks later during reviews, you know immediately when something's not working. If waste classification isn't happening during production, the production system alerts you in real-time. Predictable Performance : because compliance is embedded in operations, compliance performance becomes as predictable as operational performance. If your production process is reliable, your compliance delivery is reliable. Reduced Waste: You eliminate duplicate activities and conflicting priorities. Instead of production schedules that ignore environmental constraints (requiring later rework), you create schedules that optimize both production and environmental performance. Capability Building: Each operational improvement also improves compliance capability. When you enhance production quality, you simultaneously strengthen quality compliance. When you improve safety processes, you build safety compliance capability. Building Integrative Compliance The Lean Compliance Operational Model shows how to embed regulatory obligations in operational capability: 1. Start with Outcomes (Governance Level) What regulatory results must your organization achieve? Not just "be environmentally compliant," but specific outcomes like "maintain all environmental permits without violations" or "achieve zero unauthorized emissions." 2. Define Targets (Program Level) What performance measures will demonstrate you're achieving those outcomes? Monthly emission levels, waste diversion rates, incident-free days, permit renewal success. 3. Design Practices (System Level) What systematic methods will deliver those targets? This is where standards like ISO 14001 provide proven approaches to environmental management that can be integrated into operations. 4. Embed Rules (Process Level) What specific actions must happen during each operational task? Real-time monitoring, immediate classification, proper handling procedures, documentation requirements. 5. Create the Compliance Stream Each level must enable the one above it: rules enable practices, practices enable targets, targets deliver outcomes. And each level must be supported by the one below it: outcomes require targets, targets require practices, practices require rules. The Integrative Compliance Test Here's how you know if you have integrative compliance rather than just parallel compliance activities: Can compliance promises be demonstrated through normal operations?  Whether fulfilled by humans, machines, or both—can workers show how compliance is embedded in their work processes, and can systems demonstrate automated compliance delivery? Does improving operations also improve compliance?  When you enhance production efficiency or operational delivery, do compliance outcomes like safety and quality performance improve simultaneously? Can you predict compliance failures before they happen?  If operational performance degrades—whether human or machine—can you predict where compliance failures will occur? Is compliance visible in real-time?  Can you demonstrate current compliance status through both automated monitoring and human verification without waiting for the next audit or review? If you answered "no" to any of these, you have parallel compliance activities but not integrative compliance. The Bottom Line The future of compliance isn't better documentation or more audits—it's integrative compliance  that embeds mandatory and voluntary obligations directly in operational capability. When compliance obligations and operational capability are inseparable, you achieve the double helix of organizational DNA. Organizations that master integrative compliance don't choose between efficiency and compliance outcomes, between innovation and regulation, between speed and safety compliance. They achieve all of these because regulatory obligations are embedded in the operational capability that makes value creation and compliance delivery mutually reinforcing. Ready to move from parallel compliance activities to integrative compliance? Start with one critical obligation and embed it in operational capability across all four dimensions. The transformation will demonstrate why integrative compliance is the foundation for sustainable regulatory performance and business success. Ray Laqua, P.Eng, PMP | Lean Compliance Consulting Transforming regulatory obligations into operational capability

If you're a compliance director or manager in a highly regulated industry, you know this frustration: Your organization has procedures, training records, audit schedules, and risk assessments. You pass audits. Your management systems are certified. But violations still surprise you. You're constantly firefighting. And when leadership asks "are we actually meeting our obligations?" you can't answer with complete confidence. The problem isn't your competence. It's that most compliance approaches break obligations into disconnected parts—separate procedures, isolated training, independent audits. This reductive view creates gaps between requirements and reality, making it impossible to see how compliance actually flows through operations. The Solution: Compliance Streams Compliance & Value Streams Compliance streams  are the end-to-end flows of promises (commitments) that transform regulatory obligations into demonstrated outcomes, embedded within your operational value streams. Think of it like value stream mapping for compliance: instead of transforming materials into products, you're transforming regulatory obligations into operational capability and demonstrable compliance outcomes. A compliance stream creates a holistic, systems view that replaces the reductive approach of managing disconnected compliance parts. This creates an unbroken "golden thread of assurance" that connects regulatory requirements directly to operational evidence through clear promise flows. What Are Compliance Streams? A compliance stream  is fundamentally different from traditional compliance approaches. Instead of creating separate compliance activities that run parallel to operations, compliance streams embed regulatory obligations directly with your value streams - the actual work flows that create value for customers and stakeholders. Key characteristics of compliance streams: End-to-end flow:  From regulatory requirement to demonstrated evidence Embedded in operations:  Part of value creation, not separate from it Promise-based:  Clear commitments at every organizational level Continuous assurance:  Real-time visibility, not periodic audits Systems view:  All elements working together, not disconnected parts When you implement compliance streams, compliance becomes a natural part of how work gets done rather than something that happens to work. How Promises Flow Through Compliance Streams Compliance streams work by creating connected flows of promises through four dimensions of your organization: The Four Dimensions of Promise Flow Governance Level → Compliance Outcomes At the board and executive level, leaders make high-level promises about regulatory results: "We will maintain GDPR compliance and privacy certifications." These are outcome commitments that define what success looks like from a regulatory perspective. Program Level → Compliance Targets Directors and managers translate outcomes into specific, measurable performance commitments: "We will respond to 100% of data subject requests within 30 days." These targets bridge between strategic intent and operational capability. System Level → Compliance Practices Teams and functions commit to standardized methods that enable the targets: "We will implement ISO 27001 information security management and data classification procedures." These are the systematic approaches that create predictable performance. Process Level → Compliance Rules Individuals and automated systems make specific procedural commitments: "We will encrypt all personal data at rest using AES-256." These are the concrete actions that execute the practices. The Golden Thread: Connecting Every Promise The golden thread of assurance  connects every operational promise back to regulatory obligations and forward to compliance evidence. This thread ensures the following: 1. Accountability - Promise Ownership True accountability is threaded through the work itself, not added as an afterthought. Every promise has a clear owner at each level, and responsibility is embedded in job roles rather than bolted on through separate accountability structures. Test your accountability:  Can you name who owns each promise and how their performance is measured? If someone asks "who ensures we encrypt personal data correctly?" can you immediately identify the specific role holder and their metrics? 2. Alignment - Promise Integrity This isn't about closing gaps. It's about creating design and causal integrity where promises support higher-level commitments AND are enabled by lower-level commitments. The flow works bidirectionally—each promise logically enables the next level up while being made possible by the level below. Test your alignment:  Can you trace from any specific procedure back to the regulatory outcome it serves? Does encrypting data with AES-256 clearly enable data classification procedures, which enable ISO 27001 implementation, which enables 30-day response times, which enables GDPR compliance? 3. Assurance - Promise Verification Assurance goes beyond periodic audits to provide three types of ongoing confidence: Current assurance:  Promises are being kept right now Sustained assurance:  Capability to keep promises persists over time Adaptive assurance:  Promises evolve as conditions change Test your assurance:  Can you demonstrate ongoing promise fulfillment rather than just point-in-time evidence? Do you know not just that data was encrypted last month, but that encryption is happening reliably today and will adapt as threats evolve? Why Compliance Streams Work When you implement compliance streams instead of traditional compliance approaches, several transformations occur: Predictable Performance:  Instead of hoping all the pieces work together, you know how the system performs. You can predict where failures will occur before they happen. Reduced Waste:  You eliminate duplicate compliance activities because you can see where different obligations converge into single operational promises. Faster Response:  When regulations change, you know exactly which promises need to be updated rather than reviewing every procedure to see what might be affected. Real-Time Visibility:  You have ongoing visibility into compliance status rather than waiting for the next audit to discover problems. Mission Certainty:  Compliance becomes a capability that ensures business objectives rather than a constraint that slows them down. Traditional Compliance vs. Compliance Streams: A Data Privacy Example Consider data privacy compliance in your organization. Traditional compliance would create separate activities: Privacy training (HR department) Data inventory (IT department) Consent management (Legal department) Breach procedures (Security department) Records retention (Records management) Each department would have its own procedures, training, and audit schedules. You'd create cross-reference matrices trying to show how they connect. But you still wouldn't have clear visibility into whether personal data is actually being protected in real-time. The compliance stream approach  embeds privacy obligations directly into your data-handling value streams. Instead of separate privacy activities, you create connected promise flows: Outcome promises:  "We will maintain customer trust through demonstrated privacy protection" Target promises:  "100% data requests within 30 days, zero unauthorized transfers, annual certification maintained" Practice promises:  "ISO 27001 implementation, data classification workflows, breach notification protocols" Rule promises:  "AES-256 encryption, access logging, explicit consent, retention deletion" Now privacy compliance happens naturally as part of how you handle customer data, with a golden thread connecting specific technical controls all the way up to business outcomes. Getting Started with Compliance Streams Choose one high-value obligation  that currently causes uncertainty or surprises Map the current promise flow  from regulation to operational commitments to evidence Identify broken links  where promises aren't clear, owned, or demonstrably kept Design the golden thread  connecting all levels with clear accountability Build and test  the stream to prove it creates reliable assurance Replicate  the approach across other compliance domains The Bottom Line Compliance streams  transform how organizations meet regulatory obligations by embedding compliance directly into value streams through connected promise flows. This creates systems thinking that replaces the traditional reductive approach, generating a golden thread of assurance from regulatory requirements to operational evidence. The result: Compliance becomes a natural part of how work gets done rather than something that happens to work. You stop firefighting violations and start building capability. You move from hoping between audits to knowing in real-time how obligations are being fulfilled. For compliance directors and managers in highly regulated industries, compliance streams eliminate uncertainty by making regulatory fulfillment visible, traceable, and embedded in operations themselves. Ray Laqua, P.Eng, PMP | Lean Compliance Consulting | Transforming regulatory obligations into operational capability

If you're responsible for compliance, you've probably faced this uncomfortable question: "How do you know you're actually compliant?" Most organizations point to policies, training records, and audit reports. But there's often a nagging gap between having documentation and having genuine confidence that your obligations are truly being met. This is where Goal Structuring Notation (GSN ) and claim trees become game-changers. They're tools borrowed from safety-critical industries like aerospace and nuclear energy that help you build bulletproof arguments proving your compliance approach actually works. Let me show you how this applies to the real world of operational compliance. Goal Structure Notation & Claim Trees Applied to Obligations & Promises Compliance Model The Core Problem: Bridging the Gap Between Obligation and Reality When a regulator says "you must protect customer data" or a standard requires "annual risk assessments," there's a massive gap between that external demand and what actually happens inside your organization. Typically, someone writes a policy, IT implements some controls, training gets scheduled, and an auditor eventually checks some boxes. But can you actually prove that these activities fulfill the obligation? Can you show the clear, logical chain from requirement to result? Usually, no. And that's exactly the problem GSN and claim trees solve. Lean Compliance Operational Model The Lean Compliance Operational Model recognizes that obligations don't magically get fulfilled. Instead, there's a structured flow: external obligations must be transformed into internal promises (commitments that real people make about their own behavior), those promises must be coordinated by programs (governance structures that steer and align), and finally systems (the actual processes, tools, and people) must execute those promises to deliver outcomes. Understanding this flow is critical because each layer represents a potential point of failure, and each layer needs assurance. What GSN Brings to the Table Goal Structuring Notation is simply a visual way to show your argument for why something is true. Think of it like building a legal case, but for compliance. You make a top-level claim like "We comply with ISO 27001," and GSN forces you to systematically break that down into answerable questions. What strategy are you using to achieve this? What are the sub-claims that must be true for your top claim to hold? What evidence supports each sub-claim? It creates a tree-like diagram where you can't hide gaps or hand-wave difficult questions. Goal Structure Notation (GSN) Example For compliance using the Lean Compliance model, your top goal is always some variant of "We fulfill [specific obligation]." Then you decompose this through the operational layers. First, you need to prove you have the right promises in place—that someone has actually committed to doing what's needed, and that those commitments cover everything the obligation requires. Second, you need to show that programs are governing effectively, coordinating these promises and steering systems toward the right outcomes. Third, you need to demonstrate that systems are actually delivering on those promises reliably and consistently. Finally, you need to prove that the outcomes you're achieving actually fulfill the original obligation. Each of these becomes a major branch in your GSN tree. How Claim Trees Provide the Evidence While GSN shows the structure of your argument, claim trees show the evidence behind it. When applied to the Lean Compliance Operational Model these are evidence that commitments (i.e. promises) where kept. A claim tree starts with a statement you need to prove and systematically breaks it down into smaller, more specific statements that are easier to prove with concrete evidence. Each branch represents a necessary condition, and each leaf eventually points to a specific piece of evidence that you can touch, verify, and date. Claim Tree Example Let's say you need to prove that "Our CISO can reduce information security risks to acceptable levels." This isn't something you can just assert. You need to break it down. Does the CISO have the necessary skills to identify and evaluate risks? You prove this with certifications, training records, and demonstrated experience. Does the CISO have authority to implement risk treatments? You prove this with delegation letters and budget approval authority. Does the CISO have access to the systems and processes needed to actually reduce risk? You prove this with access control matrices and evidence of control implementations. Has risk actually been reduced? You prove this with metrics showing risk levels before and after interventions, incident data, and independent assessments. Notice how each question demands specific, verifiable evidence. No hand-waving is allowed. Getting the Outcome Right: Beyond Procedural Compliance Here's where many compliance programs go wrong, and it's worth pausing on this point. When ISO 27001 requires "conducting regular information security risk assessments," the procedural view focuses on the activity: did someone complete a risk assessment document? Did they do it on schedule? Does it have all the required sections? Auditors check boxes, the assessment report goes in a folder, and everyone moves on. But that completely misses the point. The operational view asks a fundamentally different question: are information security risks actually being managed to acceptable levels? The risk assessment isn't the goal—it's a means to an end. The real obligation is about achieving a state of managed risk, where threats are identified, evaluated, and addressed through appropriate controls that either reduce the likelihood of bad things happening or cushion the organization against their effects when they do. This shift in perspective changes everything about how you structure your assurance argument. Your top-level goal shouldn't be "We conduct annual risk assessments." It should be "Information security risks are maintained at acceptable levels." Now your promises need to reflect actual risk management activities: someone promises to identify emerging threats, someone promises to evaluate their potential impact, someone promises to implement controls that reduce risk, someone promises to monitor whether those controls are working, and someone promises to adjust when they're not. The risk assessment becomes one tool in this broader promise network, not the end goal itself. A Real-World Example in Action Let's walk through a practical scenario using this outcome-focused approach. Suppose you need to comply with ISO 27001's risk management requirements. Following the operational model, you first identify what outcome the obligation actually demands: information security risks must be managed to levels acceptable to the organization and its stakeholders. This means risks are identified, assessed, treated, and monitored on an ongoing basis. GSN & Lean Compliance Operational Model You first start by identifying what promises are needed to achieve this outcome. Your CISO might promise to maintain an accurate inventory of information assets and their associated risks, updating it quarterly and whenever significant changes occur. Your Information Security team might promise to implement and maintain controls that reduce identified high and medium risks below the organization's risk appetite threshold. Your IT operations team might promise to monitor security controls continuously and alert the security team when controls fail or degrade. Your business unit leaders might promise to accept documented residual risks for their areas of responsibility. Notice how these promises focus on achieving the state of managed risk, not just completing assessment documents. Now you build your GSN argument with the top goal stating "Information security risks are maintained at acceptable levels." Your strategy is to demonstrate this through the operational model layers. This creates sub-goals: proving that your promises collectively cover all aspects of risk management (identification, assessment, treatment, monitoring), showing that your ISMS program effectively coordinates these risk management activities and ensures nothing falls through the cracks, demonstrating that your GRC system and security tools enable reliable execution of risk treatments, and finally evidencing that risk levels are actually being maintained within acceptable bounds over time. For each of these sub-goals, you build claim trees. Consider the promise to implement controls to reduce risk. You create a claim tree that breaks this down: high-priority risks must be identified and prioritized, appropriate controls must be selected based on cost-benefit analysis, those controls must be implemented with sufficient coverage and strength, controls must be tested to verify they actually work, and the reduction in risk must be measurable. To prove this, you gather evidence: your risk register showing identified risks with severity ratings, treatment plans documenting which controls address which risks, implementation records showing when controls went live, penetration test results demonstrating control effectiveness, and trend data showing risk scores declining after controls were implemented. The claim tree for monitoring is equally important. You need to prove that controls don't just exist but continue working over time. This requires evidence of continuous monitoring systems generating alerts, incident response logs showing how alerts are handled, metrics showing control uptime and effectiveness, and regular reviews that catch degradation before it matters. The difference between this approach and a procedural approach is critical: procedural compliance might show you completed an assessment last year, but operational compliance shows you're actively managing risk right now, today, with evidence that the state of risk is known and capable of being controlled in the future. Why This Approach Transforms Compliance Using GSN and claim trees forces you to think systematically in ways that traditional compliance approaches don't. You can't hide gaps in your compliance approach when you have to draw out the complete argument from obligation to outcome. Every link in the chain must be justified, and every justification must point to evidence. This becomes especially powerful when you realize that most compliance failures don't happen because people are malicious or lazy; they happen because promises weren't clearly made, coordination broke down between teams, or systems simply couldn't deliver what was assumed. The outcome focus also protects you from the trap of performative compliance. It's easy to produce a beautiful risk assessment document that satisfies an auditor but does nothing to actually reduce risk. When your GSN goal is "risks are managed" rather than "assessment is conducted," you're forced to prove actual risk reduction. Your evidence can't just be the assessment document—it needs to be declining incident rates, reduced exposure to critical threats, faster detection and response times, and stakeholder confidence that risks are under control. This is compliance that actually makes the organization safer, not just better documented. The approach also makes compliance conversations dramatically more productive. Instead of debating whether you're "compliant" or arguing about interpretation, you can point to specific claims and evidence. When auditors ask if you're managing risk, you can walk them through your reasoning: here are the promises made, here's how programs coordinate them, here's how systems execute them, and here's the evidence that risk is actually being reduced. When executives want assurance, you can show them exactly where confidence comes from—not "we did an assessment" but "here's how we know our risks are under control." When something fails, you can trace back through the GSN to find exactly which promise broke, which program oversight was missing, or which system capability was insufficient. Perhaps most importantly, this methodology creates real assurance that evolves with your organization. Traditional compliance creates static documentation that's outdated the moment it's finished. GSN and claim trees are designed to be continuously maintained. When obligations change, you update the top-level goal and trace down to see which promises need adjustment. When new threats emerge, you update your risk management promises and prove you can address them. When systems evolve, you update the system capability claims. Your assurance case becomes an actual reflection of your compliance posture—and more importantly, your actual security posture—not a dusty binder on a shelf. Getting Started You don't need to boil the ocean to start using this approach. Pick one critical obligation your organization struggles to demonstrate compliance with. But here's the crucial step: reframe that obligation as an outcome, not an activity. Don't write "We conduct risk assessments." Write "Risks are managed to acceptable levels." Don't write "We provide training." Write "Staff make secure decisions in their daily work." This outcome framing immediately clarifies what really matters. Then identify the key promises that need to exist for that outcome to be achieved. For each promise, ask yourself if you can actually prove it's deliverable and being kept. Build claim trees for the most critical or questionable promises, and honestly assess what evidence you have versus what you're assuming. You'll quickly discover where your real gaps are—and importantly, you'll discover whether you're just checking boxes or actually achieving the outcomes your obligations demand. The goal isn't perfection from day one. The goal is building a structured, evidence-based approach to compliance that gives you genuine confidence and provides clear answers when stakeholders ask that uncomfortable question: "How do you know you're actually compliant?" With GSN and claim trees overlaid on the Lean Compliance operational model, focusing relentlessly on outcomes rather than activities, you'll finally have a good answer. More importantly, you'll know that your compliance efforts are actually making your organization better, not just better documented. If you are interested in learning more about GSN you can download the GSN Community Standard Version 3: For more information about the Lean Compliance Operational Model and related methodologies, visit our website here.

As someone working in compliance during this wave of AI adoption, I've been thinking about how we approach automation differently than other industries. The compliance field is naturally cautious about new technology—and for good reason. When we fail to meet regulatory standards, performance targets, or outcome requirements, the consequences extend far beyond operational inefficiency. Recently, I've been reflecting on Jidoka, Toyota's manufacturing principle that emerged over a century ago. What strikes me isn't just its practical applications, but what it reveals about our fundamental relationship with automated processes. The Wisdom of Stopping Jidoka emerged from a simple innovation: Sakichi Toyoda's loom that stopped automatically when a thread broke. The breakthrough wasn't the technology itself, but the philosophy it embodied—that intelligent automation should know when to stop working. This seems counterintuitive to how we often think about automation today. We typically measure automation success by uptime, throughput, and reduced human intervention. Yet Jidoka suggests that the most intelligent systems are those that recognize their own limitations and halt operations when conditions exceed their capabilities. In compliance, this perspective feels particularly relevant. We're constantly balancing the need for efficiency with the imperative to meet regulatory standards and maintain adherence to rules. The traditional compliance approach has been heavily manual precisely because the cost of errors is so high. But what if, instead of choosing between automation and safety, we designed systems that could recognize when they were operating outside acceptable parameters? The Multi-Process Insight What fascinates me about Jidoka is how it enabled what Toyota called "multi-process handling"—one operator overseeing multiple automated processes rather than watching each machine individually. This wasn't just about efficiency; it was about creating a different relationship between humans and automated systems. In compliance, we often fall into one of two extremes: either we automate everything and hope for the best, or we maintain such tight human oversight that we lose most efficiency benefits. Jidoka suggests a middle path—automation that's designed to be trustworthy precisely because it knows when not to be trusted. Consider how this might apply to our work. Rather than having compliance staff continuously monitor every automated process—whether it's regulatory reporting, performance tracking, or rule enforcement—we could design systems that operate independently until they encounter situations that require human judgment. The automation handles routine cases while immediately flagging exceptions, emerging patterns, or conditions that fall outside established parameters. Beyond Technical Implementation What I find most compelling about Jidoka isn't the technical mechanisms, but the underlying philosophy about quality and responsibility. Traditional automation often pushes quality control to the end of the process—we automate first, then inspect the results. Jidoka reverses this: it builds quality consciousness into the automated process itself. In compliance, this philosophical shift could be profound. Instead of implementing AI systems and then auditing their outputs, we might design systems that continuously evaluate whether they're meeting compliance objectives—not just processing data correctly, but actually achieving the outcomes and standards we're responsible for maintaining. This requires thinking differently about what we mean by "intelligent" automation. Intelligence isn't just about pattern recognition or data processing speed; it's about understanding context, recognizing limitations, and making appropriate decisions about when to continue and when to pause. The Compliance Challenge Compliance work encompasses far more than transaction monitoring or rule enforcement. We're responsible for ensuring adherence to regulatory requirements, meeting performance targets, achieving outcome standards, and maintaining organizational practices that support broader objectives. Each of these areas presents different challenges for automation. Performance targets might shift based on market conditions or regulatory changes. Outcome standards often involve qualitative judgments that are difficult to codify. Rule adherence requires interpreting requirements that may be ambiguous or evolving. Standard practices need to adapt to new situations while maintaining consistency with established principles. Jidoka's approach—building abnormality detection into the process itself—offers a way to think about these challenges. Rather than trying to automate everything perfectly from the start, we could focus on creating systems that recognize when they're operating outside their zone of competence. A Different Relationship with AI What strikes me most about reflecting on Jidoka in the context of AI adoption is how it suggests a different relationship with automated systems. Instead of viewing AI as either fully autonomous or requiring constant supervision, Jidoka points toward automation that operates with built-in humility. Systems designed with Jidoka principles don't just execute processes—they continuously assess whether they're meeting the standards and objectives they were designed to support. They're designed not just for efficiency, but for responsibility. For compliance professionals considering AI adoption, this perspective might be liberating. Rather than worrying about losing control or maintaining perfect oversight, we could focus on designing systems that share our commitment to meeting standards and achieving outcomes. The goal isn't automation for automation sake, but reliable automation that knows its limits. In compliance, where the stakes are high and the requirements are complex, that kind of intelligent restraint might be exactly what we need. These reflections come from considering how lean manufacturing principles might inform compliance practice in an era of increasing automation.

Properly defining and setting goals is critical to mission success including the success of environmental, safety, security, quality, regulatory and other compliance programs. However, defining compliance goals remains a real challenge particularly for obligations associated with outcome and performance-based regulations and standards. When these goals are ambiguous or ill-defined they contribute to wasted efforts and ultimately compliance risk for an organization. To be more certain about goals we first need to define what we mean by a goal and such things as objectives, targets, and the like. The following are definitions we have used that lay out a framework for goal-directed obligations. Outcomes These are the ends that we expect to attain over time where progress is expected through the achievement of planned goals. These are often described in qualitative terms but may also have defined measures to indicate and track progress towards the desired outcome. An example outcome would be achieving carbon neutrality by 2050. Goals Goals are defined measures of intermediate success or progress. They are often binary comparable to goal lines that are reached or not. Goals are usually connected to outcomes that are long-term in nature whereas targets tend to be associated with performance and are short-term achievements. There are two kinds of goals, terminal and instrumental: Terminal goals are the highest level outcome that we want to reach. They define the "ends" of our endeavours. For compliance these might include: zero defects, zero fatalities, zero violations, zero releases, zero fines, and others. Instrumental goals are intermediate outcomes or results that are critical or that must occur in order to achieve the higher-level outcome. These are often used to define measures of effectiveness (MoE) for compliance programs as they provide clear indication of progress towards terminal goals. Objectives Objectives are the results that we expect to attain over a planned period of time. These results contribute to (or cause) progress towards the targeted outcome. An outcome may require several objectives done in parallel, sequentially, continuously, and some contingent on others. Some form of causation model (deterministic, probabilistic, linear, non-linear, etc.) is needed to estimate the confidence level of creating the desired outcomes using planned objectives. In cases of greater uncertainty these models will be adjusted over time as more information is gathered and correlation between objectives and outcomes are better known. Risk Risk is defined (ISO 31000, COSO) as the effects of uncertainty on objectives which involves having a causation model. In practice, outcomes tend to be more uncertain than the achievement of objectives. However, everything happens in the presence of uncertainty so it is important to properly identify uncertainty and contend with its effects. There are two primary forms of uncertainty: Epistemic uncertainty; lack of knowledge or know how; this risk is reducible. Reducible risk is treated by buying down uncertainty to improve the probability of meeting each objective. Aleatory uncertainty; caused by inherent randomness or natural/common variation; this risk is irreducible. Irreducible risk is treated by applying margin in the form of contingency, management reserve, buffers, insurance and other measures to mitigate the effects of the risk. Targets Targets are a measure of performance (MoP) or progress when connected to an objective. These targets may be a single point or a range (min and max) of performance needed to achieve an objective. Strategy Strategy defines a plan for how goals, objectives, and targets will be obtained. Strategy is the approach to create the desired outcomes as measured by terminal and instrumental goals by achieving planned objectives at the targeted levels of performance, in the presence of uncertainty.

Why Business Managers Should Own Compliance There's a persistent practice in organizational management where compliance is separated from the business—a parallel universe where auditors live and checklists multiply. The segregation of duties, span of control, functional decomposition, job specialization, along with aligning around regulatory frameworks and audit objectivity all contribute to this practice. However, at a basic level, the main reason we separate compliance from the business is that we view compliance as a verification process not as an operational commitment to meet organizational obligations. Whichever the case, this practice results in the creation of silos, inefficiencies, and a fundamental disconnect between what the business does and how it keeps its promises associated with its legal and stakeholder obligations. But what if this organizational divide was closed? The Lines that Separate In traditional models, we draw clear organizational lines. On one side, we have Lines of Business—the revenue generators, the product developers, the operational managers who drive value streams forward. On the other side, we have Lines of Compliance—the functions responsible for ensuring that all obligations connected with safety, security, sustainability, quality, ethics, and finance are met. The problem with this separation is that it treats compliance as something done to the business rather than something that is the business. When we think of compliance as verification, we miss the fundamental point: compliance is about meeting obligations which happens by making and keeping promises. Every regulatory requirement, every quality standard, every environmental commitment, every customer assurance—these are all promises. And promises aren't kept through monitoring; they're kept through deliberate action and accountability. Two Lines, One Owner What if LOB managers owned both: business and compliance obligations? When business leaders are accountable for both delivering value and keeping compliance promises that come with that value creation, something important happens. Compliance stops being a monitoring function and becomes an operational commitment. The person responsible for business outcomes is also responsible for keeping safety promises. The manager driving customer acquisition also owns data privacy commitments. The executive overseeing operations ensures environmental obligations—both mandatory and voluntary—are fulfilled. This isn't about adding responsibility—it's about recognizing what business accountability actually means. It’s about owning all your obligations, not just those connected with meeting growth and sales targets. Integrated Obligations, Integrated Accountability When obligations are integrated so is accountability which makes decisions inherently better. A business manager who owns both value stream and compliance commitments can't rationalize shortcuts or defer difficult conversations. They can't claim ignorance of obligations because those obligations are woven into their mandate. They can't externalize accountability for meeting compliance obligations because they are part of their responsibility. This integration also eliminates wasteful cycles that plague siloed organizations. Instead of separate teams monitoring whether promises were kept after the fact, business managers build operations that maintain integrity by design. Resources that were once spent on checking, remediation, and firefighting can be redirected toward proactive value protection and creation. Perhaps most importantly, this approach fosters genuine ownership. When leaders are accountable for value chain and compliance obligations, they develop a more sophisticated understanding of what it means to operate responsibly. They see mandatory regulatory requirements and voluntary commitments not as constraints, but as integral to how they do business. From Principle to Practice Making this shift is not easy; it requires, among other things— vision— of what an integrative approach looks like. It requires re-imagining job descriptions, rewriting accountability frameworks, and often challenging entrenched organizational habits. But organizations that embrace this integrative model will consistently create better outcomes for the business—not just reducing waste, although that will happen, but also building stakeholder outcomes, most importantly the outcome of trust. Business and compliance functions aren't separate streams that occasionally intersect. They're the same river, flowing in the same direction: toward mission success. When we stop treating compliance as an audit function and instead recognize it as the fundamental means of ensuring mission success—we unlock both better performance and greater assurance. And this can happen with the same people, the same resources, and a clear understanding that every business manager is, at their core, a creator of value. Not just financial value measured by margins, but all the value that stakeholders demand: safety, security, sustainability, quality, ethics, and ultimately trust. That's lean compliance in action.

This post is written as a letter in response to typical inquiries from organizations looking to make improvements to their compliance. While this letter is fictitious it is representative of common situations facing businesses today. How Do I Improve Our Compliance? Dear Business Owner, Thank you for reaching out to me about your compliance situation. I agree with you that the risk and compliance landscape is overly complicated and it makes sense that you now find yourself frustrated, overwhelmed, and unsure you are meeting all your obligations. The advice you received to adopt a management standard and implement a compliance system for every compliance objective: safety, security, sustainability, quality, legal, and so on is not unusual and for large organizations is common practice. At the same time, your comment that your budget does not support this approach is a very real concern shared by many. You also mentioned your organizational culture is mostly negative towards compliance and sees it as a non-value add and a tax on production. This is also commonplace particularly for organizations that are new to compliance or have taken a check-box or reactive approach to compliance. Now, with respect to your specific question as to what you should do; here is what I recommend: Start with making a commitment to own all your obligations . This is necessary before any meaningful change can occur. Ownership of obligations leads to greater levels of accountability and proactivity so its important to start there. Develop an integrative roadmap . This step maps your current capabilities to what is needed to meet all your obligations and keep all your promises on a continuous basis. This will form the basis for an overarching compliance program. During this step you should also learn essential concepts and principles as you create your road map towards greater proactivity and certainty in meeting all your obligations and keeping all your promises. Operationalize your compliance . This step is where you build what’s essential to operationalize your obligations. A minimum level of operability, Minimum Viable Compliance (MVC), is necessary before actual benefits can be realized. During this step your team should establish essential functions, behaviours, and interactions to achieve Minimal Viable Compliance (MVC) to begin enjoying the benefits that come from staying between the lines and ahead of risk. Elevate your compliance. This step focuses on continual improvement raising the bar to new heights of effectiveness and value. This means more than incremental improvements. To advance compliance outcomes you need to advance compliance capabilities. That’s why this step is a game changer. It takes everything to the next level. These four steps will help you develop essential capabilities along with building a culture of compliance that generates compounding benefits over time with lower risk, reduced cost, and greater assurance. I believe this will provide greater value to you than just passing an audit or achieving certification alone. To help work through these steps, we designed “ The Total Value Advantage Program™” which follows these steps in a structured manner facilitated by one of our compliance experts. You don’t have to wait to get started. You can become a member of this program by completing the Total Value Advantage Scorecard and participating in a free orientation session. During this session we will review your results, discuss opportunities to improve your compliance, and decide together if this program is right for you. https://www.leancompliance.ca/the-total-value-advantage-scorecard We realize this program is not for everyone as many are unable to take the first step of owning their obligations. However, for those that do, this program helps them garner greater stakeholder trust and achieve greater business success in the marketplace. I trust I have addressed your concerns and provided a path forward to help you deliver compliance value. I look forward to helping you achieve compliance success. Be Proactive, Raimund Laqua, PMP, P.Eng. Founder, Chief Compliance Engineer Lean Compliance More Value, Less Waste, Greater Assurance

How do we deliver safe AI? This is the question every organization grappling with AI adoption must answer. Yet too often, discussions about AI safety focus narrowly specific aspects of the technology (such as LLMs), as if AI exists in a vacuum. The reality is more nuanced. AI is a technology that operates within existing systems—systems that in highly-regulated, high risk industries already have well-established definitions of safety, existing regulations, industry standards, and proven best practices. Understanding this context is essential to approaching AI safety effectively. From an engineering perspective, I propose three principles that organizations should consider when designing or adopting AI solutions for their business. Principle 1: Protect Existing Safety Systems Do no harm to what already works. The first principle is to ensure that AI technology does not diminish the effectiveness of existing safety measures and controls. Just as we strive not to harm the environment, we must strive to not compromise our ability to deliver existing levels of safety. This requires understanding the impact that AI technology has on established safety systems. When you introduce AI into a manufacturing process, a healthcare workflow, or a financial control system, you must ask: Does this maintain or enhance the safety controls we already have in place? Does it create new failure modes in existing safeguards? Consider two examples from a process safety perspective where Management of Change (MOC) applies to AI deployment: Example 1: AI Technology Evaluated by MOC Process safety regulations require an MOC to be conducted before modifying any safety-critical operation. When an organization introduces AI to monitor equipment conditions or predict failures in a chemical facility, this constitutes a design change that triggers an MOC. The MOC risk assessment must evaluate how the AI system affects existing safety controls. For instance, if operators begin relying on AI alerts instead of conducting scheduled inspections, the organization has effectively changed its detection and mitigation strategy. The MOC process should identify this shift and determine whether compensating controls are needed to maintain safety integrity. Example 2: AI Used Within the MOC Process Itself More subtly, when an organization uses AI to automate parts of the MOC workflow—such as reviewing and approving change requests—this change to the MOC process itself requires an MOC. The original MOC system had segregation of duties: one person requests the change, another reviews technical details, a supervisor approves it. This prevented single points of failure in safety-critical decision-making. Replacing human reviewers with an AI system is simultaneously a design change (new technology), a procedural change (new workflow), and an organizational change (altered roles and responsibilities). Without conducting an MOC on this change to the MOC process, the organization unknowingly degrades a fundamental safety control while believing they've simply improved efficiency. The engineering discipline here is straightforward but often overlooked: Map your existing safety controls. Understand how AI integration affects each one. Verify that safety is maintained or improved, not degraded. Principle 2: Protect Operational Systems Isolate the hazard, then control the risks. AI technology has inherent uncertainties that exceed those of traditional technologies. These uncertainties create opportunities for emerging and novel risks. In the language of systems safety expert Nancy Leveson, AI creates the potential for "hazardous processes" within organizations. The response to any hazard follows a consistent pattern: first isolate the hazard, then handle the risks it introduces. This means establishing guardrails—safeguards that protect the organization, its workers, customers, and stakeholders from the consequences of using hazardous technology which in this case is AI. What makes AI a potential hazard is the nature of its uncertainties: Probabilistic outputs rather than deterministic ones Opaque decision-making in complex models Emergent behaviours that weren't explicitly programmed Dataset dependencies that may not generalize Adversarial vulnerabilities unique to machine learning systems The STAMP (Systems-Theoretic Accident Model and Processes) and STPA (System-Theoretic Process Analysis) methodologies provide systematic approaches to dealing with these kinds of uncertainties. Originally developed for aerospace applications, these frameworks have proven valuable in cybersecurity and are now being applied to AI systems. Using STPA, organizations can identify unsafe control actions, understand loss scenarios, and design constraints that prevent hazardous system states. This is not about preventing all possible failures—that's impossible with any complex system—but about understanding failure modes and designing appropriate controls. Principle 3: Protect Organizational Systems Make AI technology itself less risky. The third principle focuses on reducing risk at the source: designing AI technology that is safer regardless of how it's deployed or used. The 2016 paper "Concrete Problems in AI Safety" by Amodei et al. helped crystallize many of these challenges. It identified specific technical problems such as avoiding negative side effects, reward hacking, scalable oversight, safe exploration, and robustness to distributional shift. Since its publication, we've seen the creation of dedicated AI Safety institutions and the emergence of AI Safety Engineering as a discipline. We now understand that different categories of AI systems present different risk profiles: Narrow AI systems trained for specific tasks have bounded but still significant risks Agentic systems that take actions autonomously introduce new categories of risk Advanced AI systems (AGI or ASI) would present risks of an entirely different magnitude For many organizations, the responsibility for AI safety is a shared risk with companies creating large language models and foundation models. However, organizations are developing their own specialized models for specific use cases. These custom models require their own risk assessment and safety measures tailored to their particular context and application. This means organizations cannot simply rely on foundation model providers to solve all safety problems. If you're fine-tuning models, creating retrieval-augmented generation systems, or deploying AI agents, you have safety engineering work to do. An Integrated Approach From an engineering perspective, all three principles must be considered together, not just the last one. An AI model might be state-of-the-art in terms of its training methodology and robustness testing, but if it's deployed in a way that undermines existing safety controls or without adequate guardrails for its uncertainties, the overall system becomes less safe, not more. This integrated view reflects how safety is actually achieved in mature engineering disciplines. Aircraft aren't safe just because engines are reliable. They're safe because of redundant systems, rigorous maintenance protocols, pilot training, air traffic control, and countless other layers of protection. Similarly, safe AI systems require attention to technology, process, and context. Practical Next Steps For organizations looking to implement these principles: For Principle 1 - Protect Safety Systems Document existing safety controls before AI deployment Conduct impact assessments on how AI affects these controls Establish verification processes to ensure safety is maintained For Principle 2 - Protect Operational Systems Adopt systematic hazard analysis methodologies like STPA Create clear governance structures for AI risk management Implement monitoring systems to detect emerging risks Design guardrails appropriate to the level of uncertainty and consequence For Principle 3 - Protect Organizational Systems Engage with AI safety research and best practices relevant to your sector Conduct thorough testing including adversarial and edge case scenarios Participate in industry collaborations on safety standards Budget for ongoing safety evaluation as systems and understanding evolve Conclusion The question of how to deliver safe AI is indeed the question of the day. But it's not a question that can be answered by focusing on AI technology alone. Safety emerges from the interaction between technology, systems, processes, and people. By preserving existing safety systems, managing AI-specific uncertainties, and designing inherently safer AI, organizations can move beyond the hype and fear that too often characterize AI discussions. They can adopt AI in ways that are both innovative and responsible. This is the work of engineering: not making perfect systems, but making systems that fail safely, that operate within understood bounds, and that deliver value without unacceptable risk. It's work worth doing, and doing well. Raimund Laqua, P.Eng is Founder of Lean Compliance, and Co-Founder of Professional Engineers.AI.

When mission success requires compliance success Every organization is on a journey. Ahead lies your vision—the total value you're working to achieve. Your mission is getting there, but the path winds through complex terrain and risk is always present.  The question isn't whether you'll face this journey. You already are. The question is:  how well are you navigating it? Three Essential Principles to Practice To improve your probability of success, the following principles should be part of your practice: Stay on Mission Your vision isn't just about more growth and profit. Quality IS the value. Safety IS the value along with Security, Sustainability, Ethics, and Trust. These aren't just guardrails. They ARE what you create for your stakeholders, your employees, your customers, and the world. When every decision drives toward these outcomes, you don't just succeed—you create something that matters - Total Value. Stay Between the Lines The path has boundaries—regulations, standards, policies. These aren't restrictions. They're the proven route that keeps you moving forward while others veer into costly mistakes and waste. Organizations that see compliance as burden miss the point. The lines show you where the cliffs are and what does not add to value creation. Stay Ahead of Risk Risk doesn't wait. Cyber threats, regulatory changes, operational failures, reputational damage—they're always pursuing. You can't always eliminate them, but you can maintain enough distance to see what's coming and respond with intelligence instead of panic. What This Delivers When you master these three principles, something shifts. You stop fighting fires and start building momentum. Resources flow to what creates real value. Waste disappears. Confidence grows. Your team knows the mission, trusts the process, stays ahead of what could go wrong, and focuses on doing what needs to go right. This is the Lean Compliance Way to More Value, Less Waste, and Greater Assurance. Your journey is worthwhile and success matters. However, the terrain is complex and there is always uncertainty. Every step you take can improve the probability of mission success or the probability of failure.  The choice is yours.  Choose the Lean Compliance Way. Are you ready to turn compliance into a competitive advantage?   Lean Compliance helps organizations always stay on mission, between the lines, and ahead of risk towards Total Value.

Michael Porter was right. You need capabilities to create value which he outlined in his Value Chain Analysis (VCA) from which competitive advantage can be determined. So the question is, what capabilities does compliance have to create value for the organization, and how does this generate competitive advantage? Integrated Balanced Scorecard The value chain's ultimate outcome is value as perceived by customers and stakeholders. While Michael Porter's value chain framework creates and delivers value, it cannot do so effectively in isolation. Total value creation requires integrating productivity and compliance programs. Productivity Drives Margins Organizations implement productivity programs to enhance value chain efficiencies and increase margins. This operational excellence domain encompasses methodologies such as Lean, Six Sigma, TQM, and digital automation. Performance is measured by efficiency, while effectiveness is measured by improved margins. Better margins create value both financially and as protection against unavoidable external and internal risks. Margins can offset losses from market disruptions and operational risks—instances where organizations fail to meet goals and objectives. However, operational risk is best managed through risk and compliance programs. Compliance Drives Certainty To address operational risk, organizations establish programs ensuring (to make certain) objectives are achieved. Management traditionally handles common variation, while risk and compliance functions address specialized threats and opportunities. Performance is measured by the level of certainty (or confidence) in achieving objectives—what might be called assurance—and risk amelioration. Effectiveness is measured by compliance: meeting obligations manifested through safety, quality, security, privacy, reputation, and other value properties. Managing operational uncertainty helps organizations stay within boundaries, protecting the value chain along with employees, assets, shareholders, customers, the environment, and communities. Integrated Balanced Scorecard Protecting value creation fundamentally means contending with two types of uncertainty. Aleatory uncertainty (irreducible randomness) is handled by applying margins to cover unavoidable losses. Epistemic uncertainty (reducible through knowledge) is managed through compliance controls and measures. Adequate margin and certainty are both necessary for effective value chain creation. An integrated balanced scorecard improves visibility of strategic initiatives related to value, margin, and compliance targets. It also facilitates appropriate trade-offs between opportunities to improve margins and measures to contend with threats. When establishing an integrated balanced scorecard, map strategic objectives and initiatives to appropriate categories. Using categories from Geoffrey Moore's "Zone to Win" alongside functions from Michael Porter's Value Chain Analysis helps capture objectives according to time horizon, risk appetite, and compliance priorities. Productivity and compliance activities each have objectives for positively affecting the value chain while including initiatives to improve one another. For example, productivity improvements can benefit compliance programs, and productivity initiatives benefit from objective risk-based approaches. Greater uncertainty and risk characterize incubation and startup activities, which may require different strategies focused on pursuing opportunities rather than avoiding losses. Compliance as Competitive Advantage Organizations that excel at compliance create sustainable competitive advantages beyond mere risk mitigation. Strong compliance capabilities build trust with customers, regulators, and stakeholders, enhancing brand reputation and market position. They enable faster market entry by streamlining regulatory approvals and reducing time-to-market for new products and services. Robust compliance frameworks also attract premium customers and partners who prioritize working with reliable, trustworthy organizations. Moreover, proactive compliance reduces the cost of crisis management, legal disputes, and remediation efforts that plague competitors with weaker systems. By embedding compliance into strategic planning rather than treating it as an afterthought, forward-thinking organizations transform regulatory requirements into differentiators that strengthen their competitive moat and create barriers to entry for less disciplined competitors.

What GRC Should BE Traditionally, GRC activities were centered around integrating the siloed functions of Governance , Risk , and Compliance (GRC). While this is necessary, it is based on an old model where meeting obligations (the act of compliance) is a checkbox activity reinforced by audits. Similarly, risk management was building risk registers and heat maps, and governance was providing oversight of objectives completed in the past. All this to say: This was all reactive, misaligned, and focused on activity not outcomes. However, when you start with an integrative, holistic, and proactive approach to meeting obligations, a different model emerges where the bywords are: Govern , Regulate , and Ensure (GRE). These are essential capabilities that, when working together, improve the probability of success by governing, regulating, and ensuring the ends and the means in the presence of uncertainty. There is no need to integrate disparate functions, as these are already present in their proactive, integrative, and holistic form to deliver the outcome of mission success. If you're interested in learning more about transforming reactive GRC functions into proactive GRE capabilities, explore T he Total Value Advantage Program™

EPA - Lean and Environment Toolkit Lean is well known for its focus and effectiveness to reduce waste specifically in production processes. The 8 sources of lean waste: defects, excess processing, overproduction, waiting, inventory, transportation, motion, and non-utilized talent have helped practitioners “see lean waste” in their processes and identify areas of improvement. A tool that is most often used is Value Stream Mapping (VSM) which adds a temporal dimension to visualize where, when, and how much waste is being used in every step of value creation. It's no wonder that this same approach is increasingly being used to “see environmental waste” in business processes. Although not considered part of Lean’s deadly wastes, environmental waste are embedded in and related to wastes targeted by lean strategies. Over the last decade Lean tools and practices have expanded to consider quality, safety, and environmental aspects. Instead, of quantifying waste only in terms of financial costs the quantification of such things as carbon footprint is becoming the new calculus by which processes are measured. One of the most comprehensive toolkits that combines lean and the environment is available is from the US Environmental Protection Agency (EPA). This toolkit provides practical strategies and techniques to: “improve Lean results—waste elimination, quality enhancement, and delivery of value to customers—while achieving environmental performance goals” Organizations that adopt this toolkit can better answer the following questions: Why should I identify environment waste in my processes? How will I know when I see environmental waste? Where should I look for environmental waste? How do I measure the environmental impacts of a process? Where can I find environmental preferable alternatives to my current process? One of the tenants of Lean is: if you can’t see it you can’t improve it. To begin to see environment waste in your organization, EPA recommends the following: Add environmental metrics to the metrics considered in Lean efforts to better understand the environmental performance of production areas. Show management commitment and support for improved Lean and en­vironmental performance by holding collaborative meetings and providing resources and recognition. Integrate environmental wastes into Lean training programs. This can be as simple as adding a few additional slides to a presentation or as ad­vanced as holding a special Lean training for EHS personnel. Make environmental wastes visible and simple to eliminate by using signs and other visual controls in the workplace. Recognize and reward environmental success accomplished through Lean. Identifying environmental wastes, calculating and optimizing for carbon footprint, and learning how to reduce environmental waste will become standard practice for Lean practitioners in an Environment-First future. Lean practitioners will need to work more closely with EHS professionals and become more knowledgeable and skilled on how to incorporate environmental aspects into their practices. These resources from the EPA are great places to start: The Environmental Professional's Guide to Lean and Six Sigma Lean and Environment Toolkit Lean and Energy Toolkit Lean and Chemicals Toolkit Lean and Water Toolkit