R Rajesh

Let us consider an IT Product development process. A cross functional Scrum team is doing that development. The roles involved are Scrum Master, 4 full stack programmers (Developers), 2 automation testers and 1 Product Owner and the technology used are Java based web technologies with Microservice architecture Let us see what roles existed before AI and what roles got modified/added/removed post the advent of AI Table1 : Comparison on Traditional Cross Functional Scrum team roles Vs AI based Cross-Functional Scrum team roles: Traditional Roles in the Scrum Team (before AI) Roles in the Scrum Team (post AI introduction) Remarks (Add/Modify/Remove/Retain) Scrum Master Scrum Master (AI enabled) Retain Product Owner Product Owner (AI enabled) Retain Full stack Programmers(developers) Full stack Programmers (AI enabled developers) Retain Automation Tester Automation Tester Retain - AI Governance Lead New - AI Ethics Officer New - AI Data Lead New - Lead - AI Solution Architect Note: Here, all new roles incidentally can be applicable at an organizational level (definitely at a higher level than at a team level) Table2: Responsibilities of Traditional Cross Functional Scrum team roles Vs AI based Cross-Functional Scrum team roles Traditional Roles in the Scrum Team (before AI) Key Responsibilities of the traditional roles in the Scrum Team (before AI) Roles in the Scrum Team (post AI introduction) Key Responsibilities of the AI based roles in the Scrum Team (after AI implementation) Scrum Master Coaching team members in Self-management & help the team in becoming cross-functional Helps Scrum Team focus on creating high-value deliverables (a.k.a Increments) Helps in removing impediments for the team Ensures Scrum events(meetings) happen on a cadence Helps the Product Owner in finding effective techniques for Product Management Facilitates stakeholder collaboration Helps in streamlining the Scrum adoption across the Organization (in which the SM works) Scrum Master (AI enabled) Coaches team members in Self-Management and help the team in becoming Cross-functional Helps Scrum team focus on Creating high-value deliverables (increments) Helps the team in removing impediments Develops/Leverages AI tools to create meeting cadence for Scrum Events (meets) and allows AI tools to jot down key points as part of these events Guides the developers in leveraging AI tools such as Copilots for improving their productivity Encourages the Product Owner in finding AI tools that can help them in expediting User Story writing, Epic and Feature writing Product Owner Is accountable for effective Product Management Product Owner (AI enabled) Uses in-built Application Lifecycle Management(ALM) tools’ in built AI capabilities/AI tools for creating, modifying EPICs, features, User Stories Full stack Programmers(developers) Ensure that deliverables are met on time and quality is taken care as stated in Definition of Done (an agreed criteria within the agile/Scrum team) Full stack Programmers (AI enabled developers) Leverages Copilot for improving Code Quality, simpler and effective code writing, improving exception handling and saving effort on complex functionality writing. The result is an efficient code producing quality outcome, with minimal or no rework. High quality with less development effort Automation Tester Ensures that all features are tested – regression and functional testing done, Ensures delivery quality is high by constant feedback on delivery quality to all stakeholders involved and tracks all issues to closure Automation Tester With AI based tools , more test coverage is done both for functional (System) testing and regression testing. Complex Test scenarios are done far quickly Learning Curve for the Automation tool is much less now, when compared with the Past as AI takes in-charge - AI Governance Lead Takes care of the overall AI policies and procedures cutting across all aspects of AI presence in the organization - AI Ethics Officer Takes care of the Ethical aspects/concerns of AI involvement across the organization - AI Data Lead Accountable for the data to be consumed by the AI tool/solution (component, agent, or any AI element such as CoPilot) for this process. Takes care of the Data Security, Data Integrity and Data Privacy aspects of the data that is used by AI for this process. - Lead - AI Solution Architect Accountable for providing the solution/approach for making this process, AI based. In this specific context, this may be an overkill. For this process, this specific role is more of a guide to the whole team as which role can use what type of AI tool to improve their way of working or to increase productivity. But in a process where we tend to move towards AI (as final solution), then this is a pivotal role As you can see from table1, table2, in this IT development process, the existing roles can get empowered with AI enablement. In a typical IT development process, the above tables represent a more entry phase into AI transformation. The permutation and combination of using the existing roles and adding/modifying/removing roles vary from organization to organization and is highly contextual. One Organization can just rebrand the Scrum Master as AI Facilitator and another call it AI Technology Manager. So what is important is how do human beings collaborate with AI tools/agents Therefore key to this AI and human collaboration are Setting the goals and objectives clear Ensuring alignment happens keeping this in mind and therefore laying out frameworks like OKR.. Driving the corresponding KPIs/metrics (from the OKR) Collaboration with all the stakeholders with cadence Monitoring and tracking routinely the performance of the AI agents/tools (AI solutions) Inspecting and adapting the progress at every Product Review (in an agile world, this will be a Sprint Review at every few weeks)

For an audit, there will be an audit checklist. The audit checklist is key to an audit process. It does not matter whether its for a traditional process or an AI-infused process. Having said that lets quickly see the response for these questions : What new questions, checkpoints, or risk indicators should be included when auditing a process that includes AI components? 1. Do all the AI components serve the intended purpose 2. Do all AI components adhere to the Data governance & data privacy policies and procedures (Risk indicator) 3. Do the AI components adhere to the Safety/Security regulations (Risk indicator) 4. Do all AI components are easy to diagnose/dissect if there are any issues to fix 5. Do we have the right metrics to measure the performance of the AI components (checkpoint) 6. Do we have a benchmark/threshold value(against the traditional way of doing the process) defined for the AI components as how effectively deliver in terms of timeliness, providing quality output/outcome etc.. 7. Do the AI components as any ethical concerns (Risk indicator) 8. How much AI knowledge the auditor has, to audit an AI infused process – based on this only, the audit checklist can vary and the effectiveness of the audit itself will rely upon (Risk indicator) For instance, if I want to create an AI systems for an insurance company for creating an insurance policy , I may need to have several AI agents. May have an Agent for underwriting work, An Agent for Premium, An Agent for collecting user (customer) data and an agent for Policy creation. Now I need to check if all agents serve its intended purpose and also all agents should integrate and work in unison so as to get a policy created properly and in a timely manner. The AI agents also need to ensure that the regulatory rules/laws and compliance to GDPR laws of the region/country should be captured as of on the date of policy creation. They also should focus on any ethical concerns that might pop out as part of this process. These are potential area of risks. By ensuring the above audit checklist questions , checkpoints and risk indicators are addressed, we can ensure that this Insurance Policy Creation process can be smoothly done. How would you ensure transparency, fairness, and alignment with business goals? 1. With the help of a visual radiating tools like Kanban boards, display the state of each AI-infused process, to the stakeholders 2. As we deal with AI infused processes, the BRD plays an important role here. We should have the goals, objectives clearly articulated and communicated to all the stakeholders 3. Periodic feedback of the AI-infused processes will provide a overview of each such process and comparing with the BRD can point out whether the current state of the processes are in alignment with their business goals Conclusion: In my perspective for AI infused processes, the fundamental difference in auditing is the AI knowledge possessed by the auditor. IMHO, an ideal way to do an audit this type of AI-infused processes is to combine human with AI. So when an audit happens for AI-infused processes, the audit checklist can be fed to an AI Audit agent which can handle that and which can self-learn over a period of time (inspect and adapt) and then that can be overseen by a human auditor. This way the audit can be more effective while dealing with this AI-infused processes.

