Knowledge transfer and its alternatives

Dear Bob …

What are your thoughts about knowledge transfer? I’ve been introducing “knowledge acquisition” as an alternative, to try to put responsibility where it belongs.

Some background: We’re in the middle of an extended … well, fiasco is too strong a word, but the implementation wasn’t smooth.

I’m the new CIO here. Before I arrived, my predecessor decided it was time to replace our old legacy environment with an ERP suite. He was probably right in that judgment. The company chose a package, and a “template” for it sold by a consulting company that was supposed to tailor the ERP suite for our industry.

Our goal: Get it in smoothly, have it run the company, learn how to handle the template ourselves so we wouldn’t incur a long-term dependency on the consulting company. The reality: It went in smoothly, ran the company into trouble. The template was designed for a commodity business – we run customized, premium job lots. The template was designed for a relatively unregulated environment; our government regulates the daylights out of us.

Here’s the knowledge part:Even after months of training on the part of our best programmers, we still need the consultants whenever we need to change the template, with no end in sight. Which is why I’m emphasizing knowledge acquisition. Let’s just say the staff aren’t happy with me.

What are your thoughts?

– Project rescuer

Dear Rescuer …

It boils down to a few possibilities, so far as I can tell:

1. The template is just too complicated for mere mortals to work with and maintain. If that’s the case, the consulting company that sold it to you should have made it clear up front what types of programming credentials and aptitudes were required to make it work. On your company’s side of the negotiation, since self-sufficiency was one of your explicit goals, part of the due diligence should have been to perform sufficient analysis of it up front to determine whether that expectation was realistic.

2. The template is just fine – a reasonable piece of code and data structures that journeyman programmers and data analysts should have no trouble learning and making sense of, or at least no more trouble than is the case with most ERP suites themselves. If that’s the case you have a staffing challenge – your technical staff isn’t what it ought to be. You’ll have to be the judge of how likely it is that your staff is substandard.

3. The template and your staff are fine; the consulting company’s training and support were substandard. Under the circumstances you describe I’d say that’s unlikely.

4. All of the above are fine and dandy; the problem is that your staff are simply insecure – unwilling to cut the cord, as it were. Maybe it’s time to throw them in the deep end of the pool (he said, changing metaphors mid-paragraph) and insist that they swim.

The other, entirely separate issue you raised is also a due-diligence issue, and it speaks to one of the great fantasies of our age: That the only reason companies customize packaged software is their unwillingness to change their internal processes to fit the ones that match what the software does out of the box. I’m going to guess that in evaluating the template, nobody took the time to compare hidden assumptions on both sides – the commodity vs premium and regulatory issues you described.

It isn’t surprising. Doing so requires a lot of painstaking work, and very often the only payoff is in being more realistic about how much budget is allocated for the effort – the actual effort takes whatever time, budget and staff it’s going to take.

But getting back to your question: I agree, “knowledge transfer” and “knowledge acquisition” place the responsibility on different sides of the negotiating table. We generally talk about self-sufficiency. It states the goal rather than which party is responsible for achieving it … because no matter what the situation, it’s a shared responsibility.

– Bob