Skip to main content

Service CollABorative October 2023 - Tech Talk with Stephen Jeffs-Watts, SVP Service Applications


Forum|alt.badge.img+8
  • Do Gooder (Employee)
  • 20 replies

IFS Service CollABorative: Tech Talk Session with Stephen Jeffs-Watts, SVP Service Applications at IFS

Date of Meeting: 17 October 2023 10:00 AM US Eastern Time 

 

Stephen Jeffs-Watts Presentation:

Slide: Confidential

  • Statements of possible future functionality for IFS’ software products and Copyright© 2023 by Industrial and Financial Systems, IFS AB.  IFS and all IFS product names are trademarks of IFS. All rights reserved. ​
  • This document may contain statements of possible future functionality for IFS’s software products and technology. Such statements of future functionality are for information purposes only and should not be interpreted as any commitment or representation. This document shall be kept strictly confidential. No part of this document may be reproduced or transmitted in any form by any means—electronic, mechanical, photocopying, recording or otherwise—without the permission of IFS.

Slide: IFS Cloud

  • This is the IFS Cloud Turbine where we talk about the fact that customers are at the centre of everything that we do and IFS as an organization do three main solution types or solution categories in EAM, FSM and ERP.

Slide: IFS Cloud

  • What my group do, we focus on the collision point of assets and customers, but with a very, very heavy people dimension as well in what we call service lifecycle management, where the asset and the customer dimension associated with the asset collide and obviously none of that has changed, right? That has not changed in the last three years and I don't envisage that change changing in the future either.

Slide: IFS Cloud Service Management Capability & Solutions

  • Then the way we represent that inside IFS cloud. We got right two main solutions and then additional capability around the outside of it. Now the two main solutions that are becoming crisper and crisper and crisper, if you like, as we get through each release and we'll hopefully become blatantly obvious when we get to when we get to what I'm about to show you in terms of what's coming in 23R2 is around that workforce management, the mobile workforce management piece. This is the traditional field service domain where we take away some of the asset side of that collision and we focus very heavily on workforce planning, work scheduling, using the PSO engine in the background of course and then work execution through the mobile client. For a lot of our existing our existing customer base in FSM land, they take that workforce management solution and extend it into full on SLM where we're looking after contracts and warranty and equipment and install base and engineering change orders and all those kind of things. And then some of them extend it either to the left by adding in customer service capability, which is where we start talking about the contact centre and customer engagement and portals and those kind of things or to the right further into the back office effectively with depot repair and depot repair centres. And that's what we're driving towards with every single investment that we make in IFS cloud, we're driving towards those two main solution sets. And if you take SLM, you can extend SLM further into the business by adding in the finance and HCM elements, that's the composable nature of IFS Cloud and why that exists. But then we either go further into the back office if you need to, or further into the front office if you need to on either side. So, a big, big focus in 23R2 has been on that mobile workforce management solution on the traditional field service to management space. I would argue that this is our most people centric release ever. And when I talk about that, you'll probably understand why on the next slide.

