Where packaged software stops: the workarounds are the map

Packaged software rests on a sound bargain. Find the processes that many businesses share, build them once, and sell them to all. Accounts, payroll, tax, basic purchasing and stock work in much the same way everywhere, and it would be wasteful for each company to build its own.

The bargain has an edge. A product can only contain what its customers have in common. Whatever is particular to one of them is, by definition, outside it.

There is no useful way to put a number on that part, and it is not the same size in any two businesses. What matters is which part is which. The shared part is what makes you a company. The rest is what makes you this company: how you buy, make, store, promise and deliver in a way a competitor does not.

This article is about that second part. It usually has no proper system at all, and yet it is the part most worth controlling.

Why the product stops where it does

It is tempting to read that edge as a failing of the software. It is not. It follows from how a product is made.

A vendor decides what to build by looking across customers. A feature that most of them need gets built. A feature that one of them needs is a customisation, and a product made of customisations is no longer a product. So the software settles on the general case: an item has a code and a quantity, a purchase has an order, an approval has a level.

Your operation does not live in the general case. It lives in specifics.

• Units that do not convert cleanly. Material bought by weight and sold by length. Fuel paid for by weight, after a deduction for moisture.
• Parties that are not simply customers or vendors. A broker who delivers on behalf of many farmers. A household that holds assets through several family members.
• Steps that exist only in your trade. Opening packed goods and repacking them for a different buyer. Verifying stock that sits on a supplier’s own land.
• Rules that vary with the season, the site or the customer.

None of this is exotic to the people doing the work. It is an ordinary day. But there is no field for it.

What happens to the part that is yours

The work the product does not hold still has to be done, so it goes somewhere. In practice it goes to one of two places.

It is rented badly. The package is customised, or a second product is bought and bent to fit. The business now pays for software that covers its own process approximately, and every further change goes through someone else’s queue.

It runs in workarounds. A spreadsheet beside the system, a register at the gate, a group chat where approvals are given. These work, often well, because the people who built them know the operation. But nothing in them reconciles, nobody can show who changed what, and the knowledge sits with whoever keeps the file.

Either way there is an irony. The processes every company shares are held in well-made, well-supported software. The processes that set this company apart are held in a rented approximation or in a notebook. The part most worth owning is the part with the weakest tools.

One floor, in detail

Take a textile processing house that finishes cotton cloth. It receives dyed fabric from mills, folds and measures it, grades it, cuts it and packs it into bales. Head office had an ERP of its own. The factory worked on handwritten registers, forms and notebooks, and the paper was carried to head office for data entry.

Look at what the floor needed to record and it is clear why. Fabric arrives in pieces called lumps and is measured in metres. It is cut and folded into smaller pieces, and those are assembled into bales. The lowest grades are not measured at all. They are weighed, and converted back to metres using a figure taken for that particular lot. A packed bale may later be opened and its contents repacked for another buyer. The trade has a word for each of these things. A general stock module has “item” and “quantity”.

The system the textile house runs on that floor today uses the trade’s own units as its records, and each step from arrival to dispatch is an event. But the system is not the point here. The point is that the part of the operation that was theirs alone was visible long before anything was built. It was written down, by hand, in the registers.

The workarounds are the map

You do not need an outside study to find the part of your operation that is yours. Your team has already marked it. Wherever the software stopped, somebody built a workaround, and each workaround points at a piece of the operation the software does not hold.

Go looking for these seven.

1. The spreadsheet beside the system. Ask what it holds that the system cannot. Each such column is a requirement.
2. The remarks field doing real work. Dates, quantities or names typed into free text mean a process is hiding there. Partial deliveries are a common one.
3. The approval in a group chat. If the yes is given in a message and the system receives only the result, the decision is outside the record.
4. The register nobody reconciles. A paper book at the gate or the stores that is never compared with the system holds events the system never sees.
5. The person who just knows. If one person can say where a lot is, or which customer takes which pack, their memory is acting as a database.
6. The code with a meaning packed inside. An item code or order number whose third character means something is a field the software did not offer.
7. The report built by hand each month. If someone exports, pastes and adjusts before management sees a number, note every adjustment. Each one is a rule.

Write them down as a plain list: what the workaround is, who keeps it, and what decision it supports. Do not tidy it. The mess is the information.

Sorting the list

Not everything on the list deserves software. Sort each item into one of three piles.

Change the process. Some workarounds exist only out of habit. If the packaged system’s way is close enough and nothing is lost, adopt it. This is the cheapest outcome, and it is more common than it sounds.

Leave it alone. A workaround used twice a year, by one person, with no money attached, is fine as it is.

It is the operation. What remains are the workarounds people depend on every day, where money, stock or a promise to a customer follows from them. They are not untidiness around your process. They are your process, and at present you own it only informally.

A useful test for the third pile: would a competitor do this in exactly the same way? If so, a product probably covers it somewhere, and you should look harder before building. If not, it is yours, and no product is going to arrive that covers it.

What to do with the third pile

There are three honest options, and each is a decision about who holds this part of the business.

Customise the package. This works when the pile is small and sits close to what the product already does. It becomes fragile when the customisation is larger than the feature it hangs from, and it leaves the vendor in charge of what happens to your process at the next upgrade.

Keep the workarounds. This is a real choice and sometimes the right one. Its cost is that this part of the business runs without a record: no history, no permissions, nothing that reconciles, and a dependence on the few people who keep the files.

Build a system for that part, and own it. A system for the third pile, sitting beside the package, while the package goes on doing accounts and payroll. Owning it means three things: you decide what is built and when, a change in the process becomes a change in the system without a queue, and the knowledge of how it works is written down and stays with you.

The third option has always been the right answer in principle. In practice it took a year and a large team, so keeping the workarounds became the default. That cost is what has changed.

A worksheet for the list

For each workaround in the third pile, fill in one row before you speak to any supplier.

Column	What to write
The workaround	The file, register or chat group, by the name people call it
Who keeps it	One name, and who covers when they are away
The decision it supports	What is ordered, received, promised, approved or paid because of it
What depends on it	Money, stock, or a commitment to a customer
Its exceptions	The cases the remarks column exists for
The trade’s words	Units and terms the packaged system has no field for

Ten rows of this are a better brief than most requirement documents. They also show you something no vendor’s presentation will: which part of your business you already run on your own design, without a system that is yours.

Phlo is the framework Jetbro builds on for exactly this part of an operation. Its foundations are already written, so the time goes on mapping the floor. Jetbro builds that first system with you. After it, the framework becomes available to you: your own engineers can build the next system on it, or Jetbro carries on.

Whichever option you choose, start with the list. It costs nothing to make, and it is the most accurate description of your operation that exists.