Leaderboard

Domain: Aerospace MRO - Engine shop for CFM56/LEAP Turbofans for Performance Restoration (€ 220 Million yearly turnover , approx. 1,800 shop visits in a year, AI rolled over since late 2025 to predict HPT module rework needs based on borescope images, oil debris analysis, and in-service data) Specific AI-enabled process: Predictive HPT Blade Rework Forecasting The AI will recommend if the module needs full blade rework, partial (only the tips), or none, all with the goal of eliminating unnecessary shop time and expense without losing the zero escape target on critical parts. It went live on all CFM56/LEAP visits in Q1 2026 and initially deliver an average 18% reduction in TAT on HPT modules. How we ensure & monitor the process continues to deliver intended outcomes We are treating this AI-human decision loop as a live control system and continuing to develop it over time not like one tine install, the focus is on sustainable business value – TAT savings, cost per visit going down, safety and zero quality escapes. What we monitor (daily / weekly / monthly) 1. Leading indicators (daily dashboard – shop floor + engineering) · Prediction accuracy of AI vs. actual rework result (confusion matrix updated every 50 engines). · AI suggestion Override rate by technicians / engineers (accept, tweak, reject AI recommendation). · Confidence score variation (how often is the model <80% sure?) · Data drift indicators, distributional shift of input variables (eg iron particles in oil, borescope crack density, EGT margin so on) 2. Lagging business outcomes (weekly review – operations + finance) · HPT Module: Turn Around Time Variance (target < 35 days). · Rework cost per engine vs. Baseline · Escape rate / quality holds on HPT (target 0) · Spare Parts Consumption vs. Forecast (Over/Under-Stocking Signals) 3. Model health metrics (monthly deep dive – MBB + data team) · Population stability index (PSI) on key inputs (>0.25 = moderate drift, >0.5 = severe). · Calibration plot (predicted probability vs observed rework rate) · Feature importance drift (which inputs is most important to the model now vs at launch) How we react when the going starts getting tough We have a three-level escalation protocol: Level 1 – Minor Drift (Weekly Trigger) · Override rate >25% or confidence <75% on >20% of cases. Response: · Immediate feed back loop i.e. every override by enginers requires 1-click reason (dropdown + optional voice note). · Retrain model based on last 100 engines + overrides justificatipn. · Notify shop team lead, usually fixes within 1-2 weeks Level 2 – Business impact emerging (weekly trigger) · TAT +3 days or rework cost increased +8% vs rolling 4-week average · OR escape / hold on HPT (even one) Response: · Hold AI recommendations - return to manual disposition within 48 hours/ · Root Cause A3 with MBB: Data drift? New failure mode? Change in user behavior? · Temporary rule: AI confidence > 90% required for auto-accept · Full model retrain + validation on hold-out set before re-release Level 3 – Systemic failure (monthly or immediate on escape) · PSI >0.5 on critical inputs OR calibration slope deviates >15% · OR sustained TAT/cost > 15% Response: · Full pause of AI in production · Independent audit: data lineage, labeling drift, concept drift · Notification to the regulator of any escape which occurred · Re-baseline from scratch or switch to a fall-back approach (manual and old rules) · Shared across sites post-mortem – we’ve had one Level 3 (new low-sulfur fuel changed oil debris patterns in Q3 2026) Practical setup we use today · Automated alerts using Teams/Slack when threshold breaches · Monthly “AI Health Review” (30-min standing meeting: MBB, ops manager, data lead) · Quarterly external benchmark against OEM data (CFM/Pratt) · Annual review of AI usage (EASA Part-145 requirement) Bottom line from the teardown bay AI Drift isn’t an ‘if’ but a ‘when’ In MRO, the price of slow degradation can be a long turn-around time, excessive spares, or even a failure in service. The way we monitor our AI is how we would monitor an engine, performing routine checks every day, and only grounding it completely when we have to. The process remains alive since we do not assume model is “set and forget”.

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: Solar Cell & Module Manufacturing Sector ( Capacity: 1.3 GW Solar Cell & 1.6 GW Solar Module Production and Supply per annum). When AI becomes part of a business process, it doesn’t remain static. Inputs change, user behaviour evolves, and the AI’s responses may slowly drift — even if nothing “breaks” outright. Think of a specific process in your domain where AI is/ could be involved in making decisions or recommendations. How would you ensure that the overall process continues to deliver the intended outcomes over time? What would you monitor, and how would you respond when performance starts to slip?Improvement Initiative: Build an AI enabled model for scheduling Preventive Maintenance to improve the following metrics in module manufacturing floor: Pre Lamination FPY%. Cell yield Stringer Uptime. Line Capacity Utilization. Final Quality Yield %. Why is this so important? It has been observed in almost all solar Module Manufacturing lines that the preventive maintenance has been always granted the least priority over continuous running line. This affects the line's Output quality degrading till the start of the PM and the recovery of the line capacity also gets delayed post preventive maintenance hand over. This has led to pre to post PM degradation of : Pre Lamination FPY% by 8-10% Cell yield by 30-50% Stringer Uptime by 20-25% Line Capacity Utilization 20-30% Final Quality Yield % 30 -50%. So instead of improving or maintaining the metrics, PMs often had degraded results for some durations and the business faced losses. These losses made the habit of PM so unpopular in the shop floor that higher management becomes reluctant to activate the PM schedule. If AI can be strengthened with all the historical data and learnings, it can optimize and generate a significant model for Preventive maintenance and the schedule for it. Monitor the Indicators for Positive delivery: Control charts: Though AI claims that the model of the schedule is still going good, the SPC of the above mentioned metrics can tell us the truth. Monthly Management review driven by MBB: As per ISO 9001, AI generated models should be reviewed thoroughly. if the metrics are drifting then the model is definitely failing whether the model accuracy is good or not. Learning correct reality: AI learning reality need to be kept in check. If the engineers acceptance rate is getting lower day by day, it may indicate that the model is not in the correct reality. It can affect catastrophically in near future. Parameter changes: if post PM , the parameters are still inside the recommended window then the model's health is good. Otherwise the model needs to be reverified. Control Strategy when performance slips: Some ground rules need to be confirmed before applying any AI model: There should be one golden PM schedule that is made with experts before starting the implementation, so that if any slip is identified one can revert back to the golden schedule. There should not be any sudden conclusion to scrap the model, first the root cause of incorrect reality needs to be identified and then rectify that. ( Example: Suppose a scheduling of PM for Ribbon Traction area in a stringer within an interval of 2 weeks has degraded the quality of ribbon alignment with cell busbar drastically. So primarily it may be misunderstood that the high frequency of the PM has affected the slot quality of that section and for that the degradation happened. But the reality may be that the frequency of the PM has nothing to do with that. It may be due to: 1. Wrong selection of Technician for such an important section, or 2. Wrong selection of the tools those have been used to do the PM. ) Hence to keep the model healthy and keep away from wrong decisions or reality , a well trained MBB needs to govern the model properly. What makes the model successful: Pro-activeness of triggering PM before the machine's performance starts degrading. Post PM the recovery should be minimized and reduced after every iteration. High positive Business Impact.

