Ankit Kulkarni

My positionI do not support implementing a change that improves speed but increases errors. In my view, this is a classic case of a false trade-off. Speed and quality are not competing goals. If a change improves one and worsens the other, the process is not optimized — it is imbalanced. The real issue — Local optimizationAI has optimized for one metric: speed. But real operations run on a system of metrics: Throughput First-pass yield Rework Customer experience Cost of poor quality (COPQ) If errors increase by 10%, the system is not faster — it is just pushing defects downstream, where they become more expensive. Example from my experience (LCD carrier case)We faced a severe issue in LCD carrier production: Rejection rate reached ~85% Production line supporting ~€85M revenue was at risk To keep output running, we introduced rework: ~35% recovery rate Throughput appeared to continue But in reality: Cycle time increased Labor effort increased Hidden factory load increased COPQ increased significantly So while output looked stable, 👉 the system was actually becoming inefficient and unstable. We stopped treating it as a trade-off and ran full DMAIC: Identified root cause (cooling fixture design) Redesigned mold and process 👉 Result: Rejection reduced to near zero Throughput stabilized Rework eliminated Example from industry — Boeing 737 MAXA similar pattern can be seen in the Boeing 737 MAX case. To improve efficiency and reduce operational constraints, Boeing introduced the MCAS system. It delivered: Improved performance Reduced training requirements But it also introduced uncontrolled failure risk due to limited sensor dependency. 👉 Efficiency improved locally, but system reliability degraded. The result was not improvement — it was system fragility with severe consequences. Why Bex’s argument is riskyBex suggests that speed gains justify temporary quality loss. In practice, this leads to: Customer complaints and returns Rework loops consuming capacity Increased variability and instability Erosion of trust In Lean terms: 👉 Defects create a hidden factory — and the hidden factory always costs more than it appears The right decision lensThis is not: 👉 Speed vs Quality This is: 👉 Short-term gain vs long-term system capability A system that produces defects faster is not optimized — it is simply failing at a higher rate. What AI should actually driveAI should not push single-metric improvements. It should help: Identify true bottlenecks Simulate cross-metric impact Enable balanced optimization (speed + quality together) Bottom line (my view)A faster process that produces more errors is not an improvement. It is a shift of waste from upstream to downstream. 👉 Don’t accept the trade-off 👉 Fix the process “Speed without quality is not flow — it is just faster movement of defects.”

My positionI don’t support allowing AI to implement process changes fully on its own — even at high confidence levels. AI can be very good at identifying patterns and suggesting improvements. But process changes are not isolated decisions — they affect systems, controls, and downstream operations. That requires human accountability. Example from my own development (AI-driven master data automation using MiniLM)I built a Python + AI (MiniLM) model to support master data integration for newly acquired plants. The system compares incoming data (~5,000 records) against an existing database of ~345,000 materials and classifies outputs into: AUTO → direct mapping and upload into SAP REVIEW → requires human validation REJECT → new material creation This is already a high-impact automation: Earlier: ~6 minutes per item → ~2 months effort Now: entire process completed in ~10 days Managed by 2 FTEs across 50+ plants (expanding to 70+) Where autonomy works — and where it doesn’tWe allow AI to act autonomously only in the AUTO category. Why? Because these are: High-confidence matches Low-risk decisions Limited downstream impact But for the rest: REVIEW and REJECT decisions still require human intervention Why we don’t allow full autonomyEven when AI is confident, it does not fully understand: Business context Equipment criticality Compliance requirements Future usage implications A wrong mapping is not just a data error — it can lead to: Wrong procurement Inventory duplication Planning inaccuracies across plants So the risk is systemic, not local. The key principleFrom my experience: 👉 AI decisions are local optimizations 👉 Process changes are system-level interventions That’s the gap. AI may be right about similarity — but not about business consequence. What actually worksInstead of full autonomy, we use: Confidence thresholds → to filter low-risk cases Human validation → for impact-heavy decisions Feedback loop → to continuously improve the model So AI accelerates the process — but does not take full control. Where I differ from BexI agree that AI can drive speed and continuous improvement. But removing human oversight completely shifts the risk from delay to uncontrolled impact. And in operations, uncontrolled impact is far more expensive than slower decisions. Bottom line (my view)AI should absolutely automate decisions — but not own process changes end-to-end. 👉 Let AI act where risk is low 👉 Keep humans where impact is high Because: “High confidence does not mean full understanding — and process changes demand both.”

