Principles behind a good system

System Thinking requires operating in a paradigm where we see our people, organizations, processes and technology as part of the world, a set of dynamic entities that display continually emerging patterns arising from the interactions among many interdependent connecting components.

Principle	Description
Balance	The system creates value for the multiple stakeholders. While the ideal is to develop a design that maximizes the value for all the key stakeholders, the designer often has to compromise and balance the needs of the various stakeholders.
Congruence	The degree to which the system components are aligned and consistent with each other and the other organizational systems, culture, plans, processes, information, resource decisions, and actions.
Convenience	The system is designed to be as convenient as possible for the participants to implement (a.k.a. user friendly). System includes specific processes, procedures, and controls only when necessary.
Coordination	System components are interconnected and harmonized with the other (internal and external) components, systems, plans, processes, information, and resource decisions toward common action or effort. This is beyond congruence and is achieved when the individual components of a system operate as a fully interconnected unit.
Elegance	Complexity vs. benefit — the system includes only enough complexity as is necessary to meet the stakeholder’s needs. In other words, keep the design as simple as possible and no more while delivering the desired benefits. It often requires looking at the system in new ways.
Human	Participants in the system are able to find joy, purpose and meaning in their work.
Learning	Knowledge management, with opportunities for reflection and learning (learning loops), is designed into the system. Reflection and learning are built into the system at key points to encourage single- and double-loop learning from experience to improve future implementation and to systematically evaluate the design of the system itself.
Sustainability	The system effectively meets the near- and long-term needs of the current stakeholders without compromising the ability of future generations of stakeholders to meet their own needs.

Pillars of Good System Design

Quality Book Shelf – It’s Not Complicated

It’s Not Complicated: The Art and Science of Complexity in Business by Rick Nason

Nason states at the beginning of the book: “Engineers, scientists, and ecologists have been thinking in terms of complexity for fifty years, and it is time that the business community considered some of the valuable and interesting lessons the field has to offer.”

This book is a great introduction to the concept of complexity, and I think it should be required reading.

“Complexity generally occurs whenever and wherever there are human interactions.”

“It is thinking, creativity, and risk taking that lead to sustainable competitive advantage.”

Over-reliance on data can be dangerous, and Nason goes into detail on how US Secretary of Defense, Robert McNamara disastrously managed the Vietnam War with spreadsheets: “You cannot collect data on things that are unknown … even if the factors are known, the precision needed for the data to be useful for a complex problem would not be achievable.”

None of us are as smart as all of us, and nature trumps us all. Nason refers to Orgel’s Second Rule that, “evolution is smarter than you are and that events in the business [human] world turn out to be more creative and clever than the best minds can imagine.” In addition, serendipity plays a critical role: “Complicated systems allow us the illusion that luck or serendipity played at best a limited role in our success and thus, that whatever success we have is almost exclusively the result of our own skills and effort.”

I could basically cut-and-paste quotes all day.

As someone who feels we overuse complicated and complex as synonyms, I recommend this book to all as a way to get familiar with the core concepts. I sort of wish he would write the companion volume, “No, that’s not complex.”

Level of Training

I want to talk about levels of training. I am not going to go into an Instructional Design model/framework, but more stay focused on the purpose of training in the quality system. I am also going to try to discuss training in terms that will make sense to folks who mostly dwell in a verification/validation mindset. So, all my professional learning developer friends please be gentle.

Categories of Training

There are three levels of training (lots of subdivides) that can be viewed as a risk based approach

Awareness Training

This can be barely considered training. Awareness training conveys the subject matter to an audience with the goal of making the audience aware of the content of the communication. It is either informational or actionable. At best, just a ”tell” activity.

Read-and-understand fits in this bucket.

Facilitated Training

Facilitated training strives to improve the workplace proficiency and is hopefully based on some real adult learning principles. There are a lot of delivery modalities that are usually broken into two big buckets of eLearning and classroom delivery. It always has an assessment component to ensure the training had the desired impact. Usually a “tell, show” model with limited “do”.

Employee Qualification

On the job, hands on training that confirms the individual can do the work by independently performing the tasks while being monitored and assessed by the trainer. Usually follows a “tell, show, do, follow-up” model.

The Level of Training is Risk Based

The level of training should be driven by the criticality of the process/procedure/task. I recommend several questions driving this:

The complexity knowledge or skills needed to execute the changed process?
How complicated/complex is the process/procedure/task?
Criticality of Process and risk of performance error? What is the difficulty in detecting errors?
What is the identified audience (e.g., location, size, department, single site vs. multiple sites)?
Is the goal to change workers conditioned behavior?

The Personnel Qualification Model

Qualification means fitness for some purpose, shown by meeting necessary conditions or qualifying criteria. This applies as much to our people as it does to our equipment, and we can break this own with the three phases of IQ/OQ/PQ:

Personnel IQ is provides objective evidence that the trainee has the requisite education and experience for the process/procedure/task.
Personnel OQ is proves that the trainee can function in the training situation (event) in an appropriate fashion and performance is within the control limits set by the process/procedure/task. It proves that the trainee can perform the task correctly and independently.
Personnel PQ demonstrates the acceptable performance during representative operational conditions. The trainee’s performance consistently produces results that meet the standards set by the process/procedure/task.

Once the process of employee qualification I successfully completed, the employee is qualified and stays so unless and until they become disqualified or the process/procedure/task changes significantly enough to require requalification.

Disqualification and requalification

There should be a process for disqualification, whether from extended absences, job changes or a detrimental trend in performance such as serious or repeated deviations.

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.

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.