Driving Work Instructions Content from Design Engineering
Driving Work Instructions Content from Design Engineering
(OP)
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
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





RE: Driving Work Instructions Content from Design Engineering
I got your firs paragraph (I think) but got a bit lost after that.
What is Engineering anyway: FAQ1088-1484: In layman terms, what is "engineering"?
RE: Driving Work Instructions Content from Design Engineering
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.
RE: Driving Work Instructions Content from Design Engineering
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,
Just traded in my OLD subtlety...
for a NUance!
RE: Driving Work Instructions Content from Design Engineering
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
RE: Driving Work Instructions Content from Design Engineering
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...
What is Engineering anyway: FAQ1088-1484: In layman terms, what is "engineering"?
RE: Driving Work Instructions Content from Design Engineering
Barry Lucas
www.sequencesoftware.com