Data Analytics and Business Intelligence
Give decision-makers answers they can verify.
Build reporting models, dashboards and analysis experiences grounded in governed, reconciled enterprise data.
Discuss this requirement →Start with the environment, risk and required outcome.
Build reporting models, dashboards and analysis experiences grounded in governed, reconciled enterprise data. Namandla Consultants begins with evidence and recommends a proportionate engagement rather than a generic technology package.
Connected expertise for the wider environment.
Clear steps. Visible decisions.
The problem with most BI deployments
Power BI licensing arrives with Microsoft 365 and reports start appearing. That is a good thing and it produces a specific problem within about eighteen months.
Every report connects directly to a source system, each with its own logic embedded in it. Twelve reports calculate revenue twelve times, in twelve slightly different ways, and all of them are defensible.
Nobody can say which is right, so the executive asks three people and gets three numbers. Confidence in the whole reporting layer degrades from there, and it degrades faster than it recovers.
The reports load slowly because each one queries the operational database directly, which also slows the operational database.
When a source system changes, an unknown number of reports break and nobody knows which until someone complains.
The fix is a semantic model. Business logic defined once, in one place, with every report reading from it. That single change resolves most of the above, and it is the difference between a BI deployment that matures and one that decays.
The semantic model and self-service analytics
A semantic model sits between the data and the reports. It holds the tables, the relationships, the measures and the business-friendly naming.
Measures defined once. Revenue, margin, headcount, on-time delivery. Written once, with the definition documented, used by every report.
Relationships defined once, so report authors do not each invent their own joins.
Business naming rather than source naming. A field called CUST_ACCT_STAT_CD is not usable by a business analyst. The model is where that becomes Customer Status.
Row-level security applied in the model, so a regional manager sees their region without maintaining separate reports per region.
This is what makes self-service analytics work rather than fail. Self-service against raw tables produces the twelve-definitions problem faster, because now more people are inventing logic. Self-service against a governed semantic model means people build their own views of numbers everyone agrees on, which is the actual goal.
What reporting should look like
Few reports, well used, rather than many reports, mostly ignored. Report sprawl is a reliable indicator that the semantic model is missing. Audit any mature deployment and a large share of reports have not been opened in months.
Designed for a decision
Every report should answer a question someone acts on. A report built because the data was available gets viewed twice.
Performance that does not annoy
A report taking thirty seconds to load gets abandoned regardless of how good it is. Aggregations, incremental refresh and a properly modelled dataset are what fix that, not more hardware.
A definition visible to the reader
A tooltip or a documentation page stating how a measure is calculated removes a large share of the disputes that otherwise reach the data team.
Refresh timing stated on the report
“As at 06:00 today” prevents the conversation where someone queries a number that is correct but from yesterday.
Platform and Power BI consulting
Power BI is the default recommendation in this market for a practical reason: most organisations already hold licensing through Microsoft 365 and the incremental cost is modest. Capability is more than adequate for mid-market analytical requirements.
The licensing distinctions worth understanding are Pro against Premium Per User against capacity-based licensing, because the cost profile changes substantially with user count and with whether you need paginated reports, larger datasets or wider sharing. That decision is worth making deliberately rather than discovering at renewal.
Other platforms where an organisation has an existing investment and the skills to go with it. We are not going to argue an organisation off a working platform.
Oracle Analytics and Financial Reporting where the data sits in an Oracle EPM environment, which our other practice covers directly. Covered on Oracle EPM and Hyperion services.
What Namandla delivers
Requirements taken from the decisions people are trying to make. Definition workshops. Semantic model design and build. Report and dashboard development. Row-level security. Performance tuning. Refresh scheduling and monitoring. Licensing review against actual use. Handover and training so your people can extend the model. Ongoing support under managed data services.
Remote delivery nationally. Onsite in Gauteng for workshops and training.
Common questions about Data Analytics & BI
What is the difference between data analytics and business intelligence?
Business intelligence is largely about reporting what happened, reliably and consistently. Data analytics extends into explaining why and estimating what is likely next.
In practice most South African mid-market organisations get considerably more value from getting business intelligence right than from moving to predictive analytics. A trusted, consistent view of what actually happened is a prerequisite for anything more advanced, and it is where most organisations still have ground to make up.
Do we need Power BI consulting or can we build it ourselves?
Report building is genuinely accessible and many organisations do it well. The part that usually needs help is the semantic model underneath, because that is where the governance lives.
The common pattern is an organisation building reports capably for eighteen months and then finding that twelve reports calculate the same measure differently. Getting the model right, then handing over report development to your own people, is usually the right split and it is how we prefer to work.
Why do our reports give different numbers?
Because each one connects directly to source data with its own logic embedded. Twelve reports calculating revenue twelve ways produces twelve defensible answers.
The fix is a semantic model with each measure defined once and every report reading from it. This is the single highest-value piece of work in most BI deployments and it is invisible to anyone looking only at the reports.
Our reports are slow. Do we need a bigger server?
Usually not. Slow reports are most often caused by querying source systems directly, an unmodelled dataset or measures written to iterate row by row rather than to aggregate.
Aggregation tables, incremental refresh and a properly designed model fix the large majority of performance complaints without any hardware. Where the underlying database genuinely is the constraint, that is covered on server and database infrastructure.
What is self-service analytics and does it work?
Self-service means business users build their own views rather than requesting reports. It works well on a governed semantic model and it fails on raw data.
Self-service against raw tables accelerates the inconsistent-definitions problem, because more people are now inventing logic independently. Against a governed model it does exactly what it should: people answer their own questions using numbers everyone has agreed on.
How many reports should we have?
Fewer than you have. Report sprawl is a reliable sign the semantic model is missing, and in most mature deployments a large share of reports have not been opened in months.
A useful exercise is to audit usage and retire anything unopened for six months. It is uncomfortable and it consistently reduces the estate substantially, which makes the remainder easier to maintain and easier to trust.
Can you work with our existing reports?
Yes. The usual approach is to build the semantic model, then point existing reports at it one at a time rather than rebuilding everything.
That is less disruptive and it surfaces the definition disagreements gradually rather than all at once. Where a report’s numbers change when it moves onto the governed model, that is a finding rather than a defect, and it is generally the moment the value of the exercise becomes obvious.
When do we not need a BI project?
When one system holds the data, its native reporting answers the questions and nobody is exporting to spreadsheets to combine things by hand.
Plenty of organisations are adequately served by the reporting built into their ERP. Adding a BI layer there produces a second place for numbers to live and a new opportunity for them to disagree. We will say so rather than scoping a project around it.