What signs would indicate that an AI solution is becoming fragile or outdated? In my purview, there could be quite a few reasons. Let us list that 1. During regular audit reviews, when there are frequent cases of observations and findings that portray things such as non-compliance on some of the project delivery aspects, non-satisfactory issues to stakeholders, business stakeholder escalations … then they can be viewed as potential indicators that our solution may look a revisit.. These things can also occur due to lack of self-discipline, but the chances are that the AI solution, may have to be re-visited as well. 2. We may have identified some metrics for our AI system. We would have set up some value/effort savings (some kind of tangible benefits). Initially we may have been able to achieve our intended purpose. But over a period of time, we may see the results going down .. That may be an indication that your AI solution is either not resolving the issue or becoming obsolete. 3. For example in an IT industry, Strange behavior seen in the system/application (which has AI solution), when deployed in different environments(from Dev & QA environment to Prod Environment) How can one contribute to ensuring long-term sustainability of AI deployments? Let us see some of the ways 1. Have an adaptable system. While designing the AI system ensure that the system is in a position to do self-learning (for eg, leveraging a reinforced learning approach can help the system to adapt itself to the emerging needs) 2. In your BRD, define possible architecture edge cases. The edge cases can constitute – rare case possible design scenarios (can tell as at what situation, we need to go for Supervised/Unsupervised/Reinforced learning.. as an example) 3. With Audit reviews and stakeholder feedbacks, we will be able to arrive at a decision that the AI solution provided is able to match the business needs

It’s true that AI is changing the landscape in every industry. For instance, few years back, Agile was becoming a buzz word not only in IT industry but also in every industry. Today that word is loosing its stream, and everywhere, AI/Gen AI has become the buzz word. IMHO, there is no one specific approach/framework/way to keep AI efforts grounded in value. But there is one thing/entity that can make it grounded and that is we, human beings. Let us take a deeper dive on this. Every industry has taken time to evolve. For instance, let us take a look at few industries. In IT industry – from a hardware perspective, the evolution started from a mainframe-based system to a desktop based system, followed by a laptop, then palmtop, smart phones and now we have wearable devices… Similarly from a software perspective we have large legacy systems, desktop based systems/applications, internet-based applications, mobile based systems/applications, Cyber systems, IOT systems, AI based systems Similarly from an IT operating model, we had traditional Waterfall based model (Requirements are fixed), Agile based operating model(requirements keep emerging iterative and incremental approach to development) , Product based operating model with Agile (product centric development), AI based operating model.. If you take insurance/banking industry, similarly we may have a similar structure as what we saw for IT operating model (instead of Agile, here it is lean) Traditional approach (as per the industry – where so much internal dependencies across departments may happen if a process is spanning across multiple departments and where there could be many wastes in between the steps of the process) , lean-based approach, AI based approach As we can see every industry is moving towards AI..which seems to be the inevitable end-state. In all these examples, the common thread is human involvement, as of now till date. But as we see that there is scope for systems to be completely autonomous agents, in the future, then this is where the challenge lies. It’s important that we leverage this AI technology to ensure that it serves and is being aligned with the business priorities. If you had seen the movie “Jurassic Park”, the genetically engineered dinosaurs creates havoc to people, when the park’s security systems fail. AI is your dinosaur. Your security systems in this case is your business priorities. If those priorities are not addressed by AI, then it will severely impact the stakeholders (from the people who invested in AI to the people who want to use the product and the people who developed it) There are two things that we can consciously do to ensure that we are in charge of this journey (AI completely ruling the roost and not aligning with business priorities) 1. Human in the loop (HITL) : a. We, as AI leaders (be an AI solution architect/MBBs/as a responsible AI stakeholder), need to ask a thought-provoking question to the leadership team how much do they want to give control to AI (say Agents) for doing the work? 2. There can be few approaches that can be used IMHO. I will pick 2 specific approaches which are popular and easy to track as they provide clarity at every segment. – Objective and Key Results (OKRs) and Future Reality Tree (FRT) a. Objective and Key Results (OKR) (as Framework) i. State the objective – You can list out your objectives as what you want to achieve ii. Key Results – You decide on what KPIs/Metrics for the stated objectives and accordingly arrive at the results iii. Based on your KPIs/Metrics, as an AI practitioner, you need to ensure that your AI solution/Agents are defined/formed b. Future Reality Tree (FRT) (tool/technique) i. With desired outcomes, you can state your intent (business needs) ii. Based on that you arrive at your intermediate objectives iii. Based on that the injections should be provided, for which as an AI practitioner you ensure that relevant/corresponding AI agents or any AI solutions are defined/formed Conclusion: As we see here, there are several ways/approaches to ensure business priorities are addressed properly with the help of AI, IMHO. There is no one defined approach or any right or wrong approach. An Approach like Hoshin Kanri (as strategic planning method) can also be leveraged for this kind of challenge. The most important thing is that a robust system or thought process that can help us to address this challenge. In my purview, the secret sauce lies in understanding the following things: Clearly defining what is that we want to do with AI What existing applications/systems should be converted into AI based ones Within a system/application what features/actions are to be done using AI (whether the system has to be partial/fully AI based) Clarity on Roles & Responsibilities of AI vs Human beings on the system which is going to be AI-based (partial or fully) How Data Governance would look like Who is accountable for what Having clear-cut response to all of these aforementioned points, can help us as an organization to navigate this challenge of AI projects properly aligning with the right business priorities.

