Perencanaan implementasi Power BI: Merencanakan dan mendesain konten

Nota

Artikel ini adalah bagian dari seri perencanaan implementasi Power BI dari artikel. Seri ini berfokus pada perencanaan untuk menerapkan pengalaman Power BI di dalam Microsoft Fabric. Lihat pengantar seri.

Artikel ini membantu Anda merencanakan dan merancang konten sebagai bagian dari mengelola siklus hidup konten. Ini terutama ditargetkan pada:

• Tim Pusat Keunggulan (COE) dan BI: Tim yang bertanggung jawab untuk mengawasi Power BI di organisasi. Tim ini termasuk pembuat keputusan yang memutuskan cara mengelola siklus hidup konten Power BI.
• Pembuat konten dan pemilik konten: Pengguna yang membuat konten yang ingin mereka terbitkan ke portal Fabric untuk dibagikan dengan orang lain. Individu-individu ini bertanggung jawab untuk mengelola siklus hidup konten Power BI yang mereka buat.

Manajemen siklus hidup terdiri dari proses dan praktik yang Anda gunakan untuk menangani konten dari pembuatannya hingga penghentian akhirnya. Seperti yang dijelaskan dalam artikel pertama dalam seri ini, mengelola siklus hidup konten Power BI penting untuk memastikan pengiriman konten yang andal dan konsisten kepada pengguna bisnis.

Tahap pertama siklus hidup konten adalah merencanakan dan merancang konten. Anda biasanya memulai siklus hidup konten dengan melakukan perencanaan solusi BI. Anda mengumpulkan persyaratan untuk memahami dan menentukan masalah yang harus ditangani solusi Anda, dan tiba di desain solusi. Selama tahap perencanaan dan desain ini, Anda membuat keputusan utama untuk mempersiapkan tahap selanjutnya.

Gambar berikut menggambarkan siklus hidup konten Power BI, menyoroti tahap satu, tempat Anda merencanakan dan mendesain konten.

Nota

Untuk gambaran umum manajemen siklus hidup konten, lihat artikel pertama dalam seri ini.

Petunjuk / Saran

Artikel ini berfokus pada pertimbangan dan keputusan utama untuk perencanaan dan desain konten yang berkaitan dengan manajemen siklus hidup.

• Untuk informasi selengkapnya tentang cara merencanakan dan merancang solusi Fabric atau Power BI secara efektif, kami sarankan Anda membaca artikel perencanaan solusi .
• Untuk informasi selengkapnya tentang cara merencanakan migrasi Power BI secara efektif, kami sarankan Anda membaca seri migrasi Power BI .

Saat mengumpulkan persyaratan, Anda harus dengan jelas menjelaskan aspek tentang konten yang memengaruhi pendekatan Anda terhadap manajemen siklus hidup. Anda harus mendokumentasikan aspek-aspek ini sebagai bagian dari perencanaan dan desain solusi Anda.

Bagian berikut dalam artikel ini menjelaskan aspek dan pertimbangan utama solusi yang akan memotivasi pendekatan Anda terhadap manajemen siklus hidup saat Anda merencanakan dan merancang konten Anda.

Mengidentifikasi dan menjelaskan konten

Saat Anda merancang solusi, Anda harus menjelaskan apa kontennya, siapa yang akan membuatnya, siapa yang akan mendukungnya, dan seberapa penting konten ini untuk organisasi. Anda harus menangani faktor-faktor ini selama, atau setelah selesai, mengumpulkan persyaratan sebagai bagian dari desain solusi Anda.

Nota

Seperti kebutuhan Anda, jawaban atas pertanyaan-pertanyaan ini dapat berubah saat Anda mengembangkan solusi, atau nanti dalam siklus hidupnya. Setelah Anda menjawab pertanyaan-pertanyaan ini, bersiaplah untuk mengevaluasi ulang secara berkala saat Anda membuat perubahan pada konten, atau saat menskalakan jumlah pengguna yang dilayaninya.

Jawab pertanyaan berikut tentang konten Anda untuk membantu Anda membuat keputusan manajemen siklus hidup nanti.

Apa format kontennya?

Jenis, cakupan, dan kompleksitas konten memotivasi keputusan utama tentang cara Anda mengelolanya. Misalnya, satu laporan untuk audiens terbatas memerlukan pendekatan manajemen siklus hidup yang berbeda dibandingkan dengan model semantik yang akan digunakan oleh seluruh organisasi dan oleh beberapa beban kerja hilir yang berbeda.

Jawab pertanyaan seperti berikut ini untuk membantu Anda menentukan jenis konten yang akan Anda buat.

• Jenis item mana yang ingin Anda buat, dan berapa banyak dari masing-masing item? Misalnya, apakah Anda akan membuat item data seperti aliran data atau model semantik, melaporkan item seperti laporan atau dasbor, atau kombinasi keduanya?
• Bagaimana konten dikirimkan ke konsumen konten? Misalnya, apakah konsumen akan menggunakan item data untuk membangun konten mereka sendiri, apakah mereka hanya akan melihat laporan terpusat, atau kombinasi keduanya?
• Seberapa kompleks kontennya? Misalnya, apakah itu prototipe kecil, atau model semantik besar yang mencakup beberapa proses bisnis?
• Apakah Anda mengharapkan skala, cakupan, dan kompleksitas konten tumbuh dari waktu ke waktu? Misalnya, apakah konten akan mencakup wilayah atau area bisnis lain di masa mendatang?
• Berapa lama Anda mengharapkan bisnis membutuhkan konten ini? Misalnya, apakah konten ini akan mendukung inisiatif utama bisnis yang memiliki garis waktu terbatas?

Petunjuk / Saran

Pertimbangkan untuk membuat diagram arsitektur untuk menjelaskan format konten. Anda dapat menyertakan berbagai sumber data, jenis item, dan konsumen konten, dan hubungan antara komponen diskrit ini. Diagram arsitektur dapat membantu menggambarkan konten dan kompleksitasnya secara ringkas, dan membantu Anda merencanakan manajemen siklus hidupnya. Anda dapat menggunakan ikon Fabric dan ikon Azure untuk membuat diagram ini di perangkat lunak eksternal. Atau, Anda dapat menggunakan Diagram Azure, yang dilengkapi dengan ikon dan alat menggambar untuk membuat diagram ini.

Untuk contoh diagram tersebut, lihat diagram skenario penggunaan perencanaan implementasi Power BI.

Siapa yang akan membuat dan mendukung konten?

