Since the Kingston release, ServiceNow offers a new plugin called Agent Intelligence. It’s also known as the ‘Automation Engine’, as ‘Machine Learning’, or just ‘scary future prediction AI stuff’. The last months, I’ve worked on a pilot to test this awesome feature. After introducing Machine Learning in general I’ll walk you through the challenges and surprises I’ve encountered in implementing it. After that, there will follow some predictions. Did I write them or did the scary AI stuff do? Nobody knows.
“My goal is to add value by translating processes into innovative technical solutions.”
In general, Machine Learning (ML) is a form of Artificial Intelligence that gives computers the ability to ‘learn’ by giving them data. Although often the reference between brains and computers has been made, this analogy was never really correct, since the two handle information in very different ways. Brains aren’t scripted, are totally unpredictable, and after shutting them completely down, it’s not really possible to reboot. However, since Machine Learning has come into play, and especially when using Neural Networks (a network of connections between input and output, where the weights of the connections can be altered), this analogy becomes more accurate. With ML, you don’t tell the computer what to do exactly, you just give it information about the world, letting it decide by itself what this all means – just as us our brains do.
Agent Intelligence – Machine Learning the ServiceNow way How does this work for the ServiceNow platform? A while ago they bought a machine leaning start-up called ‘DxContinuum’. Together, they’ve built the plugin. More features will be added in the next releases, but the fundamentals are already in place.
When exploring the architecture of this plugin, the first thing that stands out is that part of the mechanism lives outside your instance. The actual ‘training’ of the ML models happens in a dedicated environment. You set up a filter and the parameters indicating input and output, and you wait while the model is trained somewhere else.
The advantage of this is that it doesn’t slow down your own instance. Of course, these models need a lot of computational power and you don’t want that to have an impact on your environments.
The downside, however, is that you cannot see what happens. This is in general the case in ML: it’s a black box – you give it data, it gives you predictions. But in ServiceNow the training itself is hidden as well. A consequence of this is that if something goes wrong during the training of your models, you do not get any insight about what was the problem exactly.
In practice I was happy to run a pilot at one of our clients. They have a ServiceDesk which has been using ServiceNow for more than a year now. Here, they have generated around 15,000 Incidents, of which 12,000 were made by hand.
All these Incidents were linked to Business Services and Assignment groups. We investigated whether we could train the model with based on the Short Description field, to predict the Assignment Group.
The lack of detailed error logs, however, makes it hard to set things up. When giving it data that is insufficient to train the model with, you will just receive an error and that’s it. Of course, that was exactly what happened. Good luck finding more data!
So we went ahead, looked at the process again and figured the most useful category to predict was not the Assignment Group, but the Business Service. And, to be precise: the Business Service that was selected when the Incident was in state Resolved. By then the Business Service was definitely correct, whereas in the beginning of the process could be faulty. In other words: it happens sometimes that a ServiceDesk employee assigns an Incident to a wrong Business Service, but somebody corrects this along the way. Using corrected data from later in the process to prevent errors in the beginning: a practical example of the added value of Machine Learning.
Luckily, training the model with these parameters was in fact successful. And after it’s trained, the mechanism works flawlessly. The form is intuitive, the filter works familiar and you’re indicated whether the training is finished or not. After a successful trained model, it can be selected to start predicting with just one click.
Out of the box, these predictions are applied after the form is saved and the predicted field is still empty. But isn’t it fancier when you would see this happen in front of your eyes? After half a day of scripting I managed to make it work: after a user fills in a description that results in a prediction, the Business Service is immediately updated. Magic!
Challenges The biggest challenge is having enough data. We were able to make it work with just 15,000 records, but if you can, go for at least 30,000.
It’s not just the number of records, it’s also depended on the field that is being predicted. With the same records, our first attempt failed, but when using another field to predict, the model was trained successfully.
Next to this, the advantages are a bit fairytale-like, and this novelty can make people afraid. They don’t trust that a computer can make better choices then they do. Therefore, I would advise to use ML as a supportive feature, not replacing human action but helping them by offering smart suggestions.
The future Preventing errors in Business Service selection and making it easier for the user to fill in the form is great. But in the future even more fancy features are possible. Imagine, for example, error prediction of CI’s. When a server breaks down, it’s already too late – but if you can predict it to break down in the near future, you can already go there, and prevent the error before it actually happens.
In the end, of course, AI will take over the world. But we’re not there yet. We, humans and machines, both still have a lot to learn.
Sign up to our monthly Flow@Work Exclusive newsletter to get free access to our expertise and lots of tips and tricks to make work flow on the Now® Platform.
