Image by billhd via Flickr
This is part one of a two part series by Alan Wilensky.
"I had high hopes for that Tuna Salad", said the IT director, "It didn't really deliver".
I was thinking about his IT problems, but in the middle of lunch with him, I thought I would respond by conjoining the two issues:
I said, "It's full of heavy metals, they have signs at Whole Foods that you shouldn't eat too much, and certainly not if pregnant".
He was not thinking about his IT problems at that precise moment, and why should he? Lunchtime was his one daytime hour away from the nightmare that had been plaguing him for months; unless I could convince him to take drastic action, the issue would continue to fester until the budget was spent, he was fired, or a decision to undertake a complete roll-back to the formerly reliable processes was made. They had certainly left the realm of the familiar and functional for a stinking pile of ERP.
He continued: "Well, everyone here gets the Tuna Salad, and I'm not pregnant!"
I answered with a piquant anecdote that would steer the question back to where we could discuss his real problem: Big, heavy enterprise software, ill matched to the strategic mission, integrated, installed, and manhandled by a VAR's enterprise sales team of butchers. These stooges didn't know him or his industry from Adam.
This was indeed a phantasmagoria of errors with the proportions of a tragicomedy - nay, a comedia of epic dimensions that would be humorous if not for the high stakes.
Surely, like the Tuna Salad at this overpriced Luncheonette, it was a recipe for disaster.
Everyone gets the Tuna Salad. Everyone in our business uses SAP or some other honking server-based 'bloat anchor'. For some, it's great, it works, they can lavish resources and support on it - the features and alignment of these systems can be put to good use. In many cases, like the one at hand, however, they are too much, or just plain wrong for the task at hand. Oftentimes, it's not the application itself which is to blame, but the process for integrating and deploying it that causes havoc and destruction - particularly in the mid-tier companies in which I ply my trade. These organizations are too big for desktop or generic solutions, and too small, broadly speaking, for most of the ERP and CRM being shoved down their throat.
That's that lunchtime segue. My counterpart is not concerned about the heavy metal (bloated solutions enterprise-ware), and he's in pregnancy semi-denial (he suspected that he was on the path to delivering a bastard child). Well, he had enough sense to have me in to bid on the re-engineering.
It's complicated, though -
This fine example of a 30 year old, family owned and run business of 300+ employees had made it to this stage, and profitably, without the burden of ERP. One of the brothers who inherited the executive mantle was gung-ho to innovate...and good for him, Jack!
They had an organically grown process-based business that their dad and uncles built brick by brick. Their IT was lovingly transitioned from a paper forms method to AS400, then to a custom Oracle system with Power builder, and then some faltering, tentative steps to mobilize the processes, adding partners to the extranet over time. They had many successes and minor setbacks over a 10 year period mirroring the IT boom of the 90's.
It all started falling apart when a slick SAP VAR told the go-getter brother what kind of "efficiencies" he could gain by instituting automation for certain processes (that were not broken), such as their rapid replenishment system. And you know, he may have been technically right, in theory, but the way it was rolled out was wrong, so wrong. It kills me to see the waste and angst that occurred. What I uncovered in my analysis was ghastly.
The business had good, efficient, in-place processes that were refined over years of real-word use. One could say with confidence that they were the experts in their business of brokering specialty PCB manufacturing components. With a system of carefully maintained files, an aging yet stable Oracle database, and an integrated fax and imaging server, (not to mention a cadre of smart staffers), they had their shizzle down proper.
Now in comes SAP, whoo-hoo, and with a VAR completes a one week (!), once-over-lightly, pre-sale process study that concludes....wait for it now....that the processes must be changed to thus and so, and SAP SCN is the way to do it.
Can't do it your way anymore, only this wholesale re-engineering with THIS package, this support, this training, and these database upgrades (by the way, you will need this hardware list), is the way to enter this new and efficient era. Baby brother, the go-getter, was sold! With this complex burdening of the IT infrastructure, he had the means to unconsciously usurp his older brother while maintaining an appearance of propriety. It all seems to be good for the business, no? No. He probably believed it, too.
Many elementary rules were broken, once the trigger was pulled. They signed agreements, did no competitive RFPs, and neither held nor researched vendor cook-offs and comparisons. But most of all, they turned over their process studies to a vendor with skin in the game. This is a no-no.
Rule Number One: Never examine work processes in light of a software project. Corollary: make all examinations of process purely IT systems neutral. NEVER let a vendor run your process studies.
This company had every reason to examine process and systems upgrades, with possible concomitant IT systems augmentations. They had numerous human-centered processes in their daily grind that were bound by the expertise of a sole person who owned the processes - a scenario ripe for automation. Such solutions not only multiply an incumbent expert's productivity, but also empower other employees to cover the expert's mission in their absence. That's what system re-engineering is all about.
Not the wholesale destruction of processes cultured over a thirty year life-cycle, no sir.
Changes to mature processes must fit the ultimate strategy and purposes of the business, not the IT vendor.
This misalignment is common, and has led to some un-G-dly statistic that a large percentage of SAP client licenses go un-deployed after the sale is closed and the project is found to be irredeemably broken. It figures that these un-implemented SAP seats are most often found in mid-tier companies.
These mid-tier stalwarts are the vulnerable ones - too big to do nothing, too small to afford the massive resources to de-funk badly screwed up ERP projects that are in their second phase of non-performance by anyone's yardstick.
In the next Installment, I will tell you what I discovered, and what my recommendations were. That's where I left it; I billed them for the analysis, and left a quote for the follow-on work. I think I heard the screaming start to rise in their throats (with the exception of the poor IT director, the guy who had been saddled with a thing he never recommended) as I exited the building.
One thing before I go: If you are mid-project, and you are fighting over when to pull the plug on the old stable systems, and the new one isn't working quite right, and the meetings have like 20-30 stakeholders in the room with vendors with MS Project CPM's and power points and memos to move onto the next 125k phase....
You've got a problem.
Comments