Just to add to the discussion.
Activity: "doing something" (I kid you not)
Process: activities that use inputs to deliver an intended result (output|product|service).
Procedure: a specified (described) way to carry out an activity or process. Easiest comprehended by reading as a documented procedure.
But why then distinguish these at all? Because we could in the past distinguish between what we had to say about them.
These days, "document (verb)" is 'conveniently' said to encompass the requirement to also establish, implement and maintain.
So we have a process that can be established, implemented, maintained, and documented. This is in addition to them being used to define, communicate.
To me establish (contrasting ISO's vague define/make) means tagging it with an identifier, and by implicit matters listing its inputs, outputs, the needed relations and the intended result after that process has been executed, undergone etc.
Implement means to "put into effect or practice". Maintain means to "enable to continue".
I don't quite like the interaction, which implies implement is the kick-off, and maintain is simply keep going. In most of my mentoring interactions, implement means easing it into the (quality) system, activating those established relations. Maintain means reviewing, adjusting it, keeping it up-to-date both with other parts of the system and with best practices outside of the system (e.g. updated standard, best practices or feedback from the market). The actual obligation to execute as needed is inherent in the presence within the system, and it can be either continuous, contiguous (periodical), or circumstancial (event-based, i.e. in case of fire do this, or when the order comes in execute); I feel that the word implement doesn't quite catch that feeling.
Competent people can know what is the needed input, output, what to achieve (establish), when to do so (implement), and assign responsibility to keep it aligned with the rest of the system and developments in the profession (maintain).
We all perform many processes daily which we don't have a written procedure for. We're competent, or if not we ask help, or a check on what we did.
The requirement to document one then becomes one of commitment, verifiability, support to explain (possibly, but not necessarily to train), ability to align other processes, ability to exchange personnel at a certain level, additional controls when the task is of such criticality you cannot leave it to memory and competence (the pilot's take-off checklist).
Instructions are best seen as used to teach, not execute. Remember that in the highly succesful Training Within Industry practice, the most detailed notes were only for the instructor (how words can line up). They were used to develop the instruction provided to the trainee, who had only a checklist of the most critical steps to check on (checklist).
What do most people like best when executing a task? A checklist, often in the form of a brief sheet or even a form to be checked off or filled in, and even checked again by someone else.
What do people prefer to see when being trained? All the textual detail: no. They want to see the chunks and the relations that allow them to make sense of it, give it a place in their mind to be able to recall it.
Who is able to give a comprehensive training without ever having thoroughly worked out what is they want to say. What would you use to train other instructors|trainers? I cannot give someone less than everything they need to teach, and probably need to give them more to be able to explain all the cases, evaluate exceptions etc.
Example:
Instructions for use are mostly (expected to be) read before the first use (interaction).
Manual is something more comprehensive, taken to be at hand when you run into problems, but not necessarily used in every immediate execution. Often it stands in for instructions, but still doesn't show everything, only the critical steps.
We look at what the standard and its terminology has become, but forget both where it came from longer ago, and how the form dictates how it will be used in the here-and-now because of human nature no matter what you call(ed) it.
At times I'd argue that work instructions were instructions to execute work. A list (Bill of Materials, Production Order), that instructed/told you how to configure or what to make. The how was in the competence, and only that instruction was new. If you're making the same every time it would just be orders to execute something you already knew how to.
Hierarchy (assigned status through title) has less to do with it than affordance (design/usability). The form/content of a document is more telling of how people (will) use it or ignore it than the artificially assigned priority, unless your organization is utterly disciplined or controlled. People will peruse only section headings, skip to images, prefer flowcharts that take up more space, scan bulletpoints more when they're pressed for time or believe they're competent and just need that little bit of confirmation. They'll not believe a short document can hold the answer if their problem is huge or has been haunting them for a long time (though once accepted, you'll get the a-ha of disbelief). They like people telling them what to do (minutes long YouTube videos) while a 30-second read could provide the same information. They prefer seeing it, just jotting the core sketch with that crucial action they were missing, and then going out to the car and fixing it (after likely first just having tried it with what they already knew). It's the same reason why, as competent auditors, we don't readily accept written procedures as proof that now everything is fixed, as its not that document that holds someone accountable to actually doing it, or doing it in that way.
I believe human nature informs us on how things should be to elicit or prevent certain responses from people. Thus establishing processes informs competent people, procedures provide additional confidence where people have accepted that the knowledge in their head is not fully reliable, and instructions are useful for increasing the competence of people, checklists are that extra bit of confirmation, forms are when you need resulting records to be interpretable for a long time or en-masse.