My positionI don’t support implementing AI-recommended changes immediately if people are not ready. In my view, a solution only creates value when it is actually used. If adoption fails, the improvement does not exist — no matter how strong the data is. Example from operations (SAP IBP implementation across 50+ plants)In our supply chain setup, we implemented SAP IBP to drive replenishment decisions across: 50+ plants €200M inventory 78,000+ SKUs The system used integrated data (consumption, PM signals, lead times, service levels) to recommend: Replenishment strategies (VB, ND, PD) Inventory parameters (Safety Stock, ROP, Max) From a technical standpoint, the improvement was clear: ~70–80% decisions could be automated Faster planning cycles Significant cost avoidance potential Eventually, this translated into ~€10M cost avoidance in one year Where the real challenge wasThe issue was not the model. It was people. Even after rollout: Plant leaders continued questioning outputs, not logic Teams tried to override system recommendations based on past habits AI was treated as “suggestion,” not decision support So despite a strong solution, adoption was weak initially What would have happened if we forced implementationIf we had pushed immediate adoption: More overrides would have happened Trust in the system would have dropped Teams would have found workarounds AI would have been seen as imposed, not useful In Lean Six Sigma terms, this becomes: 👉 Implementation failure, not solution failure And that is far more dangerous — because it kills future improvements as well. What we actually didInstead of forcing speed, we built readiness deliberately: Started with pilot plants Explained the logic behind IBP, not just outputs Shifted conversations from “numbers” to “assumptions and risks” Defined clear rules (thresholds, auto-accept ranges, exception handling) Over time: Leaders began trusting the system Manual overrides reduced Focus shifted to exceptions instead of routine decisions That’s when performance actually unlocked. The real trade-offThis is not a choice between speed and resistance. It is a choice between: Delay risk → slower benefit realization Adoption failure risk → no benefit at all In my experience: 👉 Adoption failure is the bigger risk Where I differ from BexI agree that performance matters. But pushing change without readiness does not accelerate performance — it delays it in a different way. Because people don’t reject data — they reject systems they don’t understand or trust. Bottom line (my view)AI can recommend the right answer. But only people can make it work. 👉 Don’t implement fast and hope people catch up 👉 Build readiness so the system actually delivers Because: “A technically correct solution with poor adoption creates zero value.”

