Tag Archives: defense department

One Fine MES

26 Feb

I’ve been catching up on my old ‘industry vertical’ lately, Manufacturing Execution Systems (MES).

There are some interesting parallels with the introduction of mobile, social, and cloud technologies in manufacturing (referred to by Gartner Group as the Nexus of Forces)  to what the music industry faced in the 1990s with the creation of digital music formats (MP3) and digital players (iPods, etc.).

In an article entitled “Predicts 2014: Manufacturing Operations“, Simon JacobsonLeif Eriksen and Marc Halpern of Gartner speak of the Nexus of Forces as follows:

The Nexus of Forces represents the confluence of mobile, social, information and cloud technologies. Together, these technologies are transforming the way people and businesses use information and collaborate.

Looking back to the two-pronged ‘attack’ on the record industry (MP3 format and internet file sharing), copyright infringement and music piracy were the issues that played out in court, as high profile musicians (Metallica and Dr Dre) as well as the  Recording Industry Association of America (RIAA), made certain that sites such as Napster would no longer be able to share music for free.  The problem was, the cat was already out of the bag.  Portable digital music was here to stay.  While the RIAA and record labels continued to try to stop the inevitable,  the portable digital music train left the station.   in April of 2003, Apple opened the iTunes store.  in the short 10 years since then, the sale of CDs has plummeted:

When music sales reached their peak in 2000, Americans bought 943 million CD albums, and digital sales weren’t even a blip on the radar. By 2007, however, those inexpensive digital singles overtook CDs — by a wide margin — generating 819 million sales to just 500 million for the CD.

So, what does this mean to the world of Manufacturing Execution Systems?  Legacy MES and ERP systems were designed for a totally different paradigm.  Data security and control were paramount, user experience was not even a term that was recognized as important in the industry.

In the 1990’s, we warned that the new workforce would expect the same sort of computing experience on the shop floor than they had at home.  At that point, we were just talking about browsers.  In one implementation that I was a part of, the shop floor users moved very quickly from “I’m not going to use a computer” to “why doesn’t this look like Yahoo?”.

That was then.  What is happening now is a sea change.  Companies that would not consider wifi due to security concerns are now looking seriously at moving data offsite to ‘the cloud’.  The Facebook generation is demanding the same sort of mobile and social tools that are part of their everyday lives to be made available in the workplace.  And, if these tools are not available in the workplace, users will use those technologies outside of the framework of their company’s business systems.

This represents a real challenge both for manufacturing industries, and the software vendors that support them.  The answer is not simply distributing tablets to the shop floor.  There will need to be a new generation of business process management, data security and mobility software to support this next generation of shop floor systems.  This Nexus of Forces is a challenge and an opportunity for software vendors and manufacturers alike.

So, when it comes to the Nexus of Forces, are you going to be iTunes? or are you going to be the RIAA?

-RTR

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

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

MES Global Domination… or not

13 Jan

I have been following an interesting discussion started by Steven Schrecengost on one of the LinkedIn MES groups, “Should I standardize on one MES globally, regionally or allow each plant to choose?”

This is one of the age old questions.  The answer (and the comments) predictably follow the path of “who’s asking?”

IT: 

Standardization is key,  we need to be able to manage all plants from our data center, the more alternatives, the more chaos.

Plant Manager: 

My plant and my people have unique skills, uniques processes and unique challenges.  There is NO WAY the system that corporate chooses for everyone will work for ME.

Here’s the problem, Sparky.  They’re BOTH CORRECT.  But there’s more…

Let’s say that each plant in this enterprise is doing roughly the same type of manufacturing (assembly, fabrication, continuous process, whatever).  In that specific domain, it will probably be easy to find an MES environment that will be configurable enough to fit the need, from a vendor with domain expertise in that specific area.

However, that may not be possible.  There is a company that we’ve worked with that has semiconductor ‘foundry’ operations, electronic assembly, sheet metal fabrication, machining, all in the same division.  Pretty difficult to have a ‘one size fits all’ in that heterogenous environment.

The issue then becomes how configurable is configurable?  You are going to look for a vendor that can provide a system that does not require extensive customization to meet the needs of different styles of manufacturing.  You also need a system that provides the same view of key data (Master Data) to the enterprise, while allowing almost limitless flexibility to the plant.

More information here

-RTR

Intelligent Part Numbers vs. Engineering Discipline

5 Jan

A recent reminiscence about Group Technology has come full circle, with some lively discussion at both Jim Brown’s  (Tech-Clarity) blog, as well as the Arena Solutions blog regarding ‘intelligent part numbering’.  From both a design perspective (reduced costs, not re-inventing the wheel) through manufacturing (reduced inventory) and on to field service (reduced inventory of replacement parts, simplified training, repair/reuse), having an intelligent method of identifying parts has benefits that impact the entire product life-cycle.

Whether we call it Group Technology, part classification, tagging, meta data, the issue is the same…

Building intelligence into part data requires an ongoing discipline that I think we lack, culturally speaking. Back in my Group Technology days, there was a predictable life cycle of GT projects.   A Champion would get a fire in his/her belly to do something about part data classification. Policies and procedures would be implemented, savings and efficiencies would be realized, the Champion would be promoted to management, and, eventually, people would go back to the old way of doing things now that the annoying Champion is out of the way.

The referenced blogs also spoke of how, over time, companies develop multiple part identification systems, which are not compatible with each other.  Add to that the continual divesting and acquiring of manufacturing companies that takes place on a regular basis (L-3 Communications is a great example in the Aerospace & Defense world), and you find you may inherit someone’s part classification / coding system that is (of course) incompatible with yours.

