Program/System to manage Dependent Documents 3

[canty]

Does anyone know of, or use, some program or system of keeping track of documents that either depend on other documents or are interdependent?

The background - I currently work for a mid-size company that is working their way through some rather difficult and complicated projects. Currently, when we receive a change request from a customer, a change order is entered and the person entering the change order has the responsibility to come up with the various aspects of the project that that change would impact. However, we've found that this system is rather inadequate at accurately capturing every document that needs to be changed. So yes, this is partly a people error, but I think there could be a system in place that removes some of that opportunity for people errors.

For example, we'll get a change that requires us to change a part drawing. Correspondingly we'll also have to change the assembly drawing that uses that part, the customer-facing instruction manual, the assembly instructions for the shop, any purchasing instructions, etc. It has happened on more than one occasion that someone forgot to update one of these extra documents. This can be embarrassing if the discrepancy is noted by the customer, and expensive in terms of time and money. The "simplest" solution I can think of is just starting a database of all of the various documents and then slowly growing that list over time. However, it's an extra system to have to check/maintain (we've already got plenty of those) and it will require a fair amount of effort to implement. I know that the software world has many different dependency managers (Apache Maven and Ivy, java has one, almost every linux distro does this), but is there either a software program or perhaps a system that anyone has implemented that can help manage documents in this way?

 

[MadMango]

I would look into

http://www.arenasolutions.com/

We use their PLM package, and it is rather easy and robust. I do not know if they have the security features an aerospace company might require though (ITAR).

"Art without engineering is dreaming; Engineering without art is calculating."

Have you read faq731-376 to make the best use of these Forums?

 

[IRstuff]

No software package can read your mind, nor can it enforce the self-discipline required to maintain your data.

But, don't you essentially already have all of the information in the BOM?

TTFN
faq731-376

Need help writing a question or understanding a reply? forum1529

 

[KENAT]

A PLM system may be able to do this though some of those records may be in an ERP system so unless the 2 are talking you may still miss some stuff.

Not sure why the BOM (at least as a drawing parts list) would necessarily catch purchasing instructions or even user manual or assembly instructions.

Seems most of that needs to be part of the change request/implementation system.

Posting guidelines faq731-376

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

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

 

[IRstuff]

That should have been the indentured drawing list (IDL), not the bill of materials (BOM). But, the MEs maintain the drawing numbers and IDL, so most of our IDLs have assembly drawings, ICDs, specs, etc., even including statements of work (SOWs). We generally pull our technical data package (TDP) based the IDL. In any case, the IDL reflects the drawing hierarchy and the totality of the drawings.

TTFN
faq731-376

Need help writing a question or understanding a reply? forum1529

 

[KENAT]

Sure but some of the items the OP lists aren't drawings even at a stretch.

Posting guidelines faq731-376

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

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

 

[IRstuff]

Our legacy system considers text-based documents as "book-form" drawings.

The only thing that doesn't have a possible home are the purchasing instructions, but if they are technical in nature, then they ought to be reflected in a spec or a drawing.

TTFN
faq731-376

Need help writing a question or understanding a reply? forum1529

 

[KENAT]

It's the purchasing instructions that I was referring to primarily. The manual may or may not fall under the drawing pack depending on various factors.

Posting guidelines faq731-376

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

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

 

[IRstuff]

Our manuals are released documents, so they have document numbers like the other documents and drawings of a project. The purchase instructions are problematic, though. Accepting for the moment that they are not in the panoply of the IDL, that raises a serious problem of requirements traceability and configuration management. If these instructions have a material impact on the end product, then they should be captured in a specification, or a drawing note, or something, and brought into the IDL, at least as some sort of specification document. Otherwise, there is a breakage in the requirements management chain.

TTFN
faq731-376

Need help writing a question or understanding a reply? forum1529

 

[KENAT]

Like you said, if the 'purchasing notes' actually affect end function then the relevant requirements should probably be on the drawing or some kind of spec referenced by the drawing.

However, if they are commercial records like who they were bought from, how many in a lot, pricing... then they don't believe in the documentation package.

Back to the IP, to some extent our ERP system captures this but it still takes some manual efforts to properly implement it.

Posting guidelines faq731-376

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

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

 

[MikeHalloran]

Since the documents are not intrinsically capable of becoming indebted, and therefore indentured, I think IDL should mean
Indented Drawing List.
... but it's still a good idea by any name.



Mike Halloran
Pembroke Pines, FL, USA

 

[IRstuff]

Apparently, it could be both:

http://www.merriam-webster.com/dictionary/indentured

TTFN
faq731-376

