Membuat konten untuk dimigrasikan ke Power BI

Artikel ini menjelaskan Tahap 4, yang berkaitan dengan pembuatan dan validasi konten saat bermigrasi ke Power BI.

Catatan

Untuk penjelasan lengkap tentang grafik di atas, lihat gambaran umum migrasi Power BI.

Fokus Tahap 4 adalah melakukan pekerjaan aktual untuk mengonversi bukti konsep (POC) menjadi solusi siap produksi.

Output dari tahap ini adalah solusi Power BI yang telah divalidasi di ruang kerja pengembangan dan siap untuk penyebaran ke produksi.

Kiat

Sebagian besar topik yang dibahas dalam artikel ini juga berlaku untuk proyek implementasi Power BI standar.

Membuat solusi produksi

Pada tahap ini, orang yang sama yang melakukan POC mungkin melanjutkan dengan mengembangkan solusi Power BI yang siap untuk produksi. Atau, seseorang yang berbeda bisa terlibat. Jika jadwal tidak terancam, akan sangat baik melibatkan orang-orang yang akan bertanggung jawab atas pengembangan Power BI di masa depan. Dengan cara ini, mereka dapat secara aktif belajar.

Penting

Gunakan kembali sebanyak mungkin pekerjaan yang telah dilakukan pada POC.

Mengembangkan model semantik Impor baru

Anda mungkin memilih untuk membuat model semantik Impor baru saat model semantik Power BI yang sudah ada belum ada untuk memenuhi kebutuhan Anda, atau jika tidak dapat ditingkatkan untuk memenuhi kebutuhan Anda.

Idealnya, sejak awal, pertimbangkan untuk memisahkan pekerjaan pengembangan untuk data dan laporan. Memisahkan data dan laporan akan memfasilitasi pemisahan pekerjaan, dan izin, ketika orang yang berbeda bertanggung jawab atas pemodelan dan laporan data. Hal ini membuat pendekatan yang lebih dapat diskalakan dan mendorong penggunaan kembali data.

Kegiatan penting yang terkait dengan pengembangan model semantik Impor meliputi:

• Memperoleh data dari satu atau beberapa sumber data (yang bisa berupa aliran data Power BI).
• Bentuk, gabungkan, dan siapkan data.
• Buat model semantik, termasuk tabel tanggal.
• Buat dan verifikasi hubungan model.
• Tentukan ukuran.
• Siapkan keamanan tingkat baris, jika perlu.
• Konfigurasikan sinonim dan optimalkan Tanya Jawab.
• Rencanakan skalabilitas, performa, dan konkurensi, yang mungkin memengaruhi keputusan Anda tentang mode penyimpanan data, seperti menggunakan model komposit atau agregasi.

Kiat

Jika Anda memiliki lingkungan pengembangan/pengujian/produksi yang berbeda, pertimbangkan untuk memparameterkan sumber data. Hal ini akan membuat penyebaran, dijelaskan di Tahap 5, secara signifikan lebih mudah.

Mengembangkan laporan dan dasbor baru

Aktivitas penting yang terkait dengan pengembangan laporan atau dasbor Power BI meliputi:

• Memutuskan untuk menggunakan Koneksi Langsung ke model data yang sudah ada, atau membuat model data baru
• Saat membuat model data baru, tentukan mode penyimpanan data untuk tabel model (Impor, DirectQuery, atau Komposit).
• Tentukan alat visualisasi data terbaik untuk memenuhi persyaratan: Power BI Desktop, Paginated Report Builder, atau Excel.
• Tentukan visual terbaik untuk menyampaikan cerita yang perlu disampaikan oleh laporan, dan untuk menjawab pertanyaan yang perlu dijawab oleh laporan.
• Pastikan semua visual menyajikan terminologi yang jelas, ringkas, dan cocok untuk bisnis.
• Penuhi persyaratan interaktivitas.
• Saat menggunakan Koneksi Langsung, tambahkan ukuran tingkat laporan.
• Buat dasbor di layanan Power BI, terutama ketika konsumen menginginkan cara mudah untuk memantau metrik utama.

Catatan

Banyak dari keputusan ini akan dibuat pada tahap perencanaan sebelumnya atau di POC teknis.

Memvalidasi solusi

Ada empat aspek utama untuk validasi solusi Power BI:

1. Akurasi data
2. Keamanan
3. Fungsi
4. Kinerja

Memeriksa keakuratan data

Sebagai upaya satu kali selama migrasi, Anda harus memastikan data dalam laporan baru cocok dengan apa yang ditampilkan dalam laporan lama. Atau—jika ada perbedaan—dapat menjelaskan alasannya. Tindakan menemukan kesalahan dalam solusi lama yang diselesaikan dalam solusi baru ini lebih umum daripada yang Anda pikirkan.

Sebagai bagian dari upaya validasi data yang sedang berlangsung, laporan baru biasanya perlu diperiksa silang dengan sistem sumber asli. Idealnya, validasi ini terjadi dengan cara yang dapat diulang setiap kali Anda menerbitkan perubahan laporan.

Memvalidasi keamanan

Saat memvalidasi keamanan, ada dua aspek utama yang perlu dipertimbangkan:

• Izin akses data
• Akses ke model, laporan, dan dasbor semantik

Dalam model Semantik Impor, izin data diterapkan dengan menentukan keamanan tingkat baris (RLS). Ada kemungkinan juga bahwa izin data diberlakukan oleh sistem sumber saat menggunakan mode penyimpanan DirectQuery (mungkin dengan masuk tunggal).

Cara utama untuk memberikan akses ke konten Power BI adalah:

• Peran ruang kerja (untuk editor konten dan penonton).
• Pengaturan izin audiens aplikasi diterapkan pada paket konten ruang kerja (untuk pemirsa).
• Berbagi laporan atau dasbor individual (untuk pemirsa).

