IT Systems Consulting

Clarity before you commit to a solution.

Audit the week before anyone sells you a build

Most expensive software we see in Kerala SMEs was bought to end an argument that had not been written down. Two packages almost agree. Tally says one stock number. A workbook says another. WhatsApp holds the dispatch list that operations actually trust. A director then asks for “a system.” Vendors quote modules. Six months later the argument is still there, now with a login. LavisTech’s consulting work exists to stop that sequence. We sit with the week you already run — in India, with the people who type — and we write what is source of record, what is a sheet, and what a fundable next step looks like. That is not delay for sport. It is cheaper than encoding a guess about GST, branch stock, or who may reverse a dispatch.

An audit is not a tool recommendation. It is a page a vendor cannot waffle past. If you already know the slice and only need it built, you do not need this service. If the brief is still a paragraph, we will not start a build and call the first month “discovery we forgot to name.” Paid thinking and paid shipping should be two jobs even when they are the same firm. Clarity before you commit to a solution is the whole point. A twelve-module roadmap is not clarity. A sentence a sceptic can survive is.

What we actually look at

We photograph the workbooks, including the ones people are embarrassed by. We note who updates which tab, and which tab is the one they will defend in a meeting. We ask where yesterday’s order lives, how opening stock is decided, and whether item codes are unique or merely hopeful. We ask what Tally is used for versus what staff retype into Tally. We ask which WhatsApp groups are unofficial systems of record. We ask who can restore last Tuesday’s database, and whether that restore has ever been tried. If you cannot restore, do not start a build. You will only create a second system you also cannot bring back.

We also listen for the political document. Sometimes the spreadsheet is a scratchpad. Sometimes it is how a branch manager keeps power. Software that ignores that fact will be correct and unused. A workshop with only the buyer in the room produces a brochure of their hopes. A half-day with the night-shift supervisor produces the exceptions. We want both, with more weight on the second. If two people in the room do not agree what the business does, the problem is not a platform. A workshop is cheaper than a build that cements the argument.

Architecture review for a system you already depend on

Sometimes you do not need a new system. You need a picture of the one you already run. A partner still holds the real connection string, the certificate trick, the Tally flag. Hosting was set up by someone who left. Nobody can say what happens if the box dies on a Sunday. That is not a transformation programme. That is a week that writes the picture down: what talks to what, what is source of record, what is a file drop, what will break if you change a tax rate. We would rather sell that week than a rewrite you cannot operate.

An architecture review is also the right move when two vendors have already quoted “the system” on a one-line brief. We do not use the afternoon to pick a logo. We use it to decide the next sentence: leave the stack alone until a named month; buy a product for a commodity job; fund a narrow slice of the middle; or accept that two packages already disagree and the room cannot name truth. That sentence is the deliverable. A diagram with twenty boxes and no owner is not. If the review finds you should buy Odoo and stay standard, we will say so. If it finds you should keep Tally and build only the dealer portal, we will say so. If it finds you should not spend this year, that is still a result.

Vendor and platform selection without a beauty contest

Send the same one-page brief to everyone. Same systems, same first slice, same definition of done. Ask for assumptions in writing. Then put the replies in a table. If one vendor refuses to write assumptions, they will discover them on your clock. Meet the people who will do the work, not only the person who sold it. Score restatement of your process, named integrations, a definition of done, adjacent work, and change control. Price is a later column. A low score with a low price is how you fund a second project. The checklist we use in the room is the same one we published as how to choose a software development company. We apply it to ourselves. If we cannot restate your process, do not hire us to build.

Ignore “we have two hundred developers,” ISO logos on an email footer, and a slide about AI if you did not ask for AI. Do not ignore a partner who will not sign that you own the source, who wants production passwords in week one, or who quotes a fixed price before they have seen a single export. Students can ship a demo. They struggle when GST treatment is wrong, old item codes collide, or the night shift refuses the new screen. Ask who was on the last job that looked like yours after go-live. Adjacent work is fine. A marketing site is not evidence they can replace your dispatch process.

A roadmap a director can fund — three sentences, not eighty pages

Directors do not fund PDFs. They fund the next slice they can explain to a bank, a partner, or a sceptical operations lead. A usable roadmap is three sentences with dates and a count: staff will record dispatches here instead of WhatsApp by a named month, and we will count how many still went through the group; dealers will raise claims here instead of email after that test passes; the second branch waits until the numbers match for ten working days. That is a programme. Twelve modules on one slide is a brochure. If a director still wants “the full platform” before the first count exists, the platform is a guess with more screens.