Slide: Overview – New Features in 23R2

  • Yes, we have done some things in areas like install base, but when you look at what they are, they're all supporting that scheduling life cycle. So, in the request end, we've enhanced the usability quite a lot in the request management process.
  • We've added some more capability in from FSM around service notes and the event management side that we got in FSM.
  • We've made a massive investment in SLAs, that's obviously supporting scheduling a lot.
  • We've added in a lot of APIs to help people connect out in resource management so that we can have external HCM systems driving the resource management information that we need for scheduling.
  • We've added a lot of information around availability patterns so that we know when we're allowed to go to sites and things like that, but in a patterned way, rather than one offs.
  • And we've added in a huge amount of capability so that we can really drive the PSO engine from directly within IFS cloud. And we're not talking about having IFS Cloud and PSO, we're really talking about the scheduling capability in IFS Cloud now because we drive it from the workforce management solution or from the main IFS cloud solution and that means adding in things like all of the appointment booking templates, utilization rules, a whole host of enabling additional features in PSO directly from IFS cloud.
  • But we've also continued to focus on the dispatcher user experience with the dispatch console. That's one of the Halo clients inside of IFS Cloud.
  • We've added in things that I know that our FSM customers like to use like global skills. That's now there in IFS cloud, so that's coming along nicely and we're nearly finished with a massive piece of investment that we've done over about three or four releases around the management of crews. So, a couple of releases ago we added the ability to define a crew and to be able to give a shift pattern and things like that for the crew, now we can start to see what does the make up the crew need to be? What is it currently? If one member of the crew is off on leave or something like that, then that highlights that crew is being unavailable or noncompliant.
  • We've added the execution and reporting life cycle, so down on the mobile device you now get ‘Am I a crew leader’. so therefore I'm doing all the work, or ‘Am I a crew worker’, in which case I'm just seeing the work I'm not necessarily being able to transact it. So those in a crew environment, we now pretty much done on a lot of the work we want to do in crews and multi resource handling.
  • And then in the Mobile world, we've made some big changes in the way that we synchronize the data down to the mobile device, added a lot of additional configuration and some default behaviour and also the ability to do online lookups for certain pieces of data that you don't necessarily need to keep on the device all the time and be able to grab that data, pull it offline for the life cycle of the work that you're doing. And then it will just disappear off the device. So if a technician is moving from one region to another or is doing some work just across the regional boundary, so they haven't got the install base information for a site on their mobile device as part of their normal package of data, they can now basically search for it, by scanning the barcode on the asset or whatever,  it will say ‘Yep, I've got that data. Do you need it?’, And we'll say, ‘Yep, grab hold of that data for me. Let me have it offline.’ I can do the four or five tasks or whatever I've been allocated on that site with all the asset information at my fingertips. And then it will just disappear again afterwards. That's a big enhancement in terms of helping you to be able to manage the interaction of the data between the back office and the mobile device and deal with the exceptions. One of the big things that we've seen is customers synchronizing massive amounts of data on the device for just in case purposes, and we want you to be able to handle just in cases just in case and cut down on the burden that synchronization of data always puts on the application as a result. So that's probably the big one.
  • We've also started some of the mobile configuration stuff that we need to do, so we've now got conditional fields in there.
  • We've got the ability to do list of values filtering so that we can pre select certain options based on values in other fields and I'll talk a bit about the whole mobile configuration journey that we're on in IFS Cloud and where we're up to on that.
  • And finally, the other thing that we've added, which is a big one for me, is task bundling. So, task bundling is the concept whereby we say I am going to this site and rather than using PSO's do on location incentive to give me 4 tasks that are scheduled one after the other, it treats it as four visits effectively, what we can now do is balance that out a little bit. There are sometimes where you will decide in the back office or as a planner or whatever, I want those four tasks to be done in one visit, so you can predetermine a task bundle. Then, if there's other tasks at that site that aren't part of the bundle they do on location incentive will still apply, and it may say ohh great do that one as well while you're there. That’s manual in 23R2. What we're going to do in 24R1 is then extend that with the concept of being able to have rule based bundling effectively and also even possibly identify bundling candidates, so if there is that convenience PM task that sits there and never gets scheduled because it's always a low priority, you might be able to get a suggestion from the system that says ‘include that in this bundle’ if you want it to get cleared. So that's a big piece for me. I've been waiting for that for a little while and I'm quite excited that we've now managed to get that into the product.
  • So, a lot of stuff in 23R3, I have to say. I'm incredibly proud of the team because they've done a hell of a lot in a six month release cycle to deliver this level and this quantity of capability in just six months is an outstanding achievement and I hope you all absolutely love 23R2 when you start seeing what we've done and when you start working with it.

Slide: Service Management – Overview of new features in Request Management Process

  • This is where all of those improvements sit in the life cycle of the business process that we supporting and you can just looking at the volume and where they sit, the vast majority of them are sat in that big focus area of dispatch and execution, which is what we said the targets would be for the 23R2 release. So when I spoke to you in March and we were just starting up, I said we'd have a big focus on this area and you can quite clearly see from that that we have had a big focus on this area and it's probably going to be pretty much the same for 24R1 as well, just tidying up some of the add-ons and the extras that we want to do.

