Welcome to the Post-Digital-Transformation Era.
At this point, companies have fully embraced the cloud. As we enter the second decade of SaaS applications, most companies are actively adopting dozens, even hundreds of best-of-breed business applications across multiple departments — and the pace is accelerating. In this era, the question is no longer about moving to the cloud. Instead, businesses today are much more focused on maximizing the return on the increasingly significant investment presented by cloud applications as they mature.
While business apps today are simple to use, easy to set up, and address every conceivable challenge any company faces, the best-of-breed strategy is not enough. As each department adopts its own set of apps, the number of silos across the organization grows, As the siloed data creates bottlenecks, individuals may take matters into their own hands and create spreadsheets, transmit data via email or engage in other manual processes to move information along. This is not only a drain on resources, but it inevitably leads to costly errors, a lack of visibility, slowdowns, and security issues for the entire organization.
Every growing company will encounter these manual bottlenecks. This might not be an issue for early-stage companies with low organizational complexity, volume of data, and technical resources.
But at some point, broken processes become untenable, particularly when foundational SaaS apps such as CRM, ERP, or HCM are implemented. These apps are the official system of record for several key business objects for any company. For example, ERP owns accounting and customer records, CRM owns sales and prospect records, and HCM owns employee and hiring records. Due to the nature of this information, they are touched or are provided by many different processes that span across departments.
Beyond the bigger foundational apps, individual departments begin to adopt their own domain-specific SaaS apps that may include other systems of record, such as Marketing Automation for Marketing and Ticket Tracking for Support.
This translates into holistically thinking about business process automation throughout the organization. The need for integration — the ability to connect two or more applications together — suddenly jumps to the forefront of the conversation and becomes mission-critical for the company to succeed.
Integration is a key component of any robust automation strategy, but depending on the pain being felt, what’s at stake, and where a company finds itself in its lifecycle, the specific integration approaches differ significantly.
The Integration Maturity Model
The concept of a Maturity Model is a well-known framework that articulates “the ability of an organization for continuous improvement in a particular discipline”. This helps companies and teams understand the challenges they face and where they might be headed based on where they sit in the maturity model. For example, while the accounting team of a young company might slowly manage expense reporting via email, spreadsheets, and paper checks, more mature accounting teams have fully-automated systems with real-time dashboards that provide insights into total spend by departments.
Having provided integrations for thousands of companies over the last decade, Celigo has identified certain integration trends based on a company’s own operational readiness. The result is the following Integration Maturity Model to help companies understand their own integration readiness:
The Approaches to Integration by Stage
The integration approaches vary significantly depending on the stage of the company’s lifecycle.
Ad-Hoc
An early-stage company’s first order of business is to find product-market fit and by definition haven’t settled on long-term business processes yet. At this stage, while manual processes abound, integrations are pain-point based and reactive, driven by individuals solving their own issues on an as-needed basis.
Limited
Gradually companies start to grow and adopt more SaaS apps. While there is more attention to operational issues, integrations tend to be reactive: an app is acquired, a particular pain is felt, and there is an immediate need that needs to be solved right then and there. The typical first response is to rely on out-of-the-box native integrations, vendor-built integrations, and in some critical cases, build a direct API integration with technical resources.
Developing
At this point, companies are working across departments to get much more defined with their business processes, key Foundational SaaS apps have been implemented, and more and more SaaS apps are regularly adopted. As a result, the need for integration has increased exponentially. However, at this point, the previous ad-hoc and native integrations start becoming a problem in themselves.
- A company might have dozens of applications integrated via a hodgepodge of native integrations, multiple vendor-built, point-to-point integrations, and direct API integrations. This quickly becomes a maintenance and compliance nightmare to track and update.
- This integration approach is very limiting, handling only specific use cases that were built out of the box for two specific applications. If the business processes begin to have more sophistication, or if they span three or more applications, this may require customizations that are largely unsupported.
However, because processes are better defined, companies at this stage are better at proactively identifying operational issues and the requirements to address them. This is the point where consider or even adopt an integration platform, or iPaaS, to accelerate the time needed to build and reduce the cost to maintain these integrations
Centralized
As app adoption and integration needs grow, companies dedicate resources towards IT that are tasked to holistically build and own integrations across departments. This centralized set of resources with technical know-how is best equipped to identify integration requirements across the board, and to collaborate with different teams to design solutions to automate business processes across departments.
At this point in their integration journey, many companies have an iPaaS and have federated it for both IT and business users to build and maintain the integrations that suit their needs.
Optimized
This is the Holy Grail of the integration maturity model. At this point, the organization has mostly moved away from a “pain-point” model of integration; instead, integration is seen as a strategic advantage to proactively get ahead and drive the business forward. These companies have built an automation flywheel that is continuously optimizing business processes, integrations are fully standardized on an iPaaS and federated across departments, and IT is actively seeking ways for the company to do more with fewer resources.
Where Does Your Company Fit In Integration Maturity Model?
Chances are, your company is feeling the pain of manual processes and lack of visibility that normally comes with the adoption of business apps at scale. It is ok to be on the left side of the integration spectrum, as long as you understand where you stand, and what you and your company gains by proactively driving your integration strategy to the right.
The post Introducing the Integration Maturity Model appeared first on Celigo.