Process, Procedure and Task

A task is the steps for doing a particular piece of work.

Procedure are activities made up of a series of tasks.

A process is an upper level description of a series of activities required to accomplish an objective. Processes are made up of procedures or tasks. They have inputs and outputs.

Process	Procedure	Task
Flow of sequences of activities that transform input elements into results	Specific and required way to carry out a process	Describe the correct steps to perform a specific task
What we do By Whom Where it takes place When it happens	How the work must be performed	How to accomplish a specific task within a process with very detailed directions
Orchestration the work	Mandatory method	Mandatory guidance
Can link to 0, 1 or more procedures	It may consist of 0, 1 or more task instructions	Focus on the instructions of 1 task
Transversal by business units	Cross functional or only 1 business unit	Only 1 business unit
Participate more than one role	Participate more than one role	Participate only one role
Encapsulates activities	Explains how to do but doesn’t get to all the details of how it is done	All of the detail of all the steps to follow in an activity
Provides the workflow model at the highest level using BPMN	Document with both narrative and images, usually in the form of use cases and workflow diagrams	Document with the maximum detail that explains step by step the instructions that must be carried out in an activity

Process, Procedure and Task Differences

This is the middle of a traditional document hierarchy and forms the Functional set of documents.

Doorway Effect

Vivian Bringslimark recently shared an article “It’s not just doorways that make us forget what we came for in the next room“

This definitely brings to mind how movement is one the traditional Lean wastes.

It also gets me thinking of the first principle of human performance – People Make Mistakes

Research like this really drives home the importance of reducing reliance on memory in our processes.

Training Plan

As discussed in the post “CVs and JDs and Training Plans” the training plan takes the job description and then says what a given individual needs for training requirements. It does this by looking at the role on a job description and cross-referencing it with the training requirements for the role established by the process owner.

The functional manager is responsible for determining for any given job which roles within a process an individual has.

The process owner, for each process, then sets the training requirements for each role.

Take, for example, a job description that has these three job responsibilities

Lead inspection readiness activities and provide support during regulatory site inspections
Participate in the vendor management process including the creation and review of Quality Agreements with suppliers
Write, review and manage approval of deviations, change controls and CAPA’s

Those three bullets contain a ton of job requirements that translate to roles in processes.

Process	Role
Inspection Readiness	Lead
Regulatory Site Inspections	Support
Vendor Management	participant
Quality Agreements	Author Review
Deviation/CAPA	Author Reviewer Approver
Change Control	Author Reviewer Approver

Roles and Processes from an Example Job Description

The functional manager when writing the job description should understand the exact roles in the processes. A good practice is to have a catalog as part of the process framework. For example, participant may not be the right role name and a more specific role should be used.

The process owner for each of those processes has (usually with help from the training unit) determined the right training for each role. These are usually made up of curricula with individual items.

It’s useful to think of these curricula as building blocks. For example, quality agreements, deviation/CAPA, and change control all have a technical writing curricula. The training unit can have a curricula for technical writing and add that to specific roles as appropriate.

The training plan is a key record, on which everything else hinges.

In an ideal world this should be automated. But in my experience it is manual as the job description is not functionality in the Learning Management System and it involves a degree of translation to build the training plan. This is an excellent opportunity for anyone who reads my blog that works for a company doing an LMS to wow me.

Changes to the job description drive changes to the training plan. As an individuals work changes, so to does the processes and roles they interact with. This is the responsibility of the individual and the functional manager is accountable.

Changes to the processes drive changes to the training plan. The process owner is accountable here.

Records in the Training System

Records serve the purpose of controlling and directing the organization, helping to orient personnel to a common goal or purpose. For the purpose of training these records includes a training plan (and its subparts like curricula) and evidence of training performance (e.g. attendance) and assessment

There are two main audiences for record-keeping: operational staff and various auditors/inspectors. The operational perspective is ideally proactive, while the auditor’s perspective is typically retroactive.

For the training program this breaks down as:

