IFS Service CollABorative: Tech Talk - PSO Super User Success Factors w/ Cubic Transportation and Konica Minolta

Date of Meeting: 18 February 2025 10:00 AM US Eastern Standard Time

A Conversation between Sarah, Mike and Ged

• [Sarah] Today we are talking about PSO (planning, scheduling and optimization) tool. I have two guest speakers today who are going to talk a bit about their use case, what they've accomplished with PSO and most importantly what they feel the success factors are to leveraging PSO to its full extent, getting the value out of it, that companies aim to, etcetera.
• We will hear from two guests and then we'll open it up for conversation as we always do. Some of you maybe are also PSO users and would like to get a little bit of insight on how different organizations are using the tool. Others may be considering PSO and just want to understand better, what it means, how it's used, what goes into it, etcetera. Mike and Ged are going to allow you to pick their brains, whatever is on your mind, you can ask. I will speak for them and say I can't promise they'll have answers. We can't have unrealistic expectations, but certainly ask any questions you'd like. If there's anything that comes up that they don't have insight into or we need to follow up on, we can certainly do that.
• I'm going to ask you to start Mr. Mike Gosling. Mike is with Cubic Transportation Systems and Mike, if you can just share a bit about Cubic's use case, what you've been able to achieve with PSO and then what you would say are the SuccessFactors?
• [Mike] Sure. Hello everyone. Some of you may well have heard me talk about this before, because I've spoken about this on several occasions at several forums and things. This might not be new to some of you, but it's still the topic that really excites me. It's one of the tools that really has brought some business bang to Cubic the way that we do our service operation. We are responsible for the transportation systems around the world, mass transit revenue. We do ticket systems in Manhattan, Vancouver and Sydney, Australia. Our biggest European customer is Transport for London. We do the entire system in London. Everything from buses, rail, tube, you name it, the whole lot. And we host the whole system.
• We don't just do the machines themselves, we do the whole system. And the contract that we have with Transport for London isn't that we sell them ticket machines and gates and things like that, we guarantee hours of service. So, every station will have a number of validation devices and we guarantee the hours of those for the contractual period and our penalties for failing to hit those hours are extremely high from a financial point of view because they don't expect them to fail. They expect a patron to be able to travel the network and have a fully seamless, wonderful experience the whole time, which means that we're highly penalised.
• One of the other factors that we have is our equipment out in the public domain. So, if one of our bits of kits is damaged or catches fire or gets struck by lightning or whatever happens to it, we obviously can't let people get hurt and put a risk to public, so we have extremely high, tight health and safety SLA’s.
• Now we actually went to PSO prior to the contract becoming outcome based. But we knew we had an inkling that we would head in that way and we wanted to get fit for business. So, we implemented PSO, basically to do the corrective maintenance management of our field service around the UK and Europe. We wanted to be able to utilize the same amount of engineers and grow the business and not have to throw resources at contracts. And with outcome based contracts, when you've got 250 odd stations, we didn't want to have resources hanging around at each stations to guarantee it. That's just the most stupid thing of doing, but we wanted to be able to box clever with the resources we had to make sure that we were able to meet the contract by using this tight set of resources as possible and also be able to grow the business.
• So PSO was implemented, and it is largely corrective maintenance. The SLAs are chosen by the impact of the job. So, if it is a P1 safety critical, then we've got a 45-minute resolution on those. And it drives those resolutions. And it will automatically allocate to sign pass down to the field engineer’s mobile comms automatically and off they go. And those ones are high value, high return. They'll throw in front of everything. They'll battle their way in. And then we have the bell curve of the middle ones, which is the heavy lifting ones, which are the normal jobs. An incident or a fault etcetera.
• And at the other end, we have the real exception management, really strange ones that come out of the blue that everyone has to deal with, and the system will assign the priorities those. But they're the ones that we have eyes on the bells and whistles and things go. It's proven to be extremely effective in Cubic because since we implemented it, we have been able to grow the business we've taken on more contracts around the UK. If you were to look at where we were from an engineering point of view before PSO, and then estimate how many we'd need on the same platform. We'd probably have four or five times the amount of engineers had we run the same model. As it happens, we've only got about 25 extra engineers in total. So it’s 225 in total across the whole board. And that's because PSO does the heavy lifting for us. It does that hard work for us. It does that driving of SLAs for us, and keeps our contractual outcome tightened. So, from an impact point of view, it's growing the business is achieving our SLAs, it's doing that heavy lifting which means that we can manage exceptions extremely well. And exceptions aren't lost, jobs aren't lost because PSO won't let them go. It will keep on persisting jobs and they'll get more important. So, therefore we're keeping our customer satisfaction high because we're not forgetting about jobs and things like that.
• And finally, I think the other thing is the successes that our customers value the use of it and ask us to demonstrate it on their behalf to other people. So, it's become a tool that shows that we are already choosing tools that have embedded AI. Using tools that we are prepared to take gambles on, if you like, because a lot of people are nervous about that sort of technology. So it's there's no hard currency thing to say. It gave us the 20% improvement in pounds and things like that. It's very much the fact that we are much operationally slicker, achieving our targets and reputation are using a tool that's proven to be very powerful.
• [Sarah] Excellent. One of the points I remember, Mike from one of our earlier conversations is with the pressure you got from Transport for London to move to outcomes. You were right in knowing that ultimately, it would be impossible to keep pace with that if you were just basing it on manpower, right? You really had to figure out what is out there that can help us. Work smarter, essentially, and get ahead of the stuff.
• Can you talk about what would you say are the SuccessFactors? For your organization, what was it that you had to do or understand, learn to make your use of PSO as effective as it has been?
• [Mike] The SuccessFactors. Number one was that we wanted to go on a journey. We knew that we had a flabby service team, and that sounds a horrible thing to say because everyone's doing a great job. But it's just that there was embedded bureaucracy within it, that was to do with voice interfaces, that was to do with people making decisions, that was to do with whiteboards and to do with all sorts of things. And we knew that we wanted to remove that embedded bureaucracy that occurs within managing an incident. And so key some of the key factors for that are the automation of incidents being logged, the managing of mobile comms installation and then the final key, the one that brought all those together was dynamic scheduling. And we knew because we already suffered prior to the outcome. We suffered with the importance of health and safety. But we knew it had to be dynamic and it had to seamlessly go to our field service engineers.
• When we implemented the system, one of the key things we were looking for was that we did remove that bureaucracy. You can measure it by the number of phone calls just collapsed, because there was no more voice interface. We looked at the fact, were we achieving our SLAs. Well, we improved on our SLAs by around about 30% in the first few periods. Were we able to start managing exceptions where previously we were parking them and so customer satisfaction. So yes, we were able to start doing those. The best thing I can say is was that when TFL (Transport For London) said right, we're going to go to this outcome, they thought, oh, how are Cubic going to handle it? Well, as it happens, it was almost like we were we were match fit, ready to go. We adopted their new contract. We plugged it in, and we hit the ground running and that I think is probably the biggest success is that there was no hiccups, there were no backward steps. There was no reputational impact. We hit the ground running because we had the tool set ready to go.
• [Sarah] Yeah, exactly. So, PSO is a AI powered tool. It's self-learning. And you've spoken before about it, it can take time, particularly when you are moving from a manual environment where people had a lot of control over how things happened. It can take time to trust the system. So, can you speak about the importance of you have these criteria that you're committed to, but also letting the tool do its thing without intervening initially so that you can let it work the way it needs to work?
• [Mike] Absolutely. So, one of the things that we also decided on was that the system allows you to manually override if needed. And I didn't want to turn it off completely and not allow that, because everyone has exceptions. Everyone you know has meteor strikes. I hope not everyone has meteor strikes, but anyway. And because of that, we didn’t turn it off. But when we went live, I was again the person in the room saying no, don't touch it. Do not touch it. Do not manually play with it. And also if someone said oh, I think that SLA is wrong or that one there's wrong, and there were some wrong, it was, let's not absolutely change it on the hoof. Let's take a look. Let's snapshot that one for modelling. Let's put it into our continuous improvement touchpoint, which to start with was two weeks and we'll assess it then we're looking at the data, and then we'll make a change then. But if we do anything on the hoof because it's AI and because it's learning and constantly adapting, we will be shooting ourselves in the foot. And we were pretty tough about it. There will be people problems introduced like this. These are the biggest single problems you’ll have. Because no one likes to be told how to do their job or to do a job better than they are perceived to do by a system. I was standing the room saying, oh, I think that job should be high priority. And I said no, leave it. OK, take a snapshot, make a note, put on the backlog. We'll do an assessment. Therefore, we had proper consistent learned data from the system learning how to improve itself, how to model rather than oh, someone changed it on the hoof and it's throwing all the results out the window. And that was a tough few weeks doing continuous improvement. Going through, that's actually rubbish. That's just hearsay. That's Joe Bloggs thinking that he knows better. That's Fred Smith wanting to go to his favourite cafe at lunch. Ignore that one. Oh, that's a valid one. That SLA is completely right. Make the change. Understand the change. Apply it and that was hard work, but it meant that the system was allowed to breathe, grow, learn, adapt. I've often said before the system honestly looks like it's bored sometimes if it's a quiet day, it almost has a personality. It's like, oh, it's bored. When it's busy, you can see excited, jumping around, leaping, moving jobs around, and it seems to come alive. And we wanted it to come alive. And so those first few periods have been quite tough and letting the system breathe, and only making considered changes during those continuous improvements was quite important.
• [Sarah] You can also get yourself in trouble by not letting the tool you've invested in to do what it does do what it does, without just giving it the space, reflecting, giving it the space, reflecting. So there's hopefully some good learnings in there in terms of needing to be the bad guy. Someone has to be the gatekeeper of what is happening, when and how, or it will just get unruly and you will find yourself in a situation where you're not getting anywhere because there's too many cooks in the kitchen, if you will.
• Mr. Ged cranny, with Konica Minolta. Ged, if you can do sort of the same thing Mike just did talk a little bit about the use case. What you've accomplished and then your thoughts on the SuccessFactors and then we can take some more questions and chat a bit more.
• [Ged] Yeah, just before I start, I learned from Mike every time I listen to him. And part of our project, I bumped into Mike before we had our first launch and I took from him some really good feedback and that is, be that person in the room that everybody hates, and be prepared to be it.  Because AI brings change to your businesses. And if you're going to bring it to your business, be prepared for that change because unless you use it, it'll fight you. And I've got some examples that I learnt today so I can share later.
• I work for Konica Minolta for 40 odd years, I was in charge of field service. Everything from an engineer regional manager to running the UK and having the PNL for the UK, as well as the responsibility for all of the calls, and everything that sales did wrong or every time a customer complained, it was my fault. So, I the title at the end of my name, “I'm to blame”. I carried that into my job for the last five years, which has been supporting people like me in our national operating companies. If I use the word NOC, please forgive me. It's our acronym for National Operating Company. And speaking to these people, as we change from being a field centric organization to being a remote first using our IoT to analyse and start to predict calls. Using our field service knowledge and building the knowledge base to allow customers to use it, because we are definitely seening three or four types of customers. The customers who want to make a telephone call and talk to people right down to the people who just want to self-fix. They don't want to do anything else. And I think over the 40 years that I've been in field service, I can say that people have gone from that bit where they want to see an engineer, you called it outcome based, Mike. I call it uptime. They buy something to use, and they're very, very used since the arrival of the smartphone and the tablet. B2B (Business-to-Business) used to run the changes in the world before that. Now it's B2C (Business-to-Consumer). It's the customer expectations of their home usage of their products that are driving business use and such like.
• So we went to this remote first and one of our targets was to get from our 100% of the incidents that were going to fail down to 20% and that's one of our targets to get to. We were already at 5% with our IT business, so we knew what we wanted to do. We set some new rules which was three reasons for a visit so instead of having the 70 different visit types, we were going to have three reasons, and the desks were really going to focus on this. Have we got it right yet? No, we're in transition. But part of that transition said that we had a scheduling tool, which was a pretty picture. I'll be perfectly honest, we have the schedulers in all of our different national operating companies. And what they did was they manually planned. So even though it would automatically plan through that the night, they would change the picture because engineers would ring us. Mike said this and engineers said we don't like going there, so we don't want to go there. Some of our national operating companies had a thing called self-directed work groups. So, the 1st Engineer awake takes the best jobs and then leaves the last engineer awake the worst jobs and the most travel and the horrible customers to deal with. Bringing in an automated system which we wanted to do was going to bring massive change, so moving away from self-directed work groups to one call at a time, the system looking at the SLA of the customer, looking at the penalties that the customer brings, looking at the outcomes and the types of incident and what the desks have put into the incident as priority. And send in the engineers where it felt was the best result for our customers.
• We started off by speaking to Gartner. We spoke to Gartner. They told us of our ideas were good. Someone told us some of our ideas were miscalculated and helped us to rethink some of our ideas. We made 400 questions and we went out to marketplace and saw 15 different vendors with these questions. We didn't give all 400 questions to the 15 vendors there was about 20 to 30 other questions were given as key questions. From that we got down to a certain number. It was five or six who got all 400 questions and had to tell us how they would deal with it. There was a caveat to that, which was at the end of the process, we would have a POC and in the POC they would actually show us all 400 steps throughout our processes. IFS we found to be the best product. It wasn't the cheapest and I work for a Japanese company, so I was surprised that it was the way forward for us. We launched and we launched into a knock national operating company which had the self-directed work groups.
• We saw a 28% improvement in productivity. We saw absolutely the system fly, SLAS being adhered to, improved and the consistency. And after two months, the NOC decided they wanted to turn it off because they hadn't done the key bit and I'll say this later on, your C-level will decide to follow your strategy. Your C-level will drive strategy and drive the products and the software's purchases to do this. If that's not delivered to your middle management and to your engineers and to your people on the ground so they understand what this means for them, because it means change. And we got that badly wrong and we were in the middle of pandemic. So, we were not allowed to travel, so everything was done by telephone and the work was done really, really well. We took six months to get to the first platform that we were able to deliver and put into the trial. And a bit we missed was the people bit. And I will say it later on. Culture will eat strategy for breakfast. And unless you've got that culture bit, sit down. Explain. Yep. Your life's going to change. Yep, you're going to do one call at a time. Yep, going to do this, some days, it's not going to be nice. But actually we're going to bring a consistency to your life. And that's what we've been doing over the time. We put in the system to replace a system that was going to be removed. We had a target to put 10 in. We've got to five of them in place at the present moment in time. We've had to bring self-directed work groups back in because we wanted to bring that first National Operating company back in. They're actually using it in a way where the system sets up and says to the teams this is the best one. This is the best way. And then they can mess about with it. Now something I've learnt today from what Mike was saying, but also from my understanding of some figures I've been putting together, one of the national rating companies that's doing this is actually showing negative figures against before we went live. So, the system's actually fighting their schedulers. It's a banned word to say that in our business because we have these things now called exception handlers. Because if the system's going to schedule, why would you have schedulers? You want people, as Mike said, who was sitting and looking for these exceptions and saying why did that happen? Instead of just manually jumping in and fixing the problem, try and keep the hands away from it and look for the productivity gains that this brings or the reason why that failed, because then what you will see is, you'll you fix a problem for today, but you'll also fix the problem for tomorrow, and the next time, and you might be fixing one 2% of your actual failings. We've seen in two of our NOCs we've seen a 30% improvement in the SLA achievement. A 25% improvement in our productivity. An €18,000 saving in in the fuel in the 12-13 months. 1.28 million saving in work time. Now that's where we save time because of consistency. Because of getting the call times right and because of the system pulling the call times in, we're not losing lost time. We're getting them extra calls in. It's how you use it. It could be just £1.28 million worth of wasted time if you wanted, but also 9800 grams of carbon saved just in the two NOCs that I was looking at. Now if I put the third NOC in, I actually see all of these numbers go down because of the fact that the third knock isn't doing their over planning and the systems fighting them. And so what's happening is you're getting this. Oh yeah, we are automatically planning, but actually we do 60% of it is manually planned or 80% of it is manually planned. We only send 20% to you too. It's going to it's going to lose.
• [Sarah] Ged, let me just say one thing. It's a very interesting case study within one company of the same tool, same capabilities, very different outcomes. This is where the consideration of the change that you're making to the business has to come into play. Because it isn't just about will it do what we wanted to do, or won't it? It will, but also there's things that have to be navigated from a change management perspective, changing workflows, all of those things. So, it's interesting. I see this, from one company's doing it this way and they're having great results and other companies struggling because they weren't prepared for the change or they weren't ready to navigate all of that. And it's interesting to see it in the same company.
• [Ged] I've got 27 different national operating companies that have got a veto. So, they've got a, we want to buy it, but they've also got a veto. So my team and the project team are there to deliver the software to align our softwares, to reduce the amount of different tools that we have within the business that makes the customer journey much easier to work with us as we as we turn from being field centric to remote first. And the difficulty is, everybody wants change and everybody understands change, until it's their turn. And when it's their turn and they start to realize that some of their longer serving members of their teams are going to get very upset because customer practice is going to change. That's one of the things and it brings me nicely. You asked me to give you some ideas for other people. And one of the ones I'll say again is your software that you buy is only an enabler to your strategy. So, make sure your strategy is right. Make sure everybody's buying into your strategy. Once you've got that strategy in place, unless you're just going to stand there still, which is a world I don't understand, then strategy is always going to bring change. It's always going to bring a 10%, a 20% expectation from your stakeholders for change. If you don't get the culture bit right, and I've already said it, it'll absolutely eat your strategy for breakfast. The number of people in the strategy area in your C-level and your senior management, they get it. They can see the five years ahead. But if you don't get the engineer in Falkirk in Scotland to get it, then it falls apart because they go on training courses and talk to each other. So win the hearts and minds of your people sit down and explain to them, yeah, you're going to change the lives, but actually we're going to make it so that it's going to get you home more consistently.
• [Sarah] Which is, it's a really good point Ged, that I just want to emphasize. It is imperative to win the hearts and minds, and it's because it doesn't take much effort to step back just a couple inches from this and think, yeah, you're taking a bunch of control away from them and no one likes that. It's human nature to not feel great about that. I mean it, there's resistance to change as human nature. But when someone's been able to call the shots for a long time, and now you're saying nope, now the tool is doing this, you can understand from a human perspective that doesn't feel good. So, you have to win the hearts and minds. But what you just said, Ged, is very important. Often where companies mess that up is, regurgitating business benefits to the employees that I'm not saying they don't care about the business, but that is impersonal, well you have to use this tool because we're going to increase productivity 25%, that's not going to matter to them. If anything, it might annoy them more. You have to be able to differentiate what audience are you speaking to. If you're speaking to the C-level and you're speaking to the decision making team about why it's important to invest in this, of course you're going to talk about the productivity. If you're speaking to the frontline and you need to influence the hearts and minds, you need to think about what is it that is in it for them. What do you need to convey about how it will benefit them. Or what impact it has that is relevant for them. You can't just regurgitate the company stuff because it's going to fall on deaf ears.
• [Ged] Absolutely. And the other thing is, is all your reporting's wrong. Obviously in our world everything was pointed at what field service did. How great was field service. Never even measured the desk performance. One of the first things we needed to put in place was let's measure the desk performance. How much can we see is being manually planned in the different systems that's blocking the new tool from working? And it's frightening, not just on the fact that certain national operating companies, I'll use one that I know really well, which is the UK, they've got rules in that takeaway 20% that automatically won't go get sent. Then you've got the people who were schedulers, they’re exception handlers now, but on the busy days when people are walking in and shouting or ringing up and saying my customers not happy because… They're jumping and making a change because the sick people shouting. So, you've got to protect your people, but also get the reporting right. So you can sit down and say right, OK, when the automatic tool gets the 50% of the jobs that you send without doing anything, 90% of the time, it gets it right. So we've got the algorithm right. We've seen this consistency. We've seen in job incidents, the SLA improvement, the customer satisfaction and funny enough, we've also seen engineers are getting home quicker, so you’re changing the narrative to the fact we're going to put something in that's going to make you one call at a time, it's going to make you do half a call more a day. We're going to give a tool here that's going to give you more flexibility. We're going to only give you one call, one customer to worry about. You worry about that customer. If once you're finished with that customer, we'll give you something to move on to the next customer. Have you noticed your consistency about going home? You are now getting home earlier than you used to get home, and you're doing actually more so your bonus has increased. It's a different story. It's a different set of reporting that you're doing with your people. But also, you can go back into your service desk people. So you're not just talking to the engineers, you're talking to the management teams, the middle management team about the how their performance is improved, and their area and their customer satisfaction, and the reporting they can give to their customers. And then you can go to C-level and start saying, do you know how much CO2 we saved so we can put that in our green box. Do you know how much time we've saved. I can give you an example of one of our NOCs where they've made huge savings and they've actually took the head count savings and move the people to their service desk so they move 10 people at the start of January from the field to the service desk, which was 8 or 9% of the actual team at that time. Straight onto the service desks so that they would start performing the right sort of work and because of the longer serving people who are getting closer to retirement, they are also now starting to build the knowledge bases that we've been wanting them to do because they’re sat at the desks or the sat in their homes being able to work. But it's also given that longevity of work. The life of a field service engineer is a hard job.
• And one last thing. Remove the word scheduler from your business. I think I've said it three or four times. It's got to be a banned word. Somebody said it in a meeting 20 minutes after we kicked off and I actually stopped them and said, you've just used a swear word in our meeting. He was new to the meeting and he burst up laughing and said yeah, I've heard you say it before in the background, in our national operating company, but that's what I would say if you wanted ideas for other people.
• [Sarah] Yeah, that's wonderful. Ged, when you were talking about winning the hearts and minds and needing to change what you're looking at in your reporting, it brings me to a thought. It's interesting when I talk with service leaders about what are their biggest business objectives right now, and how are they measuring frontline workforce performance. Often these objectives have changed significantly, but the KPI’s they’re measuring their frontline workforce on, haven't been changed in who knows how long. It's another lever to look at. Are we aligned here, if the incorporation of this tool and in your case Ged, the remote first strategy is imperative to us as a business, are we incentivizing our employees to care about that stuff, or are we still just looking at their KPI of on time performance, which they can control just as easily on their own as they can with the use of the tool. So often times, those field service KPI’s are not correlated to what we are saying matters most to the business.
• What came to mind when you were talking about eliminating the word scheduler. And instead, you call it an exception manager. This is a very interesting example of the implication that AI is going to continue to have in businesses, in this area, but others. There are job historical jobs that are going to be replaced. I'm not saying we get rid of all of those people, but what is the new role that we need them to play in the business? Do they understand that role? Are they able to do that role? Do we need to upskill them in any way? And do they understand the connotation of continuing to identify themselves as a scheduler, when in reality that role is becoming an AI role. I guess I'm getting probably a little bit hypothetical here, but I think it's interesting to think about how that will continue to happen. What are the aspects of work in the service organization that can and likely will be replaced by AI. And how do we start thinking about the ways those people will be redeployed toward valuable work.
• [Ged] I listen to one of your podcasts the other day and you were talking about your fun with the airlines, and the fact that they had a fantastic app, but when you actually have to talk to people, it's a problem. And the problem is that you've redeployed all your people or you've took the savings and you've got the app. So, when everything goes wrong, you're in crisis. Now it got me to think about the fact that we have these things called fire marshals when people used to go into the offices, and we used to have these like crisis teams that would come together when something went wrong in the business. And these people were super motivated and because it was classed as a special team in a crisis, they were trained to be effective with whatever this crisis was. I'll use the fire marshals because they were clearing the building and making sure everybody was safe to get out. And they did the trainings for this, and it made me think. One of the things we need to do as we redeploy people into other areas is we keep them skills and we keep them in an emergency team and it's something that whet buzzing around my head all week, which is we need to have that special teams. So when things goes wrong and the app can’t answer the questions because the questions are more complex. I.e. One of the questions that you guys were talking about was, do I go from the north of Paris to the South of Paris? Can I cash it in and stop my trip. How do I get compensation? And that's where you want people who are empathetic, and they want people who are really enthused And that's where it came to me. One of these things we've got to do with the people is give them that. Yeah, we're moving you into another job, but actually the job is exciting enough, because you've got the customer skills and we want you to be there. But also we want you to be part of our crisis team. So when our app doesn't work or when our AI goes down and we have to go back to planning, all systems will go down at some point, we're able to do that seamlessly and it was your podcast that gave me that idea the other day.

