"My Department alone works in 4 different systems to accomplish our work, and it's a giant pain in the a$$.”
This was part of a conversation I was having with a good friend last night. He is in charge of site development, construction, sourcing and procurement for a large nationwide retailer. When I asked him how things are going at work, he said "the people are great, but it's killing me!"
He proceeds to tell me how they've got 4 different systems that they need to interface with in order to complete their work: One is a large AS/400 based ERP system, another is a newer SaaS procurement system that is used by some, but not all departments, another is a SaaS construction project management tool, and still another is... wait for it...a giant, lumbering behemoth of an excel workbook.
Of course none of the systems talk to each other and information has to be entered multiple times in multiple systems in order for business to flow. When you're dealing with more than 80 different SKUs per project, not to mention the countless non-construction related SKUs, how can this NOT be a recipe for disaster? Then he tells me they've just recently implemented a manual process to export PO information in a CSV format to be imported between the SaaS Procurement and the ERP systems, so I guess that could be called progress, right?
Sadly this is a really, REALLY common story that plays out in Manufacturing, Retail, Transportation, Defense, Education, and pretty much ANY business sector.
Ideally, there'd be an off-the-shelf toolset that meets the needs of each department and seamlessly hands off relevant data to the appropriate users, right? Unfortunately, though many software providers have tried, it's usually just not realistic.
In most cases, what makes a company successful, is what makes them different. It's their own spin and the way they do things. "Best Practices" aside, software that is to generic or too opinionated could likely come into conflict with what makes your organization special.
See our other post on Opinionated software.
Since there really are no Silver Bullet solutions, we're commonly stuck with specialized solutions for each department across the enterprise, each sold to a different stakeholder, with little regard given to the other departments or the impact as a whole. The sales guy for each of these software packages modeled his ROI for his target department in a vacuum and never considered (or worse yet, concealed) the likely productivity loss and other challenges that inevitably arise from this type of disparate specialization.
System Integration is where it's at. We believe in working to create a more intuitive world, and given the realities discussed above, that doesn't happen without robust integrations.
API (Application Programming Interface) layers bridge the gap between disparate systems. Web services can be written to act as translators and task masters between the various enterprise tools. And they can be set up to do it automatically with little to no touch from the end user.
Each of these different applications are built on databases, housing all of this important, enterprise critical data, right? Some of the newer SaaS toolsets have thought about this and provided SDKs (Standard Development Kits) to allow companies to develop their own APIs. That's great if you've got a robust IT and Development department, but what if you don't? So many have also marketed pre-packaged APIs for commonly needed integrations. That's more like it - but it still doesn't cover everything. What about systems that aren't really systems at all, like the Excel sheet referenced above? There are many situations where custom development makes a lot of sense, and API development is one of them.
Correction: you don't have the budget NOT to fix it. The problem here, is that most enterprises have not gone through an exercise to”quantify the pain.”
That is, they are so busy, doing all of the extra work that these disparate systems require, that they have not taken the time to figure out how much time and money is wasted doing redundant tasks and data entry. They haven't figured the cost of human error in the entry of the information in each system. They definitely haven't quantified the loss of human capital, when people decide they've had enough and choose to move on to greener pastures.
Department heads haven't quantified the pain in a way that senior leadership can digest, and in a way that demands action. In my experience, the quantified pain is usually bigger than the cost of some systems integration work, and a workable ROI is typically well within reach.
Software should make our lives easier, not harder. Steve Jobs used a great mantra some years back, when describing the iEcosystem: "It just works". That's how it's supposed to be. Imagine a world where you interface with the system that best serves the needs of your department, the relevant information is entered and processed, flows to the other teams that need it, and the appropriate workflows, payments and shipments just happen.
The sun is shining, and you can move on to your next task because this one is done. Let's not languish in the frustrating, inefficient, and costly world of disparate systems that don't talk to each other.
Go forth and fix it!
If you’d like to start a conversations about the “how” of all this, let’s talk.