Aloke Biswas

Domain: ITIL, cloud, digital services, cybersecurity and consulting based out of 26 countries In my DEX work today, the responsibilities are very clearly divided. The DEX Operations team handles device stability, patches, policies, and fixing issues quickly. My side, the DEX Analytics/RCA team, focuses on finding patterns, doing deep investigation, and explaining why certain experience problems happen. When an issue appears, Operations waits for us to analyze the data, and we wait for them to confirm the actual ground situation. This creates delays and back‑and‑forth. If AI becomes fully integrated, this split will start to feel outdated. AI can already spot unusual patterns, connect incidents with changes, and even suggest possible fixes or policy rollbacks. If Operations waits for the Analytics team to verify everything, it slows down. But if Analytics pushes insights without understanding who will actually change settings or policies, that creates risk. AI sits in the center of everything, so the old separation becomes a blocker instead of a strength. In a fully AI-enabled DEX setup, I think the boundaries will shift toward small joint teams. Instead of Operations and Analytics working separately, we will have “DEX Reliability Pods.” In each pod, there will be someone like me who handles RCA and data interpretation, an operations engineer who can safely execute changes, and an experience analyst who understands user behavior. We would share one set of goals and work together on the same list of issues and improvements. When AI gives an insight, the pod validates it together, tests it on a small group of devices, watches the impact, and then decides whether to scale or revert. This means some roles will naturally merge or change. Operations engineers will not just wait for reports; they will use AI insights directly and help validate them. Analysts will not only produce dashboards; they will help turn insights into automated actions. My role in RCA will focus more on judging AI recommendations, checking missing data, and making sure wrong AI advice does not lead to wrong actions. I will also help improve data quality so the AI becomes smarter over time. We will still need separate teams for security or compliance approval, but the day‑to‑day flow between Operations and Analytics will be much more integrated. Instead of handovers, we will work together from start to finish. This will make the process faster and reduce confusion, because AI-driven decisions need people who understand both the data and the real environment. So overall, AI will push us away from the old “Ops vs Analytics” structure. Our teams will work as one, sharing responsibility for detection, validation, and action. This model fits the way DEX actually operates when AI is involved and helps avoid delays that come from old team boundaries.

Domain: ITIL, cloud, digital services, cybersecurity and consulting based out of 26 countries I work in the DEX team, and my main responsibility is understanding end‑user experience issues, finding root causes, and helping reduce digital friction. Because of this, I already see how AI is changing my role and how it will shape my career path over the next 5–10 years. In the past, most of my work was manual. I had to look through device logs, ticket trends, patch histories, and user feedback. I compared multiple dashboards and tried to connect the dots myself. RCA often took hours or even days because I needed to confirm whether the issue came from the device, the network, a recent update, the application, or a configuration. My progress depended heavily on how good the data was and how much time I spent on deep investigation. Now AI is slowly becoming a partner in my daily flow. It can pull signals from different DEX tools, correlate incidents with patches or policy changes, and point out unusual patterns. When a group of users suddenly faces slow login times or application hangs, the AI can suggest what changed recently and which devices show the same pattern. This does not replace me, but it gives me a head start. Instead of spending an hour searchingfor clues, I now spend that time validating the AI’s suggestions and checking what the AI might have missed. Over the next few years, I see the DEX career path changing in a clear way. I will still need strong understanding of devices, apps, end‑user workflows, and enterprise environment complexity, but my real value will shift toward making good judgments based on AI signals. I will spend more time confirming whether the data supports the AI’s recommendation, checking for bias, understanding if anything important is missing, and deciding the safest next step. I will become less of a manual 'log diver and more of a decision‑maker who knows how to use AI-generated insights carefully. Around the 3 to 6 year mark, I see myself becoming more like a DEX Problem Specialist or Experience Owner. I will use AI not only to fix issues but to prevent them. I will look at silent device problems before they become outages. I will use AI to spot early signs of crashes, software failures, digital friction, and experience drops after a new update. I will also take responsibility for improving the data behind AI models: making sure device telemetry is accurate, ticket summaries are meaningful, and experience surveys are properly tagged. AI is only as good as the data it gets, so this becomes part of my job too. After 5 - 10 years, I think this path leads to something like a DEX Operations Manager or an Experience Reliability Lead. This future role will be about shaping how AI works inside digital experience. I will decide where AI can help automatically, like early detection or recommending fixes, and where human review is needed, especially when the risk to users is high. I will lead a mixed team that understands devices, applications, user behavior, and AI tools. My focus will move from only solving issues to managing end‑to‑end digital health for the whole workforce. Some older skills will reduce in importance. Manually searching multiple dashboards or reading long log files will not matter as much because AI will do the first summary. Also, relying on memory of old incidents will matter less because AI can recall hundreds of past experience issues instantly. But some new skills will become essential. I must become good at checking evidence and asking the right questions. When AI says 'the issue is caused by a recent patch' I must confirm whether the signals really support that or whether something else was missed. I must understand the limits of the AI model and notice when critical data is not included. I will need to design safe validation steps, like testing fixes on a small user group before rolling out to everyone. And I will need to communicate clearly so stakeholders understand the impact, the risk, and the plan. Performance measurement will also change. Instead of only tracking how fast I produce an RCA, we will measure how accurate the RCA was, how many issues we prevented, how well we validated AI suggestions, and how consistent our explanations were. We will also track how many misleading AI recommendations we caught early. This avoids the danger of blindly trusting AI or refusing to use AI at all. Training must be practical. What helps most is replaying real experience issues: first without AI, then with AI, and comparing the difference. Short weekly exercises also help, like practicing how to ask better questions to the AI or checking for missing data before accepting a recommendation. We can also run scenarios where AI is wrong on purpose, so the team learns how to detect those mistakes. In short, my career path in DEX will move from manual investigation to AI-guided decision making. I will be valued less for finding raw data and more for judging it, validating it, and using it to improve digital experience across the organization. My domain knowledge remains important, but my ability to work with AI, challenge it, and improve it will decide how far I grow in the next decade.