My positionI don’t agree with prioritizing learning over immediate resolution. In real operations, the sequence is critical: 👉 Contain first (fix fast) 👉 Then eliminate root cause (fix right) Reversing that order increases operational exposure, cost of poor quality (COPQ), and system instability. Example 1 — Power plant operations (real-time incident response)In our power plant operations, predictive analytics continuously monitors turbine health — vibration, temperature, load fluctuations — to detect early failure signals. When a turbine trips or shows abnormal behavior, the impact is immediate: Drop in available capacity (MW loss) Reduced plant availability and load factor Increased risk of forced outage Direct revenue loss per hour At that point, the system is outside stable operating conditions — effectively beyond control limits. LSS framingContainment action → restore the process within control limits (bring unit back safely) Corrective action → identify and remove assignable cause Preventive action → modify control strategy to improve MTBF and reduce recurrence If we delay containment in favor of analysis: Availability loss increases Throughput drops Risk of cascading failures rises COPQ escalates rapidly So in practice: 👉 We stabilize first (containment) 👉 Then run structured RCA (5 Why, fishbone, failure mode validation) 👉 Then strengthen controls (FMEA updates, predictive thresholds, SOP changes) Example 2 — LCD carrier rejection (manufacturing case)In a previous role, we encountered severe distortion in LCD carriers post injection molding: Rejection rate reached ~85% Production line supporting ~€85M revenue was at risk Effective throughput collapsed At that point, the process capability had clearly shifted — a classic special cause variation scenario. Step 1 — Containment (fix fast)Introduced rework process Achieved ~35% recovery rate Maintained partial line output From an LSS lens, this was: 👉 Containment to reduce immediate COPQ and throughput loss Step 2 — Corrective & Preventive (fix right)We then moved into structured DMAIC: Measure → MSA at supplier and plant Analyze → cycle time (7.5 min), cooling fixture (10 min), material behavior Root cause → deformation due to cooling fixture design Improve → mold and process redesign Control → updated specs, monitoring limits, supplier controls 👉 Result: Rejection reduced to near zero, process returned within stable limits What this shows If we had focused only on learning first: Production would have stopped completely Availability and throughput would collapse COPQ and revenue loss would escalate If we had focused only on quick fixes: Recurrence probability remains high MTBF remains low System stays in firefighting mode The correct sequence is: 👉 Contain → Correct → Prevent Why Bex’s position is incompleteI agree that root cause elimination is essential. But prioritizing it before stabilization ignores real-world system dynamics. Because: RCA requires stable conditions Data collected during instability is often misleading Extended disruption increases operational risk and cost In LSS terms: 👉 You cannot run a reliable Analyze phase when the process is not under control What AI should actually driveAI should not force a trade-off between speed and learning. It should enhance the full improvement cycle: Faster detection → earlier containment Pattern recognition → sharper root cause hypotheses Feedback loops → stronger preventive controls AI improves both reaction speed and learning depth — but the sequence must remain disciplined. Bottom line (my view)From a Lean Six Sigma perspective: 👉 Containment protects availability, throughput, and customer impact today 👉 Corrective and preventive actions improve capability, reliability, and MTBF tomorrow AI should accelerate both — but never confuse their order.

My positionI support keeping the feature live and fixing selectively. In my view, progress should not be rolled back because of localized issues — as long as the problem is clearly segmented and not systemic. Stopping everything to fix a minority case often destroys more value than it protects. Real example from our procurement process (AI-driven supplier recommendation)In our procurement transformation, we implemented an AI-assisted approach to recommend supplier shortlists based on: Category structure Historical spend Supplier participation and response patterns Earlier, buyers used to invite 15–25 suppliers per RFQ, with only ~2–3 responses on average. After AI implementation: Supplier invitations reduced to 5–7 per RFQ Response rate improved from ~62% to ~85%+ Negotiation delta improved from <5% to ~11–14% So for the majority of cases, the feature significantly improved both efficiency and outcomes. Where the issue appearedIn about 8–10% of RFQs, we saw gaps: Niche or less-common categories Newly onboarded suppliers Incomplete or evolving data In these cases, some valid suppliers were not being recommended. This was not a system failure — it was a coverage gap. The decision pointAt that stage, the choice was simple: 👉 Roll back and go back to inviting 15–25 suppliers 👉 Or keep the system and fix the gaps Rolling back would have: Reduced response quality Weakened competition Reintroduced inefficiency for 90%+ of cases What we did insteadWe kept the AI-driven approach live and addressed the issue where it actually existed: Allowed controlled overrides for niche cases Improved category mapping logic Accelerated onboarding of new suppliers into the system Monitored repeat overrides to identify gaps So instead of stopping progress, we tightened the system where it needed improvement. Why this worksFrom my experience, not all problems should be treated equally. When the issue is: Localized Understandable Correctable without disrupting the system 👉 The right approach is to continue and improve selectively Because rolling back in such cases penalizes the majority for the limitations of a minority segment. Bottom line (my view)The goal is not to make a system perfect before using it. The goal is to improve it without breaking what already works. 👉 Keep what works for most 👉 Fix what doesn’t — precisely