Slide: IFS Cloud Service Management

  • So last time I was with you, we talked about these five investments themes and rather than going through them again at the helicopter view level, I want to focus on two of them. I want to give you a bit more detail on two of them. And so I want to give you a little bit more detail on ‘Insightful Service’ and a bit more detail on ‘Field Worker of the Future’ because these are investment areas that are in flight. We're working on at the moment. The first ones exciting. We've got plans we're starting to do things. It's a little bit longer term. The field worker side of life we are working very, very heavily on at the moment.

Slide: Insightful Service for the intelligent, automated enterprise

  • This is where a lot of our AI investment sits under this investment category and we are trying very hard to take a holistic view across the entire service lifecycle. One of the good things with the two pillar with add-ons to the front office and add-ons to the back office type approach that we've got is that we can look at the entire customer journey and look across that customer journey and say where should we look to automate, where should we look for AI to add value to what you do.

Slide: IFS.ai conceptual architecture

  • And this bit is probably quite a confidential cause we haven't necessarily announced a lot of this stuff to the to the market at the moment.
  • We are midway through building IFS.ai. Now IFS.ai is a bit different to how other people are thinking about and talking about AI, because we don't start with a an AI toolkit and allow you to do whatever you want with it. We start at the top with the value scenarios and we marry those value scenarios to the most appropriate technical solution. And the technical solution that we have is built up of two layers, a data foundation layer and an AI orchestration layer. So, we in the business define what we want AI to do, what we then do is look across the piece in these two layers to say, OK, how, what's the best way to deliver that? And this is all stuff that is quite interesting, I'll say. And it's something that our team are quite excited about and it's something that we'll be looking actively to our customer base to help us solve problems. What we want to do really is open the gates and say what problems need to be solved, and then let us look at those problems and say, does AI help here or does it not? And if it does, how? Which I think is a little bit different to the technology forward approach that some of our competitors are following. We're trying very hard to say what's the value scenario that we're trying to address and work backwards from that rather than ‘here's a load of cool technology, what do you want to do with it?’

Slide: IFS Machine Learning Service – Delivering service into IFS Cloud for democratisation

  • I'm going to attempt to try and explain a little bit of this. Those that know me know I'm not the most technical person in the world, so I get given slides on this stuff and I'm going to try and distil them into some kind of common sense or fairly simplistic language to try and make technical stuff sound a little easier for everybody. So, what we're trying to do is deliver what's called a shared service and IFS machine learning service. And that really allows us to have a common AI environment that respects all of the data privacy rules and everything else that are needed in order for us to be able to deliver AI to you all, that your gateways inside your IFS cloud environments would connect to. Inside the ML service, there's then a number of techniques that are used and there is absolutely no customer data at rest, not even a user account. Nothing. Inside that ML service, we then use a combination of our own technology and our own proprietary algorithms, specifically around things like optimization and simulation. That a lot of our own proprietary technology, but we also have the ability to incorporate third party technology or third party services like ChatGPT if we need to. And that's the general premise that we'll try and make the delivery of value scenarios easier by running an ML service that chooses the appropriate ML techniques for the problem that it's trying to solve.
  • Slide: IFS Acquires Falkonry: Revolutionizing Industrial AI
  • A big part of that is the acquisition of Falkonry, which is in the process of closing it should close by the end of the year. But the whole idea behind this is that this gives us the technology that we need to be able to do time series analysis. That's Falkonry strength. The moment they focus on two or three specific sectors, the underlying technology is brilliant for doing time series analysis. Time series analysis is what we need for things like asset performance management, contract performance management and predictive maintenance.
  • That's what we need time series analysis as an ML technique to be able to solve. So, acquiring fault can we gives us a huge, huge potential and unlocks a huge amount of capability for us, and that will go into that ML service effectively.

