Finite-state machines: Better than flowcharts

Image Credit: R2 Docuo

Flowcharts have proved themselves to be flexible and adaptable for mapping, describing and explaining a wide range of process flows.

The development of the flowchart as a logic tool can be traced back to the 1920s when it was introduced to members of the American Society of Mechanical Engineers (ASME) in 1921 by Frank and Lillian Gilbreth.

The methodology quickly found favour with the engineering community and by the 1930s it was being used to help business people simplify work. By the 1940s US companies, such as Procter and Gamble were applying the principles to define processes. Others were using the technique to chart information processing by modelling multiple documents and their relationships.

Flowcharts for business and programming

In 1947, ASME adopted a logic flowchart symbol set and the mathematicians Herman Goldstine and John von Neumann developed programming flowcharts for the planning and coding problems for an electronic computing instrument. Flowcharts remained an essential tool of computer programmers for describing algorithms until the 1970s when shifts in technology led to a decline in popularity.

However, flowcharts are far from a legacy. They are still widely used for developing a high-level understanding of process flows. Of course, this is not just in software; many of us are likely to have sketched out a rough flowchart to illustrate to ourselves or others how a business process should run.

From this perspective, flowcharts usually model how people make decisions in a given process flow. The drawback of this is that flowchart diagrams put the user’s decision at the centre, not the business process itself. As a result, when user actions become complex or the process requires the cooperation of a number of people, the overall business process becomes harder to detect in the flowchart. As the sketch gets more complicated and more decision focused it becomes less representative of the process.

At the end of the day flowcharts representing business workflows become useful for training new people in making decisions but are not that helpful for analysing or modelling the business process itself in a consistent and reliable way.

The power of the State… the finite-state

Finite State Machine (FSM) diagrams were first used by neurophysiologists (Warren McCulloch and Walter Pitts), biologists, mathematicians, engineers and some of the first computer scientists (G.H. Mealy and E.F. Moore). They shared a common interest in trying to model the human thought process, whether in the brain or replicating it with a computer. This was called the Automata theory; it was first presented in 1943 and further defined in the fifties.

Simply expressed, instead of focusing on decision making, there are two main questions to represent in an FSM diagram. Firstly, in how many different states can a given machine (or process) be throughout its entire lifecycle?  And secondly, in which ways can the machine switch from a given state to another?

Compared to flowcharts that use as many as nine different ISO/ANSI logic symbols, FSM diagrams require only two - circles, which represent a machine state; and arrows, which denote a machine transition.

A circle represents a state which the machine can be in at a given moment. An arrow that goes from state A to state B represents an action that can change the machine to state B, providing its current state is A. States are usually named as status descriptors (‘hungry’, ‘sated’) and transitions are usually named as action descriptors (‘eat’) or events (‘3 hours passed’):

Figure 1. Sample Finite State Machine Diagram: Daily feeding

Figure 1. Sample Finite State Machine Diagram: Daily feeding

The initial state in which the machine starts has no input transition. The final states (there can be many) do not have any outgoing transitions and are the end of the process or machine’s lifecycle. Both initial and final states are double circled in FSM diagrams, with regular states shown as single circles.

Using a methodology based on finite-state machines, organisations have a better way to model, analyse and represent business processes that require significant amounts of decision making or collaboration across a team of people.

This is because FSM-defined workflows put the processes front and centre. It defines how a given objective should be achieved within the context of the organisation, and in how many different states the information can be during that process. As a result, the process that is described using FSM is independent of the roles of individuals.

Say we use an FSM diagram to define the workflow of a sales proposal. This can be in only one of a defined number of states or conditions at a time. The states could be ‘being written’, ‘management reviewing’, ‘sent to client’, ‘accepted’ or ‘rejected’. The transitions define the actions which change the state of the document. The actions which transition the document between these states would be, ‘send to manager’, ‘changes needed’, ‘send to requestor’, ‘requestor accepts’ and ‘requestor rejects’:

Figure 2. Sales Proposal workflow using FSM Diagram

Figure 2. Sales Proposal workflow using FSM Diagram