Major A&D OEMs use the concept of ‘synthetic parts’ in their BOMs, the part number is actually a place-holder for whatever appropriate part is available at the time of manufacture.

The PLM providers that are married to specific CAD environments (Dassault, Siemens, PTC, et al) are incented to make their classification tools work best with (or work only with) their own data. They are also incented to make their data less than accessible to their competitors.  It’s just good business sense!

Is this a problem without a solution?  I don’t think so, but, as a Chief Designer once told me, until it is easier to classify and retrieve a part than it is design a new one, designers will design a new one.  This, coupled with the fact that the CAD/CAM industry is bent on creating faster/better design tools (as they should), the chances of a global standard for storing/retrieving part intelligence being developed, adopted, and (most importantly) actually used seems unlikely.

- RTR

Connecting the Dots. Global Interoperability or Global Domination?

14 Dec

A pair of events this afternoon got me thinking ‘Global’.  The first (and I’m not trying to turn this into the Rick & Oleg show again) was Oleg Shilovitsky’s latest blog on PLM and Global Product Development Strategy  The second was an email from a close friend, Jerry McFeeters, who was attending the NIST TDP (Technical Data Package) Standards Development Summit.  Jerry and I met when we both worked for International TechneGroup Incorporated (ITI) here in beautiful Milford, Ohio back in the 1990s.

For those that don’t know ITI, a significant part of their business (and their history) is in the transfer of CAD data (now PLM data) between systems.  I’m old enough to remember the standard data transfer method created in the 1980s, IGES.  An ironic name for two reasons, 1) it stands for “INITIAL Graphics Exchange Standard” (the creators knowing full well that there would be others), and 2) the acronym could easily be pronounce “I GUESS”.

IGES begat PDES (Part Data Exchange Standard), then STEP (and probably a bunch more iterations, I haven’t been paying attention) to get to discussions now at NIST on TDP.

For Jerry, whose life and career had moved away from Cincinnati and CAD, part of attending this conference was being able to connect with old friends from his CAD/CAM days.  Basically, the same people who have been working on these standards since the 1990s.

So, while Oleg is discussing the difficulties that the supply chain would have in adopting a PLM Global Product Development Strategy, my mind is going back to the decades that have been spent in developing data exchange standards.

Here’s the nugget that’s missing from this discussion:

What would a CAD/CAM (or PLM) vendor have to gain by sharing data (or business) with their competitors?

Dassault, PTC, Siemens, et al will talk a good game on standards (they are all presenting at the TDP summit), but this is not in THEIR best interest, and I DON’T BLAME THEM.

So, what does Dassault (for example) see as the answer to PLM and a Global Product Development Strategy?  Have everyone across the globe use V6 and Enovia!  The same could be said for Siemens (UG and TeamCenter) or PTC (ProE and Windchill).

So, here are the dynamics at work re: Global Product Development Strategy:

1) Suppliers need to expand their business to multiple customers and industries to avoid being too dependent on one big customer.

2) The more expansion, the greater the likelihood that this suppliers’ customers will use different CAD/PLM environments.  Back in my CAD/CAM days, I remember how automotive suppliers used to grouse about having to have three different CAD systems in house to support the big three auto makers.

3) There is little or no business benefit to CAD/PLM vendors to support interoperability with their competitors.  In fact, there is more risk than benefit.

This is not a new problem, and a solution that sticks is as distant now as it was when Unigraphics belonged to McDonnell-Douglas, Calma belonged to GE and  Computervision and Applicon ruled the world.

- RTR

Where Does Mobile PLM Belong??

6 Dec

In his ‘Beyond PLM’ blog today, Oleg Shilovitsky (@olegshilovitsky) talks about the future ‘Appification’ of PLM.   He mentions examples of how engineering apps are being made available on mobile devices.  He makes an interesting point on aspects of ‘Appification’ vis-a-vis PLM:

“Two Aspects: 1/ the power of the device; and 2/ granularity. CAD /PLM companies have the opportunity to delivery applications, they want to end users via cool mobile devices. Granularity is another important aspect. PLM is going to be fragmented into a large set of applications used by many people in the organization. One size doesn’t fit all – you cannot deliver a single application for PLM.”

I found this thought provoking as well.  Back in the day, we always used to complain that the cool hardware always went to the design engineers (they needed the horsepower to drive their CAD systems).  The manufacturing engineers got the designer’s used equipment, and the shop floor got the cast-offs from the manufacturing engineers. 

When the topic turns to mobile devices, are we repeating history here?

Companies look at the investment for ‘going paperless’ on the shop floor in terms of networks, hardened terminals, mounting hardware (to keep the computer off the assembly bench).   Software vendors follow suit, providing heavy-client applications to support the shop.

It all seems backwards to me.  Design engineers are far less ‘mobile’ in their job assignments than manufacturing engineers.  In addition, design engineers are still going to be ‘pushing the envelope’ from the hardware performance side.  They have deadlines, sure, but production issues need to be resolved RIGHT NOW.  Mobile computing is made for this type of environment.  Imagine….

  • Field Service Techs using their mobile devices, communicating real time to engineers on customer issues, reviewing engineering changes, downloading as-built information on the product they are servicing, updating the product genealogy when the field repair is made.
  • Aircraft assemblers working on, in, and around the plane, recording key quality data on their mobile devices.
  • Inspectors and Quality Engineers roaming the floor, confident that they will be notified in real time if a crisis arises.
  • Customers “checking in” on progress, buying-off customer specific requirements as they happen.

That’s where the value of mobile product LIFE-CYCLE management is, not just on the design floor.

Visit CIMx Software to learn more….

-RTR

Follow

Get every new post delivered to your Inbox.

Join 136 other followers