First of all, let us understand what this concept is all about. Swiss Chess Model Wikipedia definition says “The Swiss cheese model of accident causation illustrates that, although many layers of defence lie between hazards and accidents, there are flaws in each layer that, if aligned, can allow the accident to occur “ Wikipedia example: In this below diagram, three hazard vectors are stopped by the defences, but one passes through where the "holes" are lined up.” A Wikipedia diagram How can the Swiss Cheese Model help you identify risks and strengthen the reliability of that process? The model portrays the fact that cause of a failure may not be necessarily attributed to a single factor but it could be due to multiple factors. This model essentially helps in identifying probable risks at every layer and gives an opportunity for us to improve/strengthen the defence of each layer and thereby improving the overall reliability of the process. As you can see in the above diagram, you can see the 2nd, 3rd, and 4th arrows (see the arrows from the top of the screen to the bottom for the order to be correct) getting blocked in their same/subsequent layer or at the final layer. But 1st arrow alone passes through all the defence layers and then becomes a failure!! Here the holes (we are passing through) are the weaknesses and they provide the opportunity for us to identify them as risks The cumulative effect of passing through all the holes in all of the layers successfully result in a failure. This model helps in identifying the risks at the holistic process as well. What would represent the “slices of cheese” (defence layers) and the “holes” (potential weaknesses) in your process? Slices of Cheese (Defence Layers): These are the protecting walls for the process without which we will not be able to achieve our objectives Holes (Potential Weaknesses): These are the loopholes through which costly mistakes/errors can happen because of which negative impacts occur -such as bad quality, reputation hit, revenue loss, business loss, material &/or personnel safety and hazard issues, market competitive edge loss… How can this understanding guide improvement efforts using Business Excellence principles ? As this model is in constant look out for risks, at every layer, and tries to address them, it helps the system to be continuously evolving and improving itself. The model also focuses its defence layers based on the customer objectives and therefore is highly customer focussed. As a team wants to ensure that every defence layer in its process needs to be equipped properly, the process should be guided ably by strong, vibrant and proactive leaders.. Example: Now as we understand, as what this model is about, let us see with a practical example on this: Process: IT Product Development process – The IT team wanted to ensure good quality with on-time delivery. In this example, let us focus only on the Coding and Testing aspect Holes (Potential Weaknesses): Manual - IT Dev Process (Low Maturity) Manual + Automation - IT Dev Process (High Maturity) AI Based IT Process Poor Quality code that could resulting in memory leaks, SQL injections leading to hacking, erroneous data, Turning off automation for existing features (maintenance/support work) can result in code quality issues when being worked upon Longer Initial learning curve for AI or AI prompting can result in some mental hurdle and that may prevent us from depriving some quality code output response Poor test cases written resulting in allowing of erroneous data or not well-formed data Lack of adequate knowledge on Test automation tool while writing complex test case scenarios Poor AI prompt can lead to ambiguous AI response which can make to have an average code /test quality which can fall into the manual /manual+Automation category response Application not working properly as an integrated system resulting in isolated modules not working Lack of time in investing for automation tool learning, resulting in manual intervention and hence human error inducement, while dealing many test case scenarios AI outcome cannot be simply taken for granted. Human oversight may be needed. Potential chance of human oversight is possible Slices of Cheese (Defence Layers): Manual - IT Dev Process (Low Maturity) Manual + Automation - IT Dev Process (High Maturity) AI Based IT Process Code self-review Code review by a Static Code Analyzer tool AI Tool based review Code review by Peer Code review (Functional knowledge) by SME/Architect AI based Unit Test case generation Customer Architect doing code review Unit Test case automation AI based Functional Test case generation Unit Test case self-review by Developer Functional Test case automation AI based Regression Suite generation Functional Test case self-review by Tester Regression Test case automation AI based Integration Test suite generation Function Test case review by Test lead Integration Test case automation AI based seamless deployment In this example, have consciously put the holes first and the Slices of cheese as the next. The reason being, in my experience (& IMHO), have seen that these holes have been addressed properly typically by these layers. Conclusion: The example that is listed here calls out succinctly the defence layers and holes in the process. As this model supports, continuous exploration/analysis of risks, it gives an opportunity for the servicing providing organization to look for improvements in process optimization, customer focus, Value creation etc... Reference (for definition and diagram) : Wikipedia for Swiss Cheese Model

Let us see how Change management is important across the five phases in a DMAIC project with some hypothetical examples Define Phase: Example: In an Insurance organization, there was a web-based Policy and Claims management system, which had several issues that bothered the leadership team. The system was having multiple technologies (mainframe, legacy Database, advanced web technologies). The system was undergoing a modernization (both business and technology perspective) with multiple vendor organizations working on the system and there was a considerable focus on the response time of some of the key pages. The (Six Sigma) Project team gathered VOC from various key stakeholders and then when it was widely assumed that web page Response time could be arrived as the CTQ , there was a shock awaiting to the team as another key business stakeholder who happens to be a VP for a geographical region raised a concern. He wanted to have the response captured for mobile app version of the same system as many of his regional customers use personal hand-held devices. So there were lot of discussions and deliberations as which response time to be used – System enabled web-browser based or mobile-based response time. No decision could be arrived at The MBB decided to understand how the power structure is in the organization and came up with a Stakeholder matrix. He found that Stakeholder 5 is the key stakeholder and therefore the organization heeds to his thoughts predominantly. Now the CTQ has to be changed to accommodate the stakeholder ‘s (Stakeholder 5) ask. Since the response time for both mobile based and as well for the traditional system-based web browser had to rely on database query fetching time, it was decided to have that as CTQ, than the response time. The outcome of the database query fetching time resulted in improved response time, both for mobile and for traditional system-based web-based browser satisfying all the stakeholders. Measure Phase: Example: In one of the projects during the initial stages, the customer wanted to have the categorization of Pass vs Failure and hence the measuring system was different. The approach was useful for reporting purpose. But later the customers wanted to see how many defects are there and they wanted to analyze as why defects are happening and where it is happening and what is causing them. So the MBB helped them to go for continuous data and decided to change the MSA and used Gage R&R.. This helped them to see how the defects are occurring and if there are any process gaps. This helped them to fix the process issues and also address the quality issues as well. The change brought was on the mindset of people to have ‘First Time Right’ approach and also to consciously understand any patterns when there are defects coming out. Analyze Phase: Example: The IT organization had a problem of not delivering on time for several months and has a reputation hit. The organization has decided the CTQ as on-time delivery, and they found one of the key factors - lack of domain/functional, technical knowledge. So, they decided to improve the team on these… With the guidance of the MBB, the team did - one hypothesis testing of mentored training vs self-learning Nano-video based learning. While the result was not statistically significant, the business significance was worth the effort, which was well articulated by the MBB (as what it means to them). So, the team decided to move with Nano video approach. The team changed itself to be self-reliant and more accountability creeped into the team’s mindset Improve Phase: Example: In the Policy and Claims management systems that had mainframe, legacy database and advanced web technologies, the response time for database query fetching had to be improved. As this was a modernization program, the existing policies were to be running in old systems and new policies created were to fall in newer DBs. As soon as the changes were being made to address the CTQ (DB query fetching time), lot of hassles happened in terms of policy creation and claims management. The MBB sensed this and guided the project team to let out the communication on what is being changed and what will be remaining as such and how changes being done, will impact the services rendered in a positive manner. Control Phase: Example: For monitoring the Policy and Claims management system, there were lot of metrics.. which was more focused on the business metrics such as type of policies created in specific regions, no.of policies created per hour and so on. But as the crux of the issues were on the IT side, the MBB also suggested to track the IT metrics that involved about the web page response time, mobile page response time, the DB query fetching time etc… This change of thought/approach resulted in more stable application and ensured happy stakeholders and customers. Conclusion: Change Management is critical to the success of any transformation or initiative in an organization and more so definitely for the success of a DMAIC project. The change accelerator process (CAP) formula is E= Q * A where E is the effectiveness of the solution, Q is the quality of the solution and A is the acceptance of the solution. It is the acceptance part, that is more often than not a challenging one. As we deal with human emotions, its imperative that every phase/facet of DMAIC project (for that matter any initiative that has human element) has to have the buy-in of the participants (in this case all stakeholders involved and whoever wields the most influence, usually wins). Thats why we saw how stakeholders identification sets the tone for a project. John Kotter's change management clearly outlines how change management is essential in doing any transformation or initiative

