پروژه نهایی End-to-End Power BI و نقشه راه حرفه‌ای BI

شروع فصل آخر؛ حالا باید همه‌چیز را به هم وصل کنیم

در ۴۹ جلسه قبل تقریباً تمام قطعات اصلی Power BI را جداگانه یاد گرفتیم. اما در پروژه واقعی کسی به ما نمی‌گوید «امروز فقط DAX بزن». مسئله از یک سؤال کسب‌وکاری شروع می‌شود و باید تا داده، مدل، امنیت، Performance، انتشار و Governance جلو برویم.

پس این فصل یک Capstone واقعی است: طراحی یک سامانه تحلیلی سازمانی برای شرکت فرضی «شرکت هانا»؛ شرکتی با فروش، تولید، انبار، مشتری، محصول و چند شعبه.

۵۰.۱. مسئله کسب‌وکار

مدیریت شرکت هانا می‌گوید: «عدد زیاد داریم ولی نمی‌دانیم واقعاً چه خبر است.» فروش عدد خودش را دارد، مالی عدد خودش، تولید Excel خودش و مدیرعامل هر جلسه مجبور است بپرسد کدام عدد درست است.

هدف پروژه این است که یک Single Source of Truth تحلیلی بسازیم.

۵۰.۲. سؤال‌های مدیریتی

۵۰.۳. Requirement قبل از Dashboard

اول سؤال را روشن می‌کنیم، بعد Visual انتخاب می‌کنیم. شروع از رنگ و نمودار یکی از اشتباه‌های رایج پروژه BI است.

۵۰.۴. Business Requirement Document

Project: Hana Enterprise Analytics
Business Owner: CEO / CFO / Sales Director
Critical KPIs: Net Sales, Gross Profit, Margin %, Target Achievement, OTIF
Refresh SLA: 07:00 daily
Security: Branch/Area level
Critical reports: Executive, Sales, Finance, Operations

۵۰.۵. KPI Definition Workshop

قبل از نوشتن DAX، Business باید تعریف KPI را تأیید کند. مثلاً Net Sales دقیقاً بعد از کدام برگشتی و تخفیف محاسبه می‌شود؟

۵۰.۶. KPI Contract

۵۰.۷. معماری End-to-End

ERP + CRM + Production + Excel Targets
                ↓
        Ingestion / ETL
                ↓
      Warehouse / Lakehouse
                ↓
   Star Schema / Gold Layer
                ↓
       Semantic Model
                ↓
      Power BI Reports
                ↓
 App / Embedded / Management

۵۰.۸. Source Inventory

۵۰.۹. Data Profiling

قبل از مدل‌سازی باید Null، Duplicate، Range، Invalid Date و Keyهای ناسازگار را بررسی کنیم.

۵۰.۱۰. Data Quality Gate

Source received
→ schema valid?
→ key uniqueness valid?
→ required columns complete?
→ business rules passed?
→ publish trusted layer

۵۰.۱۱. Grain

مهم‌ترین سؤال مدل: هر Row دقیقاً نماینده چیست؟ برای FactSales می‌تواند «یک ردیف فاکتور برای یک محصول» باشد.

۵۰.۱۲. Star Schema

DimDate ─────┐
DimCustomer ─┤
DimProduct ──┼── FactSales
DimBranch ───┤
DimSalesRep ─┘

۵۰.۱۳. FactSales

۵۰.۱۴. Dimensions

Dimensionها زبان تحلیل هستند: مشتری، محصول، تاریخ، شعبه، فروشنده و منطقه. Attributeهای مناسب باعث می‌شوند Business بدون SQL بتواند سؤال بپرسد.

۵۰.۱۵. Date Table

Date Table استاندارد برای YTD، MTD، PY، YoY و تحلیل‌های زمانی ضروری است.

۵۰.۱۶. Relationship

Relationshipها را ساده، قابل فهم و عمدتاً One-to-Many از Dimension به Fact نگه می‌داریم و از پیچیدگی بی‌دلیل جلوگیری می‌کنیم.

۵۰.۱۷. Power Query

در Power Query کارهای Source-level مثل انتخاب Column، Type، Cleaning و Transformation مناسب را انجام می‌دهیم و Query Folding را تا حد ممکن حفظ می‌کنیم.

۵۰.۱۸. لایه‌بندی Transformation

