Tag Archives: automotive

Comments on PLM Technology vs Vertical Industries: Wrong balance?

14 Apr

RealTimeRick:

Reading the latest blog by Oleg Shilovitsky on PLM: PLM Technology vs Vertical Industries: Wrong balance?

Oleg, you have hit the nail on the head. This reminds me of an old shop joke (which I may have used before). Shop guy goes to the tool crib and asks for a large screwdriver. Tool crib attendant asks, “Slotted or Philips head?”. Shop guys says, “Either one is fine, I’m going to use it as a hammer”.

There you have it. You can’t be all things to all people as a PLM (or MES) system. There are vertical industry specific rules, data structures, even nomenclature, that will trip you up at any time.

I recall a demo with a ‘PLM/MES’ vendor where they were extolling the virtues of their process planning tool. Now, where I came from (aerospace & defense), a process plan was a document used to describe how to create a part from raw material. What this vendor was showing me was how to lay out an automotive assembly line!

What I called a process plan had no context in automotive. Further, the idea of work instructions is an anathema in the assembly line world. They DO have work instructions, but they are set up facing away from the operator. With a vehicle rolling by every 42 seconds, you don’t want someone distracted by reading instructions, Before you get to your station, it’ assumed you know what you need to accomplish in those 42 seconds.

From that standpoint, a lot of vendors ‘go vertical’ at the start. Those that decide to do it later have to walk the fine line between being too specific and losing other verticals and being too generic and too thin to provide real value to any vertical.

– RTR

Originally posted on Daily PLM Think Tank Blog:

plm-industries

Let’s talk about PLM technologies. Err.. PLM is not a technology. Even more, PLM is even not a product. So, what is that? Business strategy? Product development politics? For the sake of this conversation let’s leave these debates out. I want to speak about PLM technologies that allow you to manage product data, CAD files, bill of materials, rich set of related information as well as processes around it. This technology came to us about 20-25 years ago first as a very hard-coded set of tools. You had to build it literally different for every customer. So, it supported only large customers that were able to pay for software, infrastructure and implementation. Later on, PDM/PLM turned into software toolkit. The next step in PDM/PLM technology evolution was called flexible data modeling. The first flexible (dynamic) PLM data modeling tools were released back in 1995-2000 and… not much changed since then.

View original 478 more words

It’s All About Your Niche, Do You WANT to Leave There?

9 Apr

Back to reading my original blog muse, Oleg Shilovitsky.  In a recent blog (“Ugly vs. Cool”) he took PLM vendors to task re: their product user interface.  It got me thinking:

What do my previous company, CIMx Software, and my current company, Vinimaya, have in common?

Although there are many differences, and many other reasons for their success, both software companies are, in part, successful because of the failings of another industry’s functionality and user interface.

Ask any PLM vendor and they will say that they support manufacturing.  Truth be told, they have products designed and built for the design engineer and management of design projects.  The user interface is designed by engineers and for engineers.   The schemas and taxonomies of the PLM system do not support the workings of the manufacturing shop, and the user interface is way too complex for the casual user.  In the case of CIMx  Software, there have been numerous attempts by the engineering organizations at CIMx customers to ‘standard ize’ on the PLM environment for manufacturing and shop floor.  At one particulart customer, there were close to 1/2 dozen ‘pilots’ of the PLM system in manufacturing engineering.  They all failed to provide what CIMx had out of the box.

The same can be said for ERP ‘eProc’ applications and Vinimaya.  If ERP vendors provided simple federated search across all of their internal and external suppliers with a user interface like Google or Amazon, there would be no need for SmartSearch™.   That’s not the case.  eProc systems tend to have the same laborious click-heavy, multi-screen UI issues as most ERP and PLM functions.

Why is this so?  It boils down to two elements, legacy and domain expertise.

1) Legacy.  One of my favorite quotes about the software industry is “God created the universe in six days because he didn’t have an installed base”.  It is extremely difficult for established vendors in a particular space (ERP, PLM) to completely re-write their large monolithic systems.  They can certainly apply a web ‘veneer’ and update icons and other visual elements, but it’s the same old code underneath.

2) Domain Expertise.  I recall the amazement in the voice of a colleague in the MES space when he had to explain to their PLM partner the  concept of a work order.  You may know the technology behind and engineering bill of materials backwards and forwards, but that does not mean your expertise has any value down on the shop floor.

