Full Webinar Transcript
We live in the era of the cloud. For years organizations have increased their reliance on software as a service, SaaS applications. But too often that has led to the fragmentation of business processes across multiple SaaS applications. And that fragmentation can reduce a company’s agility and limit its ability to succeed in the era of digital business. The best way to overcome fragmentation is through automation and integration of business processes. Hi, I’m Stan Gibson, and I’ll be your host and moderator for this live webcast. Joining me to explore how to overcome business process fragmentation through automation and integration of SaaS applications is Jan Arendtsz founder and CEO of Celigo. Welcome, Jan. It’s great to have you here for this webcast today. Thank you, Stan. Again, I’m the founder and CEO of Celigo. Celigo is a SaaS company in the integration space or iPaaS, which stands for integration platform as a service. I’m excited to be here to talk about how companies can scale and grow their business through automation and ultimately through integration. Before we dive into our discussion with Jan, just a quick word about this webcast. Now we are live and interactive and that means we’d like to hear from you in our audience. Should a question occur to you at any time, just type it into the Q&A box and then press submit. We’ll do our best to answer your question during the Q&A segment toward the end of the webcast. Jan, I know you’ve got some great information to share, so I’ll hand things over to you now. Jan. Awesome, let’s get started. Today there is a SaaS app for pretty much everything that you can imagine. SaaS is pervasive, and we live in a best of breed SaaS world. But if you roll back the clock to 20 years back, there were only just a handful of SaaS companies starting with the likes of Concur or Salesforce that really made the end of software campaigns to really kick start the SaaS movement. If you go and look at the last 20 years, you can see that there has been waves of evolution where more and more companies have come in with SaaS solutions. And what’s interesting in this mix is that the new SaaS solutions coming to the market over the years have become more and more specialized. They’ve come in and taken a certain part of functionality out of the larger SaaS applications, and they’ve decided to go much deeper. And if you fast forward to today, we have this, kind of, wonderful scenario where so many companies across the globe have really embraced SaaS. And it is increasingly easier to purchase SaaS applications these days. As we all know, SaaS apps can be purchased at a centralized level and more and more at a decentralized level at a department or line of business. And while this evolution happens, there are more and more companies building the next generation of SaaS apps out there. These are exciting times. Let’s take a look at how typical companies use SaaS today. So this data is coming from a company named Blissfully, which is a SaaS asset management company and they do an annual report every year. To focus on the top three boxes, we’ll talk about the number of apps these companies are using. So there on the left side is a typical SMB company defined as less than 100 is and a company even that small is using approximately about 100 SaaS applications. On the far right here, there are enterprise companies defined as above a 1,000 employees that are using close to 300 SaaS applications. And then of course, in the middle, the typical mid-market companies using close to 200 SaaS applications. Celigo is a mid-market company as the CEO of Celigo, I’ve authorized us to be entirely in the cloud from day number one. I know whatever spend and how many apps we have and this is very analogous to this data. It’s not only that companies have a lot of SaaS applications, their spend is also increasing, which is that here in the chart below for mid-market companies. So you can imagine companies acquiring more and more SaaS applications, but their spend on existing SaaS applications is also increasing as they grow as a company. They have more employees. They have to go buy more seats so on and so forth. The bottom line is SaaS has been a tremendous success. It’s here to stay. And this best-of-breed model is only going to grow from here. So let’s take a moment to go look at how the companies acquire these SaaS applications? It is a fairly typical landscape of a company who might have started more in the sales and marketing arena. Because of course, every company wants to sell and then they may have an accounting system, they may have an HR application. And in time, they keep adding applications. They might be recruiting software, accounts payable or they may invest in a data warehouse and put a BI front to that. They may have a service desk and so on and so forth. As their needs become more sophisticated, they may add a CBQ or a billing-type application. And before you know it, most companies will end up with a diagram similar to this. So best of breed SaaS is what got us here, but it’s also important to understand that as we acquire all these applications that it results in a sprawl of facts. We call that the SaaS sprawl. Well, the SaaS sprawl also has a certain natural order to it. There are clusters of applications that eventually become somewhat siloed. But let me take a– let me show you a few examples here in the front office, typical sales and marketing functionality, you will see a number of apps clustered around the CRM. Then in the so-called back office, accounting and finance, and order processing and what have you, there are a number of apps that fall within that larger domain typically dominated by the ERP. Likewise, you may have the similar thing in HR. There are certainly company-wide apps such as email or collaboration software and then certain other apps around IT. if you look at how these apps are organized, you will see that we have those big blue boxes, the CRM, the ERP, the HR application. These are examples of what we call foundational SaaS applications. By that we mean that these are large SaaS applications that have a much larger footprint in the enterprise, and they are the system of record for key business objects. For example, the customer or the account, the lead, the sales order, the product master, the employee, the vendor record, the purchase order, so on and so forth. And in the SaaS evolution, as other SaaS offerings come to the market, they become more and more specialized. But certainly, they need access to that system of record. For example, a marketing automation system may need access to the lead, which is the system of record. Or in a different example, an expense management system might need access to the employee record, which is owned by HR. So even though we have these various different silos, there is a natural order to this. It’s organized in a certain way. And then, of course, the silos, by default, also cause fragmentation. Let’s take a slightly different perspective and put a different lens on this by looking at a typical enterprise through the lens of business processes. The business processes what I call the heartbeat of an enterprise. It’s the operating system. It’s what allows the company to function. And as you can imagine, as that SaaS sprawl starts to increase, a typical business process might now start to span multiple business applications. If you go back in time, back in the day, there were these large monolithic apps such as SAP, Microsoft, Oracle, where arguably these business processes all lived in the same application. The world has changed. It’s best-of-breed. You have choices when it comes to applications, but there is a price to pay. And that is a typical business process that is going to span multiple applications, and as a result, there’s going to be fragmentation. Fragmentation can be solved in many different ways. But typically, if– again, depending on the importance of the business process, it’s highly likely that a given business process that is facing fragmentation needs to be automated. So before we dive into an example of a business process, let’s lay out a few typical business processes in an enterprise. By the way, we have eight here. These are meant to be representative examples. It changes from company to company. And of course, it also depends on the stage of the company. Scanning through here, let’s take a few examples. Quote-to-Cash connecting the front office, the sales teams with the back office. I think most people know about that. Issue-to-Resolution [inaudible] revolution. If you’re selling to customers, customers might be submitting support tickets which needs to be resolved. That’s a business process. Hire to retire is a business process that we all can relate to. We need to hire employees so they start as candidates in a ATS type system. They get promoted to an HR application. We have to go through onboarding processes, deboarding processes when we part ways with employees. And then, finally the last example is analytics. In this day and age, there’s so much data around. Most companies need to make sense of this data. They need to be able to take data from their SaaS applications and put it in a data warehouse and look at it through a BI type tool. So let’s look at a quick example, and I’m going to use Quote -to-Cash here. Starting from the left, in a typical company that has a B2B model you might have a sales rep who is going to create a quote, going to create a proposal. That proposal might go through a deal desk; it’s sent out to a prospect. Ultimately the order is booked. It might be approved or rejected by the finance team. It gets provisioned or shipped. Then you invoice the customer and then you collect payment. Right? Seems pretty straightforward. In a fairly simplistic scenario this type of business process might be encapsulated in one or two different business applications, but as a company’s needs become more sophisticated, there’s a high likelihood that this business process can span multiple applications such as a CRM, a CPQ for creating your proposal, electronic signatures, an ERP or a specialized billing type application; and as time goes by you’re going to start adding even more applications. Right? So just use this as an example– back in the day this could have been all in one app. When you get started, it might be within two, three apps and then before you know it it’s spread across multiple applications. And this is fragmentation in action. If all this data lives in various different applications, then one app doesn’t necessarily know about how the data is presented in the other app and this causes problems. And in order to resolve this, automation of key business processes becomes paramount. So what’s the cost of fragmentation? Here on the left is– the first thing I would mention is visibility and the integrity of the data. Right? If you don’t have access to the data, if you cannot see data from further upstream or downstream systems, then it is siloed. And if you have to then manually enter data into multiple applications that causes errors, delays, so on and so forth. And then there is a compounding effect. Because of the lack of visibility and integrity, then you’re not as efficient as a company. You might need additional resources to handle the increasing volume. And then finally you’re not as agile as you need to be. And this of course all adds up and it ends up with making an impact, sometimes a significant impact, in scaling and growing a business. And this brings us to this concept of a connected enterprise. Because business processes, as discussed before, typically span multiple business applications, there’s a need to automate these business processes. And if we need to automate a business process it is highly likely that you need to integrate, connect, move data around between multiple business applications. So what are some of the options for a connected enterprise. The first is a fairly low-level construct, which is using APIs to cobble together a certain workflow. We call it custom coding. It is something that a typical IT team, a developer might come in and write a piece of code, whether it’s a standalone piece of code or it’s running on another SaaS application platform. Either way, it’s not designed to be scalable. It’s not going to have some of the basic infrastructure such as error management. It’s pretty brittle and hard to maintain. Second option that we see often is some fairly domain-specific solutions. P2P, it stands for point to point. So the focus is there are a number of either product companies or consulting companies that have come in, used their domain expertise to solve problems in a fairly narrow domain. And these solutions, given that it’s not really built on a platform, right, it’s meant to be pre-built, and as a result, it’s a black box when it comes to the end customer using it. It is what it is. You might have some minor tweaks that you can make to it. Again, they are fairly static and hard to customize. The third category that is becoming more and more prevalent is the integration built by the SaaS vendor themselves. Of course, the SaaS vendor ultimately has ulterior motives, and that’s to sell their product, and they want to do what’s needed. Oftentimes, they call this just checking the box to be able to build certain types of integrations so that they can move their product. And then, of course, finally, there is the iPaaS category. Let’s expand on that for a second. So again, iPaaS stands for integration platform as a service. And in a nutshell, an iPaaS is there to allow you to standardize how applications and data are connected across the enterprise. So whenever we talk about an iPaaS, there are two larger categories or buckets that we’d consider. One is actually building the integrations or building the workstreams. The second is once you’ve built a certain workflow and it’s in production, how do you manage and maintain that? They’re both very important components of a large iPaaS solution. To zero in on building a particular integration or a workflow, what an iPaaS does is it allows you to be able to connect with any number of applications. It typically has a more generic way of being able to connect to any type of API or REST API, database, any file system, but then it’s also going to have a number of named connections to well-known business applications. And as part of this process, then it’s just going to have a bunch of table stakes type functionality, such as guaranteed data– the ability to [drive?] data at any time, and also provide governance and compliance so that this data is managed in an appropriate fashion. On the monitoring and management side, a typical iPaaS is going to have a number of tools to be able to help you run this integration on a daily basis. If there are errors, it’s going to give you a listing of those errors. It’s going to help you make sense of it. It’s going to help you fix some of these errors, and in certain cases, suggest how these errors can be worked automatically. There’s a lot more that an iPaaS does, but that should give you a quick understanding of the overall influence that an iPaaS has. So far, we’ve talked about the business applications. We’ve talked about business processes, and we’ve introduced the concept of an iPaaS. Now, let’s take a moment to talk about how a typical enterprise is going to think about integration, and that’s where we introduce the concept of an integration maturity model. What this does, it outlines the various different stages that companies go through when they start thinking about integration. So there on the left side is what we call more of an ad hoc model, where typically found in smaller companies, the companies that are not that mature, where they think about integration in a fairly rudimentary way, where they have a certain pain point. They’ve acquired a business application that perhaps needs to be connected. The focus is only to solve that problem or a few different sets of integrations, but not necessarily to plan how the entire enterprise is going to work. On the other extreme, and a bookend in this on either side, is what we call the optimized and empowered phases. In those models, companies think about integration in a much more holistic fashion. It’s almost like if you were to go to a certain extreme, you think about integration more as a first-class citizen well, as you are acquiring the SaaS applications you are thinking about how you’re going to automate your business processes, how you’re going to have a connected enterprise, and then you invest and you have a certain staffing model to be able to get that done. We won’t go through every single phase of the integration maturity model here in this session but I think one important takeaway that I always like to tout is whenever a company is planning their automation strategy, their integration strategy, so on and so forth, it is important to understand where they may fit in this model. It is okay to be anywhere in any of these five stages. That’s the first thing to understand. If you’re more to the left side then know that you’re doing it for a reason and understand that there is arguably a better way to do it that is more organized and that’s ultimately going to help you scale your business better. And if you’re not ready for that, that’s okay. Try to at least understand that this is where you might aspire to get to and then try to build a path towards that. More and more we’re seeing companies fall somewhere here in the middle three sectors and even smaller companies these days are starting to get beyond the ad hoc stage and think about integration in a more holistic fashion. Along with that model comes also from an IP perspective, how do you think about integration? So back in the day, IT used to hold the keys to the kingdom and everything tended to be centralized. Well, that works pretty well until you end up with too many SaaS applications and too many business processes that need to be automated that IT cannot really keep pace. Another model that we’ve seen is more of a decentralized model where it’s akin to the Wild West where everyone is coming in and building integrations. There’s no master plan per se. So it’s very reactive. It’s fluid, but ultimately it’s also not going to scale. It’s good for a sudden phase within a company’s lifespan, but at some point, definitely is not going to scale. The model that we see more and more today, and of course, the model that we promote is what we call a federated model. As the name implies a federated model is designed such that certain key processes are owned in a centralized fashion typically by IT or ops. So the quote to cash business process that we talked about is a difficult process since it’s cross-departmental, touches so many different facets of a business. That’s centralized but there might be some other business process that needs to be automated that’s fairly localized that can be done by different teams at a departmental level line of business level. So on and so forth. And so the bottom line is the federated model gives you the best of both worlds, right? It allows centralization but it also increases the number of folks and the enterprise that can touch and build and manage and maintain integrations, and it gives you the best of both worlds. So to summarize, how should you think about an automation strategy? The first thing to consider is to go ahead and map your business application landscape. And as simple as it sounds, it’s fascinating to know that a lot of companies don’t even know how many business applications that they have in the enterprise. And this is something that we see all the time. Then go ahead and itemize your key business processes. Understand what needs to be automated and then understand the cost of fragmentation, and if it’d end up doing nothing, how does fragmentation impact your ability to grow and scale the business? Once you’ve come up with a massive list of business processes, you’re going to figure out which ones require automation. Go ahead and prioritize that, and then finally think about an integration roadmap. Think about the integration maturity model in terms of where you want to be, where you are, what you aspire to be, and start planning the integration work to be able to automate these business processes and have a connected enterprise. And that’s fantastic information. I’d like to jump in if I might and just remind the audience to please send in your questions. So just type your question into the Q&A box in your screen, then press the submit button, and we’ll answer your question if we possibly can during the Q&A segment, which is coming up shortly. Yeah, and I do have a question of my own if I might ask it. When it comes to the available options for integration that you mentioned a few slides back, outside of using an iPaaS, it seems like the SaaS vendor built integrations are the most promising and perhaps the default option. Now if SaaS vendors build the required integrations, shouldn’t that solve most problems? And if not, what are the limitations of these vendor built integrations? Yeah, that’s a great question, Stan. So let me take you to a slide here. Yeah. So I think I mentioned this before as well. If you’re a SaaS vendor, your perspective is that you want to be able to sell your product. So you’re going to go ahead and build an integration that checks the box. It is not built on an iPaaS, which means that it’s not going to be as flexible. It could in certain cases be somewhat brittle. And if you wanted to customize that particular integration, let’s say one of the applications has a custom field or a custom object that needs to be utilized, it becomes harder in certain cases impossible to do. Another thing is these integrations are point to point. It’s not like that particular SaaS vendor is thinking about a larger business process and it’s trying to connect their app with two, three, four different applications. So it’s typically connecting the app with one of those. And that all aside, I think the key limitation is that these integrations, the ones built by a particular vendor really don’t know or don’t care about the existence of other integrations. So if you take a step back and you look at that SaaS sprawl and if you think that every vendor has built one, two, three integrations, you have all these integrations running around. They don’t know about the existence of other integrations and you don’t have, ultimately, that blueprint. That idea of connected enterprise because it’s built at a very local level. That said, it is in certain cases, these integrations work well or they’re going to work well for where that company is in their journey, as well. And our recommendation in these scenarios is to use it until it becomes fairly clear that there are limitations. And then you can either attempt to augment these integrations with additional workstreams to solve some of the limitations, or entirely replace these integrations. John, you outlined an automation strategy where one of the items was an integration roadmap. I’m wondering if you could perhaps explain just a bit further about formulating such an integration roadmap. What are some points to consider? Yeah. Let me take you to the right slide here. Here we go. So things to consider when organizing an integration roadmap. I mentioned this before as well. First, understand where you are. If you’re trying to fix a problem, the first step should be to recognize that you have a problem and understand where you are. Then understand who’s going to do the work, what kind of a team do you have at your disposal? Do you have an IT team with enough bandwidth? Think about the federated model because using that model you can centralize certain key business processes and bring in others from various other departments to do some additional work. Of course, try and prioritize. Trying to do everything at the same time doesn’t work. Sometimes you’ve got to build a particular integration, see how it works because there is a cascading effect. There’s an impact on other business processes as well. As I said in the last segment, definitely leverage the out-of-the-box integration. Then just going back to the point I made before. If you have a bunch of out-of-the-box integrations with Vanderbilt integrations running around it becomes chaotic. But if you know of them and you plan to use them because it fits into your blueprint then that becomes absolutely okay and makes a lot of sense. And then of course lastly, if you really want to do this the right way, especially if you want to think about integration and connectivity as a first-class citizen, then you definitely need to consider an iPaaS to be able to have this connected enterprise. Thanks, John. Well, that brings us to the Q and A segment of this webcast and there is still time to send us your question. Again, just type it into the Q and A box and then press submit. Our first question is, John, even if you use an iPaaS solution should you invest in building a team to manage these integrations in-house, or is it better to hire an outside expert or consultant? Right, so this is a question where there is not necessarily a right answer. In general a company– if you’re taking automation and integration seriously you need to invest and you need to have a team because it’s not a once and done thing. It is something that you’re going to build and then continue to refine. If it helps to get an outside party to get you organized, especially a party that has the right experience who can look at your application landscape, look at your business processes, help you get an inventory and itemize these things. That makes a lot of sense. If you don’t have in-house expertise, and you are trying to find the fastest possible way to solve some of these critical problems, then absolutely use a third-party consultancy. That makes sense. But I think in the long term, the understanding is supplementing your internal resources with external resources is a means towards an end rather than an end in of itself. I see. Next question. How does Celigo manage its integrations internally? Right. So Celigo, like a lot of companies, has been on a journey. To be transparent, when we were a smaller company, we subscribed unknowingly to that decentralized model where it was– and especially given that, of course, this is what we do for a living, it’s easy to go build a number of different integrations. So we’ve kind of oscillated between the centralized and decentralized model to some extent. We went from just being totally chaotic in the very early days to building centralizing things and now, we are definitely subscribing to that federated model. We have a number of business processes that are centralized. I mentioned the Quote-to-Cash business process. That’s a key business process for us. There are certain other business processes around pulling in product data, operational data that’s centralized, but then on the same token, we have a number of other business processes that are at a local level. There might be certain use cases around sales and marketing or our customer support team that those teams have gone in and built themselves. And obviously having some oversight and jurisdiction through our centralized ops team, but we’ve evolved into a model that’s entirely federated, and that’s the model that we’re going to stay with. That’s great, Yan. We have time for one more question, and the question is are there times it makes more sense to integrate directly via API instead of going through an iPaaS? Yeah. So I would say on this one that the default should be to use an iPaaS. There might be some exceptions as is the case always where there’s a particular use case, and I’ll give you one quick example. So let’s say there is an integration that requires an absolute real-time loop. It’s what we call more of a blocking interface. So let’s say there’s a sales user on a particular application. They’re on a web page, and they take some action, and they are waiting to get a response because behind the scenes seems there are plumbing that’s going to connect one, two, three other systems together. My past solutions may not support this model which we call true real-time because, typically, a number of iPaaS solutions will really look at this as scheduling data or being able to run it in near real-time. So that’s a situation that we run into. Just to be clear, Celigo’s iPaaS Integrator.io does support real-time. So you can go ahead and benefit from all the advantages that we have in having a full iPaaS to be able to make a true real-time call like this. But that’s just one small example wherein certain situations based on what you’re trying to do and the iPaaS that you’re considering might not be the best bet. Thanks, Jan. It looks like I spoke too soon. We do have time for another question, and the question is how much effort is needed to follow up and monitor these processes? Right. So we have a saying sometimes that building the integration is all things considered even though it might need to be planned and time-consuming, the key is how much time are you going to spend once you put it into production? So again, there’s no one single answer. It really depends on the business process that’s being automated and also how that particular iPaaS may convey that data. So I’ll give you maybe one quick example. If done right, there might be still a number of errors that you get into. Quick example is you might be referencing a product master where you have the wrong ID. And this causes not one error but let’s say hundreds of errors all related to the same core problem. Well, if the iPaaS is designed correctly, then it’s going to be smart enough to recognize that there are errors that it needs to make sense of these errors and be able to organize and group these errors and even going to the extent of being able to suggest to a user such as an administrator to be able to fix an error. And of course, the ultimate scenario is if it’s smart enough, it’s going to learn by the administrator’s actions and then ultimately be able to go fix it for the user as well. So these are many different levels. If you don’t have all those skills, then, yeah, it can be sometimes a drag in particular scenarios for particular use cases where that management might require some time. So so many different ways to handle it. It just all depends on the circumstances, the use case, and then of course the capabilities of the iPaaS that you’re using. All right. And indeed we have time for yet another question, and the question is when you’re integrating between two SaaS apps hosted on Azure with Celigo, and part of the integration is moving data between the two SaaS apps, does the iPaaS move the data and act as sort of a man in the middle or not? Yes. So I think the person asking the question is saying if they’re both running on Azure, then does the data need to leave Azure? So taking a step back, look, our platform Integrator.io runs in the cloud. And so if we are trying to connect two different applications and move data between one to the other, then we will go into one application, pull that data, it comes into our hub, and then it’s pushed into the other system. We don’t hold on to the data. It’s just in transition. But as I said before, one of the key features of an iPaaS is to ensure that this data is delivered correctly, on time, guaranteed delivery, and that’s what we do. So the short answer is, yes, we are the man in the middle. I see. Very interesting. That’s great information, Jan. Thanks so much. That is all the time we have in this live webcast. Sincere thanks to Jan Arendtsz founder and CEO of Celigo for explaining how fragmentation takes place across SaaS applications and how the Celigo integration platform as a service can automate and standardize the connection of applications and data across your organization. For more information on this topic, please see the resources area of your screen. And thanks for joining us. For Celigo and IDG, I’m Stan Gibson.