Questions / Answers / Feedback / Responses:

• Q: I was just wondering how much effort. How much resources? How much time? You name it, went into setting it up? Because we were in this exercise at the moment. And of course you can very quickly over engineer this to the very nitty gritty detail of skill levels of visas, of languages of you name it, but where do you draw the line to be operational and don't over engineered?
• A: So that's really good question. There's two things there that happened really early on in our engagement with the tool, with the user, with the IFS people and that was one of them said, do you really understand your contract and your jobs and how they affect each other and how they influence each other? And if you know that, then you setting the system up becomes a lot easier. And that was almost like a water cooler chat we were having with them.
• And the second one was, the system will handle soft constraints, flavours of skill, flavours of that. But if you can try to do everything as you can on hard constraints, then also the system's a lot better and easier and better to configure. And then you can springboard off that. So, while we were even selecting the tools that those two things played in my mind. And I started to list out our hard constraints. So, for example, skills we said, do we know for confidence our engineer has a hard skill of that, and that he's not like, oh, he's a really good, he's a grade one skill of that and grade five it was. No, let's give the engineers hard skills. So, we started working on the skills and the tools and things like that and they become hard constraints. Meanwhile, we actually did start looking at all of our jobs that we get, all of the service impact of them, how they related to others, how they related to other contracts and that was quite a bit of work and that involved quite a few people. How does it how does a job on that ticket machine at that station on that part of the contract, how does it relate to that one? Do they have to be the same? Can they be different? What's the impact? And because of that, when it came to set the system up, we knew that that one there, ideally should be done in this constraint, that time etcetera. So, we were able to build our SLA curves pretty quickly based on that really in depth. Now that did take quite a while, but it was happening while we were selecting stuff. It probably took two months of getting that data, was quite a big spreadsheet of hundreds of jobs. P1s, P2s, P3s, P4s, gates, all the different types, all how they balanced.
• And then meanwhile, we had a comprehensive list of skills, and it meant that an engineer could have 50 skills. But they were hard skills. There was no flavours of them. And as a result, when we plugged it in and an activity came through, and it matched it to the criteria we thought about and it gave it the SLA, the very first time we model data, it made sense. The very first time we looked at a PSO plan, it was like, oh, do you know what, that makes sense. That's what we were thinking it would do. Yes, that is more important than that one because we've done that hard work.
• Q: So, you say it's lots of work up front, but worth it?
• A: Yeah, but that meant the implementation was really quite quick because you can get data in the system really quickly if you understand that its activities, resources, that sort of constraints and if you put the little bit of effort in, understanding that when it came to plugging it in, we were able to get raw data in pretty quickly, and then we were able to get a raw plan in within only a few weeks and that raw plan in a modelling sense was like blimey, that's pretty good. That gave the whole steering group and all of our stakeholders a lot of confidence in the system. Seeing that plan was kind of recognisable and made sense. And then from that, we wrote the springboard off and people got more engaged and that sort of stuff.
• R: I think what else is interesting, is the timing of how everything came together for Cubic. Because you were already down the path of investing in PSO when you had the move to outcomes. The other thing that can get tough, is when organizations are in transition, or maybe don't even realize that they're in transition from almost like a business transformation perspective, because that obviously effects then the service delivery. So that's another thing that can confuse the process of just getting this up and running is how much within the business process do you also want to change? Is it just putting in the tool or are you also making other changes that you need to consider simultaneously. So those things all play a role and for Cubic, it was just honestly a serendipitous timing of everything to come together. Not that that made it easy, but Mike, you and your team kind of knew, here's the capabilities, here's what the demands are so we know we need to get all of our data aligned to these objectives.
• A: Yeah. You're absolutely right. That's interesting, because we were laser focused on what we wanted to achieve, and we didn't let anyone scope creep onto our success criteria. Our success criteria was very clear. It was to start utilising our engineers as more efficiently than they were, more SLA driven. We had a very, very set of tight SLAs and they didn't really affect the actual overall process of managing the service incident. The managing of it, we didn't really touch. It was the how do we get our resources better aligned to the contract when it comes to scheduling and resourcing, which is what PSO does. And if anyone came along and said, oh, we have you considered this? Nope, I'd be the bad man in the room. I'd be the one to get shouted out. I'd be Nope. And we were laser focused and we did not allow any of that scope creep to come into it.
• R: Yeah. And that goes back to your question. You have to have those very clear initial objectives. That's how you prevent that over engineering initially. You can always come back to it, right? Once you've accomplished whatever those initial objectives are, then you can start to say, ok, what else can we do? What else do we want to factor in. How else can we leverage this? But if you try and do it all upfront, you're never going to get to the point of, like Mike said, the business bang. Because you're just going to keep planning and planning.
• A: Yeah. And what's quite interesting is that the moment the system started to bed down, most of what was asked for beforehand fell away because the system started doing it. Because it was doing it. Because it was doing it and everyone was like, oh, OK, I can now understand the system. And day 2, 3, 4 became much more targeted about the capabilities of what it can bring us as a system to the business, rather than a wish list of what they thought it could do.

