DEV Community: Seven Billion Analytics

What does BI consulting cost for a mid-size company in India?

Seven Billion Analytics — Wed, 28 Oct 2026 09:28:08 +0000

If you are a CFO or IT head at a company in the Rs 1,000 to 2,000 crore range, the first BI question is usually cost. The honest answer is that BI consulting cost depends on four things: scope, the number and state of your data sources, licences, and ongoing support.

Only licences have public list prices. In India, Microsoft lists Power BI Pro at Rs 1,165 and Premium Per User at Rs 1,995 per user per month, paid yearly, GST extra. Tableau lists Standard from $15 and Enterprise from $35 per user per month. Microsoft Fabric and Snowflake are priced by capacity or consumption, and Microsoft says a 1 or 3 year Fabric reservation can save about 41% against pay-as-you-go.

Services cost is different. It scales with data work, not with the number of dashboards. Most BI projects run in five phases: scoping, data foundation, build, rollout and support, and each should have its own deliverable and sign-off.

The full guide covers each licence with a link to the vendor's pricing page, the hidden costs worth budgeting for, and how to scope a BI RFP so quotes are comparable.

Read the full article on Seven Billion: https://www.sevenbillion.co/blog/bi-consulting-cost-india?utm_source=dev&utm_medium=social&utm_campaign=bi-consulting-cost-india

Before You Buy an AI Tool, Name the Owner of Your Item Master

Seven Billion Analytics — Wed, 21 Oct 2026 15:35:11 +0000

Ask a room of managers who owns the item master and watch what happens. Finance points at operations. Operations points at IT. IT says it only keeps the server running.

That silence tells you more about your AI readiness than any vendor demo.

The quiet file that runs everything

The item master is the list of every product you buy, make or sell. Each line has a code, a unit of measure, a supplier, a lead time. Forecasts read it. Reorder logic reads it. Dashboards group by it. If one product has three codes, the forecast sees three weak products instead of one strong one. If one plant counts in boxes and another in units, every total is wrong before any model runs.

Nobody notices this while people plan in spreadsheets, because people fix it by hand. They know that "SNK-01" and "SNACK 1" are the same thing. An AI system does not know that. It takes the data at its word.

Why ownership comes before tools

Clean data is not a one-time project. New items arrive every month. Suppliers change. Someone creates a duplicate code on a busy Friday. Without a named owner, the clean-up decays and the AI layer slowly starts giving confident wrong answers.

So the first readiness question is not "which model?" It is "who approves a new item code, and who fixes a bad one?" Give each master, items, customers and suppliers, one person with the authority to say no.

A small test you can run this week

Export your item list.
Sort by description and look for near-duplicates.
Check that each item has one unit of measure.
Write down who would fix what you find.

If step four is hard, you have found your first project. It is usually smaller than an AI project, and it pays back faster.

What changes once the backbone is in place

We saw this with a food-service distributor in India on Microsoft Dynamics NAV. Once live stock data could be trusted, forecasts could raise reorders inside the ERP. The distributor saw 18% less perishable wastage, a 96% fill rate and Rs 1.2 crore in added margin. The ERP was not replaced. The data in it was made reliable.

The full post covers the rest: a readiness checklist, how to tell a system of record from a system of conversation, and when to extend, upgrade or replace.

Read the full guide: ERP Readiness for AI: Why ROI Needs a Data Backbone

Abhijit Singh is CEO of Seven Billion Analytics, which builds enterprise AI, analytics and ERP systems for mid-size manufacturers and distributors.

Your BI Quote Is Really a Data Quote

Seven Billion Analytics — Wed, 21 Oct 2026 13:27:33 +0000

When a BI proposal arrives, most people turn to the dashboard list. How many reports, how many pages, how many charts. It feels like the thing you are buying.

It is the smallest part of the work. Dashboards are the last step of a long chain. The effort sits in the chain.

Where the hours actually go

Before a single chart exists, someone has to connect every source system, map codes that do not match, decide which number is the right one, and make the whole thing refresh without a person pressing a button. An old ERP without an API, a plant that keeps stock in a spreadsheet, a region that names products its own way: each one adds days. None of them shows up in a dashboard count.

