Gotcha! Where the Process of Changing Processes Fails

Did You Know That:

Picking the wrong parties to carry the new-process message leads to poor-quality implementation

Brady spent much time reworking business processes with upper and middle management, but in some cases the wrong “subject-matter expert” was chosen to work it through on the front lines. Make sure the person has full decision-making power over the process in question, enough time to change things and the right knowledge. One particular subject expert in Brady’s finished product and shipping area got overwhelmed with her new duties and fell behind in her regular work. The result: Packages didn’t get shipped to customers.

The answer: Brady carved out part of her process-changing job and gave it to someone else.

Timing is everything

Brady cut it too close in converting data and was in deep water because of it during the first Eclipse rollout in 2000. Master data conversion was completed at the last minute, as was the automated sales software called a Variant Configurator. The rush resulted in incorrect formulas that led to some erroneous pricing of parts of the Brady product line.

For its second rollout, Brady took the problem to heart and created a replica of its production system seven months prior to launch and populated it with a complete set of master data, well in advance of cutover. It also updated its cost data three weeks prior to going live and double-checked its pricing in the Variant Configurator. The result was a smooth flow of products through the manufacturing and distribution process.

Successful process change = Training, Training, Training

Massive change isn’t easy, and Brady thought it had done enough training to drive home the importance of Eclipse to its workforce. Not so. After a bumpy first launch, it became clear that many employees were taking short cuts with data entry, or ignoring chunks of the new processes altogether. Most Brady employees received about 60 days of training prior to the first launch. It was too little, too late.

“We didn’t engage early enough,” says Chris McElfresh, order-to-cash process leader. “SAP requires quite a bit more discipline than they’re used to.”

The result was a nasty domino effect, where if one piece of data was left out, workers all the way along the line couldn’t do their jobs. Brady went back to the line workers and retrained them, with particular emphasis on how their own data impacted the rest of the system.

Data cleanliness is next to godliness

True to its Teutonic roots, SAP wants data neat, clean and buttoned-down. This issue came into high relief in the first “go-live,” when the software used to track data delivery-times was filled with inaccurate information by production workers. For instance, some data was put in that stated a particular label was in stock when it was not. A rep would promise delivery within 48 hours and the order wouldn’t show up for three weeks.

The answer? More intensive training emphasizing the importance of data accuracy. Otherwise, a massive amount of new code must be written to stem all individuals’ attempts to do end-arounds on the system.

High backlogs are hell

The first Eclipse launch was marred by a performance dip—backlogs went up 25% and on-time shipping dropped to 80% from a norm of 95%, compounded by high backlogs in production, order management and quoting.

Brady disciplined itself to make sure all orders were picked, packed and shipped before the lights went out. That meant many Brady employees worked weekends for the first 60 days after the launch to get things back in order.