Pembuat konten memiliki berbagai kebutuhan, keterampilan, dan alur kerja. Faktor-faktor ini akan memengaruhi keberhasilan pendekatan manajemen siklus hidup yang berbeda. Tim pusat yang lebih besar dengan kolaborasi sering membutuhkan manajemen siklus hidup konten yang lebih canggih daripada tim pembuat layanan mandiri yang lebih kecil.

Jawab pertanyaan seperti berikut untuk membantu Anda menentukan siapa yang akan membuat atau mendukung konten.

• Berapa banyak individu berbeda yang Anda harapkan untuk membuat konten ini? Apakah beberapa pembuat konten akan berkolaborasi, atau apakah satu individu bertanggung jawab untuk membuat konten?
• Apakah pembuat konten terbiasa dengan manajemen siklus hidup dan konsep terkait, seperti kontrol versi? Apakah pembuat konten memahami manfaat manajemen siklus hidup?
• Apakah pembuat konten yang mengembangkan solusi adalah individu yang sama yang mendukungnya setelah penyebaran?
• Apakah pembuat konten atau tim mereka memiliki praktik manajemen siklus hidup yang ada untuk mendukung solusi yang ada?
• Apakah pembuat konten saat ini menggunakan alat manajemen siklus hidup seperti Azure DevOps?

Penting

Pastikan Anda mendokumentasikan dengan jelas siapa yang bertanggung jawab untuk membuat konten, dan siapa yang akan mendukungnya setelah disebarkan ke produksi. Libatkan semua individu ini dalam perencanaan manajemen siklus hidup konten Anda.

Apa pentingnya konten?

Bergantung pada seberapa penting konten untuk bisnis, Anda akan membuat keputusan yang berbeda tentang cara mengelolanya. Konten penting bisnis memerlukan pendekatan manajemen siklus hidup konten yang lebih kuat untuk melindungi kualitas dan mengurangi kemungkinan gangguan.

Jawab pertanyaan seperti berikut untuk membantu Anda menentukan apakah kontennya penting.

• Seberapa penting konten ini untuk bisnis? Seberapa mendesak permintaan untuk mengembangkannya?
• Apakah keputusan atau tindakan penting bisnis akan dibuat dari informasi yang disediakan oleh konten ini?
• Seberapa luas Anda berharap untuk mendistribusikan konten ini (dari seluruh organisasi ke tim lokal terbatas)?
• Apakah eksekutif atau pembuat keputusan strategis lainnya akan mengandalkan konten ini untuk pekerjaan mereka?
• Apa dampak konten ini? Misalnya, jika konten tiba-tiba tidak tersedia, dampak bisnis apa yang akan terjadi, seperti kehilangan pendapatan atau proses bisnis yang terganggu?

Setelah cukup mengidentifikasi dan menjelaskan konten yang akan Anda buat, Anda selanjutnya harus memutuskan bagaimana pembuat konten harus berkolaborasi.

Menentukan bagaimana pengguna akan menggunakan konten

Di Power BI, ada banyak cara berbeda di mana pengguna dapat menggunakan konten, termasuk model dan laporan semantik. Tergantung pada bagaimana orang akan mengakses dan menggunakan konten ini, Anda harus membuat keputusan yang berbeda tentang desainnya dan bagaimana Anda akan mengembangkannya. Beberapa keputusan ini dapat secara drastis mengubah cara Anda membuat konten, dan berapa banyak waktu dan upaya yang diperlukan. Biasanya, semakin banyak cara yang berbeda bahwa orang akan menggunakan model dan laporan Anda, semakin banyak pertimbangan yang Anda ingat, dan semakin tinggi biaya pengembangan yang dihasilkan.

Menggunakan dan menggunakan kembali model semantik

Model semantik bisa dibilang merupakan jenis item terpenting di Power BI dan Fabric, karena pengguna dapat mengonsumsinya dengan menggunakan banyak pendekatan dan item hilir yang berbeda. Jika Anda hanya akan mendistribusikan laporan, maka Anda akan membuat keputusan desain yang sangat berbeda seperti kapan pengguna akan menghubungkan berbagai item ke model untuk melakukan analisis mereka sendiri atau mencapai tujuan mereka sendiri.

Anda dapat menggunakan kembali model semantik bersama dengan menggunakan jenis item hilir berikut:

• Power BI

  • Laporan
  • Laporan berhalaman
  • Kartu Penilaian
  • Excel (menganalisis dalam tabel pivot Excel)
  • Model semantik (model komposit)

• Microsoft Fabric

  • Aktivator (sebelumnya Reflex)
  • Keterampilan AI
  • Kopilot
  • Eksplorasi
  • Kumpulan metrik
  • Notebooks (melalui Semantic Link dan pustaka semantic-link-labs )

Bagian berikut memberikan gambaran umum pertimbangan penting saat Anda menggunakan model semantik dengan beberapa item ini.

Nota

Banyak dari opsi ini hanya tersedia jika Anda mengaktifkan pengaturan penyewa yang relevan. Pastikan Anda membiasakan diri dengan pengaturan penyewa untuk mengetahui metode konsumsi apa yang dimungkinkan di ruang kerja tempat Anda akan menerbitkan model semantik Anda. Jika opsi ini terbatas pada grup keamanan tertentu, pastikan Anda mengidentifikasi apakah pengguna Anda termasuk (atau harus termasuk) dari grup keamanan ini, atau tidak.

Laporan

Ada beberapa cara berbeda di mana pengguna dapat terlibat dengan model semantik melalui laporan:

• Melihat laporan. Skenario standar, di mana pengguna melihat data dalam laporan yang Anda distribusikan atau bagikan dengan mereka.
• Menyambungkan ke model semantik dan membuat laporan baru. Dengan izin build, pengguna dapat membuat laporan baru di Power BI Desktop atau di layanan Power BI. Laporan ini memiliki koneksi langsung ke model semantik bersama. Pengguna juga dapat mengonversi laporan terhubung langsung ke model semantik komposit baru yang mengkueri aslinya dengan menggunakan DirectQuery.
• Membuat eksplorasi dari visual laporan yang sudah ada. Dengan izin build, pengguna juga dapat memilih visual yang didukung untuk membuat eksplorasi datanya. Ini membuat item eksplorasi baru yang memungkinkan pengguna untuk menambahkan bidang atau mengubah pemformatan. Pengguna dapat menyimpan dan berbagi eksplorasi yang dihasilkan jika mereka memenuhi kriteria yang diperlukan untuk lisensi, keanggotaan ruang kerja, dan izin item.
• Mempersonalisasi visual laporan, di mana pengguna dapat mengubah bidang dan pemformatan.Mempersonalisasi visual berfungsi mirip dengan eksplorasi, tetapi hanya memerlukan izin baca, dan tidak membuat item baru. Personalisasi visual juga menggunakan perspektif apa pun yang diterapkan pengguna ke halaman laporan, yang membatasi bidang yang tersedia yang dapat dilihat dan digunakan pengguna.