My positionI don’t support stopping the process every time AI raises a flag. In my view, reacting to every prediction — even at 85–90% accuracy — creates a different problem: we reduce defect risk, but we damage flow, availability, and trust in the system. Example from operations (Power plant — turbine reliability & outage strategy)Let me take a real example from our operations, we have 54 GW power generation coming from CCGTs under different locations. We use predictive analytics on our turbines data — vibration, temperature, load behavior — to flag potential failures early. Now, in this environment, decisions are not just “stop or continue.” They are tied to outage strategy: Minor outage → few hours to 1–2 days Major outage → several days to weeks Both decisions have cost: If we miss a real failure, we face forced outages, generation loss, and possible equipment damage If we shut down unnecessarily, we lose generation revenue and disrupt grid commitments So we don’t treat every signal the same. We use a risk-tiered response, not a binary stop rule. What a risk-tiered response looks like🔴 High-risk signalsStrong deviation across multiple parameters Matches known failure patterns High impact on critical equipment 👉 Action: Immediate controlled shutdown (Shift into planned outage — minor or major depending on severity) 🟡 Medium-risk signalsModerate deviation Early-stage anomaly 👉 Action: Continue running Increase inspection / monitoring Prepare for planned intervention 🟢 Low-risk signalsWeak or inconsistent signals 👉 Action: Monitor only No disruption Bringing it back to the given scenarioLet’s look at the numbers: 3–4 flags per shift 12% false positives 15–40 minutes per stoppage If we stop on every flag: Total stoppage per shift45 to 160 minutes per shift On an 8-hour shift (480 minutes): 👉 That’s ~9% to 33% loss of availability False positives alone0.36 to 0.48 unnecessary stops per shift Equivalent to ~5 to 19 minutes lost per shift 👉 That’s ~1% to 4% pure false-alarm loss, before even considering restart instability or downstream effects. Daily impact (3 shifts)2.25 to 8 hours lost per day Of which ~16 to 58 minutes is pure false positive loss At that point, we are no longer protecting quality — we are systematically disrupting flow. The real lens: Type I vs Type II errorThis is fundamentally a Type I vs Type II trade-off: Type I error (false positive) → stopping when no defect would occur Type II error (missed defect) → not stopping when failure is real Stopping on every signal tries to eliminate Type II error — but at the cost of very high Type I error impact. In operations, both errors have cost. The goal is not to eliminate one — it is to balance them intelligently. Where I differ from BexI agree with Bex on one point: defects reaching the customer are unacceptable. But stopping every time AI predicts risk is not discipline — it is treating probability as certainty. AI gives early signals. Operations must convert those signals into proportionate action. Bottom line (my view)AI should trigger attention, not automatic interruption. Stopping the process should be reserved for: 👉 high-confidence signals + high-impact risk Everything else should be handled through: Monitoring Containment Planned intervention Otherwise, we solve one problem — defects — by creating another: loss of flow, trust, and operational discipline.

Process Context My team also manages the central master data management for 50+ plants today, and this will grow to 70+ plants by 2027. The entire fleet data management is handled by two people in my team. Every time we commission a new plant or acquire a new plant, we need to align it’s material master with our fleet database, to avoid duplication, planning errors, and wrong spares being introduced into SAP. In a typical post commissioning and acquisition, we review minimum of 5000+ incoming material records against an existing 345000 item fleet master. Practically for my team, each item review takes at least 6 minutes without AI. The AI-enabled Process To solve this, I built a Python + AI solution using a MiniLM semantic model, combined with rule based checks. The program setup classifies each incoming item into three categories, Auto, high confidence match to directly map & upload in SAP. Review, ambiguous match, reviewed by the master data team. Reject, no valid match, program generates a new master data creation template for my team, to directly load into SAP. You can clearly see, AI does not create master data blindly in this case, it recommends, and the team decides. When We Trust The AI I have defined clear rules after testing the model for almost 10 days with millions of lines, semantic similarity is high & critical identifiers (model number, size, rating). It checks if descriptions and attributes are complete and consistent. One more rule I have setup is to keep standard, low-risk categories, and excluding verified MRP items, and these items directly flow straight into Auto category & are uploaded without manual touch. When We Override The AI Team deliberately does the review when similarity scores are close across multiple candidates, technical digits conflict even if text similarity is high. Then we also look at if item is maintenance critical or safety critical. We jump to the poor descriptions as well. In all such cases, team’s priority is correctness, not the speed. Safeguards That Keep The Balance We have built simple controls to avoid blind trust or even excessive overrides, Strict thresholds for Auto classification, mandatory team’s review for all Review cases, spot audits of Auto mappings, tracking & analysis of override patterns to improve program, and we have clear ownership, AI suggests, Team decides. Impact In Real Numbers Now with this program, my team completes 5000 item migration in 10 days in total instead of 2 months. I have a clear breakdown of 10 days, Data setup + AI pre-load + first analysis is done in 0.5 day SAP mapping for Auto category takes 1 day Manual review is done for Review category in 7 days New MD setup for Reject category is done in 1.5 days This has really improved my team’s output and bandwidth, and also reduced the onboarding risk for new plants, and best part is, it is allowing two people to scale this work for our growing fleet. Bottom Line I trust AI where signals are strong & mistakes are low impact, I override it where ambiguity or risk is high. As you can see, we are improving the overall process, idea isn’t to remove people from the process, it’s to make sure people spend time only where judgement actually matters.

