Good evening, all. Who's got document creation/management experience and would like to share?

As part of my new job, I get to create and maintain the documents that will guide the build process. I've done this sort of thing before, so I'm not a complete newbie. What I'm wondering lately, though, is how many better methods are out there, compared to the very manual (paper-based) systems I've worked with before.

Right now I have a "yuge" benefit in that there's a single product for me to manage right now. But that will change, of course, and the document collection will get more complex.

There's not a budget for big-name software, nor could we justify it right now with only one live project and two more in the pipe.

At this point, what I think I'm after is a simple Acrobat/PDF-based system. I'd have a "master" document with hyperlinks to PDFs of the detailed operations. Those PDFs would provide the specifics, in words and pictures. I've learned this evening that we can embed video in PDF documents. That could be an incredible improvement over the way I did things before [in a previous organization].

On the surface of it, and in the current (narrow) scope, this seems very workable but I wonder about being scalable for future growth.

Who's got related experience or advice to offer? I do appreciate it, thank you.

I see a lot of Enterprise Wiki for documenting procedures and and Sharepoint for organizing docs.

I'm certainly no expert in these things.

About 10 years ago, we went to CRT based work instructions. Scan the serial number, the system would look up hte product type and revision and display the correct documents.

The benefits were:
1. No paper on the floor to control.
2. Operators always had the correct version of documents to use.

We did Build Procedures in Power Point. They were easy to update and edit. Everyone was familiar with the format.

The way we do it at work for our Methods Of Procedures is super simple. Write MOP in Excel including all linked documents such as site rules and regulations, scopes of work, equipment documentation, blueprints, drawings, schematics, diagrams, etc. After that the various steps to do whatever you're doing. Once your document is written convert it to PDF. All your links will transfer to new document.

If you need to edit the procedure, update docs/links, change equipment name for similar procedures, etc. you edit the much simpler to edit Excel doc. Then just convert it to new PDF and replace it wherever you decide to store them.

quote:

Originally posted by Skins2881:
If you need to edit the procedure, update docs/links, change equipment name for similar procedures, etc. you edit the much simpler to edit Excel doc. Then just convert it to new PDF and replace it wherever you decide to store them.

quote:

Originally posted by heathtx:
The benefits were:
1. No paper on the floor to control.
2. Operators always had the correct version of documents to use.

And that's exactly why I want to go this route.

I'm curious about the scan-to-select method you used, heathtx. Was that tied to a database?

You might consider an open source solution. Read this article for a quick run down.

