ERPNext projects rarely fail because the software cannot do something. They struggle when nobody is clearly responsible for a decision, a data file or a sign-off. Naming the roles at the start, and writing down who does what, prevents a large part of the delays and disagreements that follow.

These are project roles, not ERPNext user roles. One person may hold several of them in a small business.

Roles on the business side

Usually the owner, managing director or a senior executive. The sponsor:

  • Explains why the business is changing
  • Approves scope, budget and major decisions
  • Settles disagreements between departments
  • Makes the final go or no-go call

Without an active sponsor, decisions stall and departments pull in different directions.

Project lead (client side)

The day-to-day organiser inside the business. They schedule workshops, chase data, track actions and keep the sponsor informed. In a small business this may be the finance manager or operations manager.

Process owners

One person per area, such as finance, stores, purchasing and sales. They:

  • Describe how work is done and should be done
  • Approve process maps and design decisions for their area
  • Sign off UAT for their processes

Data owners

The people responsible for each master list: customers, suppliers, items and the chart of accounts. They decide on merges, naming and groupings, and they check loaded data. Often the same people as the process owners.

Key users

Experienced users in each department who test, help train colleagues and support them after go-live.

Internal system owner

The person who looks after ERPNext once the project ends: users, permissions, small settings changes, and coordination with outside support. Name them early so they learn alongside the project.

Roles on the delivery side

Whether these come from a partner or an internal team:

  • Implementation lead: runs the method, plans phases and manages the delivery team.
  • Functional consultant: leads workshops, designs the solution, configures the system, plans data migration and trains users.
  • Developer: builds any agreed customisations, integrations or reports that need code.
  • System administrator: sets up and maintains hosting, backups and upgrades.

Writing it down with a RACI table

A RACI table lists the main tasks down one side and the roles across the top. For each task, mark who is:

  • R, Responsible: does the work
  • A, Accountable: owns the outcome and signs off; only one per task
  • C, Consulted: gives input before decisions
  • I, Informed: is told about the result

For example, for "approve the chart of accounts", the finance process owner is accountable, the functional consultant is responsible for preparing it, the sponsor may be informed, and the external accountant may be consulted.

Useful tasks to include:

  1. Approve scope
  2. Approve process maps
  3. Approve fit-gap decisions
  4. Clean and supply master data
  5. Configure the system
  6. Approve print formats
  7. Run and sign off UAT
  8. Approve opening balances
  9. Make the go-live decision
  10. Provide support after go-live

Common gaps

  • Nobody is accountable for data. Files arrive late and unchecked.
  • Several people are accountable for one decision. Nothing gets approved.
  • The sponsor is absent. Disagreements are never settled.
  • No internal system owner. The business depends entirely on outsiders after go-live.

Checklist

  • Sponsor named and committed
  • Client-side project lead named
  • Process owner and data owner named for each area
  • Key users chosen in each department
  • Internal system owner named
  • Delivery team roles clear
  • RACI table agreed for the main tasks and shared with everyone

Setting up project roles and governance is covered in the ERPNext Implementation Consultant course, which follows these roles through each phase of a real project.