The Trauma of OOTB

The prevailing wisdom from the PLM Software providers is to deploy the PLM system “Out of the Box” (OOTB). This reduces development and deployment costs and ensures smooth upgrades, but is it such a bargain? The hidden costs of an OOTB PLM deployment are significant and impact the cost, quality, and timeliness of your design activity. The ‘project’ may be very successful, but then you need to live with this system day in and day out for the next 20 years.

The Scenario

Your existing PLM system is getting old and slow. Maybe it is already out of support. Maybe you want to reinvent your design process and the old system is so customized that you don’t know how to change it. You embark on a conversion to a shiny new PLM system that is the industry leader. The salesmen say it can do anything.

Out of the Box Deployment

You also decide to follow the prevailing wisdom recommended by the provider and deploy the PLM in an OOTB configuration. The system integrator has a template and expects very rapid deployment. You spend a few weeks defining part attributes and setting up change and release workflows. Then the project team gets to work and configures the system to the correct data model and flow. After a few short months, it is all done and ready for deployment. The initial testing says it meets all the requirements and is ready for the users to move in.

Gaps in the Template?

The next step is the User Acceptance Test. This should be a slam dunk, but as you begin training the users on the new system, they start to ask some questions. They ask where the design review happens in the release workflow. They ask where the plant and procurement department are engaged in the change lifecycle. They ask what happens when a part is rejected and needs to be reworked. None of these seem to be in the standard template.

Quick fix for minor gaps

The system integrator is not disturbed by the requests. This is a normal part of the process. He is surprised it was not caught earlier. He develops a project change control and a plan to get it all included in a few months for a reasonable cost. The project team documents the new requirements and configures them. They pass all the integration tests with only minor tweaks.

It looks good at first

The User Acceptance Tests begin again, and the processes seem to be flowing well. All the data looks good, and the data migration has gotten to a level you consider acceptable. There are several minor issues, but you want to get into production, so you mark them for a patch release somewhere down the road.

Productivity issues?

The go-live is relatively smooth. The users are having a little trouble being productive in the system, but it seems to be working. It probably has something to do with the reduced training schedule you imposed because the system was so easy to use. You are confident that they will get up to speed soon.

Out of the Box ‘project’ was successful

You look back on the project and reflect that it went almost perfectly. The “Out of the Box” decision seemed to pay off in a successful project with minimal hiccups. You are happy you dodged the bullet on the 70% failure rate that plagues these sorts of projects.

What about error checks?

About a month later, you start getting feedback from the plant. The data you are shipping is not consistent and not accurate. Bills of materials are incomplete, and the drawings are not always available. You call in your design team and they do not know what is wrong. One of the veteran designers recalls that the old PLM had checks for BOM accuracy and consistency built into the flow. He recalls that it was a huge effort to customize it into the old system, but it worked well.

Begin with manual workarounds

You contact the System Integrator, and he says quality checks are not in the template. They are specific to every customer and there would be no way to include all these diverse checks in one template. He agrees to add a BOM review step to the workflow without additional cost.

Productivity suffers?

After a few weeks, the design supervisors start asking for additional headcount to support BOM reviews. All the labor saved by the old customization must now be done by hand. Also, they must check it twice because human inspection is only about 80% accurate, so this doubles the workload. You decide that this is a small price to pay to avoid customization.

Integration issues?

A few weeks later, the Logistics department calls you. They are getting unusual BOMs via the ERP interface and some of the part attributes are missing. You check with the design team and the BOMs and Part Attributes are correct on their side. You call the System Integrator again. This is difficult because he has started ghosting you. He explains that the ERP interface sends exactly what is on the PLM system to ERP. This was verified in testing.

What about data adaptation to partner systems?

You go back to the Logistics manager and tell him you are sending the correct information. One of the veteran part planners is in the meeting and mentions that that ERP system cannot use raw Engineering BOMs or Parts. The old interface had a customization to set a default for certain attributes and modify others to make the ERP work correctly. It also adjusted some BOM lines to align with Logistics’ process needs.

Was customization a better answer?

You are starting to feel traumatized by the whole process. This was supposed to be an easy project. It finished successfully and you were congratulated by everyone. But now everything is starting to fall apart. That stupid old PLM system seemed to magically make everything right somehow. Now you have reduced productivity by the engineers as they manually check everything. You have bad data going to the plants, despite all your manual checks. And now you have the ERP system choking on perfectly good data that does not meet their needs.

So, you begin to customize – a little

You try to get in touch with the System Integrator again. They simply do not answer your calls. One of your people suggests a post-processor application that can fix the ERP data on the fly as it is transmitted. You shake your head in disbelief that you are approving a customization to the system, a home grown one at that. But your options are limited. Also, all the people that congratulated you on your success are starting to criticize your ability to execute projects.

Begin to Question if Out of the Box?

The post-processor is developed in a few months and starts working to correct the ERP data. This is a small victory, but it is really the start of your epiphany that “Out of the Box” may not be the panacea that it was made out to be. Could all the sales pitches have been just that? How did these people think an “Out of the Box” system could possibly meet all the needs of an organization that had spent the last twenty years customizing every detail to be exactly what they needed?

A hard look at the cost / benefit

You review the decision process. You optimized the project process, but it only lasted for a couple of years. Now you must deal with the aftermath of the project simplification or the next 20 years – day in and day out. You planned to save a lot of money on the upgrade project, but it is nothing compared to the cost of additional people to manually do all the things that were automated in the old system. Not only that but now you cannot trust the data in the new system because automated quality checks no longer exist, and human inspection is only 80% effective.

Of course, the partners loved Out of the Box

What were you thinking? Of course, the Systems Integrators were all for it because they got in and out without dealing with your complicated needs and made a bunch of money just filling in their template. The software provider was all in too. Their system looked like it was ready very quickly and they promised that their upgrade process was easy-peasy. You cannot blame them because a realistic system that meets all your needs is difficult to upgrade.

Can Out of the Box scale?

I can imagine that a small organization that has simple products and runs on the “prairie dog” system where everyone is in the same office and just yells down the hallway could use an “Out of the Box” system to supplement their tightly integrated work environment, but global organizations with high variability in the capability of their workforce need their system to help them to get things done.

Can Out of the Box support the day to day?

The trauma of deploying and using a system “Out of the Box” is rarely felt in the configuration and deployment phases. Life is great and you are the hero. The real trauma comes when your organization executes, day in and day out, with inadequate tools and, on top of that, your data is unfit for purpose.

Is Out of the Box Lean?

Lean principles state that tools should be adequate to the job, or they need to be customized until they are. It is difficult to say why this principle seems to go out the window when it comes to IT system deployment. Inadequate tools are so easy to fix, and adequate tools provide so much more capability and satisfaction.

Conclusion

Have you suffered the trauma of “Out of the Box” system use? Have you found the secret sauce that can make it work for a global enterprise? Or have you had to recant and start customizing to achieve adequate productivity and data quality? Please let us know how you cope in the comments.

Digital Guideposts is written by Mark Pendergast – retired Data Junkie, Deep Thinker and Innovator. He worked with product data for over 30 years of his 41-year career in Automotive Components Manufacturing. His background includes work in Engineering, Operations and Information Technology. He is also an Electrical and Computer Engineer (BS-ECE) and a Certified Project Management Professional (PMP). In his spare time, he mentors a High School FIRST Robotics Team, reads and plays on his computer.