>>live from Boston, Massachusetts. It's the Q covering I. F s World Conference 2019. Brought to you by I. F. S. >>We're back at the Hynes Convention Center in Boston. This is a cube, the leader in live tech coverage. And this is our coverage of I f s World 2019 Matt Smith. This year. He's a global chief architect. Paul Dylan and I are happy to have you on Matt. Great >>pleasure to be here. Thanks very much. >>Filing. You're welcome. So business value engineering is a concept that you're a fan of on 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 I affects it's a little different. Fundamentally, it's, ah, collaborative process that we use working with our customers on 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 wanna ask you a question about this because your philosophy is a company seems to be the Let the customer define value. Um, 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 on DSO forth. So how do you reconcile that? Is it like balanced Scorecard is sort of pay you can tailor to yourself versus some kind of rigid methodology. How do you How do those two worlds meet in >>TV? Yes, 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 customers framework or that all their language is about agreeing the language. One of the challenges when you're trying to build a business relationship with with one or more parties is you have to have a common shared understanding, a common vision on a common value system so that when I say something to you, it means the same thing when you say it to me. And so part of that collaborative process requires that you worked together on 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? >>And so it enters as early as you can possibly make it. Answer rights? A. Right at the beginning, you asked 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 on it puts that a 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 gonna get there and therefore what the financial benefits and metrics would be to do it. Who >>were >>the ideal stakeholders when you're doing a collaboration like this in terms of getting them involved in getting their >>implements. So you might expect the answer to be C level executives on Dove course. They're important from, ah, leadership in 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 quite well understood types of people, they're the ones that tend to cause change. To happen more successfully doesn't mean there any more valuable than anybody else inside an organization, but the other 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 PL manager here. She's controlling a big portion of the budget. Has thousands of people working for them would be important. Maybe not a sea level executive, but a line of business executive, the son of the field General. Could that be an example of a change agent? 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 in all of our careers. Change is difficult, right? >>Wake up in the morning. >>Let's change. It s it's more about who were the people that lay the groundwork for that change that you follow. You listen to the influences. Now, of course, you'll have people that own the budget the financial controllers on 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. Thio help organizations realize the benefit off change. >>If you'll excuse me, this is not seem like a typical role for a software company to take on. Yeah, change management. What? 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 will 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. they were a software provider. I think software providers that don't deliver the context on the value that they are trying to achieve with software they buy in the customers are poorer supplies because they're just trying to push technology on its fun. Technologists 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 the 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 on. You have to have that that fortitude to say to the customer. This is actually not a great idea because the financial case doesn't support this. I think it is. 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 dark time when they've got a different problem. That perhaps does fit you. So I think it's about recognizing there's a both a short medium and a long term engagement with with with the customers that you have to maintain that >>in 2019. Given all the discussion on data digital transformation A. I cloud, I would think that data plays a crucial role in these discussions. So what role does data played? Companies understand the importance of data as it relates to the business value discussion. >>Absolutely. I think I think that data driven decision making is is pretty fundamental. A lot of people say the numbers don't lie. Maybe some statistics might be bent, but numbers don't really like, so you've got to be a capture numbers and make decisions based on those numbers. Eso 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, >>R o i N P V I R R. Even >>some of those numbers of valid right for >>a business case for sure, >>for sure, but just sticking with simple things like are always is not enough >>salad. If you treat the software as an asset. A zey expense? Essentially, >>Yeah, yeah, absolutely. But then it comes to the engagement's more than your software I like. I like Thio, I 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 and the people they're human beings they're going to do with work are the ones that are going to generate the value. The software's a tool, and the years are 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 apply this methodology for your customers? >>So we've done a number of things, so we've established practice inside. If s, 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. Andi, we are working with lots and lots of customers now on this as a Maur methodical disciplines approach. But we've also recognized that we needed to measure our existing customers benefits. So what you are existing customer base achieved with our software. So we commissioned Ah, pretty big and important study. And that was anonymous. We weren't involved other than inviting the company to go and do this work on, then unleashing them on our customer base for six months across all industries, all products on asking them to go and find out and measure what our customers really achieve with the software. >>So how was that anonymous? How it was in that you weren't doing the survey. >>We weren't doing the survey and any, um, numbers that came back. Where were anonymous? Dhe. 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 other express and share that data. >>And so you were specifically asking about the business impact of of I f s software throughout some kind of life cycle, like a before and an after? Yes, Exactly. Isn't it to be or what happened? Okay, so what'd you find >>so as a couple of surprises in the results, actually eso firstly >>tell us who did the study or is that >>yes, So the study. That's a good question, because the the choices are many. There are lots of analyst firms out there that you could use A ll do this sort of work and do it very well. The team that I worked with, we would personally had a previous relationship with I. D. C. Now we really liked I. D. C. And I've done some of this work previously with I D. C. Because they arm or they're an analyst. That has more statisticians as well as analysts. So they take a really very methodical mathematical approach. A scientist. I very much appreciated that. So we 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. On 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. That's why we picked I. D. C. That work in terms of what we found out where they found on we now just see the report on our customers can go and see this report. We published it last week. So you're just gonna free download and look at the material from I. D. C. The first thing that was interesting about the study. It was human productivity focused. So not things like, how much inventory you hold in supply chain on. Was it reduced? It was more about how did the workers get on? What kind of mistakes did I made? L. A. Faster doing their work and more successful. And they looked at lots of different categories on the returns. The improvements ranged from just a 10% improvement. So not 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 just shy of of 19% 18 and a bit percent productivity improvement across all of the different teams from the finance function, the supply chain function, human resource functions, 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 benefits studies, most of the value is in cost. Saving on only cost saving tends to be where asset management resource planning service management happens. Just under half of the value that the I. D. C study showed was net new revenue. The 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 pick. Probe Adept so productivity When I when you're saying productivity, I think revenue per employee has a simple list measure of productivity. But then you're saying there was incremental revenue, a swell independent. It first of all is is revenue per employee the right measure? Or was it more like Do we think's faster or sort of more generic measurements and specific to a task? Or was it kind of boil down to a revenue per employee? And and then how did that relate to the the incremental revenue. >>Yeah, so it was done by function by by team type. So if you look to finance and auditing and human resources and supply chain and so on so that the metrics on the you'll see in the white paper are specific to the team's specifically that role specific to that, >>right, You're not really big in insurance, but a claims adjuster could, you know, get more claims done exactly, or something like >>exactly example. So you'd find, for example, one of the statistics was around filled service engineering on how many jobs per day they couldn't do. It was reasonably specific, >>and they would attribute that directly to your software Direct. Now, as a result of installing I f s, how much would you increase your etcetera per day? >>That's why it took them six months to do the study. I mean, this is quite an in depth piece on >>how many customers that the interview. >>And so it was a cross on dhe. We gave them a challenge to do this. So it was a set of about 17 fairly large customers, which sounds like a small time. >>No, no, no, >>no. But when you do these kinds of studies, >>that's a totally legitimate number. And then thes air in depth surveys. Yeah, so it's not like it's not trivial. And and as well, revenue increases specific, too. The software. So that would have been what, like cohorts sales or service, you know, follow on sales things of that nature. >>Absolutely. And that's why we were so delighted with the report when it came back, because it was it was a really nice pleasant finding. So most companies that all the companies reported the revenue increase, but some are bigger than others. On average, it was a pretty sizable chunk, nearly half of all of the benefit. Um, and when we asked, I D C well, can you give us some kind of glimpse as to why we see such a large chunk of improved revenue? I. D. C. Said, Well, you're improving the productivity of the sales teams so they can quote faster. There's more accuracy and 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 is 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 revenue. >>Did you attempt Thio factor in less tangible factors, such as customer satisfaction, that promoter score perceived value, customer perceived value. >>So the folk note that the focus of the study was human productivity on. And it's something that I d. C do particularly well on that that's what we gave them a target. Obviously, when we doing business value engineering, you then have to take way more than just that. Things like the benchmark dated find from a study like I. D. C. Have conducted where you take into account those soft factors on 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. >>It could take away that so it's not just your software's not just operational impact in nature. It's more strategic. It has productivity impact, revenue impacts and obviously cost savings as well. Congratulations. That's good. How did we get this study >>out of people? You said customers can download it. Can anybody down? >>Anybody can download this U S So we've published it on our website. It's very easy to find on it. Sze freely available. We obviously have to comply with the I. D. C's. They owned the rights for the report because it was their material, but we've oversee purchased the rights to the other, distribute that material. We think it's super valuable for our customers. >>What a business model >>and super well, you know, And and if I was to write business case for it, I'd be delighted with the work that was done and I'd be happy with the outcome on. I'm sure our customers will make use of the information to be a benchmark, their own work and also hold my effects on our partners to account to help build business cases. >>Well, I you know, I know it's anonymous ized anonymous to protect the customer, but I bet you some of the customers would be willing to go public with some of this information. So hit him up. Bring him on the cube, you know, well distributed for free. If you want to charge for them. Reprint rights. Great to have you on. Thank >>you. Thank you. >>All right. Thank you for watching Paul Gill and I will be back with our next guest to wrap up I f s World 2019. You're watching the Cube from Boston?