The Top 7 Posts of 2013

As the year comes to an end, we inevitably think of where we've been, where we are, and where we're going. To help you along, I offer this look back at the top post of 2013. Looking back is only good if it helps us move forward, so take a look at these posts, and then go and get it done with PLM in 2014.

Configuration Management

Let's start with the 7th most popular post from 2013. Actually it was very close to a tie, so I will introduce these two together. The Basics of Configuration Management - Part I and The Basics of Configuration Management - Part II were very close. As a bonus, let me throw in The Basics of Configuration Management - Part III. This proves my point that configuration management is poorly understood by most companies. Even if a company has taken the time to understand and implement a good configuration management practice the rules are often not enforced, and usually not followed. Take these three posts as a guide to doing a better job with configuration management in 2014. You might also enjoy a related post: Change Management: The Ghost in the Machine.

Cultural Change Management

My impression over the past year is that one of the most challenging activities related to PLM implementation is cultural change management. Often, it is not even considered until the solution is rolled out and in the hands of the users; this is too late! Take my post Cultural Change Management, or How I Saved PLM as a good example. I wrote this in a short story format, and I think you will like it. If not, at least it's short.

PLM Education

I am a big proponent of PLM education. Virtually every company I have visited this year needed more PLM education. Keep this in mind for 2014 and put PLM education in your budget early in the year. The 4th most popular post from 2013 was this one: PLM Education Done Right in 3 Easy Steps. Follow these steps to get the most from PLM.

How to Measure the Value of PLM

We often do surveys, and when we ask for the top impediments to PLM, one of the top answers is always measuring PLM value. Without a way to measure the value, it is often hard to get upper management to invest in PLM. The 3rd most popular post of 2013 was How Can You Measure The Value of PLM, which, it turns out, is a very good question. Without some way to measure the value of PLM there is no way to evaluate your success, and plan for future updates. Keep this in mind as you plan your changes in 2013, and find a good way to measure this important aspect of your business.

Social PLM

There have been many posts about social PLM, or how social tools will impact the activities that are traditionally part of PLM. But in my experience, the impact of social PLM has been very low, or nil. Why is this the case? I dove into this question in my post Why Has Social PLM Failed? I think we will see a better meshing of PLM and social tools in 2014. There certainly is an opportunity to enhance PLM with social tools, but PLM vendors will need to do a better job of integrating these tools into their solutions. This may take some time, but we will see it some day; I just hope I live long enough. You might also want to read a related post: Why is Social PLM DOA? I like the graphic I used here; very creepy.

PLM vs ERP

I am amazed how often I am asked about the difference between PLM and ERP. There exists a very different set of views on this topic depending on who you ask. I addressed this in my most popular post of 2013: PLM vs ERP: Can't We All Just Get Along? This was an attempt to give some clarity to this polarizing topic. I think companies need to come together and decide where they will put the dividing line. Obviously it is not a clear demarcation, and there will always be some overlap. Just agree and then implement consistently to get the best results.

Conclusions

So, there you have it, the top posts from 2013. I hope that 2014 will be a very successful year for your PLM implementation. No matter where you start you can always improve, and PLM can have a dramatic effect on your bottom line. I wish you all the best in the coming year!

Don't forget to read one of my favorite posts from 2013: Email: "I'm not dead yet!" PLM: "But you're not well." I really like that one!

Cheers,

Jim

The Basics of Configuration Management - Part III

Welcome to the third, and final post on the basics of configuration management (CM). If you missed part I, or part II, go ahead and read them now. In this post I want to talk about the bad things that can happen when you ignore basic CM practices. The results may not be as dire as this story, but hopefully you can see that CM practices should be followed by all companies to avoid serious problems.

On the morning of April 20, 2010, several explosions rocked the Deepwater Horizon oil platform, and fires broke out. The platform was evacuated; coastguard and other ships were dispatched to fight the subsequent fire, and rescue the survivors. 11 men were killed in the initial devastation, and oil began to rush from the unsecured well head deep under the Gulf of Mexico.

Of course, every oil rig is equipped with many safety devices. When BP engineers attempted to activate a huge piece of underwater safety equipment, it failed. The failure was a result of modified drawings of a variable bore ram, designed to seal the pipe, that did not match the current equipment drawings used by BP. The fail-safe in use did not match any of the drawings that had been given to BP from the equipment owner.

Transocean, the owner of the variable bore ram and of the sunken Deepwater Horizon rig said any alterations would have come at BP's instigation. BP said they never asked for any alteration. These alterations meant that BP spent several days unsuccessfully trying to cap the well. Only after several unsuccessful attempts did they figure out that the drawings they had did not match the actual equipment at the bottom of the gulf. The existing equipment would not cap the well properly, and more work had to be done to finally get the well capped.

