Deliver Hyperautomation with Artificial Intelligence Technologies from SAP [INT102]

Hi there, everyone. Thank you so much for joining the session today where we'll be looking to tell you how we're delivering hyperautomation with AI technologies here from SAP. I'm Andy Lawrence and I'm the lead architect for Business Operations Self-Healing. I'm looking forward to walking through capabilities and solution, how we are managing our approach in this area, and showing just what we're all about overall.

Now just before we dive into that, I just want to set the scene and show you where we sit as far as the intelligent enterprise goes. So Business Operations Self-Healing is a cloud-delivered application. We deploy this on the business technology platform. We use a combination of the application runtimes and a data persistence, a number of the different technologies like conversational AI, robotic process automation, and the AI factory here at SAP. Our application provides an integrated way to consume and apply all of those great technologies in an intelligent way to supporting you in running businesses day to day.

So what do we mean by hyperautomation? We aspire to deliver an unmatched customer experience for our customers where we are looking to fix issues that we either detect in the environment or hear from the end users. We want to do that automatically, seamlessly in the background from the monitoring side. And from the end user side, just provide really simple, intelligent, intuitive ways to interact with the core processes, be able to understand what that issue is, and help them bring that issue to resolution in the shortest time possible by combining all of the technologies that we're bringing together here as part of the Business Operations Self-Healing service. In terms of what we focus on, we are looking to be able to take away a lot of the repetitive tasks through automation to release employees, whether in support or delivering a direct business of up to the customer on those higher value tasks.

Focus where it matters and increase the performance in all of those areas as well. How do we do this? We look to apply machine learning to get understanding of what's happening in the customer environment, whether that's training our models with ticket history to know where we can send the right tickets to or understanding the data distribution in the environment. We can propose the correct values for missing data or incorrect data that exists within one of the processes that may be causing a disruption there. We then apply robotics to analyze that further and detail and look to create resolutions for that to actually take that problem away automatically for the end user at their point of contact with us, or equally on the self-healing moments that issue's been detected. Again use the robotics and other services there to take action in the connected applications and solve those problems. How we do this? A real key element for us is being able to execute on data that we get in as close to real time here as possible.

We don't go out and acquire all of that data for ourselves. There's other systems and solutions that exist in customer environments today, like monitoring solutions or AI ops platforms there. They've done as this specific application sits. And they may be working at an infrastructure level or technology layers and different combinations that exist out there. And they're very good at what they do. They're very tuned into the things that they are monitoring.

And to be able to try and cater for all of that within this product doesn't give them the credit they deserve and also takes us away from the real focus. For what we want to do is to understand what's going on in the environment and take action to resolve that. So at the start of this process, those monitoring platforms would connect to the systems to acquire the data and look to collate that. And they will measure that against their own configurations to see whether or not any situation is breached a threshold-- by which they would normally just raise an alert within that monitoring platform. Route that to the relevant operations team or support team to investigate further and take action. But that's where we'd like to step in here at that point.

We would like to consume the event from those monitoring platforms into this elaborate self-healing and understand and map that to content that we have in relation to that specific error. We can then understand that situation in more detail, based on the data provided. And we'll know where it's happening in the landscape and what type of error it is. We do that level of analysis and see whether or not we can resolve the problem.

And if we are not able to resolve that, we're then able to document that and route that to the right people. But basically taking an action on that event every time either to take it away or pre-diagnose it for the other operators who will end up making the right choice on how they resolve that further. How do we do that? So what we have on the screen here now is a representation of our Hyperautomation architecture. So over the next few minutes, I'll look to walk you through that and give you a better understanding of how this is put together. We'll start over at the top right where we see the triggers here.

And this is where we can have these monitoring platforms or other applications raising events and sending them into us. Start with Solution Manager and Focused Run where we have an integration that we can deploy into those products which are then able to send events into our APIs into our resolution execution area. Other products that there as well.

So we could take security incidents, either from, IDMs Identity Management, or the GRC solutions, or other Landscape Management type tools that would be out there as well. Equally from the business process side, we can take things from SAP Process Insights, another dimension of the Business Process Intelligence suite here, or other third party applications in those areas. Any of them that can send an event with a payload to us we would be able to ingest that into our APIs and analyze that and start comparing that as to how we would execute the resolution there for us. That happens down on the execution side on the middle left of this picture of the Resolution Execution. And there's three key components to this. We have skills that we deliver out-of-box which the blue squares and cubes that are available here.

