The discipline, framework, and feedback loop most Indian SMEs and MSMEs are missing.
Many organisations have invested heavily in collecting operational data, but have not built the organisational discipline, analytical framework, and feedback mechanisms required to convert that data into decisions and measurable performance improvement. You may already have most of the data you need. The missed opportunity, in almost every business I have walked into, is that nobody has built the system that continuously turns that data into questions, answers, actions, and feedback.
There is a particular kind of conversation that tends to happen in the first meeting with a new manufacturing or trading client, and it happens often enough now that I can predict roughly how it will go before the person across the table has finished the first sentence. They will describe, usually with real pride, the sensors they installed on the shop floor, or the quality management module they bought, or the ERP they migrated to two years ago, and they will list the reports it produces with the fluency of someone who has sat through the vendor demo more than once. And then, a few minutes later, almost as an aside, they will admit that nobody actually looks at most of it, or that looking at it means three people spending half a day each month pulling numbers into a spreadsheet to see if last month’s story matches this month’s, by which point whatever the numbers were trying to tell them has already cost money. This piece is an attempt to explain why that pattern is so common, particularly among Indian SMEs and MSMEs, what the evidence actually says about how deep the gap runs, and what a genuinely effective monitoring and analysis framework looks like in practice, drawn from work Arsenal IT Consultants has done inside manufacturing, healthcare, and procurement environments running on Odoo, ERPNext, and SQL Server.
The hypothesis, and why it deserved checking rather than assuming
It is easy to assert that companies collect data and then fail to use it, because the claim flatters the person making it and rarely gets pushed back on. Before writing this, I wanted to see whether the pattern held up against real research rather than just consulting folklore, because a hypothesis that sounds obviously true is exactly the kind that is worth testing properly.
The India SME Forum’s Digishaastra 2025 report, built from a survey of close to eight thousand MSMEs across the country, is a useful starting point precisely because it separates two things that get conflated in most conversations about digitisation: adopting a digital tool, and actually using data from that tool to decide something. On adoption, the news is genuinely encouraging, with 53.8% of surveyed MSMEs having taken up at least one digital tool. On the second, much harder question, the picture changes considerably: only around 13.2% of those digitally active enterprises report actually using analytics tools on top of what they have digitised, and the report puts genuine data driven decision making at under 20% for businesses with turnover below fifty crore rupees. Put plainly, roughly half of Indian MSMEs have crossed the first threshold of putting their operations into a system, and a small fraction of that group has crossed the second, much more valuable threshold of turning what that system captures into a decision that would not otherwise have been made, or made in time.
The gap is not unique to India, and it is not unique to small business either, which suggests something structural rather than a simple lack of ambition. IBM’s frequently cited estimate is that as much as 90% of sensor generated data across industries goes unanalysed, and a Splunk survey of enterprise data leaders found that roughly a third of organisations believe three quarters or more of their data is never used at all. What changes for an Indian SME or MSME is not the existence of the gap but its cost relative to the size of the business, because a large multinational can absorb the inefficiency of dark data as a rounding error against its overall spend, while a mid sized manufacturer that paid real money, often a meaningful fraction of its annual technology budget, for a quality management system or an IoT retrofit feels the waste directly and personally, in cash flow terms, not just in an abstract efficiency metric.
A study of smart manufacturing readiness among Indian automotive SMEs, published this year and built on survey responses from over thirty component manufacturers, gets closer to explaining why the gap persists rather than just measuring it. The two barriers it identifies most consistently are financial constraints, meaning tight capital budgets that make it hard to fund anything beyond the initial collection layer, and a skills gap, with the research noting that roughly half the manufacturing workforce will need reskilling to meet the demands of connected, data driven operations. Both of these point toward the same underlying explanation: the collection layer gets funded because it is visible, demoable, and easy for a vendor to price, while the analysis and monitoring layer gets deferred because it looks like an internal project with no clear owner, rather than a purchase with a delivery date.
What the gap actually costs, in numbers a finance function will recognise
Manufacturing quality is where this gap shows up most starkly in rupee terms, because the Cost of Poor Quality is one of the few places where the price of not connecting your data has a well established benchmark. Industry estimates, echoed by the American Society for Quality and more recent manufacturing research, put COPQ at fifteen to twenty percent of total sales revenue for a typical manufacturer, and the same research is consistent on a second point that matters even more for this argument: the visible cost of scrap and rework, the number that shows up easily in a monthly review, is usually only a tenth of the true figure once you account for warranty claims, customer escalations, and the engineering hours spent repeatedly diagnosing a defect pattern that better connected data would have flagged after the second occurrence rather than the twentieth.
This is not a call to collect more inspection data, and it is worth being explicit about that, because the instinctive response to a quality problem is often to add another checkpoint or another sensor. In every engagement I have seen where this was tried in isolation, the immediate effect was more data sitting in more places, not fewer defects reaching the customer, because the constraint was never the volume of what was being captured. The constraint was the absence of a framework that brought different sources of quality data into the same view, on a cadence tight enough that a pattern could be caught while the batch was still on the floor rather than after it had shipped.
What an effective monitoring and analysis framework actually looks like
Having built this kind of layer across quality, purchase, and clinical operations contexts, the pattern that works reliably comes down to four things done in order, and none of them require replacing systems the business has already paid for: integrate the data, analyse it meaningfully, take action on what the analysis actually says, and use the outcome to improve performance on a continuing basis rather than as a one time project.
Integrate data. This starts with an honest audit of what is already being captured, and where it currently lives, because in almost every engagement the raw material for a solution already exists, scattered across two or three systems that were never designed to talk to each other. In a quality context this typically means inspection sheets from measurement stations sitting alongside a formally maintained rejection register classified by defect category, with nobody having built the join between the two. Underneath that audit sits a proper structural layer, separating the raw transactional records a system generates from the fact and dimension tables that make trend analysis fast and reliable. This sounds like a technical detail, and it is one, but it is the difference between a dashboard that takes thirty seconds to load and quietly gets abandoned, and one that a shop floor supervisor or a purchase manager will actually keep open during the day. In a hospital dashboarding engagement built on ERPNext version 16, this meant moving source data out of the hospital information system’s native MongoDB structure into a proper PostgreSQL fact and dimension model, with access managed through ERPNext and charting handled by Apache ECharts, chosen deliberately because it supported the drill down sophistication the clinical and operations teams actually needed rather than a generic chart library that looked fine in a demo and fell short in daily use.
Analyse meaningfully. Integration on its own produces a tidier version of the same problem if nobody has decided what actually gets watched, and on what cadence, which is a business decision disguised as a technical one. A reject rate trend needs to be visible daily or near real time to be useful on a shop floor, while a control plan approval status might only need weekly review, and a vendor delivery performance pattern in procurement might be most useful reviewed monthly against the purchase order cycle. Getting this cadence wrong in either direction, either drowning a manager in real time noise they cannot act on, or burying a pattern in a monthly report that arrives after the decision window has closed, is one of the most common reasons a well built dashboard still fails to change behaviour. Meaningful analysis also means resisting the instinctive response to a quality problem, which is usually to add another checkpoint or another sensor. In every engagement I have seen where this was tried in isolation, the immediate effect was more data sitting in more places, not fewer defects reaching the customer, because the constraint was never the volume of what was being captured.
Take action. This is the step most often missing entirely, and it is the one that separates a dashboard from a framework. The monitoring layer cannot stop at a chart, it has to connect a detected pattern to a work order, an escalation, or a review meeting with a named owner and an expected response time. In the automotive component quality work referenced earlier, this meant a single dashboard bringing reject rate trends, PIR, IR, ISIR, and line inspection counts, and control plan approval status onto one screen across twenty one quality and seventeen maintenance destinations, replacing what had previously been a set of separate monthly exports that required manual reconciliation to even confirm the dimensional inspection data and the rejection register agreed with each other. The value was not in generating a new number. It was in making an existing, already paid for set of numbers arrive together, on time, in front of the person who could still do something about it.
Improve performance. The loop only earns its keep if the business checks, on a regular cadence, whether acting on the data actually moved the number it was meant to move, and adjusts the framework itself when it does not. This is the step that turns a one time consulting project into a habit the business owns, and in practice it is a short recurring review, monthly in a quality or purchase context, that asks a narrow question: did closing last month’s flagged patterns change this month’s reject rate, delivery slippage, or turnaround time, and if not, was the wrong thing being watched, or was it being watched at the wrong cadence. That is a much smaller conversation than the one that produced the original dashboard, and it is the difference between a framework that keeps paying for itself and one that quietly reverts to being a report nobody opens.
Why this matters more, not less, for SMEs and MSMEs specifically
There is a version of this argument that applies mainly to large enterprises with dedicated data teams, and that is not the argument being made here. For an SME or MSME, the case is sharper for a simple reason: the collection layer, whether it is a quality management module, an IoT retrofit, or an ERP implementation, typically represents a proportionally larger share of the technology budget than it would for a large enterprise, which means the opportunity cost of leaving it half used is proportionally larger too. A business that has already paid for accurate inspection data, accurate purchase order data, or accurate patient and operations data has already cleared the harder and more expensive threshold. The monitoring and analysis layer that turns that data into decisions is, in almost every engagement we have run, a smaller and faster investment than the collection layer that came before it, precisely because it is building on infrastructure that already exists rather than creating new infrastructure from nothing.
How Arsenal IT Consultants approaches this
Arsenal IT Consultants works across Odoo versions 17 through 19, ERPNext, SQL Server, and Docker based infrastructure to build exactly this second layer for manufacturing, healthcare, and services businesses, starting from an audit of what a client already captures rather than a proposal to capture more. The engagements referenced in this piece, an automotive component manufacturer’s quality dashboard, a 350 bed hospital’s clinical and operational reporting layer, and a railway material procurement system’s post purchase order visibility, are described here without naming the clients, consistent with how we publish this kind of work, but the underlying pattern, integrate, analyse, act, improve, repeats closely enough across industries that we are confident it will be recognisable to most operations, quality, or purchase leaders reading this. If the gap described here sounds like the one inside your own business, that first audit conversation, of what you are already collecting and where it currently goes unread, is usually the fastest way to find out how much value is sitting unused in systems you have already paid for.
Your Data. Our Expertise. A Stronger Tomorrow. That is the shortest way we know to describe this work, and it holds because it puts the client’s data first: we are rarely selling a company its first sensor or its first ERP module, we are building the people, process, and technology layer on top of what it already owns, for a stronger, more measurable tomorrow.
Sources referenced: India SME Forum, Digishaastra META Report Card 2025; IBM on sensor generated dark data; Splunk enterprise data usage research; American Society for Quality and related manufacturing research on Cost of Poor Quality; peer reviewed 2025 study on smart manufacturing readiness among Indian automotive SMEs (MDPI, Sustainability).
Related Arsenal ITC service: AI Implementation for SMEs. Need help on your own systems? Contact us.