Implementation, Pricing & Consulting FAQs

The Fabric Starter Sprint is a fixed fee from USD 1,500 for a two-week proof of value. Larger builds are scoped to a fixed price after a short discovery, because cost tracks your estate — source count, whether sources are accessible or gated, plant and entity count — not a headline figure. We price against your real sources rather than guess before seeing them.

Two shapes: fixed-scope projects (a defined deliverable, timeline and price — typically the first slice) and a monthly Fractional Data Consultant / Chief Data Officer retainer for ongoing delivery and oversight. Both are directly accountable to Amit — no junior hand-off, no sales-engineering pyramid.

First working value in six weeks — a reconciled slice running in production and used by a named person, not a prototype in a demo workspace. The two-week Starter Sprint delivers a proof of value even sooner. We lead with the six-week timeline because it is the honest measure, not a 50-slide roadmap.

Discovery is a short, separately-terminable phase that ends with a fixed-price scope for the first slice — not bundled inside a twelve-month commitment made before any data is seen. A proportionate discovery narrows the build estimate from a wide band to a tight one; if it does not, it was not discovery.

Fixed scope for a well-defined first slice, because it forces genuine discovery and puts the estimation risk on us. Time-and-materials with a ceiling suits open-ended work where sources are gated and unknowns are high. Many programmes run fixed-price discovery and first slice, then a retainer for expansion.

Yes. The practitioner you speak with is the practitioner who builds — 14+ years of hands-on industrial data work, directly accountable, no offshore hand-off. That accountability is the model, and it is a fair question to put to any consultancy, us included.

Manufacturing, FMCG & Packaging, Supply Chain & Logistics, and EPC & Real Estate — across India, the GCC (UAE and Saudi Arabia), Singapore and Malaysia, the UK and North America, in that priority order. The domain depth is the point; we are not a generalist consultancy.

We will say so. If your sources are gated, your key metrics disputed, or nobody will own the platform after go-live, a diagnostic that concludes "not yet" — and states what has to be true first — saves you the build budget. We diagnose before we propose, every time.

A two-week sprint delivers a working slice — usually one region or channel of secondary sales, or an inventory view — modelled properly and reconciled to source, plus a Power BI dashboard replacing a manual report. The measurable outcome is a trusted number available days after the week closes instead of a manual pack assembled by an analyst.

Within the two weeks. SAP mirrors or pipelines into OneLake, distributor files and Excel land in Bronze, and are conformed for the sprint's scope. The pace depends on access — read credentials and, for on-premises sources, a gateway — which is why we send the access list before the sprint starts, not on day one.

One focused dashboard for the sprint scope — typically secondary sales and distribution, or inventory and days-of-cover. We deliberately do not attempt all three in two weeks; one dashboard that is trusted and used beats three that no one believes.

By replacing the analyst's Monday extract-and-paste with scheduled pipelines into a governed model and a Direct Lake dashboard, the sprint removes the manual assembly for its scope. Instrument the current effort first, so the recovered hours are evidence rather than a claim.

Usually the ERP (SAP or Dynamics), one or two distributor feeds, and any Excel that holds the current working logic. We scope the connections to what the sprint's one decision needs — a gated source that needs weeks of access work is flagged, not forced into a two-week window.

By scoping to one decision and one data slice, landing the sources, modelling to the grain the business argues about, and shipping one reconciled dashboard. The 14-day proof works because it is narrow and real, against your data — not a demo on sample data that was chosen to make the demonstration succeed.

A sprint dashboard delivers the KPIs for its one scope — for example sales volume and value, numeric distribution and days of stock for a secondary-sales slice — each defined once and reconciled to source. Trade promotion ROI needs structured scheme data, so it is a fuller engagement, not a two-week deliverable.

It automates the pipeline and serving for the reports in scope, so the pack refreshes without an analyst assembling it. The countable benefit is the weekly hours returned — we measure them before and after, so the reduction is a number, not an assertion.

Working ingestion pipelines, a governed semantic model for the scope, one production Power BI dashboard reconciled to source, and documentation of the data model and refresh. You own all of it — code in your own Git, running in your tenant — and a clear recommendation on what to build next.

Success is one reconciled, owned dashboard a named person uses to make a decision they previously made on a manual pack — and agreement on whether to proceed. Define the success criterion before the sprint starts, in the client's own words, so it is a test, not a feeling.

