Re-engineering

Reengineering A Process

June 20, 20243 min read

While leading a large program that involved software, hardware and manufacturing development, we encountered several problems with flow. One of these occurred in the manufacturing team - we had design engineers and technicians working to design computer drawers and rack assemblies (what goes in them, not the cabinets). Designers would design the enclosure or rack, the parts would get ordered, and when the technicians would try to assemble and wire them.. If there was a problem, they'd write an Engineering Order (EO). Think of this like a defect report. And they were writing a bunch of them. We had a major problem.

I had just learned about Lean and reverse engineered the process in the book "Reengineering the Corporation: A Manifesto For Business Revolution" by Michael Hammer and James Champy. So decided to actually give it a try.

I put together a presentation with the disturbing metrics. The basic message was "we can't get there from here". This was the "Case for Action". I asked for volunteers to work on a tiger team and got the team together. The first thing we did was understand the current process flow and very quickly mapped it out. I then asked the team if we could throw the process out the window and start from scratch, what would we do? Like deer in the headlights, I got nothing but a bunch of blank stares.

So we then proceeded to do a value added analysis of every task in the flow and asked the question: "How does this task add value to the customer?" Well, it turned out there were about 5 or 6 people who had to sign off on the designs. It was clear that those were steps that could be eliminated. I asked the team "who really needs to sign off on the designs?". It turned out the only person who needed to sign off was the downstream consumer, the technician.

So we made the rule change. The only one who had to sign off on the design was the technician who would build it. Next thing you know the designers are pulling the technicians in while they were doing design. Then the technicians asked for CAD workstations and training so they would no longer need to work with redlining paper plus trek back and forth across the building continuously. After providing CAD stations and training - the technicians could now crank out designs too. And when t came time to put together the assemblies, the designers worked side by side with the technicians. This type of collaboration is not normal

The changes turned out to be a huge success and eliminated our flow problem. The racks and assemblies were also pure works of art that the team decided to put smoked see through panels on all the racks to show off the great work

Key takeaways for this story:

  • Develop a strong case for action

  • Form a tiger team

  • Understand end to end process flow

  • Consider throwing the process out the window and starting with a blank sheet, if not then

  • Do a value added analysis - look at every step in the flow. Get rid of any tasks that are not value add or value enabling to the customer.

  • Eliminate hand-offs and unnecessary approvals

  • Implement concurrent engineering (it just works)

  • Then automate the flow

  • Finally, enable team to take pride in their accomplishments

I would recommend teams take a similar approach for DevOps. Get rid of the waste first, Then automate. In other words, Do not automate obsolete processes. Doing so will do nothing but add cost, complexity and will slow or inhibit the ability to adapt down the road

Back to Blog