Inventory Your Files: Which Sheet Is the System?

In part one we named the five signals that a file has passed its limit, and closed with a five-minute exercise on a single file. If you ran it, you now have written answers about one file. This part widens the exercise to the whole company, because the most expensive mistake in any migration happens before the move rather than during it: starting with the wrong file.

The reason is that what you think of as your system is not necessarily your system. There is the official file — formatted, approved, shown in meetings — and there is another, far less handsome one that somebody opens every morning and works in all day, and out of which come the numbers your decisions rest on. The second is your real system of record, even if nobody has ever called it that. The job of this part is to find it.

Why the number of files grows in the first place

Nobody decides one morning that the company should have forty sheets. The count grows because every new sheet was, at the moment it was created, the fastest available answer. A department needed a field the main file did not have, so it started a small one beside it. Someone needed to work without blocking anyone else, so they took a copy. Management asked for a report in a different shape, so a file was built that pulls from two others. Every step is reasonable; the sum is a map nobody drew.

And because the growth is gradual, the company gradually loses track of which file feeds which. You discover that a monthly report pulls from a sheet whose owner stopped updating it months ago, or that two files hold the same data and each department only updates its own copy. Those invisible links are what make the inventory a step you cannot skip, rather than a piece of administrative tidying.

Three questions that expose the real system

You do not need an exhaustive sweep of every file in the company. Three questions separate the files that carry the work from the files that carry copies of it:

• Which file, if it were lost today, would stop work tomorrow? This is the strongest question in the whole inventory, because it measures dependence rather than declared importance. Ask it in operational terms: if we opened tomorrow and it was gone, could we still receive, issue, invoice and answer a customer? Very few files answer no — and those are your system.
• Who opens it daily? A file opened once a month is a report; a file opened every morning and written into as the day happens is an operational record. Daily frequency is the most reliable indicator that a file has become part of the process itself rather than a description of it.
• Which file has other files built on top of it? Trace direction: where do this file's numbers come from, and where do they go. A file feeding three others is a source, and any error in it is multiplied three times before it surfaces. A file that feeds nothing and is fed by nothing is a strong candidate for closure rather than migration.

Apply the three questions, but do not answer them alone. Ask the people who actually work in the files — the answer sits with whoever opens them, not with whoever receives their reports. You will most likely run into a file you did not know existed, and that will be one of the most important things you find.

What the inventory usually turns up

The inventory does not just produce a list; it explains problems you had been living with for no known reason. Four recurring findings:

• The official file is not the file in use. The carefully built approved template is abandoned, and the team works in a simpler private copy that fits how the work really runs. That is not misconduct, it is information: the official template does not match the real process, and the process won.
• One piece of data in two places. The same customer list or price list exists in two files, and each department updates its own. This is the direct source of the number changing depending on who you ask, which we covered in part one. The durable fix is that every piece of data has exactly one place it is written, the principle behind one source everyone can see.
• Dead files still consuming time. A sheet updated every week for two years that nobody reads. Do not migrate it and do not improve it — ask who uses it, and if no answer comes, stop it for two weeks and see whether anyone asks.
• Meaning stored outside the file. A column called status holding codes one person understands, or a coloured row that means urgent without saying so. The data is present but its meaning is not in it, and that is the subject of the next part.

The Origami view

We are a technology company that builds systems for Saudi businesses, and the first thing we ask for in this kind of project is not a written requirements document but the files themselves, exactly as they are — mess, hidden columns, exceptions and all. The reason is that the file documents how the company actually works, while the written document records how it is supposed to work, and the gap between the two is where projects fail.

The order we recommend is that the inventory comes before any decision about tooling or scope. A company that knows it has exactly two critical files makes a completely different decision from one that assumes forty files all need moving, and that difference shows up in project scope and duration. So our services start by reading what exists before designing a replacement — the same logic we set out in how to implement a system successfully when discussing data migration and change management.

The deliverable: a one-page list

An inventory that produces no page cannot be relied on. Make the output a single table no longer than one page, with only four columns for each critical file:

• The file. Its real name and its actual location: on whose machine, in which shared folder, under which account. Writing the location precisely is a revealing exercise in itself.
• Its owner. One named person, not a department. If you cannot find a single name, the file has no owner, and that is a finding worth recording.
• What depends on it. Which operations stop if it stops, and which files or reports pull from it. This column is what will set the migration order in part four.
• Whether it has a backup. With a direct answer: yes automatic, yes manual and done by a named person, or no. And if the answer is a copy on the same machine, that does not count as a backup.

The number of rows in this list is what decides the size of any migration ahead, and it will usually be far smaller than you expect. A file that combines two traits — work stops without it, and it has no backup — is your number one priority regardless of any other plan. And a file nothing depends on does not deserve to be moved at all; knowing that saves you half the work.

In the coming parts

We know which file is the system; now it has to become fit to move. The next part covers cleaning data before migration: duplicates under different names for the same party, mixed date formats, numbers stored as text, and columns whose meaning nobody knows. The rule we will build on is that every meaning stored in a colour or in someone's head must become a written field before the move. Then we turn to a migration order that keeps you trading, then permissions, then reports, and we close with the first thirty days after the move.

Sources

• Zakat, Tax and Customs Authority — requirements for retaining invoices and tax documents, and retention periods.
• Saudi Data and AI Authority (SDAIA) — the Personal Data Protection Law and the authority responsible for it.
• Ministry of Human Resources and Social Development — requirements for keeping employee records and data.
• Ministry of Commerce — provisions on commercial books and records for establishments.
• National Cybersecurity Authority — controls covering data protection and backup in organisations.