Berbagai skenario ini menciptakan sejumlah pertimbangan yang harus Anda ingat untuk model semantik Anda, seperti:

• Izin mana yang akan Anda berikan kepada pengguna, dan bagaimana Anda akan mengelola izin ini. Sebaiknya pengguna menyelesaikan pelatihan sebelum mendapatkan izin build.
• Apakah Anda akan menambahkan perspektif ke model Anda atau tidak? Anda hanya bisa menambahkan perspektif dengan menggunakan tampilan TMDL di Power BI Desktop, atau dengan menggunakan alat pihak ketiga lainnya. Kami menyarankan agar Anda menambahkan perspektif saat pengguna akan menggunakan mempersonalisasi visual atau model komposit.
• Bidang mana yang harus Anda sembunyikan dalam model Anda, dan apakah Anda perlu mengaktifkan properti tabel TOM IsPrivate untuk menghindari bahwa mereka atau objek turunannya muncul sebagai saran. Perhatikan bahwa properti TOM Privat hanya dapat diatur dengan menggunakan alat eksternal pada file metadata model (seperti .bim atau .tmdl) atau model jarak jauh yang diterbitkan di layanan Power BI.
• Bagaimana Anda akan mendokumentasikan model Anda, dan apa yang harus dimuat dalam dokumentasi tersebut. Kami menyarankan agar Anda membuat dokumentasi yang disesuaikan dengan kasus penggunaan tertentu dan Anda menyertakan informasi yang relevan dan berguna, dan bukan ekspor metadata model seperti ekspresi pengukuran DAX, yang umumnya tidak berguna untuk pengguna akhir.
• Bagaimana Anda akan menyarankan pengguna untuk memilih satu pendekatan di atas pendekatan lain.

Perhatian

Setelah Anda memberikan izin baca atau bangun ke model semantik, maka pengguna mungkin dapat mengkueri tabel atau kolom apa pun dalam model Anda dengan menggunakan pendekatan yang dijelaskan di bagian ini. Ini benar meskipun Anda tidak mengekspos tabel, pengukuran, atau kolom tersebut dalam laporan. Pastikan Anda selalu melindungi data sensitif dengan menggunakan keamanan data, atau mengecualikannya dari model Anda. Dengan begitu, Anda dapat menghindari mengekspos informasi sensitif secara tidak sengaja kepada orang yang salah.

Excel (analisis dalam tabel pivot Excel)

Jika pengguna memiliki izin build ke model, maka mereka juga bisa menyambungkan ke model semantik dari Excel dan mengkuerinya dengan menggunakan MDX dari tabel pivot Excel. Ini bisa berguna ketika pengguna lebih suka bekerja di Excel untuk menjelajahi atau menganalisis data sendiri.

Saat menggunakan analisis di Excel untuk mengkueri model semantik Anda, Anda perlu mempertimbangkan hal berikut:

• Fitur tertentu seperti parameter bidang atau mengukur string format dinamis hanya berfungsi di Power BI, dan bukan di Excel. Untuk mencapai hasil yang sama, Anda perlu menggunakan pendekatan lain.
• Analisis di Excel mengharuskan properti kolom IsAvailableinMDX diaktifkan. Jika pengguna tidak akan menggunakan Excel, maka menonaktifkan properti ini dapat mengakibatkan model yang lebih kecil dan lebih berkinerja.
• Pengguna tidak dapat melihat kolom atau pengukuran tersembunyi dalam model semantik, seperti yang mereka bisa dari Power BI Desktop (dengan mengklik kanan panel data, dan memilih "lihat tersembunyi").
• Pengguna tidak dapat membuat pengukuran atau perhitungan visual mereka sendiri di Excel, seperti yang mereka bisa saat menggunakan koneksi langsung dari Power BI Desktop. Namun, mereka dapat mereferensikan bidang tabel pivot di sel Excel dan lembar kerja lainnya untuk perhitungan kustom.
• Pengguna analisis di Excel sering memerlukan pelatihan tambahan tentang cara menggunakannya. Ini terutama benar jika mereka mengharapkan pengalaman seperti ekspor atau mereka mengekspresikan niat untuk menyimpan salinan data offline. Pertimbangkan untuk melatih pengguna tentang hal-hal seperti:
  • Cara memperbarui data.
  • Filterkan data sebelum menambahkan bidang ke tabel pivot.
  • Hindari membuat kueri yang besar dan terperinci tanpa filter.
  • Power BI Desktop akan lebih berkinerja daripada Analisis di Excel, karena menganalisis di Excel mengkueri model dengan menggunakan MDX, tetapi Power BI Desktop mengkueri model dengan DAX.
  • Cara menghindari pembuatan risiko tata kelola atau keamanan sambil tetap memanfaatkan Excel seperti yang mereka sukai.

Keterampilan copilot dan AI

Jika pengguna memiliki izin baca ke model, maka dapat menggunakan bahasa alami untuk menjelajahi dan mengajukan pertanyaan tentang data mereka dengan menggunakan Copilot. Atau, mereka juga dapat mengajukan pertanyaan data tentang data mereka dalam keterampilan AI, tetapi tidak seperti Copilot, Anda harus terlebih dahulu membuat dan berbagi item ini dengan mereka.

Ketika pengguna ingin berinteraksi dengan model semantik Anda dengan menggunakan bahasa alami, ada konsekuensi yang cukup besar untuk desain dan implementasi model Anda:

• Skema linguistik: Anda harus menambahkan sinonim dan hubungan ke model Anda sehingga kata dan istilah bahasa Inggris yang sesuai dikaitkan dengan objek model yang benar.
• Konvensi penamaan: Anda harus menggunakan konvensi penamaan bahasa Inggris yang ramah AI. Ini berarti Bahwa Anda harus menghindari nama bidang duplikat atau terlalu mirip, akronim, simbol, dan singkatan, bahkan jika itu standar di organisasi Anda.
• Properti: Anda harus mengatur properti seperti deskripsi kolom atau pengukuran, kategori data, dan lainnya sehingga alat AI dapat mengenali dan menggunakan bidang ini dengan lebih baik.
• Menyembunyikan bidang: Anda harus menyembunyikan bidang yang tidak ingin Anda ekspos ke Copilot atau gunakan dalam responsnya.

Anda juga perlu memberikan upaya tambahan dalam melatih pengguna.

