Systems, Information, Processes and Technology

There’s a tendency to conflate the meanings of “system” and “technology”, typically with technology being referred to as a system. It’s becoming increasingly common and it’s a really bad idea. Perhaps we can first settle on some terminology – a system is the encapsulation of information, decisions about what it means and how it’s to be used (process), and the means to carry it out (technology). Technology forms part of a system, but often a very modest part.

Take, for example, an aviation system used by a bird native to my area in northern Australia – the whistling kite. In times of food scarcity, the kite will look for cooking fires or bonfires from which it can grab a partially burning branch. It’ll carry the branch to an area of grassland and drop it, starting a fire that flushes out lizards, snakes, marsupials and other prey. It’s common to see dozens of kites circling above a bushfire, as they’re very well aware of the benefits.

Assuming you’re willing to accept that such deliberate and consistently applied behaviour does indeed constitute a system, let’s break it down a bit and examine the constituent parts. First, information:

  • The available prey is inadequate for my needs
  • Fire can make prey more available
  • Fire is available
  • That fire is not making prey more available

Next, process:

  • I need to obtain part of that fire
  • I need to relocate that fire to where my prey is likely to be hiding
  • I need to consider the wind and the geographic features to maximise the yield of the potential fire

This is quite complex, consisting first of risk analysis regarding the keepers of the fire. Once that’s been dealt with, there’s another whole subsystem with its own risk analysis (will I be burnt obtaining and then flying with a burning stick?) and process (approach the fire from upwind, pick a stick near the edge, etc.).

Finally, technology. Well, there’s not a lot. You could claim that fire is technology, but it’s enabling technology at best, much as electricity enables computers that don’t rely on pedals or water wheels. A good example of technology would be if the kite was able to source and operate a lighter, but 2020 doesn’t seem like the year to even joke about that.

The point is that many complex systems have little if any reliance on technology. In fact, often the less reliance on technology, the more resourceful the resulting system is. Systems are inherently elegant, beautiful creations that require information and process and may optionally also utilise technology. The role of technology is to improve the efficiency of a system, not to dictate the requirements of it.

That doesn’t mean that technology can’t play a role in shaping the system – it absolutely can. Sometimes the features of a technology open up possibilities for improving the system and a canny organisation will recognise that. What they need to remain aware of though is that they’re re-imagining the system. That system is usually one of many systems in the organisation, all of which are governed by a roadmap that hopefully extends well out into the future. Adopting the technology because it appears to address immediate concerns elegantly in the context of a single system can only succeed by dumb luck. The airline industry is littered with thousands of examples of good technology being badly applied, resulting in a nett negative outcome for the organisation. This is the fundamental definition of a siloed organisation, if I can be forgiven for using such 90s terminology. Localised benefits for one department to the (albeit unintentional) detriment of others.

So who benefits out of convincing people that technology equals a system and how do they do it? Vendors of course, but it’s not their fault. They don’t even understand the department that they’re trying to sell into, let alone the impact on the whole organisation, and why should they? They’re promoting their technology based on the perceived benefits to particular departments in other organisations, and that’s a perfectly defensible rationale. They believe in what they’re doing, and they’re entitled to. Yes, they’ll try to convince you that you should change the system to match the way the technology works, but they’re not responsible for your systems, you are. They’re responsible for operating within the constraints of their own systems, the requirements of which are very different to those of an airline. There would be a very modest overlap in that Venn diagram.

For over a decade, Closed Loop has been banging the drum that airlines need to take far more responsibility for maintaining the balance of systems across the airline. The availability of electronic information and the ability to digitise processes across the airline and intra-organisationally needs to be the focus of activity. Airlines run on such ridiculously thin margins that to spend money on programs that don’t contribute to long-term organisational objectives is more indefensible by the day. Given the inevitability of transparent information and processes, failure to act is nothing short of a corporate dereliction of responsibility.

So what can airlines do to address this?

  • Map the information – every data point has value, but consideration of it in a narrow context means that most of the value is unrealised,
  • Map the processes – every airline has different groups of people doing the same thing in different places and they’re often staggered when this comes to light,
  • Strengthen the systems – look further into the future and design systems to evolve as technology catches up and regulatory initiatives fall due.

None of this is particularly difficult or expensive and unlocks massive long-term benefit for the airline. Aside from the obvious internal benefits, it provides the airlines with something that they’ve never before experienced – they start driving the technology instead of the other way around. Currently, requirements are departmental in nature and systems are regarded as being “adjustable to suit”. The airline needs to be able to express not just departmental requirements, but organisational imperatives. Further, it needs to be saying to the vendor “in two years we expect to be able to feed x information into your system and get y outcome – tell me how you’re working toward that”. Similarly, for longer-term aspirational objectives, though tempered by the knowledge that the organisational topology may change over time. A more demanding client makes for better technology and the vendors will rise to the occasion. The more information they have, the better vision they get for commercial advantage. Far from setting up a confrontation, the vendors will utilise the knowledge in their own roadmaps. Technology will be re-established as the means of improving the efficiency of a system, not dictating what it should look like.

The key to this is to collaboratively develop a unified and far-reaching vision across the industry. Airlines are going to work more closely together and initiatives like TBO are the first tentative steps in that direction. As collaboration becomes more prevalent, the utilisation of well-designed systems will be a much more valuable lever than the current approach of discounting seat prices to less than that of an airline’s competitors.