Systems Modelling

When I joined the aviation safety regulator I was introduced to the concept of systems-based auditing (SBA). Before this I had been carrying out aerodrome inspections and I thought becoming an Aerodrome Inspector for the government was going to be more of the same. How wrong I was! Even after four years, my concept of systems-based auditing is still evolving. I coming to discover, and it seems everything I read will attest, that most things in life tend to be more complex than we initially think - SBA is no different.

SBA101

For those not familiar with the concept, let's look at the features and benefits of this approach.

SBA is often compared to its predecessor, which I will call, product-based auditing. This approach involved comparing examples of finished products to the standards laid out. The image often conjured up is of an auditor with checklist in hand and ticking off the compliant aspects of the product.

The problem with is, of course, that this can only ever make an assessment of the selection of product observed. The auditor can, perhaps, infer that future products will also meet the standard involved but they haven't really assessed that to a point where a true judgement can be made.

And that is what SBA sets out to do. By looking at the system that produces the product, the auditor is making an assessment of the operator's ability to consistently achieve the required output standard.

This approach comes to the fore when systems are brittle but the environment hasn't yet put pressure on the system's weaknesses. The products have all met the requirements so far but you can see that problems will arise if just one small thing falls out of place - say a key person leaves the company. It also works really well for systems that are rarely put into action - such as an aerodrome emergency response plan at a small aerodrome.

Semantics

When I've discussed systems with colleagues before, we have sometimes descended into a semantic quagmire. Depending on one's field, education, experience, what constitutes a system differs in the mind. Sometimes a definition can be so restrictive that discussion is pointless and others are so loose that discussion is impossible.

Let's aim for the middle, at something useful.

A system is some form of endeavour that seeks to convert some input(s) into some predetermined output(s) in a consistent and predictable manner.

Now that can be a similar definition for a process, task, element, activity, etc. but I am going to stick with system to cover any single or collection of human or mechanical changes of state which result in an input changing into an output.

You may note that I haven't defined the scale of the "endeavour". It could be making toast or it could be shipping 10,000 new Furbies from their factory in Taiwan to Walmart stores on the west coast of America. The scale of the system is simply that which is to be and can be audited.

Yes, you could define an airline system with a whole bunch of inputs, a single box of action and then one output, the safe transport of people and cargo from A to B. But it wouldn't really be possible to audit that in one go and make a judgement as to the ability of the system to consistently produce the desired output.

We need, therefore, to breakdown the overall system into smaller chunks to make auditing manageable. And we will need to consider the interrelationships between these chunks. So, how can we do this?

In Need of a Model

There are plenty of system models out there but I've grown fond of the SADT or IDEF0 approach. I'll say fond because we've only really flirted so far; maybe a quick dance but definitely not a slow dance or any real alone time.

I stumbled on to this model initially through some reading on the Structured Analysis & Design Technique (SADT). I can't say I remember much about the actual technique. It was the graphical representation of a system that caught my eye. So in the beginning, it was all about looks.

I did some more reading into the graphical approach and I've made a few tweaks to suit the more socio-technical system of which, an aviation organisation is likely to consist.

Now, let me introduce you...

A Basic System Model

I'll go through the components of the model first and then give you an example to help explain.

• Inputs - These are the things which are converted into the outputs. They are fundamentally changed by the process and become a constituent part of the output.

• Resources - These are things used within the system to transform the inputs into the outputs. They are not changed by the process but while they are being used in one system they are not available for use by another system or instance of the same system.

• Controls - These things guide the system in its process. They too are not changed by the process but they can be used by multiple systems or instances.

• Outputs - These are the primary products of the system. They are the system's raison d'être and, in a larger sense, should meet the objective of the designer of the system.

• By-Products - These are also outputs of the system but do not necessarily consist of the inputs or are the primary objective of the system. This feature is something I've only just thought of and doesn't appear in the SADT approach. This is a significant tweak I've included to help with the amalgamation of systems into a larger system - more on this later.

Let's get to a simple example: Baking a cake.

A Basic Model of a Baking a Cake System

Here's the breakdown:

• Inputs - The ingredients - flour, sugar, eggs, etc. The ingredients are fundamentally changed by the system - they become the cake.

• Resources - The bowls, spoons, cups, cake tin, oven, the chef, etc. These things are used within the system but do not become part of the cake. However, while they are part of the system, they can't be used to bake another cake or cook something else.

• Controls - The recipe, procedures, etc. Typically, controls are data or information. They can be used over and over again by many people at once.

• Outputs - The cake. Hopefully, it meets our objective and we weren't trying to bake a potato.

• By-Products - This one is a bit harder in this simple example but let's say that this system is part of a professional kitchen. The chef will probably be trying to improve their skills and would be taking notes on the performance of the system. These notes are an output of the system but are not made up of the inputs. They are however, an important part of the larger kitchen system.

Putting It All Together

Two big selling points of the SADT approach is the ability to link the systems together and fold them up or drill down into super or subsystems, as desired.

In my academic reading at the moment, I'm coming across quite a bit of push back against reductionism and modelling. It is thought that the complexity of the world is being masked by oversimplification and that people are failing to consider the bigger picture.

The SADT approach is still reductionist in a sense but when you start tying systems together, you can start to identify interrelationships and dependencies between them. Modelling will always be a simplification, it's about striking a balance.

I haven't yet dived into mapping out a large super-system, like an aerodrome, but it is on my to-do list. What I have done so far has highlighted the model's ability to capture some of the complexity in managing a large socio-technical system. I found that it didn't take long to see how outputs from one system become inputs, controls or resources for another.

What's in the Box?

Let's call time there. This post is already getting too long and I'm still, very much, in the middle of processing these ideas into something useful. As the sub heading notes, I haven't really looked inside the box. We've got arrows going in and coming out but what actually happens in the box is still a mystery.

I also haven't really identified a way of assessing the various components of the model and therefore, you can't do much with it, yet.

I'm in jeopardy of becoming a tease on this blog. I'm always signing off with a promise of more to come. Please remember that this blog is more of a journey than a destination and I thank you for coming along for the ride.

More to come... ;)

Image credit: Jeremy Waterhouse (via Pexels)