Clarity on PLM

What I learned this week … came from PLM Processes: Flowchart vs. Rule-based? from Oleg in PLM Twine. He discusses rule-based business processes for PLM, which immediately set off red flags in my head based on past experience. Oleg made me think about two different experiences I have in the same context, and it made me shudder. Why? I have seen rules go wrong too many times. And I have seen workflow processes go wrong just a many times.

Workflow Warnings

As Oleg knows, I am bit of a process weenie. Years at Andersen Consulting (the part that is now Accenture) will do that to you. I am 100% in favor of defining processes as a part of implementing business change and supporting technology. But here are some tidbits that I think are worth sharing:

• Define All Processes - Technology implementations should be process driven. Unless you define how the technology helps the business, you won’t get the most out of it.  
• Automate Some of Them - Not all processes should be workflows. While workflow is a great tool to automate and enforce processes, don’t overdo it. I have seen people implement workflow for workflow’s sake. It should be used as needed to improve efficiency and process adoption, but don’t workflow everything.
• Don’t Sweat the Exceptions – There are times where humans need to step in to make decisions and alter workflows. Don’t try to handle every exception condition. If you can identify them and send an alert, great. But most importantly make sure you have flexibility to alter a workflow based on business needs. This is where I see rules-based processes go wrong. Companies try to make rules cover too much, get too complex, and end up being hard to maintain, outdated, and eventually ignored.

The combination of workflow and rules can be very powerful, but can also lead to a resource sinkhole of if not approached cautiously. This is true for the process / rule authors and those that execute them alike.

Implications for Manufacturers

Define your processes. Use workflow where it makes sense. Keep it simple. Don’t try to do too much. Don’t forget that in many scenarios people make better decisions in context than any pre-determined set of rules can handle – don’t tie their hands. If you have standard operating procedures that you need to follow, you may need to document process exceptions. But don’t entirely lock them down in the system. Exceptions will happen, and if the system doesn’t accommodate the real world it will just happen outside of the system in an unmanaged way.

So those are my quick reactions to Oleg’s post, I hope you found it interesting. His post is worth reading if you haven’t already. But I get scared when I see the opportunity for things to go astray. And workflow and rules are a great candidate for bad things to happen. And this is from a self-admitted process weenie!

I had the chance to talk with … a couple of vendors this year about Quality Lifecycle Management, or QLM. I posted earlier about What I Learned: Expanding PLM’s Pervue – Quality and Risk Management and promised to follow up with some more detail on the vendors. Here are my thoughts on my conversations with MasterControl. Before I get started, it’s important to state up front that MasterControl is not a pureplay QLM suppplier, but a broader solutions company that has strong capabilities in document management coupled with a history of helping companies in regulated industries. More on that later.

What do they Do?

Industry analysts like to put software companies into categories and neat little boxes so we can compare them to each other. This doesn’t fit the reality of most software companies or solutions, because – with the exception of some very mature enterprise solutions or point tools – the solution scope and footprint varies from vendor to vendor.Quality management solutions are particularly difficult, because they are often part of a larger solution (such as ERP, PLM, MES, or a combination of the above). As one commenter on my last post rightfully points out, “quality is a series of well defined business processes.” 

So what box do we put MasterControl in? You could start with “Document Management” and cover a lot of bases. In fact, MasterControl does offer document management capabilities for quality processes, including FMEA, CAPA, non-conformance, quality audit, regulatory submissions, and others. But that would not really suffice in an explanation. MasterControl also helps to manage change control, and even position themselves as a “compliant PLM” solution in some instances. Indeed, they can manage BOMs and other engineering and manufacturing data, including the DMR (device master record) for medical device companies. 

What do they Offer?

So not quite so easy to fit MasterControl into a single box, but one thing is certain – they should be considered when companies are looking for QLM. So while they don’t fit neatly into that box, they have a lot of capabilities in that arena and more. MasterControl focuses more on process compliance than product compliance, which is different (and potentially complementary) to some other, highly product-focused QLM solutions. One other consideration that is pretty unique is that MasterControl also helps regulated companies validate their software implementations. They also offer an integrated training module which helps track employee training records, which can be important to compliance efforts and audits.

Who do they Work With?

MasterControl works with a large number of manufacturers in the regulated industries, but also serves less regulated industries. Their customer list spans quite a few industries, including both discrete and process manufacturing industries. They also have a strong presence in midsize companies.

So that’s what I hear from MasterControl, I hope you found it useful. I have talked about two very different vendors so far, which points out how fragmented this market really is. What do you think? Is quality a missing link in PLM? What else should I have asked them?