• Apa yang bisa dan tidak bisa dilakukan oleh keterampilan Copilot atau AI.
• Kapan menggunakan keterampilan Copilot atau AI untuk menjelajahi data melalui pendekatan lain (non-AI).
• Cara menulis perintah yang efektif.
• Cara memvalidasi output.
• Cara memecahkan masalah output yang tidak terduga.

Petunjuk / Saran

Lihat artikel berikut untuk tips dan pertimbangan tambahan dan terperinci tentang mengoptimalkan model agar berfungsi dengan baik dengan Copilot:

• Pengoptimalan untuk penulis laporan dan pengguna model
• Perbarui model data Anda agar berfungsi dengan baik dengan Copilot untuk Power BI
• Menulis kueri DAX dengan Copilot

Copilot dan teknologi AI generatif lainnya memiliki batasan dan pertimbangan penting yang harus Anda pahami dalam tahap perencanaan dan desain konten Anda.

• Ini non-deterministik, yang berarti bahwa input yang sama pada konteks yang sama dapat menghasilkan output yang berbeda.
• Anda bisa mendapatkan keluaran berkualitas rendah atau tidak akurat, seperti ketika alat berhalusinasi, atau melebih-lebihkan pentingnya fakta tertentu. Copilot mungkin juga salah atau tidak akurat karena kelalaian, sehingga meninggalkan informasi penting.
• Alat-alat ini dibatasi oleh data pelatihan mereka, jadi pertanyaan tentang lebih banyak informasi baru cenderung tidak menghasilkan output yang berguna.

Perhatian

Anda harus mengurangi risiko batasan dan pertimbangan ini. Copilot, keterampilan AI, LLM, dan AI generatif adalah teknologi baru berkembang, jadi Anda tidak boleh menggunakannya untuk proses otonom, berisiko besar, atau kritikal bagi bisnis dan pengambilan keputusan. Untuk informasi selengkapnya, lihat juga Panduan keamanan untuk Model Bahasa Besar.

Laporan berhalaman

Anda dapat menulis kueri DAX untuk model semantik untuk membuat laporan paginasi dengan hasil kueri. Ini relevan jika pengguna memerlukan laporan paginated dan Anda berniat menggunakan model semantik Anda sebagai sumber data.

Saat Anda berencana untuk membuat laporan paginated pada model semantik, Anda mungkin perlu mempertimbangkan poin-poin berikut:

• Bagaimana Anda akan menulis dan memelihara kueri DAX, seperti dengan menggunakan tampilan kueri DAX Power BI Desktop, atau alat pihak ketiga lainnya.
• Apakah Anda perlu membuat keputusan desain untuk memastikan model semantik Anda berkinerja saat dikueri, seperti mewujudkan data tertentu dalam kolom model atau tabel.
• Apakah Anda akan menyematkan laporan berjenjang ke dalam laporan Power BI interaktif Anda dengan menggunakan visual laporan berjenjang atau tidak.
• Bagaimana Anda akan memastikan bahwa tidak ada redundansi antara laporan paginasi Anda dan laporan lainnya.
• Dalam format mana Anda harus mendistribusikan laporan paginated, dan apakah Anda memerlukan label sensitivitas atau pencegahan kehilangan data untuk melindungi output tersebut agar tidak menjadi risiko tata kelola atau keamanan.

Lainnya

Ada juga cara lain untuk mengonsumsi model semantik. Beberapa contoh di bawah ini:

• Aktivator (sebelumnya Refleks): Anda dapat menggunakan model semantik untuk mengotomatiskan pemberitahuan data dan memicu alur hilir, seperti yang Anda buat dengan menggunakan Power Automate.
• Set metrik: Anda dapat membuat set metrik, yang mencakup pengukuran dan dimensi yang direkomendasikan dari beberapa model semantik di satu tempat. Kumpulan metrik dapat meningkatkan penemuan data untuk pengguna.
• Eksplorasi: Selain membuat eksplorasi dari laporan dan output Copilot, pengguna juga dapat membuat eksplorasi dari model semantik.

Distribusi dan berbagi Laporan

Bergantung pada bagaimana Anda akan mendistribusikan dan berbagi laporan Power BI, Anda akan membuat pilihan desain yang berbeda. Misalnya, penelusuran lintas laporan adalah fitur yang memungkinkan pengguna menavigasi antara laporan di ruang kerja atau aplikasi yang sama. Namun, Anda tidak dapat menggunakan penelusuran lintas laporan jika Anda menyematkan laporan atau membagikannya secara publik melalui Publish-to-Web.

Item lainnya

Bergantung pada bagaimana orang akan menggunakan konten Anda dan data yang mendasar, Anda mungkin perlu beralih ke jenis item lain di Power BI atau Fabric. Misalnya, jika pengguna ingin menambahkan data dan perhitungan mereka sendiri, mereka dapat menggunakan model komposit dengan model semantik Anda. Atau, Anda dapat membuat item data terpusat lainnya untuk digunakan dalam model baru, seperti aliran data.

Setelah Anda menentukan bagaimana pengguna akan menggunakan konten yang Anda buat, Anda selanjutnya harus memutuskan bagaimana pembuat konten harus berkolaborasi selama pengembangan.

Memutuskan bagaimana pembuat konten harus berkolaborasi

Ketika solusi meningkat dalam cakupan dan kompleksitas, mungkin perlu bagi beberapa pembuat konten dan pemilik untuk bekerja dalam kolaborasi. Saat membuat solusi yang kompleks, kami sarankan Anda menggunakan alat efektif yang membantu menyusun, mengelola, dan mendukung kolaborasi. Ada banyak cara untuk berkolaborasi saat memproduksi konten Power BI, seperti dengan menggunakan Microsoft Teams, Azure DevOps, atau GitHub.

Petunjuk / Saran

Bahkan ketika pembuat konten bekerja secara independen, mereka masih dapat memperoleh manfaat dari perencanaan dan penataan pekerjaan mereka dengan menggunakan alat seperti Microsoft Teams, Azure DevOps, atau GitHub. Ini sangat penting ketika Anda merencanakan cara menyebarkan konten, seperti dengan menggunakan OneDrive Refresh dari pustaka dokumen Microsoft Teams atau integrasi Git dari repositori Azure DevOps atau GitHub.

Microsoft Teams

Untuk proyek yang lebih kecil atau lebih sederhana, pembuat konten dapat berkolaborasi dengan menggunakan Microsoft Teams.

Dengan menggunakan Microsoft Teams, pembuat konten menyusun komunikasi, perencanaan, dan pekerjaan mereka dalam tim dan saluran. Microsoft Teams sering kali merupakan pilihan yang baik untuk skenario kolaborasi yang lebih sederhana. Misalnya, tim terdesentralisasi yang menghasilkan konten untuk audiens terbatas dapat menggunakan pustaka dokumen untuk menyimpan file dan kontrol versi. Mereka juga dapat menggunakan alat dan layanan terintegrasi lainnya.