Slide: Intelligence Embedded – AI Use Cases

  • Here are some examples of some of the use cases that my team are working on now. We looking more and more on predictive job duration. We've done some work on that already, but we want to extend the number of dimensions that are used in predicting job duration. We know that that's the age old problem of we have a standard task library. The standard task library was updated or was last reviewed when the system was implemented, when it was all uploaded 20 years ago and it still says it takes an hour and a half to do this job. Does it really? How does that change based on where that job is? How does that change based on who it is that's been assigned the job? All of those kind of dimensions we want to add in so you get a real time adjusted scheduled duration for each job.
  • Another one that I'm actually really quite excited about is the schedule explainability service. So the idea here is very much that PSO as an application and the scheduling engine that's there is an AI based scheduling engine. If you look at what it does, it is AI. But a lot of the time you have no idea why it's done what it's done. In fact, it's the most common support case we get. Why did this job not get scheduled? And how many times do you end up getting the message “optimum schedule does not consider this activity”? That's the default answer to every exception when it can't tell you what it thinks, and what we're trying to do is schedule explainability is take that away. I want you to be able to click on a job that isn't scheduled and for the application to say I didn't schedule this because this job and this job were more valuable at that time, or you can't get into that location at any point in time. You've got a data issue here to try and highlight data issues in your scheduling schema that are stopping it from scheduling jobs. This type of job has got such a low value on it, it's never going to get scheduled. What do you want to do about it? So, what we're trying to do is really make that schedule explainability service, really the route of explainable AI. We wanted to have a human touch, so it starts to tell you why it's thinking the way that it's thinking.
  • We're also doing some work around image recognition for people in utilities, for instance, where they need to know exactly which meter is it that I'm currently looking at and what is the reading, without you needing to type anything in, such as things like surface degradation and recognition and those kind of things. So that's in progress.
  • For those customers that are using in the whole service lifecycle. Then there's a few interesting things here. The first one and the third one are kind of interrelated to one another, because what I want to be able to do is, almost think of it like a copilot, right? That's helping customers and helping service desk agents log the requests and manage the requests more intelligently. There's no way you've given me enough information about this problem, I can't work out what it is that we should do to try and resolve it. Here's how to get more information to increase the quality of logging so that we have enough information to be able to dispatch the right technician with the right part, to pick up the right standard task or service catalog item. So those two are kind of interrelated because the first one is all about trying to increase the quality of data around the problem. That's not necessarily just human data that could be us going, ‘hang on a minute, I want to go and get to my IoT readings for this. Then I can understand and maybe ask three or four other questions and maybe then try and work out what's going on. And the other part in the ‘Intelligent Service Catalog’ is being able to dynamically work out the content of a task when it's packaged, based on that context that it gets from that more intelligence process of logging. So that's going to be two things that are very closely interrelated, but are very, very, very, big in terms of investment cost for us. It's going to take us a lot of effort to be able to get that right, but I think they're huge value points because both of those things then link into the third, which is all around first time fix prediction. Based on what I know today, what is the probability that this job will be fixed first time? It only 40%. That's bad. OK, what do we need to do to raise 40% to 80% or 90%? Ah, try adding this part. And the reverse of that as well in some respects is the skill set and the part needs are constraining this job so much that yes, you're going to get a 90% first time fix rate, but the ability of your organization to actually be able to schedule the work and send a technician out with that skill set and that part is really low. Your delivery probability is pretty much zero, but here's the good news. You can ignore that skill. You can ignore that part, because you don't necessarily need that skill. You only use that part in 10% of the cases that have this problem, so let's not consider that a constraint. The first time fix may drop, but the ability to deliver to SLA may increase. And trying to find that balancing point, I think will add a lot of value to our customers. But I'm willing for you to challenge me on these ideas that we've had as to where we think AI can add value and also help contribute to what that solution should look like.
  • And then, a lot of the other side is when we move forward in the service delivery process all about much more intelligence, skill based call routing. Can we make sure that the inquiries that we get in are go into the right place in a much more intelligent way than a fixed rule based type mechanism that we have today.
  • So there's the first eight use cases and value scenarios for AI that we intend to deliver and I say intend to deliver. This is roadmap work, so we'll see how close we get to those, but they're the ones that are in the domain if you like that we're working on and investigating now as the first ones because that's where we think we can hit off. One, these are achievable. Two, I think they'll be very good showcases and they will add a lot of value to our customers.

