Whether it is a customer relationship manager, a project management platform, an inventory tool or an online booking system, introducing a new business system is a significant decision. It affects how people spend their day, where information lives and how different parts of the organization work together. It is also a decision that is easy to make quickly and expensive to reverse.
The considerations below are not a procurement manual. They are a practical set of questions that help organizations choose with more confidence and fewer surprises.
Start with the problem, not the product
System selection often starts with a demonstration that looks impressive. Before looking at products, write a short statement of the problem you are trying to solve and how you will know it has improved. For example: “Client information is spread across email, spreadsheets and paper files, so staff spend time searching and sometimes work from outdated details.”
A clear problem statement keeps evaluation grounded. It also helps you notice when a problem might be better solved by changing a process, improving how an existing tool is configured, or providing training, rather than introducing something new.
Map how the work actually happens
Every system encodes assumptions about how work should flow. If those assumptions do not match your reality, people will create workarounds, and the system will gradually lose value.
Before evaluating options, map the workflow the system will support. Note each step, who is responsible, what information is needed and where handoffs occur. Include exceptions: the urgent requests, the unusual clients, the end-of-month tasks. Exceptions are where systems most often struggle.
Turn needs into clear requirements
Requirements translate the workflow into a list you can evaluate options against. A simple way to keep them manageable is to group them:
- Must have — without these, the system cannot do the job.
- Should have — important, but a reasonable workaround exists.
- Could have — useful additions that should not drive the decision.
Write requirements as observable capabilities rather than vague qualities. “Staff can see a client’s full communication history on one screen” is easier to test than “good client management.” Include non-functional requirements too: accessibility, performance, availability, data location and the ability to export your information.
Think carefully about integration and data
New systems rarely stand alone. Consider which existing tools the system will need to exchange information with, such as accounting software, email, a website or a reporting tool, and how that will work in practice. Native integrations, third-party connectors and manual imports each come with different trade-offs in cost, reliability and maintenance.
Data deserves particular attention:
- Migration. What existing information needs to move into the new system, and what condition is it in? Cleaning data before migration is almost always easier than cleaning it afterwards.
- Ownership and export. Can you get your data out in a usable format if you change systems later?
- Reporting. Will the system provide the information people need for decisions, or will reports still be assembled by hand?
- Single source of truth. Be clear about which system is authoritative for each type of information to avoid conflicting records.
Look at the total cost, not the subscription price
The licence or subscription is only part of the cost. A realistic estimate also considers setup and configuration, data migration, integrations, training, internal staff time during the transition, ongoing administration and future price changes as the organization grows. Comparing options on total cost over several years often produces a different ranking than comparing monthly fees.
Ask vendors practical questions
Demonstrations show what a system can do in ideal conditions. Useful questions help you understand how it will behave in yours:
- Can you walk through our specific workflow, including the exceptions we described?
- Which features are included in the plan we are considering, and which cost extra?
- How is customer support provided, and what are the stated support hours?
- Where is our data stored, and how is it protected?
- How are updates released, and how much notice is given for changes?
- What does the process look like if we decide to leave?
Where possible, test with real scenarios during a trial period and involve the people who will use the system every day.
Consider privacy and security from the start
If a system will hold personal information about clients, customers or staff, consider your privacy obligations early. Organizations in Canada should understand which privacy laws apply to them — for many private-sector organizations this includes the federal Personal Information Protection and Electronic Documents Act (PIPEDA) — and seek qualified advice where needed. Practical questions include who will have access, how permissions are managed, how long information is retained and what happens to data when the relationship with the vendor ends.
Plan for adoption, not just installation
A system succeeds when people use it consistently. Plan for training that reflects real tasks, clear guidance on what the new process is, and a period where questions are expected and answered quickly. Appoint an internal owner who understands both the system and the work it supports.
A phased rollout is often safer than switching everything at once. Starting with one team or workflow allows problems to surface while they are still small and builds confidence before wider adoption.
Before you decide
- We have a written problem statement and a way to recognise improvement.
- The current workflow, including exceptions, has been mapped.
- Requirements are prioritized into must, should and could.
- Integration and data migration needs are understood.
- Total cost has been estimated over several years.
- Privacy and security questions have been asked and answered.
- There is a named internal owner and an adoption plan.
Taking time over these questions does not have to slow a decision down. More often, it prevents the far larger delay of choosing a system that does not fit. Our Business Systems and Technology Consulting services can help structure this process.
Topics: Business Technology, Operations, Data. This article provides general information and is not legal, financial or professional advice for your specific situation.
