پروژه جامع End-to-End؛ ساخت یک راهکار واقعی Power BI از صفر تا تحویل

کتاب جامع Power BI — آموزش پروژه‌محور، تصویری و کاربردی

مقدمه؛ حالا همه قطعات را کنار هم می‌گذاریم

تا اینجا Power Query، مدل‌سازی، DAX، Time Intelligence، طراحی داشبورد، Service، امنیت، Performance، Governance و معماری Enterprise را جداگانه یاد گرفتیم. در این فصل قرار است مثل یک پروژه واقعی همه این قطعات را به هم وصل کنیم.

سناریوی ما همان شرکت فرضی «شرکت هانا» است؛ شرکتی با چند شعبه، چند گروه محصول، فروشندگان متعدد و مدیرانی که می‌خواهند فروش، سود، هدف و روند عملکرد را یک‌جا ببینند.

۱۴.۱. چرخه کامل پروژه

شکل ۱۴-۱ — مسیر End-to-End پروژه Power BI

نکته مهم این است که پروژه از نمودار شروع نمی‌شود؛ از سؤال کسب‌وکار شروع می‌شود و بعد به داده، مدل، محاسبه، تجربه کاربری و استقرار می‌رسد.

۱۴.۲. جلسه اول با مدیر

مدیرعامل می‌گوید: «می‌خوام بدونم فروش‌مون چقدره، نسبت به پارسال چه وضعی داریم، کدوم شعبه عقب افتاده و کدوم محصول سود خوبی نمی‌ده.»

این جمله خام را باید به سؤال‌های تحلیلی قابل اندازه‌گیری تبدیل کنیم.

۱۴.۳. استخراج سؤال‌های کسب‌وکار

۱۴.۴. KPI Definition قبل از DAX

قبل از نوشتن Measure باید تعریف رسمی KPIها را از مالک کسب‌وکار بگیریم.

Total Sales = approved net sales
Profit = Sales - Approved Cost
Achievement % = Actual Sales / Target

اگر تعریف فروش مبهم باشد، DAX دقیق هم خروجی قابل اعتماد نمی‌سازد.

۱۴.۵. شناسایی منابع داده

در پروژه واقعی برای هر Source باید Owner، Refresh Frequency و کیفیت داده هم مشخص شود.

۱۴.۶. Grain داده فروش

تصمیم می‌گیریم هر ردیف FactSales نماینده یک ردیف سفارش باشد.

One row = one order line

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

۱۴.۷. Power Query؛ مرحله آماده‌سازی

در Power Query ستون‌های لازم را انتخاب می‌کنیم، نوع داده را اصلاح می‌کنیم، رکوردهای نامعتبر را بررسی می‌کنیم و کلیدهای مورد نیاز را آماده می‌کنیم.

Source
→ Select columns
→ Fix data types
→ Handle nulls/errors
→ Standardize keys
→ Load

۱۴.۸. Data Quality Gate

قبل از Load چند کنترل مهم داریم: OrderID خالی نباشد، ProductKey معتبر باشد، مبلغ فروش با نوع تراکنش سازگار باشد و BranchKey در مرجع شعب وجود داشته باشد.

نکته: داده خراب را فقط برای اینکه Refresh سبز شود پنهان نکن؛ علتش را مشخص کن.

۱۴.۹. مدل ستاره‌ای پروژه

شکل ۱۴-۲ — مدل تحلیلی پیشنهادی شرکت هانا

FactSales در مرکز است و Dimensionهای تاریخ، محصول، مشتری، شعبه و فروشنده اطراف آن قرار می‌گیرند. Target هم بر اساس Grain خودش مدل می‌شود.

۱۴.۱۰. Date Table

برای تحلیل زمانی یک Date Table استاندارد می‌سازیم تا Year، Quarter، Month و محاسبات YTD/YoY قابل اتکا باشند.

DimDate
Date | Year | Quarter | MonthNo | MonthName

۱۴.۱۱. Measureهای پایه

Total Sales = SUM(FactSales[SalesAmount])
Total Cost = SUM(FactSales[CostAmount])
Profit = [Total Sales] - [Total Cost]
Profit % = DIVIDE([Profit], [Total Sales])

