A core component of many digital transformation programs is the modernisation of business applications such as CRM, HCM and Finance systems. Modern SaaS solutions tout the ease of implementation with hundreds of pre-built connectors that will have your new system seamlessly embedded into your environment in no time. In our experience, however, this is not always the case. One of the big contributing factors to delayed or failed implementations is a lack of strategic thinking around integration; notably, not understanding that integration is not just about pushing and pulling data between applications, but about operating end-to-end business processes that often span more than one system.
Approaching integration design from a tactical, ‘data pushing’ perspective often comes with a high risk of the business process failing in one of the downstream systems. In this article I will run through some key issues I’ve seen organisations face in this situation when they underestimate the impact on their business processes in application integration projects. I will then present recommended approaches and thinking that can help mitigate these issues and ensure your application integration is not only successful, but robust enough to cope with future change.
System vs Business Process Mindset
When we think about implementing a new application (or building integrations for an existing one), it’s easy to think about processes as they occur within that application. Many organisations are encouraged by the ‘point-to-point’ system mindset favoured by vendors; the idea that after configuration, included connectors will slot everything together and start to push and pull data from other applications.
In reality, most business processes will span multiple systems, applications and/or departments throughout their execution. Additionally, while proposed integration ‘accelerators’ or connectors can be helpful in a tactical sense (and particularly effective for smaller organisations with simpler processes), they cannot replace strategic thinking about integration design and downstream process impacts.
Sometimes these impacts are significant and can show up in unexpected ways. For example, a recent implementation of a new HCM system removed the flexibility that employees had previously enjoyed in their work schedules. Where before they could choose up to the minute work schedules, they were now required to choose from a restricted dropdown list due to the new system’s usability limitations (e.g. “5 day work week” or “9 day fortnight”). This discrepancy only surfaces when analysis of the end-to-end onboarding integration business process occurs. With a proper integration process we could work around this limitation by pulling finer-grained work schedules for employees from a different custom field, restoring the employees’ flexibility and choice across all systems in the HR landscape. If it was simply a matter of pushing data between systems, these employees would have lost their work schedule flexibility.
Benefits of a Business Process Mindset
Taking the time to understand your end-to-end business processes and factor them into integration decisions can make a huge difference to the success of your implementation. Below I’ve listed some of the major advantages of taking this approach in your system implementation.
Meeting all Data Requirements
Business processes should dictate what data is required in which system and at what time, although your process design may need to make allowances for system requirements and capabilities. An awareness of the full process’s data needs will make a considerable difference to your integration quality and whether it ultimately serves business needs. In our opinion the business process is intimately related to the data modelling.
For example, when asked what a Learning Management System needs to create a new employee, you might reply ‘Staff Data’ – this seems pretty obvious. An integration could be built to provide that information when it’s needed. But if you look at the full process, a staff member cannot complete the on-boarding process if the system doesn’t also have information on required learning modules. Without a consideration for the end-to-end process, this information is missed and may cause major holdups down the line.
Better Business Exception Handling
When building integration solutions that focus on a particular system or set of systems, it can be easy to focus on the technical side of things. Technical errors and configurations are often thoroughly tested, but the business functional team should also be sure to action business exceptions. This is much easier to do when you think of it as a full process with process exception cases. Frequently when we ask ‘what business exceptions do you need?’ people will think of A, B and C. But if we take the time to ask ‘walk me through the full process – what happens to the data after this? Where does it go? Who needs it there and why?’ Then they’ll start to remember exceptions D, E, F and G too.
Better Customer (or other entity) Experience
A classic process issue for large organisations is the transition from customer onboarding to service delivery/long term relationship management. Though customers expect a consistent experience across all their interactions with a company, in reality they often receive changes in service quality and experience repetition once they move into current customer processes.
This issue can be exacerbated by integrations that do not consider the full customer onboarding/lifecycle process. For example, does the customer experience system that signs the customer up to a new service capture all information required for the CRM system to manage service delivery (e.g. missing address or missing date of birth)? The same problem can be found in other kinds of experience – such as end-to-end employee or investor experience.
Recommendations
We typically put emphasis on good integration business analysis as part of our integration services, as we know a quality integration means more than just integration development done by developers. It also needs the business analyst role, the integration design role to identify and implement patterns, good SIT testing etc.
Keeping this in mind, see below some key recommendations that can help you avoid process issues in your application integration.
- Design and document business processes before you purchase a new solution, then slot in system components to fill the required capabilities (rather than the other way around). This can help ensure you are making right-fit technology investments to fulfil the intended processes, rather than purchasing a system and realising it does not meet your needs. That’s not to say you cannot successfully integrate around a chosen system beforehand, but then all levels of an organisation need to fully agree with the new systems’ processes and concurrent limitations.
- Engage the integration capability (whether it be an external consultant or your internal integration owners) during business process definition. This way business processes can incorporate items identified by integration capabilities, and integration design can allow for changes in strategy and requirements. This requires you to build a business case from the start for integration, and have a true appreciation for its value and opportunity to enhance your process design and execution.
- Govern not only the data but also the business processes. For example, follow up on business exceptions, define them as part of the process, understand how data quality impacts the process, and ensure data and process domains have clearly acknowledged data & process ownership and stewardship.
- Make integration a first-class citizen with appropriate planning and strategy. Taking the time to appreciate integration impacts and building a solid integration architecture will allow you to switch systems later without catastrophic impacts on your business processes. For example, if you run a continuously improving integration capability in your organisation it can build API abstractions with good domain models in front of key systems ahead of those being re-used in specific initiatives. This means replacing the system only changes the abstraction layer, not the actual business process.
I recognise that at this point it may sound like there is a quite a bit of time and effort being spent on process analysis. But there are ways to strike the right balance depending on your organisation size and complexity of your processes. Even simply identifying a list of business processes beforehand can help you get in the right mindset and reap some benefits. From there you can then take an iterative agile approach to defining those processes as you go. Of course, the more informed you are on your processes the more prepared you are to deal with downstream impacts and the more likely you are to end up with a strong integration that can withstand changes to process and system requirements.
Concluding words
Working on these sorts of projects we frequently see opportunities to reduce headaches, added costs and missed deadlines through taking a process focus from the start. Applications do not exist in a vacuum, even less so in the modern enterprise that relies so heavily on interconnected data and information. Investing in quality integrations that enable end-to-end processes will always be a critical step to ensuring your implementation and processes are strong, effective, and flexible enough to see out changes in business and technology strategy.