And we can also host alongside this custom skills in relation to errors that we haven't covered so far or ones that are very specific for a particular customer customization they've done or third party application they're using where we haven't had any standard content there and available. We can combine that with the context of where that problem occured with the information we received through the event and our understanding of the customer's landscape, we will be able to connect, understand where we need to execute that and work out how we can link through to it. So we're able to connect it to on-premise systems using the cloud platform connector and BTP or other areas of the SAP cloud that's accessible from the platform to any other application that would be accessible over public internet with the right security and credentials, of course, to connect security to that. We then able to trigger the execution, to do the analysis, and ideally the resolution of the issue that's been raised. And trigger that using the appropriate runtime environment. We have a lot of content we developed today on robotic process automation.

We'll be using that engine for triggering those. We also have content we've developed in microservices for ourselves, as ODATA services, that we can then trigger also to connect through to the same systems in a similar way. So when we move over to the right hand side of the middle here this is how we interact with the different products that would be available. So we have standard content for ERP and S/4HANA.

We are able to do some solutions there in SuccessFactors. Microsoft Azure is another example. where we can understand what's going on from the cloud resource perspective, giving operators insights as to their status, being able to restart them, resize them, all of those typical day-to-day operations they may be needing to do. We can extend this to other applications in the SAP cloud or other products there as well as the content builds out. And essentially through this mechanism and connectivity that BTP allows us to do, we can connect through to any of those applications there. That deals with a self-healing approach where we've received the event trigger from an external application, pop that through the resolution engine and then execute that against the back end applications where the issues reside.

Coming down to the bottom right now in what we mark as Intelligence, this is where our chat box sits. You'll see this later on presented as part of Customer Portal demo for us. But the chat can be deployed as part of any existing portal or in stand alone for customers to access. But ideally it's in a place where they'll be going to see that today. In terms of how that works, end users come to the chat bot and start having a conversation, describing the issue they're having.

We will use intelligence in the chat bot and also looking up against resolutions and content that we have today, to see if we understand that issue and gather more details from them. What we can do as part of that, we can use if we're getting more data and use that to maybe log a ticket on the user's behalf. We can use machine learning there to be able to classify the ticket and send that through to ticketing systems as you see over there on the bottom left-hand side around that where we have out-of-the-box integration for ServiceNow, BMC Remedy Cloud, and Solution Manager ITSM, and any other ticketing system with APIs to allow us to create, read, and update tickets. They're looking for knowledge items. We have a machine learning model that we've trained with the customer's knowledge data looking and searching against that, if they're describing a particular issue, and being able to refer them through to the relevant articles to see if that's resolving their issue for them.

But another example of how we can apply the machine learning there. Equally if there are problems with master data in the environment, we can train machine learning models again on customer data from the relevant application. And where data is incorrect or missing we can augment the end user by providing them with a proposal and a ranked list based of the confidence that was there of what's the right value to fill that particular field in that part of the organization at that time. So many different ways to apply that and give the users insights as well as being able to understand their issues day to day, and be able to learn from those interactions too.

Whilst we're doing all of this execution, a key thing for a centralized automation platform today would be for us to be able to trace and provide visibility of everything that's going on. Without that we'd never be able to account for what we have done, the decisions have been taken, and then we wouldn't be able to build trust within the customer environment that this platform and its solutions are operating in the correct way. It's very important to be able to gather that as we go and deliver that level of transparency.

And we also replicate this into the tickets that we log and, as shadow teams as well, to be integrated to the existing support processes that are there and running in the customer environment today. Effectively allowing us to be operating as an intelligent autonomous member of the support team, helping them out in the day-to-day activities. Going up to the final block up here, to the top left, is where we're getting insights and building on what we've logged. And what we can get from a product point of view is to understand where improvements are needed, or extra solutions would be required, building out our roadmap, helping the customer understand, how the users are using the platform, any known improvement opportunities in the system. Maybe they've done a release. Introduce some new functionality into these applications.

It's now generating a new peak of errors coming in there. Users might come to the platform to look for a solution, but there's none there. But we can highlight these gaps to customers and help them understand and be able to plug those maybe a lot earlier than they would be able to realize today. So that gives you a good feel for our architecture. We can operate in both the self-healing mode, self-service mode with the users coming and talking to us through the chatbot technology, centralized skills management area, and resolution engine with full transparency, and logging running through the environment as well.

In terms of how this comes together, the architecture itself is a key foundation stone for being able to deliver this and provide this integration across the AI technologies that we have here and deploy them seamlessly into operation. That would be great. But what makes that significantly more valuable is the content that we provide. We provide content today in IT, crossline of business areas, give them a password reset, security role requests, and others, Cross LoB topics, content in sales orders today and we're expanding that across HR, Finance, Procurement and others into the future and also hosting custom skills here as well.. So that allows us to deploy a platform that's not only there to be able to create new content against, but to be able to deliver value straight away activating that new environment, helping on those high volume repetitive tasks to ease the burden on the operations as well as reducing disruptions, too. That's really that combination that makes up the Business Operation Self-Healing service today.