Petunjuk / Saran

Kami menyarankan agar Anda menggunakan Microsoft Teams untuk memfasilitasi manajemen siklus hidup konten yang efektif dalam skenario layanan mandiri dengan pengiriman konten terdesentralisasi.

Untuk berkolaborasi dan berkomunikasi di Microsoft Teams, Anda menggunakan layanan pendukung sepanjang siklus hidup konten Power BI Anda.

• Planner: Pemilik konten dapat menggunakan Planner untuk membuat rencana, yang mereka gunakan untuk melacak tugas dan ruang lingkup pekerjaan konten. Tugas dapat menjelaskan masalah, bug, atau fitur dalam solusi, dan pemangku kepentingan yang sesuai.
• SharePoint: Pembuat konten bisa menyimpan dan mengelola file di pustaka dokumen Microsoft Teams atau situs tersambung untuk setiap saluran. File konten yang disimpan di SharePoint dapat menggunakan kontrol versi untuk membantu melacak dan mengelola perubahan konten. Untuk informasi selengkapnya tentang melacak dan mengelola perubahan dengan menggunakan SharePoint, lihat Tahap 2: Mengembangkan konten dan mengelola perubahan.
• Persetujuan: Pembuat dan pemilik konten dapat menyiapkan dan menggunakan alur kerja untuk menyetujui perubahan atau rilis konten setelah ditinjau.
• Fabric dan Power BI: Pembuat dan pemilik konten dapat mengakses portal Fabric dari dalam Microsoft Teams. Dari sana, mereka dapat mengelola atau mendiskusikan konten, dan menambahkan laporan bermanfaat ke tab di saluran Teams.
• Integrasi lain: Pembuat konten dapat menggunakan layanan Microsoft atau pihak ketiga lainnya yang terintegrasi dengan Microsoft Teams agar paling sesuai dengan alur kerja dan kebutuhan pilihan mereka.

Kami menyarankan agar Anda menentukan proses terstruktur tentang bagaimana pembuat konten harus menggunakan Microsoft Teams untuk berkolaborasi. Pastikan Anda menentukan:

• Cara mengelola akses ke tim dan saluran.
• Siapa yang bertanggung jawab untuk mengelola tim dan saluran.
• Bagaimana pekerjaan ditentukan ruang lingkupnya dan diatur ke dalam tim, saluran, dan rencana yang spesifik.
• Bagaimana pembuat konten harus menggunakan pustaka dokumen untuk mengatur file dan melacak dan mengelola perubahan. Misalnya, cara mengatur pustaka dokumen dan apakah pembuat konten harus memasukkan dan mengeluarkan file.
• Apakah pembuat konten harus menggunakan OneDrive Refresh untuk menerbitkan file Power BI Desktop (.pbix) secara otomatis.
• Bagaimana konflik sinkronisasi file diselesaikan.
• Kapan harus mengarsipkan dan menghapus file dari pustaka dokumen yang tidak lagi relevan.

Azure DevOps atau GitHub Enterprise

Pembuat dan pemilik konten juga dapat berkomunikasi dan berkolaborasi di hub pusat yang terorganisir dengan menggunakan Azure DevOps atau GitHub Enterprise.

Nota

Azure DevOps adalah serangkaian layanan yang terintegrasi dengan Power BI dan Fabric untuk membantu Anda merencanakan dan mengatur manajemen siklus hidup konten. Saat Anda menggunakan Azure DevOps dengan cara ini, Anda biasanya memanfaatkan layanan berikut:

• Azure Repos: Memungkinkan Anda membuat dan menggunakan repositori Git jarak jauh, yang merupakan lokasi penyimpanan jarak jauh yang Anda gunakan untuk melacak dan mengelola perubahan konten.
• Azure Pipelines: Memungkinkan Anda membuat dan menggunakan serangkaian tugas otomatis untuk menangani, menguji, dan menyebarkan konten dari repositori jarak jauh ke ruang kerja.
• Azure Test Plans: Memungkinkan Anda merancang pengujian untuk memvalidasi solusi dan mengotomatiskan kontrol kualitas bersama dengan Azure Pipelines.
• Azure Boards: Memungkinkan Anda menggunakan papan untuk melacak tugas dan rencana sebagai item kerja, dan menautkan atau merujuk ke item kerja dari layanan Azure DevOps lainnya.
• Azure Wiki: Memungkinkan Anda berbagi informasi dengan tim mereka untuk memahami dan berkontribusi pada konten.

Dengan menggunakan Azure DevOps atau GitHub Enterprise, pembuat konten menggunakan proyek untuk menyusun komunikasi, perencanaan, dan pekerjaan mereka. Selain itu, pembuat konten dapat mengatur manajemen siklus hidup konten dari dalam Azure DevOps dengan melakukan kontrol sumber, validasi, dan penyebaran. Kontrol sumber adalah proses pengelolaan perubahan yang lebih terperinci pada kode konten dan metadata.

Azure DevOps sering kali merupakan pilihan yang baik untuk skenario kolaborasi yang lebih canggih, karena ada layanan dan opsi pendukung untuk mengatur pembuatan dan penyebaran konten.

Petunjuk / Saran

Kami menyarankan agar Anda menggunakan Azure DevOps untuk membantu manajemen siklus hidup konten yang efektif dalam skenario perusahaan dengan pengiriman konten terpusat. Berkolaborasi dengan menggunakan Azure DevOps atau alat serupa lebih disukai dalam skenario yang lebih besar atau lebih kompleks daripada berkolaborasi dengan menggunakan Microsoft Teams atau SharePoint. Itu karena ada lebih banyak alat dan opsi yang tersedia untuk memfasilitasi kolaborasi dan otomatisasi yang lebih kuat.

Kami menyarankan agar Anda menentukan proses terstruktur tentang bagaimana pembuat konten harus menggunakan Azure DevOps untuk berkolaborasi. Pastikan Anda menentukan:

• Bagaimana cakupan kerja diuraikan dan bagaimana cabang konten dibuat, diberi nama, dan digunakan.
• Bagaimana pengarang mengelompokkan dan mengkomit perubahan serta menjelaskan perubahan tersebut dengan pesan commit.
• Siapa yang bertanggung jawab meninjau dan menyetujui perubahan dengan menggunakan pull request.
• Cara menyelesaikan konflik penggabungan pada permintaan tarik dan siapa yang menyelesaikannya.
• Bagaimana perubahan yang dilakukan di cabang yang berbeda harus digabungkan ke dalam satu cabang.
• Bagaimana konten diuji dan siapa yang melakukan pengujian sebelum konten disebarkan.
• Bagaimana dan kapan perubahan disebarkan ke ruang kerja pengembangan, pengujian, dan produksi.
• Bagaimana dan kapan perubahan yang disebarkan atau versi solusi dapat digulung balik.