It wasn't until July 15, 2010 that the well was able to be capped; almost 3 months later. By this time, nearly 53,000 barrels per day of oil had spewed into the gulf with a total discharge of 4.9 million barrels. The impact on many aspects of the Gulf of Mexico are still being felt to this day, and the full impact may not be fully understood for many years.

Had BP and Transocean followed basic CM principles they would have been able to cap the well within a short time using the proper equipment. No changes could have been made that no one knew about, and all parties would have been able to sign off on any changes. 

Think about this disaster, and make sure you don't get stuck with the same mess. Without CM practices that are followed by everyone, you risk your customers, your products, and your business.

What do you think?

- Jim

The Basics of Configuration Management - Part II

In part 1 we talked about some of the basic steps you should take to make sure Configuration Management (CM) is working well in your company. Following strict rules around CM provides the foundation for product innovation. In this post I want to cover a few of the rules you should follow to make sure CM is helping support your business properly.

Change Processes

The first set of rules you should evaluate covers how changes are initiated, tracked, and completed. There should be as few options here as possible. Do not provide the ability for anyone to use any type of ad hoc process they choose. Two or three options is all you really need: Simple and Low Risk (75%-80%), Complex and Medium Risk (15%-20%), Complex and High Risk (0%-5%); that's about it. Audit change processes, and make sure no one is going around them for a "unique" change. There should be accountability and penalties for those who do not follow the prescribed change processes. Your system should be set up so that NO WORK CAN BE DONE unless they have come through an approved change process.

Working on change practices can have a very significant impact on your projects. Those who have excellent change management practices are much more likely to achieve or exceed project objectives. This usually leads to happier customers, and more revenue for you.

(Procsi, 2009 Best Practices in Change Management Benchmark Report)

Requirements

The most basic approach to CM is to make sure the final product matches the original requirements. There must be a way to capture these requirements, and checks to measure conformance at each stage of product development. Many companies have some requirements that initiate a product, but as the process progresses there is no linkage back to these requirements. At the end of product development a working product may be produced, but if it matches the original requirements is anyone's guess. Implement a strong PDM system that can track requirements and provide a global view of as-planned vs. as-released states. Hold people accountable for decisions they make that are not in line with these original requirements.

Baselines

Create baselines to "freeze" the product at certain points in the development process. Baselines are very important since they allow us to go back to a valid design at any time. We can analyze these baselines, share them with partners and suppliers, evaluate with marketing and sales, and use these for product reuse to start a new valid project. Most companies do not have a good way to create a valid baseline. Have you ever sent something to a supplier, and then wondered what version you actually sent them? Baselines eliminate all these problems, and allow a smooth error-free design process.

Making CM an important part of your business will provide many benefits. It doesn't happen overnight, so keep working on it. Once you make this part of how everyone works, it will become second nature. I will provide a few more insights in part III.

What do you think?

-Jim

The Basics of Configuration Management - Part I

Configuration Management (CM) is like a seat belt: it might be uncomfortable, unfashionable, and painful, but without it, you just might be dead. When I say CM what am I talking about? Well, here's the short definition that I like to use:

Configuration Management is a set of inter-related processes meant to enable people to work together better. 

The Basics

There are many aspects to this discipline and very few companies will likely apply all of them. However, I want to mention 4 areas where you can start to use CM to support innovation and collaboration today.

1) Initiate basic rules in your company that support CM - Many companies think too many rules will stifle creativity; nothing could be further from the truth. As I mentioned in my previous article, The Tortoise and the Hare: a PLM Story, there is no way to support collaboration and innovation if you do not have very strict, formal rules that are followed by everyone; that leads me to point #2:

2) Make sure people actually follow your rules - It doesn't make much sense to spend time formalizing rules and procedures, only to allow people to do whatever the heck they want. Make sure you audit your processes and make sure people are following CM rules, whatever they are. If people know your rules are only weak suggestions, they will not follow them.

3) Automate as much of the CM process as possible. If you expect people to enter information or update details manually, it won't happen. With good tools in place you can automate much of your work without depending on the potentially limited brains of your workers. But, remember, process leads, tools follow; when tools lead, fools follow. Create your business processes first, then use tools for support.

4) And, finally, don't try to do everything at once. Remember, incremental improvement is better than delayed perfection. Start in one area, like Engineering Change Management, and walk the walk. Once you have processes and tools to support you in one area, you can grow into other areas. Your users will get use to following CM processes, and additional changes will seem less gruesome.

Good luck with all your efforts at Configuration Management; more on this later.

What do you think?

- Jim