Whether you’re raising your first round or preparing for an IPO, scalability is pivotal to success. To achieve this, you need to get your processes in place – and this starts with effective automation & integration. Yet, there’s a lot to balance and prioritize – including quote-to-cash, procure-to-pay, hire-to-retire, marketing automation, reporting and analytics.
In this on-demand session, integration expert Matt Graney provides a practical guide to help you create an integration roadmap – without significant IT investment. You’ll learn how to prepare your business for high-growth and enable your company to scale through effective automation.
- Review of typical business processes and prioritizing what processes to automate
- Our roadmap for automating quote-to-cash that helped us get to $25m
- How to start building your own integration roadmap
- Why an agile approach to automation is important
Full Webinar Transcript
This is about defecting business processes and how they can be so key to enabling a company to scale. So let’s get started. Maybe before I do that, I’ve been with Silico for four years as VP of Product. Probably six years, also, in the integration space and about 20 years in B2b Product in the San Francisco area. So let’s get into it. Okay, so the first thing to– to recognize, of course, is that companies are made up of business processes. And here we see some of the typical business processes that you might run into in software companies. Some of these you would recognize by their names. Things like quote-to-cash, for example, effectively how you’re going to get paid. But over time, these processes need to evolve. These business processes, of course, exist whether you’re automating them or not, right? Procure-to-pay, for example, is all about how you manage the payment of vendors and suppliers. The importance of these business processes changes as a company evolves, right? At the early stage of a company, you might not be hiring many people so thinking about the full employee lifecycle is not that important yet. If you’re in the expansion stage, you might be hiring tens or hundreds of people in a quarter. You need to think about how to automate that. How to make sure employees are properly onboarded and offboarded, as well. Similarly, when you get further into the journey, what might have begun as purely operational business intelligence needs to turn into much deeper analytics. So business processes, of course, are integral to– to running a business. And as a business matures, the importance of these and the need to run them efficiently increases. So it used to be that– that you could just go off and buy a large software suite and they would claim to take care of everything. One-stop shopping, a complete suite of software. That, of course, came along with multi-u deployments, very slow to get live. But what we’ve seen over time is a sort of a fragmentation where the Cloud, in fact, has allowed this. The Cloud has allowed rapid deployment. It’s meant businesses are easier to start. It’s meant that software is easier to acquire as the spend has gone down, even with the spend moving from capital expenditure to operational expenditure, and indeed the spend moving away from central IT into each department. And so what used to be features of a major software suite, now might actually be entire companies. And categories of software that didn’t exist some years ago are popping up all the time. So this is an inevitable nature of– of the software space today for software businesses, and so the prevalence here is towards a best-of-breed solution that leads to what we would call a sprawl of SAS applications, tens or maybe hundreds of such applications. And yet these applications are what– running your business processes. You can be sure that each one of these icons you see on the screen are not designed with all the others in mind. So you end up with a lot of silos and it makes your business processes rather fragmented. So how do you stitch it all back together while still allowing your teams the flexibility they need to choose the right tools for the job So it’s ultimately about becoming a connected enterprise. Business processes not only span multiple departments, they span multiple business applications. So in order to perfect these processes, as we talked about, and to get to automation, you really need some level of integration. How are these different apps, as I said, that weren’t designed with each other in mind, how are they going to communicate with each other? So when looking at this problem, you have a number of options for how you’re going to connect your enterprise. The first is really to deploy your own engineering effort and build custom integrations. So this can be a quite expensive proposition and is maybe okay at the beginning, but it tends not to scale. As the business processes evolve, as I suggested at the beginning, as a business matures, the software landscape changes. It makes it difficult to keep up and ultimately rather hard to maintain. Applications change over time, introducing new capabilities, new interfaces. And how are you going to keep up with those? So that’s one option. Another is very specific, third-party, point-to-point solutions that focus just on one problem. So these can work too, of course, but they’re often a black box. And the moment you start going outside the boundaries of what they’ve defined, they become very difficult to use and hard to customize. Many integrations, of course, are built by software vendors themselves. If you want to, as a SaaS provider, if you need your app to integrate to one of the gorillas of the SaaS base, you’re probably going to want to build it yourself. And this, of course, is important, and it will often allow the most basic requirements to be met, but they tend not to be built with customization in mind. So, for example, it might work fine if you’re using all the standard business objects out of your CRM or your ERP. But over time, as your business matures, you want the flexibility to adapt those large hubs, if you will, of SaaS applications to adapt. And sometimes these vendor-built integrations won’t keep up. So each integration vendor, then, doesn’t really know about the existence of each other and you end up with quite a challenging problem to manage in terms of impact analysis. The final option here that I want to talk about is IPASS or integration platform as a service. So at the beginning, I didn’t mention what Celigo does. So maybe no surprise to say that Celigo itself is an integration platform as a service, and this is a key competitive advantage for us because we’re able to use our own product to solve our own automation of business processes problems. So what an IPASS does, it’s a whole class of software. If you’re not aware of it, I recommend you check it out, because it’s one of the fastest-growing segments of B2B software today. So what an integration platform does, as it says on the box, it sort of is a platform that brings all the integrations together, and it’s typically delivered as a service. And this allows the integration of cloud applications to be standardized. It allows it to be centralized. It allows it to evolve with all the right sort of controls in place, providing solutions such as governance and compliance. Guaranteed delivery of. between applications and generally a lower cost of maintenance. So, again, this is a bit of a competitive advantage to us because we are, in fact, an iPaaS vendor ourselves. But there are a whole segment of tools out there that do this and solve this problem. All right. So that’s just a bit of background. We know that businesses are made of business processes that are increasingly powered by a broad and disparate set of applications that you somehow now need to stitch back together to make coherent business processes. So let me talk now from our own experience at Celigo, using ourselves as a sort of a proxy for what mid-market software companies have to get through. Early mid-market, I may say. So let’s talk specifically about some of the key integrations that helped us get to our first 25 million in [ARA?]. So we’re a Series B start-up and we’ve been around for a little while, and this app landscape has changed significantly. In fact, as I prepared for this, I thought about my four years at Celigo and I thought about all the logos that weren’t on the slide when I joined. HubSpot wasn’t there, Paystand, Concur, Gainsight, LiveChat, FinancialForce, G2 Crowd. There were many of them that have been added along the way. But you can see that there’s a mix here. First off in the orange, those where we’re using native integrations. These are the integrations that are built out of the box. So, for example, between Zendesk that our support team uses and Jira used by engineering. What we found is even as time has gone by, the out-of-the-box integrations serve our purposes very well. But then beyond that, of course, we’ve expanded. And so whether it’s the integration between our CRM and Salesforce and our financial system in the form of NetSuite, to ensure, for example, that as opportunities have closed, one, in Salesforce, they become sales orders in NetSuite. All these integrations have been critical to us along the way. And so it’s a mix here of being pragmatic, using the vendor-built integrations where it makes sense and developing our own, of course, using our own platform as we go. So this application landscape is probably not too different from what you have at your own companies. And so how do you go about solving a problem like this? Sometimes we talk about kind of the hairball of integration. Can get pretty complicated. You have major hubs, whether it’s the ERP, the CRM, marketing, automation, and so on. These different hubs that are so critical for different parts of the business. They represent effectively a system of record for different parts of the business. How do you stitch it together? So let’s talk then about building your own integration roadmap and the steps that we would recommend. The first is to think about your data hubs. Already mentioned this a little bit. Here are the ones that are important to us. Again, for example, on here gain site as our customer success hub wasn’t in the picture really until about 18 months ago. So you need to know really what’s important for different parts of your business and really which part of your information is going to belong in which system. Then the way you approach integration will depend a little bit on your own maturity. If you’re in the [inaudible] stage, then you may be okay at the beginning with sort of ad hoc integration. But as you move forward, you really want to get to, for growth companies, get towards this optimized stage. And one of the features of this stage is that there’s some federated development, meaning things are brought together into one system. And yet there’s still some decentralization, where individual departments, not just IT, can get the job done when it comes to integration. One of the key areas here that we have to keep an eye on when thinking about automating business processes is the total cost of integration. I’m sorry. Yeah, the total cost of ownership for integration, I should say. As I’ve already mentioned, you need to think about the limitations of out-of-the-box integrations. So when you buy a software app, for example, it’s going to say, yes, we integrate with CRM flavor of the month or flavor of the last 20 years, perhaps. And that may be fine. It’s really a good place to start. And I think in our journey, we’ve used those well along the way. But they often will just check the box, in that they are often very point-to-point and don’t tend to be all that flexible. So for example, if in your CRM you’re no longer using the out-of-the-box opportunity object, for example, you’re using something completely custom, then it will probably mean you have to leave those out-of-the-box integrations behind, as well; say, the integration with your marketing automation tool. So you have to think– you’ve got to know when you’ve hit the limit of those out-of-the-box integrations. You also, as you’re building this roadmap, you need to beware the lure of do-it-yourself. Old companies, you have your own engineering team, your own IT team, and that may well say, “Hey, look. This is just software. We can build this ourselves.” And no doubt they can. However, it can be a little bit complicated. And is that really where you want to be spending your resources in automating your own business processes? And you will find that you might get version one going okay. But can you really rely on your own engineering teams to continue to evolve those integrations as the business evolves, as the business needs change? On top of that, you also have changes in APIs, the integration interfaces that are being exposed by various applications. You might have a CRM that has three releases a year, an ERP with two releases a year. And obviously, there’s a lot to keep track of. And there’s an advantage to relying on an external vendor sometimes to handle a lot of that compatibility for you. You also need to think about prioritizing and organizing. You can’t do all this at once and you shouldn’t. You need to think about a roadmap that’s based on, of course, like any backlog, impact, cost, complexity. And so if I give you a specific example here, let’s look at reporting and analytics. And this is sort of a simplified view of where we are today, where from a financial point of view, Oracle NetSuite is the system or record for a lot of our customer data. We’re getting that into a big Cloud-hosted Postgres database. We’re getting a lot of product information from Splunk for real-time logs, sort of static data from Mongo, and more dynamic data out of another database called Influx. So this has served us quite well to date. There’s a lot of data, but not too much for a Postgres database. And it gives us a fair bit of insight that we can make actionable. But this is grown over time. This is part of what we call our data room project. And over time, as we evolve, we’re looking to add more, get more opportunity data in from Salesforce, for example. Integration will evolve as our needs evolve and in this case, really drive a number of business processes. It will improve our ability to get better insight into our customers and ultimately, drive even the product roadmap because we’ll see more of what’s being used by various parts of the business. We can also think in terms of the deployment model here. When you think about automating business process, think about how you’re going to think about repeatability, how much reuse you can expect, the overall total cost of ownership, and ensuring that you find the right balance between solving every department’s problem for them versus giving business teams the ability to control their own destination– their own destiny, rather. Automating business processes, it’s a technical challenge. Because you’re talking about how to get a whole host of [SAS?] apps that have been acquired by different parts of the business, brought together all into the same interface, and ensure that there’s a smooth transition and that business processes can be made as efficient as possible.