Of equal importance to the creation and display (or distribution, if you don't use a screen to show them on the floor) of the documents, is organization of them. Keeping track of what files relate to what product(s) can become a huge PITA if don't have a good structure in your document storage system. Whether that's a Wiki or Sharepoint or something else, you need to manage the organization of the documents as much as you do the use of them. On my last job we started with Sharepoint (we were more or less commanded to use it because it was what corporate, HR, and other departments used). Over time we switched to a couple of different Wiki systems. We had the same problem with all of them. When you have multiple people creating the documents, everybody has a slightly different idea of what the "best" folder structure looks like. Eventually the thing becomes a huge beast that nobody can find anything in. Search facilities built into most document management systems, suck. Structure plus the discipline to stay with it (or be very very careful when changing it) is critical.

Hyperlinking sections of a document only makes sense if the sections are shared across multiple documents. If a section is only used in one place it's cleaner, simpler and more easily maintained, to just let it live there. It can always be split out later if things change.

If you do use linked sections and some of those sections are used in documents for multiple different products, be sure to allow for that in your folder structure design. Likewise if a complete document - with or without linked sections - is used across multiple products.

Finally, consider how related documents are stored. Here I'm talking about files that are not part of the build process but are related to it. Parts lists, packaging information (for shipping), component sourcing information, vendor details, purchase order histories, that sort of stuff. That part is boring, but at some point you'll probably save some manager's bacon by being able to find them.

Oh, and on the creation of the docs. I know nothing about creating PDF's other than I can create a MS Word doc and then use a tool to convert it to a PDF, but one thing to keep in mind is to TRY to use the same structural elements within all of your documents. Things like chapters, paragraphs, tables, and so on. This will pay benefits in particular if you do decide to use linked sections, plus making it easier for the end users of the docs to follow them as they work.

quote:

Originally posted by Expert308:
Of equal importance to the creation and display (or distribution, if you don't use a screen to show them on the floor) of the documents, is organization of them.

Very true. At the moment, the manufacturing document maintenance will be "all vthoky, all the time." As we grow, we'll add others who will create and maintain documents, and a common/standard look and structure are certainly very important.

quote:

Originally posted by Expert308:
Sharepoint

Sharepoint has been mentioned by the IT group. It's something I'm going to have to learn.

quote:

Originally posted by Expert308:
Hyperlinking sections of a document only makes sense if the sections are shared across multiple documents.

I intend to just be linking to other documents, rather than linking to particular sections of documents, but I do see your point.

quote:

Originally posted by Expert308:
Oh, and on the creation of the docs. I know nothing about creating PDF's other than I can create a MS Word doc and then use a tool to convert it to a PDF, but one thing to keep in mind is to TRY to use the same structural elements within all of your documents. [

Very true. These documents will be pretty simple -- essentially, they'll be two-column tables, with text in the left column and pictures in the right column. I don't see me having to tackle purchasing/sourcing/other documents -- I'll leave that craziness to the ERP team and their Netsuite goods.

Creating docs will be simple, as you say. Word --> PDF, no big whoop. I tinkered today with alt-text in Word, trying to make it show up in the PDF. So far, I'm apparently doing it wrong. . More learning to do!

All of our controlled documents are through SharePoint. We also use Excel extensively for reporting end of shift and keeping statistics and PowerPoint for certain instances. We still use paper for training documentation for the trainers to initial and sign off on.

quote:

Originally posted by petr:
We still use paper for training documentation for the trainers to initial and sign off on.

That'll be the next thing to tackle -- digital signoffs on training documents.

Not sure how to do this, but tying instructional videos to it, and ensuring that each video is tied to each model, would be useful.

It’s amazing how often a product gets an update, but the instructional materials were not updated/everyone gets mixed up about which materials go with which version.

I was tasked with creating a procedures documentation system but I didn't get to finish it as the company closed in six months after I joined.

My background is in regulated industry of medical device / pharmaceutical manufacturing so my discussion is under the heading of ensuring no adverse condition happens out in the field or else the FDA will close your ass tomorrow if they find anything sloppy in your record keeping documentation.

I'll give you the major components much like I'm naming off the major parts of a house if you were looking to build a house.

Documentation is part of the Quality Management System.

You need a document(s) that specifies your Document Numbering system, Format to be used in documents, approval process for a document, change process for a document, control process for each document as it's created, still in development, approved by various people, process for implementation once approved and released (it can be reworked products out in the field, rework product in inventory, rework product still in manufacturing, start working production to the latest revision at a certain date or serial number, or start working to the latest revision after current component part is used up), training process of people to the latest revision, document control to ensure production is using the latest approved and released revision when they are supposed to and preventing old revisions to be used, records of training tied to the document and to each people trained and qualified to that document, records retention system.

Here is what I suggest: since you're small scale at this point, start with a Microsoft Word document. Build your system first around creating documents using Microsoft Word. Everything I said in the last paragraph, decide how you're going to implement those things around an imaginary Microsoft Word Document. You flesh out those basics first then printing them out to PDFs with hyperlinks will be relatively easy as soon as you figure out how you will secured those documents securely so that only authorized people can access them to read only or to modify. Obviously, the ability to modify a document needs to be exponentially more secure than who is able to read a document. Also, you'll need a system to track relationships among procedures; that is, if one procedure is changed, which other documents should be reviewed to see how those documents may be affected by the change in the first document. For example, if you're manufacturing a component that is common to more than one assembly and you're changing that component, someone needs to review how that affects the other assemblies. This calls for a system where you can look up "where used" for each part that even go up several levels up to the finished product level.

To go back to how form of any document, it needs to be uniform especially if it's for production use. Every document has to have the same main sections such as: Purpose of the document, Policy statement of the company that is driving the existence of that document, Departments affected which, in turn, tells you the minimum list of who needs to approve the document, Responsibilities of the people involved with the procedure, Definitions and References, Appendix section, and finally, Revision history. I actually have this initial document and can send you a copy as a seed for thought if you're interested. Just let me know here and I'll email you a pdf.

Thank you, Rey. Your description is right in line with the system I've dealt with in the previous job. Uniformity and standardization are key, for sure.

I'd definitely be interested in a look at your initial document; thank you for offering to share it.

quote:

Originally posted by vthoky:
Thank you, Rey. Your description is right in line with the system I've dealt with in the previous job. Uniformity and standardization are key, for sure.

I'd definitely be interested in a look at your initial document; thank you for offering to share it.

I just emailed to you. Sorry, I've been busy with other things.