 Live from Boston, Massachusetts, it's theCUBE, covering IFS World Conference 2019, brought to you by IFS. We're back at the Heinz Convention Center in Boston. This is theCUBE, the leader in live tech coverage, and this is our coverage of IFS World 2019. Matt Smith is here. He's the global chief architect. Paul Gillan and I are happy to have you on, Matt. Great to see you. It's a pleasure to be here. Thanks very much for having me. You're welcome. So business value engineering is a concept that you're a fan of and one that you've sort of promoted and evolved. What is business value engineering? So business value engineering is quite a common term in the industry, but here at IFS it's a little different. Fundamentally it's a collaborative process that we use working with our customers and our partners to make sure that what we do with those customers delivers financial value to their business. So it's fundamentally about making sure what we deliver delivers value. So I want to ask you a question about this because your philosophy as a company seems to be that let the customer define value. It's in their terms, not your terms, not trying to impose a value equation on them. At the same time, it's nice to be able to compare across companies or industries and firm level and so forth. So how do you sort of reconcile that? Is it like balance scorecard is sort of, hey, you can tailor it to yourself versus some kind of rigid methodology. How do those two worlds meet in BVE? Yeah, so obviously benchmarking across industry is really important and there are lots of people that do that kind of work and that's part of business value engineering. Fundamentally it's about mutual collaboration. So it's not just about using the customer's framework or their language, it's about agreeing the language. One of the challenges when you're trying to build a business relationship with one or more parties is you have to have a common shared understanding, a common vision, a common value system so that when I say something to you it means the same thing when you say it to me. So part of that collaborative process requires that you work together and business value engineering facilitates that. It's not just about producing a business case. It's really more about the process and steps that you go through to get to that business case that allows you to establish trust and understanding and clarity. How does this enter into the customer discussion? So it enters as early as you can possibly make it enter. So right at the beginning you ask the very first question which is fundamentally what are the business initiatives that you're trying to achieve with this potential change program? And then you have a deep discussion about what they mean. So you understand and they understand and everybody really agrees firmly what we're trying to achieve before you get anywhere near solution. And it's really difficult as technical people, I've got a technical background to stop yourself from hearing a problem and going I've got a solution for that. And it puts that more disciplined approach to make sure that you don't straight away go to solution to help you really understand where you're going, how you're going to get there and therefore what the financial benefits and metrics would be to do it. Who are the ideal stakeholders when you're doing a collaboration like this in terms of getting them involved and getting their input? So you might expect the answer to be C level executives and of course they're important from a leadership and a direction perspective, but as it turns out from a human psychological behavior perspective, there are three personality types that are really, really suitable for this kind of engagement work that's focused around change. And if you find those three personality types and they're quite well understood types of people, they're the ones that tend to cause change to happen and more successfully. Doesn't mean they're any more valuable than anybody else inside an organization but they are the right kinds of people to establish this sort of work with. And it's important you have the right number of those people in a change program. So change agents, so I would think like a P and L manager who's, he or she's controlling a big portion of the budget and has thousands of people working for them would be important, maybe not a C level executive but a line of business executive that's sort of the field general. Could that be an example of a change agent or not necessarily because they're trying to protect their turf? So not necessarily, right? When it comes to change, change is always hard. In any company you've ever been in it, all of our careers change is difficult, right? Wake up in the morning, let's change. Yeah, nobody does that, right? So it's more about who are the people that lay the groundwork for that change that you follow, you listen to, the influencers. Now of course you'll have people that own the budget, the financial controllers and absolutely they're important, of course they are. But they may not be the personality type that causes change to happen. Business value engineering is about making sure you harness the right talent, the right skills, the right people at the right time to help organizations realize the benefit of change. If you'll excuse me, this does not seem like a typical role for a software company to take on. Change management, how do you, why do you put yourself in that role? I think this is something that all software companies are gonna have to do and you'll see the subject of business value engineering in many software vendors now. It's true, it's a fine line between being a business analyst and being a software vendor. You know, we're a software provider. I think software providers that don't deliver the context and the value that they are trying to achieve with the software they buy in the customers are poorer suppliers because they're just trying to push technology. And it's fun, technologies like myself enjoy the technology and I'd buy technology all day long. But is it really the right thing to do? So I think it's about being morally right. You have to take a high ground and conduct that engagement in a way which in some cases, and this has certainly been true in my career, you do the business value work and you realize that you probably shouldn't do the project and you have to have that fortitude to say to the customer, this is actually not a great idea because the financial case doesn't support this. And I think it's taking that moral high ground is a really important stance. And software companies that do that, generally those customers will come back to you in a future time when they've got a different problem that perhaps does fit you. So I think it's about recognizing there's both a short and medium and a long-term engagement with the customers that you have to maintain. Man, in 2019, given all the discussion on data, digital transformation, AI, cloud, I would think that data plays a crucial role in these discussions. So what role does data play? Do companies understand the importance of data as it relates to the business value discussion? Absolutely, I think that data-driven decision-making is pretty fundamental. A lot of people say the numbers don't lie. Maybe some statistics might be bent, but numbers don't really lie. So you've got to be able to capture numbers and make decisions based on those numbers. So one of the difficulties, though, is that for many, many years in many industries, we've been using very simple terminology and simple mathematical calculations to do these value calculations. Everybody's aware of years ago the software industry was awash with phrases like return on investment calculators. ROI, NPV, IRR, break-even. Some of those numbers are valid, right? Yeah, for a business case, for sure. For sure, but just sticking with simple things like ROI is not enough. Well, it's valid if you treat the software as an asset, as an expense, essentially. Yeah, yeah, absolutely. But then it comes to the engagements more than just software. I like to think, as a human being, the software is considerably less than half the game in any change program where you're trying to achieve value. The people, the human beings that are gonna do the work are the ones that are gonna generate the value. The software is a tool that you use, a very important tool, but it's a tool. So you have to think about how do you build teams that can collaborate around value, achieve the value, measure the value, capture that data, but at the same time, physically collaborate properly to do the work. So how have you applied this methodology for your customers? So we've done a number of things. So we've established a practice inside IFS. We've made sure that every country has the capability to do business value engineering. We've hired some specialists, people who do this for a living, and we are working with lots and lots of customers now on this as a more methodical, disciplined approach. But we've also recognized that we needed to measure our existing customers' benefits. So what did our existing customer base achieve with our software? So we commissioned a pretty big and important study and that was anonymous. We weren't involved other than inviting the company to go and do this work and then unleashing them on our customer base for six months across all industries, all products, and asking them to go and find out and measure what our customers really achieve with the software. So how was that anonymous? How anonymous in that you weren't doing the survey? We weren't doing the survey and any numbers that came back were anonymous. So we couldn't say, oh, it was this company that gave this feedback with these numbers. So it gave them a sense of freedom to be able to express and share that data. And so you were specifically asking about the business impact of IFS software throughout some kind of life cycle, like a before and an after. Yes, exactly. As is in a 2B or what happened. Okay, so what did you find? So there's a couple of surprises in the results, actually. So firstly- Well, can you tell us who did the study or is that- Yeah, so the study, that's a good question because the choices are many. There's a lot of analyst firms out there that you could use. All do this sort of work and do it very well. The team that I worked with, we'd personally had a previous relationship with IDC. Now, we really liked IDC and I've done some of this work previously with IDC because they are more, they're an analyst that has more statisticians as well as analysts. So they take a really very methodical mathematical approach. And as a scientist, I very much appreciated that. So we picked them to do this work and they take it really very, very seriously. And there were a lot of strict processes they have for how we are allowed to engage with them and talk to them during this process. And that rigor, I think, allows us to be comfortable with the numbers and for our customers to be comfortable with the numbers that they obtain because of this anonymity and the rigor they put behind it. That's why we picked IDC to do the work. In terms of what we found, well, they found and we now just see the report. And our customers can go and see this report. We published it last week. So just going to freely download and look at the material from IDC. The first thing that was interesting about the study was human productivity focused. So not things like how much inventory you hold in supply chain and was it reduced. It was more about how did the workers get on? What kind of mistakes did they make? Are they faster during their work, more successful? And they looked at lots of different categories and the returns, the improvements range from just a 10% improvement. So not a huge improvement, all the way up to a 94% improvement in productivity, human productivity. If you averaged it all out, it worked out at just shy of 19%. So 18 and a bit percent productivity improvement across all of the different teams from the finance function, the supply chain function, human resource function, sales team productivity function. So we saw a range. What was good was it pretty much didn't matter which category of customer or size of customer or industry. They all saw pretty similar productivity improvements, which means we can extrapolate the numbers. The second thing we saw, which was a surprise, a very pleasant surprise, was that usually when you see these kinds of benefit studies, most of the value is in cost saving and only cost saving. That tends to be where asset management, resource planning, service management happens. Just under half of the value that the IDC study showed was net new revenue. So customers were finding that nearly half of the benefit was new money coming to the company, top line benefit. That's a little unusual. So let me probe at that. So productivity, when you're saying productivity, I think revenue per employee is a simplest measure of productivity, then you're saying there was incremental revenue as well. Independent. First of all, is revenue per employee the right measure? Or was it more like doing things faster or sort of more generic measurements and specific to a task? Or was it kind of boiled down to a revenue per employee? And then how did that relate to the incremental revenue? You have to follow my question. Yeah, I do. It was done by function, by team type. So if you look to finance and auditing and human resources and supply chain and so on, so that the metrics that you'll see in the white paper are specific to the teams. So specific to that role. Specific to that role. And you're not really big in insurance, but a claims adjuster could get more claims done in an AA or something like that would be an example. So you'd find, for example, one of the statistics was around field service engineering and how many jobs per day they can do. So it was reasonably specific. And they would attribute that directly to your software, correct? As a result of installing IFS, how much would you increase your et cetera per day? Yeah, and that's why it took them six months to do the study. I mean, this is quite an in-depth piece of work. And how many customers did they interview? So it was across, and we gave them a challenge to do this. So it was a set of about 17 fairly large customers, which sounds like a small number, but when you do these kinds of studies. That's a totally legitimate number. And then, I mean, these are in-depth surveys. So it's not trivial. And then as well, revenue increases. Specific to the software. So that would have been what? Like cohort sales or service, follow-on sales, things of that nature. Yeah, absolutely. And that's why we were so delighted with the report when it came back, because it was a really nice, pleasant finding. So most companies that, well, all the companies reported that the revenue increased, but some were bigger than others. On average, it was a pretty sizable chunk, nearly half of all of the benefit. And when we asked IDC, well, can you give us some kind of glimpse as to why that we see such a large chunk of improved revenue. IDC said, well, you're improving the productivity of the sales teams so they can quote faster. There's more accuracy in those quotes. The service quality is improved. The speed and to get a product to market is faster. So their ability to respond to bids and tenders is better. So it's actually a combination of lots of things, speed, error, quality improvements that led to their ability to bid and win faster and better business. Net new revenue. Did you attempt to factor in less tangible factors such as customer satisfaction, net promoter score, perceived value, customer perceived value? So the focus of the study was human productivity. And it's something that IDC do particularly well. And that's what we gave them as a target. Obviously, when we're doing business value engineering, you then have to take way more than just things like the benchmark data you'd find from a study like IDC have conducted, where you take into account those soft factors and other factors outside of human productivity. So value engineering is way more than just human productivity, which is why it's an engagement model. It's something you have to do mutually together. That kind of transparency really is what most customers are now demanding. You know, I'm not buying technology unless I know what business outcome I'm going to obtain from this. It's just the way of the world these days. Good takeaway that so it's not just your software, it's not just operational impact in nature. It's more strategic. It has productivity impacts, revenue impacts, and obviously cost savings as well. I'm sure it was in there. Oh, well congratulations. That's good. Appreciate it. How did we get this study? How do people find it? You said customers can download it. Can anybody download it? Anybody can download this, yeah. So we've published it on our website. It's very easy to find, and it's freely available. We obviously have to comply with IDC's. They own the rights of the report because it was their material, but we've obviously purchased the rights to be able to distribute that material. We think it's super valuable for our customers. What a business model. It's super important. It's a great business model. Well, and if I was to write a business case for it, I'd be delighted with the work that was done and I'd be happy with the outcome. And I'm sure our customers will make use of the information to be able to benchmark their own work and also hold IFS and our partners to account to help build business cases. Well, I know it's anonymized, anonymized to protect the customer, but I bet you some of the customers would be willing to go public with some of this information. Hit them up, bring them on theCUBE and we'll distribute it for free. We want to charge it for their reprint rights. Great to have you on. Thanks very much. Appreciate it. All right, thank you for watching. Paul Gillan and I will be back with our next guest to wrap up IFS World 2019. You're watching theCUBE from Boston.