Rules for System Integrators

or.. how to succeed even though the IT staff is still the scarce resource.

A number of technologists I follow are saying that combining ‘Best of Breed’ solutions is becoming the default ERP strategy; for example, taking the HR module from Workday and integrating it with the core Finance module of a product like NetSuite. My anecdotal impression is that companies are still choosing a full-service ERP system for most core business functions, but what were once optional add-ons (CRM, talent management, enterprise-scale business intelligence, etc) are now table stakes in most industries.

Part of the CIO role (or CIO advisory role) is balancing delivery of the great functionality business users want right now against the long-term cost of integrating multiple systems.

In a post on my blog, I talked about how successful technology leaders deliver the most value in the mode of “Yes, and…” 

The job is about getting things done on a predictable schedule; avoiding the twin traps of either over-promising or never-committing. Delivering this value requires remembering that with all of the change in technology over the last 20 years, the IT team is still the scarce resource.

I’ve led three companies through digital transformations, where they replaced virtually every system used to run the business in a multi-year effort to go from industry laggard to industry leader in technology. Three rules guide my interface decisions as we map out the future state system landscape:

1. If you can avoid it, then avoid it
2. Isolate in content
3. Isolate in time

Having these principles in mind keeps you from overloading your scarce resource.

1.  The Best Interface is the One You Don’t Implement

There is a reason that ERP vendors have grown into behemoths. Linking two systems together means twice the upgrade events and another level of integration testing on every upgrade. It means potential “sand in the gears” every time a business user tries a previously unused function, and every time either vendor extends functionality in an unexpected direction.

Software development has the concept of “technical debt,” the accumulated work you need to undertake to straighten out all the shortcuts taken in the past. Teams that don’t attack their technical debt get less and less productive as each new feature reveals a mistake made in the past.

The “sand in the gears” from interfaces is very like this technical debt. Unless the IT team is consistently addressing newly uncovered issues, business users become more dissatisfied with how systems work together.

I was surprised to learn a great CIO I know had just implemented Workday as the ERP for their Asian region. In this case the CIO turned the ERP selection decision on its head, and decided the benefits of Workday drove an unorthodox choice (in this industry) for GL/AR/etc. She kept her eyes open to the inroads Workday made in core functionality to deliver a win/win for the business without needing a messy interface.

2.  Isolate in Content

Best of breed systems succeed in the face of integration pain because parts of their functionality are much, much better than the corresponding module in the standard ERP. At their heart, many of these side systems succeed by managing the odd data that that does not fit well in the row/column table model that are the base of most ERP systems.

• Salesforce for contact management data like call logs and calendar events
• Workday for HR data like resumes and performance reviews
• Transportation management systems for route optimization and interfaces to myriad trucking systems
• Pick-to-light or pick-to-voice warehouse add-ons for managing the data and interfaces needed to drive specialized hardware devices

The edge systems succeed in the marketplace because they have different object and process models optimized to deliver superior functionality. The key to ensuring these systems continue to spark joy over the long term is to make sure you design the linkage between systems to minimize the “sand in the gears” going forward. That means:

• Edit master data in one place and send to the other
• Only send results of completed transactions / processes from one to the other
• If integrating to multiple systems for the same function (like disparate work order systems in your customer base), specify a common interface if possible

Your interface design needs to minimize the chance that your end users will be exposed to the different object and process models in the disparate systems. I wrote more about how to design interfaces to avoid that pain in my blog here.

3.     Isolate in Time

Best of breed systems can deliver great value if that sweet spot is important for your business. While I have invested years of effort getting the ERP foundation set up correctly for businesses, it is always these edge systems that generate the most excitement. 

• The catalog lookup directly linked to the Point-of-Sale that cut transaction time by 80%
• The Salesforce iPad app that helped salespeople find the intersection of the highest profit order and the customer’s strongest preferences
• The pick-to-voice system that freed up both hands in a demanding physical warehouse environment

A key in integrating all of these systems was keeping another principle in mind: make the interface as current as it needs to be, but no more so. Your software vendor may be excited about the latest web service call they’ve exposed to allow real-time integration, but as a CIO you need to recognize that a real-time interface requires real-time response when something goes wrong.

For an automotive aftermarket chain, we determined real-time integration of the catalog lookup to the point-of-sale was critical. Recognizing the long-term pain this would cause if scarce internal IT resources needed to keep this up, we worked with a point-of-sale vendor to integrate the leading catalog directly into their offering. For them, it would be the critical differentiator for penetrating the US market. That made it worth consistent effort to keep in place and optimize with their underlying data and process models.

In the Salesforce application, the ERP system was instrumented with triggers that made updates theoretically available to Salesforce near real-time. We implemented an intermediate layer with a SQL Server staging database and an SSIS package controlling flow back and forth from Salesforce. Salesforce and the ERP system used radically different technologies, and with this solution neither side was dependent on the real-time availability of the other. The retailer in this case operated with an extremely light IT staff, and this provided a necessary buffer in response time from a third party.

At the other extreme, in my experience it always makes sense to automate an interface and run it on a daily (or at most weekly) basis. A daily interface happens frequently enough that you can track down what change may have caused the error, and the pain of fixing an issue daily helps enforce the discipline of getting to the root cause. Leaving an interface to be run manually or very infrequently usually means that interface will be an ongoing source of trouble long after the excitement of the new function has worn off.

About the Author

Chris Crowley is Founder & President of K&C, providing Program Management, Interim CIO/ CTO and Supply Chain consulting services. Companies hire Chris when undertaking enterprise-level digital transformations.

Founded in 2011, K&C works with startups to Fortune 50 clients. Read more from Chris on his K&C blog.

Program Management. Interim CIO / CTO Services. Operations Innovation.