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.