GitHub

Pembuat dan pemilik konten juga dapat berkomunikasi dan berkolaborasi dengan menggunakan GitHub (hanya versi cloud) dan GitHub Enterprise. Mirip dengan Azure DevOps, GitHub menyediakan platform dengan layanan yang dapat Anda gunakan untuk membantu mengatur dan mengelola aspek lingkungan Power BI atau Fabric Anda.

Perbedaan utama antara Azure DevOps dan GitHub adalah bahwa sementara Azure DevOps menyediakan serangkaian alat untuk mengelola siklus hidup pengembangan perangkat lunak, GitHub berfokus terutama pada hosting repositori Git, kontrol sumber, dan kolaborasi pada kode. Anda terutama menggunakan GitHub ketika Anda berencana untuk menyebarkan konten dengan menggunakan integrasi Git. Selain itu, Anda dapat menggunakan GitHub untuk menyinkronkan konten dari repositori sumber terbuka publik ke ruang kerja.

Untuk menggunakan integrasi Git dengan GitHub, Anda harus mengaktifkan pengaturan penyewa admin Pengguna dapat menyinkronkan item ruang kerja dengan repositori GitHub.

Nota

Anda juga dapat menggunakan Microsoft Teams bersama dengan Azure DevOps atau GitHub karena ada berbagai cara untuk mengintegrasikan layanan ini. Misalnya, Anda dapat melihat dan mengelola Azure Boards dan memantau peristiwa di Azure Pipelines dari dalam Microsoft Teams.

Anda juga dapat berkolaborasi dan merencanakan konten dengan menggunakan alat lain yang tidak disebutkan, di sini. Yang paling penting adalah Anda menggunakan alat dan layanan yang memfasilitasi kolaborasi untuk Anda, dan yang paling sesuai dengan kebutuhan tim Anda dan cara kerjanya.

Ketika Anda telah memutuskan apakah dan bagaimana pembuat konten harus berkolaborasi, Anda selanjutnya harus memutuskan di mana Anda akan menyimpan file Anda. Banyak dari file-file ini akan disimpan di mana Anda memilih untuk berkolaborasi.

Memutuskan tempat untuk menyimpan file

Saat membuat konten, Anda biasanya menghasilkan berbagai jenis file. Penting untuk memutuskan di mana menyimpan file-file ini sehingga Anda dapat mengelolanya secara efektif.

Petunjuk / Saran

Simpan file tempat file dapat diakses oleh beberapa anggota tim, dan di mana perubahan dapat dengan mudah dilacak (dikenal sebagai kontrol versi). Pendekatan ini memastikan bahwa kepergian anggota tim atau kehilangan file tidak menyebabkan gangguan.

Jenis file yang harus Anda simpan sering kali meliputi:

• File konten: File yang berisi data konten atau metadata. File konten dengan data seperti file .pbix dan Power BI Project (.pbip) berisi informasi sensitif. Simpan file konten di lokasi aman yang hanya dapat diakses oleh mereka yang memerlukan akses ke file tersebut. Selain itu, Anda harus menyimpan file konten di lokasi yang mendukung kontrol versi, seperti pustaka dokumen di Microsoft Teams atau repositori Git di Azure DevOps. Contoh file konten meliputi:
  • File Power BI Desktop (.pbix)
  • File Proyek Power BI (.pbip)
  • File laporan paginasi Power BI (.rdl)
  • File metadata model (.bim atau .tmdl)
  • Metadata aliran data (.json) file
• File sumber data: File yang digunakan oleh item data seperti model semantik atau aliran data. Konten bergantung langsung pada file sumber data, jadi penting untuk mempertimbangkan dengan cermat di mana file disimpan karena menghapusnya akan mengakibatkan kegagalan refresh data. Selain itu, file-file ini mungkin berisi informasi sensitif. Jadi, simpan file sumber data di lingkungan yang aman, andal, dan dapat dipercaya yang memiliki akses terbatas oleh individu lain. Contoh file sumber data mungkin meliputi:
  • Sumber data terstruktur, seperti buku kerja Excel, Parquet, atau file CSV.
  • Sumber data semi-terstruktur, seperti file JSON atau XML.
  • Sumber data yang tidak terstruktur, seperti gambar yang Anda impor ke dalam laporan.
• File pendukung: File yang mendukung pembuatan atau manajemen konten, tetapi tidak diperlukan agar berfungsi. File pendukung harus disimpan di lokasi yang mendukung kontrol versi, dan di mana alat dan pembuat konten lain dapat mengaksesnya. Contoh file pendukung mungkin meliputi:
  • File tema Power BI (.json) .
  • File gambar (.png, .jpg, atau .gif) di laporan Power BI.
  • File Aturan Penganalisis Praktik Terbaik (.json).
  • Berkas kode sumber untuk konten dan kueri.
  • File visualisasi kustom (.pbiviz).
• Templat dan dokumentasi: File yang membantu dalam pembuatan konten layanan mandiri atau menjelaskan konten yang ada. Templat dan dokumentasi harus mudah diakses oleh orang-orang yang perlu menggunakannya. Contoh templat dan dokumentasi mungkin mencakup:
  • File templat Power BI (.pbit).
  • Templat visualisasi dan contoh laporan.
  • Desain dan dokumentasi solusi.
  • Perencanaan solusi dan peta jalan.
  • Permintaan pengguna dan masalah solusi.

Perhatian

Beberapa file konten seperti file .pbix dan .pbip dapat berisi data sensitif yang diimpor dari sumber data. Selain itu, file metadata juga dapat berisi informasi sensitif, atau dalam beberapa kasus, titik data. Contohnya adalah metadata laporan dan templat .pbit, yang dapat berisi nilai kolom dalam keadaan tertentu. Pastikan Anda mengambil tindakan pencegahan yang diperlukan untuk menyimpan file-file ini di lokasi yang aman dan Anda mempraktikkan pencegahan kehilangan data yang efektif.

Anda memiliki opsi yang berbeda untuk menyimpan file. Pastikan Anda memilih lokasi yang sesuai, tergantung pada jenis file, kontennya, dan bagaimana file tersebut akan digunakan.

SharePoint Online atau OneDrive