Domain: ITIL, cloud, digital services, cybersecurity and consulting based out of 26 countries I will use one real ideal process from my work which is major incident management. This is when a very important system goes down or becomes slow and many users or customers are impacted, so is the business. Before AI the workflow was simple but usually very slow. Whenever a major incident happened we would start a call and invite all the technical teams, SMEs from network, application, database, security etc. everyone checked their own tools, logs, records etc. We would usually get on a meeting to find the cause. sometimes people argued because each team thought the problem was not theirs, there was no clear cut bifurcation or problem identification. It took at least 15 to 20 minutes just to agree on the first possible cause that too after a lot of disagreements. The goal was to find a work around first, update stakeholders every now and then typically within 30 minutes and bring the service back as quickly as possible. Now with the help of AI the first step at least moves faster. The AI can read the historical logs, metrics, errors, monitoring alerts etc. from many systems. It can also check if any change or deployment happened around the same time then it tells me the top two or three possible causes, even though it does not solve the problem on its own but it helps me know at least where to start or a high level root cause and where to investigate first. It also drafts the first message for stakeholders and suggest which playbook/rules to follow based on past incidents. This reduces confusion and at least speeds up the early decisions. There is one situation which I recall where AI improved results a lot. One time we had sudden 502 errors. AI was notified that there was a deployment 15 minutes before the issue began and it saw that memory usage and garbage collection patterns matched an old incident. It suggested rolling back the deployment or scaling up the app further into other servers, this helped us fix the issue faster instead of wasting time exploring other areas like network or database first. There is also a situation where AI can create problems. Once after a storage upgrade the application became very slow. the AI obviously did not know about the storage change because this change record was not fed yet. So basis the historical data the AI is thought it was the same old database time out issue and recommended tuning the connection pool once. Our DB technical team followed that direction and wasted almost 40 minutes! Later we found out the storage upgrade caused micro delays. This shows me that AI can be wrong when the data is missing or not updated which we all know is a drawback of AI. If the data fed is not correct or up to the mark or updated, the output is bound to go wrong and this is where we need to be careful as well as we have discussed in one of the previous forum questions. From these experiences one important skill which I learned is checking evidence. I cannot trust AI blindly I must understand why it is giving a suggestion and check if the signals match what I see and the skill is understanding what information the AI can and can't see. If I know the AI doesn't have the latest change records I will obviously fully not trust its suggestions, I also need to quickly test when the resolution is correct or not by doing safe/Qualitychecks. The ability to ask good questions to the AI also becomes important like -show any signals after the last deployment or compared pre incident and post incident data. Some old skills becomes less important for example manually searching through many dashboards and log tools becomes less important because the data is already collected and fed and the AI summarizes that information. Also the best part is depending on memory becomes less important because the AI can remember hundreds of old incidents. We also do need to keep on updating the excels and records locally in our systems. Performance metrics also need to change, instead of measuring only speed we should measure how good the first thought is and whether we used good judgment. We should also track how many times we check the AI’s answer for acting and how many wrong suggestions we detected. This prevents blind trust.At the same time we should encourage people for using AI because this is the latest technology, this is the need of the hour. This is obviously a friendly in need but that creates trouble as well. Instead we measure how well the person uses AI to support good decisions. For training, I think simple and practical sessions work best we can take real past incidents and replay them first without AI then with AI. after that we compare the results and discuss what we learned. Short weekly practice sessions also help like how to write a better question to the AI or how to verify an AI recommendation with quick quality checks. In fact we have also created a list of AI prompts which can be used for typical scenarios. Just to summarize this example I would like to state that AI definitely helps make major incident management faster but it still continues to need a lot of human judgment. This is where the experts, the technical experts, architects etc. are needed now more than ever simply because this is the initial stages of AI and we really need to validate if this can be used independently as soon as possible in the near future. As I have mentioned in one of the previous post that AI is used as a helper not a replacement. The AI is good at speed and pattern recognition and repeatable data but myself, the SMEs the technical experts they are basically responsible for safety,understanding the business impact and making the final decisions.