So, where do you want to live, Mr. ERP vendor?  Mr. PLM vendor?  The more you decide to venture outside of your area of core competence, the more you will have to be concerned about functionality and UI, and the less likely you will be able to compete with the likes of CIMx and Vinimaya.

- RTR

If It’s All About Process, Why Focus On Features?

22 Feb

The following was tweeted from the PLM Conference at the Westin in Munich this morning by Gabriel Gheorghiu:

“Marc Halpern (Gartner) some of the best #PLM implementations done without PLM software. Processes matter most #plm2012

If this is true, and I believe it is, then why on God’s green earth do companies still go through the same drill, asking for a feature list, looking at features, providing RFIs/RFPs that talk about features (example: 314 features in an RFP that we answered last year).

What do features matter?  It’s ALL ABOUT THE PROCESS.  It doesn’t matter how shiny it is, whether or not it’s on the cloud, what technology platform it runs on.  Here’s all that matters:

Do you have a reliable, efficient process?

Does this software make that process better?

’nuff said

- RTR

They’re Doing It Without You!

14 Feb

I owe this inspiration to SAP’s Paul Boris.

There is a long-running dialog on the LinkedIn Manufacturing Execution Systems Group, started by Luigi De Bernardini , entitled “Does any ERP need an MES?”  It’s been up for about two weeks.

BTW: Paul’s answer was

“That question is really like asking do you really need a heart AND lungs ?”

… but that’s not the the inspiration.  The inspiration came from his opening paragraph, which was both humorous and insightful, and I told Paul I would steal it:

“I believe everyone who manufactures anything has an MES – it might be a specific Manufacturing Execution System, Microsoft Excel Spreadsheets or even Many Employees Scurrying around (sorry) – but they have something.”

After laughing out loud, I realized this really brought home something that is key to all software vendors selling in the Manufacturing Space.

Nobody is sitting around waiting for your application, Sparky!

They have stuff to make.  They have to order material, build stuff, cut chips, deal with the day-to-day issues that manufacturers face.  They are lean.  They have no time.  Covey Quandrant 2 activities?  Not so much.

When they finally DO have time to look at your shiny new application, be careful to look at their body language, facial expressions.  What are they telling you, once you are actually paying attention to them?

“… it looks impressive, but how long will my shop be down in order to make this work?  I don’t have ANY time,  so where am I going to find implementation time?  PLEASE don’t tell me I have to ‘re-do’ my old work in your system.”

Why do these shiny new applications fail to generate excitement in the plant manager’s heart?  Because they don’t take into account that the work is being done now without them.

You have two choices:

1) Build a compelling case for why the shop should be disrupted for months (if you can)

2) Build an application that can be implemented without disrupting production

Learn more about option 2  here

- RTR

Reality-Based Software

23 Jan

The ongoing discussion started by Jim Brown (Tech Clarity) re: “A Maturity Model for Product Data Accessibility?” at the PLM CAD CAM Network group in LinkedIn continues to be thoughtful and insightful.  Jim responded recently with this quote regarding ‘sloppy data’

For the record, I wasn’t suggested that individuals should be sloppy – the pursuit of accuracy and order are important.  But instead saying that we live in environments that tend towards chaos no matter how hard we try, and we need to keep doing the job that customers pay for (designing and producing great products) in that reality.

YES!!!!

It is so common in our industry to assume we know best.  I hear software people talking about “educating the customer”.  Not so fast, Sparky.  I maintain we have MUCH more to learn FROM our customers and prospects than we can ever teach them.  Do we have something to offer?   You bet….  but don’t prescribe before you diagnose.

In the paperless manufacturing space, this “know it all” behavior is rampant.  We can improve your bottom line, provide new efficiencies that you never thought possible, make your key traceability and quality data accessible electronically.

All you have to do is… change everything!  Those MS word work instructions?  Sorry, you have to re-enter them in OUR environment, so they’ll be ‘useful’.  No, we don’t have a converter, but cut and paste should work for those 10,000 docs, right?  Those ERP routings?  Everyone knows that the ERP routings are incomplete, we’ll just take over that task as well.   Oh, by the way?  for this to work MOST efficiently, we need to own the BOM as well..

