10 Essential Questions for Brands Adding to Their Tech Stack (Part 1/2)

Nov 21, 2024

If you are a brand, or tech supplier to a brand, and you are serious ab-…

… I can already feel your attention span diminishing?

You’re thinking about something else now aren’t you?

OK. Let’s get into the cosy numbered points to help you focus.

The title kind of says it all, anyway, I guess.

1. Is our ‘why’ good enough?

It’s an interesting paradox.

Every software supplier sees the conscientious people inside brands.

Yet, when it comes to systems, these same brands sometimes fail to fully answer the fundamental question: ‘why’ — why are we adding a new system to the business?

Why are we doing this? Are the reasons good enough? Are we clear on what the benefits of this selection are?

Reasons for adopting new systems range in quality.

At one side of the spectrum is a partially considered approach.

Perhaps a brand hears that competitors, or brands to which they aspire, have implemented ‘System A’.

Once the brand hears that enough times, they begin to see implementing ‘System A’ as just ‘the done thing’, without doing a full analysis of whether implementing ‘System A’ is the right thing for their requirements.

“If it’s good enough for ‘X’, it’s good enough for us”. There’s logic to that.

But, it pays to be on the other side of that spectrum.

There, on that side, are the battle-hardened CTOs, systems managers, finance teams and ops leaders.

They have seen first-hand the digital trench warfare of ERP implementation, survived the psychological blitzkrieg of a platform failing during BFCM, and know that the foundational decision to avoid tech pain and achieve tech gain, is to make the right system choice in the first place.

Because here’s the reality: brands on the second side of that spectrum grow faster than they would if they were on the first side.

So, brands, thumb your nose to ‘that’ll do-ism’. Re-scrutinise your ‘why’.

Ask yourself, “why are we doing this?”

”Are the reasons strong enough?”

”Are the benefits absolutely clear?”

2. What will this really cost?

It pays — literally — to have a deep understanding of every cost factor before you start adding a new system.

Being able to accurately calculate Total Cost of Ownership (TCO) enables a brand to make the most informed procurement decisions.

Below is a breakdown of the cost factors. It’s not a list to scare anybody; it’s a list to empower.

Disclaimer: it’s a long list. More pictures have been added as a peace offering.

Here are the ones most brands tend to consider automatically:

Licensing/subscription fees.
Implementation costs.
Hardware costs (if applicable).
Support costs.

Here are the ones less considered:

Return on investment.

The true cost of the system should factor in the value you derive from it as well as the costs incurred.

Example — if brands expect to get big efficiency gains from automating data flows or using AI agents, that’s a saving on person-hours which should be calculated and offset against the costs.
The cost of doing nothing.

What is your current setup costing you that your new setup wouldn’t?

(This eBook gives some ideas on that and explains technical debt quite well, pages 7–11.)
Data migration

Suppliers don’t always want to handle this, and sometimes charge extra for doing it. Check in each case how they want to work.
The cost of any system customisation.

It’s possible your new supplier charges extra for this; check with them.
Integration costs.

The system being added likely needs integration.

That may or may not be provided by the new supplier, maybe at an extra cost. If you have an integration partner, factor in their costs to work on the project.

Also, integrations are typically an ongoing cost (servers, maintenance, support, etc).
Costs for existing partners/systems.

If you’re integrating this new system into your current stack and the suppliers of other systems are affected, they might charge you to help.

The cost of your team’s time for:
- Training.
- Change management.
  
  Someone needs to manage the change process to ensure everyone is kept aligned to the vision and objectives — the ‘why’ (!) — and delivers the results.
- Testing.
  
  Fundamental to the success of an implementation. Test it thoroughly to make sure it’s working well before you set it loose in your organisation.
- System maintenance.
  
  Someone needs to stay on top of the system admin! Even at the simple end of the scale:
  - Users need to be managed.
  - Integrations need to be monitored.
  - Issues need to be managed.
  - Upgrades need to be coordinated.
  - Data quality needs to be maintained.

Launch.

Depending on the scope of the system, even the launch process could be a time cost worth calculating. Big ERP projects can knock multiple people out of the business for days, even weeks.

How your costs will grow over time.

Work with your supplier to forecast how their costs could grow beyond year 1.
Opportunity costs.
- Downtime during implementation.
  
  Launching a new eComm site, for example, might involve a period of the site being offline — calculate the cost and factor it in.
- Lost productivity for a short period after launch.
  
  Staff might not work as well on the new system straight after the transition. This is a cost worth working out and potentially mitigating.

Decommissioning legacy systems.

Find out whether your old supplier needs to be involved in the cutover to your new one and whether that has a cost impact.

Check whether there any closing down activities with the soon-to-be legacy system which your old supplier may charge for.

If there was hardware used with your legacy system, the cost of disposing it — or indeed the money to be made re-selling it — can be factored in.
Exit costs.

What your supplier/partner might term ‘stickiness’, others have labelled ‘vendor lock-in’.