The sprint delivers one visibility slice — usually inventory health or OTIF for a defined scope — modelled from real ERP and WMS data and reconciled to source. The measurable improvement is a trusted, current view replacing a manual reconciliation, with agreement on whether to extend to the full chain.

One of them, done properly — most often inventory health or OTIF — rather than all three thinly. The scope is chosen by which number, if trusted and current, would change a weekly decision. The others follow in the extension, once the foundation and definitions are proven.

Scope to one decision, land ERP and WMS data into OneLake, conform the keys that let them join, and ship one reconciled dashboard in two weeks. The proof is quick because it is narrow and against your real data — the point is evidence to decide on, not coverage of the whole chain.

The KPIs for the sprint scope — for an inventory slice, days of cover, excess and shortfall by SKU and location; for an OTIF slice, on-time and in-full against one agreed definition. Each is reconciled to source, so the numbers are defensible from day one.

By delivering one trusted dashboard fast, the sprint gives operations and finance a shared number to decide against, which builds the confidence that a long roadmap never does. Adoption follows trust; trust follows a reconciled number someone acts on, not a demo.

Typically the ERP (SAP or Dynamics), the WMS, and any Excel holding current logic — scoped to what the sprint's decision needs. A gated source requiring weeks of access approval is flagged up front rather than squeezed into two weeks.

The sprint stands up the data foundation and one exception view that a control tower later builds on — proving the sources join and the definitions hold before committing to the full programme. It is the low-risk first step of a control-tower initiative, not the whole thing.

Ingestion pipelines for the in-scope sources, a governed semantic model, one production Power BI dashboard reconciled to source, and documentation. You own the code and the tenant, and receive a scoped recommendation for the next phase.

By conforming stock feeds into one model refreshed on schedule, the sprint replaces the manual stock reconciliation for its scope with a live view — cutting the reconciliation effort and surfacing excess and shortfall the manual process hid. The recovered hours are measured, not assumed.

Expect a proof of value: a trusted dashboard, reduced manual reporting effort for its scope, and a clear decision on whether the full build's benefits — better OTIF, less excess stock, fewer stockouts — justify it. The sprint's job is evidence to fund the next step, not the full ROI itself.

One operations dashboard for the sprint scope — typically on-time delivery and exceptions, or freight cost by lane — built from real TMS and carrier data and reconciled to source. Depth over breadth: one dashboard a coordinator acts on beats several nobody trusts.

Within the two weeks for the sprint scope. TMS exports, carrier files and Excel land in Bronze and are conformed to a shipment and lane model. The pace depends on carrier feed formats and access — which is why we agree the source list and access before the sprint begins.

The sprint is low-risk because it is fixed-fee, narrow and against your real data — one decision, one slice, one reconciled dashboard. You validate whether Fabric and the approach deliver before committing to a larger programme, and you own everything produced regardless of what you decide next.

The KPIs for the scope — for an operations slice, on-time delivery, exceptions and dwell; for a cost slice, freight cost per lane and rate variance. Each defined once and reconciled to source, so the dashboard is defensible from go-live.

By automating ingestion and serving for the in-scope reports, the sprint removes the weekly Excel assembly and gives coordinators today's exceptions this morning. Decision speed improves because the number arrives at the decision point; the recovered hours are measured before and after.

Typically the TMS, the ERP, and one or two carrier feeds, scoped to the sprint's decision. Carrier portals without APIs are handled via file or EDI ingestion; a source needing lengthy access approval is flagged rather than forced into the window.

It replaces the manual data preparation behind the in-scope operations and freight reports with scheduled pipelines and a certified model, returning hours to both teams. We instrument the current workload so the saving is a number you can take to a budget conversation.

Ingestion pipelines for the in-scope sources, a governed semantic model, one production Power BI dashboard reconciled to source, and documentation — all owned by you, in your own Git and tenant — plus a scoped recommendation for the wider logistics analytics programme.

Measure it against a success criterion set before the sprint: one reconciled dashboard a named person uses, and the manual hours it removes. The sprint proves value cheaply so leaders can decide, on evidence, whether the full transformation's ROI justifies it.

The sprint proves the sources join, the definitions hold and the team will use the output — de-risking the larger programme and giving it a working foundation to extend rather than a blank start. It turns a big, uncertain commitment into a sequence of proven slices.