• Q: We have field technicians, we have engineers, we have shop technicians that do manufacturing and we have some people that do a little bit of everything to help each other out, and that is one of our biggest challenges. Can you mix the different modules? Is it easy to set up? Is that a challenge or concern?
• A: I know this sounds a bit simplistic, but as long as you have activities defined and you have your resources clearly defined, you can mix them. And it does go down to something I was saying earlier about the constraints and how you set the constraints up. So you might have someone that's an engineer and a technician but not a field service tech, and then you might have a field service tech that can also be an engineer. As long as you put those skills in and the activities match up to those properly, then it will point to the right one. But it does sound like you will have a change management issue that Ged talked about. It’s managing the different roles and how you do it and all that. But absolutely the system can mix it.
• F: Perfect. Thank you so much because. I really love the culture eats strategy for breakfast. I wrote that down, Ged. Thank you both.
  R: There's a podcast coming out tomorrow with EDF Energy in the UK and it's really interesting because the conversation really is centered around some of the bits that are interesting and unique to nuclear energy and the regulatory issues and things like that. But what they ended up doing, is creating a pooled resource business. The way they did it is specific to what their needs were. But we do talk about how the communication on both ends. Why is this helpful to the employees in giving them more career longevity, more stability. Being able to make sure that they are secure in their work for a longer term, and then once the benefit to the businesses or the licensees in this, in this case which is being able to have the resources they need when they need them, being able to better plan for variations in workload and stuff like that. And I think it's interesting to think about. There might be some things in there that could be helpful to you. We talk a bit at the end about how this could apply to more of a commercial environment versus the energy space. But it was a very interesting conversation.