Process Context In our fleet size of more than 50 plants, we use SAP IBP as an AI-enabled planning engine for forward spare parts demand planning, replenishment strategies and inventory strategy for all operations and maintenance. We manage roughly 200 Million Euro, 78000 SKUs in inventory. Let me explain what IBP does, It autonomously calculates, recommends replenishment strategies (VB, PD, ND), and planning paraments such as safety stock, Reorder point, and Max stock, using consumption history, PM demand, variability and lead times. Currently, for us, the process already runs with minimal manual interventions. So the real challenge for us is not making AI work, it is ensuring it continues to work as intended over time. How We Prevent Drift While Keeping the Process Autonomous We follow the simple principle, Automation with explicit guardrails. Any IBP recommendation that changes planning parameters for items by more than +/- 30% from the current setting automatically triggers a workflow approval in SAP. Our workflow goes to Planning manager, inventory controller, Final approval from PGM & Myself. We have build a clear summary in approval process, along with raw numbers, it shows number of SKUs impacted, Net Inventory Impact on Max stock (Positive/Negative), Risks. This gives completely details to reviewers, to approve, reject, fine tune recommendations based on the actual business context, In our process AI proposes, humans decide only when risk crosses a defined threshold. What We Monitor To Ensure The Process Stays Healthy We simply monitor the business behaviour & outcomes. If I say very specifically, we look at frequency of parameter changes exceeding the 30% threshold, Repeated SKUs entering the workflow approval, Manual override trend, Inventory vs Service levels, Gap between IBP recommendation & executed parameters. How We Respond When Performance Starts To Slip When we see the drift, we don’t fix the AI engine, we review the decision logic, PFEP. Typically we revalidate the demand classification, Lead time assumptions, ABC calculations. We do the corrections at the policy & logic level, not through the repeated manual intervention. Evidence That This Approach Works Our this structure helped us to optimize around 12000 SKUs, delivering 3 M Euro Inventory reduction, 10 Million Euro Cost Avoidance in a year. Review cycle time has been reduced by 80%. Now process auto approves 70% of recommendations. Bottom Line In my view, AI enabled process stays effective over time not because it is constantly supervised, but because decision rights, thresholds, and escalation rules are designed upfront. We let SAP IBP run high volume, repeatable decisions, while we intervene only when changes signal the real business risk, and then we judge system health by outcomes, not by how often people touch it, this shows the clear example of how autonomy & control coexist with AI delivering the value not drifting the process.

