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

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.

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.

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.

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.