Is it any wonder that most companies (especially in the small to medium business space) look at paperless manufacturing with a sense of dread?  If they had the time to turn their organization upside down, they wouldn’t need the help!  At the end of the day, they need to produce product.  Everything else STARTS in 2nd place.  I imagine re-keying in existing information is well down the list.

The approach that needs to be taken by software vendors is what I am referring to in the blog title: 

Reality-based Software.   

Paraphrasing Jim Brown, software vendors need to do the job that customers pay for in the customer’s reality not the vendor’s reality.  Learn more here

-RTR

The Problem with [PLM/ERP/MES] Integration… Is it People?

20 Jan

Since I started blogging, the ‘inspiration’ comes from two sources. 

1) Interesting things I read online or elsewhere (I am not completely paperless)…

2) Bolts of lightning

This is one of the 2nd variety.  A few of us here at CIMx were having a philosophical discussion on manufacturing process, when the dots were connected, the switch was thrown and the lightning bolt commenced. 

Is there something missing in the integration discussion?

Integrations have gotten more complex.  Technologist will continue to advance technology.  Flat file transfer becomes neutral interface tables which becomes XML and web services.  Automated error recovery.  Electronic alerts.

So why do integration projects still run overtime, over budget?  Why do the most painstaking designs still produce code that doesn’t do the job when push comes to shove?  Could it be… people?

In a previous company, I developed an integration for an automotive OEM.  This integration provided updated scheduling information for the production of stamping dies.  There was a 2″ looseleaf notebook that described the process that they used in excrutiating detail.  I codified that process and produced the integration.  Done deal….

Except it didn’t work.  After lengthy discussions and discovery, we determined that the detailed process never worked.  In their paper environment, manufacturing engineers would manually fill out the information and feed it to a clerk.  The clerk would then change the information and re-key it into the scheduling system.  The missing piece was the logic in the clerk’s head that described what the data really  meant and how the system should see it.

I’ve heard story after story in a similar vein.  There’s always an exception, always a unique case.  Computers are only as smart as the program they’re running.  People can analyze, synthesize, make exceptions, break the rules, to get the job done…  and they will

The moral of the story.  It’s not the technical connection of data you need to work on.  It’s the people side of the process….

- RTR

Quality Management Software – A Victim of Culture?

16 Jan

I’m looking forward to what Matt Littlefield (LNS) will be writing about Quality Management Software.  This is an area that, in some ways, appears to be a victim of its own culture.

Let’s go back to the days of stone tablets (‘scuse me) paper-based processes in manufacturing.  Like last week, for example.  The quality department and quality processes were always adjunct to actual production.   Design engineers would design a product and would work with quality engineering to define those critical characteristics that need to be tracked through manufacturing.  Let’s say this is an aircraft part/assembly that is being built for a larger OEM, or, for that matter, built by a supplier.  Throughout this supply chain, there is the need to produce a ‘first article’ (for quality), with a corresponding AS9102 filing to document this first article.  Inspectors work with the shop to insure that all of this first article data is collected (on paper) and forms are filled out to comply with the OEM/customers process.

Once in full production, the quality organization is then tasked with providing inspection resources to insure that part/product quality is maintained.  If there is a question on the floor?  Call an inspector.

I visited a consumer products company, a big ERP user, to meet with their quality organization.  They were looking for a paperless system.  I was a bit puzzled, as the products they made were made by highly automated systems.  When we sat down in the quality office, the reason was clear.  We were surrounded by Iron Mountain storage boxes full of data collection sheets.  In this highly automated plant, there were requirements to collect quality data, on an hourly basis, on paper forms.  These forms were then reviewed by a quality person, and an OK was given to ship product.  This OK (or rejection) coming days after the product was completed (the product was stored in a warehouse, awaiting quality approval).  Even in this highly automated plant, quality was separate.

So, how does this make quality management systems a victim of their own culture?  It’s the paradigm.  Quality is something external to the production process.  QMS systems tend to become an electronic version; another system that manages a specific user community.

What if quality was just part of the process?  What if these quality issues and processes just became part of an overall electronic business management environment?  There are MES vendors that have taken this approach, but it shouldn’t start and end there.  When you look at most ERP, PLM and MES solutions, quality is still a separate module, not part of the main business workflow.

Until that happens, Quality Management Software might just become an electronic replacement for “the way we’ve always done things”.

-RTR

Follow

Get every new post delivered to your Inbox.

Join 136 other followers