Let us see the reasons as why those wins (as stated in the question) sometimes slip away in the Control phase Generic Reasons (this answers why any process can loose its sheen after an improvement is done): 1. We need to understand the fact that every process that has got an improvement will have two aspects – short term sigma (Zst) and long term sigma (Zlt). Often, we tend to miss this reality that there would be a process variation in the longer run and that, this is inevitable unless we consciously make an effort to adjust/correct the process to align with our expectation/goal. 2. For every process, if there is no monitoring process in place or if the monitoring process is not suffice or inefficient, then you will not be able to retain the (improvement) gains, that you have achieved. I should have a clear-cut view of my monitoring process. For instance, having some info as below can help me to arrive at a good monitoring process What I want to measure? (Eg: Delivery time – minimum time to deliver, maximum time to deliver) How I want to measure it? – Service Level Agreement (SLA) How do I benchmark it ? – Comparison of my SLA with my competitors/industry leaders 3. When there is no visual flow of your process as how it progresses from time to time, then monitoring of your process is difficult as you may miss the trend/pattern as how it is evolving over time, post the improvement. Context-Specific Reasons: In the case of the logistics firm which had new routing system 4. There could have been some unknown issue(s) that would have propped (emerged) up which might not have been anticipated as part of the monitoring and controlling process and suddenly those issue(s) getting frequently or permanently surfaced, in the new route (eg.. road narrowed down due to say – making that road as a one-way traffic and 2. laying out of pavement-platform extensions) Tools and Techniques that can be used for keeping our improvement gains intact (to this context): 1. Use a control chart for monitoring and controlling the process first for understanding the problem deeper/where the problem is. For instance Checking for 5+ continuous points on the same side (LCL/UCL) can throw hint about the process having a problem somewhere. [For brevity sake, we can put this though there are plenty of things that can be explored in control charts] 2. For addressing #1 a, Using techniques like Brainstorm, Liberating Structure (to arrive at a wider, engaging consensus amongst the employees of the firm) we can come up with some outcomes. The solutions could be like Include a live map APP, that can help in deciphering the current updated status in the new route system (improvement solution) Agreeing/Adherence to defined SLAs (more sensitization to employees, due to the newer challenges) Also, we can leverage, a FMEA/PFMEA tool, and with that, we can put necessary action plans and control this process Conclusion: Every process should have a monitor and control mechanism properly defined. If a process have a good monitoring capability, the process variation could be very high and the effort that a team might have put in to improve its process, might become a waste. Therefore, it is imperative that every team has a solid monitoring capability in particular. Monitoring and Controlling go hand in hand in Six Sigma projects and are inseparable. Its important that therefore your tracking mechanism is good and your control capability should be able to support/complement that.

Let us answer this, with the help of an example. Cricket Ball Manufacturing process We will consider a Cricket Ball manufacturing process as a hypothetical example Background: Now, let us say we have 2 types of Cricket Ball manufacturers XYou Sports Inc and YMe Sports Inc. XYou Sports Inc produces ball in Country 1 where the ball will turn (Spin) more a YMe Sports Inc produces ball in Country 2 where there is more swing. Now the national team of Country 1 plays with the national team of Country 2 in one of its Cities… Therefore Country 2 feels uncomfortable playing to a different brand of Cricket ball (made by X) as it has got more spin. So, to counter that, Country 2’s Cricket board looks for XYou Sports Inc manufacturer to supply that brand to its national team. The steps mentioned above, depict the AS-IS process view AI-Enabled Process where human improvements were made As XYou Sports Inc manufacturer found out that, multiple countries may need multiple type of Cricket Balls, it decided to leverage AI in getting useful insights and ultimately getting things done quickly. As a first step, it ensured that AI process (and hence solution) was setup that addressed that the ball will be more conducive to Spin (turn) when implemented in Country 1. The AI was fed with data, and it was more like a supervised learning for the AI. The humans in the loop, were doing manual verification of key differentiating parameters/factors such as weight of the ball (in Ounces), size of the ball, bounce, seam, stitching, materials used … AI solution evolves with the Process Once XYou Sports Inc received the request from Country 2 as well, the team realized that they can still explore on AI technology and leverage it for bettering this process. It started to identify what kind of key differentiating factors can be included as part of the AI. The AI solution agent now has to look for an additional information(parameters) – how the prevailing weather in Country 2 impacts the cricket ball, how does the pitch/soil (in Country 2) supports this type of Cricket Ball (manufactured by XYou Sports Inc). How did the MBB help here for XYou Sports Inc? The MBB envisaged a plan. As this process is an ongoing journey and may have uncertainties and require constant feedback from the stakeholders (eg, National teams, Cricket Boards of respective countries..), he felt using Scrum as an agile framework might help the team to navigate through the uncertainties that might prop up.. He suggested the team to use this and also requested them to put a Kanban board for radiating information on a routine basis to all stakeholders He had put a high-level plan that stated as Planning Type Objective Remarks Vision Planning Developing a scalable tech excellence support Agent that supports the Cricket ball manufacturing process of XYou Sports Inc Release Planning Release Phase 1: Defining the AS-IS process to AI (Basic Knowledge Integration of the Cricket Ball manufacturing process) Release Phase 2: Re-imagining the defined process in phase 1 by considering all key parameters that is required to make the ball suitable in multiple countries (Country1, Country 2) Sprint Planning Release 1 Sprint 1 – Creating the KB agent and AI agent for defining few basic parameters (such as weight and shape) Sprint 2 - Defining the KB agent and AI agent for remaining parameters such as materials, bounce, seam, stitching Release 2 Sprint 3 – Defining the KB and AI agent for additional parameters such as pitch soil, weather conditions of a country (which can influence the ball behaviour) Duration: 2 weeks Note: Sprint 1 will have a minimum viable product (setting up the AI process and adding very limited functionality) Release 1 had 2 Sprints and Release 2 had 2 Sprints Sprint 2 had the feedback incorporated from the stakeholders that came from Sprint 1. Similarly for Sprint 3, 4 the team got feedback from the previous Sprints and incorporated the feedbacks which were relevant to them Subsequent releases had subsequent Sprints based on the emerging needs for the manufacturer. Integrating AI into improvement Cycles and AI process got adapted with proper feedback As we see from the above table, the team leveraged Scrum as a framework to build an iterative and incremental development of their AI based Cricket ball manufacturing process. What was a cumbersome exercise in getting huge amount of data across multiple parameters and few parameters which were changing based on the Country and its weather conditions (worst if there are multiple weather phases – summer, winter, autumn..in a country) , it became much more simpler when done with AI. Every Sprint produced some incremental values keeping the stakeholders happy. The AI system improved itself over a time period as it gathered more data (in the usage of how the cricket balls behaved in those countries across weather seasons) and had reinforced learning to improve itself With every Sprint, there was a Sprint Review that happened where the stakeholders were presented with the finished work (in the Sprint). Whatever feedback was given was taken into consideration and those were implemented. Strategic Role of MBBs in maintaining alignment The MBB was able to devise a strategy for AI solutioning of this Cricket Ball manufacturing process. He was able to setup a vision, release plan and then help the team to come up with Sprint goals for each of the Sprint making the team adjust to the uncertainties Conclusion: We saw here how AI enabled process with human efforts can navigate through complex scenarios/situations in an incremental manner addressing emerging needs with quick feedback cycles. The most important thing is quick release(deployment) of the value that you want your stakeholders to get and have continuous exploration of the market needs and adapt your system accordingly.

