Driving Work Instructions Content from Design Engineering 1

[Erewhon69]

The development, publication and maintenance of Assembly and Process Instructions in large Enterprise applications has always been difficult and error prone. You get it right at release, but revisions to design , tooling or processes that impact the down stream seems to lag - at least long enough to get tagged.

All modern production design and manufacturing systems are perfectly capable of 'driving' most of the engineering drawings and related notes directly into the production paper - keeping engineering requirements aligned with the manufacturing instructions. When I hear complaints about having to manage 50 to 100 pages of work instructions per major assembly step - invariably no one has found that whether it's CATIA, SAP, PDM, they are all Object Oriented data management systems based on MRP logic.

Most just don't know what their systems can do - or have disciplined the Design Engineering groups into releasing systems "palatable" BOM and Model structure. Let alone manage BOM and data structure to reduce maintenance through proper use of deletive logic product optioning, or use release Model Unique ID fields to quickly and accurately retrieve and review collections of released engineering.

I would like to hear about your related trials and tribulations - and would like to start some discussions on this or related topics. By sharing problems, perhaps we can find Systems Based Solutions. When a problem can be solved by following a process defined by computing processes, it eliminates the growth of 'hacks', the proliferation of manually written process 'work arounds' and 'territorial' disputes.

Erewhon69

 

[KENAT]

Erewhon69, any chance you could rephrase the question without the buzz word bingo?

I got your firs paragraph (I think) but got a bit lost after that.

Posting guidelines faq731-376

http://eng-tips.com/market.cfm?

(probably not aimed specifically at you)
What is Engineering anyway: faq1088-1484​

 

[ornerynorsk]

Are not revisions to instructions and BOM's part of the engineering change order process? It should be methodical and straightforward. When I see someone speak of hacks, work arounds, and territorial issues, it's a company culture problem, not a systems problem.

It is better to have enough ideas for some of them to be wrong, than to be always right by having no ideas at all.

 

[SkipVought]

In a product's life-cycle, there may be at least 4 different bills of material: The as-designed BOM, the as-planned BOM, the as-built BOM, the as-maintained BOM.

A tremendous amount of effort is expended in reconciling the first three, explaining and justifying deviations. In my experience from afar in the aircraft manufacturing industry, it comes down to the structure of the organizations, that each march to their own priorities. Work from one organization is tossed over the transom to the next, with all the finger pointing that come with poor communication and understanding.

About 20 years ago I was involved in a "conference room com version" project to upgrade our MRP system. The product that had been purchased was a bust, after spending over $20 mil, but the silver lining in the dark cloud was that the participants went back to there respective departments as evangelists of cooperative design & development. With just a modicum of change in this respect, there were noticeable improvements in communication and cooperation. Unfortunately, the management never got the message and things eventually devolved.

A similar thing happened with tagged parts. The GM stated we would see tiger teams, engineering, manufacturing, quality etc, get these things resolved quickly. They still wait for months to resolve defects. Management can't seem to pull it off. And the individual participants inherit that mindset as well.

Manufacturing marches to realization. Production marches to schedule. These two are almost always at odds, cuz the high realization parts are not the parts needed for the next assembly at the right time. But that's NOT how management measures their performance.

O the best ERP or the best CAD or the best, you name it, cannot overcome an organization that promotes uncoordinated and/or uncooperative departmental involvement. It's not the information. It comes down to understanding human nature and designing rewards that will accomplish the ultimate goal of delivering a superior product to the customer for a price that the customer is willing to pay at the time the customer needs it.

Skip,
[sub]
Just traded in my OLD subtlety...
for a NUance![/sub]

 

[Erewhon69]

Thanks for the responses. I will refrain from the acronyms.

I don't want to sound jaded either but so often while attempting to find a solution to a chronic failure or to decrease cycle times or LEAN a product flow, I find great disparities between how the computer process flow description reads (or is capable of )and what passes for written procedures the employees follows.

Often it is these discrepancies that drive the "anomalies" that too often get attributed to things like human error, or a "crapy" computing system or despite everyone's best effort, just won't do away. This results the mess you get when you try to squeeze a toothpaste tube with the cap on, it oozes out the weakest point - and if you reinforce the weak point, you discover yet another weak point.

This in not improvement. This is moving the problem from one place to another. It has been my tendency to compare what the manual tasking for the employees is and asking this question; "What is the computing systems capable of and can provide ?" Invariably I find major or at least partial solutions in the system architecture.

If I could help anyone avoid experiencing future problems by letting design engineering or traditional processes or the ubiquitous attitude of 'What does it matter?' decide the form the released data takes (drawings or digital models). Ensuring that all released data is properly formatted to ALLOW consumers of that to avail themselves of the systems fullest capabilities.

I will provide some specific scenarios on how improper structure, bad data definitions and non-compliant processes can cause problems for enumerable people down stream, and set up roadblocks for the future and inhibit a companies ability to grow and remain efficient.

Erewhon69

 

[KENAT]

OK, so one point I will make that from a Design Engineering point of view (Per ASME Y14.100 series) the prime goal of an engineering drawing is to define the finished product. I.e. define what is required/acceptable.

I liken this to putting a cross on a map of where the destination is.

However, engineering drawing generally (with some exceptions) does not define how to achieve the end product.

Going back to my map analogy it doesn't show the route to be taken from your current location.

On the other hand a Work Instruction/Routing or whatever you term it tells you how to achieve the end goal.

It's more like a set of directions "turn left at yellow house, carry on past the big tree until you reach the cottage with the red door ...."

WI should be more flexible to allow changes of process fairly easily.

Back to my map/journey analogy if traffic is heavy on the high way it should let you take the surface streets...

Posting guidelines faq731-376

http://eng-tips.com/market.cfm?

(probably not aimed specifically at you)
What is Engineering anyway: faq1088-1484​

 

[blucas1]

While I too am having a hard time following what it is that is really being asked, it appears to focus on the lack of "connectedness" of the various silos of information that exist within a manufacturing company and some lack of understanding of the architecture of these systems so that conduits can be built between these silos - BoMs, Routings, Work Instructions etc. What we have experienced is that companies with IT that "gets it" have this connectivity sorted out. For example, we work with a number of customers that develop an eBoM in CAD or PLM, export this to ERP at which point it becomes and mBoM, and then allow this BoM, Routing, Operations, etc. to be picked up by their enterprise work instructions system which continuously receives updated BoMs and notifies manufacturing engineers of changes. Conversely, manufacturing engineers can conduct Kaizen or CI events from the floor that only affect manufacturing and make those changes without going back to design engineering. This seems to be a well-accepted flow of information and works very well when rigorously implemented.

Barry Lucas

http://www.sequencesoftware.com