So two quotes with the same report list can be far apart, and both can be honest. One bidder looked at your data. The other did not.

Five questions to ask every bidder

Which of our source systems did you assume, and how will you connect each one?
What data clean-up is in scope, and what do you expect our team to fix?
How often will each metric refresh?
Which costs are licences, and which are services?
What does support cost after go-live, and what does it cover?

If a bidder cannot answer the first question, the price is a guess.

Make the bidders compete on the same scope

Send every bidder the same list: the decisions you want to support, the metrics behind them, every source, refresh needs and who sees what. Then compare. You will learn more from how each bidder handles your messiest source than from any sample dashboard.

What good looks like

Good BI removes manual work. For a global food and beverage company, we built unified reporting and an executive command centre, with a 60% reduction in manual reporting effort. The reports were not the hard part. Joining the data behind them was.

The full guide covers licence pricing from official vendor pages, cost drivers, project phases, hidden costs and an RFP checklist for mid-size companies in India.

Read the full guide: BI Consulting Cost in India: A Mid-Size Buyer's Guide

Abhijit Singh is CEO of Seven Billion Analytics, a Snowflake and Salesforce partner that builds enterprise AI, analytics and ERP systems.

Write the ERP Demo Script Before You Meet a Single Vendor

Seven Billion Analytics — Wed, 21 Oct 2026 13:26:12 +0000

Most ERP shortlists are decided by the best demo, not the best fit. That is not the buyer's fault. A vendor demo is built to show the product at its strongest, on clean sample data, along a path the presenter has walked many times.

The fix is simple and rarely done: write the script yourself, before the first meeting.

What goes in a demo script

Pick the few processes that make or lose you money. For a mid-size manufacturer that is often order to delivery, the engineering change on a live order, month-end costing, or a multi-site stock transfer. For each one, write the steps your team actually follows, including the awkward ones.

Then add your own data. Ten real items with their real bills of material. A customer with odd credit terms. An order that changes after release. Ask every vendor to run the same script on the same data.

Why this works

A shared script turns three sales pitches into one comparison. You stop judging features and start judging fit. You also see how each product handles the exceptions that fill your planners' day. Clean happy paths look the same on every system. Exceptions do not.

It also exposes the partner, not only the product. The ERP brand matters less than the people who will configure it. Watch who asks good questions about your routings. Ask each partner for references near your plants, then call them.

Price the same scope

Ask every bidder to price the scripted scope, with licences, implementation, data migration and support listed separately. Quotes that cover different scopes cannot be compared, and the gaps usually show up later as change requests.

Then think about data

Whichever system wins, AI value after go-live depends on clean masters and same-day transactions. Put a data readiness review inside the project plan, not after it.

The full post compares Infor LN, SAP and Microsoft Dynamics on manufacturing depth, multi-site, India GST, partners and AI readiness, with every vendor claim linked to the vendor's own pages. It also has a decision tree for building a fair shortlist.

Read the full comparison: Infor LN vs SAP vs Dynamics for Mid-Size Manufacturers

Abhijit Singh is CEO of Seven Billion Analytics, which builds enterprise AI, analytics and ERP systems for mid-size manufacturers and distributors.

MRP Is Correct and Still Wrong: A Worked Example

Seven Billion Analytics — Wed, 14 Oct 2026 13:02:56 +0000

If you work on ERP integrations, you will meet MRP sooner or later. It is worth understanding exactly what it computes, because its blind spot explains a lot of support tickets from the shop floor.

Take an illustrative snack maker. The master production schedule says week 3 needs 11,000 cases of a 200 g pack. That figure came from a 12,000-case forecast, minus 2,000 in stock, plus a 1,000-case buffer.

MRP now runs three steps:

Explode the BOM. Each case needs 24 pouches of film, so 11,000 cases need 264,000 pouches.
Net against stock. There are 64,000 pouches on hand, leaving 200,000 to buy.
Offset by lead time. The supplier needs two weeks, so the purchase order releases two weeks before week 3.

Clean, deterministic, and correct. Now notice what is missing. Nothing in that calculation checks whether the packing line can run 11,000 cases in that week alongside everything else. Nothing knows that two big orders share a due date and pile onto Tuesday. Nothing prices the changeovers between flavours. MRP assumes infinite capacity and fixed lead times, on purpose.