Staging → Clean → Business-ready → Semantic Model

۵۰.۱۹. Measureهای پایه

Net Sales =
SUM(FactSales[GrossAmount])
- SUM(FactSales[Discount])
- SUM(FactSales[ReturnAmount])

Gross Profit =
[Net Sales] - SUM(FactSales[CostAmount])

Gross Margin % =
DIVIDE([Gross Profit], [Net Sales])

۵۰.۲۰. Time Intelligence

Sales YTD =
TOTALYTD([Net Sales], DimDate[Date])

Sales PY =
CALCULATE([Net Sales], SAMEPERIODLASTYEAR(DimDate[Date]))

YoY % =
DIVIDE([Net Sales] - [Sales PY], [Sales PY])

۵۰.۲۱. Target

Target Achievement % =
DIVIDE([Net Sales], [Sales Target])

۵۰.۲۲. DAX Layering

Measureهای پایه را بساز، بعد Measureهای ترکیبی را روی آن‌ها قرار بده. این روش نگهداری و Debug را ساده‌تر می‌کند.

۵۰.۲۳. Naming

۵۰.۲۴. Executive Dashboard

صفحه Executive باید در چند ثانیه وضعیت را منتقل کند: KPI اصلی، Trend، Variance، Top Problem و امکان Drill-through.

۵۰.۲۵. طرح متنی Executive

+--------------------------------------------------+
| Net Sales | Margin % | Target % | YoY %           |
+--------------------------------------------------+
| Monthly Sales & Target Trend                      |
+-------------------------+------------------------+
| Sales by Region         | Top/Bottom Products    |
+-------------------------+------------------------+
| Exceptions / Alerts / Last Refresh               |
+--------------------------------------------------+

۵۰.۲۶. Sales Dashboard

Sales Manager باید بتواند Region، Branch، Product، Customer و Sales Rep را تحلیل کند و از Summary به Detail برسد.

۵۰.۲۷. Finance Dashboard

Finance روی Revenue، Cost، Margin، Budget Variance و Trend تمرکز می‌کند.

۵۰.۲۸. Operations Dashboard

Production Plan، Actual Production، Downtime، Quality و Delivery KPIها را پوشش می‌دهد.

۵۰.۲۹. Drill-through

از Executive به Branch Detail و از Customer KPI به Customer 360 می‌رویم؛ کاربر نباید برای هر سؤال یک Report جدا باز کند.

۵۰.۳۰. Tooltip

Tooltip برای Context اضافه خوب است، ولی اطلاعات حیاتی را فقط داخل Tooltip مخفی نکن.

۵۰.۳۱. UX

رنگ باید معنی داشته باشد؛ مثلاً وضعیت بحرانی، هشدار و مطلوب. تعداد Visual را محدود کن و فضای سفید را دشمن فرض نکن.

۵۰.۳۲. Mobile

صفحات مهم را برای Mobile Layout بازطراحی کن؛ کوچک کردن نسخه Desktop کافی نیست.

۵۰.۳۳. Accessibility

Contrast، عنوان روشن، Tab Order و توضیح مناسب را در Report رسمی رعایت کن.

۵۰.۳۴. RLS

Branch Manager فقط شعبه خودش، Area Manager منطقه خودش و CEO کل سازمان را می‌بیند.

۵۰.۳۵. Security Mapping

۵۰.۳۶. Dynamic RLS

SecurityUserScope
UserEmail | ScopeType | ScopeKey
--------------------------------
area1@hana | AREA   | 1
b12@hana   | BRANCH | 12

۵۰.۳۷. Security Test

فقط با حساب Admin تست نکن. CEO، Area Manager، Branch Manager و Unknown User باید Test Case داشته باشند.

۵۰.۳۸. Performance Budget

۵۰.۳۹. Performance Analyzer

Visualهای کند را پیدا می‌کنیم، سپس DAX، Model، Cardinality و Source را بررسی می‌کنیم.

۵۰.۴۰. Model Optimization

ستون غیرضروری حذف، Data Type کوچک‌تر، Cardinality کنترل، Star Schema حفظ و Calculated Columnهای غیرضروری کم می‌شوند.

۵۰.۴۱. Incremental Refresh

برای Fact بزرگ لازم نیست همیشه تمام تاریخ را دوباره Refresh کنیم؛ Strategy باید متناسب با Source و SLA طراحی شود.

