{"id":221,"date":"2026-10-11T06:41:32","date_gmt":"2026-10-11T05:41:32","guid":{"rendered":"https:\/\/arrowlancer.ma\/blog\/?p=221"},"modified":"2026-10-11T06:41:32","modified_gmt":"2026-10-11T05:41:32","slug":"bi-dashboard-adoption-morocco-2026-mistakes","status":"publish","type":"post","link":"https:\/\/arrowlancer.ma\/blog\/en\/bi-dashboard-adoption-morocco-2026-mistakes\/","title":{"rendered":"BI dashboard adoption Morocco: 4 mistakes to avoid in 2026"},"content":{"rendered":"

An auto parts distributor in Casablanca commissions eight Power BI screens: sales by product family, margin by customer, stock rotation, receivables ageing. Acceptance is signed with no reservations, training runs two hours, everyone leaves with a login. Six weeks later the sales director still builds his Monday meeting from an Excel export he cleans by hand, and the management accountant is back on his own margin file.<\/p>\n

The case is a composite, assembled from situations that recur rather than taken from one client, but the failure mode is real and common. BI projects almost never die on a technical defect. They die because a few weeks after go-live, nobody has a compelling reason to open the thing.<\/p>\n

The four causes behind that are visible before signature, and each one turns into either a clause in the quote or a check you run 30 days after go-live.<\/p>\n

Three months in, Excel is back<\/h2>\n

The drift back to spreadsheets happens gradually. Someone “checks” a dashboard number in Excel, then keeps the checking file because it filters faster, then runs the meeting off that file. A quarter later the dashboard has one remaining function: reassuring management that it exists.<\/p>\n

What makes this hard to spot is that an abandoned dashboard generates no tickets. The provider hears nothing and reads the silence as success. Meanwhile a connection drops, a default filter stays stuck on last year, a new item family created in the ERP maps to no grouping. Nobody reports any of it, because nobody depends on it.<\/p>\n

Tool choice has very little to do with it. The Excel versus Power BI<\/a> argument belongs before the project starts. When the spreadsheet comes back after delivery, the problem is no longer a tooling problem.<\/p>\n

The deliverable is the decision, not the dashboard<\/h2>\n

If you want to know why a dashboard fails, the answer is almost always in the sentence that never made it into the spec: which decision is this screen supposed to support, who makes it, and at what point in the week or the month.<\/p>\n

\"BI<\/p>\n

A usable formulation looks like this: “Monday 9am, sales committee, decide which customers to chase this week.” That sentence constrains everything else. It forces the data to be current on Monday morning, not Tuesday. It forces a ranked customer list rather than a revenue curve. It names a specific user instead of “management”.<\/p>\n

The reverse holds too. A metric that feeds no identified decision does not need to be built. That is unwelcome news after three workshops spent defining it, but it will cost more to maintain than it ever returns.<\/p>\n

Mistake 1: building the request instead of the decision<\/h2>\n

A client asks for “revenue by sales rep by month”. The provider delivers exactly that, correctly. The real question behind the request was which reps are behind their annual target and how much time they have left to catch up. That is a different screen. The first one gives history, the second one needs a target, a time pro rata and a gap.<\/p>\n

An experienced provider asks twice: what you want to see, then what you will do differently depending on what you see. When there is no answer to the second question, that belongs in the scoping conversation, not in acceptance testing.<\/p>\n

Mistake 2: nobody owns the dashboard after go-live<\/h2>\n

In most BI quotes the provider’s responsibility ends when the acceptance report is signed. On the client side it often never started. So when the chart of accounts changes, when a rep leaves, when the ERP adds a field or a new product line appears, nobody has the mandate to update the model.<\/p>\n

The owner has to be a named internal person, written into the quote or the scoping minutes. The job itself is small: validate the numbers once a month, arbitrate requests for new metrics, escalate the gaps they cannot explain, and delete the screens nobody uses. Roughly an hour a month, owned by somebody with standing on the subject.<\/p>\n

A management accountant usually fits this role better than an IT manager, because the question that kills adoption is a question of definitions, not of queries.<\/p>\n

Mistake 3: the numbers contradict what people already calculate<\/h2>\n

This is the brutal one. The day the sales director sees MAD 4.2m on the screen and MAD 4.35m in his file, he does not go looking for the explanation. He goes back to his file. And he is right to be suspicious, because a single unexplained gap is enough to discredit the other seven screens.<\/p>\n

Almost always the gap is not a calculation error but a definition difference. Is revenue invoiced or collected? Are credit notes deducted from the month of the original invoice or the month of the credit note? Are end-of-year rebates accrued into monthly margin? Are foreign-currency invoices converted at the daily rate or the closing rate? Invoice date or delivery date?<\/p>\n

The countermeasure is a boring, decisive document: a metric dictionary, one line per KPI, with the plain-language definition, the source, the calculation rule and the exclusions. Then a reconciliation step, where across three closed months the screen and the legacy file land on the same amount or the gap gets explained in writing. That is precisely what a data quality audit before a BI project<\/a> is meant to surface, and it is also where most source integration timelines<\/a> slip.<\/p>\n

Mistake 4: too many KPIs, no hierarchy<\/h2>\n

A dashboard in a Moroccan SME does not need forty KPIs to be useful, and it becomes unreadable long before it gets there. When a screen shows twenty numbers in the same size, the reader cannot tell which one to look at first, so they look at none of them.<\/p>\n

The rule that survives contact with real users: a first page with five to seven numbers at most, the ones that trigger an action, each with a comparison (target, previous month, same month last year). Everything else lives one click down. Scoping workshops naturally produce a list of thirty metrics, and the provider’s job is to cut it rather than ship it.<\/p>\n

Quick test: if you cannot say straight away what you would do tomorrow morning depending on a metric’s colour, it does not belong on the first page.<\/p>\n

BI dashboard adoption Morocco: what to write into the quote<\/h2>\n

All four points are negotiable before signature, and usually at the same budget, because they move effort around rather than adding it. What to get in writing:<\/p>\n