
How Important Is the Business Size in Choosing ERP? - samsuthar
http://www.skywardtechno.com/blog/business-size-in-choosing-erp/
======
ddingus
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.