۵۰.۴۲. Gateway

اگر Source On-premises است، Gateway بخشی از Production Architecture و SLA است و باید Monitoring و Ownership داشته باشد.

۵۰.۴۳. Refresh Chain

ETL success
→ Data quality validation
→ Semantic model refresh
→ Refresh validation
→ Executive report ready
→ Alert on failure

۵۰.۴۴. DEV/UAT/PROD

۵۰.۴۵. Git و PBIP

در پروژه تیمی از Source Control، Commit معنادار، Branch و Review استفاده می‌کنیم تا تغییرات قابل رهگیری باشند.

۵۰.۴۶. Release Flow

Ticket → Feature branch → Review → DEV → QA → UAT approval → PROD → Smoke test

۵۰.۴۷. Rollback

قبل از Production باید نسخه پایدار قبلی و مسیر بازگشت مشخص باشد.

۵۰.۴۸. Governance

هر Report رسمی Owner، SLA، Security Classification، Support Contact و Lifecycle دارد.

۵۰.۴۹. KPI Catalog

۵۰.۵۰. Certified Semantic Model

Reportهای Self-Service سازمان بهتر است تا جای ممکن روی Semantic Modelهای رسمی و قابل اعتماد ساخته شوند.

۵۰.۵۱. CoE

CoE استاندارد، Template، Training، Review و Governance را هدایت می‌کند؛ هدفش متوقف کردن کاربران نیست، بلکه ساخت مسیر امن برای رشد BI است.

۵۰.۵۲. Adoption

Report موفق فقط Report فنی خوب نیست؛ باید استفاده شود. Active User، Repeat Usage، Feedback و Duplicate Reportها را اندازه بگیر.

۵۰.۵۳. Fabric Option

اگر سازمان به معماری گسترده‌تر نیاز دارد، Sourceها می‌توانند از Data Factory به OneLake و Lakehouse/Warehouse وارد شوند و سپس Semantic Model و Power BI روی لایه قابل اعتماد ساخته شوند.

۵۰.۵۴. معماری Fabric پروژه

ERP / CRM / MES
      ↓
Data Factory
      ↓
Bronze → Silver → Gold
      ↓
Lakehouse / Warehouse
      ↓
Semantic Model
      ↓
Power BI

۵۰.۵۵. Embedded Option

اگر شرکت هانا یک Portal داخلی React + ASP.NET Core داشته باشد، Dashboard را می‌توان در سناریوی مناسب به شکل Embedded داخل همان Portal نمایش داد.

۵۰.۵۶. معماری Embedded

React Portal
    ↓
ASP.NET Core API
    ↓
Identity + Power BI Integration
    ↓
Semantic Model + RLS
    ↓
Embedded Report

۵۰.۵۷. Observability

Refresh Failure، Query Performance، Gateway، Capacity، API Integration و Usage باید قابل Monitoring باشند.

۵۰.۵۸. Incident Runbook

۵۰.۵۹. Documentation Pack

/docs
  architecture.md
  data-dictionary.md
  kpi-catalog.md
  security-model.md
  refresh-runbook.md
  release-checklist.md
  support-runbook.md

۵۰.۶۰. Definition of Done

۵۰.۶۱. Portfolio خروجی پروژه

اگر برای استخدام یا فریلنس Portfolio می‌سازی، فقط Screenshot Dashboard نگذار. Problem، Architecture، Model، DAX، Security، Performance و نتیجه Business را نشان بده.

۵۰.۶۲. Case Study ساختار

1. Business problem
2. Data sources
3. Architecture
4. Data model
5. Key DAX
6. Dashboard UX
7. Security
8. Performance
9. Deployment
10. Business outcome

۵۰.۶۳. مسیر شغلی Power BI Analyst

تمرکز بیشتر روی Requirement، Power Query، مدل‌سازی، DAX، Visualization و Business Analysis است.

۵۰.۶۴. مسیر Power BI Developer

علاوه بر موارد Analyst، روی Semantic Model، Performance، Deployment، Security، Git/PBIP و Integration عمیق‌تر می‌شود.

۵۰.۶۵. مسیر BI Engineer

SQL، Data Warehouse، ETL/ELT، Fabric/Data Engineering، Automation، Semantic Layer و عملیات Production اهمیت بیشتری پیدا می‌کنند.

