When Excel is no longer enough, but ERP is premature: choosing the next step

1. What job does your spreadsheet actually perform?

One workbook can act as an order register, product directory, calculator and management report. Those roles have different requirements. Flexible formulas are useful for exploratory analysis. The same freedom in daily transaction records can allow accidental changes to history. Separate the purposes before assessing the tool.

Ask the author where information comes from, who edits it and which decisions use the result. Follow one record from creation to reporting. Include chat messages and other files along the way. The open workbook does not reveal all the surrounding work.

Describe the problem as an observable event: refreshing the report removes a manager’s comments, or two employees maintain different statuses for the same order. “Excel is outdated” does not explain what must change. It also provides no acceptance criterion for a replacement. Keep the original business question visible while comparing solutions.

2. Which symptoms reveal a real limitation?

Repeated loss of control matters: nobody knows which copy is current, who changed a value, why totals differ or how to recover without the author. One slow calculation does not establish a need for ERP. It might call for a different data structure, simpler formulas or separating reporting from entry.

Assess the consequence, not only inconvenience. An error in a presentation draft and an error in available stock affect operations differently. Record who detects the issue, when it becomes visible and how much work could be affected before detection. Do not turn a few observations into unsupported business-wide statistics.

Check organizational causes too. If no one owns the item directory or metric definitions, a new platform will not automatically assign responsibility. Agree rules first, then choose mechanisms that support them. An expensive application can preserve the same ambiguity in a different interface.

• File copies diverge without a defined authoritative source.
• Manual refresh changes formulas or removes operational comments.
• Important transactions lack an owner, state or observable completion.
• The team cannot produce a report or resolve a failure without one person.

3. Audit the files and handovers in one workflow

List the files involved in one process. For each, record an owner, inputs, recipients, refresh frequency and required access. Do not begin by copying an entire drive into a new service. Structures and anonymized examples are sufficient for the initial investigation; agree access to working data separately.

Distinguish source files from outputs that merely calculate a result. If the same product code is corrected in three places, decide where it should be created and maintained. If reports disagree, compare periods, statuses and inclusion rules before searching for a broken formula.

Finish with a dependency list. A weekly report might require a CRM export, returns register and manual code mapping. For every dependency, describe what happens if the source is late or its structure changes. These are future automation requirements, not minor technical details. Assign an owner to unanswered questions instead of assuming every input will remain stable.

4. When is improving the workbook enough?

A spreadsheet can remain suitable for bounded analysis or a simple workflow with controlled entry and acceptable error consequences. First check a shared location, stable headers, separate reference data, input validation and clear ownership. Do not add a macro merely to bypass an unresolved rule.

Separate source data, transformations and outputs. Keep manual comments separately, linked by a stable identifier, when the output table is rebuilt on refresh. A coloured row without an explicit status field is difficult to verify or migrate. Important states should be data, not formatting alone.

Protection against accidental worksheet edits is not equivalent to access control for confidential records. If different users may see different parts of the dataset, assess the actual permission mechanism. Do not distribute a complete file because sensitive columns are hidden. Include the recipient’s access and export capabilities in the assessment.

5. When does automated consolidation help?

If the main problem is repetitive importing, cleaning and combining, automate that path without replacing the whole operational system. Microsoft describes Power Query as a way to connect, transform, combine and refresh data in Excel. Verify particular connectors and capabilities for your version and environment.

Consolidation is not transaction management. It can prepare a report, but it does not itself decide who approves an order or resolves competing reservations. Do not assign a data-preparation tool responsibilities that need separate rules and mechanisms.

Agree column types, keys, timezone and permitted missing values before automation. A changed date format or renamed column should create a visible exception rather than silently remove rows. Show the last successful refresh and whether all required sources were included. A successful query execution alone does not establish that the dataset is complete or current enough for its intended decision.

6. How do you verify an automated report?

Teaching scenario: a retailer combines CRM orders with a separate returns register. One order can have several return rows. Joining those rows directly to orders and summing the order amount can repeat the amount several times. The cause is different data granularity, not workbook size.

Define what one row means in each source. Agree whether the output is grouped by order, item line or event. Test an order without returns, one with a partial return and one with several returns. Do not substitute zero for an unmatched record without a rule: missing correspondence and a true zero are different conditions.

Keep control totals before and after transformation and a list of rejected records. Another authorized person should explain the result without rewriting the query. Readiness means reproducibility and visible exceptions, not just a polished dashboard. This is an invented scenario, not a customer result. Use reference records you can reconcile manually before trusting the complete output.

7. When is a database with a form the next step?

Consider this when the central need is shared structured entry with validation, roles and change history, but a complete ERP workflow is unnecessary. An internal request register with approval might be a separate tool. A database alone, however, does not provide a working process or usable interface.

Requirements include creation, editing, search, permissions, event history, backups and recovery. For API input, test repeated requests, validation failure and interrupted connections. If two employees edit one record, define the behaviour rather than silently losing one change.

Compare a specialized service with custom development over the full support lifecycle. Who changes rules, updates dependencies and restores operations? A small application can be appropriate, but it is not free forever merely because there is no per-user subscription. Include handover documentation and the ability to export records in the comparison.

8. When should CRM or ERP be evaluated?

Investigate CRM when the problem concerns enquiries, deals, owners, next actions and communication history. Investigate ERP or another operational system when connected purchasing, inventory, manufacturing or other workflows need consistent rules. A category label does not guarantee suitability; check the particular edition and scenarios.

The signal is not simply file count but the need for coordination across transactions. If a sale must create a reservation, release warehouse work and account for returns, independent files need substantial coordination. Compare maintaining that connection with the mechanisms available in candidate systems.

Do not require every old column to migrate. Some support manual workarounds that the new workflow removes. Ask which decision or required record each field serves. Do not delete unwanted history without agreement: define an archive and access separately. A cleaner operating model does not require losing the ability to explain earlier transactions.

9. How do you avoid two parallel sources of truth?

Choose one object or flow for the first launch. Define the moment after which new records are created in one designated place and how changes between initial export and cutover are transferred. The old workbook can remain an archive or reconciliation tool without quietly continuing as a second working database.

Prepare normal, incomplete, exceptional and history-bearing reference records. Check them using future users’ permissions. Recovery must account for records created after launch; restoring an old copy without them can lose new work. Keep the source until acceptance and an agreed retention decision.

Train people on a real workflow using safe data. They should know where to start, how to finish and where to send an error. Train the backup owner too. If the new process depends on one person exactly as the old workbook did, part of the original problem remains. Test that handover before the regular owner becomes unavailable.

10. How can you tell whether the change helped?

Before launch, record a few measures tied to the problem: reporting time, manual handovers, inconsistent records or time to detect failure. Compare similar periods and workloads. A faster but incomplete report is not an improvement, so include a quality check.

Count new work separately: rule maintenance, exception handling and access administration. Automation can shift effort to another team rather than remove it. Do not promise cash savings from minutes saved alone; understand how the released capacity will be used. Include recurring support when evaluating the ongoing burden.

After the pilot, decide to retain, revise or stop the change. Record why and when to review it again. The aim is not to prove that Excel is bad, but to make particular work more reliable at an acceptable cost. A well-supported workbook can be a better first result than an unfinished migration.

• The problem is an observable event with a consequence.
• Sources, owners, keys and refresh rules are defined.
• Scope is the smallest sufficient change, not every available feature.
• Reference scenarios, visible errors and verified recovery exist.
• The outcome can be maintained and explained without the original author.