The future of business system usability
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.