Business Intelligence Management

01Purpose and scope

• This manual supports the course Business Intelligence Management. It describes how a business intelligence program is run day to day: how requests are taken in, how data is sourced and modeled, how reports and dashboards are built and retired, and how the people who depend on them are kept informed. It is written for managers, analysts who take on coordination work, and project leads who inherit a reporting estate that nobody fully owns.
• The scope covers the management layer rather than the technical details of any single tool. You will still need to understand SQL, extract and load patterns, and the basics of dimensional modeling, but this manual focuses on the decisions that determine whether those skills produce reports people trust and use. It applies to internal reporting teams in companies of many sizes, to shared service groups that serve several business units, and to embedded analytics teams inside a function such as sales or operations.
• Limits matter here. Business intelligence work often touches financial reporting, personal data, and regulatory submissions. Where that is the case, this guidance does not replace qualified professional judgment, your organization's approved procedures, or the authorization required for access to restricted data. Where rules depend on jurisdiction, consult the current authoritative source for your location and your legal or compliance function.

02Core principles

• Every report exists to support a decision or a recurring operational routine. When a manager cannot name the decision a dashboard informs, the dashboard is a candidate for retirement, not expansion. Start each request by asking what action the requester expects to take and how often they will look at the output.
• Single definitions beat clever calculations. If sales, finance, and operations each calculate active customers differently, the program will spend its energy arguing about numbers instead of using them. A governed metric dictionary, with an owner for each metric, is the most valuable artifact in most mature programs.
• Trust is earned slowly and lost quickly. A report that is wrong once in a leadership meeting can take months to recover from. Build reconciliation checks into the pipeline and make it easy for users to see where a number came from, including the source system, the load time, and any transformations applied.
• Keep the estate small enough to maintain. A typical team can keep a few dozen well-run reports current. Hundreds of abandoned workbooks create support load, conflicting answers, and security exposure. Retirement is a normal part of the job, not a failure.

03Planning and preparation

• Before taking on a program, or a major change to one, establish the inventory. List every recurring report, dashboard, extract, and scheduled distribution, along with its owner, its audience, its source tables, and its last known use. Most teams are surprised by how many items have no clear owner and how many were built for a person who has since changed roles. The inventory becomes the baseline for every later decision about consolidation, funding, and priority.
• Next, map stakeholders and their decisions. Interview a small number of executives, process owners, and power users. Ask what they decide each week, month, and quarter, what information they lack, and what they do today to fill the gap. Record the answers in a simple request register that captures the business question, the requester, the urgency, and the expected consumers. Avoid asking stakeholders to specify the visual design first. Their needs are usually clearer in terms of decisions and thresholds.
• Agree on the operating model before work starts. Decide whether the team is centralized, federated, or hybrid. A centralized team owns standards and delivery, which gives consistency but can create a queue. A federated model lets business units build their own content under shared rules, which is faster but needs strong governance to avoid duplicate metrics. A hybrid model is common: a central group owns core data, certified datasets, and standards, while domain analysts build local views on top.
• Confirm the platform and data foundation. Know which warehouse, semantic layer, and visualization tools are in use, who administers them, and what licensing limits apply. Check whether source systems can supply data on a schedule that matches stakeholder needs. A dashboard that refreshes once a day cannot support intraday staffing decisions, and a real-time feed built on an unstable source will generate alerts no one can act on.

04Recommended workflow

1. 1
   : Intake and triage. Log every request in the register with the decision it supports, the required timeliness, the audience, and a rough estimate of effort. Reject or defer requests that duplicate an existing certified report, and say so in writing with a pointer to the existing asset. Triage weekly with a small group that includes a business sponsor and a data owner.
2. 2
   : Define the metric and the grain. Before any build, write down each measure's formula, its inclusion rules, its time basis, and the level of detail at which it is reported. Ask the metric owner to sign off. Most rework in business intelligence traces back to a metric that was defined informally in a meeting and then implemented three different ways.
