Adopt a reference process
A reference process is a process document with the organizational parts left blank. The activity walk is already done, the roles are named and the deviations are drawn. What is missing is everything that belongs to you: the owner, the dates, the caps, the thresholds and who actually holds each role. Filling those in is what turns it into your process at version one.
Read it before you copy it
Open any process, for example negotiate the agreement, and four things are worth reading in this order. The activity table says what happens and who holds each step. The graph has the backward edges in it, which is where the real work lives: an approval that comes back with changes, a check that fails, a claim that cannot be evidenced. The document with the blanks marked is the thing you copy. The failure edges say what happens when a run does not go the way the diagram hoped, including what happens when somebody abandons it.
If the shape is wrong for you, stop there. A reference process is a first draft to argue with, and arguing with it is a legitimate outcome.
Fill in the header
The header is four lines and they are all yours. owner is the
role accountable for a run, not a person's name. effective is
the date it starts being how you work. trigger says what
starts a run in your organization, which is usually a document or an event
you already have. concurrency says how many runs may be live
at once and what may not overlap.
A reference process has no owner and no effective date on purpose. Those two blanks are the mark that it is not yet anyone's process.
Decide the automation level for every phase
Each phase carries automation: and the reference leaves it as
a blank, except where it says never. That word is not a
default anybody chose lightly: it marks a gate a person has to sign, and
changing it to anything else changes what the process is for. The other
phases take one of assisted, supervised or
autonomous, and the honest way to pick is to start lower than
feels ambitious and move up when the records show it earned it.
Bind the roster and the systems
The bindings block is where the process meets your world. The
roster says which agent or person holds each role named in the activity
table. The systems block lists what a run touches and at what access. The
data block names the documents a run reads.
Roles that an agent can hold cite an abstract agent, which is a description of a job rather than a product. Any vendor's agent can hold one if it leaves the records that abstract agent names. Roles that only a person can hold are written as people in the source, and they stay people.
What you inherit, and what you owe
You inherit the walk, the handoffs, the failure edges and the records a run
must leave. You owe the numbers. Every <cap>,
<days> and <target> in the document is
a decision the reference deliberately refuses to make for you, because a
number invented here would be a claim about your organization that nobody
could stand behind.
Keep the from: line. It records which reference process and
which version yours came from, which is how you can tell later what has
changed upstream and whether you want it.