Domain & Project Context This case comes from a lean six sigma project I led in one of my previous company (Medical Equipment Manufacturing), focused on a critical sub-assembly line of Mobile Viewing Station (MVS), which is critical part of all C-arms medical machines we produced. This supported the Yearly revenue of 85 Million Euros, Monthly output/demand of MVS was 150, each MVS required one complete set of LCD Carriers. To give better context, MVS displays live the images from C-arms of patients for the surgery and doctor’s operates C-arms by MVS controls. Since MVS was the mandatory piece of final machine, if this line stops, C-arms assembly lines stops as well, thus impacting revenue. What Actually Happened We started seeing the severe rejections of LCD carriers at the MVS line. We observed minor shape distortion, visually parts looked fine, but during the assembly LCD monitors would not seat properly. At our end, rejection rate climbed to 85%. We looked at few process details, injection molding time 7.5 Minutes, followed by 10 mins in cooling fixture. We observed on paper, everything looked stable, however in reality, something in that window was introducing deformation. We attempted the rework to keep the production alive, with success rate of 35%, rework was clearly a containment action, not a solution for us. If I had AI Available then & How I Would Use It Today If I had to deal with this problem today, I would bring AI early. AI could help me quickly correlate: Rejection rates against injection molding cycle times Cooling fixture duration vs shape deviations Differences across mold cavities & production shifts Batchwise behaviour at the supplier Measurement variation between supplier & our plant Raw material behaviour (33% Glass-Fibre Nylon From BASF) Assembly fixture tolerance stake-up at our line It would have helped me to form hypothesis faster & narrow the investigation space. However, in my view that’s where AI’s role ends, these correlations are signals not evidence. It could not tell us which one was the true root cause. As LSS expert, it I treat AI output as a hypothesis accelerator not a validator. Statistical Confidence (What was good enough & What wasn’t) This project reinforced something I strongly believe, The level of statistical confidence required depends on how irreversible the decision is. We needed speed and for short actions like rework to protect the output, directional confidence was acceptable. But for irreversible decisions, statistical rigor was non-negotiable for us: Redesigning the molds Changing the cooling fixtures geometry Locking supplier process parameters Declaring the permanent fix of the issue With 85% rejection, limited rework success & 85 Million Euro revenue at risk, we relied on below: MSA at supplier Independent MSA at our plant Controlled trials on molding & cooling parameters Physical verification of carrier geometry at assembly No AI could replace the level of proof. Data Quality & Credibility (Still LSS Responsibility) One of the early discoveries we made was that measurement variation itself was part of the confusion, the same carrier set measure differently at the supplier & at our plant. Just imagine, if I had trained AI on that data without first fixing the measurement system, it would have produced confident but misleading insights. This reinforced a core LSS principle for me, before trusting any analysis by human or AI, validate the measurement system. In my view, AI processes bad data faster, it does not make it more credible. Correlation, Prediction & Causation This project clearly force us to respect the difference in between all three: Correlation: Certain batches & cooling windows showed higher rejection Prediction: AI could likely flag high-risk batches Causation: Only controlled testing proved that cooling fixture design and post-molding deformation were the real drivers Causation was confirmed only after we: Stabilizing the measurement systems, validating the material behaviour, redesigning cooling fixtures, updating the assembly fixture geometry. That sequence mattered for us. Bottom line- Where AI should accelerate & Where it must not In my view, AI should accelerate inEarly Pattern detection,Hypothesis prioritization, & Faster narrowing of investigation scope. However, traditional statistical validation must remain non-negotiable for us when: Root causes are declared, Tooling/mold changes are approved, supplier processes are modified, production release decisions affect the final product. On conclusion note, AI would help me move much faster at the front end, however when decisions affect 85M Euro revenue, medical equipment (patient safety) and irreversible tooling changes, classical lean six sigma discipline still defines what counts as proof.