Slide: IFS Machine Learning Service – Support for ML Recipes

  • So effectively what we've got is some of the examples services., You've got what's called recipe techniques, that will be in the ML service.

Slide: Semantic search architecture – Extendable with LLMs

  • Semantic search and the large language model stuff. This is basically the ChatGPT style of AI.

Slide: Anomaly detection – Joining IoT with APM

  • Anomaly detection. This is where Falkonry comes in, with the time series analysis and anomaly detection, that's another technique that will be part of that ML service.

Slide: Simulation – Driving product success

  • Simulation. This is based on a lot of the underlying technology and techniques that are used by the WISE today (if you're a PSO user and you're using WISE). So that's the AI bucket. It's moved on a hell of a lot since I spoke to you six months ago, and I'm quite excited about that one.

Slide: Field Worker of the Future

  • Field workers. We're doing a lot here as well. You can see from the amount of capability that we've been adding and delivering over recent releases that the functional footprint of the mobile solution in IFS cloud is now pretty big and getting bigger and bigger and bigger with every release. That's good.  But there's a lot of other things we need to do. I want to give you a bit of a preview of some of the things that we are working on now.
  • Slide: MWO Framework Roadmap – Existing Capability
  • So, one of them, is all about configuration capability. We've been on a journey over the last few releases to add more and more configuration capability to IFS Cloud Mobile. One of the interesting things about FSM mobile for those customers that are using that and Alliance mobile as well, they are incredibly configurable. The problem with them is that there are very few guardrails. So, you can get yourself in a bit of a death by configuration scenario if you're not careful. It's very code driven to do that configuration, and the UI stuff in FSM and Astea is very point and click but as soon as you want to put some rule based behind that then you're doing things like client scripting and it's quite code based to do it. We don't want IFS cloud to be like that. We want you to be able to achieve the exact same outcomes, but we want you to be able to do it in an Evergreen safe manner. We want you to be able to do it with the right guardrails in place, so you don't screw things up. Because if you don't screw things up, then our ability to deliver a reliable cloud service, and a reliable repeatable application, which is what we're driving towards, increases massively. But where mobile work order and the mobile framework was in IFS Cloud back in 2020-2021 where we started this journey, was miles away from that. So, we're investing a lot and we've added all of these things on this list as we've gone, we've just added conditional fields and these custom push entities that allow us to define how data should appear.

Slide: MWO Framework Roadmap – Intended capability beyond 23R2

  • And as we go into the next release cycles, then we're getting into field validations, conditional pages, not just conditional fields. Conditional sections within pages, not just conditional fields. Being able to invoke APIs officially from within the client environment rather than using client script to go and hack around to do it. Adding in the ability to do custom workflows. Adding the ability for other applications to call mobile work order. Making a huge investment in updating and uplifting the UX which I'll come on to in a second. And then as we go through the second half of 24R2 or second half of 24, so for the 24R2 release, the intent as it stands today. That always has to have the word planned subject to change against it, Is that we then start getting into conditional pages rather than just sectioned. Adding in customer assistance. So you can build your own user guided workflows. Being able to have conditional commands, so when you add a custom command onto something, when should that custom command be available and not available. Being at being able to add in custom workflows. Being able to calculate values on the screen. E.g. this plus this equals Y or whatever it might be. Being able to add all of that kind of stuff in.
  • And then finally, we finish off a lot of the customer assistant stuff. But the idea is that what we've done is looked at what could you achieve with FSM mobile? What could you achieve with Astea mobile? What do most of our customers do with it, and how do we create capability that mimics the outcome or that creates the outcome that everyone was achieving in a “I'm just going to use standard IFS cloud configuration technique” manner like the page designer and the pages, navigation designer, all that kind of stuff, to be able to achieve that outcome rather than going in and typing client script that says ‘if value in field what field X is this that or the other make the colour yellow’ for instance. So, we try and take the code out, make it codeless, put the guardrails in case in in place, but make sure that you can all do everything that you could do before. Or everything the most of you did before. That's the idea. And we are quite a long way on that now, with very clear plans and good ability to deliver on this over the next couple of releases. So as people get towards the point that they're uplifting to IFS Cloud, moving over to IFS Cloud, the capability will be there to make sure that your field workers can operate exactly the same way as they could before.