3. 3
   : Assess the source data. Profile the candidate tables for completeness, duplicate keys, late-arriving records, and changes in meaning over time. Document known gaps. If a source system overwrites history, decide whether the warehouse needs to capture snapshots. Record the source owner and the agreed service level for delivery.
4. 4
   : Design the model and the pipeline. Build or extend a dimensional model with conformed dimensions such as customer, product, and calendar where practical. Keep transformations in version-controlled code rather than in individual reports. Separate raw, cleansed, and presentation layers so that a change in one does not silently alter another.
5. 5
   : Build and test the output. Construct the dashboard or report on the certified dataset. Test against a sample of records traced back to source by hand. Compare totals to an independent figure from the source system or a finance control total, and record any accepted variance with its explanation. Check performance at realistic concurrency, not only on the developer's machine.
6. 6
   : Review and certify. Hold a review with the business sponsor and at least one intended end user who did not build the artifact. Confirm the labels, the thresholds, the filters, and the default view. Once approved, mark the asset as certified in the catalog with its owner, refresh schedule, and known limitations. Uncertified content should be visibly labeled so readers can tell the difference.
7. 7
   : Release, monitor, and retire. Publish with a short release note describing what changed and why. Set up monitoring for refresh failures, row count anomalies, and unusual usage patterns. Schedule a review date for each asset. When an asset falls out of use or is superseded, announce the retirement, keep it available in read-only form for a defined period, and then remove it from distribution.

05Quality checks, risk controls and compliance

• Quality checks should run automatically wherever possible. Useful controls include schema change detection on source tables, null rate thresholds on key fields, reconciliation of row counts and control totals between stages, and freshness checks that alert the owner when a load is late. Route alerts to a named on-call person rather than a shared mailbox nobody reads. Test that the alert actually fires by introducing a controlled fault in a non-production environment.
• Access control is a major risk area. Apply role-based permissions at the dataset level, not only at the dashboard level, because a user who can export the underlying table can bypass a dashboard filter. Mask or aggregate personal and sensitive fields for audiences that do not need them. Review access lists on a schedule and remove access promptly when people change roles or leave. Keep an audit trail of who changed a certified definition and when.
• Compliance obligations depend heavily on jurisdiction and industry. Privacy laws, retention rules, and sector regulations can restrict what data may be combined, how long it may be kept, and where it may be processed. Some regulated reports, such as those supporting financial statements, tax filings, or regulatory submissions, carry their own control frameworks and sign-off requirements. Confirm these with your legal, compliance, or audit function and follow the current authoritative guidance for your location. Do not treat a business intelligence tool's default settings as a compliance decision.
• Financial and performance-sensitive outputs deserve extra scrutiny. When a dashboard informs pricing, credit, staffing, or safety decisions, the consequences of an error are larger, and the review must include someone accountable for that decision. This guidance does not replace qualified professional judgment or the approval procedures that govern those decisions in your organization.

06Collaboration and documentation

• Good collaboration starts with clear roles. The business sponsor owns the question and accepts the value. The metric owner owns the definition. The data steward owns the quality of a source domain. The platform team owns infrastructure and access administration. The analyst or developer owns the build. Publish this map in the catalog so requesters know whom to contact, and revisit it when reorganizations happen.
• Documentation should be short, current, and close to the asset. For each certified dataset or dashboard, keep a one-page record that states its purpose, its owner, its sources, its refresh schedule, its metric definitions, its known limitations, and its change history. Store the record where users already look, such as the catalog or the dashboard description field, rather than in a separate wiki nobody maintains. Stale documentation is worse than none because it creates false confidence.
• Run a regular forum, such as a monthly governance meeting or a standing working session with power users, to surface definition conflicts, backlog priorities, and retirement candidates. Keep the agenda tight and record decisions. Where two business units disagree on a metric, escalate to the executive sponsor with a short options paper showing the figures under each definition. Do not let the disagreement sit unresolved in production reports.
• Training is part of collaboration. Many users read a dashboard incorrectly because they do not know what a filter does or why a number differs from a finance report. Offer short walkthroughs for new certified content and keep a searchable question channel with visible response times.