Industry Power & Water Production- Asset intensive organization Process & Context I am going to share a project that already exists on Master data management in Supply Chain Management for all the plants we operate in 14 countries and under different technologies as CCGT, CSP, Wind, Solar & SWRO. This is the first step of our procurement process, all procurement is done via a unique material code. Our material master has grown to 378000 different items. The huge size of our database was not created in one day or because of a one reason. Let me explain, our Master data creation used to be decentralized. We acquired plants also, integrated different systems, ERPs, migrated data many times. In all cases, our company’s priority was to keep operations running, not the standardization. The effects of that legacy are now clearly visible to us: We have a lot of things in our inventory. Total approx. value is around 200 million euros. We have around 15,000 materials that the Material Requirements Planning system or MRP is actively planning for. We have around 78,000 items physical in stock across the fleet. We have active transactions in last 4 to 5 years on unique 125,000 material codes. We started seeing a trend, almost similar spares were existing under multiple material codes across the fleet, our stock was spread across multiple look-alike stock items. We also missed opportunities to manage common spare/stock for the fleet and incomplete, inconsistent master data in SAP due to legacy templates. We clearly understood, this was not just a data cleansing issue, and it was significantly impacting our fleet inventory levels, spareparts optimization, and our procurement planning efficiency for 50+plants. My current ongoing initiative I am working on master data enhancement initiative, using AI to support the heavy analysis work. Here, AI is helping us to completely check the full masterdata, indicating the duplicates, descriptions comparison, technical details check, matching the part numbers with our usage/consumption trend, and finally tracing the link back to higher level equipment in plant, all using the SAP data. We have setup 23 key parameters as criteria for AI to check, and you can imagine, without AI, this analysis would have taken many years. Now, we can truly focus on the human efforts on the identified cases that really needs attention. AI is enabling the work and people still makes the decision. Ongoing Results & Early Wins Practically, we have already compiled our spares across Wind turbine plants, CSP Plants & CCGT plants. In many cases, we have found more than 3 material codes under the same functional spare, and keeping the parallel stock without clear visibility on consumption. We have started seeing fewer duplicates in MRP items, better visibility on fleet level stocks, elimination of duplicate codes creation at first step of new MD creation. Our estimation is (based on the validated items sofar), we will achieve 7-9% cost avoidance, which will reflect around 14-18 Million Euro on inventory base. DMAIC Role In This Case With AI being used for find patterns very fast, Define step has become even more significant. The real question for us was never how many duplicate codes exist, but which item codes may actually create the risks or value. We clearly had to be focused from start that this project is not about deleting the records; it is about “Optimizing the spares without putting our asset reliability at risk”. With this clarity, Measure become better, we moved from sampling to analyzing the full 378000 item database, linking the duplication, gaps to actual inventory value and our consumption across the fleet and technologies. In Analyze, we used AI to group the similar materials, but this alone was not enough. Engineering, maintenance & Supply Chain Teams still had to assess the OEM constraints, safety requirements, LTSA, functional perspective & limitations. AI helped to speed things up for us, but the main judgement remained essential. In Improve, we are taking suggestions as options not answers, teams reviewed them cross-functionally, we piloted the changes at selection of plants and even assessed risk before scaling to our fleet size of 50+. For Control, now AI flags the near-duplications during the new master data creation, and also underlining the deviations from standards set. However, the Governance of whole remains with us, that is human-led, We approve the exceptions, decide when such cases make sense, and we are feeding the learnings back into the rules. Conclusion While AI has significantly improved the speed of execution for this initiative, however it hasn’t changed who owns the critical thinking. In my view, Measure & Analyze are pretty much stronger with AI; Define, Improve, and Control still depends on human judgement. My role is to ensure DMAIC doesn’t turn into automatic answers, but continues to support decisions that faster, better and sustainable for the organization. AI is creating the opportunity, and disciplined improvement makes it real success.

