(upbeat music) >> Hey, everyone. Welcome to theCUBE's presentation of the AWS Startup Showcase, season two, episode four. I'm your host, Lisa Martin. This topic is cybersecurity detect and protect against threats. Very excited to welcome a CUBE alumni back to the program. Snehal Antani, the co-founder and CEO of Horizon3 joins me. Snehal, it's great to have you back in the studio. >> Likewise, thanks for the invite. >> Tell us a little bit about Horizon3, what is it that you guys do? You were founded in 2019, got a really interesting group of folks with interesting backgrounds, but talk to the audience about what it is that you guys are aiming to do. >> Sure, so maybe back to the problem we were trying to solve. So my background, I was a engineer by trade, I was a CIO at G Capital, CTO at Splunk and helped grow scale that company. And then took a break from industry to serve within the Department of Defense. And in every one of my jobs where I had cyber security in my responsibility, I suffered from the same problem. I had no idea I was secure or that we were fixing the right vulnerabilities or logging the right data in Splunk or that our tools and processes and people worked together well until the bad guys had showed up. And by then it was too late. And what I wanted to do was proactively verify my security posture, make sure that my security tools were actually effective, that my people knew how to respond to a breach before the bad guys were there. And so this whole idea of continuously verifying my security posture through security testing and pen testing became a passion project of mine for over a decade. And through my time in the DOD found the right group of an early people that had offensive cyber experience, that had defensive cyber experience, that knew how to build and ship and deliver software at scale. And we came together at the end of 2019 to start Horizon3. >> Talk to me about the current threat landscape. We've seen so much change in flux in the last couple of years. Globally, we've seen the threat actors are just getting more and more sophisticated as is the different types of attacks. What are you seeing kind of horizontally across the threat landscape? >> Yeah, the biggest thing is attackers don't have to hack in using Zero-days like you see in the movies. Often they're able to just log in with valid credentials that they've collected through some mechanism. As an example, if I wanted to compromise a large organization, say United Airlines, one of the things that an attacker's going to go off and do is go to LinkedIn and find all of the employees that work at United Airlines. Now you've got say, 7,000 pilots. Of those pilots, you're going to figure out quickly that their user IDs and passwords or their user IDs at least are first name, last initial @united.com. Cool, now I have 7,000 potential logins and all it takes is one of them to reuse a compromised password for their corporate email, and now you've got an initial user in the system. And most likely, that initial user has local admin on their laptops. And from there, an attacker can dump credentials and find a path to becoming a domain administrator. And what happens oftentimes is, security tools don't detect this because it looks like valid behavior in the organization. And this is pretty common, this idea of collecting information on an organization or a target using open source intelligence, using a mix of credential spraying and kind of low priority or low severity exploitations or misconfigurations to get in. And then from there, systematically dumping credentials, reusing those credentials, and finding a path towards compromise. And less than 2% of CVEs are actually used in exploits. Most of the time, attackers chain together misconfigurations, bad product defaults. And so really the threat landscape is, attackers don't hack in, they log in. And organizations have to focus on getting the basics right and fundamentals right first before they layer on some magic easy button that is some security AI tools hoping that that's going to save their day. And that's what we found systemically across the board. >> So you're finding that across the board, probably pan-industry that a lot of companies need to go back to basics. We talk about that a lot when we're talking about security, why do you think that is? >> I think it's because, one, most organizations are barely treading water. When you look at the early rapid adopters of Horizon3's pen testing product, autonomous pen testing, the early adopters tended to be teams where the IT team and the security team were the same person, and they were barely treading water. And the hardest part of my job as a CIO was deciding what not to fix. Because the bottleneck in the security process is the actual capacity to fix problems. And so, fiercely prioritizing issues becomes really important. But the tools and the processes don't focus on prioritizing what's exploitable, they prioritize by some arbitrary score from some arbitrary vulnerability scanner. And so we have as a fundamental breakdown of the small group of folks with the expertise to fix problems tend to be the most overworked and tend to have the most noise to need to sift through. So they don't even have time to get to the basics. They're just barely treading water doing their day jobs and they're often sacrificing their nights and weekends. All of us at Horizon3 were practitioners at one point in our career, we've all been called in on the weekend. So that's why what we did was fiercely focus on helping customers and users fix problems that truly matter, and allowing them to quickly reattack and verify that the problems were truly fixed. >> So when it comes to today's threat landscape, what is it that organizations across the board should really be focused on? >> I think, systemically, what we see are bad password or credential policies, least access privileged management type processes not being well implemented. The domain user tends to be the local admin on the box, no ability to understand what is a valid login versus a malicious login. Those are some of the basics that we see systemically. And if you layer that with it's very easy to say, misconfigure vCenter, or misconfigure a piece of Cisco gear, or you're not going to be installing, monitoring security observability tools on that HPE Integrated Lights Out server and so on. What you'll find is that you've got people overworked that don't have the capacity to fix. You have the fundamentals or the basics not well implemented. And you have a whole bunch of blind spots in your security posture. And defenders have to be right every time, attackers only have to be right once. And so what we have is this asymmetric fight where attackers are very likely to get in, and we see this on the news all the time. >> So, and nobody, of course, wants to be the next headline, right? Talk to me a little bit about autonomous pen testing as a service, what you guys are delivering, and what makes it unique and different than other tools that have been out, as you're saying, that clearly have gaps. >> Yeah. So first and foremost was the approach we took in building our product. What we set upfront was, our primary users should be IT administrators, network engineers, and that IT intern who, in three clicks, should have the power of a 20-year pen testing expert. So the whole idea was empower and enable all of the fixers to find, fix, and verify their security weaknesses continuously. That was the design goal. Most other security products are designed for security people, but we already know they're task saturated, they've got way too many tools under the belt. So first and foremost, we wanted to empower the fixers to fix problems that truly matter. The second part was, we wanted to do that without having to install credentialed agents all over the place or writing your own custom attack scripts, or having to do a bunch of configurations and make sure that it's safe to run against production systems so that you could test your entire attack surface. Your on-prem, your cloud, your external perimeter. And this is where AWS comes in to be very important, especially hybrid customers where you've got a portion of your infrastructure on AWS, a portion on-prem, and you use Horizon3 to be able to attack your complete attack surface. So we can start on-prem and we will find say, the AWS credentials file that was mistakenly saved on a shared drive, and then reuse that to become admin in the cloud. AWS didn't do anything wrong, the cloud team didn't do anything wrong, a developer happened to share a password or save a password file locally. That's how attackers get in. So we can start from on-prem and show how we can compromise the cloud, start from the cloud and show how we can compromise on-prem. Start from the outside and break in. And we're able to show that complete attack surface at scale for hybrid customers. >> So showing that complete attack surface sort of from the eyes of the attacker? >> That's exactly right, because while blue teams or the defenders have a very specific view of their environment, you have to look at yourself through the eyes of the attacker to understand what are your blind spots, what do they see that you don't see. And it's actually a discipline that is well entrenched within military culture. And that's also important for us as the company. We're about a third of Horizon3 served in US special operations or the intelligence community with the United States, and then DOD writ large. And a lot of that red team mindset, view yourself through the eyes of the attacker, and this idea of training like you fight and building muscle memory so you know how to react to the real incident when it occurs is just ingrained in how we operate, and we disseminate that culture through all of our customers as well. >> And at this point in time, every business needs to assume an attacker's going to get in. >> That's right. There are way too many doors and windows in the organization. Attackers are going to get in, whether it's a single customer that reused their Netflix password for their corporate email, a patch that didn't get applied properly, or a new Zero-day that just gets published. A piece of Cisco software that was misconfigured, not buy anything more than it's easy to misconfigure these complex pieces of technology. Attackers are going to get in. And what we want to understand as customers is, once they're in, what could they do? Could they get to my crown jewel's data and systems? Could they borrow and prepare for a much more complicated attack down the road? If you assume breach, now you want to understand what can they get to, how quickly can you detect that breach, and what are your ways to stifle their ability to achieve their objectives. And culturally, we would need a shift from talking about how secure I am to how defensible are we. Security is kind of a point in time state of your organization. Defensibility is how quickly you can adapt to the attacker to stifle their ability to achieve their objective. >> As things are changing constantly. >> That's exactly right. >> Yeah. Talk to me about a typical customer engagement. If there's, you mentioned folks treading water, obviously, there's the huge cybersecurity skills gap that we've been talking about for a long time now, that's another factor there. But when you're in customer conversations, who are you talking to? Typically, what are they coming to you for help? >> Yeah. One big thing is, you're not going to win and win a customer by taking 'em out to steak dinners. Not anymore. The way we focus on our go to market and our sales motion is cultivating champions. At the end of the proof of concept, our internal measure of successes is, is that person willing to get a Horizon3 tattoo? And you do that, not through steak dinners, not through cool swag, not through marketing, but by letting your results do the talking. Now, part of those results should not require professional services or consulting. The whole experience should be self-service, frictionless, and insightful. And that really is how we've designed the product and designed the entire sales motion. So a prospect will learn or discover about us, whether it's through LinkedIn, through social, through the website, but often because one of their friends or colleagues heard about us, saw our result, and is advocating on our behalf when we're not in the room. From there, they're going to be able to self-service, just log in to our product through their LinkedIn ID, their Google ID. They can engage with a salesperson if they want to. They can run a pen test right there on the spot against their home without any interaction with a sales rep. Let those results do the talking, use that as a starting point to engage in a more complicated proof of value. And the whole idea is we don't charge for these, we let our results do the talking. And at the end, after they've run us to find problems, they've gone off and fixed those issues, and they've rerun us to verify that what they've fixed was properly fixed, then they're hooked. And we have a hundred percent technical win rate with our prospects when they hit that find-fix-verify cycle, which is awesome. And then we get the tattoo for them, at least give them the template. And then we're off to the races. >> Sounds like you're making the process more simple. There's so much complexity behind it, but allowing users to be able to actually test it out themselves in a simplified way is huge. Allowing them to really focus on becoming defensible. >> That's exactly right. And the value is, especially now in security, there's so much hype and so much noise. There's a lot more time being spent self-discovering and researching technologies before you engage in a commercial discussion. And so what we try to do is optimize that entire buying experience around enabling people to discover and research and learn. The other part, remember is, offensive cyber and ethical hacking and so on is very mysterious and magical to most defenders. It's such a complicated topic with many nuance tools that they don't have the time to understand or learn. And so if you surface the complexity of all those attacker tools, you're going to overwhelm a person that is already overwhelmed. So we needed the experience to be incredibly simple and optimize that find-fix-verify aha moment. And once again, be frictionless and be insightful. >> Frictionless and insightful. Excellent. Talk to me about results, you mentioned results. We love talking about outcomes. When a customer goes through the PoC, PoV that you talked about, what are some of the results that they see that hook them? >> Yeah, the biggest thing is, what attackers do today is they will find a low from machine one plus a low from machine two equals compromised domain. What they're doing is they're chaining together issues across multiple parts of your system or your organization to opone your environment. What attackers don't do is find a critical vulnerability and exploit that single machine. It's always a chain, always multiple steps in the attack. And so the entire product and experience in, actually, our underlying tech is around attack paths. Here is the path, the attack path an attacker could have taken. That node zero our product took. Here is the proof of exploitation for every step along the way. So you know this isn't a false positive. In fact, you can copy and paste the attacker command from the product and rerun it yourself and see it for yourself. And then here is exactly what you have to go fix and why it's important to fix. So that path, proof, impact, and fix action is what the entire experience is focused on. And that is the results doing the talking, because remember, these folks are already overwhelmed, they're dealing with a lot of false positives. And if you tell them you've got another critical to fix, their immediate reaction is "Nope, I don't believe you. This is a false positive. I've seen this plenty of times, that's not important." So you have to, in your product experience and sales process and adoption process, immediately cut through that defensive or that reflex. And it's path, proof, impact. Here's exactly what you fix, here are the exact steps to fix it, and then you're off to the races. What I learned at Splunk was, you win hearts and minds of your users through amazing experience, product experience, amazing documentation. >> Yes. >> And a vibrant community of champions. Those are the three ingredients of success, and we've really made that the core of the product. So we win on our documentation, we win on the product experience, and we've cultivated pretty awesome community. >> Talk to me about some of those champions. Is there a customer story that you think really articulates the value of node zero and what it is that you are doing? >> Yeah, I'll tell you a couple. Actually, I just gave this talk at Black Hat on war stories from running 10,000 pen tests. And I'll try to be gentle on the vendors that were involved here, but the reality is, you got to be honest and authentic. So a customer, a healthcare organization ran a pen test and they were using a very well-known managed security services provider as their security operations team. And so they initiate the pen test and they wanted to audit their response time of their MSSP. So they run the pen test and we're in and out. The whole pen test runs two hours or less. And in those two hours, the pen test compromises the domain, gets access to a bunch of sensitive data, laterally maneuvers, rips the entire environment apart. It took seven hours for the MSSP to send an email notification to the IT director that said, "Hey, we think something suspicious is going on." >> Wow. >> Seven hours! >> That's a long time. >> We were in and out in two, seven hours for notification. And the issue with that healthcare company was, they thought they had hired the right MSSP, but they had no way to audit their performance. And so we gave them the details and the ammunition to get services credits to hold them accountable and also have a conversation of switching to somebody else. >> Accountability is key, especially when we're talking about the threat landscape and how it's evolving day to day. >> That's exactly right. Accountability of your suppliers or your security vendors, accountability of your people and your processes, and not having to wait for the bad guys to show up to test your posture. That's what's really important. Another story that's interesting. This customer did everything right. It was a banking customer, large environment, and they had Fortinet installed as their EDR type platform. And they initiate us as a pen test and we're able to get code execution on one of their machines. And from there, laterally maneuver to become a domain administrator, which in security is a really big deal. So they came back and said, "This is absolutely not possible. Fortinet should have stopped that from occurring." And it turned out, because we showed the path and the proof and the impact, Fortinet was misconfigured on three machines out of 5,000. And they had no idea. >> Wow. >> So it's one of those, you want to don't trust that your tools are working, don't trust your processes, verify them. Show me we're secure today. Show me we're secure tomorrow. And then show me again we're secure next week. Because my environment's constantly changing and the adversary always has a vote. >> Right, the constant change in flux is huge challenge for organizations, but those results clearly speak for themselves. You talked about speed in terms of time, how quickly can a customer deploy your technology, identify and remedy problems in their environment? >> Yeah, this find-fix-verify aha moment, if you will. So traditionally, a customer would have to maybe run one or two pen tests a year. And then they'd go off and fix things. They have no capacity to test them 'cause they don't have the internal attack expertise. So they'd wait for the next pen test and figure out that they were still exploitable. Usually, this year's pen test results look identical than last year's. That isn't sustainable. So our customers shift from running one or two pen tests a year to 40 pen tests a month. And they're in this constant loop of finding, fixing, and verifying all of the weaknesses in their infrastructure. Remember, there's infrastructure pen testing, which is what we are really good at, and then there's application level pen testing that humans are much better at solving. >> Okay. >> So we focus on the infrastructure side, especially at scale. But can you imagine, 40 pen tests a month, they run from the perimeter, the inside from a specific subnet, from work from home machines, from the cloud. And they're running these pen tests from many different perspectives to understand what does the attacker see from each of these locations in their organization and how do they systemically fix those issues? And what they look at is, how many critical problems were found, how quickly were they fixed, how often do they reoccur. And that third metric is important because you might fix something, but if it shows up again next week because you've got bad automation, you're in a rat race. So you want to look at that reoccurrence rate also. >> The reoccurrence rate. What are you most excited about as, obviously, the threat landscape continues to evolve, but what are you most excited about for the company and what it is that you're able to help organizations across industries achieve in such tumultuous times? >> Yeah. One of the coolest things is, because I was a customer for many of these products, I despised threat intelligence products. I despised them. Because there were basically generic blog posts. Maybe delivered as a data feed to my Splunk environment or something. But they're always really generic. Like, "You may have a problem here." And as a result, they weren't very actionable. So one of the really cool things that we do, it's just part of the product is this concept of flares, flares that we shoot up. And the idea is not to cause angst or anxiety or panic, but rather we look at threat intelligence and then because all of the insights we have from your pen test results, we connect those two together and say, "Your VMware Horizon instance at this IP is exploitable. You need to fix it as fast as possible, or is very likely to be exploited. And here is the threat intelligence and in the news from CSAI and elsewhere that shows why it's important." So I think what is really cool is we're able to take together threat intelligence out in the wild combined with very precise understanding of your environment to give you very accurate and actionable starting points for what you need to go fix or test or verify. And when we do that, what we see is almost like, imagine this ball bouncing, that is the first drop of the ball, and then that drives the first major pen test. And then they'll run all these subsequent pen tests to continue to find and fix and verify. And so what we see is this tremendous amount of excitement from customers that we're actually giving them accurate, detailed information to take advantage of, and we're not causing panic and we're not causing alert and fatigue as a result. >> That's incredibly important in this type of environment. Last question for you. If autonomous pen testing is obviously critical and has tremendous amount of potential for organizations, but it's only part of the equation. What's the larger vision? >> Yeah, we are not a pen testing company and that's something we decided upfront. Pen testing is a sensor. It collects and understands a tremendous amount of data for your attack surface. So the natural next thing is to analyze the pen test results over time to start to give you a more accurate understanding of your governance, risk, and compliance posture. So now what happens is, we are able to allow customers to go run 40 pen tests a month. And that kind of becomes the initial land or flagship product. But then from there, we're able to upsell or increase value to our customers and start to compete and take out companies like Security Scorecard or RiskIQ and other companies like that, where there tended to be, I was a user of all those tools, a lot of garbage in, garbage out. Where you can't fill out a spreadsheet and get an accurate understanding of your risk posture. You need to look at your detailed pen test results over time and use that to accurately understand what are your hotspots, what's your recurrence rate and so on. And being able to tell that story to your auditors, to your regulators, to the board. And actually, it gives you a much more accurate way to show return on investment of your security spend also. >> Which is huge. So where can customers and those that are interested go to learn more? >> So horizonthree.ai is the website. That's a great starting point. We tend to very much rely on social channels, so LinkedIn in particular, to really get our stories out there. So finding us on LinkedIn is probably the next best thing to go do. And we're always at the major trade shows and events also. >> Excellent. Snehal, it's been a pleasure talking to you about Horizon3, what it is that you guys are doing, why, and the greater vision. We appreciate your insights and your time. >> Thank you, likewise. >> All right. For my guest, I'm Lisa Martin. We want to thank you for watching the AWS Startup Showcase. We'll see you next time. (gentle music)

>>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?