Have you ever encountered this method and is it inferior to extending past a fold line?

His reason for doing this was a) fusing should never end on a fold line and b) it should not extend past a fold line because it is adding bulk to the fold line, leading to…a bulky fold line (?)

Your method seems to make more sense to me, but I’d be interested to know if stopping short of a fuse line is bad practice.

I suppose it would be a little like a swimwear company acquiring a mountaineering gear company and then standardising their best-practice swimwear seam construction and finish for all products produced by the combined entity. Or eliminating the mountaineering gear testing department and assigning the task of product testing and development for the combined entity to the swimwear company.

So we really need to decide on best practices *for a given use.* Kathleen may have the nec plus ultra of faced lapped zipper applications, but maybe we don’t want a faced lapped zipper. Maybe it’s a single-use industrial item and we genuinely want the cheapest, fastest zipper application possible, and we really don’t care at all whether the seam allowances are correctly aligned and we have a tolerance of 3/4″ for the dimensions of the finished item. Maybe we’re going to be using the cheapest zippers available on any given day, which might all be slightly different sizes. Maybe we want a drawstring.

It may be significant that the examples provided by Alison contrast the behavior of engineers with the behavior of doctors. Engineers, in my experience, are notoriously famous for “doing what it takes to get the job done!”

Returning to best practices: I think there are often problems associated with integrating systems and processes from organizations that have developed the systems and processes in response to unique or local requirements. Alison’s ERP comments may bear this out. The existence of problem situations may be independent of whether or not the conflicting processes started out as “best practices.”

Perhaps also it is a good idea to clarify in this discussion when we are talking about “industry wide” versus “company wide” standard practices. Also, some people (such as myself) may not automatically equate “standard practices” with “best practices” since “standards” are sometimes equated with “lowest common denominator.”

I don’t think that’s what Kathleen is talking about, though. I work for the network engineering department, and we have been spending the last six years or so developing and refining our use of databases and our system for issuing designs to the people who will implement them. Nobody really thinks that each engineer entering data into a database using their own idisyncratic interpretation of requirements is a good thing, and all engineers cooperate enthusiastically on each new standardisation project, just like Kathleen says.

An excerpt from Blink by Malcolm Gladwell, discussing doctors’ resistance to substituting a standard algorithm for diagnosing heart attacks for doctors’ own experience and judgement:

“‘Doctors think it’s mundane to follow guidelines,’ [Arthur Evans] says. ‘It’s much more gratifying to come up with a decision on your own. Anyone can follow an algorithm. There is a tendency to say, ‘Well, certainly I can do better. It can’t be this simple and efficient; otherwise, why are they paying me so much money?””

…
“The algorithm frees doctors to attend to all the other decisions that need to be made in the heat of the moment: if the patient isn’t having a heart attack, what is wrong with him? Do I need to spend more time with this patient or turn my attention to a more serious problem? How should I talk to and relate to him? What does this person need from me to get better?”

This is absolutely the spirit in which standard practices are implemented within the company I work for.

Note that both Kathleen and I talk about situations in which the implementers have a feeling of ownership toward the standard practices: in the case of the company I work for, this is because the people who implement the practices are the people who created them. And everyone is welcome to propose and develop an improvement at any time, at which point it must be shared with all engineers across the country.

My experience is from the world of IT departments and computer systems development and management, not from manufacturing. The reason I read this blog, though, is that the insights here I find to be universally relevant and not limited to any one industry.

Back to best practices. Frequently (but not always) best practices involve both equipment (technology) as well as (human) processes. Technology and process have to be managed together.

Here’s what I’ve found to be a problem with how best practices are implemented: A best practice, whether it’s for sewing on a zipper or for responding to a customer billing inquiry, is not a standalone operation. It has to interact with other operations. Some of these operations, whether they are homegrown or “best practices” imported from elsewhere, interact differently in different companies. It’s the management of these unique interactions via changes to technology or process that can lead to major cost increases and overruns when “best practices” are introduced to a company.

Again, I’m drawing on my own experience with computer systems as a basis for these observations. Two specific examples are the following.

The first is that many years ago companies began to adopt monolithic “ERP” systems to help manage basic inventory, financial, HR, and other operations. The systems had been developed around the concept of “best practices.” What many companies found themselves doing was spending huge numbers of $$$ to adapt and implement these systems to their own unique circumstances. A major aspect of this complexity was not the best practices as embedded within the ERP system, but the facts that (a) the systems had to be adapted to local conditions to make them work and (b) local business processes had to be adapted to accommodate the “best practice” defined by the new system.

OK, maybe this is just a fancy way of saying “change can be expensive” but I assure you that many consultants made a very good living for many years helping companies implement these best practices based systems and there continue to be arguments to this day about the cost-benefits of such systems.

The second point is about the increasing number of Internet based systems that are becoming available that may negate the need for companies to purchase and install software on their own machines. These days, for example, a large company can avoid buying its own sales management system or customer support system and get everything it needs as a “web service.” Here all data and functions are accessed through a web browser and stored remotely by the service. In other words, why buy when you can rent — especially if what you rent is based on a “best practice” and all you need is an Internet connection and a web browser to get at it.

The same issue applies with web based services that are “rented.” Best practices don’t exist in a vacuum, they have to interact with other best practices and other operations, and that interaction needs to be managed, whether the best practice is home grown or not. In my experience, it’s a failure to anticipate the “ripple effects” caused by implementing a best practices based system that cause cost overruns, staff turmoil, and management headaches.

So fundamentally I agree with the concept of best practices but I have concerns about real-world implementation and how you manage it.

I’ll use this, as we struggle with this very perspective.

Thank you!