Kiat

Sebaiknya latih penulis konten tentang cara mengelola keamanan secara efektif. Penting juga untuk memiliki pengujian, audit, dan pemantauan yang kuat.

Memvalidasi fungsionalitas

Saatnya memeriksa kembali detail model semantik seperti nama bidang, pemformatan, pengurutan, dan perilaku ringkasan default. Fitur laporan interaktif, seperti filter, tindakan drill-down, tindakan drillthrough, ekspresi, tombol, atau penanda, semuanya harus diverifikasi juga.

Selama proses pengembangan, solusi Power BI harus diterbitkan ke ruang kerja pengembangan di layanan Power BI secara teratur. Verifikasi bahwa semua fungsionalitas berfungsi seperti yang diharapkan dalam layanan, seperti perenderan visual kustom. Ini juga saat yang tepat untuk melakukan pengujian lebih lanjut. Uji refresh terjadwal, Tanya Jawab, dan bagaimana laporan dan dasbor terlihat di perangkat seluler.

Validasi fungsi kerja

Performa solusi Power BI penting untuk pengalaman konsumen. Sebagian besar laporan harus menyajikan visual dalam waktu kurang dari 10 detik. Jika Anda memiliki laporan yang membutuhkan waktu lebih lama untuk dimuat, jeda, dan pertimbangkan kembali apa yang mungkin berkontribusi pada penundaan. Performa laporan harus dinilai secara teratur dalam layanan Power BI, selain Power BI Desktop.

Banyak masalah performa muncul dari DAX substandard (Data Analysis eXpressions), desain model semantik yang buruk, atau desain laporan suboptimal (misalnya, mencoba merender terlalu banyak visual pada satu halaman). Masalah lingkungan teknis, seperti jaringan, gateway data yang kelebihan beban, atau bagaimana kapasitas Premium dikonfigurasi juga dapat menyebabkan masalah performa. Untuk informasi selengkapnya, lihat Panduan pengoptimalan untuk Power BI dan Memecahkan masalah performa laporan di Power BI.

Penting

Artikel ini mengacu pada Power BI Premium atau langganan kapasitasnya (SKU P). Saat ini, Microsoft sedang mengonsolidasikan opsi pembelian dan menghentikan SKU Power BI Premium per kapasitas. Pelanggan baru dan pelanggan yang sudah ada harus mempertimbangkan untuk membeli langganan kapasitas Fabric (F SKU) sebagai gantinya.

Untuk informasi selengkapnya, lihat Pembaruan penting yang masuk ke lisensi Power BI Premium dan Tanya Jawab Umum Power BI Premium.

Mendokumentasikan solusi

Ada dua jenis utama dokumentasi yang berguna untuk solusi Power BI:

• Dokumentasi model semantik
• Dokumentasi laporan

Dokumentasi dapat disimpan di mana pun yang paling mudah diakses oleh audiens target. Opsi umum meliputi:

• Dalam situs SharePoint: Situs SharePoint mungkin ada untuk Pusat Keunggulan atau situs komunitas Power BI internal Anda.
• Dalam aplikasi: URL dapat disiapkan saat menerbitkan aplikasi Power BI untuk mengarahkan konsumen ke informasi selengkapnya.
• Dalam file Power BI Desktop individual: Elemen model, seperti tabel dan kolom, dapat menentukan deskripsi. Deskripsi ini muncul sebagai tooltips di panel Data saat menulis laporan.

Kiat

Jika Anda membuat situs untuk berfungsi sebagai hub untuk dokumentasi terkait Power BI, pertimbangkan untuk menyesuaikan menu Dapatkan Bantuan dengan lokasi URL-nya.

Membuat dokumentasi model semantik

Dokumentasi model semantik ditargetkan pada pengguna yang akan mengelola model semantik di masa mendatang. Berguna untuk menyertakan:

• Keputusan desain yang dibuat dan alasannya.
• Siapa yang memiliki, memelihara, dan mensertifikasi model semantik.
• Persyaratan pembaruan data.
• Aturan bisnis kustom yang ditentukan dalam model semantik.
• Persyaratan keamanan model semantik atau privasi data tertentu.
• Kebutuhan pemeliharaan di masa depan.
• Masalah terbuka yang diketahui atau item backlog yang ditunda.

Anda mungkin juga memilih untuk membuat log perubahan yang meringkas perubahan terpenting yang telah terjadi pada model semantik dari waktu ke waktu.

Membuat dokumentasi laporan

Dokumentasi laporan, yang biasanya disusun sebagai penuntun langkah demi langkah yang ditujukan untuk konsumen laporan, dapat membuat konsumen memperoleh lebih banyak nilai dari laporan dan dasbor Anda. Tutorial video singkat sering berfungsi dengan baik.

Anda juga dapat memilih untuk menyertakan dokumentasi laporan tambahan di halaman tersembunyi laporan Anda. Dokumentasi ini dapat mencakup keputusan desain dan log perubahan.

Konten terkait

Pada artikel berikutnya dalam seri migrasi Power BI ini, pelajari tentang tahap 5, yang berkaitan dengan penyebaran, dukungan, dan pemantauan konten saat bermigrasi ke Power BI.

Sumber daya bermanfaat lainnya meliputi:

• Transformasi BI dari Microsoft
• Perencanaan implementasi Power BI
• Pertanyaan? Cobalah bertanya di Komunitas Fabric
• Ada saran? Berikan ide untuk meningkatkan Fabric

Mitra Power BI berpengalaman tersedia untuk membantu kesuksesan organisasi Anda dalam proses migrasi. Untuk menemukan mitra Power BI, kunjungi portal mitra Microsoft Power BI .