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.