Most ERPs add a rough-cut capacity check by work center and week. It might say packing is at 90%, which looks fine, while one day inside that week is badly overloaded. RCCP tells you a week is too full. It does not tell you which order to move.

Takeaway for developers: if you are building reports or alerts on ERP data, do not treat MRP planned orders as a schedule. They are material timing. A schedule needs a finite model where every resource has a calendar and setups are sequence-dependent. Label your dashboards accordingly and you will avoid a whole class of confused users.

That finite layer is what our finite capacity production scheduling accelerator adds, reading from the ERP and writing back only approved plans.

Full comparison of MPS, MRP and APS: MRP vs APS vs MPS: What Each Layer Decides

Scheduling Is a Constraint Problem Before It Is an AI Problem

Seven Billion Analytics — Wed, 14 Oct 2026 13:01:51 +0000

If you are a developer handed a "make our factory schedule smarter" ticket, the first instinct is often to reach for a model. Resist it for a moment. Production scheduling is mostly a constraint satisfaction problem, and the hard part is getting the constraints right.

Here is the shape of it. Inputs come from the ERP: production orders, routings, bills of materials, work-center calendars and stock. Then come the limits. Line capacity, shifts and operator skills, maintenance windows, tooling, material arrival dates, and sequence-dependent changeover times from a changeover matrix. Then the odd plant-specific rules. One dairy plant we built for had to respect blast-freezer curves, because a run that clashes with freezer capacity simply cannot happen.

The solver underneath is a constraint-programming and mixed-integer model (CP-SAT or MILP). Its job is not to find one perfect answer. It returns several feasible plans that trade changeovers against overtime against late orders, fast enough for a person to compare them. In that dairy case, a week of plans comes back in 90 seconds.

The key concept is finite capacity. Basic ERP logic usually assumes every machine has unlimited capacity, so it can load three weeks of work onto a line that has two. A finite model only places an operation where a resource actually has room, which is why its output can run as written.

Takeaway for builders: the most valuable artifact in these projects is often not code. It is the written list of rules that until now lived in a senior planner's head. Many of them have never been documented anywhere. Spend your first session extracting and encoding those rules, and the solver work gets much easier.

The approved plan then goes back to the ERP or MES with an audit trail, and the ERP stays the system of record. Our AI production scheduling page shows how that integration is structured.

Full walkthrough, step by step: How to Schedule Production with AI: A Guide

Designing RAG for Lawyers: Refusal Is a Feature

Seven Billion Analytics — Wed, 14 Oct 2026 13:01:36 +0000

Building retrieval-augmented generation for a law firm teaches you something general chat products tend to hide: the most important output is sometimes "I can't answer that."

The pattern itself is familiar. Ingest the firm's corpus (briefs, memos, contracts, matter files, playbooks), usually from SharePoint, iManage or a document store. Group it into matter workspaces. At query time, retrieve passages by meaning, then generate an answer only from what was retrieved, with a numbered citation per claim that links back to the source paragraph.

Three design choices matter more than model choice:

Semantic retrieval. Lawyers ask questions the way a partner would. "Who carries the risk if the platform leaks customer data" should surface indemnity and confidentiality clauses even if neither contains the word "leak." On one SEC filing search project, plain-English queries ran 3.4x faster than the 256-character Boolean strings analysts had been writing.
Hard refusal. If retrieval does not support an answer, the system says so and stops. Filling gaps with something plausible is exactly the behaviour you are designing out.
Human gate in the pipeline. Drafts come back as tracked changes with Accept or Reject per change. Nothing is filed or sent until an attorney signs off, and that event is logged.

Corpus condition also beats corpus size. Clean case law ingests quickly. Twenty years of scanned matter files need cleanup first, and that work shows up in the estimate.

Takeaway for engineers: write your evaluation set before you tune anything. Use research the firm's team already did by hand, measure precision and recall against it, and add missed-case audits on live work. Those numbers, not demo impressions, should decide whether the system goes to production.

For scope, integrations and how a build runs, see our custom legal AI for law firms service page.

Full step-by-step architecture: Custom Legal AI for Law Firms: How It Works