So I took a cue from my own book, practicing something I spoke about in my blog on Credible Leadership. At my work we currently have many open tasks, to the point that the staff is getting stressed and projects are becoming delayed. Instead of cracking the whip harder on the team, I rolled up my sleeves and started taking on some of the low-level admin tasks to try to open time for the staff. I say low level, because I don’t want to interfere with the engineers designs, and I am out of practice with the current CAD tools and everyday PDM environment. I took on some BOM tasks, which means releasing part numbers into our PLM system and structuring Bill of Materials (BOMs). I am typically on the BOM approval side, and honestly it has been some time since I was on the BOM creation side.
As I am releasing part numbers into our PLM system I started noticing some strange quirks and bugs in our system. Here is a little background on our system, Part numbers are generated in a PLM system by engineers. A number of attributes and descriptors are added for each part number, such as a description, a vendor in purchased, vendor part number, or engineering files for fabrication if it is an internally developed part. Once a part number is created, it is then structured into a BOM of a purchasable item. Once the part and BOM is ready for production release, it is added to an Engineering Change Order, or ECO and submitted to a change analyst for routing. The change analyst adds information that might pertain to a variety of departments, then places the ECO into an electronic signoff committee for approval. Once the ECO is approved by all it become active in our MRP system to be purchased or sold. Follow all that? It’s a pretty standard workflow.
As for the bugs I am seeing in practice, I started asking around with the engineers I began hearing a number of suggestions and workarounds for the bugs. From a management level, I hear grumbling and comments from the staff on a variety of issues, and I feel it is my job to filter these comments to determine what are simply gripes, and what are legitimate issues that can hamper productivity. Hindsight is 20-20, what is clear now is that walking in an engineer’s shoes for a mile will tell a lot about real problems being faced.
One bug in particular annoyed me as a user, which in turn is a real concern from a management perspective. After I had created about 100 part numbers and structured them into BOM’s, I did an ‘Audit’ on my ECO. This ‘Audit’ is a tool that checks all part numbers created for mandatory attributes. What I found was that every part I had created was missing 3 mandatory fields, which had nothing to do with the parts themselves. This is important: these errors only showed up because I am typically an approver, so I have more rights and privileges than the engineers. These errors do not show up for the engineers.
After a lot of head scratching and asking around, it turned out that the engineers never filled in these fields because they didn’t know they had to. The change analysts knew this was a bug, so they ‘simply’ fixed each part an each ECO as they came through before submitting the ECO to the approval committee. What the hell? This is one of the CPI basics, root cause an issue and fix it systemically at the source, not later in the workflow where it needs to be fixed every time. In the case of this ECO, I found that I had to reopen each part, click to a different tab, update 3 fields to ‘No’ (its always NO, that’s another issue), then save the part, then open the next. I got really good at this after 100 parts, but it still took me 30 seconds or so on each. That’s about hour of my time.
The manager in me is baffled by this, this ECO of 100 parts took an extra hour of processing….. and we release thousands upon thousands of parts every year!
Since I made this discovery we opened the dialog with out IS team to correct the engineers privileges so they are able to see all the errors in their work before submitting ECO’s. We also defaulted all of these fields to say ‘No’, to eliminate the need to select ‘no’ over and over. The bigger question is why these fields are necessary at all, if they are always no. (well, not always, but 499 of 500 parts are ‘no’, that’s close enough).
My take-aways from this whole thing?
- Get your hands dirty as a leader to truly understand the issues going on in the trenches.
- Don’t assume your staff will always correct issues at the source without being trained. It’s all too easy for the staff to ‘just know how to fix it’, rather than systemically correct the problem.
- Listen to all the staff complaints and comments, missing just one time-suck can mean a significant impact to capacity.
Ever have a similar experience?