Very important. I'm going to add some hard won, critical commentary here. Sorry if I ruffle any feathers. It's aimed at young teams aiming to disrupt or enter moderate to high complexity markets.

You need to consider current size and complexity as well as anticipated size and complexity.

Of the two, complexity carries both the higher costs and risks. This is significant enough to warrant refactoring complexity even if it costs a bit of overall potential efficiency.

The reason for that lies in the overall difficulty and lock in that often results from customizations to a given ERP system. Once those have been implemented, the tradeoff is most likely near term efficiency happening at the expense of modifications needed in the future state and complexity level.

Further, a small team may well require complexity on par with much larger and more mature teams. As they grow and mature themselves, they may find their most competitive options taken off the table due to cost and the inertia present in the initial implementation.

These dynamics can be painful enough to warrant using something simple, augmented by people and common sense means and less automation in the beginning. This can be planned out such that it ends up being a throwaway. Simple data can often be migrated, transformed, and archived cheaper than a more complex and custom dataset can be.

Scalable is just not always the right move early on. Open data definitely is.

Doing this may yield very significant cost advantages in the future when more of the necessary complexity and automation are known to be a genuine competetitive advantage. Early dollars and burn rate considerations are important here too. Spending a lot in the near term may bring risk and cost, where doing that later on may just bring a cost, which can be managed more reasonably.

You should consider team size, data complexity, market maturity, team maturity, and align that with potential automation as well as where a standard workflow and data representation can work.

A mature market works very different from a new one, and if disruption is part of the business model, it's also very likely to require unique capability from what potential ERP vendors offer. You may consider understanding what is standard, or low cost, low risk features and investing in processes to work with those. Many advanced, "yeah we do that" features are often more like platforms and frameworks than products. Be aware these work at the fortune 500 level, but may be completely impractical otherwise. Vendors will not always present these in ways where that can be understood, and some who shall remain nameless here will leave that spillage to their services team or a partner to sort out long after the initial dales investment is difficult to walk away from.

In that case, you will be left with a high cost implementation and internal IT burden, or will have to patch it in and integrate some other product or just live with a less effective overall solution.

Finally, be aware of cozy people and vendor relationships. These may appear to be advantageous, and may be in mature, well proven use cases, but may in fact be limiting and costly for new or disruptive ones.

It may be worth your time to evaluate the systems and processes used by the target to be disrupted and with an eye on solution vendors and their vision alignment to your "to be" disrupted state. Most are reactive.