The true cost of a system, especially one you know you will outgrow at some point in the future, includes the cost of switching away to its successor.

Contingency budget.

Optional but advisable. Better to have it and not need it than the reverse.

Yes, it’s a long list, but with it the power is back in your hands.

No going back the project sponsor asking for more money.

No billing surprises in year 2 of a new system.

Just a clear picture of value.

3. How will the new system impact our existing systems and processes?

OK.

So you have great reasons for taking on a new system. Good start.

And, you have a clear picture of the costs of doing that. Muy bien.

But how exactly will this new system impact the way you do things today?

And, to what extent are you in control of that impact?

The TLDR answer — unless a brand builds its own software, it will almost certainly need to tailor the way it works to the software it selects.

Making a software completely configurable is unachievable, and actually should not be strived for, lest that software becomes a Frankenstein’s monster: grotesque; vengeful; determined to make its creator pay for their unchecked idealism.

Taking eCommerce platforms for an example — it’s predominantly vast retailers which build their own platforms successfully. Nike, Asos, Amazon, all build their own and have flexibility to fit their eCommerce tools around their business processes.

For everyone else, there are ready-made platforms out there to select from.

Those systems — even ones which are heavily modularised and come with a rich app and developer ecosystem — will mean compromise on your existing business processes.

Here’s a simple set of steps to remain in control:

Map out your current processes. (Whimsical is free and has some useful templated process diagrams).
Map out the desired process state.
Consult everyone who needs to input into those process diagrams.
Evaluate the new system for how good a match it is to your desired process state.
(Note: your supplier should be prompting you do this in the sales process).
Identify the gaps. Where does the new system not fit exactly with the way you want to work?
Decide whether those gaps are plugged with a change of process, or by customising the system (if that’s an option).

That’s it!

A simple exercise; one that will improve the adoption of a new system by getting ahead of its impact on the way you work.

4. What are the biggest challenges we pose to this type of system, and can it handle us?

Brands — from a systems perspective, you do weird stuff.

All of you. No exceptions.

Every brand does something idiosyncratic which will give their prospective new system supplier(s) something to think about.

Here are some real-life examples & why they were a challenge:

Category: extremely high data volumes, especially if surge-y.
1. Example: a brand does 100k orders in under an hour on BFCM.
2. Why it’s a challenge: because a lot of retail systems still don’t ‘auto-scale’. They have infrastructural limits. Sudden, large volumes of data might result in slowness, timeouts, even outages.
Category: complex fulfilment requirements.
1. Example: a brand has 3 fulfilment centres: one in the US, one in Europe, one in the UK.
  
  They also have 8 Shopify stores serving different purposes.
  
  The brand wants their systems to be smart enough to direct all orders for European countries, regardless which site they are placed on, to the EU 3PL, all North American orders to the US and all UK orders to the UK.
  
  But, it also wants a secondary layer of logic which allows certain orders to be fulfilled partly from one fulfilment centre and partly from another if the items ordered by a customer are not in stock in their closest fulfilment location. Follow that?
2. Why it’s a challenge: SO many scenarios to account for.
  
  An order placed on a German site, well you send to the EUR 3PL, right?
  
  Oh wait, it’s being shipped to the US for some reason, so let’s fulfil from there.
  
  But, ah… it’s a multi-line order and 1 line is out of stock in the US, so we’ll fulfil that line from the EU.
  
  So now one of our systems needs to split that order into 2.
  
  So now I have 2 order numbers, will my ERP allow 2 orders with the same order number?
  
  OK, I’ll prefix one.
  
  But what does that mean for the fulfilment data coming back?
  
  And, returns? Oh god, returns.
  
  Ah FFS the EU is out of stock of that line too!

The action for the brand:

Recognise the things you do which are likely to pose challenges to your proposed new suppliers and put it to them early — in the sales process.

Ask them, how would you handle this? Do you have reference customers we can speak to for whom you’ve handled this before?

If you don’t bring it up, they might not think to. And, if it’s not explored early, the relationship might begin with vulnerabilities which could have been surfaced at the start.

5. Are we thinking far enough ahead?

It’d be like taking a 737 from London to Brighton; by the time you’d got it up and running it’d already be coming down.

There are a lot of variables here.

What size of brand? (turnover and headcount).
What type of system is involved? (ERP? WMS? eComm? CRM?).
What is the year-on-year growth forecast? (a brand growing at
15% will be faced with different technology challenges to one growing at 100% year-on-year).
How far ahead has the brand planned? (if the brand is young, agile and reacting to new trends all of the time, they might not have a 5-year plan to align technology with).

The killer question is, “how often do you really want to re-platform?”

For key systems, a good rule of thumb is “if this new system can’t support us for at least 3–5 years (building in a buffer for type of system — ERP, for example, 5 years and beyond), we are not thinking far enough ahead”.

Why?

Systems take time to properly select, implement, learn, master and start delivering value.

Change them too soon and you won’t realise their value.

It’d be like taking a 737 from London to Brighton; by the time you’d got it up and running it’d already be coming down.