The Process Behind the Process
Part 1: The creation and evolution of your Multivariable Process Map (Post 8)
The previous two blog entries were very much describing the “What” associated with Multivariable Process Mapping (MVPM). We discussed content in terms of the headings and the type of content captured, and the best profile of a person to manage the content to help the team flourish with the model’s output and outcomes. This discussion will be about the “How”: How does all this work play out? How does your team capture the information, and ensure it is accurate? How does the Process Map tool drive subsequent process design?
This is the basic idea:
Create MVPM by identifying major process steps. Process steps are the natural break points in creating something. Most (but not all) of these major process steps often include:
set-up,
preparation,
execution,
waiting for something to happen, and
measuring the result.
A process step with an input, state change, and an output is described as a “transformation.” Sometimes there is no state change as part of the process step, so that step would not be a transformation, but rather, a “move.” In some processes, moves are a big part of the overall production time (sometimes called Cycle Time) and have very specific requirements.
The diagram below represents the basic concept of the process mapping and the elements that will be captured, and later created to control your process. In this diagram, each operation or step of the build process is represented in blocks on the left, as an operation number and transformation or move designation. Each step or operation will have inputs, process steps, and outputs. Quality testing or measurement may occur several times during the operation for any Critical to Function (CTF) parameters: testing and/or measuring inputs going into the operation, potentially several times during the process steps as needed, and testing and/or measuring the output of the operation. The next blog entry will detail the CTF and testing influences more fully.
How are Multivariable Process Maps Useful
They capture basic information about product: how it’s built in the originator’s imagination to repeat how they got to the result
The method uses the originators’ brains’ “process flow” as a guide, to describe how a design was built and what exactly went into the effort
In these early stages, these process maps become the Fundamental Backbone for storing information until it can be formalized and controlled (more on this later)
Process mapping of any type is typically associated with manufacturing, and not early commercial efforts, until now
They become the engine for more advanced modeling methods and product data management
MVPMs help avoid rehashing less productive, previously eliminated outcomes by memorializing inputs, transformation, and outputs that work, or don’t work…
Relating to what I said before, if you don’t have an element shown in this diagram, don’t let it stop you. Note it and move forward. Later Readiness Activities will help prioritize this work (more on that later).
Creating and updating Process Maps using Workshops
Here are some suggestions associated with driving the methods of harvesting process map information. Although an individual team member will be designated Process Map Lead and will own initial data gathering (and drive the ongoing evolution), holding group meetings or “workshops” are key, to ensure all perspectives are considered and all team members are committed to the process.
The executive leadership must prioritize and support these workshops and socialize and drive the employees’ perception that is critical to the success of the company.
The Process Map Lead should manage the scheduling and notifications, so people can prepare and be mindfully present.
Send out emails explaining that there will be Process Mapping Workshop and give stakeholders a rough schedule of when, and of whom will be needed.
Schedule a kick-off meeting with all stakeholders, explain the methods in term of high-level overview, basic methods, and desired outcomes. And make sure folks understand that this effort has executive visibility and should be seen as a priority.
Each workshop meeting should be no more than 2 hours. People lose interest and will perceive they have to get back to work. Don’t fight it in the beginning.
Schedule individual Process Map Capture Meetings, starting from the beginning of the process, with the responsible stakeholders (product development engineers, process engineers, test engineers, production supervisor, support technicians, team leaders, and senior production operators)
For example, if there are different team members who are responsible for different process steps, don’t burden others with having to sit through a session not related to their work.
If indirect stakeholders are downstream “internal customers” interested in the “how”, invite them. If an upstream internal supplier disproportionately determines process capability in the process you’re capturing, invite them.
These interdependencies and reinforcement of internal customer-supplier relationships will be critical now and later.
Hold the meeting. I’ll discuss this in the next section.
Send simple meeting minutes to all stakeholders, explaining what was captured, and what will be achieved in the next meeting. Also, this is the time to formalize action items and commitment for missing data, that someone has to chase down. Be direct and DO NOT apologize: What is owed, by when, by whom.
Facilitating the Process Map Capture Meetings
Congratulations, you’ve tipped the scales of influence and employees are excited about – or at least engaged in – moving forward. The introductory meeting has been held, and executive management has aligned and confronted dissenters who claim they have better things to be doing than ensuring the success of the company by sharing and not hoarding their knowledge.
The first challenges you may encounter, before your first workshop, are: data hoarding, tribalism, paranoia, and hubris (surely, you’re not bright enough to understand my important work…). The process map capture leader and facilitator must listen and ask questions, perhaps from multiple directions and perspectives. They must use their influence and other’s influence to drive for answers and get the details that allow a process to be executed, repeatably. Often people have a lot of fear when they are required to give specific and quantitative answers for parameters and states they usually just wing it and hand wave. This fear is particularly acute if they are failing to repeat earlier results, and they truly believe they are the only one who can return to the previous state of grace.
Each Process Capture meeting should be handled as two meetings, Part 1 and Part 2
Part 1 – Designated Block of Processes (you’ll figure out how many can be handled)
For part 1, use a whiteboard and write down the process steps that will be covered in the meeting, as a horizontal list, leaving space between each. The columns can be created beforehand.
You can start numbering or save it for later. I recommend saving it for Part 2.
Agree to the name of each step and get consensus that everyone understands the boundary for each step. Simply put, make sure that there aren’t hidden processes, before, after, or within a step that should be stated and broken out. Sometimes, these hidden processes pop out during the capture, and everyone agrees that it’s its own thing.
Once everyone agrees to the process steps, and that it’s sufficient in scope, start filling in information. DO NOT FREAK OUT IF THERE ARE EMPTY BLANKS!
Type: This sometimes takes time to determine these supersets.
Times: Early on these will be estimates, maybe from lab notebooks. Sometimes they are guesses. Future action will be to quantify and firm these up.
Yield: This could be a fiery discussion because poor yields hurt people’s feeling. From my perspective, they are what they are. They are a function of the design capability, process capability, test capability, and technical understanding of the process. The concept is referred to as Design Intent. Yields are something to be improved over time, with increased knowledge and refinement.
Material Cost: Like times, early on these will be estimates, maybe from lab notebooks. Sometimes they are guesses. Future action will be to quantify and firm these up.
Equipment: Should be straightforward, as these are expensive and often big.
"Touch" Work, Settings, Specs: This will be the most detailed and data intensive sections, because this is often the “How” and “How Much”.
Touch Work: Have the stakeholders explain the basic activities associated with this process step.
Settings: If equipment or systems are set to “set points” (e.g., temperature, pressure, duration).
Specs (Specifications): If you know there are process for performance limits (e.g.: resistance (Ohms) after soldering, power or loss (mW or dB) after coupling a fiber optic device, surface finish or roughness (um) after etching), specifications are the best guesses you have of your processes limits to achieve a desired outcome at the next step.
When 2 hours is reached, summarize the last process step, thank everyone, inform them of the next meeting, immediately take a picture of the whiteboard, and collect all notes and content.
I suggest at this point setting up a shared file directory with three subdirectories. Why do I care about storage and naming conventions. Because it’s in line with the basic philosophy that it’s more expensive to search or repeat than to leave a sufficient trail of breadcrumb to retrieve information.
Process Maps
Populate your process map in the Excel file template found at the follow [link] with the contents for Part 1.
Each version should be named and dated [Best Product Process Map (09-21-2022)]
Note that these files will grow with each Part 1-Part 2 session
Supporting Contents
These are documents or scans of notebooks to support the process map
Name something like this [Mixture B formulation from Bob’s notebook]
Whiteboard Pics
Use your smart phone and a number of apps (OneDrive, DropBox) which have whiteboard to PDF converters built in. Take pictures of the workshop’s content and save them a PDFs.
These are the archives of the process map sessions Part 1
Name the file something like this [Whiteboard, Ops 1 thru 6, Part 1]
Also, in my experience, people will jump to the board to clarify points and processes. THIS IS GOLD. Take a picture and save them.
Name the file something like this [Part 1, Mixture B sketch by Bob]
The next blog entry will cover Part 2 meetings and how to validate Part 1’s content, close actions, and launch into the next block of processes. At this point, you have a philosophical and user choice. I prefer using the Whiteboard approach, as it’s more organic and engaging with the stakeholders. Some folks prefer building the maps in Excel during workshops. Think about it.
Example of a MVPM Template
Full Arc Posts Table of Contents
Post 4 - Defining Product Requirements
Post 5 - Exploring the Product Life Cycle
Post 6 - Understanding Risks in Real Time
Post 7 - A Deep Dive on Process Modeling
Post 10 - Looking into the Future
Post 11 - Keeping an Eye on The Next Generation
Post 12 - Product Platforms