Editorial · Technology
Why new software may not fix the problem
Work out whether the problem comes from unclear responsibilities, missing instructions or the software itself. Then decide what needs to change.
Start with the problem you want to solve
A business buys a new system to reduce missed orders, slow approvals or repeated questions. The team moves its records into the product, but the same problems continue.
There are several possible reasons. People may not have agreed on who handles the work or what information they need. The setup may not match the agreed process. The product may lack a necessary capability. These problems need different responses, so it helps to examine one real task before buying more software.
Software can record decisions, route requests, calculate results and show progress. The people running the business still need to decide who can approve a request, what they must check, when someone else should get involved and what counts as a completed task.
Example: an order waiting for approval
Imagine a team setting up purchase approvals. The system needs to know who can approve an order, the spending limit, which location and budget the purchase belongs to, and who covers an absence.
If the owner and managers give different answers, changing the software settings will not resolve their disagreement. They first need to agree on the approval rules. If they already agree but the product cannot support those rules, the software or its setup needs attention.
The same issue can appear in customer service, inventory, scheduling and projects. An order marked “complete” might mean that it was sent to a supplier, accepted by the supplier, delivered or paid. Those are different events. Decide which event each status describes and what record supports it.
More fields and alerts can add work
A missing field sometimes is the problem. But adding fields or notifications without a clear purpose can give people more to enter and more to ignore.
For each proposed field, ask who needs the information and what they will do with it. For each alert, name the person expected to respond and the action they can take. If people maintain separate spreadsheets, find out what the main system fails to tell them before asking them to stop.
Keep information needed to explain decisions, meet obligations or resolve problems. Review fields that serve no useful purpose, while preserving required records. Configure the usual sequence of work and make cases needing help easy to identify.
Keep the decision and its supporting records together
Someone reviewing a purchase should be able to find the quote, who approved it, what changed and what happened afterward. If those records live in different tools, provide a reliable way to follow the connections.
For a disputed delivery, for example, the person handling it needs the original order, supplier confirmation, receiving record and any messages about the discrepancy. A status label alone does not tell them whether to contact the supplier, correct an invoice or arrange a replacement.
The aim is to help the next person understand the problem, see the decision, know who is responsible and check the result. That may involve several tools; the records need to remain connected and accessible to the people doing the work.
Recognize when the product cannot do the job
Clear instructions do not compensate for missing permissions, unreliable operation, poor support, inadequate security, missing history or an inability to export the records you need.
Write down the requirement and test it with a realistic example. If the product fails, record what happened and compare the available options: change the setup, connect another tool or replace the product. Check the cost, effort and ability to recover your data before choosing a replacement.
Try this before making the next change
Choose one recurring task that currently causes trouble. Write down:
- What starts the task and who is responsible.
- Which records and information they need.
- What they may decide and the limits that apply.
- When they need help, and who provides it.
- The actions to take and the records to keep.
- What result counts as finished and how it will be checked.
Run an example through the current software. Note whether each problem comes from an unanswered business question, a setup issue or a missing product capability. Agree on the business decisions that remain open, then make and test the software changes those decisions require.