How to define MVP for ERP software

How can you define the minimum viable product (MVP) in Enterprise Resource Planning (ERP) software when all of the functionality is so interrelated and highly complex?

It doesn’t really matter whether you use Kanban, Scrum or another Agile practice, the aim is the same: to deliver MVP as soon as possible, prove to the business that this solution fits, and then in iterations upgrade it until it’s at a level where customers are satisfied. First you upgrade it to Minimal Marketable Product (MMP) and then to a full scope fully functional product.

For ERP software this can be done in several ways, depending on the project specifics. There are many techniques in Agile to help define the scope and the MVP. 

The most straightforward way would be to treat ERP like any other piece of software, defining the full scope and the MVP using story mapping or another technique, and then in refinement sessions throughout the project align the out-of-box functionality and your best practices with the customer needs that are of the highest value. You even can prepare better for refinement sessions because you already have a product to show – just configure it to the best of your abilities and discuss it with the customer.

The MVP could include some basic functionality which would allow the customer to “get a taste of” the ERP software either in full or in limited (most valuable to the customer) scope. In the best-case scenario business would be able to start using the software in partial scope (a Minimal Marketable Feature (MMF) or Minimal Marketable Product (MMP)), using old software or other tools like Excel in parallel. As for the MVP, you can treat it as a prototype, proof of concept, beta version or version 0.1 – whatever option brings the most initial value to the customer. There are special techniques for mapping and prioritising the scope, and defining the MVP.

An Example

We can take as an example the ERP project of a manufacturing company producing water. They would like the ERP to cover all their operations, including manufacturing, warehousing, logistics, finance, personnel, reporting and consolidation. They operate in five countries, or in five cities. 

You could facilitate a few days’ workshop to define the full scope at a high level. During that you would also define the MVP. 

In this example it could be a setup of:

  • the item catalogue with basic information
  • basic warehousing – only for accounting inventory quantities
  • basic purchases to make item purchasing possible in the simplest scenarios
  • basic sales to simulate selling of manufactured goods 
  • a chart of accounts – only to accommodate purchasing and cost calculations
  • and maybe a simple Bill of Materials to show that the system can convert raw materials into products

No data migration. This MVP functionality could be out-of-the box features of ERP with some configured and developed tweaks. 

You commit to this MVP and deliver it in few weeks. What value does this bring? The customer can test-drive the basic functionality and get a feel of the system. They might notice different features, generate some questions, and cancel previous requirements and generate new ones based on this hands-on experience. In some rare cases, if it delivers better than what they had previously been using (emails and a few Excel spreadsheets, for example), the customer might see the value of the product and even switch over to using this MVP release.

What’s Next

The next release could be a go-live of the smallest plant as a pilot with data migration and a minimum set of features (Excel or other kinds of workaround tools could still be used to get all the work done), and then release by release deliver the scope the customer values the most.

Did you notice that customer can play around with the software as early as three weeks after work on the project has started? Waterfall does not usually provide this as an option.

Keep in mind that Agile is not suitable for all ERP implementations. Agile is best for those with a medium to high level of uncertainty about the scope of functionality and business specifics.

Remember, this is just an example, and a simplified one. We would be delighted to dive into a real example and help you with your scope and MVP definition.