ERP Journey: Knowledge capture that sticks (unlike Silly Putty)

Silly Putty, a one-ounce orb of bouncing, malleable material of indeterminate composition, was a fad in the 1950s and 1960s. The ball of putty inside the bright red plastic egg was magical. For just a week or two's allowance, we could buy the leading-edge technology in toys.

My friends and I were convinced that only we knew about Silly Putty's ability to instantly capture information.

If you flattened out your Silly Putty (future engineers used a rolling pin) and pressed it onto the Sunday funny papers, you'd capture a full-color image of the comic strip -- not black-and-white -- like the cartoons on television. It was a little fuzzy and the words were backward, but it was amazing.

This was our first glimpse of a leading-edge information-capture engine. But like any leading-edge technology, it had bugs. We could collect just one image at a time; and if we balled up the Silly Putty, the image was gone.

Corporate knowledge, a company's most valuable and volatile resource, is sometimes like Silly Putty: It can be distorted as it is absorbed and can disappear forever before it can be transferred. We wanted to ensure that didn't happen when we rolled out our new ERP system. So, 11 months after we started looking for our new system and two months after we chose our partner, we began to examine our corporate knowledge and revise our standard operating procedures (SOPs) to capture the best of what our people know and blend it into the way we operate with the new software.

There were surprises, such as the inability of competent employees to articulate what they routinely did as a part of their jobs. They made errors of omission (like forgetting special customer handling rules), got steps out of sequence and were struck dumb at dreaded "Why?" questions. In retrospect, their vertigo makes sense. These people are rarely asked for their opinion; they are learning that much of what they know is now obsolete, and they are being coerced into a process they worry might cost them their jobs.

This reminded me of Thomas H. Davenport and Laurence Prusak's Working Knowledge. The authors asked under what circumstances employees would be willing to share what they know. They concluded that something had to be in it for the employee. We hoped recognition, an opportunity to control how things get done and a change of pace from daily tasks would be sufficient. In the end, our team members shared.

Redesigning the company

To start the process, we grouped seven SOP teams into back-office (accounting) and front-line (line-of-business) classes. Each group spent four days being trained on the software in its areas of responsibility. Then the groups spent one day in a Cliff Notes version of the other teams' training. They all got a sneak peek at their futures, tried on the software to see how it fit and considered how the other half might live. Over the coming weeks, they would make hundreds of new-vs.-old decisions based on this training.

The training also triggered a few turf skirmishes when members saw dramatic process changes that would affect them. The smiling trainer would ignore crossed arms and tucked-in chins and say, "I'll make a note of that." Some saw how the new product would improve their lives and got excited. But change, even change for the better, is uncomfortable and needs to be managed. Our first change management tactic was to take a week off before we started designing SOPs.

We limited our functional groups to teams of five to 10 members (representing about 5% of each functional group) to minimize the discomfort and enhance the group dynamic. Only consultants supplied by our ERP provider and team members attended the meetings, which were held behind closed doors to discourage visitors.

For the next six weeks, these teams would assess the practicality of hundreds of SOPs, system-control parameters, and numbering and naming conventions. For some, this took them away from their regular duties for eight hours a day for the entire six weeks. Most would get by with only three weeks away. They would read through the proposed procedure, parameter or convention; do gap analyses against our current practice; identify the issues and actions and record them. Then, by means of T-charts and flow charts, they would document their recommendations. Ultimately, our executive team would review and approve each team's recommendations. Many changes, like immediate posting of all transactions to the general ledger vs. batch processing, would have significant fiscal as well as procedural implications.

We encouraged all members to voice opinions. If they believed a change would be detrimental, they were responsible for showing how. The bar was set even higher if they wanted software changes. Before endorsing a change request, they needed to answer several questions to address this issue: What is the economic impact of not changing? Then the project management team would quickly review the change request.

The vendor's facilitators worked hard to keep members involved by asking questions like, "Do you agree?" or "Is that the way you do it now?" Early on there would be dead quiet, with most of the team wishing for invisibility. The person who could least endure the silence answered.

By the second day, things began to heat up. Sometimes, with several voices talking at once, the participants seemed transformed into villagers with pitchforks and torches. The procedure would elicit the following kind of responses: "We can't do [A]. We have always done [B]. I'm not going to be responsible when [C] happens." Or, ignoring the experiences of the hundreds of companies using the software, someone would say, "It'll never work." But through passionate involvement, they eventually began to see why the current way wasn't the best, or even if it was, that there were alternatives. Facilitators were now managing the flow, not priming the pump. By the end of the process, team members were visibly fatigued.

It took us 25% longer to complete the SOP design process than we planned. We could have driven the teams to complete this in the time allotted, but that would have made the schedule the goal. Like rolling up the Silly Putty image of the Sunday funnies, we would have irretrievably lost some corporate knowledge. Instead, the teams said they discovered as much as they decided. Twenty-five percent more time in SOP development translates into three months of project delay but less than 1% in additional costs. We've eaten up our project slack, which puts more pressure on the training and implementation phases. But it's better to discover the good and the bad now rather than during production.

Our most productive team members discovered that knowledge sharing is exciting when combined with the power to influence outcomes.

The rest of the company's employees will benefit from the six-week effort of these groups through better procedures and better training. Crossing the chasm from old to new will be easier because they analyzed the gaps between our current and future procedures.

These are all good things, but I'm still sitting here with a ball of Silly Putty wondering if there's any way I can reconstruct L'il Abner or Terry and Lulu.

Next: We'll continue tracking our ERP project by looking at the light.

Les Johnson is CIO at North Coast Electric Co., a wholesale electrical distributor in Bellevue, Wash. Write to him at ERPJourney@ciodecisions.com. This column originally appeared in the September issue of CIO Decisions magazine.

Dig deeper on ERP software for enterprise CIOs

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

SearchCompliance

SearchHealthIT

SearchCloudComputing

SearchMobileComputing

SearchDataCenter

Close