How do we do this in terms of the content? We've talked a little around some of these already. But from a self-help point of view being able to connect the user to the knowledge items instantly allows that to give them a resolution to the problem without having to log a ticket or speak to anyone on the support desk at all. By being able to capture that information as well, what they're looking for, and if it's not relevant they can describe issues further and improve the quality of any ticket that we do log if we can't solve the problem just by connecting them to the right area of knowledge.

On the self-service side, as soon as they hit a problem they can come to the platform, have a conversation with the chat bot, and look to see if there is a resolution now whether that is simplified way of requesting the right role, allowing them to do password resets in an application they've locked themselves out from. They're not having to log a ticket and wait for a slightly later response or understanding other things going on in the environment if the system is there or performance issue is occurring. We can give some insight as to what's going on in the system, as well as understanding from them any further details that are affecting them. Then, be able to log in high quality tickets and route it to the right teams for them to deal with straight away reducing that time for delivery and also improving service quality overall.

On the self-healing side, being able to look at the events that are coming in, be able to trigger the resolutions 24/7, reducing that operational effort, and also increasing service quality and becoming a fully autonomous member of the support teams. Showing you around the architecture and how we're doing that and giving some examples there around the content. So what better way to bring this to life to hand over to my colleague Alice who is going to walk you through some demonstrations of the content that we deliver out-of-the-box today.

Thank you for the introduction, Andy. In this use case, we will show you how you can use the Business Operation Self-Healing platform to reset your system password. BoSh chat bot can be embedded into any web based service portal very easily. To begin, you start a conversation with Florian which will request a password reset. Florian will then ask you for the system and client number that you need to reset your user in.

After this, Florian asks you to confirm whether the password reset is for you. If allowed, BoSh can be configured to reset a colleague's password. You will not see the password, but the colleague will directly receive the new password via email. Florian will now reset your user and show you the new password on the screen. You will also receive an email showing the password if this setting is configured.

Here you can see a user is fully productive in just under a minute, which is significantly faster than a traditional ticket-based process. Once Florian has completed the operation, you were able to leave your feedback of the process. This can help customers understand the success of the platform and also understand the user satisfaction when using and experiencing the platform. In this use case, we will perform a How-to Request using the BoSh platform. To begin, instead of logging a ticket, a user can log onto the chat bot and request help from Florian. Florian will ask you to describe the problem and, from here, will analyze your description and provide a ranked list of possible articles which could help.

After reviewing the articles, a user will determine whether the proposed solution has solved the issue. BoSh has allowed the user to continue their work with little interruption. As always, Florian will ask you to confirm whether your issue is resolved and we'll also ask for any feedback or additional comments. In this use case, we will show you how to resolve sales order issues interactively using the BoSh platform. In this example, BoSh can resolve an issue when a sales order cannot be created due to a master data issue.

Here you can see a user trying to create a new sales order. After entering the material number, they are receiving an error message saying that the material is not listed to the customer. After clicking for more details, the user can see that this is Error Message V1118. At this point, a user would normally have to contact a support desk to get the data corrected.

This process can take time and, until it's solved, the user cannot create a sales order for their customer. Using the BoSh platform, the user can provide the details of issues and check to see if Florian can resolve the issue for them. Florian will ask them for more information regarding the error. The user will provide the system details and error code, and Florian will check to see if a resolution is available. As we can see, Florian is aware of Error V1118, and can provide a resolution.

The user can choose to trigger the solution, or look for knowledge documents, or create a quality ticket. In this case, the user chooses to run the resolution. Florian gathers more information specific to the error and asks for a valid business reason. This is stored for audit purposes later.

The user confirms the data is correct and Florian then runs the resolution. In this case, the fix is triggered to run in the background using SAP RPA software. BoSh can use different technologies, like REST APIs, to execute fixes as well. We can see here that the resolution has worked successfully. The end user can continue and complete the sales order, saving them time, effort, and disruption. Florian will log every action into a ticket in the customer's ticketing system.

If the action is successful, the ticket is closed and there to refer to later. If unsuccessful, the ticket is automatically routed to the correct support team. You are always able to provide feedback, which helps Florian to understand how well he is performing. In this use case, you will see Florian self-healing failed IDOCs in a system. Here you can see several failed IDOCs with the Status 51, shown as red.

This means they are unable to be processed for a few reasons. Each of these IDOCs relate to different errors. In this example, the errors are V1118 and V1117. You can see here that our monitoring has picked up the failed IDOC. This alert has notified BoSh of the problems with the failed IDOCs, which will show up in the alert inbox showing a red status.

The alert shows you that there are currently six failed IDOCs which Florian will attempt to resolve. After refreshing the IDOC list, you can see that the job has been completed successfully. All of the IDOCs have been correctly processed and have generated the sales orders in the system.

