Automation for Growth: Using Integration as a Competitive Advantage – Register

Automation for Growth: Using Integration as a Competitive Advantage – Register2020-10-07T00:24:41+00:00
ON DEMAND WEBINAR

Automation for Growth: Using Integration as a Competitive Advantage

Register Now

Jan Arendtsz Jan Arendtsz Founder and CEO
CELIGO
Matt Graney Matt Graney VP of Product
CELIGO

When you think of ways to accelerate growth and gain the edge over your competition, developing an integration strategy probably isn’t the first thing that comes to mind. High growth SaaS companies have one thing in common, they all automate critical business processes early on to free up resources and run faster.

With today’s modern integration platforms as a service (iPaaS), any organization from early-stage to well-funded startups can build scalable, efficient, and resilient operations. But how do you get started with the right strategy? What processes matter most to automate and when? When should you use native integrations vs. building custom integrations? Why not just code directly to APIs?

In this session, Jan Arendtsz, Founder and CEO of Celigo, and Matt Graney, VP of Product at Celigo, will answer these questions and more..

In this session, we will cover:

  • Typical automation priorities at different stages of a company’s maturity
  • Business process journey in the company life cycle
  • Integration options available and pros/cons of each
  • Common integration patterns that bring real value to the business
  • Pitfalls to avoid

Watch Today!