۵۰.۶۶. مسیر BI Architect

معماری End-to-End، Governance، Security، Capacity، Domain Design، CoE و تصمیم‌های Platform در مرکز کار قرار می‌گیرند.

۵۰.۶۷. ماتریس مهارت

۵۰.۶۸. نقشه راه ۳۰ روزه بعد از کتاب

۵۰.۶۹. هفته اول

یک Dataset واقعی انتخاب کن؛ Requirement بنویس، Star Schema بساز و ۱۵ Measure اصلی ایجاد کن.

۵۰.۷۰. هفته دوم

Time Intelligence، Dynamic Measures، RLS و Performance را روی همان پروژه پیاده کن.

۵۰.۷۱. هفته سوم

DEV/UAT/PROD، Git/PBIP، Release Checklist، KPI Catalog و Documentation را اضافه کن.

۵۰.۷۲. هفته چهارم

پروژه را مثل یک Case Study حرفه‌ای ارائه کن؛ ۱۰ دقیقه Presentation برای مدیر یا مصاحبه‌گر آماده کن.

۵۰.۷۳. سؤال‌هایی که باید بتوانی جواب بدهی

چرا Star Schema؟

فرق Measure و Calculated Column چیست؟

Filter Context چه می‌کند؟

چرا یک DAX کند است؟

RLS را چگونه تست می‌کنی؟

Import یا DirectQuery؟

Refresh SLA را چطور طراحی می‌کنی؟

چطور یک KPI را Govern می‌کنی؟

PBIP و Git چه ارزشی دارند؟

Fabric چه زمانی ارزش دارد؟

۵۰.۷۴. پروژه نهایی دانشجو

یک شرکت واقعی یا فرضی انتخاب کن و حداقل چهار Source، سه Fact/موضوع تحلیلی، شش Dimension، ۲۰ Measure، سه صفحه Report، RLS، Performance Test و Deployment Plan بساز.

۵۰.۷۵. تحویل پروژه نهایی

۵۰.۷۶. معیار ارزیابی

۵۰.۷۷. سطح حرفه‌ای واقعی

حرفه‌ای بودن یعنی وقتی عدد اشتباه شد بتوانی مسیر Source تا KPI را Trace کنی؛ وقتی Report کند شد دلیلش را پیدا کنی؛ وقتی کاربر جدید آمد امنیتش را درست اعمال کنی؛ و وقتی تغییر جدید خواستند بدون ترس Release کنی.

۵۰.۷۸. چیزی که نباید بعد از ۵۰ جلسه انجام بدهی

Dashboard را قبل از فهم مسئله نساز.

همه چیز را در یک Flat Table نریز.

DAX را بدون فهم Context کپی نکن.

امنیت را با Filter اشتباه نگیر.

Production را محل آزمایش نکن.

هر تیم را مجبور نکن KPI خودش را دوباره بسازد.

Performance را به آخر پروژه موکول نکن.

۵۰.۷۹. چک‌لیست نهایی یک پروژه Enterprise

Business ✓
Data quality ✓
Star schema ✓
DAX ✓
UX ✓
RLS ✓
Performance ✓
Refresh/Gateway ✓
DEV-UAT-PROD ✓
Git/ALM ✓
Governance ✓
Monitoring ✓
Documentation ✓
Adoption ✓

۵۰.۸۰. پایان دوره

اگر این ۵۰ جلسه را فقط خوانده باشی، اطلاعات زیادی داری؛ اما اگر پروژه نهایی را واقعاً بسازی، تازه دانش تبدیل به مهارت می‌شود.

هدف نهایی Power BI ساخت نمودار قشنگ نیست؛ هدف این است که داده خام را به تصمیم قابل اعتماد تبدیل کنیم.

جمع‌بندی نهایی کتاب

Raw Data
   ↓
Trusted Data
   ↓
Good Model
   ↓
Correct Measures
   ↓
Clear Story
   ↓
Secure & Fast Delivery
   ↓
Governed Adoption
   ↓
Better Decisions

با این فصل، مسیر ۵۰ جلسه‌ای کتاب Power BI کامل می‌شود. قدم بعدی منطقی، ساخت یک نسخه یکپارچه از کل کتاب، فهرست مطالب، واژه‌نامه، پروژه نهایی، چک‌لیست‌ها و نسخه آماده انتشار است.