Why June is a useful pause
April and May are when finance lives in Tally, Excel, and late evenings. July onwards, many firms start promising work that must land before Onam or the autumn festivals. June is often the first quiet week in which someone can ask whether the software you already pay for is doing the job, or whether a spreadsheet is still the real system.
This is not a transformation programme. It is a checkpoint. You do not need a new platform to run it. You need a morning, the people who type all day, and five questions that are awkward enough to be useful. If the answers are clean, you leave the stack alone and spend the second half of the year on work that makes money. If they are not, you still have time to fix the boring parts before a festival deadline makes every change look like an emergency.
We run this shape of review as IT systems consulting when two packages already disagree, or when nobody in the room can name the system of record. You can also run a thinner version yourself. The questions below are the ones we would put on one page and take into the room.
Question 1 — How many systems of record do you have?
A system of record is the place you would defend in an argument. If two numbers disagree, which one wins? For money, that should be the ledger — Tally, or whatever you file from. For stock, it should be one warehouse truth. For jobs, it should be one list of work that is open, not a WhatsApp group and a whiteboard.
Most mid-size firms in Kerala have two. Accounts live in Tally. Operations live in a package, a custom screen, or a workbook that has been “temporary” since 2019. Sales lives wherever the last person saved the file. That is already three truths if you count generously. The June question is not “how many logins do we have”. It is “when Friday’s numbers do not match, which file do we trust, and who is allowed to say so”.
Two systems of record are survivable if they have a named join. Tally holds money. The operations tool holds jobs. A posting or an export keeps them honest. Two systems of record with no join are a weekly reconciliation job you have hired a person to do. That person is not a strategy. They are a warning light.
Write the list on a whiteboard. Ledger. Stock. Jobs. Customers. Dealers. Payroll if it is not already a product. For each, write the winning system in one word. If you cannot, you have found the first problem. Do not solve it in the same meeting. Name it. The build versus buy decision later depends on whether you are replacing a commodity or the operational middle.
What two truths look like on a Tuesday
A dispatcher prints a list from the “system”. The warehouse ticks a sheet. Accounts posts from a third file that someone emailed at 6 p.m. By Wednesday the three lists have diverged by a handful of lines. Nobody is stealing. The process has three owners who each believe they are looking at the original. June is when you notice that the divergence is not a bad week. It is the design.
If the join is a person, write their name. If they go on leave in August, write what happens. If the answer is “we wait”, you do not have two systems of record. You have one person of record. That is a more honest phrase, and it belongs on the same page as the backup question later.
Question 2 — Which work still lives in a shadow sheet?
A shadow sheet is the workbook staff keep because the official system cannot express the job. Price exceptions. Branch transfers. Job cards that mix labour, parts, and a promise the customer already has in writing. Dealer claims. The “real” dispatch list. If you ask only managers, you will hear that the system covers 80 percent. If you ask the person who types, you will be shown a file with a name like final_v7_use_this.xlsx.
The test from our comparison page still holds. Eighty percent means staff can finish the job in the product without a second process. If the missing 20 percent is how you invoice, or how you allocate stock across branches, you do not have a fit. You have a brochure and a workbook. June is a good month to photograph those workbooks — not to shame anyone, but to see the actual product you are already maintaining.
Shadow sheets are not automatically a reason to build custom software. Some of them exist because nobody trained the last package. Some exist because a director wants a report the system already has, in a layout they like. Some exist because the data model cannot say what the business must say. The review’s job is to sort those three. Only the third one belongs in a build conversation.
How to find the sheets nobody mentioned
Sit with the people who close the day, not the people who signed the licence. Ask what they open first in the morning. Ask what they would take on a USB stick if the office flooded. Ask which WhatsApp group is the real queue. You will get more truth in forty minutes than in a week of slide decks.
Write each sheet as a sentence: who updates it, what it decides, which official system it contradicts, and what happens if it is wrong. If the sentence is “we retype this into Tally every Friday”, you have an integration job, not a new ERP. If the sentence is “this is how we actually bill”, you have the operational middle. That is the slice custom software versus off-the-shelf is for — not a rebuild of email, payroll, or the ledger.
Do not collect twenty sheets and call that a backlog. Rank them by how often they are used and how expensive a mistake is. A daily dispatch list that can ship the wrong lot is ahead of a monthly chart a director looks at once. June is for the daily ones. The monthly charts can wait until you know which system of record they should read.
Question 3 — Who owns exceptions?
Every business has work the system cannot describe: a price that is not on the list, a job that skips a step, a dealer who is allowed to see tomorrow’s rate, a customer who pays on a shape no package author imagined. The question is not whether exceptions exist. They will. The question is whether a named person is allowed to grant them, and whether the grant is written down somewhere you can find in November.
If exceptions live in a phone call, you will not be able to explain a dispute. If they live in a shared login “just this once”, you have already lost the audit trail. If they live in a sheet that only one supervisor can edit, you have an owner — fragile, but an owner. Write the name. Write the deputy. If there is no deputy, you have a leave-shaped outage waiting for Onam week.
Software does not remove exceptions. It makes them visible. A first slice that cannot record “why this line is different” will be abandoned for the sheet that can. That is why we refuse to strip audit trails out of an MVP. A June review that finds exception-without-owner is not a reason to buy a platform. It is a reason to write a one-page rule before anyone opens a new vendor brochure.
Exceptions that are really the process — the way you always bill a certain kind of job — do not belong in a side door. They belong in the data model. If you have been calling the same “special case” for three years, it is not special. It is the work. Put it on the system-of-record list. That is often the moment a package starts to look expensive and a narrow custom slice starts to look cheaper over three years.
Question 4 — When did you last restore a backup?
A backup you have never restored is a rumour. Ask for the last date someone actually brought a copy back and opened it. If the answer is “the vendor does it”, ask for the last ticket. If the answer is “it is on a drive in the cupboard”, ask who last plugged that drive in. If the answer is a cloud tick-box nobody has tested, write that down as unknown, not as safe.
June is a better month to fail a restore than September. You still have time to buy a second copy, to move the only backup off the same machine as the live data, or to admit that the desktop application in the stores office has no backup at all. The night shift will not thank you for discovering this during a festival order.
Restore is not only files. It is identity, licences, and the one Windows box that still talks to a USB dongle. It is the export from Tally and the folder of PDFs that is not in Tally. Write what you would need on a Monday morning if the office did not open. If that list only exists in one person’s head, you have another person of record. Name a deputy before you talk about new features.
If you cannot restore, do not start a build. You will only create a second system you also cannot bring back. Backups and a handover belong in the first conversation of a systems review, not as a footnote after someone has already quoted a rewrite.
Question 5 — What does year three cost?
Year one is the invoice everyone remembers: licences, a partner, a build, a migration. Year two is quieter — renewals, a few change requests, hosting. Year three is where the honest comparison lives. The product still wants licences. The custom system wants hosting and a change budget you control. The hybrid wants both, in smaller numbers. The shadow sheets want the staff hours you already spend and never put on the vendor’s slide.
We will not invent a rupee total for your firm. The useful work is to put three columns on one sheet — product, custom, hybrid — and fill years one to three with what you already know: subscriptions you can see on last year’s bank statement, partner days you actually bought, the person who reconciles two systems every Friday, the overtime in May. Leave blanks where you do not know. Blanks are more honest than a round number from a brochure.
A product wins when those three years are mostly subscriptions and you are not paying someone to invent your process inside a module. Custom wins when year-two “small changes” on the product already look like a second system you will not own. Hybrid is the usual answer for firms that should keep Tally and a public website, and only build the operational middle. That argument is finished on the custom versus off-the-shelf page. June is when you put your own numbers next to it, not a vendor’s.
Include switching cost. Leaving a SaaS in year three is an export, a mapping project, and a month of two truths. Leaving a custom system you own is a handover of source, hosting, and backups. Neither is free. Ask what a full export looks like before you renew. If the answer is “CSV of some tables”, price the cleanup as part of year three, not as a surprise in year four.
A half-day that is not theatre
Block a morning. Bring one person from finance, one from operations, and one person who still types the job. Leave the vendor in the waiting room. Write the five answers on one page. Photograph the shadow sheets. Name the exception owner and the deputy. Write the last restore date or “unknown”. Sketch year three with blanks.
Do not use the afternoon to pick a platform. Use it to decide the next sentence: leave the stack alone until November; buy a product for a commodity job; fund a narrow slice of the middle; or pay for a proper systems review because two packages already disagree and the room cannot. That sentence is the deliverable. A twelve-module roadmap is not.
- Name the winning system for money, stock, jobs, and customers.
- List the three shadow sheets that run the week, not the twenty that exist.
- Write the exception owner and the deputy, or write “none”.
- Write the last successful restore, or write “unknown”.
- Fill year-three columns with invoices you can show, and leave blanks you cannot.
If you cannot finish those five lines in a morning, the problem is not software. It is that two people in the room do not agree what the business does. A workshop is cheaper than a build that cements the argument. We have said that on the consulting page for a reason. June is a good month to take it seriously.
What to do with each kind of answer
If you have one system of record per job, no daily shadow sheet, a named exception owner, a restore from this year, and a year-three cost you can explain — stop. Do not shop for a new stack because a salesperson has a calendar. Spend the second half of the year on customers.
If you have two systems of record and a person who joins them, keep the person, write the join, and decide whether an export can replace the retype. That is integration, often a small service, not a new ERP. If you have two systems and no join, you are already paying for a review whether you call it that or not.
If the shadow sheet is the invoice, you are past training. Read the build-versus-buy page and price a first slice, not a platform. If the shadow sheet is a report, teach the official system or export once. If nobody owns exceptions, write the rule before you write code. If backups are unknown, fix that this month. None of those answers require a festival deadline.
Leave it, buy it, or build a slice
The checkpoint is allowed to end in “leave it”. That is a decision. Write it down so the next brochure does not reopen the year. Buying is right when the job is common — payroll, email, cards, a simple pipeline. Building a slice is right when staff already maintain the real process in a sheet, and that process is why customers stay. Rebuilding Tally is almost never the slice.
Year-three cost is how you keep the room honest. A cheap year one that renews forever is not cheap. An expensive year one that you own can be cheaper by year three if the alternative is a partner who customises a package into a corner. We will not pretend the arithmetic is the same for a two-branch workshop and a dealer network. Put your hours on the sheet. Then choose.
If the five answers are messy and the argument is still about whose number is true, stop choosing software. Hire a short systems review, or run the half-day again with the people who type. Clarity before a solution is the whole point of the consulting work. June is early enough to use it. September is when the same questions start to sound like blame.