Brought to you by:

Brought to you by Ariba.com

Qwerty, move over

Qwerty

I am typing this blog on a piece of glass, 5 mm thick, connected to billions of devices and the combined knowledge of millions, yet my fingers trace out the pattern of letters designed by the engineers of a mechanical device that my children have never even seen.

The qwerty keyboard.

Over the last 100 years, there have been several attempts to improve it, but any change would founder on the need to retrain literally billions of people.

I’m a pretty fast two finger typist, and my fingers fly over the keys at a decent pace: in fact, they exhibit the “muscle memory” of the familiar layout. The layout created by a nameless engineer who set up the keys so that the word “typewriter” could be typed on just the top row.

Many years ago I attempted to learn to touch type, and I was surprised that the “home keys” were not the most common letters, but include the rarely used “J”, “K” and extraordinarily, the semi-colon.

Muscle memory following the mental models of Venetian merchants

In business we are doing the same. We have our Purchase Order, Sales Order, Shipping Document, Receipt, Invoice, and Cheque. We are also using “muscle memory”, following the grubby pieces of paper first used by Venetian merchants 500 years ago. We may be pretty fast, for example using ERP systems to move documents between our departments and EDI to save some transmission time and costs, but as with the qwerty keyboard, the whole layout is inefficient.

This procedure was developed at a time when documents moved at the speed of a Venetian caravel, and a round-trip to the orient took a year. In the same way, the qwerty keyboard was designed when typing involved moving metal arms.

Both arrangements were chosen to avoid getting jammed.

On a Business Network we have the potential to change this model. My purchase order and your sales order become the same document, rather than two separate documents. It then flips to an invoice. The blanket order is like the semi colon above, an essentially meaningless document that satisfies some muscle memory that all invoices must have a PO.  In a Business Network a blanket order can be replace by shared catalogs and contracts that both parties maintain.

Networks such as Google docs and Zoho already allow document sharing, and it’s not too much of a stretch to see how this type of sharing could be extended to a Business Network.

Change will not be easy, external bodies such as tax authorities and auditors will still want “a signed copy of each invoice”, accountants recite “no PO, no pay” or still insist on a “three-way match.” But Blanket Orders and other such relics are surely ripe for replacement.

Now my idea of overturning the familiar concepts of an invoice and an order may be a little fanciful, but it’s too easy to hang on to familiar mental models, and insist that change is too difficult, and end up with a setup which is not fit for purpose; unless you are a fan of the semi-colon;

 

About the author
James Marland
Vice President of Network Strategy - Ariba (Twitter: @JamesMarland)

James is responsible for defining and rolling out strategies for the Network with particular focus on Europe. He joined Ariba at the launch of the Ariba Network in 1998 after previously being a Solution Consultant at SAP America. In addition he ha... Read More >>>

5 Comments

John Lambie

2013-03-31 18:55:57 Reply

Great article James, And a fascinating parallel between an industrial-age relic hampering our communications and a positively medieval transactional process hampering our financial interactions.

I have to ask why we have such bloated finance departments who do nothing more than move papers between in and out-trays, while entering them all in byzantine accounting systems. I’m also amazed at how these systems are often designed by engineers for accountants – obfuscating the process to make them all but unusable for anyone who hasn’t done the 3-month training program and read the 900-page manual.

Like all guild-based professions (doctors, lawyers, accountants) an entire language and code of practices has been set up — not to serve the businesses they ‘work’ for and help them run smoothly and efficiently, but to protect the guild’s own interests and ensure it’s members can never be replaced by an empowered lay-person.

    James Marland

    2013-04-01 08:24:53 Reply

    Thanks John for the feedback and the additonal examples. It does sometimes seem like our existing financial arrangements are set up by a “guild” and it is likely that a new paradigm could emerge to sweep away the “byzantine” systems. But where, and when that innovation will come from, is hard to say: unlikely to be from the established guild of the G8 ecomonies, though.

Hugh Chatfield

2013-04-03 17:32:06 Reply

The following observation entered my mind a short while ago.

In the past, in addition to the iron rails we built to allow steam engines to move goods and people cross country, we also strung a copper wire alongside the rails on poles.

A person at one end of the wire could write out a message on paper, hand it to a telegraph operator, who typed the message in Morse code – binary (dots/dashes). An operator at the receiving end could receive that electronic binary message and translate it back to a message written on paper to the person who should receive the message.

Skip ahead to a world of computers and the internet running on fibre optic connections.

When we look at how we send invoices – we type the messages into a computer at one end, print out a piece of paper, send the paper by vehicles using up a non renewable resource. Once received, the receiver retypes the data on the invoice back into a separate computer system.

Yep – we manage to get it exactly backward.

In this case – a big improvement would be sending the invoice electronically – just like we used to do with telegraph messages. The “morse code” would be the Universal Business Language (UBL).

    James Marland

    2013-04-04 01:45:58 Reply

    Spot on. In fact I blogged about Samuel Morse in this post: The Victorian Internet

    In my opionion, the fax machine gave rise to a “lost decade” in the 1990s, as we regressed from a digital form (Telex) to an Analog form (and horrible paper, too!). Your comment gives me an idea about a blog posting on this.

    The “Morse Code” that Ariba developed in 2000 is a form of XML called cXMl which has the same aims as UBL. Most other XML B2B protocols were an attempt to translate the EDI business process and documents into the syntax of XML. As such, they generally encountered the same problems that have plagued EDI: The need for point-to-point mappings makes them unsuitable for the Internet. cXML attempts to come at the problem from another angle (informed by EDI but not following it) and avoid those issues.

    Thanks for the input, you can join the community of these users at Ariba.

      Hugh Chatfield

      2013-04-04 13:12:47 Reply

      ” point-to-point mappings”

      Not entirely sure what you are referring to here. Unless everyone adopts the same software (a non starter) – there is always a need to map from whatever form your invoice is in – to the form that the receiver requires. EDI wound up with trying to convert 5000 different sender forms to 5000 receiver forms – truly a nightmare.

      UBL requires your form ->UBL->receiver form .. and most importantly requires that this is done by the sender / receiver respectively.

      Will check out your links…..Hugh

Leave a Comment