Once a process is described using an FSM diagram it is straightforward for people familiar with the workflow to take responsibility for executing transitions from state to state.

FSM-defined workflows also simplify the definition of business processes when compared to flowcharts as business processes tend to have a smaller number of information states than decision-making points. Here is a side by side comparison of another sales proposal workflow with some additional decision points represented using the two techniques:

Figure 3. Side to side comparation

Figure 3. Side to side comparation

The essentials of designing a finite-state process flow system

Applying this methodology to managing the documents used within an organisation, either generated internally or originated externally, is relatively straightforward.

Firstly, there are a lot of document types and processes that can be defined across the whole organisation. However, we need to consider that not every document has the potential to be in every state, or to be subjected to every action. As an example, you are unlikely to want documents to do with sales to be routinely handled by human resources as part of a standard workflow.

Consequently, process flows for document management and workflow should be segmented for each functional area of the business. This prevents unwanted complexity and document management and workflows spilling over between departments. Splitting the entire spectrum and segmenting them by department - sales, HR, finance, and so on – or by type, such as contracts, proposals and incidents - is a good way forward.

When designing a process flow for managing enterprise documents, it is essential to identify all of the possible states that a document can be in; and also, to identify the corresponding actions which allow the documents to transition between states.

Within each department workflows can be designed for different document types. In enterprise sales you are likely to have the need to manage proposals generated in response to RFPs. A dedicated workflow for managing enterprise proposals can take into account the specific needs for managing documents of this type.

They are likely to be the life-blood of sales and ensuring they are produced using a process that is consistent and which repeatedly produces the high-quality proposals that win new business is within reach using an FSM-based process flow.

Software and office process automation

When designing workflows and automating document management with software, an appropriate FSM-based application that has been well thought out should provide real ease of use. For example, it is desirable for document management workflows to be simple for users to define with ‘drag and drop’. There should be no need for programming skills or for vendor customisation, a value-add that frequently increases the deployment timeframe and cost.

Remember, initial process flow design is unlikely to be perfect. However, with a simple, agile system, design and configuration should be straightforward, enabling process flows to be debugged, refined and optimised for every conceivable purpose in a matter of minutes.

On the other hand, once a process has been defined using an FSM diagram, the actions associated with every transition are often straight-forward and repetitive. Consequently, they are perfect for automating using software.

As an example, if you have a sales proposal in the “requested” state  and you have a proposal document template, once you enter the basic input: client name, address, project description and costs, the software should be able to automatically generate the document using the template and send it to the client (using an email-template) whenever you execute the “send to client” transition and the state is switched to “sent to client”.

Through automating every possible repeated action, office process automation software technology saves a great deal of time.

Other automation features should include auto-execution of any transition based on given conditions. For example, when a process has spent X days in a given state, or when a given condition is met. In this way users do not have to concern themselves with these tasks and only need to interact with the software when human intervention is needed.

Record keeping policy and FSM final states

When you create an FSM diagram for a business flow you are mapping the final states of every process. This is exactly what is needed in order to establish an appropriate record keeping policy for the organisation (a common requirement in records management).

Software usually allows auto deleting documents once they have been in a final state for a given number of days, months or years. This is useful for compliance scenarios in which some documents must be kept, archived and later deleted following strict rules in accordance with legal requirements.

Versions, revisions and other tools

Document management workflows that incorporate multiple iterations and reviewing cycles before being sent to the recipient can be readily created. Workflows that are about the management of processes rather than documents are also easy to set up. Consider a customer service department which needs to manage help desk tickets from first customer contact right through to ticket resolution. The ticket lifecycle can be easily represented by FSM diagram and managed and automated using software.

Layering in additional tools such as a metadata search, a PDF engine, digital signing and automated email enhances the power of a system, helping prevent important steps in enterprise document and workflow management falling through the cracks.

With the system in the cloud, additional capability such as enterprise document storage, secure file sharing and changing a document’s state with a single click on mobile devices, rounds out the capability to manage documents through their entire lifecycle and to define workflows in a way that meets the demands of today’s enterprises.

Jorge Ramirez, founder and CEO, R2 Docuo.
Image Credit: R2 Docuo