07Measures and continuous improvement

• Measure the program on outcomes and health, not only on output counts. Useful indicators include the share of requests closed with a decision recorded, the percentage of key reports refreshed on time, the number of reconciliation exceptions per month, the proportion of active users who rely on certified content, and the median time from request to certified release. Track trends rather than chasing single targets, and agree on baselines during planning. Do not publish benchmarks from other organizations as goals unless you can verify their basis.
• Usage data is informative but easy to misread. A dashboard with many views may be heavily used or merely confusing, so pair usage counts with short surveys or interviews. Look for reports that are opened but never filtered, which can suggest they answer the wrong question, and for exports that feed spreadsheets, which can indicate a missing capability in the official view.
• Improvement works best in small, dated cycles, which you can run without a formal calendar. Pick one pain point from the latest review, such as slow refresh on a key model, and test a fix. Keep the change if the measure improves and the owner agrees. Capture lessons in the team's working notes so that they survive personnel changes.
• Be honest about limits. Business intelligence cannot fix a source system that captures poor data, and a better dashboard will not resolve a disagreement about strategy. When the program reaches those limits, say so to the sponsor and redirect effort toward data capture or decision process changes.

08Common mistakes and how to prevent them

• Building before defining. Teams often start with the visualization and discover later that two stakeholders meant different things by the same label. Prevent this by requiring a signed metric definition before build begins, even when the definition is short.
• Letting extracts multiply. When analysts export data to spreadsheets for convenience, copies drift from the governed source and produce conflicting totals. Prevent this by making certified datasets easy to query, providing sanctioned extract paths with access controls, and reviewing shadow reports during the inventory cycle.
• Treating certification as permanent. A certified report can become wrong when a source system changes a code, a business unit reorganizes, or a regulation shifts. Prevent this with scheduled reviews and with change alerts tied to upstream systems.
• Ignoring the audience's workflow. A technically correct dashboard that does not fit the way people make decisions will be abandoned. Prevent this by observing users during a review session and adjusting filters, thresholds, and layout to match their routine.
• Overloading the team. Taking every request at once spreads capacity thin and slows everything. Prevent this by publishing the intake criteria and the current backlog, and by saying no or not yet with a reason.
• Underinvesting in monitoring. Failures discovered by executives on Monday morning damage credibility quickly. Prevent this with automated freshness and reconciliation checks that alert a named owner before business hours.

09Practical checklist

• Confirm the business decision, requester, and expected consumers for each request before build starts.
• Check the request register for duplicates and point requesters to existing certified assets where possible.
• Obtain a signed metric definition covering formula, inclusion rules, time basis, and grain.
• Profile source data and record known gaps, owners, and agreed delivery service levels.
• Build on certified, version-controlled datasets rather than on local copies or manual extracts.
• Reconcile totals to an independent control figure and document any accepted variance.
• Apply dataset-level access controls and remove access promptly when roles change.
• Confirm applicable privacy, retention, and sector rules with the compliance function for the jurisdiction involved.
• Hold a review with the sponsor and at least one end user who did not build the asset.
• Publish a release note, a one-page record, and the refresh schedule in the catalog.
• Set automated alerts for refresh failures and reconciliation exceptions with a named on-call owner.
• Schedule a periodic review and a retirement path for every certified asset.
• Track program health measures and review them in the governance forum with decisions recorded.

★Learning sources

• Micro Degree: Business Intelligence Management
• Micro Degree: Data Analytics Applications
• Micro Degree: Azure Cloud Fundamentals
• Micro Degree: Google Cloud Platform Basics