Let us explain this question with an example. Example: In an IT environment, there were multiple teams situated across different locations. Most of the teams were struggling to deliver the goods (requirements) on time.. The development effort, were more due to several factors such as complexity involved, lack of coordination/alignment amongst the team members who are from different vendors. This means that every team had team members with different vendors. The Problem statement framed was to improve the development cycle time of a requirement, for these teams. Based on the problem statement, one team was piloted for understanding, the current ecosystem and was taken, for implementing the changes. But the solution provided by AI, did not provide the expectation that the business owner wanted. There were multiple teams, each team was unique – One was a component based team, another a cross-functional agile team, another distributed agile team (members from different places), another team was collocated… So with such diverse teams, the result was not having any improvement on the development cycle time for all the teams. The piloted team was a collocated team and the improvement shown was virtually nothing, as this was a well-knit team and the team operated at a better cycle time. This is where a MBB helped in rebranding the problem statement. With the help of a Project Charter, the MBB helped to write a proper business case and Problem Statement. The business case stated the impact of the cycle time taking long reasoning out the why part (as mentioned above) and which types of teams (distributed - cross-functional teams, component teams) are contributing (where it is happening) to this problem and how long it has been there. Then the Problem statement was defined as “Lot of Development effort goes on due to the complexity involved and lack of coordination amongst team members, in distributed component-based and cross-functional teams”. Then SMART Goal was developed stating 2 pilots would be done – one on Distributed Cross-functional team and one on Distributed Component-based team – within a month’s timeline . Out of Scope will be Collocated teams Once this clear-cut strategy was established, then it was clear to all the stakeholders as what to do and then the execution became laser-focused and the teams were able to improve (Reduce) their cycle teams Conclusion: It is essential to frame the problem statement right, irrespective of whether AI is used or not. AS an AI Solution Architect, we can encourage the person who provides the problem statement to use prompt engineering/fine tuning (depending upon how depth you want to explore something). We can also help them in using Chain of Thoughts, if they don’t know (assuming we also don’t know), how to structure our thoughts and leverage the problem statement further As a MBB, its important to ask insightful queries while going through a problem statement. The MBB has to know from the Business Owner/Problem Statement provider - Who are the impacted stakeholders - The impact/implications of the problem need to be understood - How long the problem exists - In-Scope/Out-of-scope - Tangible/in-tangible benefits need to be understood. Apart from this, the MBB need to know with the AI Solution Architect/AI teams - What is the AI solution trying to do - Will the AI solution be short term/long term Based on this response, the MBB will be able to make the AI Solution Architect design the solution catering to these needs. Thus you can see how with proper framing of the problem can yield the right results and how not doing the right framing of the problem, resulted in no improvement (in this case). But in general it can be like you may loose customer confidence, stakeholder dissatisfaction etc.. when you get a solution which does not provide value.. An analogy could be - while ordering food through online, it is like you get an eatery which you have not ordered, when you are hungry but looking for your ordered item!!

In an AI based ecosystem, following are key elements in the governance framework that I would be interested in - Laying out Clear Governance and proper accountability structures - Defining adequate policies and procedures for data governance and security - Effective oversight mechanisms to ensure proper safety, and also, legal compliance - Adherence to security standards ensuring data protection and trust maintenance I feel that the stakeholders who should be involved in this, should be Business Owner, AI Solution Architect, Legal Team, Governance team/leads Mechanism/Approach for maintaining agility and control - Establish the objectives as what you want to do, by setting up a SMART goal - Define the KPIs/metrics - Data Availability and Privacy - Ensure right technology infrastructure is available - Ensure right skilled people are available - Ensure stakeholder management is properly done - Ensure Continuous Security Testing is done which can help in identifying and fixing vulnerabilities - Ensure right data strategy is available Example: In an IT project for an Insurance customer, creating and managing Property insurance policies were a challenge. The Project team wanted to re-write from a legacy application to a modern rich and niche-skilled application. As the team started its journey, it found out many bottlenecks, such as the non-availability of few experienced underwriters (who moved to different teams), frequent change in regulatory laws and compliance [in some of the countries in which the customer (insurance organization) is placed at] delaying the policy creation/policy management processes. These things resulted in delay in Policy management, especially delay in creation of policy. From few hours (existing), it took a day to complete a policy creation, on an average There was a discussion that happened between the Product Manager (who takes care of the Property Insurance product suite – that contains - Policy Management, Claims Management, Administration…), the Product Owner (who takes care of the Policy Management) and Business stakeholders. The discussion centred around as how to improve the overall cycle time of getting a policy created and how to provide a better experience for the end user. For them, the purpose of re-writing an application rather than migrating from a legacy to a modern application was supposed to be superior. But the results were not showing as expected. One of the stakeholders suggested about the usage of AI and proposed if that can be leveraged. Then the Product Owner suggested to include an AI Solution Architect to get his opinion. The AI solutions Architect was called upon and was briefed on the current situation. He suggested that with the help of AI, those challenges can be addressed. How were the challenges Addressed: With the stakeholders' consent, the AI Solution Architect (along with a few AI minded volunteers), arrived at the following things 1. Defined clear-cut goal for reducing cycle time – from a day to a range of 10- 15 minutes 2. Defined KPIs/metrics · >= 98% Accuracy Risk Profiling of Policyholder data · 100% documentation/repository of updated/compliant regulatory laws/rules for various states/provinces in different countries (where the insurer/customer organization has a presence) 3. Established the AI specific roles and responsibilities · ML Engineer who was responsible for guiding/helping the team in its this AI journey and acted as a technical SME for the team · Domain Expert with minimal AI knowledge, to offset the lack of enough underwriters · Data Scientist/Engineer (who was used across teams) to ensure the data governance was smooth · Prompt Engineer was responsible for helping the team to rephrase or refine their queries/ideas in a clear and focussed manner. [She was later leveraged for multiple teams as the team got matured in prompting] · AI Quality Engineers for testing the AI system · Provided extensive training to the people as per the AI roles that they played · AI Facilitator helped the team to collaborate with all the stakeholders (such as Business stakeholders, AI Solution architect, key end-users..) 4. Established proper data governance and accountability structure · Product Owner in conjunction with the AI Solution Architect had put the backlog items for consumption · The Order of escalation was : the first point of escalation was the Product Owner, followed by Product Manager 5. Established Safety and compliance mechanisms · Safety Procedures and Policies were fed into the AI KB · All Safety compliance things were well- documented 6. Right technology infrastructure was established · Microservices based architecture was created – so that loosely coupled systems can work easily – for instance Policy Issues not impacting Claims Mgmt · Niche Front end technology skills such as React.js, Android were being used to make the system highly interactive 7. Established a data protection and privacy policy With all those necessary changes, the existing challenges faced by the team was addressed. The Risk Profiling profiling was predominantly automated by an AI agent, with a minimal oversight by an underwriter (This drastically reduced the need for an underwriter and addressed #1 challenge). With respect to the regulatory rules and compliance, the team leveraged an AI agent which constant polled (pulling info from a server) on a centralized repository (for every country in which the customer organisation was present) that had the latest info on the regulatory laws and ensured that the latest update was available. This made it a 100% POKA YOKE system and resolved #2 challenge. Thus, the team was able to achieve its goal of reducing the cycle time and in the process made the stakeholders and end-users delighted. The team also started to make everything through a Kanban board (as a Visual radiator of information) of its progress, providing dashboards on how many policies were created in a month and what type of policy coverages are getting generated more etc.. It also started highlighting any outstanding issues/blockers and leveraged AI KB agents to provide timely resolution. Conclusion: AI has reshaped the way how the world is responding to challenges, ideas. It is beyond imagination to see how AI can influence any industry. The more we embrace AI, the better it could be for our business. For that to happen, our understanding of that powerful technology has to be in-depth. As we keep exploring on that, we may tap its potential to the fullest. As we try to co-exist with it, we need to understand as a framework, how to govern it. What are the elements that are needed to govern the AI framework, therefore becomes critical. IMHO, I find the aforementioned ones as some of the key elements that are required. Source Reference: Benchmark Six sigma academy CAISA program material and based on personal learning