Full Webinar Transcript
Hello, everyone. My name’s Jan Arendtsz. I am the founder and CEO of Celigo. With me today, I have Matt Graney VP of Product at Celigo as well. And we’re here today to talk about automation to grow and scale your business especially scaling software companies. The SaaSmodel has been around for about 20 years. SaaS started way back in 2000. The first known SaaS company was Concur. And then, of course, there was Salesforce in around 2000. For those of you who are old enough to remember that era, Salesforce had this slogan called ‘end of software, no software’ which used to be in red. That’s how we got started. That was a 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 10,000 on last count. And we’ve come a long, long way in the last 20 years. A couple of things that have happened along the way is that more and more SaaS applications. Vendors have come in and gone deep in specific functionality. They’ve taken a sliver out of another larger SaaS app and they’ve gone deep. So that continues to happen. And then a number of these assets, especially the ones created very recently in the last 5, 10 years, they have been consumerized as well. So that these SaaS apps 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 SaaS applications have been consumerized as well. And as we speak, there are lots and lots of other SaaS companies just like you who are building the next generation, the next evolution of SaaS. So the bottom line is there is a SaaS application for pretty much every business function that you can think about today. It’s increasingly easy to acquire and start using these SaaS applications often at a departmental level. And then companies of all sizes, all types of industries have fully embraced SaaS. That’s not a question anymore. That’s just a fact. And especially software companies have been at the forefront in the adoption of SaaS applications in that enterprise. So we can see that manifest itself in the number of SaaS apps in a typical enterprise. So if you had a look at the three boxes down the top, a typical SMB company defined as a company with less than 100 employees is using about 100 SaaS applications. On the other end of the spectrum, an enterprise company above a thousand employees based on this definition is using close to 300 SaaS applications, and mid-market companies who sit in the middle using close to. 200 applications. Not only that the spend on SaaS applications is growing aggressively. Last year across the board, across all these three segments, companies spent 50% more than the prior on SaaS. If you were to focus on the mid-market sector, looking at the chart down there on the bottom– and by the way, this data is coming from the SaaS Trends Report in 2020. If you look at the mid-markets spend– on average, it’s over two million, close to two and a half million. So Celigo is also a mid-market company. We have 200 employees, and I know how much we spend on staff. And I think these numbers are spot-on. I can’t tell you for sure how many apps that we use because that’s the same thing, pretty much, 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 SaaS apps in the mix. And as they grow in scale to business, their needs start to change. They become more sophisticated. Maybe they need a specific billing application. Or they may need professional services automation to deliver the software. They may need sales compensation or, on the IT side, they may need a data warehouse and put a BI front end on that or perhaps invest in a single sign-on solution. And then, as the sales process becomes more and more complex, they may need a CPQ in time. And as you can see, and for the last slide, even the smallest company can have up to about 100 SaaS applications, and this is only capturing 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 the sprawl of apps, which we call the SaaS sprawl. Not only is there a sprawl, but in time, that sprawl turns into silos as well. So working from the left to the right, if you look at the front of this, typically sales and marketing, there are a number of apps that are clustered together. In the back office, the same thing– typically around any ERP in finance and accounting, in HR, 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 SaaS app. So what’s a foundational SaaS app? A foundational SaaS app is an application that has a broad sense of responsibilities and footprints within the enterprise. And they own the system of records for key business objects in the enterprise. So let’s go through some examples. What are some of the key business objects? It might be a lead, an account, an opportunity, a sales order, an employee, a vendor, a purchase order– and these foundational SaaS apps own those systems of record. And so what happens, then, is some of the more specialized SaaS applications that go deep ultimately need to access the foundational SaaS app for the system of record. So let’s take one quick example. 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 the employee, the system off record or the master, is not gonna be the time and expense application. It’s going to be in an HR app. So by definition, the time and expense application needs to connect with this HR app. And, I’m sure a lot of you here in this session are going through this exact problem where 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 vendor built integrations and Matt Green is going to talk about this later on. So, the takeaway here is there’s a sprawl, there’s a natural order, there’s a hierarchy, there are foundational assets. And then ultimately, there are silos. So, we talked about SaaS applications. Now, let’s talk about business processes. Think about business processes as these processes that live on top of the sprawl of SaaS apps. 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– back in the day, may have been encapsulated within one SaaS application or a couple, now they are 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 to cash 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, the 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 [inaudible] might get involved there. Then that sales order needs to be booked. Typically, happens with sales ups and perhaps with the sales rep working with sales ups. The order 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, 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 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 order 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-to-cash business process – if that was not automated and it spans multiple systems, just think about the complexity that’s going to arise. A system further 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 there. 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 highlight a few of the business processes. The one there the top left is suspect-to-prospect. That means that companies, especially when they get started, need to generate demand, generate leads, MQLs. They need to bring that into the CRM, so there needs to be a business process and an automation there. Typically, that’s done mostly with these so-called vendor-built 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 you have more of a dedicated billing application, especially subscription billing. And that, of course, has an impact on the quote-to-cash business process, and it turns into its own business process. When you’re hiring employees, you need to be able to onboard them, and you need to provision them on various different SaaS applications. And when you deboard 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 or 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 so that it’s 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 see that data repository with data from various other SaaS 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’s a connected enterprise? Recognizing that there are business processes that span multiple SaaS applications. We ultimately need to automate those business processes. And to automate a business process that spans multiple SaaS 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 SaaS 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, especially if they’re using certain SaaS platforms to be able to do this. So let’s think of a Salesforce or a NetSuite. There’s the ability to be able to take and use that platform and do coding to handle situations where they can go build specific custom integration. 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 integrations or, in certain cases, consulting ware. So these solutions tend to focus on a fairly narrow problem where there is a purpose-built solution and it’s often a black box and a given company or a system integrator has built a solution, it might work great under certain circumstances but in the end, long-term, there are deficiencies that it’s 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 a vendor-built, SaaS vendor-built integrations which is the most popular option. We talked about that a little bit early on. It serves some of the basic requirements. Again, similar to some of the other options, it doesn’t necessarily scale. One thing that we see often is when customers want to customize these SaaS vendor-built integrations, there are limited options there and it’s hard to also manage this. Think about it for a second. If you have 100 SaaS applications in the enterprise and each of those have multiple vendor-built 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 there as well. And the last option is, of course, going with an integration platform. So what’s an integration platform? Oh, I passed a short integration platform as a service. It standardizes the way that integrations can be built and managed. Without getting into a lot of the details down there, I just want to focus on two things. When we talk about integration, we always talk about building a particular integration, 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 and recover and resolve those to provide a centralized, one pane of glass to see how all the integrations in the enterprise are running in a holistic fashion. These are some of the key features that an [iPaaS?] 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 SaaS 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. Oftentimes, these companies are surviving based on vendor-built integrations. There might be a scattering of SaaS apps in the enterprise but it’s disorganized. The next stage is similar to the ad hoc stage but companies can now understand some of the limitations that have come about based on the model. They understand that they need to get a plan together. They may have a few foundational facets. And as soon as you have the foundational facets, you know that you have to go– it’s inevitable that you’re going to buy 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 optimized phase, in a nutshell, is you’re finding the right balance between– you have a plan. Certain mission critical integrations are handled by the IT 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 just cannot come in and start making changes, right, because there are gonna 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 bypass should be able to handle both the technical needs of an IT team, as well as the ad hoc 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 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’d like to say here is that it is okay if you’re in any stage here, including the ad hoc stage. I think the most important thing is to be aware of where you are and understand that there’s 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’re in ad hoc 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 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’d 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 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 IT or UPS and so there is a backlog as companies are buying all these different SaaS applications. The mission and integration is getting held up. On the other end of the spectrum, there are companies that are very decentralized. It’s kind of an 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’s oversight from the IT team. There’s a reason and a plan for everything. But the IT 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 McGranny to get into some of the other details around integration. Thanks, John. And we’ll begin with some of the pitfalls, and I’m going to echo many of the comments that Janet already had for you. The first is to be aware of the limitations of out of the box or vendor built 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 a vendor built integration. So in our case, that’s Zendesk for support, Jira for engineering tickets, and the integration works well both ways. Status updates have pushed in each direction and everyone’s happy. So there’s no need for us to look any further than that. But the thing to be aware of is that sometimes vendor built integrations merely check the box. If you’re a SaaS 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 go to them. 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 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 built integration keep up with you? For example, an integration, say between the CRM and the ERP, it might all be fine out of the box at the beginning. But as your offers become more complex and you introduce a CPQ, if that’s a third party CPQ, you now have three moving parts. Maybe you also introduced a subscription billing application, and all of a sudden you’re very close to the scenario that Jan described with quote to cash. And so you need to be sure that these vendor built 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 tempting to say, “Well, okay. System A and system B, maybe system C, they all have APIs. We could just build it ourselves. Build an integration ourselves 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 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 are 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 business needs 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 going to be static. So just be aware that you may well have an engineering team that they could indeed do it, but 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 evolution of companies, whether it’s in terms of the number of apps, the business processes 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 now to talk about some common integration patterns because I think you’ll recognize in here the sorts of things you’ll run into throughout your own organization. The first kind 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 ERP for billing purposes. It’s not necessarily, at the moment of synchronization, part of the 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 the skews in an e-commerce system. So synchronizing that data is really key, just to make sure 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 enough systems. 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. So the synchronization can actually be good for that as well, perhaps to take something out of a system or record, and get it into a collaboration tool just for 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 a data warehouse or data lake kinds of use cases, but also for synchronizing campaign results, say, from a marketing automation system back into the CRM. So it’s about providing 360-degree visibility so that you can build reports and so on, on there. And the final one here 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 applications. Typically, there’s going to be one or two systems of record in there, maybe different systems of records for different parts of the organization. For sales, it’s the CRM. For finance, it’s the accounting or ERP system. For support, it’s a case-management system. And when business processes cross multiple apps in this way as we’ve described, 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 wrap it all up, you need to think about your automation strategy and the way integration plays into that, and 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 [inaudible] 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 are the breakdowns occurring? What is it costing you, from 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 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 vendor-built integrations are not to be ignored. But finally, keep in mind, the advantages of using an integration platform, again in iPaaS, 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. 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 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 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 or automation strategy or would like to understand where you fit in in the maturity model, please contact us at celigo.com. Thank you so much.