Business software guide
Business Software: Where the Data Lives and Who Is Responsible
Business software is easier to judge when you know which work it covers, where approved data originates and who decides how it changes. Before adding a new tool, list the existing systems, transfers, access, exports and recovery. That review helps separate a missing feature from an unclear rule or a broken link between systems.
List your systems by the work they support
Sales may hold one customer address, accounting another and delivery a third. A new application will not decide by itself which one belongs on the invoice, the sales rep's contact card or the shipping label. Every purpose needs its own rule.
This guide offers a working framework for reviewing what you already use. Once the review is done, you can judge more clearly whether you need an off-the-shelf tool, an integration or custom development.
Start from departments and workflows, not just the list of contracted licences. Ask where employees keep orders, contracts, stock, contacts and proof of completed work.
Include spreadsheets, forms and side services if they take part in the work. A spreadsheet one employee emails to another department every Friday can be a critical link even though nobody calls it a business system.
NIST CSF 2.0 includes an inventory of software, services and systems, together with a review of flows and selected data types. The table below turns that starting idea into an operational conversation inside the company.
| Review item | What to record | The question it opens |
|---|---|---|
| System and purpose | Tool name and the work it supports | Why do we use it? |
| Business owner | Who confirms the rules and priorities | Who can decide on a change? |
| Data | Important record groups and what they mean | What is created or changed here? |
| Exchange | Source, destination, direction and frequency | When does the other system learn about the change? |
| Access and support | Administrator, supplier, user roles | Who can help, and who may do what? |
| Export and recovery | Available formats, procedure and checks | Can we use the data and restore it? |
| Cost | Where the invoice comes from, the billing model and the review date | Do we know what we pay and per which unit? |
Do not aim for a perfect inventory straight away. Fill in the rows for the systems involved in one important process first. An unknown owner or an untested export is already a useful finding.
Decide the authoritative source for each piece of data
The statement „ERP is the main system" can be too broad. ERP may confirm available stock, while the CRM holds sales notes that the ERP has no reason to take over.
For every important data type or field, write down where the approved value originates, who may change it and how the change reaches other places. Responsibility is sometimes split by data point rather than by the whole customer record.
In this article, responsibility for a record means an operational role: who can explain its meaning and approve a correction. It is not a legal opinion on data ownership, usage rights or roles in personal data processing.
Hypothetical wholesale example
Suppose a wholesaler uses a CRM, an ERP and a carrier portal. The example exists to work through decisions; it does not describe a real company or a Novero delivery.
| Data | Agreed source in the example | Rule to confirm |
|---|---|---|
| Preferred sales contact | CRM | Sales updates the contact following the agreed procedure |
| Address used on the invoice | ERP | The owner confirms the change before the invoice is issued |
| Available item quantity | ERP | Other views must show when the data was last retrieved |
| Shipment status | Carrier portal | A retrieved status differs from the internal order status |
None of these rows requires moving all data into a single database. First, agree on how the values will be understood and used in the business.
Review the handovers where data waits or gets retyped
Follow one record from creation to completion. Note every copy, file transfer, message confirmation and wait for another person.
For each link, ask when the transfer happens, how success is recognised and who resolves a deviation. „Automatic" is not a precise description if nobody knows where a failed exchange shows up.
In the wholesale example, sales may look at a stock figure retrieved earlier the same day. You need to know whether it only informs the conversation or whether an order is confirmed on its basis. The answer determines how fresh the view must be and what extra check is needed.
If you find that the tools support their own tasks well but the transfer between them stays manual, the next subject to assess is integration of business systems. Check the supported access methods and actions first; the wish to connect is not proof that the suppliers allow it.
Separate the decision-maker from the maintainer
Technical support can fix server access but may not decide which sales status is correct. A sales manager can confirm what a status means but may not know how a data import is run.
For important data, assign a business owner for the rules and a technical owner for implementation. If you depend on an external supplier, also record the contact for approving a change or an export.
Microsoft's guide to managing data for migration also separates business understanding of data from technical migration delivery. In a small team the roles may be combined, but the responsibility should still be explicit.
Agree who takes over the duty during absence or when an employee leaves. A business system should not depend on everyone remembering who set up that export several years ago.
Check export and recovery before they become urgent
Export, backup and documentation answer different questions. An export can let you work with selected data in another tool. Recovery should return the agreed state of the system following a tested procedure.
For an export, check whether it contains the relationships between records, attachments, labels and the values you need. An opened CSV file alone does not confirm that you could rebuild the business record.
For backups, record what they cover, who monitors them and when a restore was last tested. The NIST framework's PR.DS-11 outcome includes testing backups. A file merely existing is not a recovery check.
Add an access review: who can export sensitive data, who manages accounts and how permissions are removed. Do not widen access to the whole team just so a few people can inspect the inventory.
Choose the first move based on the problem you found
After the review, rank the findings by their effect on daily work. For example: an unknown data recovery procedure, the same order entered several times or a report two departments read differently.
Next to each finding, write the small verifiable step that follows. It may be a conversation with the supplier, a trial export, a confirmed data definition or an assessment of one integration. A new application is not automatically the first step.
Update the review when you introduce a tool, change a supplier or an owner, or when an important data flow changes. That keeps it useful for the next decision instead of turning into a one-off document.
If data between your tools often disagrees, send Novero your list of systems and one example of the mismatch. That starts the conversation exactly where the problem appears.
Sources
This article draws on two primary external sources, alongside original editorial analysis and an explicitly hypothetical example.
- NIST Cybersecurity Framework (CSF) 2.0, NIST CSWP 29: software, service and system inventory, data-flow review and backup testing (PR.DS-11 outcome).
- Microsoft: managing data for migration in Dynamics 365: separating business understanding of data from technical migration work.