Mohamed Safir

View B — Preserve flexibility. Consistency is valuable. But standardization that ignores context doesn't improve decisions. It just makes bad decisions more uniform. The core problem is this. A large service organization across multiple regions isn't one environment. It's many. Customer expectations differ. Regulations differ. Cultural norms differ. And an AI trained on aggregate data optimizes for the average situation. The cases that matter most, the difficult, sensitive, unusual ones, are never average. For Example: IBM's Watson for Oncology deployed globally to standardize cancer treatment recommendations. Consistent, data-driven, scalable. Sounds good. But doctors in South Korea, India and Germany flagged it almost immediately. Recommendations didn't account for locally available drugs, regional protocols, or patient-specific circumstances. MD Anderson Cancer Center, one of the world's top cancer hospitals, walked away after spending $62 million on it. Experienced oncologists were being overruled by a system that was consistent but wrong. The experienced team member problem is also underrated. When you constrain people who genuinely know their context, you don't eliminate their judgment. You just stop using it. That's not efficiency. That's waste dressed up as process. The right model is simple. AI as a floor, not a ceiling. Standardization ensures no team falls below a baseline. But experienced people keep the right to override, with documentation. An AI that makes every region look the same isn't serving diverse customers. It's just making the organization feel tidier from the inside.

I support View B — organisations need to limit how much they rely on AI. The performance numbers look good on paper. Decisions are faster, errors are down, the team seems to be doing well. But the problem is what's happening underneath. People are slowly losing the ability to make decisions on their own. When AI is unavailable or gives wrong outputs, the team is expected to step in. But if they have not been doing that work regularly, they will struggle. That is the real risk here. A good example of this is Knight Capital Group back in 2012. They had automated most of their trading operations. The people on the team had moved from making decisions to just watching the system. When the system made a mistake, they took 45 minutes to stop it, because they were no longer used to working without it. In that time they lost around $440 million. The company never recovered from it. This is exactly what happens when teams rely too much on AI over time. The system works fine most of the time. But when it doesn't, the people behind it no longer know what to do. The answer is not to stop using AI. It is to make sure people still practice doing the work manually on a regular basis. Run the AI for day to day tasks. But also make sure the team can still function without it when they need to. Improving speed is useful. But an organisation also needs to be able to recover when things go wrong. Right now, based on what is described in this scenario, that ability is being lost quietly in the background.

My opinion is not to adopt in the current form. Improving average performance in aviation is meaningless if it breaks 2-3% of the time. Airlines are normally scored on their worst days. In aviation, a single delay have a cascading effect on crew timeouts, aircraft position, connecting passengers stranded, slots missing etc. It is connected closely and breakage in one loop has a cascading effect. The real world example of Southwest Airline in 2022 when the Storm Elliott hit - The tightly optimized network could not recover. The scheduling system didnt have any buffer to operate. Over 16,700 got cancelled in 10 day and an additional burden of the huge fine imposed on them. It is not to abandon AI - but needs to build mandatory buffers as a hard constraints - Even if the optimization percentage reduce 2-3%

Sigma Shift An improved process using DMAIC methodology is expected to be impacted by variations due to Common Causes & Special Causes. Common Causes Common causes also known as natural problem and random cause is a stage when the process measure shows random pattern within the control limit. This may be due to changes in machinery, measuring patter, employee, or environment. Although, the process is said to be statistically control or stable, a process capability to be conducted to understand the exact cause of the of the random patter. Special Causes Special cause variation is predominantly due to defect, breakdown, shortage, delay in the process. Special cause variation shows a non-random pattern of variation or process measures are plotted outside the control limit. In the short run an improved process is impacted by common cause variation as we are calculating the Standard deviation and Sigma level for shorter period. During short term, the process will show good capability as compared to long term which is impacted by both Common and Special causes. This shift is the 1.5 Sigma shift. While calculating Long term Sigma level, it is obtained by subtracting 1.5 Sigma from the short Term Sigma Level.

Effect Size: Effect size will give the practical significant and shows the strength between variables or between a group. While hypothesis testing we check the statistical significance which shows the effect exists using the P-Value where as the practical significance shows how the effect is large enough and is represented by the effect size