The State of Process Design

Photo by Robert Stump on Unsplash

In the first short article of this series I highlighted the implications and cost of ignoring business data when designing processes. Now let’s see how to find, organise and include business process data, in a way that both simplifies design and improves general understanding.

Data design and management is a vast topic, full of technical jargon and abstract concepts but, for the purposes of complete and accurate process design there are ways to simplify things significantly.

Our preferred approach is to list and name all the Entities involved in a process, using the local, well-understood terminology of your business.  Entities are simply the logical bundles of real-world data involved in the process.

They include tangible and abstract business things such as: a form, document, account, payment, loan, applicant, agent, customer, invoice, approval, approval-rating, credit check — anything of relevance to the process.

As we design more processes the same entity may reappear in other processes, which can later help in process rationalisation.  A collection of such business entities in a process is sometimes called a case, or the case data.

Entities are always nouns and, in our experience, easily identified by anyone close to the particular process.  They are the easiest way to think about data.

Thanks to artificial intelligence, it is now viable to quickly extract a list relevant process entities directly from lengthy policies, procedures, forms, contracts, terms and conditions.

An entity, during the life of a process instance,  progresses through its own lifecycle stages or States.  The entity doesn’t fundamentally change except how we consider and use it changes.

This is a bit like water, it’s always the same thing H20, but can exist in different states such as: solid ice, liquid or vapour.  Ice is the state name of water that’s below zero degrees centigrade (0℃).

Entity states can also be thought of as a short-hand name that best describes an entity at a point in time. For example, “Account PAID” describes an Account entity where “the balance is zero or above.”

“Applicant is ELIGIBLE” may describe an applicant entity where their “Age is over 18.”

States are adjectives (ELIGIBLE) that describe the condition of an entity, or a past participle (PAID) that describes how the entity attained this condition.  At any level of a process an entity can only exist in one state.

Some entities are created during the life of a process instance and may start their lifecycle in a state called NOTHING.

Not unsurprisingly, you can see that natural language plays a key role in describing components of a process.  Language is after all how we understand and conduct ourselves in the world.

So now we have developed an agreed entities each with its own list of states.  Note that entities can share the same state name, although the same term, such as say APPROVED, may carry a different meaning related to each entity.

Whenever an entity changes from its current to its next state we call that an Event, which is an important moment in a process lifecycle, often defined by sending or receiving a message.

For example, the Account PAID event simply broadcasts the fact that the Account entity is no longer in any other state like DUE, OVERDUE or INACTIVE.  Within a given process event names are unique and defined by the entity name and the state name together, such as Customer ACTIVE.

Now some events must logically follow one or more other events, usually due to the constraints of physics or regulatory compliance. For example, the Bonus PAID event must be preceded by all of: Bonus CALCULATED, Policyholder ELIGIBLE and Funds ALLOCATED events.

To capture the mandatory constraints we have developed a guided user interface component called the Lifecycle Designer, which makes it easy to create and delete these event constraints.

Reasoning about a process like this, one event change at a time, completely simplifies the mental model for the designer.  No need to try and remember the whole flow and data model all at once.

And that’s it … At this point, our job as a process designer is basically finished.

But wait, I hear you say, there’s been no mention of the usual Tasks or work necessary to conduct the process.  Well that’s the magic.

Given that the entities, states and constraints are all described in meaningful business language, software can now generate and name the minimum set of necessary tasks, each pre-populated with key details and sequenced mathematically to ensure compliance with the constrained data model.

Regardless of the process complexity, data integrity and business compliance is completely assured.  This is surely as LEAN as a process can get.

And what about process diagrams and documentation? Also fully generated!  Sit back and watch as software updates the BPMN drawings and all relevant documentation with your latest update. Have a new requirement?  Add, change or delete an entity, state or constraint and the whole model is recomputed, verified and redisplayed along with the adjusted documentation.

To summarise, Flowstate Software flips the traditional Task-Work approach to process design into a simpler Data-Event method that enables anyone to describe and present accurate and complete models.

Anyone can become a brilliant process designer.

In the next post I will explain the Generative Process Design (GPD) algorithm that makes this all possible and outline the many emerging opportunities this new approach brings to process design and automation.