Learning Objectives
By the end of this chapter, you will be able to:
- Describe the phases of an ERP implementation, from planning to post-go-live support.
- Explain fit-gap analysis and why experts recommend minimum customization.
- Compare big bang, phased, parallel and pilot go-live approaches, and on-premise vs cloud (SaaS) ERP.
- Explain how core ERP modules hand data to each other in procure-to-pay and hire-to-retire.
- Identify critical success factors, common failure causes, change-management activities and total cost of ownership (TCO) components.
- Apply Nepal-specific requirements (VAT, e-billing and CBMS, fiscal year) to an ERP project.
Why Implementation Is the Hard Part
The previous chapters explained what an ERP system is and how it supports the order-to-cash process. Buying the software is the easy part. An ERP package comes with built-in assumptions about how a business should work; Davenport (1998) warned that an enterprise system “imposes its own logic” on a company’s strategy, organization and culture. Implementation is the project of deciding where the business adapts to the software, where the software is configured to the business, and how people move from the old way of working to the new one.
Markus and Tanis (2000) describe the enterprise system experience cycle in four phases:
- Chartering: the decisions that lead to funding the project (business case, package and partner selection).
- Project: configuring the system and rolling it out to users.
- Shakedown: the period after go-live until operations become “normal”.
- Onward and upward: ongoing use, improvement and upgrades until the next major change.
The practical phases below fit inside this cycle.
The ERP Implementation Phases
flowchart LR
P["1. Planning\n(chartering)"] --> R["2. Requirements"]
R --> FG["3. Fit-gap\nanalysis"]
FG --> D["4. Design &\nconfiguration"]
D --> M["5. Data\nmigration"]
M --> T["6. Testing"]
T --> TR["7. Training"]
TR --> C["8. Cutover &\ngo-live"]
C --> S["9. Post-go-live\nsupport"]
S -.->|"improvements, upgrades"| R
style C fill:#1565c0,color:#fff
Figure 1: ERP implementation phases. In practice, data migration, testing and training overlap.
| Phase | Key activities | Main output |
|---|---|---|
| 1. Planning | Business case and goals; scope (modules, sites); steering committee and project sponsor; budget; select the package and implementation partner | Project charter, plan and budget |
| 2. Requirements | Map current (“as-is”) processes; define future (“to-be”) processes; list legal, reporting and integration needs | Requirements document, process maps |
| 3. Fit-gap analysis | Compare each requirement with the standard package; classify as fit or gap and decide how to close each gap | Fit-gap register with decisions |
| 4. Design and configuration | Set up company structure, chart of accounts, tax codes, approval workflows, user roles; build the agreed extensions and integrations | Configured system, design documents |
| 5. Data migration | Extract from old systems; clean duplicates and errors; map to new fields; load masters (customers, suppliers, items, employees) and balances | Clean master data and reconciled balances |
| 6. Testing | Unit tests, end-to-end integration tests (e.g. order-to-cash), user acceptance testing (UAT), performance tests, a parallel payroll run | Signed-off test results, defect log |
| 7. Training | Role-based training; train-the-trainer for “super-users”; quick-reference guides in the users’ language | Trained users, support materials |
| 8. Cutover and go-live | Freeze old system entries; final data load; reconcile; go/no-go meeting; switch users over | Live system, cutover sign-off |
| 9. Post-go-live support | “Hypercare” period with extra support; fix defects; monitor key reports; then continuous improvement and upgrades | Stable operations, improvement backlog |
Fit-Gap Analysis
Fit-gap analysis compares what the business needs with what the standard ERP package does. Each gap can be closed in one of four ways, from cheapest to most expensive to maintain:
- Change the process to follow the package’s standard practice.
- Configure the package (settings, workflows, report layouts) without code.
- Work around with a report, a manual step or a small add-on.
- Customize (change or extend the code).
Nah, Lau and Kuang (2001) list “business process reengineering with minimum customization” as a critical success factor: every customization must be re-tested and often rewritten at each upgrade.
Example fit-gap register for a Nepali distributor
| Requirement | Fit or gap | Decision |
|---|---|---|
| Sales orders, stock reservation, delivery notes | Fit | Standard |
| VAT invoices at 13% with VAT-registered buyer’s PAN | Fit | Configure tax codes and invoice layout |
| Dates in Bikram Sambat (BS) on invoices and reports | Gap | Use a Nepal localization add-on or configure |
| Fiscal year from Shrawan 1 to the end of Ashadh | Gap/fit | Configure fiscal periods (check the package) |
| E-invoices linked to IRD’s CBMS (if turnover threshold is met) | Gap | Use an IRD-enlisted billing solution or connector |
| Sales staff want their old Excel discount sheet | Gap | Change process: use the package’s price lists |
Go-Live Approaches
| Approach | How it works | Advantages | Risks | Suits |
|---|---|---|---|---|
| Big bang | All modules and sites switch on the same day; the old system stops | Shortest overall timeline; no temporary interfaces | A failure affects the whole business at once; heavy training load | Smaller firms with simple processes and a strong test phase |
| Phased | Go live by module (finance first, then inventory) or by site (head office, then branches) | Lower risk per step; lessons from early phases carry forward | Longer project; temporary interfaces between old and new systems | Multi-branch or multi-company groups |
| Parallel | Old and new systems both run for a period; results are compared | Safety net; outputs can be reconciled | Double data entry; staff overload; expensive | High-risk processes such as payroll or a first month-end close |
| Pilot | One site, department or product line goes live first as a full trial | Real-world test before wider rollout | Pilot site may not represent others | Chains of similar branches (e.g. retail outlets) |
Approaches can be combined: for example, a pilot at one branch, then a phased rollout by region, with a one-month parallel payroll run.
On-Premise vs Cloud (SaaS) ERP
In Software as a Service (SaaS), as defined by NIST SP 800-145, the consumer uses the provider’s applications running on cloud infrastructure and does not manage the underlying servers, operating systems or storage. See Cloud Computing for the service models.
| Factor | On-premise ERP | Cloud / SaaS ERP |
|---|---|---|
| Cost pattern | Large upfront licence and hardware (capital expenditure) | Recurring subscription per user or module (operating expenditure) |
| Infrastructure | Company buys and runs servers, backups, security | Provider runs infrastructure; company needs reliable internet |
| Customization | Deep changes possible, but harder to upgrade | Mostly configuration and extensions within provider limits |
| Upgrades | Company schedules and pays for upgrade projects | Provider releases updates on its schedule |
| Data location | Company’s own premises or chosen data centre | Provider’s data centres; check contracts and any legal requirements |
| Internet dependence | Works on the local network during internet outages | Needs a backup internet link; plan for outages |
| IT staff needed | More (servers, database, security) | Fewer, but still needed for integration, roles and vendor management |
Nepal consideration: for businesses outside the main cities, a second internet connection and an offline billing fallback procedure are part of the cloud ERP decision, not an afterthought.
Core ERP Modules and How They Integrate
| Module | Main functions | Sends data to |
|---|---|---|
| Finance and accounting | General ledger, payables, receivables, cash and bank, fixed assets, tax | Every module posts to it; it produces financial statements |
| HR and payroll | Employee master, attendance, leave, payroll, tax deductions | Finance (salary expense and liabilities) |
| Procurement (purchasing) | Purchase requisitions, supplier quotations, purchase orders | Inventory (expected receipts), Finance (commitments) |
| Inventory and warehouse | Stock levels, goods receipts and issues, transfers, valuation | Finance (stock value), Sales (availability), Procurement (reorder) |
| Sales and distribution | Quotations, sales orders, pricing, delivery, invoicing | Inventory (reservations), Finance (receivables, revenue) |
| Manufacturing / production | Bills of materials, production planning, work orders, costing | Inventory (consumption, finished goods), Finance (costs) |
| CRM | Leads, opportunities, customer service cases, campaigns | Sales (orders), Finance (credit status) |
Integration is visible in end-to-end processes. Order-to-cash was covered in Chapter 6.5. Two more:
flowchart LR
subgraph P2P["Procure-to-Pay"]
PR["Purchase requisition\n(Procurement)"] --> PO["Purchase order\n(Procurement)"]
PO --> GR["Goods receipt\n(Inventory)"]
GR --> SI["Supplier invoice\n3-way match\n(Finance)"]
SI --> PAY["Payment\n(Finance)"]
end
subgraph H2R["Hire-to-Retire"]
HI["Hire\n(HR)"] --> AT["Attendance & leave\n(HR)"]
AT --> PY["Payroll run\n(Payroll)"]
PY --> GL["Salary posting\n(Finance)"]
end
Figure 2: Procure-to-pay and hire-to-retire across ERP modules
In procure-to-pay, the three-way match compares the purchase order, the goods receipt and the supplier’s invoice before payment is approved. Because all three documents live in one database, mismatches in quantity or price are flagged automatically, a control that is hard to enforce with separate spreadsheets.
Critical Success Factors and Common Failure Causes
Researchers have studied why some ERP projects succeed and others fail. Two widely cited frameworks:
Nah, Lau and Kuang (2001) reviewed the literature and identified 11 critical success factors:
- ERP teamwork and composition
- Change management programme and culture
- Top management support
- Business plan and vision
- Business process reengineering with minimum customization
- Project management
- Monitoring and evaluation of performance
- Effective communication
- Software development, testing and troubleshooting
- Project champion
- Appropriate business and IT legacy systems
They mapped these factors onto the Markus and Tanis phases, showing that different factors matter most at different stages. Somers and Nelson (2001) similarly examined how the importance of success factors changes across implementation stages.
Holland and Light (1999) split success factors into strategic factors (legacy systems, business vision, ERP strategy, top management support, project schedule and plans) and tactical factors (client consultation, personnel, business process change and software configuration, client acceptance, monitoring and feedback, communication, troubleshooting).
Common failure causes are largely these factors done badly:
| Failure cause | Linked success factor |
|---|---|
| Treated as an “IT project” owned by IT only | Top management support; project champion |
| No clear goals or measures of success | Business plan and vision; monitoring and evaluation |
| Heavy customization to copy old habits | Minimum customization; process change |
| Dirty or incomplete master data at go-live | Legacy systems; testing |
| Weak testing of end-to-end processes | Testing and troubleshooting |
| Users trained too late or too generally | Change management; communication |
| Wrong team (part-time, no key users) | Teamwork and composition |
Change Management
ERP changes jobs: who approves a purchase, who can edit a price, how fast month-end closes. Resistance is normal, so plan for it:
- Stakeholder analysis: who gains, who loses control or workload, who must sign off.
- Visible sponsorship: the owner or CEO explains why the change matters and attends steering meetings.
- Super-users in each department who join design workshops, test the system and support colleagues after go-live.
- Communication plan: what changes, when, and what it means for each role, repeated through go-live.
- Role-based training with the company’s own data, close to go-live, with guides in Nepali where staff prefer it.
- Reinforcement: retire old spreadsheets on a fixed date, update job descriptions, and track adoption (for example, share of purchase orders raised in the system).
Total Cost of Ownership (TCO)
TCO is every cost of owning the system over its life (often planned over five or more years), not just the licence. Major categories:
| Category | Examples |
|---|---|
| Software | Licences or subscriptions, add-ons, localization modules |
| Implementation services | Partner consultants for design, configuration, project management |
| Infrastructure | Servers or cloud hosting, networking, backup internet, end-user devices |
| Data migration | Cleansing, mapping, loading and reconciling data |
| Customization and integration | Extensions, interfaces with banks, payment gateways, e-billing/CBMS |
| Testing | Test environments, user time for UAT |
| Training and change management | Trainers, materials, super-user time |
| Internal staff time | Key users seconded to the project; temporary backfill staff |
| Ongoing support | Annual maintenance or support contracts, internal ERP administrator |
| Upgrades | Re-testing and re-doing customizations at each major version |
| Productivity dip | Slower work in the first weeks after go-live |
| Contingency | Reserve for scope changes and delays |
Internal staff time and the productivity dip are the costs most often left out of the business case.
Nepal Context: Rules Your ERP Must Handle
- VAT: The Value Added Tax Act, 2052 (1996), Section 7 sets a flat VAT rate of 13%, with zero-rated items listed in a schedule. Under the VAT Rules, registration is not required for a business with transactions not exceeding NPR 50 lakh (goods) or NPR 20 lakh (services or mixed) in the last twelve months. The ERP must apply correct tax codes, print VAT invoices and produce VAT registers.
- Electronic billing: IRD’s Electronic Billing Procedure, 2074 allows only billing equipment and software enlisted with the Inland Revenue Department to be used for electronic invoices; the list is published on ird.gov.np. Ask the ERP vendor or partner for proof of enlistment.
- CBMS: In a notice dated 4 Baisakh 2083 (April 2026), IRD stated that all taxpayers with annual transactions above NPR 20 crore (except banks and financial institutions that do not issue invoices directly to customers) must issue invoices electronically and connect them to IRD’s Central Billing Monitoring System (CBMS) at the time of issue. Thresholds have changed before, so check the latest IRD notice during planning.
- Fiscal year and calendar: Nepal’s income year runs from Shrawan 1 to the end of Ashadh (mid-July to mid-July), and many documents use Bikram Sambat dates. Many firms plan go-live at the start of a fiscal year so that opening balances are clean.
Case-Style Exercise: Gandaki Agro Traders (hypothetical)
Gandaki Agro Traders distributes seeds, fertiliser and farm tools from a head office and warehouse in Pokhara and two branches in Butwal and Bharatpur (Chitwan). Today it uses desktop accounting software at head office, a separate stock spreadsheet at each branch and payroll in Excel. Stock counts rarely match the books, branch managers phone head office to check stock, and month-end closing takes about two weeks. Its annual turnover is close to the CBMS threshold. The owner wants a single ERP within a year.
Tasks
- Recommend a go-live approach and justify it.
- List five fit-gap items you would expect, with a decision for each.
- Choose on-premise or cloud ERP and give two reasons, including one about connectivity.
- Name the three critical success factors you consider most at risk, and one action for each.
- Propose a go-live date and a data-migration checklist.
Model answer points
1. **Pilot then phased by site:** go live at Pokhara head office and warehouse first (finance, inventory, sales, procurement), stabilise for one or two months, then roll out to Butwal and Bharatpur. Run payroll in **parallel** for one cycle. A big bang across three sites with poor stock data is high risk. 2. Bikram Sambat dates; 13% VAT invoices with buyer PAN; IRD-enlisted e-billing and CBMS connection; branch stock transfers; seasonal credit sales to farmers' cooperatives with due dates; existing discount spreadsheets (change process to price lists). 3. Cloud ERP reduces server management for a firm without IT staff and gives branches the same live data; require a backup internet link at each branch and an offline invoicing fallback procedure. On-premise is defensible if connectivity is unreliable, but then branches need a secure connection to head office anyway. 4. **Data quality** (legacy systems): count stock and clean item codes before migration. **Top management support / project champion:** the owner chairs a monthly steering meeting and appoints a full-time project lead. **Change management:** one super-user per branch, Nepali-language guides, and a fixed date to retire stock spreadsheets. 5. Shrawan 1 (start of the fiscal year), so opening balances come from audited closing figures. Checklist: freeze item, customer and supplier masters; remove duplicates; physical stock count; load opening stock by location; load open receivables and payables; reconcile trial balance to the old system; sign-off by the accountant.Summary
ERP implementation turns packaged software into a working business system. It runs from planning and requirements through fit-gap analysis, configuration, data migration, testing and training to cutover and post-go-live support. Organizations choose a go-live approach (big bang, phased, parallel or pilot) by balancing speed against risk, and choose on-premise or SaaS deployment by balancing control against infrastructure burden. Modules such as finance, HR, procurement, inventory, sales, manufacturing and CRM integrate through shared data in processes like procure-to-pay and hire-to-retire. Research on critical success factors stresses top management support, clear vision, minimum customization, good data, testing, communication and change management. In Nepal, the project must also handle 13% VAT, IRD-enlisted e-billing, CBMS for businesses above the threshold, and the Shrawan–Ashadh fiscal year.
Key Takeaways
- Implementation phases: planning, requirements, fit-gap, design/configuration, data migration, testing, training, cutover/go-live, post-go-live support.
- Close gaps by changing the process or configuring before customizing.
- Big bang is fast but risky; phased, parallel and pilot approaches reduce risk at the cost of time or effort.
- SaaS ERP shifts cost to subscriptions and infrastructure to the provider, but depends on reliable internet.
- ERP modules integrate through shared data: one transaction updates inventory, finance and other modules at once.
- Most ERP failures are management failures: weak sponsorship, unclear goals, heavy customization, dirty data and poor training.
- TCO includes internal staff time, training, upgrades and the post-go-live productivity dip, not only licences.
Discussion Questions
- Why do Nah, Lau and Kuang recommend “minimum customization”? When might customization still be justified?
- A bank’s payroll and a supermarket chain’s billing both need to go live. Which go-live approach would you choose for each, and why?
- How do IRD’s e-billing and CBMS requirements change the ERP selection process for a Nepali company near the turnover threshold?
- Which costs in the TCO table do business owners most often underestimate, and why?
Exam-Style Questions
Short answer
- List the main phases of an ERP implementation.
- What is fit-gap analysis? Give four ways to close a gap.
- Distinguish big bang and phased go-live.
- State four critical success factors for ERP implementation.
- What is CBMS, and which Nepali taxpayers must connect to it?
Long answer
- Explain the ERP implementation process from planning to post-go-live support, with the key output of each phase.
- Compare on-premise and cloud (SaaS) ERP for a medium-sized Nepali manufacturer.
- Discuss the critical success factors and common failure causes of ERP implementation, citing the literature.
- With a diagram, explain how ERP modules integrate in the procure-to-pay process.
References
- Davenport, T. H. (1998). Putting the enterprise into the enterprise system. Harvard Business Review, 76(4), 121–131.
- Holland, C. P., & Light, B. (1999). A critical success factors model for ERP implementation. IEEE Software, 16(3), 30–36. doi.org/10.1109/52.765784
- Markus, M. L., & Tanis, C. (2000). The enterprise system experience: From adoption to success. In R. W. Zmud (Ed.), Framing the Domains of IT Management (pp. 173–207). Pinnaflex.
- Nah, F. F.-H., Lau, J. L.-S., & Kuang, J. (2001). Critical factors for successful implementation of enterprise systems. Business Process Management Journal, 7(3), 285–296. doi.org/10.1108/14637150110392782
- Somers, T. M., & Nelson, K. (2001). The impact of critical success factors across the stages of enterprise resource planning implementations. Proceedings of the 34th Hawaii International Conference on System Sciences.
- Mell, P., & Grance, T. (2011). The NIST Definition of Cloud Computing (NIST SP 800-145). doi.org/10.6028/NIST.SP.800-145
- Inland Revenue Department, Nepal. विद्युतीय विजक सम्बन्धी सूचना (notice on electronic invoices, 4 Baisakh 2083). ird.gov.np/content/13488/cbms-notice-01-04
- Inland Revenue Department, Nepal. Electronic Billing Procedure, 2074 (4th amendment, published October 2021) and the list of enlisted billing software, available via ird.gov.np.
- The Value Added Tax Act, 2052 (1996), Section 7, and Value Added Tax Rules, 2053, via ird.gov.np/content/7798/thevalueaddedtaxact19962052
