Back in the 18th century there was a period of new thinking called the Age of Reason; or the Enlightenment. The thinkers of the time were moving towards a largely fact-based view of the world and all things in it – using reason rather than sentiment or religion to explain things. Dominated by a well-known group of French Philosophers, it’s this period that has significantly influenced our current scientific approach to our view of the world. Amongst other things, they described the process of understanding things by breaking them down into individual parts. Like, a bicycle is made up of wheels, a chain, handlebars, pedals, etc. As though all whole things in the universe were merely a sum of their parts. At the same time as the French philosophers were enjoying their breakthroughs in thinking, there was a smaller group of British philosophers, like Edmund Burke and David Hume, who believed that there was more to it than just Parts.
This idea of pure reason clearly breaks down when it comes to living things: like people. It’s far too simplified an approach to say that we’re merely a collection of parts: like arms, head, skin, liver, heart, legs, etc. What Hume & Burke argued to all those Frenchies across the Channel, was that it’s not just the parts that matter, it’s what’s between the parts that also matters. Maybe even matters more. It’s the connections, and the intelligence in those connections that makes the whole much greater than the sum of its parts.
I’m telling that story as a simple metaphor about Workflow. We often talk about workflow in the software business, and how important it is in creating easy-to-use and intelligent software. When describing what a software application does, it’s common to make a list of features and capabilities, like a checklist of Parts, to evaluate the application. Construction project management software, for example, may have capabilities such as estimating, procurement, change management, forecasting, tracking and reporting; and each one of those modules may be very powerful on their own. But what’s equally important, is to consider how all those things work together; how they’re connected, and how intelligent the connections are between them. Those connections, and the intelligent movement of functionality and data between the Parts, is what we call Workflow.
Procurement management workflow is a great example of this. There is a tremendous amount of complexity of events, dependencies and roles involved in the process of purchasing, contracting, fabricating, etc. Not to mention the logistics of getting it all there on time. Large project procurement typically necessitates key interactions between multiple roles. Roles such as: the Engineer, the Buyer, the Expediter, Vendors, Project Controls and Project Accounting. The underlying software that supports the complexities of each of these roles not only needs to deliver the appropriate data and functions at each step – it must also possess the intelligence to know how each of those roles, functionality and data, is connected to the other. The even greater picture to consider, is to look at how the whole procurement piece fits and interacts with the rest of the system. For instance, how does it connect with Project Estimating, Change Order Management, Earned Value Management, project cost controls, etc.? All these interactions and intelligent movement of data makes for a far broader and holistic picture of the Project as a highly connected entity.
Software has come a long way from the days when all you had was a series of forms to input data. Or were relying on inventing your own forms in a bunch of spreadsheets. Modern software has workflow intelligence built-in to meet the specific needs of complex applications. Large ERP systems that have plugin modules for just about everything you can imagine, are built around this forms-based concept and lack the workflow intelligence that truly represents what people actually do in real life. Sure, it’s helpful to be able to enter data fields in a SAP Materials Management system to create a purchase order that’s posted directly to the GL. That’s great. But it sort-of just ends there. Procurement is far more involved than that. How is that PO connected to expediting, and receiving, and vendor documents, and scorecards, and historical material average unit rates, etc.? How is it connected to the original budget and latest project forecast? In forms-based systems, there is no connection. This is why workflow is so key, and is critical for improving how organizations execute on projects. And how they do business in general.