How to make PLM less complicated and more user-friendly?

I think that PLM in general as well as most other enterprise systems are very non-user friendly. My simple conclusion is that all these systems have a ‘push’ behavior – you need to manage all processes, initiate data transformation, send released design to engineering, release bill of materials to manufacturing… processes, processes, processes. We have too many processes to manage, in my opinion… How we can change and transform PLM systems to behave differently?

I suggest that we don’t focus on processes. Organizations need processes but people are troubled by them. They see processes as something that makes their life more complex and slows down their work. They are not good for people. They are not good to people. I cannot understand processes. BUT I can understand the list of my tasks. I need to have data to make a task happen, yet, in most cases my task depends on changes somebody else makes to the data. So, let’s focus on this and imagine that our PLM system is a single Web. Everything is published and organized. You need to be notified when something is changed. This reminds me of RSS!

In order to create a possible revolution for PLM, I think that we need to formalize 3 fundamental steps:

 1/ Stop dealing with processes and focus on data

2/ Manage people’s tasks

3/ Notify people about data changes

I envision a future PLM system that deals much less with processes and focuses more on data and tools. Process management will become a native part of the IT infrastructure and will be used across organizations, without being limited to a particular application domain. 

Share

Share This Post

  • Brian K Seitz

    Oleg,
    I would strongly disagree with item number 1. Its not that one needs to stop dealing with process, its you need to stop dealing with I.T. processes.

    Over the past decade I’ve watched as I.T. organizations have morphed business processes into I.T. programs and procedures; each having a new API, data format and the like, and then to add insult to injury you have to spend even more time “integrating” your own Engineering Data because the applications store it in different formats.

    I know when you look at how a hard good products are design, developed and maintained apart from the I.T. system there is less issues. If one looks at I.T. –a new to the game “Engineering Discipline?” they’re still grappling with coming up with modular components.

    People are not troubled by processes, people are troubled by lack of clarity and flexibility which today’s PLM and PDM systems yield.

  • Brian,
    Good to have you here and welcome to PLM Think Tank! Thank you for your comments!
    You are saying above – “each (application, I assume) having a new API, data format and the like, and then to add insult to injury you have to spend even more time “integrating” your own Engineering Data because the applications store it in different formats.”. I think, by focusing on data PLM will be better integrated into processes. And, of course, processes are important, but to build processes on inefficient product data will make them either expensive to maintain or just not reflecting organizational needs. All KPI and process improvements can be done only when you have right data in your hands.

    Regards, Oleg

  • Brian K Seitz

    This sounds like the debates I had with John Zachman of Enterprise Architecture fame Process or Data. What I’ve seen and experienced of the past 30 years is that people start out with the idea that they will have “THE ONE DATA FORMAT, STORE” or what every. Massive amounts of time and money are spent to create such only to end up with what I described prior. IGES, STEP/PDES are just two examples. Having been in the thick of both and watching vendors jockey for competitive positions of their formats it gets ugly real quick.

    If data semantics and formats could be established aka an Engineer Dictionary of sorts things would be easier. Dr. Fulton of Boeing tried that as an offshoot of the ISO 10303 (STEP) program. Unfortunately it became a unification meta-model project –more glue-code translators or another layer on layers of translators.

    The problem with that was data without context is just wasted space. The process provides that context. So if you’re asking Data or Process, take a side. I’ll tell you neither. It has to be both and it has to be a coordinated effort otherwise you get mush.

  • Brian, I don’t believe in single data format. Some of these initiatives may have local success, but for long term cost of changes in organizations and systems will destroy benefits of single data format (even if possible to create this at all). My proposal to focus on data was to emphasize importance of data over process. If you have right data, than you can make decision that you process require. Also, right data is very efficient foundation for future process and non-process applications and products. I think process built without data will be not be able to create productive user environment.

  • Oleg, from experience I see vendors always go the one data format –even if they don’t want to admit it. There are several CAD vendors that are still cleaning up old code that has multiple data formats and routines for the same function which is executed in various other modules. –a nightmare of the vendor’s own making.

    Similarly STEP turned into the same nightmare. After multiple interations a common library of formats/definitions were created for the higher level APs to use. Guess what, in use the context changed the definition therefore the entity was not really the same.

    To illistrate the point. I had a long, very long debate with my mentor back then. I argued that ere was a fundamental problem in that format, representation, definition, and context all needed to be specified. He said representation was all that matters as there are only so many ways to represent geometry. I said Mike we’re not talking geometry we’re talking product definition. Back and forth through the night we argued till he was so heated he yelled in the phone. I understand you but their are only so many ways to represent a point. I continued pressing tellling him he didn’t understand my point. After another ten minutes SLAM!! He hung up the phone in disgust.

    He called back later after looking up the definition of point in the Oxford and called back sheepishly..I see you point, as a mater of fact I see all 23+ definitions of point we have a problem. My point being it talks an integrated approach Data+Process to have a correct system. Buidlinga system from a data centric approach is not better than building it from an activity only approach. When you really build a true process oriented system you look at both and replicate each element procedure + data as appropriate. If you don’t your create a mess.

    On your other thread, yes SharePoint has benefits, yes it has issues if not used intelligently. I believe it can be used a a coporate infrastructure but not without some policies and practices to address the previous.

    In regard to if you have the right data you can make the right decision…history proves otherwise. The CIA is full of data, but still managed some major boo, boos Remember, there are lies, dam lies and statistics. Data is data to be bent all sorts of ways. One of the reasons FDA now has to validate the math and procedures drug companies use in specifiying and proving validity –I’m working a fun validation project in that field right now.

  • Hi Brian, I think you are too focused on CAD format. I don’t care if this one format or two, but on the level of person/team/organization/value chain, I want to be able to understand what data I have. As soon as I understand it, I can build process that take this data, include decisions and drive personal and organizational activity. My problem that today’s focus is how to organize process, and I think this is wrong sequence if we’d like to improve user’s adoption. So, I agree on data+Process formula, but today we have lots of focus around process and much less around data . Also processes need to exposed to people in simplified way – this is where I spoke about task list.

  • Oleg,
    I would suggest my peers would strongly disagree with you on your first statement about my focus on CAD format. My focus is on Product definition. 2nd the numbers tell another story; data and data management related issues are still the number one, by a long margin, focus of the majority of developers and I.T.

    What I do see though is a lot of people talking about process that haven’t a clue. Its like watching the HR function being accomplished by just chopping up the org-chart and saying we’ve reorganized.

    We do agree on that processes must be exposed to people is the simplest and easiest way. Have reengineered processes for most of my career. I can tell you that making a process simple and easy is hard work. One of the processes I redesign (not engineering related) had over 300 steps initially. The process was so convoluted that no one person could explain to me how it worked or why.

    After a significant investment in learning what they were trying to achieve with the process and the core activities and information needed to support that, a new process emerged less than 50 steps, short cycle time, more accurate and better yield resulting in higher profitability.

    This was not done by building the one true format, nor focusing on building the most elegant process in the world. I am a pragmatist not a purist.

  • Brian,
    I got this feeling about CAD format since you mentioned STEP and IGES, but you are right – probably product definition is good too. Actually industry developed too many TLA (three letter acronyms):)… I’d be interested to learn more about re-engineering experience you mentioned. I’m looking on this as ability to discover something new may be I’m missing in your explanations. What are these pragmatic steps you are following when you re-engineer processes? What tools are you using today?.
    From my experience, each time I see customer deal with processes they have hard time to find data they need to have in order to move between process steps.
    Thanks! Oleg

  • Pingback: Beyond PLM (Product Lifecycle Management) Blog » Nobody wants to use PLM products and it’s okay…()