• Q: Thanks for some nice insights. I got a question more related to the tool. I understood that when comes to the intelligence scheduling you guys were talking a lot about SLAs and some planned services? How do you feel the tool handles last minute changes? Things that we might not control ourselves because there's a lot of things that we have under control like the skills and the resources and spare parts and so on. But, there's also a customer. So, how do you feel when it comes to the last-minute changes, the ripple effects it has on other services. Is that where you have your exception manager intervene or is it also something that you feel the tool handles in a good way?
• A: 65% of work, we took out planned maintenance as much as possible since 2017, 2018. It was work that was just reducing up time. So, what we did was we've used the IoT so that we get the information at the right time. So, 65% of the work that comes into our organisations is in day. It comes with two and four hour response times in the UK and it disrupts the day. It creates a plan. Something changes between 8:30 AM and 11 is where about 70-75% of all the work for the day, the break fix will come. So, it's replanning. So, what it started off in the morning, very, very quickly starts to change and that's why we give one call at a time to the engineers. Tell the engineer to worry about that one customer. Once the system starts to overload, it starts to throw the exceptions. Now, whether that's because we've got capacity issues that some we have to deal with externally, but we might have to make some changes with priority customers. But the system does a lot of that work for you, and the more you leave it alone the more it learns, the better it gets at doing those sort of the days.
• A: And I'd like to back that up. That's almost the answer I'd give. It seems to enjoy that strange situation, if that makes sense. I said to you earlier, the system gets bored if it's like plodding along. It seems to really enjoy when it gets flooded with jobs or something strange happens. It would normally derail a business when you get like a whole station down and 1000 extra incidents, but this seems to gobble it up, and that's when it really comes into its fore because it adapts to the plan. It's always trying to do it and you can actually watch it continually trying to improve the plan, improve the plan and all that. And if you do it one job at a time, it will say well, I might give all of these to this one person because it's fine within the SLA. If it can't, it might give it to 20 engineers, but it'll do it. It flexes and adapts to exactly that situation. And because of our job, the system is really for us, mostly corrective maintenance, real time, corrective maintenance and very little planning. I just had a quick look at the background and it seems quite bored today.
• R: I think the value proposition of PSO is strongest in a very dynamic environment. It can be used in other ways, but for a lot of businesses, if it's a very stable and it's just executing planned work, it's just not going to be used to its full extent. So, in some instances, that would make it probably too expensive for people in other instances, it's just not going to be doing as much as it can, so it is really good at navigating and really quickly redistributing things to accommodate things that are coming in real time.

Podcasts:

• Balancing the Opportunity and Risk of Automating Service – Future of Field Service
• Are Shared Resources the Future of Service? – Future of Field Service

Next CollABoratives: 

• 11 March 2025 11:00 AM US ET / 15:00 GMT / 16:00 CET
  IFS Assets CollABorative: Tech Talk: Road Map Session
   
• 13 March 2025 10:00 AM US ET / 14:00 GMT / 15:00 CET
  IFS Digitalization CollABorative: Meet the Member - Journey to IFS Cloud w/ Chris Rundell, Covia
   
• 19 March 2025 10:00 AM US ET / 14:00 GMT / 15:00 CET
  IFS Service CollABorative: Think Tank - Change Management with Alfa Laval
   

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