Need help writing a question or understanding a reply? forum1529

 

[IRstuff]

But, I think that the meaning is more than just the physical formatting of the list; the indentured items are bound to whatever is above them by the design and the document tree, so indentured makes some sense.

TTFN
faq731-376

Need help writing a question or understanding a reply? forum1529

 

[MikeHalloran]

I accept IRStuff's interpretation.

Mike Halloran
Pembroke Pines, FL, USA

 

[canty]

Wow, what a great discussion! Thanks, all, for your input. I should clarify that while my degree is aerospace, I work for an OEM of control valves and the work that I do is more mechanical in nature. As I tried to allude to in my original post, I admit that the error is human in nature. However, my goal is to develop a system that might help mitigate some of that human error.

MadMango - I think your suggestion for Arena PLM was exactly what I was asking for. However, the more that I think about it, the more I can see it will be an uphill slog to try to implement a commercial solution like this (i.e. there are a lot of "pointy heads" that I would need to convince a commercial solution is needed). Especially since we've got a number of systems already which would potentially be replaced by Arena PLM, this may be something that would be better reserved for a startup company that can fully integrate this into their system.

IRstuff, MikeHalloran, and KENAT - In its current form, a BOM wouldn't catch dependencies on instruction manuals, shop procedures, or other text documents. Some of these items are attached as additional specifications to some parts, but not in the capacity that if I were to remove a set of cap screws from a given assembly and replace with a longer set of cap screws that I would automatically know that I need to go to the IM to update the part number listed for the former cap screws. Granted, this is a pretty basic example and should be something that is quite obvious, but I'm trying to simplify enough to get the basic idea across without going into unnecessary detail. I like the idea of an IDL, but I think that our department does enough "one-off" or low volume orders that it doesn't seem like the optimum solution. I'm also not sure that it fits as well with our current systems. Based on KENAT's responses, I do think that something with our ERP system could be workable. Currently our change management system is separate from the ERP system. I think that this is part (if not the source!) of the problem. As you seemed to be heading towards, I think either tying these systems together, or getting one to fulfill the purpose of the other, would be the best solution.

Thanks again for your input. If anyone has anything further to add, I'd be happy to hear it.

 

[MikeHalloran]

There are fortunes to be made by anyone who can produce an integrated PLM/ERP/whatever system that is usable by ordinary mortals.

Many fortunes have been spent, or squandered, depending on your POV, in pursuit of such a thing, but AFAIK, nobody has even come close to actually doing what you're asking for, or what you appear to need.

There will be no shortage of people who will _tell_ you that they can do what you want. Those people grow their own sharkskin suits.

By way of counterexample, one of my former employers used an ancient POS system that had been extensively hacked, over decades, to 'run' their companies. It was able to search for and find things using fairly imprecise keys, but then be unable to find the same thing using the exactly correct key. It used other people's part numbers, but had the same item stocked under several different part numbers because the antiquated base system couldn't handle some characters that commonly appear in part numbers, and the numbers had been transmogrified differently by different people at different times. That probably happened because exactly none of the system was documented, or exactly none of whatever documentation existed was disseminated to any of the users, ever, over a period of forty years. All the experienced users had their own cheat sheets and memorized sequences of what keystrokes would take them to the screens they needed to do their jobs, using a smallish subset of what appeared to be an infinity of screens. Each user needed individual permission to see every screen, needed IT's assistance to get the permission, and IT was apparently not even aware of many of them. That's not to fault the _current_ set of IT wonks; there has been a lot of mobility in that group over the decades. At this point, they are waiting for the central IT guru, the idiot who bought the original system, to retire or die, so they can rip it out and replace it. ... with what, I don't know, and they don't know, and now don't care. The generation of IT wonks with whom I fought have all departed involuntarily since I did, and the old idiot is still there.
</how not to do it>






Mike Halloran
Pembroke Pines, FL, USA

 

[KENAT]

canty while it has its pros & cons your ERP BOM doesn't inherently have to match exactly your drawing parts list.

By which I mean documents such as Work Instructions and Manuals could be in the ERP BOM even though since they aren't a part as such.

Effectively your ERP system serves the duty of the drawing list IRstuff mentions.

Additionally I'd hope the purchasing records could be part of your ERP system.

The ERP system can then provide some help in doing 'where used' searches etc. You may still have to have the discipline that as part of the change process you have to check 'what other documents may be affected' it's just the ERP helps with this. For instance when changing a part we have to do a where used search in ERP and attach to the ECO form so the approvers can verify we didn't overlook something.

Posting guidelines faq731-376

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

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