Measureهای پایه را ساده نگه می‌داریم تا در محاسبات بعدی دوباره استفاده شوند.

۱۴.۱۲. Target و Achievement

Total Target = SUM(FactTarget[TargetAmount])
Achievement % = DIVIDE([Total Sales], [Total Target])

بعد بررسی می‌کنیم Target در چه Grainی ذخیره شده تا جمع آن اشتباه نشود.

۱۴.۱۳. رشد سالانه

Sales LY =
CALCULATE([Total Sales], SAMEPERIODLASTYEAR(DimDate[Date]))

YoY Growth % =
DIVIDE([Total Sales]-[Sales LY], [Sales LY])

این Measure باید روی Date Table صحیح تست شود.

۱۴.۱۴. سؤال مدیر را به Visual تبدیل کن

۱۴.۱۵. صفحه Executive

HEADER: Executive Sales Dashboard

[Sales] [Profit] [YoY] [Achievement]

[Monthly Sales vs Target]

[Branch Ranking] [Product Profitability]

[Date] [Region]

این صفحه برای پاسخ سریع مدیرعامل است؛ جدول تراکنش‌ها را اینجا نمی‌آوریم.

۱۴.۱۶. صفحه Branch Analysis

در این صفحه فروش، هدف، رشد، سود و فروشندگان هر شعبه بررسی می‌شوند. مدیر باید بتواند از رتبه‌بندی شعبه به جزئیات همان شعبه Drill Through کند.

۱۴.۱۷. صفحه Product Analysis

برای هر Product یا Category، Sales، Quantity، Profit Margin و Trend را نشان می‌دهیم. محصول پرفروش الزاماً پرسودترین محصول نیست.

۱۴.۱۸. Tooltip و Context

روی Branch Tooltip می‌توان Sales، Profit، YoY و Achievement را نمایش داد تا بدون شلوغ کردن صفحه اطلاعات بیشتری در دسترس باشد.

۱۴.۱۹. Dynamic Title

Selected Branch Title =
"تحلیل فروش شعبه: " & SELECTEDVALUE(DimBranch[BranchName], "همه شعب")

عنوان پویا کمک می‌کند کاربر همیشه Context فیلتر را بفهمد.

۱۴.۲۰. امنیت پروژه

مدیرعامل همه شعب، مدیر منطقه شعب خودش و مدیر شعبه فقط شعبه خودش را می‌بیند. برای این سناریو Dynamic RLS طراحی می‌کنیم.

SecurityUserBranch
UserEmail | BranchKey

Rule:
SecurityUserBranch[UserEmail] = USERPRINCIPALNAME()

۱۴.۲۱. تست امنیت

۱۴.۲۲. Performance Audit

قبل از تحویل، Performance Analyzer را اجرا می‌کنیم، Visualهای کند را پیدا می‌کنیم و مدل را از نظر ستون‌های اضافی، Cardinality و Measureهای سنگین بررسی می‌کنیم.

Benchmark → Optimize → Re-test

۱۴.۲۳. طراحی Mobile

نسخه موبایل را جداگانه می‌چینیم: KPIها بالا، Trend بعد از آن، رتبه شعب پایین‌تر و فیلترها ساده و قابل لمس.

نسخه Desktop را فقط کوچک نمی‌کنیم.

۱۴.۲۴. آماده‌سازی Service

Workspaceهای مناسب، Semantic Model، Report و App را مشخص می‌کنیم. اگر SQL داخل شبکه باشد، Gateway را روی زیرساخت پایدار تنظیم می‌کنیم.

۱۴.۲۵. مسیر تحویل کنترل‌شده

شکل ۱۴-۳ — مسیر مفهومی Dev تا مصرف کاربر

تغییرات را در Development می‌سازیم، تست می‌کنیم و بعد به محیط رسمی می‌بریم. Production جای آزمایش مستقیم نیست.

۱۴.۲۶. Refresh Plan

زمان دقیق باید با نیاز واقعی سازمان و محدودیت ظرفیت تنظیم شود.

۱۴.۲۷. Last Refresh و اعتماد کاربر

روی گزارش زمان آخرین به‌روزرسانی را نمایش می‌دهیم تا مدیر بداند تصمیمش بر اساس چه Snapshotی از داده است.