In the monitoring alert inbox, you can see that the IDOC monitoring has been changed to green as the issues have now been resolved. In this use case, we will resolve a customer master data issue by using user augmentation and workflow. Using an example, we will exemplify how incomplete master data can stop an end user from creating a sales order. When creating a sales order, our end user receives a Warning message explaining that they have not entered the payment terms.

A user can enter a value, but there are so many to choose from that it's likely a user would choose the wrong one. As we check the customers master data, we can see that the payment terms have not been maintained. As a result, we will now fix the root cause using our virtual assistant Florian to do so. Primarily, you explain the issue to the chat bot and provide the name of the system which is experiencing the issue. Florian will then offer you an available resolution which is relevant to your query. From here you can either resolve the issue or access further assistance.

Florian will ask the details of your master data and you can fill in the respective fields. The machine learning model will then use those fields as inputs, allowing it to predict possible payment terms. BoSh uses trust levels which are set by customers.

If a value is higher than the trust level, than Bush can implement the fix immediately. If lower than that level, BoSh will create a workflow as shown in this example. Florian will ask you to cross-check the details and then trigger a workflow. You are welcome to leave feedback and help Florian and understand their performance. An approval request was created here and the reviewer can see that a user has picked up a wrong value.

This can be corrected and sent for final approval. The workflow approval enables change to occur solving both the sales order and root cause of the issue. The workflow approval has triggered the fix to run using SAP RPA. Now BoSh has resolved the issue let's try to create another sales order. Here we can see that our payment terms are automatically populating.

I hope these demos have given you a great feel for how BoSh can support you. Now back over to Andy. Thanks very much Alice, those demos were awesome. I really hope people have got a good feel for what we can do as a solution today looking at the different areas that we ran through there. So just moving on a little bit here, just to give you some insight as to how we deliver this today and what our plans for the future are as well. Currently, the business operations self-healing service is deployed as private cloud in Business Technology Platform.

The customer needs to have an account and also needs to have that as a platform enterprise agreement as well as any of those services that we are using are all available under that type of engagement with us. We do need support from an implementation service point of view to help customers get up and running. There's a fixed price offering available through Max Attention / Premium Engagement contracts as well as professional service. And we don't mind which contract it is.

That's really a customer choice as to how they wish to engage on that. That service will deliver essentially the content deployment to the customers, run through knowledge transfer, and help them as support get that out to production beyond once it's been validated by someone from there. We deploy all of the content into a customer environment and have them pick and choose what needs to be activated from that. We'll increase the content level for that over time.

Looking to the future, we're working on a next generation SaaS based offering for the BoSh moving forward. And that would be deployed on the next generation runtimes in Cloud Platform, and also introduce a different subscription model as part of that. People will go for this today and continue to use what they're doing as well in that fashion.

But also, coming over to the SaaS side at a later point in time where we're able to facilitate migrations. We'll look at beta testing program towards the end of the year. And at some point, going into 2022, that will look to come a reality and also deliver an increased level of content as part of that. And also utilizing any new execution technologies like SAP process automation to expand the capabilities from our runtime point of view. Just to give you a bit of insight here from a live customer, Hewlett Packard Enterprise are live with BoSh today and continuing to roll that app across their environment. We have a couple of slides describing the global reference.

It says how they've gone about this and the benefits they've been getting. You can read about this in more detail when you receive the information in the slides following on from the session today. In terms of being able to wrap this up and summarize where we are today we can deliver 80 or so high value use cases out of the box with hundreds of conversational skills in just as little as four weeks. Preparation time for the customer when they're deploying, but once we kick in, we can do all of that knowledge transfer around it, run through all of the use cases, bring everyone up to speed in that, and support the initial validation in those non-production environments to that point. And then we can hand that rollout over to the customers from there. Very quick to deploy.

Very quickly start taking value from that once right and supporting the end user community. We're able to do self-healing and self-service, allowing us to run in the background and reduce any disruption. We're also able to augment the end user and help them make the right choices to resolve their issues or request things as you may have seen early in one of the demos through workflows and have those approved for operations here. By deploying this platform with its content, customers don't have to invest in creating this for themselves with all the extra skills and the development effort they will require not only to deliver that but to maintain that and expand that into the future. That's dramatically reduced by taking this approach. Our abilities to monitor and understand things really gives people insight as to how these things are working in production.

So with that, just like to wrap up today. Thank you for all of the time you spent here. I hope you've learned a lot. I really hope you're able to explore the rest of what TechEd has to offer looking at the new sessions and networking with peers. I'll be doing some of that myself.

All that remains for me to say is thank you so much from me, Andy, and also from Alice. We've really enjoyed the session. Enjoy the rest of TechEd.

2021-12-10 13:17

Other news