Operational staff are interested in the trainee’s currency in their individual training plans for purposes of work assignments. Supervisors need to be sure people are doing the tasks they are trained on. Management is also ensuring they have enough capacity of trained individuals to ensure upcoming activities can be supported.
Auditors (internal and external) are interested in whether the individual who completed a task (e.g. approved a document) was trained to the appropriate process/procedure before doing the task. In this case the training records provide evidence of the organization’s past fulfillment of its regulatory obligations. Auditors will also look at the general health of the training system.

Training records (like all records) must demonstrate that training is implemented, responsible, consistent:

Implemented means that training events can be duly recorded in the system.
A responsible system’s controlled documents (i.e. procedure for training record-keeping) are written and followed, plus the procedure clearly identifies the responsible party for each task. For example, training is completed within the specified period.
Consistent systems ensure identical activities generate identical outcomes. Therefore, we validate Learning Management Systems (LMS)

Documentation of individual training is a captured record (training is captured as it happens), a maintained record (training can be verified after it happened) and a usable record (decisions can be made).

Captured records means the record has the following:

Record Management Term	ALCOA Principle	Means
Authorized	Attributable	Created by an authorized person, for example a qualified trainer.
Comprehensive	Contemporaneous	A record is created for every training event.
Identifiable	Attributable	The created record can be linked to the particular training event
Complete	Accurate	Includes all information on the training event (who participated, what was covered, who trained and when)

Maintained records means the record has the following:

Record Management Term	ALCOA Principle	Means
Inviolate	Legible	Any alteration or modification is traceable
Auditable	Original	Every use of the record leaves an audit trail
Appropriately retained	Original	Training records must be subject to a retention schedule and then disposed according to procedure

Usable means the training records can be used by authorized parties to make decisions:

Record Management Term	ALCOA Principle	Means
Retrievable	Original	Training records are I a form that can be searched and retrieved within a reasonable period of time and expenditure of resources
Accessible to Authorized Parties	Legible	Available to those who are authorized to access them

Training Unit as Audience for Records

The training unit is a special case as an audience of documentation that has both operational and audit similarities. Some uses include:

Level of effort being applied to training oversight
Test and verify accuracy of statements about the benefits and impact of training

Culture is Complex, Experiment for Success

In the post “Quality Culture is Fundamental to Actually Providing Quality” I discussed some of the elements of organizational culture and how it fits into conceptualizing a quality culture. I think it is important to discuss some of the complexities and how these complexities need to be solved through iterative experiments.

John Traphagan in his 2017 HBR article “We’re Thinking about Organizational Culture All Wrong” discusses how that the study of organizational culture commonly conveys the idea of culture as a unifying force that brings people together to work productively toward the attainment of organizational goals. The approach implies that organizational culture is understood as a collective project able to create unity and cohesion in some simple steps. But reality presents a quite different picture because today culture is not only about cohesiveness and unity. It is also about disagreement, discrepancy and disparities constantly testing the capacity of people to work together and benefit advancing common and ethical organizational goals in spite of individual differences.

Traphagan ends his article with a powerful statement that should be kept front and center in any culture initiative: “The idea that unity can be generated among employees by fixing or creating an organizational culture relies on a naïve assumption that culture unambiguously brings people together. But the reality of culture is that it represents a tremendously complex variable that can both bring people together and pull them apart — or do both at the same time.”

Because of the reality Traphagan discusses, we need to realize that work on culture is really about experiments. I’ll point you to another article in HBR by Stefan Thomke “Building a Culture of Experimentations“. This article emphasizes that the main obstacles obstructing change are lodged in the culture, in deep shared behaviors, beliefs and values that shape a culture over time and perpetuate in place without periodic or effectiveness assessment and in spite of obsolescent outcomes. Thomke writes that a successful culture of experimentation is built on five critical elements: cultivation of people’s curiosity, insisting that data trump educated opinions (avoiding guessing), democratize experimentation across organizational divisions, promoting ethical sensitivity in all functions and embracing a humane and agile leadership model.

Culture is a complex problem and the only true path for addressing is small scale experimentation iteratively applied with the end-goal of transformation.