۱۴.۲۸. UAT؛ تست با کاربر واقعی

قبل از Go-Live، مدیر فروش و چند کاربر واقعی سناریوهای مشخص را تست می‌کنند.

۱۴.۲۹. Reconciliation با منبع

چند KPI کلیدی را با SQL/ERP یا گزارش رسمی موجود تطبیق می‌دهیم. اختلاف باید توضیح‌پذیر باشد.

Power BI Total Sales
vs
Approved ERP Sales Report

۱۴.۳۰. مستندات تحویل

حداقل این موارد را تحویل می‌دهیم: Data Sources، KPI Definitions، مدل داده، Measure Catalog، Refresh Plan، Security Matrix، Workspace/App Structure و Change Log.

۱۴.۳۱. آموزش کاربر

یک جلسه کوتاه برای مدیر و کاربران برگزار می‌کنیم: Slicer، Drill Through، Tooltip، Reset Filters، معنی KPIها و زمان Refresh.

گزارشی که کاربر بلد نیست استفاده کند، حتی اگر فنی عالی باشد ارزش کامل ایجاد نمی‌کند.

۱۴.۳۲. Runbook پشتیبانی

If report is wrong:
1. Check Last Refresh
2. Check source data
3. Check filters/RLS
4. Check measure/model
5. Document incident

Runbook کمک می‌کند رفع مشکل وابسته به حافظه یک نفر نباشد.

۱۴.۳۳. Acceptance Criteria

۱۴.۳۴. اشتباه کلاسیک؛ شروع از Dashboard

اگر بدون تعریف سؤال و KPI مستقیم سراغ Chart برویم، احتمال زیادی دارد گزارش زیبا ولی بی‌هدف شود.

Wrong: Visual → Data → Question
Right: Question → KPI → Data → Model → Visual

۱۴.۳۵. اشتباه کلاسیک؛ همه‌چیز در یک PBIX

اگر Integration، پاک‌سازی، Business Logic، Security و ده‌ها Report همگی بدون معماری در یک فایل بزرگ جمع شوند، نگهداری پروژه سخت می‌شود.

فصل سیزدهم یادمان داد لایه‌ها را متناسب با مقیاس پروژه جدا کنیم.

۱۴.۳۶. برنامه اجرای پروژه در Sprint

این فقط یک نمونه است؛ زمان واقعی به حجم و پیچیدگی پروژه بستگی دارد.

۱۴.۳۷. Definition of Done

یک صفحه زمانی Done است که فقط ظاهرش تمام نشده باشد؛ داده، DAX، UX، Security، Performance و تست آن هم تکمیل شده باشند.

۱۴.۳۸. پروژه عملی دانشجو

همین سناریو را از صفر بساز: حداقل پنج جدول، یک Star Schema، ده Measure، سه صفحه Report، یک Tooltip Page، Drill Through، Dynamic RLS و یک طرح Deployment.

برای هر تصمیم یک دلیل کوتاه بنویس؛ مثلاً چرا Bar Chart انتخاب کردی یا چرا یک ستون را از Fact حذف کردی.

۱۴.۳۹. چک‌لیست نهایی پروژه

۱۴.۴۰. از تحلیل‌گر Power BI به BI Developer

وقتی فقط Visual می‌سازی، بخشی از کار را بلدی. وقتی Requirement، Data Quality، Model، DAX، Security، Performance، Deployment و Governance را کنار هم می‌فهمی، وارد سطح حرفه‌ای‌تری از BI Development می‌شوی.

جمع‌بندی فصل چهاردهم

این فصل نقشه اتصال همه فصل‌های قبلی بود. پروژه موفق Power BI یک فایل PBIX نیست؛ یک محصول داده‌ای است که باید درست، سریع، امن، قابل فهم و قابل نگهداری باشد.

Business Need
→ Trusted Data
→ Good Model
→ Correct DAX
→ Clear UX
→ Secure Deployment
→ Adoption
→ Business Value

در فصل بعد وارد تحلیل‌های پیشرفته‌تر می‌شویم: What-if، Scenario Analysis، Forecasting، Key Influencers، Decomposition Tree و استفاده درست از قابلیت‌های هوشمند Power BI.