Slide: MWO Roadmap – Intended Functionality beyond 23R2

  • There's still more to do on the functionality side. Again, a lot of this being based around increasing the efficiency of the field workers, making sure they're able to see what they need to, do things in an easy and effective manner, and add capability that we know they need. We know that a lot of our FSM customers do more than just job based time reporting. They want to do a proper weekly timesheet. So, we need to add that capability in the back office as well as in the mobile. We know that we want to be able to do things like monitor and manage the product structure for the install base from the mobile device, which is something that you can do a bit of in FSM, you can't do a huge amount, but you can do a bit of it. We want to make that properly accessible and available in a safe manner on the mobile. So, that's where we are on the functionality side, but the functionality side now is at a pretty high level compared to FSM and Alliance. if I'm doing a finger in the air calculation on the feature, the out of the box features and capability would probably at the 90-92% level now on mobile, which is great news.

Slide: Mobile UX Design Concept

  • I'm going to give you a little preview of what the UX might look like as part of the visual uplift program that we're doing now. We're working very hard to make the UX far more consumer like than it is today. As it I think I said last time, we as an industry did this wonderful thing where we said have loads of forms to fill in on this device and make your life hell, what I want to do is make you want to use my mobile software. I want your technicians to pick it up in the day and check it as the first thing they do in the morning. Just like they check Instagram. And that's the experience that I want them to have within the app. And so the team have done an enormous amount of work. This is a really good example of what happens when you get proper UX designers with proper user communities, with proper user research, to come up with something that is far more engaging than what we have today, and this is not finished. I think, prototype iteration #3. This is a Figma recording. It’s not real software I'm afraid, it's a Figma recording of a couple of user flows, and this is iteration #3. As we get towards iteration #4 and #5 and this is a little bit more refined, I will be on the phone and I will be asking for any of you that want to allow your technicians to join my user experience designers on a an experimentation study where they basically get a link to a web page on their mobile, so it opens up as a simulated app. We're recording it so we can see every click they do and everything they do, they get zero instructions and they get to navigate around the app. And we take that feedback in that's captured automatically by Figma to say are they clicking in the right place. Did they really understand that? Did they linger on that button for too long? Did they look at that menu and not understand what it said? That's the insight that we get at the back end of that study that we do. So, I will be on the phone shortly before we start coding some of this stuff. But I think hopefully you get to look at that, you recognize that it's a task and that it's everything that you think it is today, but he looks a bit nicer. And I'd like your feedback on that as we go.

Slide: Revolutionize Your Workplace with IFS & Poka

  • The last one is I wanted to touch on Poka and what it means for Field Service. So Poka is an acquisition that we've just made. It's very much geared today around shop floor product productivity for manufacturing workers and it's really good. It's a bit like a Facebook feed. It's a bit like a knowledge base. There's the ability to do simple work instructions and things like that.  It's really nice application, and those of you with manufacturing facilities and stuff, you should really have a look at it, cause it's really nice.

Slide: Manufacturing excellence – In a single platform

  • There's quite a lot in there that I think is very relevant to a lot of your users, because it really focuses on daily management and on learning and development, knowledge management, skill management, and it's on that second half that I think we've got quite a good alignment with service. If we start to transition across from manufacturing out into other industries. What I want to see us try and do with Poka is take their approaches to forms and checklists, and the approaches that they've got in there to knowledge management, and apply that to field service and embed that in the field worker technology solution. So we'll see how that evolves over the next couple of years as well. Everything we do in mobile is all designed about turning this from an administrative burden into a proper productivity tool, which is what I think you will want for your field service techs.

Slide: IFS Cloud Service Management

  • Just to just to recap, 5 themes, they've not changed. There's a bit of a deeper dive that has hopefully been useful for you into two of the five for today.

 