Domain: Strategic Sourcing, Procurement & SCM – Asset intensive organization, into Power & Water Context: We build & operate multiple plants in 14 countries, different technologies with high procurement complexity, multiple categories, and large, diverse supplier base. Three years back, we roll out an e-sourcing tool, for our procurement process. Main idea was to bring order, consistency in the process, and overall transparency into sourcing and negotiations. When the tool was implemented, all the existing supplier base was categorized into a category/commodity structure, which was built by the tool implementation team using UNSPSC standards. On paper, the structure was correct & industry accepted. All the suppliers were classified, commodity categories were created and we went live the system technically. But after living with it for a while, it became clear that something still wasn’t working the way we expected. What we noticed: What triggered this initiative wasn’t a system failure, we noticed a pattern, we kept seeing in day to day sourcing process. In many RFQs we observed: · Buyers were inviting more than 20 suppliers · Only two or three suppliers would respond · Lots of effort of buyers went into the managing suppliers who were never going to quote · Negotiations didn’t have the pressure & competitiveness we assumed they had, just less than 5% from first quote to final quote Theoretically for us, activity level was high & compliant, however in reality, the outcome was showing a different picture. Our question shifted from “Is tool working” to “Why buyers are working so hard and negotiating so weakly”. That’s when we decided to drill down and realized this wasn’t a tool issue, it was a process and decision-making issue. From the Lean Six Sigma lens, this was clear waste: Overprocessing (Too many RFQ invitations) Waiting (Low response cycles) Lost Opportunity (Poor negotiation leverage) Process (What we are now implementing) We started by slowing things down instead of adding more dashboards. We mapped the sourcing flow end to end: · How categories are defined · How suppliers are shortlisted · How RFQs are issued · What actually happens between the first quote and the final quote Once we looked at the five years of spend (approx. 2.2 Bln Euro) and item level data (150K Item codes), RFQs (45000+), the gap was obvious. The category structure made sense theoretically, but it didn’t reflect how money was being spent. We made a call to rebuild the logic. This is where AI plays a role: · Classify five years of item-level spend from L1 to L5 · Rework L3 & L4 (commodity & sub-commodity) based on the real buying behaviour · Link items to suppliers using actual spend & receiving history · Build a complete category, item & supplier close loop in a structure manner Our goal is very simple: When a buyer raises an RFQ, system should naturally surface relevant 5-7 suppliers, to help them, not 20 irrelevant ones. To make this happen, we have implemented: · The new supplier category structure in the tool · All buyers are being trained on the same · Clear RFQ rule in tool on threshold e.g. Max 7 suppliers for RFQs >8000 value, Max 3 suppliers for RFQs <8000 value · We are tracking new process leading indicators- RFQ Response Rate, Negotiation Delta (First Quote vs Final Quote), Savings achieved per RFQ In this case, AI will help us to calculate and present these insights, but it does not own the decisions, which led us to the next part where I will talk on role of MBB. The Role of MBB in this AI-enabled improvement journey: If I am being honest, the biggest role of MBB here is to keep asking why we are doing this in first place, which means MBB must own the problem framing. This initiative is not about, improving tool, cleaning supplier data, using AI for classification. The real problem definition is, "sourcing effort is misaligned with supplier relevance, reducing negotiation effectiveness and savings". What MBB Ensures: · The improvement stays focused on the value creation · CTQs are clear (response rate, negotiation depth & savings) · AI is applied to improve the process, not just to analyze it. What MBB must challenge: I fully expect AI to do clean classifications. That’s what it’s good at. What I don’t take at face value is what comes after that. For example: Whether the new category logic improves competition Whether suppliers are being excluded due to any historical bias Whether response rate improvement translates into the real savings This is Lean Six Sigma thinking: Correlation is not causation Patterns must translate into better decisions Insights must lead to action AI accelerates analysis. The MBB ensures the analysis is decision-relevant. What MBB has to safeguard in this case: From my own experience, biggest risk here is not AI being wrong, the real risk is buyers quietly going back to old habits. For them, RFQ rule slowly becomes just guidelines, exceptions become normal, and before management know it, buyers are back again inviting 20 suppliers because they feel safer. So, big part of my role being the project manager of this initiative is protecting a few basics: · Adoption of new logic and is used in all RFQs, day to day sourcing · Ensuring the governance is real and not just optional · Transparency, so buyers understand the why for supplier’s suggestion in tool · Ethical use, where AI recommendations are explainable and challengeable without ignoring them completely Without this balance, we will end up with sophisticated model, same old habit, or even worse, buyers stops trusting the system or process. Why this really matters for organization: If I get this right: · Reduced wasted sourcing efforts from buyers · Improved RFQ response rate, naturally · Increased negotiation effectiveness and more focused · Converting AI insights into real & repeatable savings If done poorly, it will become another good analytics project for us with no lasting impact. Bottom Line In my view, AI is not something an MBB competes with in this journey. AI is exceptional at handling big data and spotting the patterns at a scale which no team even can, however MBB can turn that into sustainable improvements. What I believe AI cannot do is to decide what is worth fixing, what is fair, so MBB ensures AI is used in the right place, for the right problem and in an ethical way people can trust. Disclaimer: Exact numbers are not shared due to external communication guidelines of company.