Jan Arendtsz and Matt Graney @ Celigo
Main Stage
Ascent Conference 2020
Jan Arendtsz [00:00:00] Hello, everyone, my name’s Jan Arendtsz, I’m the founder and CEO of Celigo with me today, I have met Matt Graney, a product at Celigo as well. And we’re here today to talk about automation, to grow and scale your business, especially scaling software companies. So SAS, the SAS model, has been around for about 20 years, so I started way back in in 2000, the first known Fast Company was concur. And then, of course, that was Salesforce in around 2000. For those of you who are old enough to remember that era, Salesforce had this slogan called Into Software and no software, which used to be in red. That’s how we got started. That was the battle that they were trying to fight at that time. And if you were to fast forward to today, 20 years later, there are thousands of SaaS applications, well over 10000 on last count. And we’ve come a long, long ways in the last 20 years. A couple of things that have happened along the way is that. More and more sass applications vendors have come in and gone deep in specific functionality, they’ve taken a sliver out of another largest asset and they’ve gone deep. So that continues to happen. And then a number of these assets, especially the ones created fairly recently in the last five, 10 years, they have been consumer raised as well. So that these assets today don’t look like anything from the past. They look like the personal apps that we use on our devices in our personal lives today. So these SAS applications have been consumer sized as well. And as we speak, there are lots and lots of other SAS companies just like you who are building the next generation, the next evolution of SAS. So the bottom line is there is a SAS application for pretty much every business function that you can think about today. It’s increasingly easy to acquire and start using these SAS applications, often at a departmental level. And then companies of all sizes, all types of industries have fully embraced SAS, that’s not a question anymore. It’s that’s just a fact. And especially software companies have been at the forefront in the adoption of SAS applications in that enterprise. So we can see that manifest itself in the number of suspects in a typical enterprise. So if you were to look at this, the three boxes there on the top. A typical assembly company defined as a company with less than 100 employees is using about 100 applications. On the other end of the spectrum, an enterprise company, about 1000 employees based on this definition is using close to 300 SAS applications. And mid-market companies who sit in the middle are using close to 200 applications. Not only that, the the spend on science applications is growing aggressively. Last year, across the board, across all these three segments, companies spent 50 percent more than the price on on says if you were to focus on the mid-market sector. Looking at the chart there on the bottom and by the way, this data is coming from this fully as part of the Fast Trends report in 2020. If you look at the mid-market spend, on average, it’s a it’s over two million, close to two and a half million. So there you go. Is also a mid-market company. We have 200 employees. And so I know how much we spend on SAS. And I think these numbers are spot on. I can’t tell you for sure how many apps that we use because that’s changing pretty much on a on a weekly basis as well. But these numbers match really well with what we are doing internally as well as what we’re seeing out there in the market. And so let’s. Get into some details on what this might look like in a typical enterprise, so think of this as a company, a fictitious company, let’s say, in a growth stage, who has a number of assets in the mix. And as they grow and scale, the business then needs to change to become more sophisticated. Maybe they need a specific building application, or they may need professional services, automation to deliver the software. They may need sales compensation or on the right side, they may need to spin up a data warehouse and put a buy front end on that or perhaps invest in a single financial solution. And then as the sales process becomes more and more complex, they may need a CPQ in time. And as you can see in the last slide, even the smallest company can have up to about 100 SaaS applications. And this is only catching some of the highlights here. And while this is ultimately the best of breed model that we all live day to day, it also has some consequences in that there is a sprawl of apps which we call the sass sprawl. Not only is there a sprawl, but in time that sprawl turns into into silos as well, so working from the left to the right. If you look at the front office, the sales and marketing, there are a number of apps that are clustered together in the back office, the same thing typically around an ERP in finance and accounting and so on and so forth. And not all of these apps were kind of born equal, so to speak, there is a hierarchy within these applications. And if you look at the bigger boxes in blue, the CRM, the ERP, the HCM, these are what we call a foundational asset. So what’s a foundational asset? A foundational asset is an application that has a broad sense of responsibilities and footprint within the enterprise, and they own the system of record for key business objects in the enterprise. So let’s go through some examples. What are some of the key business objects that might be a lead and a count? An opportunity, a sales order, an employee, a vendor purchase order, and these foundational assets on those systems of record. And so what happens then is some of the more specialized applications that go deep ultimately need to access the foundational fast up of the system of record. So let’s take one quick example. If you’re in if you’re building a time and expense type business application, ultimately you’re going to have to have access to the employee business object. But they employ the system off record. All the master is not going to be the time and expense application. It’s going to be in an hour. So by definition, that time and expense application needs to connect with this H.R. app. And I’m sure a lot of you here in the session are going through this exact problem with you. In order for you to ultimately go to market and sell your product, there’s a need for you to go ahead and build some of these integrations yourself. This is what we call Vanderbilt’s integrations. And Matt Groening is going to talk about this later on. So. The takeaway here is that the sprawl, there’s a natural order, there’s a hierarchy, there are foundational steps, and then ultimately there are silos. So we talked about SACE applications. Now let’s talk about business processes. Think about business processes as these processes that live on top of the sprawl of assets. I like to think of it as the operating system of the enterprise, the OS, because it’s like a central nervous system. Everything that’s important in the enterprise is going to go through a set of business processes. And as companies add more and more apps, what happens is a typical business process that was going to go back in the day may have been encapsulated within one SACE application or a couple now get fragmented across multiple business applications. And so this, of course, is fragmentation. And to solve fragmentation, you need to automate some of those business processes so that you can make it all look like it’s one common entity. So look at let’s look at an example of. A business process, and through that example, we want to see how fragmentation may occur. So what you see here on the screen is a typical, quote, Bikash business process that a lot of you are familiar with. If you look at some of those boxes going from the left to the right, a salesperson may have an opportunity and they want to go ahead and put together a quote. And at some point they have to go send that as a proposal. The deal desk, they might get involved there. Then that sales order needs to be booked, typically happens with sales ups and perhaps or the sales rep working with sales ups or there needs to be approved at some point. You need provision and user licenses. You need to invoice that order. And then ultimately, of course, you need to be able to collect payment. This, as you can see, is touching multiple different departments and people for this business process to really work flawlessly. And the key thing is that it encapsulates a number of business applications. Typically, you might start with a CRM and ERP or accounting app just to be able to book that order. But as a company grows, there needs change and business processes get more sophisticated. So the let’s take an example of a company. Let’s say you are taking about 100 orders a month and business is doing well. And now you’re starting to increase that volume and you want to go all of a sudden before you know it, 100 goes to a 500 and a thousand. And if you don’t have this under control, you’ll end up being a victim of your own success. Because what we want to see, and we’ve seen this many times in working with customers, is that the word of processing time, if you don’t have this fully figured out, tends to go up when it should be really coming down as you scale. And so. Not only that, now in this business process, you might decide to go ahead and add a CPQ solution, which means that the automation, how it needs to work is going to change. So companies are going to make this process more and more sophisticated as they grow and scale. And that means there’s going to be more fragmentation in the end. So what is the cost of this fragmentation? To put it in very simple terms, if you have this type of fragmentation, a business cannot scale and grow and at some point it’s going to come back to bite you hard and surprise you. So imagine let’s go back to the, quote, the cash business process, if that was not automated and it spans multiple systems. Just think about the complexity that’s going to arise a further a system for the downstream may not have visibility into what’s happening further upstream. So the visibility is going to be lacking. Maybe you’re going to do manual data entry into another system which is ultimately going to result in the data being incomplete or there being errors. So integrity becomes a problem. And then eventually you’re going to throw resources at this, which, of course, is not the most efficient way to do things. And then ultimately you as a company are not going to be agile. You are doing well, you are selling your product, but on the back end, you can’t keep pace with that success. So we talked about one business process, quote, to cash. Of course, a typical company and in this case a software company has multiple business processes. We’ve shown you a few here. This is representative, but certainly not an all inclusive list. And so I’ll I’ll highlight a few of the business processes. The one down the top left is suspect to prospect. That means that companies, especially when they get started, I need to generate demand, generate leads. They need to bring that into the CRM. So there needs to be a business process and an automation that typically that’s done mostly with the so-called vendor integrations. Once you acquire a certain critical mass of customers, your customers may have issues, support tickets that they file. You need to be able to resolve that. That’s where the issue to resolution business process comes into effect. As we talked about in the quote to cash, you might decide to have more of a dedicated billing application, especially subscription billing. And that, of course, has an impact on the quarter cash business process. And it turns into its own business process. When you’re hiring employees, you need to be able to unload them and you need to provision them on various different SaaS applications. And when you devote an employee, you need to be able to take access. And by the way, that’s a great example of a business process where if you’re only hiring an employee or terminating an employee once a month, once every three months, it’s fine to do that manually. But at some point, once you start to do this at scale, then you need to think about automating that particular process, that efficient. And then the last example is you might decide to start up a data warehouse and do some advanced analytics. And you have to have processes to be able to seed that data repository with data from various other applications as well. As you can see there on the bottom row, of course, these business processes change by the stage of the company. Sometimes companies can be pretty mature at an early stage and get into some of these details while some other companies might wait until it becomes more of a crisis. So in saying all of that, there is a need ultimately for a connected enterprise, so what the connected enterprise, recognizing that there are business processes that span multiple SAS applications, we ultimately need to automate those business processes and to automate a business process that spans multiple tasks, applications. You need to be able to integrate those various systems together. So what are some of the options for a connected enterprise? Let’s start with what we call API based coding, so every application has an API and because they have an API, they should be able to anyone should be able to come in and build integrations, and especially if they’re using certain SaaS platforms to be able to do this. So let’s think of a salesforce or NetSuite. There’s ability to be able to take to use that platform and do coding to handle situations where they can go build specific custom integrations. The problem with these custom integrations is they are brittle, they’re hard to maintain and they don’t scale. And in fact, ultimately, the customer ends up reinventing the wheel most of the time. The next option is to have point-to-point integration’s or in some cases consulting. So these solutions tend to focus on a fairly narrow problem where there’s a purpose-built solution and it’s often a black box and a given company or a system integrator has built a solution, might work great under certain circumstances, but in the end, long term, there are deficiencies that hard to customize, that what you see is what you get. You can’t really do anything beyond that unless you bring in other consultants to come in and be able to change some of this as well. And then the next category is Vanderbilt, that’s Vanderbilt Integration’s, which is the most popular option, we talked about that a little bit early on. It’s some of the basic requirements, again, similar to some of the other options doesn’t necessarily scale. One thing that we see often is when customers want to customize these Facenda both integrations. There are limited options there. It’s hard to also manage this. Think about it for a second. If you have 100 fast applications in the enterprise and each of those have multiple Vanderbilt integrations, you have a ton of integrations where one doesn’t know about the existence of the other. So in time there’s going to be overlap and there’s going to be some thrashing around that as well. And the last option is, of course, going with an integration platform. So what’s an integration platform like IPASS social integration platform as a service, it standardizes the way that integration can be built and managed without getting into a lot of the details down there. I just want to focus on on two things. When we talk about integration, we always talk about building a particular integration and building those use cases. How easy is it to come in and be able to build those integrations? And the next part is to be able to then work to manage those integrations once it’s built and put in production. What’s the effort to manage things on an ongoing basis? So things like being able to monitor the integration, manage errors then and recover and resolve those to provide a centralized one pane of glass to see how all the integration and enterprise are running in a holistic fashion. These are some of the key features that an IPASS brings to the table. So every company looks at integration in a different way, as you can expect, and the way they look at it is based on the maturity of the company when it comes to their SAS applications, their business processes, and whether they want to automate the business processes. So this is where we introduce the concept of an integration maturity model. So it’s got five stages. We’re not going to get into every single detail here, but I’m going to highlight a few things that are salient. Starting on the left is the ad hoc stage, and I think we can all relate to this stage when we start a business. And our focus is to try and find product market fit and go sell as much as possible. And then integration is an afterthought, right? It’s decentralized. It’s oftentimes these companies are surviving based on Vanderbilt’s integrations. That might be a scattering of assets in the enterprise, but it’s disorganized. The next stage is similar to that stage, but companies can now understand some of the limitations that have come about based on this model. They understand that they need to get a plan together. They may have a few foundational assets. And as soon as you have the foundational assets, you know that you have to go. It’s inevitable that you’re going to buy a bunch of more of the specialized SaaS applications as well. Ultimately, where we want to get to where most companies should be striving to get to is this optimized phase. And the the optimized phase in a in a nutshell is you’re finding that right balance between you have a plan, certain mission critical integrations handled by the I.T. team because, again, they touch multiple different departments and resources and multiple business applications and. There has to be a certain control at a macro level so that anyone in the enterprise can cannot come in and and start making changes. Right, because they are going to be a number of consequences. But every business process or every automation or every integration doesn’t need to be centralized. Certain things can absolutely be delegated to certain business teams or departments where they are empowered as business users to be able to go build these integrations. So a typical IPASS should be able to handle both the the technical needs of an I.T. team as well as that needs of a business team as well. Empowered is just taking that to the next level. It’s really meant for larger companies in general. Doesn’t have to be where they have. They have an integration first mentality. There’s a blueprint for everything that they do. And everyone in the company ultimately is empowered to take part in automation. So one thing that I like to say here is that it is OK if you’re in any stage here, including that stage, I think the most important thing is to be aware of where you are and understand that there is a path and arguably a better way to be able to handle automation and integration. And that’s trying to get to that optimized space. So if you are in adhoc and you know that if you can get to this optimized phase and what that means or what the consequences would be, if you don’t get there, then at least you have awareness and then it’s up to you as to how you want to progress and get there based on the cadence of your business. We typically see early stage companies somewhere in those first three stages. And then, of course, we see companies going through growth spurts and really scaling their business to be across the board. And it’s surprising sometimes smaller companies might be a lot more mature. And shockingly, sometimes large companies are not that mature. That’s to be expected in in this model. So, again, the key takeaway is know where you are today. Try to identify yourself and then try to figure out where you would like to get to in the not too distant future. And here’s another slightly different way to look at the same problem in terms of the integration models. So what we’ve seen is two ends of the spectrum on one end. There are companies that have very centralized processes where everything is controlled. Most things are controlled by tea or ups. And so there’s a backlog as companies are buying all these different sorts of applications. The automation and integration is getting held up on the other end of the spectrum. here are companies that are very decentralized. It’s kind of anything goes mentality, a little bit like the Wild West and business users and business teams are really driving the process and that doesn’t really scale as well. So the recommended model to be able to get to is what we call a federated model, where there is oversight from the I.T. team. There’s a reason and a plan for everything, but the team doesn’t have to go build all these integrations. They can easily delegate this as long as they understand and they have some jurisdiction over what is happening. With that, I’m going to turn things over to my granny to get into some of the other details around integration.
Matt Graney [00:27:50] Thanks, John, and we’ll begin with some of the pitfalls and I’m going to echo many of the comments that John has already had for you. The first is to beware of the limitations of out of the box or Vanderbilt integrations. Now, of course, they’re going to be suitable in some cases, particularly at the early stage of a business. Even today, for example, it’s illegal. The integration between our customer support system and the engineering ticketing system is using the Vanderbilt integration. So in our case, that’s Zendesk for support for engineering tickets. And the integration works well both ways. Status updates are pushed in each direction and everyone’s happy. So there’s no need for us to to look any further than that. But the thing to be aware of is that sometimes bendable integrations merely check the box. If you’re a SACE company in the Salesforce ecosystem, for example, and you’re up and coming, of course, Salesforce isn’t going to build an integration to you. You have to build it to that. So many SaaS companies will need to say, yes, we can integrate with one of these foundational apps, but it doesn’t necessarily mean it is going to suit your needs. And there, again, often just point to point and tend to be a bit inflexible. And so as your business processes evolve or as your own needs evolve, will a vendor integration keep up with you, for example, an integration, say, between the CRM and the AARP? It might all be fine out of the box at the beginning that as your offers become more complex and you introduce a CPQ that’s a third party CPQ, you now have three moving parts. Maybe you also introduce a subscription billing application and all of a sudden you’re very close to the scenario that you describe with with quote to cash. And so you need to be sure that these Vanderbilt integrations, you need to keep your eye on them and make sure they’re going to grow as your business grows. So the next one is about the lure of do it yourself integrations on the next slide. So it’s it’s tempting to say, well, OK. System and System B, maybe System C, they all have APIs, we could just build it ourselves, build an integration ourselves to to automate these key pieces of the business. Well, I would just caution you that it’s often more complicated than you think. Yes, they have APIs, but are the APIs, other systems always going to be available? What happens if a system changes its API, its governance rules? There are many reasons why issues that could be introduced. What are you going to do about reporting? What if a certain record, for example, didn’t make it through the system? How you going to go back and deal with that? And ultimately, it’s not your core competency. It’s not what you really want to be spending your engineering resources on. There’s a high opportunity cost on those resources and you’d be better off investing in things that are actually going to differentiate. And then the final thing, of course, is even if you can do it for version 1.0, what happens in the future? Your businesses are going to evolve, just as I described, with multiple apps, especially when you see such fine grained applications. Things that used to be features are now entire companies. And once they’re in place again, APIs change, right? It’s not not going to be static. So just be aware that you may well have an engineering team that they could indeed build it. That is that really where you want to be spending your time and money? The final one I’ll mention is just about the need to organize and prioritize. Don’t assume you can do it all at once. Just as we’ve talked about the the evolution of companies, whether it’s in terms of the number of apps, the business processes that that are most critical as a company evolves. Think about this. As you build a kind of integration roadmap, think about the impact that the lack of automation is having on the business. Think about the cost on the business as well as the cost to solve the integration problem and then the complexity and use those factors as a way of prioritizing where you choose to spend your time. So I’ll just transition out to talk about some common integration patterns, because I think you’ll recognize in in here the sorts of things you’ll run into throughout your your own organization. The first kind is is just about getting data to where it needs to be. So it’s ready. So think of that in terms of synchronizing contact details between, say, the CRM and the marketing automation system or the CRM and the AARP for billing purposes. It’s not necessarily at the moment of synchronization part of a business process, but you need the information there in order that when the business process runs, it’s going to run correctly. Maybe it’s related to the assignment of account reps to various territories. Maybe it’s related to updating of Skewes in an e-commerce system. So synchronizing that data is really key just to make sure it’s it’s available where it’s needed. And another common pattern actually around synchronization is even in cases where you just don’t have all the licenses for an up system. So maybe you have sales reps, of course, who have accounts in the CRM. But there are many people in the company who want to know when a sales order is closed. One or many stakeholders that want to know when a VIP customer logs a support ticket. Synchronization can actually be good for that as well. Perhaps to take something out of a system of record and get it into a collaboration tool just with visibility. So this relates to the middle one here around liberating data, and that’s about getting data into systems of record for reporting. So whether that’s like a data warehouse or data like kinds of use cases, but but also for synchronizing campaign results from a marketing automation system back into the CRM. So it’s about providing three hundred and sixty degree visibility so that you can build reports and so on on there. And the final one here is, is really to bring it home. It’s where we began and that’s talking about business processes. The fact is that your business processes are spanning multiple application. Typically, there’s going to be one or two systems of recording, then maybe different systems of records for for different parts of the organization for for sales of the CRM, for finance. It’s the accounting or ERP system for support. It’s a case management system. And when business processes across multiple apps in this way, as we’ve described, you know, automation and integration enables those to flow properly. So this is really the main one that we’ve talked about today and the one I wanted to finish with. So to to wrap it all up, you need to think about your automation. The strategy and the way integration plays into that, and there are there are five key things we would leave you with the first if we build, is to get an idea of the application landscape. It’s changing all the time. As John said, it’s changing almost on a weekly basis, even in a mid-sized company like ours. Next, you want to understand the cost of fragmentation, where the breakdown is occurring. What is it costing you from? You know, whether it’s about time to close, whether it’s about duplication of efforts, whether it’s about lack of visibility. The next is to have an integration roadmap. Think about the most important pieces of that puzzle where the gaps and the friction is greatest and put a plan together to to address those in some sort of priority order. Then you should leverage out of the box integrations where you can, but be aware that they can only take you so far. So the Vanderbilt integrations are not to be ignored. But finally, keep in mind the advantages of using an integration platform again, IPOs in order to provide a common way of approaching integration, common visibility and reporting, and ultimately building a competency in an organization as you mature so that you can address fragmentation in your business processes.
Jan Arendtsz [00:36:28] Thank you, Matt. And I’ll add one more thing. As Matt said, ultimately, everyone’s circumstances are going to be different. There’s not one cookie cutter type strategy. We’ve given you some some details on how you can think about this. But ultimately, you have to craft and adapt to a strategy that makes sense for you. But, of course, knowing that there are certain well honed best practices out there, such as the integration maturity model and and some of the items discussed here. And folks, that’s it for today. I hope that this is helpful for companies like you to be able to scale and automate your business if you have any questions or if you want to talk to us about your integration automation strategy or would like to understand where you fit in in the maturity model, please contact us at Filmgoer Outcome. Thank you so much.
Matt Graney [00:37:36] Thank you.