- Contract Packaging
- Leaders in Packaging
- Calendar of Events
Article | September 5, 2012
Does PackML hinder the OEM’s ability to differentiate?
In a recent discussion on PMMI’s LinkedIn Group, James Laverdiere of KleenLine Corp. opined that it was time for broad industry adoption of PackML, describing it as “a standardized language that delivers great improvements for packaging operations.” Here are the two comments that were posted:
From Richard Kurtz, principal consultant at Ptarmigan Consulting: I agree the concept is excellent, particularly for new entrants to the field. Costs for well established companies can be prohibitive, plus there is often reluctance as it can diminish the differentiation of one brand from another. Much more discussion is needed and this could be a forum for this. From Rob Aleksa, recently retired packaging and controls engineer at Procter & Gamble:
During my time at Procter & Gamble, we deployed PackML very successfully on new and existing machines. Some machines were pretty standard commercial unit ops while others were very unique in their capabilities. Both from a technical and a business perspective, PackML was key in laying a solid software foundation. Even the most complex software was constructed in a very logical and efficient manner. This led to our equipment being much more reliable than code developed either by the OEM (assuming they didn't use PackML) or by some outside third party. Why? As the business (product or operations) required software changes, the software was much easier to modify keeping its robustness. Operators had to be taught once and they could go from machine to machine without having to re-learn operational states from one OEM’s machine to another’s. One of the statements I hear often is diminished differentiation. I am completely baffled as to why this is a concern. I assume it's because the industry needs to do more education on exactly how PackML works and what it does. Differentiation should occur between OEMs by the features supplied by the mechanical and servo drives. PackML doesn't do anything to make this common from one machine to the next. The only thing it may do is provide a better software structure to embed servo commands (or encapsulated code) and necessary machine logic. Frankly, a customer would be VERY HAPPY to see the same operational structure from one OEM to the other. I certainly would NOT tell an OEM, "Oh I see you used PackML... that is a deal breaker...I'd be much happier if you randomized the operating sequence of the machine so I have to train every machine operator on each shift. And by the way, I'd like to see a software design framework/structure so completely different from the machine next to it that no one but the ORIGINAL software coder knows how it works!"
We now have many machines working very well with PackML. There have been several incidents where an OEM machine ran so poorly, reliability less than 30% due to poor software (lousy design structure), that our management requested the machine be re-programmed with PackML. After the re-design, reliability shot up to 85%. I can't emphasize enough that PackML has no impact on each OEM's intellectual property. OEMs should embrace PackML for it's business benefit to customers AS WELL AS to the OEM. PackML is pretty cool and what the manufacturing industry really needs to make a leap forward.
E-BOOK SPECIAL REPORT
42 Best Package Designs: 2014 edition
Sign up to receive timely updates from our editors and download this e-book consisting of our editors' picks of most notable package designs. Updated for 2014!