Let us consider a scenario to describe the effect of capturing metrics in traditional Business Excellence way versus capturing the metrics in an AI based ecosystem Scenario 1: Consider an IT Development Project that uses niche skills (emerging technologies like React.js, Node.js, Mongo DB…). Let us try to put our metrics focus on, say, the following parameters - Cost, Quality, delivery, efficiency and customer satisfaction. Let us deep dive a bit into each of these metrics (with a sample, expected SLAs) Note: There are so many aspects to cost.. For simplicity sake, have put special labour cost that talks about niche skills (and therefore it does not consider the normal costs associated with the rest of the skilled workers). Now, let us reimagine this scenario with AI. So, what could be the new metrics, if any. Will there be any modification/deletion of any existing metrics? Lets see that now The Status column consists of a). ‘Removed’/’Not Applicable’ – which means the metric is not relevant for the AI based ecosystem b). ‘Retain’ – it means that the metric is retained from the traditional ecosystem (which means this can be used in AI system as well) c). ‘Improve’ – It means the metric has got more stringent SLA (as expected) d). ‘New’ – It means the metric is specific to the AI based ecosystem In the AI ecosystem (pls refer to the above table – table 2), let us ponder on few things: 1. The AI model can provide niche-skills specialization thereby eliminating the need for Special Labour Cost (it will loose its relevance, therefore). Note the fact that there could be initial setup cost for building AI infrastructure into the organization but that will be of an investment and may not be specific to any project. So, the Special Labour cost can go away. 2. Usually when it comes to traditional efficiency calculation, we will think of automation of testing tools such as Xunit (Developers’ testing tools) , Selenium(QA testing tools), Postman (API testing tool)…So in a way, the focus of automation was targeting towards the test cases, test scripts and stuffs. So what about the development life cycle where the developer is able to leverage AI based coding, reviewing, unit testing, building it and deploying in some staging environment for (functional/System) testing. This is where ‘AI development cycle time’ can be captured. One of the benefits of having an AI based system is, it increases the productivity of the developers and hence this metric is a key metric. We can also add metrics - say, “Ease of use” that should always be >= 7 (between range of 1 – 10), AI Ethical Concern Alert - ‘0’ (Zero) / release , just to name a few.. The metrics are always contextual and can be decided by the Organization/Project teams and the AI solution architect/expert (to ensure there is a feasibility of implementing the metrics) Conclusion: AI is a powerful technology that if leveraged properly can help us to reimagine our business excellence. AI can give an organisation a competitive edge and with the right AI model and KB powered Agents, we can focus on improving traditional metrics as stated over here and also to monitor how AI is improving the business excellence capability, we can also define our own metrics (relevant to what we are doing) and measure the outcome.. We can then use those outcome from the defined metrics and improve our AI system further.

In this AI world, the role of a MBB should be like a coach guiding the team that builds the AI-powered solution for a critical business process Imagine you want to go from city A to city B which is a considerable distance and now you are go in this combination - an Express Highway and a F1 race car. So how quick that would be. The combination of MBB and AI Solution Architect is akin to this!! The MBB letting know what her thought process/ideas on doing a transformation and the AI Solution Architect complementing that thought process/ideas with concrete implementations I personally saw the power of this in my AI enabled Business Excellence MBB program organised by BenchmarkSixSigma.com. There were many modules in that program. When there was a discussion on a Monte-Carlo Simulation problem, while doing in a conventional manner, the outcome took some time to arrive at for all of our batch mates in the program. With the help of AI prompts (as part of the program), when the same problem was fed to an AI model (say ChatGPT), it threw good suggestive approaches which expedited us to get the right set of parameters (necessary for Monte-Carlo simulation) which can result in the right solution. This was a classic case of a MBB and an AI system working together. Imagine that AI system being engineered by an AI Solution Architect!! This is just a proof of how a MBB and an AI Solutions Architect can work together and achieve great results Imagine the MBB picks a transformation project that talks about cost reduction for the customer in one of its critical process. The work demands a typical Black belt project. By conventional means, the Six Sigma Black Belt project would take quite some time. Shrewdly the MBB decides to leverage her colleague an AI Solution Architect. She tells him about the project needs and customer expectation. He hears out the problem and comes up with a solution which is relevant to the ask. How he does that solutioning? By providing an AI solution that focuses on - Data driven insights - Automation of process With the above focus, he (AI Solution Architect) is able to - innovate the organization, - making the leaders/MBB (in this context) arrive at informed strategic decisions that can impact business outcome, - reduce the operational costs involved - Also, in general, the costs, as we improve the overall efficiency & productivity of the system - help the customer organisation to outperform its competitors through quick adaptation to changing market needs - extracting valuable insights from data turning into actionable strategies which drives business success This really helps her (MBB). During this transformation journey, there may be several touchpoints for both of them. For instance, if there is an insightful data (Coming out from the AI solution) that can bring a new perspective to the MBB. Then she may have a discussion with the AI Solution Architect. To have some clear-cut strategy for a good discussion with an AI Solution Architect or to an AI based team would be - It would be always good to have a cadence setup between the MBB and the AI Solution Architect. - Have good discussions with the AI team which can help the team to write better prompts for a better solution By reducing the costs associated with the project, we can showcase the value that can be provided to the customer and also focus on satisfying customer needs and expectations, as part of our organisational priorities There are few things as a MBB should do, to improve upon his/her AI knowledge. 1. Learn basics of AI and also Gen AI which is good enough to explain your problem statement that you want to convert into an AI based system 2. Learn basics of Prompt Engineering and 3. Understand fundamentals of ethical AI Governance and understand how it impacts organisational standards and Data Privacy compliance As an AI Solution Architect (other than AI specific skills), you need to know 1. The vision/idea (intended purpose) of the problem statement and what is the expected outcome so that the solution can be more contextual and precise 2. Development of skills in preparing comprehensive System Requirements or Business Requirements document that will map the objectives of the AI based project with the business needs Thus, you can see how a MBB and AI Solution Architect can get in sync with a transformation and can really speeden up the transformation and bring benefits to the customer. So does this mean that you need a MBB and an AI Solution Architect together. Is it possible that a MBB also becomes an AI Solution Architect? Well, you can be a MBB and also be skilled with AI Solution Architect just like how I plan to be now (thanks to the CAISA program). This is similar to a Tennis player being the captain (of the squad) and also being a player while playing Davis/Fed cup. He/she will be knowing whom to select as player and also understand the strength and weakness of each player and also the playing conditions. Same way, the MBB with AI skilled would be able to understand which transformation to do and what to do and how to do it through AI. This is where these sort of programs – AI Enabled Business Excellence MBB and CAISA programs when leveraged effectively can be game changers. Reference Material Source for AI: Benchmark Six Sigma CAISA Course program