Customer Experiences / Talking Points:

  • Q: I'm familiar with the product called Dozuki. Is that kind of doing the same thing? Do you know that product?
    A: No idea. Don’t know it.
    F: Yeah, it seems like it's a lot of the same things. It was something we were considering at one point in time. That's why I was wondering, but generally it's a place you would put bulletins and things that you want your techs to know and they can search it based on the job type and that kind of thing. https://www.dozuki.com/
    R: The nice thing with Poka is that it recognizes the equipment as well if I remember the demo I saw of it correctly. It will then start to take in feeds of information from other sites that are using the same piece of equipment. So, if you got the same production line in five different sites, a knowledge article or a bulletin that's created, or a maintenance instruction or whatever that's created in one of the manufacturing facilities can be applied to that same product version in all of the manufacturing facilities. It’s a really quick way of distributing knowledge and distributing context. Distributing knowledge and information whilst maintaining its context, and I think that's really exciting for service for me because that's the thing that's often missing, right, is the whole manual tagging right. I need to create a knowledge article, we need to manually tag that knowledge article to say it's for this product or whatever, if it's part of it, you're saying ‘I'm here’, that's the product in front of me and it's just using the camera to recognize that for you. And you're just saying I had this issue. This is what we did to fix it. This is how we fixed it. Job done, and if automatically done all that work in the background for you, then when the next technicians on a different site looking at the same product, it's just done it for you. And that's the kind of thing that I look at Poka and think ohh now that's nice because ‘what are we?’ We're a community of distributed lone workers a lot of the time, but they're all doing the same things on similar equipment at least.
  • Q: You mentioned some nice ideas regarding AI and learning and different types of models for learning. Especially the first time was resolution support based on AI, this is a very nice story, but what do you expect? How many cases? How much data do you need or expect for a basis for a productive model? I think, if you have one case in a year, I don’t think its working, if you have maybe one in one hour, maybe it works. I don’t know what your expectation about data quality and data volumes about this AI stuff.
    A: Looking at what our AI team are talking about, they're saying it's kind of 3000 data points and up. Now a data point doesn't necessarily mean a job. A data point can be an attribute on a job, but we can start generating predictions from about 3000 data points upwards. And then what happens in reality is it then refines itself every time the same kind of thing happens again, and one of the other things that's interesting in the way that some of the models can build themselves is that they don't have to be exact match data points. There can be similar scenario data points. So, if you take a first time fix at a particular location could be really low. Now that could be because of the location rather than the equipment or the type fault. The first time fix on a on a particular fault type could be really low or really high irrespective of what type of product it's on. So, you can use each of the individual data points in combination to try and reduce the fact that you haven't seen that problem on that site more than 3000 times, right? And then what you do effectively is we use data then to validate the prediction. Ok, was it first time fix or not? And if it wasn't, the big thing is what we have to do, and this is where we need to rethink quite carefully about how we develop our software, because if first time fix is involved in that process for instance, I need to capture from the technician, if they can't fix it first time, why? I need them to answer that ‘why’ question. Because if they if we just get back a yes or no, and the yes no is easy. Was there another visit on that job or not? Fine, that may help us a little bit, but what I really want to know is if not, why not? I was missing part. I didn't have this and I didn't have the right skill set, the time that you sent me was stupid because they were about to close and I couldn't possibly finish the job. Whatever it might be, I need to get that information to close the loop more accurately than just a simple yes, no. And then I don't need as much data to be able to increase the reliability of the prediction.
    Q: Just a quick one on that. I mean in the past every company has worked with the drop downs for exactly answering ‘why not’. Basically, how do you see that going forward with this new model? I mean free text could theoretically be OK?
    A: It can, because now all of a sudden we can supplement drop down categorization with contextual information, if we can get the technicians to fill it in because I'm going to go back to the ‘I don't want so much form filling’, but that's a different problem altogether really. But then we can use semantic analysis to pick out from the text that's written or the narrative that's there, like codified contextual information. We can interpret the text into codified information, which can then close the loop for us. And that's a good example of IFS's AI approach actually being quite strong because I've got semantic analysis hidden away in my toolkit. I've got the learning models and the probability type analysis hidden away my architecture, and here I can join the two things together.
    F: And we can even have the technicians, even, I mean, voice to text. So he doesn't even need to fill it.
    R: Yeah, absolutely.
    F: But if you're talking about voice to text, please keep in mind we need that multilingual. The Chinese have to talk to the American as well as Africans to German.
    R: Exactly. And that's part of the multi X side of the other angle of what we're doing at the moment to.
  • Q: Something you mentioned, not today, but about the work going on with repair in IFS Cloud at the moment. Is that postponed due to all the other interesting and new stuff you we learned today?
    A: Postponed is possibly the wrong word.  There's a lot of activity that's going on in the background around repair. Let's just say there's a few gotchas that we've uncovered along the way that means there are some things that we need to put in place first to make sure we have a really good repair solution. One of those is parts planning and parts availability planning. I want us to hugely extend the insight window in part availability planning, so that when we have demand either through a sales order, through a warranty repair, through a warranty claim, through a service task, I want us to be able to say, OK, you haven't got this in stock, but you do have repairable items, and this is the repair lead time. So this is the lead time when that part could be made available again to you, and help our customers make buy versus repair decisions. That's kind of part of the sustainability drive that we have. Now, I could carry on and just plough on with a lot of the repair stuff now, but for me that's such a critical and important building block in having a really effective repair solution, I want us to focus on some of that kind of back end engine of material planning that exists, before I start building some of the repair stuff around it. So that I give you a greener repair solution. And try and make repair a completely integrated part of the service delivery process, which it never really was in any of the offers that we had. So, we're working on that first and then we'll put in the business workflows and everything else to do the repair. So, it's going to take a tiny bit longer than we hoped it would do, but I think the outcome will be massively better for everybody.
    R: OK, but that will be not only a repair or purchase solution. That will be as well a repair, we build a new one, or purchase solution.
    A: Yeah absolutely, buy versus build versus repair, if you like.
     
  • Q: I was curious when you talked APIs, so inbound sources of service traffic for us have largely shifted to Corrigo, ServiceNow. I mean, we're taking way less phone calls or emails and we're getting way more portal management going on and happens through the service life cycle all the way through accounting, and I haven't seen you guys yet play nice in that sandbox. Easy API integrations, is that somewhere on your horizon and where does that fit in?
    A: There are quite a few that we released in 23R1 for taking in work orders, taking in requests, taking in resources, and what you've got with IFS Cloud is almost like a 2 tier API strategy. You have every single function, every single screen, every single what they call projection in the application produces APIs. Those are the APIs which drive the clients that we have. So, they're not necessarily the best for integrating. They can be used to integrate too, but they're not necessarily the best, because they're transaction based and I think that's the main challenge that you guys have had using those transaction based APIs. And it means trying to Daisy chain things together or trying to reverse things if it fails later in the process is really quite hard when you're in that world. So, then we have the second tier of APIs which are what's called the premium APIs. Now premium APIs are guaranteed to be backwards compatible. Different API versioning, where is the normal API’s don't have the versioning against them. They are published schemas. They have full documentation and they are business process driven APIs rather than individual transaction driven APIs. And now that the data model in IFS Cloud for service is stable enough to be able to guarantee the backward compatibility, we are adding in APIs to cover every single business process and every single interaction point. So quite a few were done in 23R1. A few more have been done on 23R2 and we will continue to do them during 24 so that we've got full coverage of every touch point we need through the premium API process, not just the interaction API processes that we have today.

 

If you are an IFS Customer and would like to watch the recording and/or want a copy of the slides, please email jessica.foon@ifs.com

 

Next Meeting: 9 November 2023 10:00 AM US Eastern Time
IFS Service CollABorative - Think Tank Session TBD

 

 

If you are an IFS Customer and you would like to join the CollABoratives, please click here to fill out the form

 

Did this topic help you find an answer to your question?

0 replies

Be the first to reply!

Reply


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings