Skip to content

The future of business system usability

March 4, 2010

Don’t you just hate it when you have the wrong tool for the job? We’ve all had to “apply the hammer” to situations which would probably have been better off with a screwdriver – or in some cases we’ve had to apply pliers to nuts!

Sometimes you just have to do what you have to do – but is it good enough as a long-term solution to a job you need to do everyday? Well, you probably wouldn’t put up with it.  So why, all too often, do we put up with using the wrong “tools” when working on our business systems.  Here are some examples of the wrong “tools”  used in business systems: asking trades people to log into the corporate system to update work orders or time confirmations, asking managers to log-in to complex reporting tools to understand their businesses performance or having to deliver reams of dated, static paper reports to executives.  All of these are examples of people using the best that was available years (or in some cases decades) ago to get their job done.  And the efficiency of the organisation and our own performance suffers – it is notoriously difficult to get accurate and timely information on asset performance back from maintenance technicians, managers still complain about not being able to get information ‘out’ of a system and executives often need to make decisions based on information that is at least a month old. 

Over the last few years (I’ve still got a beach towel from the 2001 ASUG  Conference Usability Lab – although that probably says more about my ability to throw things away than anything related to system usability) there has been a lot of work done on improving the usability of ERP systems – particularly how screens are designed, which fields are placed where and how many ‘clicks’ it takes to complete a transactions. This is still important but the game has changed – it’s no longer necessary to have a “computer” to transact in an ERP system.  Ignoring machine-to-machine transactions – integrating to SCADA, RFID, etc – and looking only at human data entry we can find mobile device, digital pens, faxed data with ORC which are just some of the ways people can transact and support business processes.  Service Oriented Architecture and Business Process Management has also made it easier to trigger business system transactions from interfaces other than those delivered directly from the ERP software vendor or by technology other than the ol’ PC.

The starting point in making decisions on which technology to use are the organisations ‘to-be’ business processes.  All business re-engineering, ERP implementation projects, improvement projects etc would have as output the business process and which systems these process will be executed in and also probably a ‘swim-lane’ definition of the roles needed to execute the transactions.  The nature of the transaction is not always defined.  What do I mean by that?  I mean that there are characteristics of a transaction that lends itself to different technologies.  These characteristics are: complexity of transaction, frequency of transaction (number of transactions per day, week, etc) and % of total users doing the transaction.  Lets look at an example, an activity in a process might be ‘Enter work order time confirmation’.  How complex is this transaction – not very it’s just entering the work order number, the operation and date(s) and start and end time.  How often are these transactions performed – very often, a large organisation would have hundreds of these coming in every day.  What % of system users are doing this – probably a high percentage.  This sort of transaction: low complexity, high volume and many users needs the simplest of interfaces.   Something like the digital pen or an ORC paper reader would be ideal.  What other transactions fall into this category?  Probably things like project cost forecasting, work order status update, goods receipt and proof of delivery.  And so as transaction become more complex and maybe less frequent the more it makes sense to use the native ERP interface.  Of course all transactions will always be available at least in the core ERP user interface.  I’ve put some technologies in a continuum below technologies which could applied to different business transactions, with low volume, high complexity on the left and high volume, low complexity on the right. 

 

 My main point from this post is that a single user interface will probably not drive business efficiency and process compliance and a range technologies should be assessed to get the best UI.  How do we know which is the best UI, what’s cost benefit analysis for any of these technologies.  Well I’ve got some ideas which I’ll post next time.

Cheers,

Duncan

 

Advertisements

From → Usability

3 Comments
  1. john dwyer permalink

    Interesting thought initiators and discussion points, with usability being a particular interest point for me. A further recent bout of user training is a continuing wrench back to reality at a nuts-and-bolts level, and it is not pretty.

    Keep the blogs coming.

  2. Duncan

    I agree with you that it is hard to determine upfront what sort of user inteface will be required when people start using the applications in their environments. There are so many other technologies that drive user interactions that it is difficult to determine what is the “next thing”. We’ve seen a rapid increase in demand for Andriod-based user interfaces just in the last 2 months.

    The approach that we have followed is to try an create a single design environment that will render the same form in various user interfaces. We are a Microsoft based application (and play in the Duet space) and we’ve created a solution where the same form is rendered in Microsoft SharePoint, Outlook, iPhone, BlackBerry, Andriod, Windows Gadget and the range of Internet browsers (IE,Firefox, Safari, Chrome).

    User interfaces remain a challenge 🙂

    • Duncan permalink

      Hi Pieter,

      Device independent access to the same form is a great approach. This should further reduce the cost to use interfaces other than those provided by the ERP software vendor. The design of the interface and when and how it interacts with the business process will remain critical – value is generated when beautifully designed UI’s are put on sleek business processes. I look forward to seeing more of that.

      Cheers,

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: