We all know the picture of the person who hitches the cart up in front of the horse. It’s good for a laugh: how’s he going to get anywhere?
In IT, we have a annoying tendency, though, to do just this repeatedly.
It comes by moving to the solution far too soon, before fully understanding the problem.
Imperceptibly at first, we stop solving the real problem and start solving the problem of fitting the solution to the problem we think we have.
For example, one organization made the decision — too soon — that its customer centre would run using SAP’s component for handling this function.
There’s nothing wrong with SAP’s solution in this regard. But they did fall into the solution “too soon”.
SAP — as anyone who’s used the product knows — cannot operate without running the financial core. So the decision to consider SAP ought to have included the conversion of their existing financial system to SAP.
But they ignored it.
Soon, they discovered that they couldn’t afford the traffic on the network to handle synchronizing all the financial data between their existing system and the SAP implementation.
Instead of using this warning as a chance to reconsider the overall path, they immediately moved to summarize data coming from the customer centre and send only summaries across to the financial system.
The organization has been plagued ever since with challenges in closing their books. The customer centre will, for instance, reverse a customer charge. But the financial system doesn’t have the detailed line items to handle the reversal. The negative amount can be sent across — but not matched up. If a month end boundary is in the way (and it often is), matching backward becomes a manual effort.
This — and heavy modification of packages — happens routinely. We get committed to the solution and from then on the questions are all about “how do we make this work”, not “is this the right path”.
An eLearning company president once told me his firm would routinely lose business because “our screens are the wrong colour”: award-winning courseware would be rejected because someone preferred blue rather than green highlights. This sounds like a joke, but it isn’t: packages are often selected on just such ephemera.
Here are some of the questions you should always ask to get the solution on the right track:
Is this part of our market differentiation, or is it routine? Packages, outsourcing and -as-a-service solutions are all options for things that don’t differentiate you; differentiation tends to require custom solutions.
Will this lead to functional duplication? All vendors constantly seek to broaden their base, which means more and more of the software we acquire has overlaps with other software we’re using. You can dictate that those overlaps not be used — but if they have to be used, you have to instead figure out how to migrate or integrate.
Does using this solution require extensive modification? If it does, it’s a warning sign that either the business area(s) involved are unwilling to change to fit the solution, or that the solution isn’t a good fit (no matter how well liked). Either way, leaving this unresolved adds cost for years to come.
At first IT managers who try to limit solution selection to the end of the process will be ridiculed. Business area managers “know what they want”, their own people in IT get committed early to solutions.
But fixing the issues when it’s still just “on paper” costs pennies compared to living with millions in cost for a decade or more. Stand your ground.
Prudent use of resources and lower cost options going forward will build a career.