داده‌های پراکنده را به یک منبع واحد و قابل اعتماد تبدیل کنید
در بسیاری از سازمان‌ها اطلاعات مهم در چندین سیستم مختلف ذخیره شده است. هر سیستم بخشی از واقعیت سازمان را نگهداری می‌کند؛ اما زمانی که مدیر نیاز به یک گزارش یکپارچه دارد، اختلاف تعریف شاخص‌ها و پردازش دستی اطلاعات باعث پیچیدگی می‌شود.
جریان داده سازمان
یکی از رایج‌ترین مشکلات این است که واحد فروش، مالی و مدیریت اعداد متفاوتی برای یک شاخص گزارش می‌کنند.
فروش این ماه چقدر بوده است؟
یک سؤال ساده ← سه جواب متفاوت
OLTP (عملیاتی)
Data Warehouse (تحلیلی)
مشخص می‌شود اطلاعات مورد نیاز در چه سیستم‌هایی وجود دارد.
داده از منابع مختلف دریافت می‌شود.
داده خام استاندارد می‌شود.
Business Ruleها روی داده اجرا می‌شوند.
داده‌های آماده وارد ساختار تحلیلی می‌شوند.
در بسیاری از پروژه‌های BI، ساختار Data Warehouse براساس Fact و Dimension طراحی می‌شود. این ساختار باعث می‌شود تحلیل سریع‌تر، قابل توسعه‌تر و قابل کنترل‌تر شود.
FactSales
Dimensions
هر Data Mart برای یک حوزه تخصصی طراحی می‌شود.
Sales Data Mart
داشبورد و تحلیل فروش
Fact Table
FactSales
Finance Data Mart
تحلیل مالی و بودجه
Fact Table
FactGL · FactBudget · FactCashFlow
Inventory Data Mart
تحلیل موجودی و گردش کالا
Fact Table
FactInventoryTransaction · FactInventorySnapshot
Production Data Mart
تحلیل تولید
Fact Table
FactProduction · FactDowntime · FactWaste
اگر Dimensionهای کلیدی مستقل و بدون استاندارد طراحی شوند، گزارش‌های مختلف ممکن است با یکدیگر ناسازگار شوند. به همین دلیل Dimensionهای مشترک بهتر است به‌صورت Conformed Dimensions طراحی شوند.
فشار روی Database عملیاتی
Queryهای تحلیلی ممکن است روی عملکرد سیستم اصلی اثر بگذارند.
Business Logic پراکنده
هر گزارش ممکن است تعریف متفاوتی از KPI داشته باشد.
تاریخچه محدود
سیستم عملیاتی ممکن است فقط وضعیت فعلی را نگهداری کند.
Integration سخت
ترکیب چند سیستم مستقیماً در Power BI پیچیده می‌شود.
نگهداری دشوار
هر تغییر در منبع داده ممکن است چندین Dashboard را تحت تأثیر قرار دهد.
فرض کنیم یک مشتری از منطقه تهران به منطقه شمال منتقل شده است. اگر فقط مقدار فعلی نگهداری شود، گزارش فروش گذشته ممکن است اشتباه تفسیر شود.
Customer A
تاریخچه تغییرات حفظ می‌شود تا گزارش‌های تاریخی دقیق باقی بمانند.
ETL
ELT
بسته به زیرساخت، حجم داده و معماری پروژه می‌توان ETL یا ELT مناسب را انتخاب کرد.
فقط رکوردهای جدید یا تغییرکرده دریافت می‌شوند.
این کار مدت بارگذاری و مصرف منابع را کاهش می‌دهد.
در معماری داده باید مشخص شود رکوردهای مختلف چگونه به یک موجودیت واحد تبدیل می‌شوند.
CRM
Customer = 4582
Accounting
Customer = C-975
Sales
Customer = 001254
این مسئله برای: Customer، Product، Supplier، Employee، Branch اهمیت زیادی دارد.
Semantic Model شامل Relationships، Measures، KPIs، Business Definitions، Hierarchies و Security است. این کار باعث می‌شود تعریف شاخص در تمام گزارش‌ها یکسان باشد.
Measures
قبل
بعد
پایگاه‌های داده سازمانی و سیستم‌های داخلی.
سیستم‌ها و نرم‌افزارهای تحت وب.
اطلاعات عملیات سازمان.
مشتریان و فرآیند فروش.
اطلاعات مالی و حسابداری.
فایل‌های عملیاتی یا تاریخی.
دریافت اطلاعات از سرویس‌های دیگر.
اتصال نرم‌افزارهای داخلی سازمان.
Data Warehouse برای همه شرکت‌ها ضروری نیست.
مدل ساده BI کافی است اگر:
Data Warehouse ارزش بیشتری دارد اگر:
On-Premise
برای سازمان‌هایی که زیرساخت داخلی دارند یا سیاست امنیتی آنها نگهداری اطلاعات داخل مجموعه است.
Cloud
برای پروژه‌هایی که استفاده از زیرساخت ابری برایشان مناسب است.
Hybrid
بخشی از داده در سازمان و بخشی در Cloud. انتخاب براساس امنیت، حجم، هزینه و Performance.
امنیت داده
بررسی KPIها، گزارش‌ها و سؤال‌های مدیریتی.
مشخص‌کردن سیستم‌های منبع و نوع اتصال.
بررسی کیفیت، ساختار و محتوای داده‌های منبع.
انتخاب الگوی مناسب برای معماری تحلیلی.
طراحی Fact، Dimension و روابط.
فرآیند استخراج، تبدیل و بارگذاری داده.
پیاده‌سازی ساختار و پایپ‌لاین‌ها.
اعتبارسنجی و تطبیق داده با منابع.
تعریف Measureها و KPIهای استاندارد.
اتصال Power BI یا ابزار تحلیلی به مدل.
بهینه‌سازی کوئری‌ها و عملکرد.
Deploy نهایی و پایش پایپ‌لاین‌ها.
نقشه جریان داده از سیستم‌های منبع تا لایه تحلیلی.
انبار داده طراحی‌شده برای تحلیل سازمان.
مدل‌های تخصصی فروش، مالی، تولید، انبار و سایر حوزه‌ها.
فرآیندهای دریافت، تبدیل و بارگذاری داده.
Factها، Dimensionها و روابط تحلیلی.
Measureها و KPIهای استاندارد.
کنترل‌های صحت و کیفیت اطلاعات.
مستندات معماری، منابع، Mapping و Business Rules.