Domain: ITIL, cloud, digital services, cybersecurity and consulting based out of 26 countries I use AI in my ITIL work as a helper or assistant that supports me but does not replace my judgment. I trust the AI when the situation is stable, normal and based on repetitive issues or good data. for example if the AI looks at past tickets and tells me this incident is likely related to a network outage and I see that the symptoms match whatever I have seen before then I usually follow it on routine tasks like suggesting the correct ticket category, predicting which teams would handle the issue or recommending a known solution. AI usually very reliable because these tasks follow patterns from history. Another example is problem management. sometimes the AI analyzes logs and says most similar cases were caused by a memory leak. If the logs support this, I trust the AI and investigate the direction first. It saves time compared to checking everything manually. But there are times when I need to override the AI if the system is business critical like a payment service or a customer facing portal or an industry which will be critical impacted like railways airlines. For example if the AI suggests restarting a service during business hours I may ignore that advice because it could cause downtime. My experience tells me that even if the AI thinks it's safe, a small mistake can actually trigger major incidents and escalation. Sometimes I also override the AI when the situation is unusual or new, once a ticket came in with very strange symptoms, the AI predicted a common root cause but I knew from experience that that this didn't make sense because the system had recently been updated. AI obviously did not know about the update, so I relied on my judgment, we spoke to the SMEs and the process owners and then found the real issue later. A simple ruler what is this I trust AI when the risk is low and the task is more routine with the outcome familiar. I override I when the risk is high the data is unclear we don't have any SMEs or process experts or process owners or delivery leads to support the case and validate. AI surely helps me finish work faster but I take the responsibility for the important decisions. Moreover we are also not allowed to upload real data and numbers directly on the AI tool, so many a times the answer is generic. With the current dynamics of work, I see that as a great helping hand in the near future.

I have been a part of two different industries in last 1 year abd have witnessed very interesting discussion around this. the first one was a product based one and the current being a ITIL industry. The previous company which was product based had more flexibility in terms of adopting and experimenting but my current ITIL org is far more sensitive when it comes to deliverables as the impact often goes to the end customer. My product based org was actually taking the AI things slowly without changing much but here we are more focussed on shorter projects. with AI actually, DMIAC will become far more feasible. For this year, we have kept that as one of our ways to run atleast one improvement project in a quarter and the proposal is under final review.DMAIC in itself isn't a tool but a guiding principle and methodology. With AI, its actually is a good thing for our scenario where we need speed more than accuracy. it'll go hand in hand with the DMAIC methodology. every step which used to take days and weeks of analysis will take minutes or hours now, the takeaways will be easier to uncover.With ITIL framework,I can already think of a project which can run DMAIC with integration of AI. In our service desk environment,a common improvement initiative is reducing incident resolution time while maintaining service quality.This is a basic thing which we are dealing with everyday. Traditionally DMAIC would take lots of discussion, workshops, and manual analysis. With AI,the define stage itself can start with AI application, just using data dump itself is enough to identify the scope and target, this activity usually takes days of work. The same would continue into the next stage, baselining of current incident counts, the current process capability can be easily calculated using data dumps from dashboards and service now. Possibly the best combination of AI and traditional approach comes in the next stage of Analyse and improve.AI can quickly analyze large volumes of incident data, SLA breaches,user sentiment and ticket data to highlight patterns that normally takes weeks to understand, it can reveal that delays are less about analyst performance and more about poor categorization,repeated reassignments or gaps in knowledge articles. This strengthens the improvement effort by providing a clearer, data backed view of the problem. Also here our judgment remains critical. AI may show correlations,but it lacks the background or domain knowledge that a SME can possess, it cannot fully understand business priorities,customer frustration or cultural realities within .Decisions such as which pain points to address first,whether automation is appropriate or how much change a team can absorb will still need our expertise.Even during solution selection out of the multiple options presented by AI, ultimately it'll come down to us to pick the right one knowing the management priorities, future demand etc. Also the Control stage would need a lot of manual validation and human intervention. Although AI can help in the statistical part faster which we really need in my scenario. To really summarise, AI will help will actually help our case to initiate DMAIC due to speed, accuracy etc but we'll continue to be accountable for the case specific judgement and outcome. The next few months is going to be more exciting for sure.