We will not deliver an eighty-page strategy document you will not reopen after the workshop lunch. We have seen those. They restate the industry, list trends, and end with a heat map. Nobody can raise a purchase order from a heat map. What leaves our week is a short written picture: systems that stay, the unofficial list, the first-slice sentence, the out-list, the people who must sit with the next phase, and the waits you do not control — Tally at month-end, a bank test key, item codes that three people must agree. If that packet is thinner than you expected, good. Thickness was never the product.

Build, buy, or wait — decided in public

Buy the commodity. Accounting, email, payroll, card payments, a generic CRM for a simple pipeline. Building those from scratch is how custom work gets a bad name. Build the middle: the job that is specific to your warehouse, your job cards, your dealer network, your billing exceptions — the place staff time already goes into Excel. Wait if the pain is still one person’s afternoon, or if two people have not agreed what the business does. The comparison without slogans is custom software versus off-the-shelf. ERP-shaped versions of the same decision belong on the ERP solutions page only after the sentence exists. Do not start there because the word ERP sounded like a plan.

Hybrid is the usual honest answer. Tally or a SaaS ledger stays. The public website stays. You build the portal, the job cards, the branch stock, the thing customers actually feel. That is not indecision. It is refusing to rebuild commodity software. If a package quote to “make it work like we work” already looks like a unique system you will not own, say the word custom and price a slice. If the product can show last Tuesday’s actual job in a sandbox and the person who types can live with it, buy. Change management is real when the product is close and the habit is the problem. It is a slogan when the data model cannot express the job.

What Friday should have produced

A one-page process. An agreement on the system of record. A named owner. A first-slice sentence that names one location or one team. An out-list so June stays honest — portal, second branch, last year’s analytics, a bilingual help site, an AI draft button, whatever was wished on Monday and did not survive Thursday. A list of systems that must stay. A restore test, or a written admission that you do not have one. Assumptions a later vendor must accept or challenge. If a firm cannot promise those objects in writing before the week starts, you are not buying discovery. You are buying a right to be disappointed.

We sell this shape when the brief is still a paragraph. We also refuse to start a build when the brief is still a paragraph. Those two sentences are the same ethic. Free discovery is a sales call that has to be recovered in the build. A paid week is a product. You keep the page even if you never hire us again. The next vendor cannot waffle past it. That is a good Friday. A slide that says thank you for an inspiring week is not.

Time, money, and who must be in the room

A focused audit or architecture review is often one to three weeks of calendar, with a few concentrated days on site or on calls, then writing. A vendor-selection packet on top of that is another short stretch, not a quarter. We are not selling a twelve-week strategy programme. If someone quotes you an eighty-page digital-transformation PDF measured in months, ask which purchase order the PDF can raise. We will not invent a rupee total here that will be wrong for the number of branches or the mess of the workbooks. The shape of serious estimates, once you are ready to build, is on how much custom software costs. Consulting is the prior question: should you build at all, and what sentence you would fund.

Who must attend: an operations lead who can spare real hours, not only a kickoff; someone from accounts who will say when the numbers are wrong; a person who still types orders or dispatches. If those people are “too busy until after the strategy,” you will get a strategy. Software cannot learn the process from a steering slide. Your job in the week is to settle arguments about item codes before anyone encodes them. Our job is to turn that time into writing. A partner who does not ask for that time is planning to guess — whether they are selling consulting or a build.

When you should run this yourselves

A sharp operations lead with a notebook can start this week. Write the job the software must do, who will use it, which systems it must talk to, and what a good first live version looks like. If you can finish those lines in a morning, you may only need a later estimate, not a consulting engagement. Hire the week when the argument is stuck, when nobody owns the sheets, when two vendors have already quoted “the system,” or when a partner still holds production-only knowledge. We will not pretend every firm should hire us for this. We would rather lose a vague request than turn it into a build we have to unpick.

If you want a partner for the week itself, bring the unofficial list, not a blank “we need to digitalise.” The list is the brief. If you want neither a week nor a build, you can still steal the objects above and run the half-day internally. That is a fine outcome. If you want the week, start on the contact page with the argument you cannot settle and the systems that already disagree. Do not send a vision deck. Send the spreadsheet you are ashamed of. That is the document we need.