Domain: Aerospace MRO - Engine shop for CFM56/LEAP turbofans performance restoration visits (€220M turnover facility ~1,800 shop visits / year, focus on reducing module TAT and cost while maintaining zero escapes on critical parts) Specific Lean Six Sigma Project: Reducing High Pressure Turbine Blades rework rate from 42% To less than 25% On Performance Restorations (This is a complete high cost driver worth nearly €4 - 6M on an annual basis, given unexpected coating wear that we notice, coolant hole blockage or tip rub forcing rework delays in TAT by 8-12 days per engine. The project began Q1 2025, utilizing AI-based predictive analysis of the borescope images and oil debris pattern recognition.) How the MBB treats AI-generated insights in this project 1. Forming or testing hypotheses Traditional LSS: MBB first conducts brainstorming, resulting in hypotheses like “coating peal off is caused by EGT exceedances above 50°C cumulative. ” Verified using designed controlled experiments and / or regression analysis. With AI: The model shows correlations instantly (for example: “HPT rework 68% correlated with borescope images of micro-cracks near cooling holes + oil debris iron particles > 15ppm last 500 hours”). MBB Role · Consider these AI results as hypothesis generators rather than conclusions. · Turn the AI correlation into a testable null / alternative hypothesis, e.g., H₀: No difference in rework rate between high iron oil lots and low iron oil lots. · Run confirmatory DOE or stratified sampling – no AI pattern should ever be taken as ‘causation’ without this. · Document: “Terminal Object: ‘AI suggested X → we formed hypothesis Y → tested via Z’”” 2. Establishing statistical confidence Also, it provides probability scores, such as “92% confidence this lot will need HPT rework” but rarely includes p-values, degrees of freedom or power. MBB must: · Demand transparency in Data flow : force the AI team to show their statistical method, such as random fore sets, SHAP values, or Bayesian posterior probabilities. · Re-run important patterns using classic statistics: t-test, chi-square, logistic regression, etc. on hold-out data. · Set hard thresholds: AI insights only actionable if classical p-value < 0.05 and effect size > medium (Cohen's d > 0.5 or OR > 2). 3. Assessing data quality and credibility AI Agent is only as good as the training data set, so all the good, bad and covering full tolerance band must be used for training. In MRO, the historical borescope images and oil reports are noisy with several variations (different inspectors, varying illumination, and inconsistent sampling). MBB safeguards: · Check data lineage audit: who collected, when, under what conditions? Reject datasets if greater than 15% missing/mislabeled. · Use stratified sampling to check for bias: for example, do high hour engines dominate the sample? · Run inter-rater reliability on borescope annotations. Kappa >0.7. · Never blindly trust AI predictions on ‘Black Swan’ events — If the model is trained on <10 similar cases, treat as low credibility. AI accelerates decisions in a) Early Analyze phase: pattern discovery – 5 – 10 potential X’s in hours vs weeks of manual Pareto / fishbone analysis. b) Screening: quickly eliminate weak signals (AI correlation <0.3: drop the hypothesis). c) Simulation: Test “What-If” Situations (e.g., additional inspection predicted to lead to 18% reduction in re Where traditional statistical validation is non-negotiable · Causation Claims: AI provides correlation (iron particles + rework) – MBB requires DOE or natural experiment to establish cause. · Critical to Safety Features: Changes to the HPT system that affect HPT integrity require p < 0.01 + power > 0.9. · Control phase: sustainment metrics including rework rate after change, again using control charts – here, monitoring is done by AI, but control limits in terms of what constitutes out of control remain set by SPC. Practical outcome after 7 months · Rework rate is now 23.8% · TAT savings approx 9.2 days / engine on average · No escapes - since MBB applied classical validation on each major insight · Team trusts AI because it is “AI suggests àWe Validate à We prove it”. Bottom line from the engine teardown bay AI is an amazing needle finder, and it screens hypotheses better than we do. But in aerospace MRO, causation is king, safety is non-negotiable, and regulators don’t accept "the neural net said so". The MBB’s task is to ensure that DMAIC is keeping: leveraging AI to make discovery happen faster, relying on classical stats to validate everything, and never confusing correlation with proof. That balance makes AI a serious accelerator of real improvement rather than a shiny toy.