Solusi umum untuk menyimpan file adalah dengan menggunakan situs SharePoint . SharePoint dapat diakses secara luas untuk sebagian besar pengguna dan sangat terintegrasi dengan Power BI dan aplikasi Microsoft 365 lainnya, seperti Microsoft Teams. Selain itu, ia memiliki kontrol versi bawaan, membuatnya nyaman untuk menyimpan sebagian besar jenis file. Kontrol versi memungkinkan Anda untuk melihat dan mengelola versi file yang disimpan yang berbeda.

Saat Anda menyimpan file di SharePoint, pertimbangkan poin berikut.

• Organisasi: Pastikan Anda mempertahankan struktur yang konsisten dan logis sehingga mudah untuk menemukan file tertentu. Gunakan konvensi penamaan yang baik, atur file dalam folder, dan arsipkan file yang tidak lagi relevan untuk proyek yang sedang berlangsung.
• Refresh OneDrive: Anda bisa menautkan model semantik yang diterbitkan atau laporan ke file .pbix yang disimpan di SharePoint atau OneDrive di situs kerja atau sekolah. Dengan pendekatan ini, Anda tidak lagi harus menerbitkan model semantik agar perubahan diterapkan. Sebagai gantinya, perubahan Anda terlihat setelah refresh OneDrive otomatis, yang terjadi per jam. Meskipun nyaman, ketahuilah bahwa pendekatan ini dilengkapi dengan beberapa peringatan dan tantangan. Ketika semuanya berjalan, itu tidak dapat dengan mudah dibalik.
• Pratinjau laporan: Di SharePoint, Dimungkinkan untuk menampilkan laporan Power BI tanpa harus menginstal Power BI Desktop atau mengunduh file .pbix secara lokal. Saat Anda membuka laporan dengan cara ini, laporan ditampilkan di browser. Kemampuan ini dapat menjadi alternatif yang nyaman untuk melihat laporan dari portal Fabric. Ini diaktifkan secara default di pengaturan penyewa Fabric.

Petunjuk / Saran

Saat Anda berkolaborasi dengan menggunakan Microsoft Teams, pertimbangkan untuk menyimpan file di pustaka dokumen saluran. Pendekatan ini membantu memusatkan file dan memfasilitasi kolaborasi.

Pertimbangkan untuk menyimpan tipe file berikut di SharePoint.

• Templat dan dokumentasi: Menyimpan templat dan dokumentasi di SharePoint saat Anda tidak memiliki solusi penyimpanan yang sudah ada. SharePoint sangat ideal untuk file-file ini karena Anda dapat memberikan akses ke orang lain dan mengelola file tanpa penyetelan atau proses yang kompleks.
• File pendukung: Simpan file pendukung di SharePoint saat Anda tidak memiliki solusi penyimpanan yang sudah ada. Namun, beberapa file pendukung (seperti tema Power BI .json file untuk laporan) mungkin lebih baik disimpan dalam sistem kontrol versi yang memungkinkan menampilkan dan mengelola perubahan yang disimpan.
• File konten: Simpan konten di SharePoint saat tidak penting bagi bisnis, atau saat Anda tidak memiliki akses ke repositori jarak jauh seperti Azure Repos.
• Sumber data: Simpan sumber data di SharePoint hanya saat ukuran dan kompleksitasnya kecil. Latihan disiplin saat menggunakan SharePoint untuk menyimpan file sumber data. Pertimbangkan kemungkinan alternatif lainnya, seperti OneLake.

Perhatian

Jangan gunakan SharePoint sebagai alternatif untuk arsitektur data yang tepat. Meskipun menyimpan file sumber data di SharePoint bisa nyaman dalam beberapa skenario terbatas, pendekatan ini tidak menskalakan ketika Anda memiliki sumber data yang lebih besar dan lebih kompleks, atau ketika Anda membutuhkan latensi data yang lebih rendah.

Peringatan

Jangan gunakan sistem file pribadi atau akun OneDrive pribadi untuk menyimpan file. Jika pemilik meninggalkan organisasi, file-file ini tidak akan lagi tersedia.

OneLake

Jika Anda memiliki kapasitas Fabric, OneLake bisa menjadi pilihan yang baik untuk menyimpan file sumber data. Anda dapat mengunggah atau menyinkronkan file ke OneLake dengan menggunakan OneLake File Explorer, di mana file tersebut dapat diubah menjadi tabel untuk digunakan dalam beban kerja hilir seperti Power BI. Untuk sumber data yang lebih besar atau diperbarui secara teratur, Anda dapat memuat file ke OneLake secara otomatis dengan menggunakan Fabric Data Factory atau aplikasi lain yang menggunakan AZURE Data Lake Storage (ADLS) Gen2 API atau Azure Storage Python SDK.

Perhatian

Tindakan seperti mengunggah atau mengunduh file dari OneLake menggunakan unit kapasitas Fabric. Anda harus memantau metrik kapasitas dan mengambil langkah-langkah untuk menghindari ketegangan kapasitas yang disebabkan oleh pergerakan file besar yang tidak perlu.

Selain itu, file yang diakses oleh pengguna dengan OneLake File Explorer rentan terhadap perubahan atau kehilangan yang tidak disengaja. Kami menyarankan agar Anda menghindari penggunaan OneLake File Explorer untuk solusi penting bisnis.

Peringatan

OneLake File Explorer memiliki beberapa batasan dan pertimbangan penting. Misalnya, OneLake tidak mendukung kontrol versi untuk file, seperti SharePoint atau OneDrive. Pertimbangkan pertimbangan dan batasan ini ketika Anda memutuskan di mana menyimpan file.

Petunjuk / Saran

Saat menyimpan data di OneLake, pertimbangkan untuk mengaktifkan Kelangsungan Bisnis dan Pemulihan Bencana (BCDR) untuk mengurangi risiko kehilangan data. Dengan diaktifkannya BCDR, data Anda diduplikasi dan disimpan di dua wilayah geografis yang berbeda, sesuai dengan pasangan wilayah standar Azure.

Repositori jarak jauh

Pembuat konten dapat menerapkan dan menyimpan pekerjaan dari komputer lokal mereka ke repositori jarak jauh—seperti repositori Azure Repos atau GitHub Git—secara berkala selama pengembangan. Repositori jarak jauh berisi versi terbaru konten atau file pendukung, dan dapat diakses oleh seluruh tim pengembangan. Biasanya, repositori jarak jauh memfasilitasi pendekatan manajemen siklus hidup yang lebih canggih daripada menggunakan Teams, SharePoint, atau OneDrive. Itu karena dengan menggunakan repositori jarak jauh, pembuat konten dapat memperoleh manfaat dari opsi yang lebih canggih untuk berkolaborasi pada file, atau melacak dan mengelola perubahan file. Misalnya, pembuat konten dapat bekerja di cabang repositori jarak jauh mereka sendiri untuk membuat perubahan, dan meminta untuk menggabungkan perubahan tersebut ke cabang utama ketika siap.

