You’ve heard the complaints: your systems are too clunky, slow, have too many steps, and they take too long to execute everyday transactions.

The dialogue plays out probably hundreds of times a day in offices throughout the world: users complain about to-hard-to-use systems and their IT departments tell them they just don’t know the right way to use them.

This can be a big problem, but costs and other impacts are not easy to measure. A rough estimate can be had by extrapolating the lost time per user across the enterprise.  A 15% hit to people’s productivity because the systems they use slow down their work actually means you need 1.176 people to do the work of one person.

Extrapolating this, if you have a 500-person organization, an equivalent of 88 of those people are needed only because you have sub-optimal systems.  As convincing as this seems, it’s hard to get the money to improve systems based on this argument. With perfectly-efficient systems, you wouldn’t actually need 88 fewer people because the sum of wasted time is across all 500 people.

What do you do? Two relatively low-cost options are user interface (UI – what you see when you look at the screen) tools and mobile applications.

UI Tools: There is an active market for these, which are intended to be used with widely-deployed ERP systems like SAP and Oracle. These solutions modify or enhance the system’s UI for simplified navigation and a more intuitive feel, and may combine several steps in a transaction or query into one, like an Excel macro.

One company marketing UI solutions (Winshuttle) claims to “turn everyday SAP users into heroes who transform the way their companies work.”

Solutions like this are only relevant for those companies that have full control over their systems environments – companies that own their own “instance” of the ERP system, versus those who use a SaaS ERP or one that is shared across many different business units. This is because you’ll need access “under the hood” to configure these tools.

Mobile: A shortcut (sometimes) to simplified ERP transactions is via mobile applications. A mobile application, out of necessity, must have minimal steps involving minimal data entry. No one wants a Windows version of the ERP system on their 5-inch smartphone screen.

This forces the software to consolidate steps in the transaction and pre-populate fields with user data and settings. If a given ERP transaction involves 5 or 6 steps on a desktop it will likely require only 2 or 3 steps on a mobile device.

Several of the large ERP vendors already have mobile versions of the most frequently used transactions, such as purchase orders and purchase order approvals.

You can always design your own mobile applications (there’s no shortage of people creating new smartphone apps), and doing so can lead to some very creative results that have a huge impact on user morale.

Image: Island Peak, Nepal, by McKay Savage, CC license

“Scope,” or “footprint” in software terms refers to the number of business processes that an application will “cover,” or enable.  The scope of an accounting system is usually: general ledger, accounts payable, accounts receivable, fixed assets, P&L and balance sheet.

The scope has to fit the application, and vice versa, and it has to be feasible for the project team and deliver the benefits expected to pay back the investment in the new system.

Too big a scope can overwhelm the team and the application you select.  It will also cost more.  Too small a scope might not be worth the time and expense, and may not yield the financial benefits expected.  A creeping scope starts out small and feasible, then as the project progresses scope is added in the form of requests for features and functions not originally planned.

Money pits are usually found at the end of projects with too big of a scope or a creeping scope.

How do you find the right scope?

Determine which areas of the business would benefit the most from a new or better application. Can you define the specific problems that are leading your enterprise to consider new software? Where are those problems located – in what functional areas and related to which current (legacy) system? Is the problem that a) a particular application is too limiting; b) a group of applications are islands and that integration of them would yield benefits; c) none of your applications are integrated; or d) something else?

Consider a range of scope options to find the optimal one. In some cases, expanding the scope of a new application beyond “problem areas” can be the optimal choice. The process is iterative, and you should consider several alternatives. For example, implementing a new accounting system may satisfy most of a company’s needs and produce a good ROI on its own. But expanding the application footprint to, say, payroll and purchasing, may result in an even better return because it simplifies integration costs, eliminates more manual work, and may strategically be a better decision.

Set up a framework to evaluate each scope alternative. In a framework (Excel comparison) you can evaluate each scope option according to such factors as cost, complexity, length of time to implement, risk to the business, ROI, required internal resources and strategic value. Then you have a logical basis for your decision.

The scope of an ERP project does not have to be huge. You can be selective in what processes to migrate to an ERP system, and you don’t have to convert everything at once – both of these steps will reduce the overall risk of the project. For example, you can implement demand planning systems first to shake out the bugs in what is traditionally a complex and parameter-sensitive application. The core financial systems of an ERP can also be phased in first before everything else.