Context: There was a Software development product development, that I was aware of. The IT project(product development) had multiple technologies with multiple vendors. The Sponsor of the project (product development) was very much concerned about the delay in delivering the requirements/deliverables (functionalities) to his customers. This issue was there for almost a year. The development team had always stretched itself to complete the deliverables on time, more often than not comprising on quality. On an average it took 18 days(Cycle time) for a single requirement to be completed end-end (time taken to deliver a requirement to production). That was the time, when a Six Sigma Black Belt (SSBB) Process consultant was roped in. She was requested to focus on the delayed delivery/release of requirements to Production environment Process: Cycle Time Reduction 1. The cycle time for each of the requirements going to production (release) was taking time. The Process consultant did a value stream mapping of the AS-IS process. She understood what are all the steps involved in from the Requirements stage to the Production stage and also which stage is owned by which vendor (as this is a multi-vendor environment). 2. The lead and wait time in each step was noted 3. The SSBB consultant found out few couple of steps (Development and Testing) where the wait time was more a. Code Review (6 days) b. Testing in staging (which mimics production environment) environment (4 days) c. Technology version Upgradation (3 days) (Note: this was a challenge as multiple technologies were used in the project, and to provide rich features to the system (product), the latest versions of technologies were needed.. so there was a constant need for technology upgradation in some technologies) 4. After finding these key steps (#3) that had more wait time. Several root causes (as Vital Xs) came out such as a. Root causes for Code Review i. Lack of knowledge in Technology ii. Lack of awareness in Coding Standards and Best Practices iii. Delay in identifying the reviewer iv. Dependency on the availability of the identified reviewer b. Testing in Staging i. No coordination/cooperation between Vendor who does the development work and the Vendor who does the testing work ii. Vendor doing development work and Vendor doing testing do not adhere to a common product goal, resulting in siloed way of working c. Technology Upgradation i. Lack of awareness in latest version of technology ii. Lack of backward compatibility awareness on different versions of technology (For eg., how latest is compatible with the existing or current version used) With the help of Fishbone diagram and Pareto chart, the above Vital Xs were found out How was this addressed/improved? 1. Code Review: The SSBB consultant facilitated a brainstorm session. The team used that session to understand how the root causes for code review can be addressed. It came with Pugh Matrix approach for arriving at a best solution for couple of problems related to technology learning by the team members (whether self-study, video learning, in-person training etc) and also did some Force field analysis for code reviewing for both Peer-Peer vs SME reviewing to address identifying reviewers and dependency on identified reviewers and accordingly arrived at a conclusion. There was some initial investment (of days) especially when learning came into picture but over time, the overall wait time saved was 4 days (so job completed in 2 days!!) 2. Testing in Staging: Up next, the SSBB consultant facilitated her next brainstorming session so that the team can address the issue of Testing in ‘staging’ environment (an environment which mimics the production environment). The team ensured that there was a common product goal (based on SMART) and that all members of the team were aligned, irrespective of which vendor they belonged to. This ensured that there was collaborative effort and more focus. This resulted in 2 days saved. 3. Technology Upgradation: Finally the SSBB consultant facilitated a brainstorming session for the team to address “Technology upgradation” issue. The team had prepared a list of all technologies used in the project with the current version and the latest version.. It did a regression analysis which technology has a correlation with which other technology and what kind of impact it has when there is a technology upgradation and accordingly updated the corresponding technology. This resulted again in 1 day saved [Note: This happens when there are some libraries (collection of files/functions that are meant for addressing some purposes) that is called from one technology to another and then compatibility issues happen at times] To see how the improvement was effective, lets compare the measurement of the process time+wait time for these steps in the overall scheme of things Cycle Time Reduction “ Process Steps in Product Delivery for a Single Requirement: Steps Before the Process Implementation change (AS-IS) [ Process Time + wait Time ] After the Process Implementation Change [ Process Time + wait Time ] Remarks Requirements Analysis .5 day .5 day High Level Design .5 day .5 day Low Level Design 1 day 1 day Development (includes Code development, Technology upgradation, Unit Test, Code Review) Code Development (1.5 days) Unit Test (.5 day) Technical upgradation (3 days) Code Review (6 days) Code Development (1.5 days) Unit Test (.5 day) Technology upgradation (1 days) Code Review (2 days) Code Review, and Technology Upgradation part of the ‘Development’ process step was worked upon resulting in 6 days of overall saving Functional Testing (System testing) .5 day .5 day This was treated a separate process by the customer organization, as it was done by the team UAT Testing .5 .5 This was treated a separate process by the customer organization as this was done by specific end users/few critical customer stakeholders Staging 3 days 1 day This was treated a separate process by the customer organization as it was done by people with special access to the environment that included senior management and few Enterprise and solution architects Production (Deployment) 1 day 1 day Total Cycle Time 18 days 10 days Thus, you saw the difference in cycle time getting reduced. The SSBB consultant did a commendable job in bringing the cycle time from a 3.5 business weeks to 2 weeks, which was a great achievement Reimagining how this process can be done using AI Now in the current technological ecosystem, if we were to use AI to solve this problem, how can we do this.. There are multiple ways to approach this IMHO. There is no right or wrong approach AI based Solution: As an AI enthusiast,. Few things that I will do are 1. I will look at the problem statement first - a. Delay in deliverables (addressing Cycle time) 2. Then capture the following details. a. Understand whether it is single vendor or multi-vendor project b. If multi-vendor, then who is owning which stage of Software Development Life Cycle (SDLC) c. Understand how workflow is happening as of now (AS-IS) based on the response provided by the user (some way of understanding the ecosystem is needed either observation or information feeding) 3. Based on that will create an AI solution that will throw a Value Stream mapping model which will show what are the steps thats producing waste and what could be potential root causes and how to address them. These are examples for more of a Chatbot/conversational ways of supporting the humans when AI agents or AI systems do not know your challenges AI based re-imagination of the problem/challenges Now imagine that you know the problem statement and you also know the root causes (lets say you are in ‘analyze’ phase). At this point, when you want to use AI to address your challenges, then AI becomes a real game changer. Lets us see how those 3 key challenges are getting addressed with AI’s help 1. Code Review – Using an AI tool like Codeium or any AI tool used for development, you may seamlessly more or less eliminate the need for a reviewer as it helps you in refining your code to the maximum hilt, though you may still need a reviewer (but the dependency is limited and time saved overall is much higher). This can happen from few days in the past, to few hours/minutes 2. Testing in Staging – Based on the context and the product vision and roadmap, AI tools can provide SMART suggestions, saving in collaboration time amongst members from different vendors 3. Technology Upgradation – An AI tool like GitHub CoPilot or any AI tool, may have the capability to identify or help developers in version compatibility issues and this can result in tremendous amount of time saving (from days to hours/minutes). This clearly shows how AI can help us to resolve our challenges which we are dealing on days to perhaps, in hours/minutes. Few things that we can learn from this whole discussion: 1. Traditional way of working involves lot of processing time and waiting time (often in days) while doing the work, whereas AI processing time and wait time (between the steps) either do not happen or reduced to hours/minutes (in some cases) 2. Standardization of Conclusion: In this context, I find that reimagining the process with AI can be beneficial as we would be dealing the aforementioned challenges in hours/minutes and not on days. Therefore, I would recommend to the SSBB consultant in trying out this approach. I have personally heard and seen, from many of the projects that Code Development (as an example) is rapid and it takes very few hours(even minutes in some projects) to complete the code quality, code refactoring, unit testing, review etcs.. for all requirements that are available, say in a code branch. Having said few cautions to be made, 1. AI Usage should have a proper governance 2. Ensure mandatory regulatory compliance is met 3. Ethical AI usage has to be followed 4. intent of AI usage should not be focused on workforce reduction rather improving the processes 5. Psychological safety of the employees is important for AI tool usage to be effective. Else Employee emotions/sentiments may run high 6. AI Upskilling required for AI tools to be effectively used -

The one thing i would like to focus upon is "Tacit knowledge". Currently, IMHO, feel that AI lacks that ability to possess that "Tacit knowledge", in several areas (in specific situations or in several industries). It is too human to hand over to AI Example: Lets take an example in substantiating the claim that i made above. As a workplace foundation coach and also an enterprise agile coach, i deal with many individuals and teams. The knowledge and experience that a coach have accrued over a period of time is difficult to be conveyed and replicated in AI in my purview. Especially when dealing with people on coaching, the emotional intelligence is a key aspect. IMHO, therefore it is not easy to train AI models on these aspects however sophisticated they be. How you might reimagine it to make AI a valuable contributor? W.r.t examples related to the activities of say coaching/consulting (say Psychologist)/healing following can be useful steps 1. Build Capability/Train on emotional intelligence for the AI systems 2. After capability is built, feed dummy problem statement (similar to the original problem where human beings were used for the activities) for coaching/consulting and check how results are coming out. 3. Compare the human based outcome vs AI generated results/outcome 4. If not satisfactory, then inspect where the gap is and adapt accordingly In General, wherever 'tacit knowledge' is needed, you may need all these 4 steps. There are many areas in which AI is difficult to be leveraged. But nevertheless, i feel these steps could be by and large common - Build the corresponding capability, test the capability built with a sample data, compare that with existing ecosystem (human driven) and if satisfactory you move to AI based; else then inspect where the gap is and adapt accordingly. Also please do take a look at Polanyi paradox that gives some additional info on 'tacit knowledge' and 'emotional intelligence' aspect "https://www.benchmarksixsigma.com/forum/topic/39795-polanyi%E2%80%99s-paradox/" Conclusion: IMHO, there are quite a few areas like 'Tacit knowledge' which are difficult to be achieved through AI. In general, any task or decision for which you are (made) accountable, you would want to manually do it and would not rely on AI. This may be due to a psychology fear (That there could be a backlash if things go awry and it stems from the fact that most of the people, do not trust technology especially when they do not have too much grip or understanding on that). Therefore, IMHO, such tasks or decisions belong to this category of too human to handover to AI. So that kind of tasks/decisions are difficult to be reimagined in AI way. Better understanding of AI can increase people's confidence (for instance, where its power lies and where can be pitfalls in its usage - if that can be understand by people). This can help in transforming such manual works to AI based

Before we deep dive into the problem statement, let us understand what PoC is and know about its benefits Proof of Concept (PoC): A PoC is a small experiment to determine whether an idea(or concept)/principle/proposed solution can be realized(made feasible). A PoC can be anything like a). how to use a newer IT technology to see if that works (as a replacement for the current IT technology in use), to achieve some defined objective(s) b). showcasing a newer mode of tracking shipment of goods in a supply chain (let us say BlockChain) instead of traditional tracking of shipment of goods The experiments are small, and you can see prototypes playing a key role here. The objective is that you are able to decide upon whether you want to pursue or not about the idea/principle/proposed solution that you suggested/envisaged, at a short span of time. Some of the most important benefits of having PoC: 1.It helps to either continue with or dispense your ideas/principles/proposed solutions considering various aspects such as feasibility (practically can be implemented), viability (cost-wise) 2.It helps you in quick decision-making whether to go-ahead with the idea/principle/proposed solution. 3.Cost saving is likely to happen as you do not have a full-blown deployment of your actual approach 4.Can highlight potential bottlenecks/traps, technical challenges before a full-time deployment happens 5.It can help in minimizing Financial, operational – risks 6.It can increase stakeholders’ confidence as stakeholders see a small working version which can help in gathering fund for the full-scale deployment Now let us come to the context Designing a Proof of Concept (PoC) to test its feasibility and alignment with business excellence goals Let us see what aspects the POC (AI driven chat-bot) can have to test its feasibility and alignment with the business excellence goals for improving the customer service. IMHO, the following are some generic but key features/aspects that one may expect to have: 1.will it provide a seamless facility to capture customer challenges 2.will it help in improving the response time to customer enquiries/queries 3.Can it help in minimizing the waiting time for customers to get some help/assistance (to start with) 4.will it be better trained to contextualize responses/suggestions as per a specific customer need 5.will it be able to provide a good customer experience for its customers in terms of ease of use and simplicity 6.Can a good customer experience result in good customer satisfaction 7.will it have the capability to track Net Promoter Score (NPS) by requesting its customer to provide their willingness to recommend your business 8.will it have the capability to guide a customer who prefers a phone call or in-person appointment 9.can all the good features that it may possess result in bringing loyalty IMHO, these are some of the key things that a stakeholder might expect an AI driven chat-bot PoC to have for giving an effective customer service. The list can always grow but practically from the perspective of the stakeholders/key influencers in an organization, the POC should address those important ones as needed by those influential stakeholders for it to get succeeded. Primary Risks From my perspective, the primary risks that are associated with the POC that the Project leader might need to mitigate, for a smooth transition are: a. To implement this POC, few things are absolute must i). AI Technology awareness to staffs in the organization ii). Sensitizing staffs that AI is to help staffs for efficiency purpose only (because this is not the case currently in most circumstances). iii). Using AI-driven/enabled chatbots requires a shift in organizational thinking. Unless you do this, the fear of unknown will always derail the efficiency of this b. To ensure that the AI driven chat-bot is bound to laws and regulations of the country from which it is being operated.. (Ensuring ethical behavior,) i). This is an important aspect.. Just like as when human beings gather data from the customer during the conventional ways, AI can do a similar one while having chat-bot conversations (so we need to be careful on ensuring only right data is captured) ii). Regulatory compliance for AI driven products, during the PoC development and during real-time deployment may (or may not) vary. In that case, the project leader should communicate to the stakeholders about the additional changes happening in terms of potentially delayed deployment, potential increase of the deployment cost, etc. If not communicated, this can lead to stakeholder dissatisfaction c.Developing AI SMEs to troubleshoot any AI technology issues d.A Solution Architect who can visualize the business needs and apply the AI architecture accordingly e.Project leader him/herself understanding AI fundamentals to talk to the people who support the AI-driven chat bot system, on their own language f.Continuous monitoring of the AI driven chat-bot and g.Identify a mechanism for Continuous Improvement of the AI driven chat-bot using individual/the support teams’ observations and through customer feedbacks Lacking on any of these aforementioned aspects can be deemed as risks. These are the aspects that need to be addressed by the Product leader for a smooth transition from the conventional ways to AI driven conversations to improve the customer service Conclusion: Thus we can see how a PoC can help us in the context of business scenarios, as how to quickly arrive at a decision and help us in improving our current ecosystem