Pertimbangkan untuk menyimpan jenis file berikut di repositori jarak jauh.

• Templat dan dokumentasi: Menyimpan templat dan dokumentasi di repositori jarak jauh saat Anda mengelola proyek dengan layanan terkait seperti Azure DevOps.
• File pendukung: Simpan file pendukung di repositori jarak jauh ketika tersedia untuk melacak dan mengelola perubahan dengan mudah.
• File konten: Simpan konten di repositori jarak jauh saat penting bagi bisnis, atau Anda berniat untuk berkolaborasi dengan pengembang lain pada konten yang sama. Repositori jarak jauh sangat ideal untuk melacak perubahan konten dan memfasilitasi kolaborasi.

Petunjuk / Saran

Saat Anda menggunakan repositori jarak jauh, kami sangat menyarankan Agar Anda menyimpan laporan Power BI dan model semantik sebagai file proyek Power BI Desktop (.pbip) alih-alih file .pbix. Itu karena perubahan yang disimpan tidak dapat diidentifikasi dalam file .pbix.

Selain itu, pertimbangkan untuk menggunakan format laporan yang disempurnakan Power BI (PBIR) untuk laporan. Format PBIR memastikan bahwa metadata laporan lebih mudah dibaca, yang membuat pelacakan dan pengelolaan perubahan dalam kontrol sumber lebih mudah. Selain itu, laporan yang menggunakan format ini dapat lebih mudah dikelola oleh alat terprogram seperti semantic-link-labs, pustaka Python dari Microsoft yang dapat Anda gunakan di notebook Fabric.

Tidak ada file: Konten yang dibuat di portal Fabric

Pembuat konten dapat menulis konten langsung di portal Fabric. Dalam skenario ini, mereka biasanya tidak bekerja langsung dengan file konten. Anda biasanya harus menulis konten di portal Fabric hanya ketika jenis item tidak dapat dibuat di tempat lain (seperti aliran data, dasbor, atau kartu skor). Anda juga dapat menulis laporan dan model semantik di portal Fabric saat tidak memiliki akses ke komputer Windows, dan karenanya tidak dapat menggunakan Power BI Desktop. Untuk informasi selengkapnya, lihat Alat dan perangkat pengguna.

Perhatian

Anda tidak dapat mengunduh sebagai file beberapa konten yang dibuat di portal Fabric. Misalnya, laporan yang dibuat di portal Fabric tidak dapat diunduh sebagai file .pbix.

Saat menulis konten di portal Fabric, Anda harus menggunakan FABRIC API atau integrasi Git untuk mencadangkan definisi konten. Saat Anda mencadangkan definisi konten, Anda mengurangi gangguan jika konten tersebut dihapus secara tidak sengaja atau mengalami perubahan yang tidak diinginkan. Jika konten dihapus atau diubah secara tidak sengaja, Anda dapat menggantinya dengan menggunakan cadangan.

Daftar periksa - Saat merencanakan dan merancang konten, keputusan dan tindakan utama meliputi:

• Melakukan perencanaan solusi: Kumpulkan persyaratan bisnis dan persyaratan teknis untuk cukup memahami masalah yang akan ditangani konten Anda, dan untuk merancang bagaimana konten ini akan mengatasi masalah.
• Identifikasi siapa yang akan membuat konten: Bergantung pada alur kerja, keterampilan, dan kebutuhan masing-masing pembuat konten, pendekatan yang berbeda untuk manajemen siklus hidup mungkin diperlukan.
• Identifikasi apakah beberapa pembuat konten perlu berkolaborasi: Pastikan pembuat konten yang berkolaborasi menggunakan jenis file yang mendukung kontrol versi, seperti file .pbip.
• Tentukan bagaimana pembuat konten akan berkolaborasi: Tentukan seberapa canggih kolaborasi tersebut. Selain itu, putuskan bagaimana Anda akan memfasilitasi kolaborasi ini, seperti dengan menggunakan Microsoft Teams, Azure DevOps, atau GitHub.
• Tentukan format konten: Tentukan apakah model dan laporan semantik Power BI akan terdiri dari file .pbix atau .pbip (atau format lain seperti .bim atau .tmdl untuk model), dan apakah laporan akan menggunakan format PBIR atau tidak.
• Tentukan bagaimana konten akan digunakan: Mengevaluasi bagaimana pengguna akan terlibat dengan data. Tentukan jenis item mana yang perlu Anda buat untuk mendukung konsumsi, dan apakah pengguna hanya memerlukan izin baca, atau juga membangun izin ke model semantik yang mendasar atau item data lainnya. Jika pengguna memerlukan izin build, tentukan sejak dini bagaimana mereka akan menggunakan model semantik, dan bagaimana Anda akan melatih mereka untuk melakukan ini, secara efektif.
• Menyiapkan alat kolaborasi: Pastikan Anda melakukan penyiapan pertama kali yang diperlukan untuk solusi atau proyek. Buat keputusan utama tentang bagaimana Anda akan mengelola kolaborasi dengan menggunakan alat-alat ini.
• Menyimpan file sumber data di SharePoint atau OneLake: Menyimpan file sumber data kecil dan sederhana di SharePoint. Jika tidak, gunakan OneLake atau ADLSGen2 (jika tersedia) sebagai gantinya.
• Simpan konten dan file pendukung di SharePoint, Microsoft Teams, atau repositori Git: Untuk proyek yang lebih sederhana dan lebih kecil, gunakan SharePoint untuk sebagian besar file jika diatur dan Anda mempraktikkan manajemen akses yang baik. Untuk lingkungan yang lebih besar atau ketika kolaborasi paralel diperlukan, pertimbangkan untuk menggunakan repositori Git di GitHub atau Azure DevOps, yang akan memberikan visibilitas terperinci tentang perubahan konten.
• Menyimpan templat dan dokumentasi di Microsoft Teams atau SharePoint: Templat dan dokumentasi ini ditujukan untuk komunitas pengguna. Pastikan templat dan dokumentasi mudah ditemukan, digunakan, dan dipahami orang lain.
• Rencanakan pengembangan dan penyebaran: Untuk menyimpulkan tahap pertama ini, lakukan perencanaan khusus untuk mengatasi area utama dan melakukan penyiapan awal. Misalnya, buat alat dan uji koneksi sumber data.

Konten terkait

Di artikel berikutnya dalam seri ini, pelajari cara mengembangkan konten dan mengelola perubahan sebagai bagian dari mengelola siklus hidup konten.