Perencanaan implementasi Power BI: Perencanaan solusi BI

Catatan

Artikel ini merupakan bagian dari rangkaian artikel Perencanaan implementasi Power BI. Seri ini berfokus terutama pada pengalaman Power BI dalam Microsoft Fabric. Untuk pengantar rangkaian ini, lihat Perencanaan implementasi Power BI.

Artikel ini membantu Anda merencanakan solusi yang mendukung strategi kecerdasan bisnis (BI) Anda. Ini terutama ditargetkan pada:

• Direktur atau manajer BI dan analitik: Pengarah keputusan yang bertanggung jawab untuk mengawasi program BI dan solusi BI yang sangat penting.
• Tim Center of Excellence (COE), IT, dan BI: Tim yang merancang dan menyebarkan solusi BI perusahaan untuk organisasi mereka.
• Pakar subjek (UKM) dan pemilik konten dan pembuat: Tim dan individu yang memperjuangkan analitik di departemen dan merancang dan menyebarkan solusi untuk skenario penggunaan layanan mandiri, BI departemen, atau bi tim.

Strategi BI adalah rencana untuk menerapkan, menggunakan, dan mengelola data dan analitik. Anda menentukan strategi BI Anda dengan memulai perencanaan strategis BI. Perencanaan strategis membantu Anda mengidentifikasi area dan tujuan fokus BI Anda. Untuk menentukan jalur untuk maju menuju tujuan BI Anda, Anda menjelaskan hasil utama tertentu dengan menggunakan perencanaan taktis. Anda kemudian mencapai kemajuan menuju hasil utama ini dengan merencanakan dan menyebarkan solusi BI.

Catatan

Dalam kerangka kerja tujuan dan hasil utama (OKR), tujuannya jelas, deskripsi tingkat tinggi tentang apa yang ingin Anda capai. Sebaliknya, hasil utama adalah hasil yang spesifik dan dapat dicapai untuk mengukur kemajuan menuju salah satu tujuan Anda.

Selanjutnya, inisiatif atau solusi adalah proses atau alat yang dibuat untuk membantu Anda mencapai satu atau beberapa hasil utama. Solusi memenuhi kebutuhan data tertentu untuk pengguna. Solusi dapat mengambil banyak formulir, seperti alur data, data lakehouse, atau model atau laporan semantik Power BI.

Untuk informasi selengkapnya tentang OKR, lihat Mengenal OKR (Tujuan Microsoft Viva).

Ada banyak pendekatan untuk merencanakan dan menerapkan solusi BI. Artikel ini menjelaskan salah satu pendekatan yang dapat Anda ambil untuk merencanakan dan menerapkan solusi BI yang mendukung strategi BI Anda.

Diagram tingkat tinggi berikut menggambarkan cara melakukan perencanaan solusi BI.

Anda mengambil langkah-langkah berikut untuk melakukan perencanaan solusi BI.

Langkah	Keterangan
1	Merakit tim proyek yang mengumpulkan persyaratan dan mendefinisikan desain solusi.
2	Rencanakan penyebaran solusi dengan melakukan penyiapan awal alat dan proses.
3	Lakukan solusi proof of concept (POC) untuk memvalidasi asumsi tentang desain.
4	Buat dan validasi konten dengan menggunakan siklus pengembangan dan validasi berulang.
5	Sebarkan, dukung, dan pantau solusi setelah dirilis ke lingkungan produksi.

Catatan

Perencanaan solusi BI berlaku untuk proyek BI swalayan dan BI perusahaan.

Untuk informasi selengkapnya, lihat seri migrasi Power BI. Meskipun seri ini berkaitan dengan migrasi, tindakan dan pertimbangan utama relevan dengan perencanaan solusi.

Langkah 1: Kumpulkan persyaratan

Anda memulai perencanaan solusi dengan terlebih dahulu mengumpulkan persyaratan dan menentukan desain solusi.

Catatan: Perencanaan strategis dan taktis dipimpin oleh tim kerja, yang memimpin inisiatif. Sebaliknya, perencanaan solusi dipimpin oleh tim proyek, yang terdiri dari pemilik konten dan pembuat.

Mengumpulkan persyaratan yang tepat sangat penting untuk mencapai penyebaran dan adopsi solusi yang sukses. Cara efektif untuk mengumpulkan persyaratan adalah dengan mengidentifikasi dan melibatkan pemangku kepentingan yang tepat, secara kolaboratif menentukan masalah yang akan diselesaikan, dan menggunakan pemahaman bersama tentang masalah tersebut untuk membuat desain solusi.

Berikut adalah beberapa manfaat dari menggunakan pendekatan kolaboratif untuk mengumpulkan persyaratan.

• Input pengguna menghasilkan desain yang lebih berguna: Dengan melibatkan pengguna dalam diskusi yang berfokus untuk mengumpulkan persyaratan, Anda dapat lebih efektif menangkap kebutuhan data bisnis. Misalnya, pengguna dapat menunjukkan kepada pembuat konten bagaimana mereka menggunakan solusi yang ada dan memberikan umpan balik tentang efektivitas yang dirasakan dari solusi ini.
• Hindari asumsi dan mitigasi permintaan perubahan: Diskusi dengan pengguna sering mengungkapkan nuansa, pengecualian, dan kompleksitas tersembunyi. Wawasan ini mengurangi kemungkinan permintaan tahap akhir, yang dapat mahal untuk ditangani.
• Pengguna onboarding meningkatkan adopsi solusi: Dengan melibatkan pengguna dalam desain dan pengembangan awal, Anda memberi mereka kesempatan untuk memengaruhi hasil akhir. Keterlibatan juga dapat memberi pengguna rasa kepemilikan intelektual dan akuntabilitas untuk solusi. Pengguna yang sangat terlibat akan lebih cenderung mendukung solusi dan memimpin komunitas praktik mereka dalam menggunakannya secara efektif.
• Desain menetapkan harapan bagi pemangku kepentingan dan pengguna bisnis: Dengan menghasilkan mock-up atau ilustrasi desain solusi, Anda dapat dengan jelas menunjukkan kepada pemangku kepentingan apa yang akan diberikan solusi. Ini juga membantu dengan menciptakan pemahaman bersama tentang hasil proyek yang diharapkan. Proses ini juga dikenal sebagai pemikiran desain, dan dapat menjadi cara yang efektif untuk mendekati dan memahami masalah yang kompleks.

Anda dapat mengambil pendekatan yang berbeda untuk melibatkan pengguna dan mengumpulkan persyaratan. Misalnya, Anda dapat mengumpulkan persyaratan dengan desain bisnis dan desain teknis (dijelaskan secara rinci di bagian selanjutnya dari artikel ini).

Desain bisnis adalah pendekatan untuk mengumpulkan persyaratan bisnis. Ini berfokus pada melibatkan pengguna bisnis dalam sesi desain bisnis untuk merancang solusi secara kolaboratif. Output desain bisnis terdiri dari mock-up solusi dan dokumentasi desain deskriptif.

Desain teknis adalah pendekatan untuk menerjemahkan persyaratan bisnis ke persyaratan teknis, dan untuk mengatasi asumsi desain. Desain teknis berfokus pada validasi desain bisnis dan menentukan pendekatan teknis untuk digunakan. Untuk memvalidasi desain, pembuat konten biasanya terlibat dengan pakar teknis dalam diskusi terfokus yang disebut sesi desain teknis, jika perlu.

Penting

Mengumpulkan persyaratan yang salah adalah alasan umum mengapa implementasi gagal. Seringkali, tim mengumpulkan persyaratan yang salah karena mereka terlibat dengan pemangku kepentingan yang salah, seperti pembuat keputusan yang memberikan permintaan top-down untuk solusi yang akan dibangun.

Melibatkan pengguna bisnis dengan menggunakan pendekatan kolaboratif seperti desain bisnis dapat membantu Anda mengumpulkan persyaratan yang lebih baik. Persyaratan yang lebih baik sering menyebabkan pengembangan yang lebih efisien dan solusi yang lebih kuat.

Catatan

Bagi beberapa tim, mengadopsi proses pengumpulan persyaratan terstruktur adalah perubahan besar. Pastikan Anda mengelola perubahan ini, dan tidak mengganggu perencanaan solusi. Kami menyarankan agar Anda menemukan cara untuk menyesuaikan pendekatan ini agar sesuai dengan cara kerja tim Anda.

Bersiap untuk perencanaan solusi

Anda harus terlebih dahulu mempersiapkan perencanaan solusi dengan mempertimbangkan faktor-faktor yang dijelaskan di bagian berikut.

• Identifikasi siapa yang akan melakukan perencanaan solusi: Sebagai bagian dari perencanaan taktis BI, tim kerja membuat backlog solusi yang diprioritaskan. Dalam perencanaan solusi, tim proyek bertanggung jawab untuk merancang, mengembangkan, dan menyebarkan satu atau beberapa solusi dari backlog. Untuk setiap solusi di backlog, Anda harus merakit tim proyek yang akan bertanggung jawab atas solusi. Selain menjalankan perencanaan solusi BI, tim proyek harus:
  • Tentukan garis waktu dan tonggak pencapaian untuk perencanaan solusi.
  • Identifikasi dan libatkan pemangku kepentingan yang tepat untuk pengumpulan persyaratan.
  • Siapkan lokasi terpusat untuk komunikasi, dokumentasi, dan perencanaan.
  • Libatkan pemangku kepentingan untuk mengumpulkan persyaratan.
  • Berkomunikasi dan berkoordinasi dengan pemangku kepentingan dan pengguna bisnis.
  • Mengatur siklus pengembangan dan pengujian berulang dengan pengguna bisnis.
  • Dokumentasikan solusinya.
  • Onboard pengguna ke solusi dengan mendefinisikan dan memberlakukan rencana pelatihan.
  • Berikan dukungan solusi pasca-penyebaran.
  • Atasi permintaan pengguna yang wajar untuk mengubah atau memperbarui solusi setelah penyebaran.
  • Lakukan penyerahan solusi setelah penyebaran, jika perlu.
• Mempusatkan komunikasi dan dokumentasi: Penting bagi tim proyek untuk mempusatkan komunikasi dan dokumentasi untuk perencanaan solusi BI. Misalnya, tim proyek harus memusatkan persyaratan, komunikasi pemangku kepentingan, garis waktu, dan hasil kerja. Pertimbangkan untuk menyimpan semua dokumentasi di portal terpusat.
• Merencanakan pengumpulan persyaratan: Tim proyek harus dimulai dengan merencanakan sesi desain bisnis untuk mengumpulkan persyaratan bisnis. Sesi ini berbentuk pertemuan interaktif, dan mereka dapat mengikuti format yang mirip dengan lokakarya perencanaan strategis.

Tip

Pertimbangkan untuk mengidentifikasi dan melibatkan tim dukungan yang bertanggung jawab atas solusi di awal proses pengumpulan persyaratan. Untuk mendukung solusi secara efektif, tim dukungan akan membutuhkan pemahaman komprehensif tentang solusi, tujuannya, dan pengguna. Itu sangat penting ketika tim proyek hanya terdiri dari konsultan eksternal.

Mengumpulkan persyaratan bisnis

Mengumpulkan persyaratan bisnis yang tepat sangat penting untuk merancang solusi yang tepat. Untuk mengumpulkan persyaratan yang tepat dan menentukan desain solusi yang efektif, tim proyek dapat melakukan sesi desain bisnis bersama dengan pengguna bisnis.

Tujuan dari sesi desain bisnis adalah untuk:

• Konfirmasikan cakupan solusi awal.
• Tentukan dan pahami masalah yang harus ditangani solusi.
• Identifikasi pemangku kepentingan utama yang tepat untuk solusi tersebut.
• Kumpulkan persyaratan bisnis yang tepat.
• Siapkan desain solusi yang memenuhi persyaratan bisnis.
• Siapkan dokumentasi desain pendukung.

Diagram berikut menggambarkan cara mengumpulkan persyaratan bisnis dan menentukan desain solusi dengan menggunakan pendekatan desain bisnis.

Diagram menggambarkan langkah-langkah berikut.

Benda	Keterangan
	Tim proyek memulai desain bisnis dengan mengonfirmasi cakupan solusi yang pertama kali didokumenkan dalam perencanaan taktis. Mereka harus mengklarifikasi area bisnis, sistem, dan data yang akan dicakup solusi.
	Tim proyek mengidentifikasi pemangku kepentingan utama dari komunitas pengguna yang akan terlibat dalam sesi desain bisnis. Pemangku kepentingan utama adalah pengguna dengan pengetahuan dan kredibilitas yang memadai untuk mewakili bidang subjek solusi.
	Tim proyek merencanakan sesi desain bisnis. Perencanaan melibatkan menginformasikan pemangku kepentingan, mengatur rapat, menyiapkan hasil, dan terlibat dengan pengguna bisnis.
	Tim proyek mengumpulkan dan meneliti solusi yang ada yang saat ini digunakan pengguna bisnis untuk memenuhi kebutuhan data bisnis yang ada. Untuk mempercepat proses ini, tim proyek dapat menggunakan penelitian yang relevan dari perencanaan strategis BI, yang telah didokumenkan di hub komunikasi.
	Tim proyek menjalankan sesi desain bisnis dengan pemangku kepentingan. Sesi ini adalah pertemuan kecil dan interaktif, di mana tim proyek memandu pemangku kepentingan untuk memahami kebutuhan dan persyaratan data bisnis.
	Tim proyek menyimpulkan desain bisnis dengan menyajikan rancangan desain solusi kepada pemangku kepentingan dan pengguna lain untuk umpan balik dan persetujuan. Desain bisnis berhasil ketika para pemangku kepentingan setuju bahwa desain akan membantu mereka mencapai tujuan bisnis mereka.

Desain bisnis menyimpulkan dengan hasil kerja berikut.

• Desain solusi draf: Diagram mock-up, prototipe, atau wireframe mengilustrasikan desain solusi. Dokumen-dokumen ini menerjemahkan persyaratan ke cetak biru desain konkret.
• Daftar metrik bisnis: Bidang kuantitatif yang diharapkan dalam solusi, termasuk definisi bisnis, dan agregasi yang diharapkan. Jika memungkinkan, beri peringkat berdasarkan kepentingan kepada pengguna.
• Daftar atribut bisnis: Atribut dan struktur data yang relevan yang diharapkan dalam solusi, termasuk definisi bisnis dan nama atribut. Jika memungkinkan, sertakan hierarki dan beri peringkat atribut berdasarkan kepentingan kepada pengguna.
• Dokumentasi tambahan: Deskripsi persyaratan fungsi atau kepatuhan utama. Dokumentasi ini harus setepat yang diperlukan, namun sesingkat mungkin.

Hasil desain bisnis digunakan dalam, dan divalidasi oleh, desain teknis.

Tip

Solusi mock-up, prototipe, atau diagram wireframe dapat menciptakan pemahaman yang jelas tentang hasil yang diharapkan, baik untuk pengembang maupun pengguna akhir. Membuat mock-up yang efektif tidak memerlukan keterampilan atau bakat artistik. Anda dapat menggunakan alat sederhana seperti Microsoft Whiteboard, PowerPoint, atau bahkan hanya pena dan kertas untuk mengilustrasikan desain.

Mengumpulkan persyaratan teknis

Setelah menyelesaikan desain bisnis, tim proyek memvalidasi hasilnya dengan menggunakan desain teknis. Desain teknis adalah pendekatan yang mirip dengan desain bisnis. Sementara desain bisnis berfokus pada kebutuhan data bisnis, desain teknis berfokus pada aspek teknis solusi. Hasil utama dari desain teknis adalah rencana solusi, yang menjelaskan desain solusi akhir dan perkiraan terinformasi tentang upaya untuk mengimplementasikannya.

Catatan

Tidak seperti desain bisnis, desain teknis sebagian besar merupakan penyelidikan independen terhadap data sumber dan sistem yang dilakukan oleh pembuat konten dan pemilik.

Tujuan dari desain teknis adalah untuk:

• Validasi hasil desain bisnis.
• Atasi asumsi teknis dalam desain saat ini.
• Identifikasi sumber data yang relevan dalam cakupan, dan tentukan perhitungan bidang dan pemetaan sumber bidang untuk setiap sumber data.
• Terjemahkan persyaratan bisnis ke persyaratan teknis.
• Menghasilkan estimasi upaya yang diperlukan untuk implementasi.

Tim proyek melibatkan pemangku kepentingan teknis atau fungsi dalam sesi desain teknis yang terbatas dan terfokus. Sesi ini adalah pertemuan interaktif dengan pemangku kepentingan fungsi untuk mengumpulkan persyaratan teknis. Pemangku kepentingan bertanggung jawab atas area fungsi tertentu yang diperlukan agar solusi berfungsi secara efektif.

Contoh pemangku kepentingan dalam desain teknis dapat berupa:

• Tim keamanan dan jaringan: Bertanggung jawab untuk memastikan keamanan dan kepatuhan data.
• Tim fungsional dan pengurus data: Bertanggung jawab untuk mengumpulkan data sumber.
• Arsitek: Pemilik platform, alat, atau teknologi tertentu.

Tim proyek melibatkan pemangku kepentingan dalam sesi desain teknis untuk mengatasi aspek teknis solusi. Aspek teknis dapat mencakup:

• Koneksi sumber data: Detail tentang cara menyambungkan, dan mengintegrasikan, sumber data.
• Jaringan dan gateway data: Detail tentang jaringan privat atau sumber data lokal.
• Pemetaan sumber bidang: Pemetaan data metrik dan atribut bisnis ke bidang sumber data.
• Logika perhitungan: Terjemahan definisi bisnis ke perhitungan teknis.
• Fitur teknis: Fitur atau fungsionalitas yang diperlukan untuk mendukung persyaratan bisnis.

Tip

Tim proyek yang melakukan desain bisnis juga harus melakukan desain teknis. Namun, karena alasan praktis, individu yang berbeda dapat memimpin desain teknis. Dalam hal ini, mulai desain teknis dengan meninjau hasil desain bisnis.

Idealnya, individu yang memimpin desain teknis harus memiliki pemahaman menyeluruh tentang hasil dan pengguna bisnis.

Diagram berikut menggambarkan cara menerjemahkan persyaratan bisnis ke dalam persyaratan teknis dengan menggunakan desain teknis.

Diagram menggambarkan langkah-langkah berikut.

Benda	Keterangan
	Tim proyek memulai desain teknis dengan menentukan cakupan sumber data berdasarkan hasil desain bisnis. Cakupan sumber data menyatakan data mana yang diperlukan untuk membangun solusi. Untuk mengidentifikasi sumber data yang tepat, tim proyek berkonsultasi dengan UKM bisnis dan fungsi.
	Tim proyek mengidentifikasi pemangku kepentingan teknis atau fungsi untuk melibatkan nanti dalam sesi desain teknis.
	Tim proyek merencanakan sesi terbatas dan terfokus dengan pemangku kepentingan fungsi untuk mengatasi aspek teknis solusi. Perencanaan melibatkan menginformasikan pemangku kepentingan, mengatur rapat, dan menyiapkan hasil.
	Tim proyek meneliti persyaratan teknis. Penelitian mencakup menentukan perhitungan bidang dan pemetaan sumber data, dan juga mengatasi asumsi desain bisnis dengan analisis teknis dan dokumentasi.
	Jika perlu, tim proyek melibatkan pemangku kepentingan dalam sesi desain teknis. Sesi berfokus pada aspek teknis tertentu dari solusi, seperti koneksi keamanan atau sumber data. Dalam sesi ini, tim proyek mengumpulkan umpan balik kualitatif dari pemangku kepentingan dan UKM.
	Tim proyek menyiapkan temuan mereka dengan menggunakan rencana solusi, yang mereka sajikan kepada pemangku kepentingan dan pembuat keputusan. Rencana ini adalah perulangan dan ekstensi hasil desain bisnis yang mencakup desain akhir, estimasi, dan hasil pengiriman lainnya.
	Desain teknis harus disimpulkan dengan rapat akhir dengan pemangku kepentingan dan pengambil keputusan untuk memutuskan apakah akan melanjutkan atau tidak. Rapat ini memberikan kesempatan terakhir untuk mengevaluasi perencanaan solusi sebelum sumber daya berkomitmen untuk mengembangkan solusi.

Catatan

Desain teknis mungkin mengungkapkan kompleksitas tak terduga yang dapat membuat perencanaan solusi tidak layak mengingat ketersediaan sumber daya saat ini atau kesiapan organisasi. Dalam hal ini, solusi harus dievaluasi kembali dalam periode perencanaan taktis berikutnya. Tergantung pada urgensi kebutuhan data bisnis, pembuat keputusan, seperti sponsor eksekutif, mungkin masih ingin melanjutkan dengan bukti konsep, atau hanya satu bagian dari solusi yang direncanakan.

Desain teknis disimpulkan dengan rencana solusi, yang terdiri dari hasil kerja berikut.

• Alat dan teknologi: Daftar instrumen teknis relevan yang diperlukan untuk mengimplementasikan solusi. Daftar ini biasanya mencakup opsi lisensi baru yang relevan (seperti kapasitas Fabric atau Premium per pengguna), fitur, dan alat.
• Daftar metrik bisnis yang ditentukan: Perhitungan dan pemetaan sumber bidang metrik bisnis untuk semua sumber data dalam cakupan. Untuk menghasilkan hasil ini, tim proyek menggunakan daftar metrik bisnis yang dibuat dalam desain bisnis.
• Daftar atribut bisnis yang ditentukan: Pemetaan sumber bidang atribut bisnis untuk semua sumber data dalam cakupan. Untuk menghasilkan hasil ini, tim proyek menggunakan daftar atribut bisnis yang dibuat dalam desain bisnis.
• Desain yang direvisi: Revisi pada desain solusi berdasarkan perubahan pada, atau asumsi yang tidak valid tentang, desain bisnis. Desain yang direvisi adalah versi terbaru dari diagram mock-up, prototipe, atau wireframe yang diproduksi dalam desain bisnis. Jika tidak ada revisi yang diperlukan, komunikasikan bahwa desain teknis memvalidasi desain bisnis.
• Perkiraan upaya: Perkiraan sumber daya yang diperlukan untuk mengembangkan, mendukung, dan memelihara solusi. Perkiraan menginformasikan keputusan akhir tentang apakah akan melanjutkan penerapan solusi, atau tidak.

Penting

Pastikan bahwa tim proyek memberi tahu pemangku kepentingan tentang setiap perubahan atau penemuan tak terduga dari desain teknis. Sesi desain teknis ini masih harus melibatkan pengguna bisnis yang relevan. Namun, pastikan bahwa pemangku kepentingan tidak perlu terpapar informasi teknis yang kompleks.

Tip

Karena tujuan bisnis sangat berkembang, diharapkan persyaratan akan berubah. Jangan berasumsi bahwa persyaratan untuk proyek BI telah diperbaiki. Jika Anda berjuang dengan perubahan persyaratan, mungkin merupakan indikasi bahwa proses pengumpulan persyaratan Anda tidak efektif, atau bahwa alur kerja pengembangan Anda tidak cukup memasukkan umpan balik reguler.

Daftar periksa - Saat mengumpulkan persyaratan, keputusan dan tindakan utama meliputi:

• Klarifikasi siapa yang memiliki perencanaan solusi: Untuk setiap solusi, pastikan bahwa peran dan tanggung jawab jelas untuk tim proyek.
• Klarifikasi cakupan solusi: Cakupan solusi harus sudah didokumentasikan sebagai bagian dari perencanaan taktis BI. Anda mungkin perlu menghabiskan waktu dan upaya tambahan untuk mengklarifikasi cakupan sebelum memulai perencanaan solusi.
• Mengidentifikasi dan menginformasikan pemangku kepentingan: Mengidentifikasi pemangku kepentingan untuk desain bisnis dan desain teknis. Beri tahu mereka terlebih dahulu tentang proyek dan jelaskan cakupan, tujuan, investasi waktu yang diperlukan, dan hasil dari desain bisnis.
• Merencanakan dan melakukan sesi desain bisnis: Memoderasi sesi desain bisnis untuk memunculkan informasi dari pemangku kepentingan dan pengguna bisnis. Minta agar pengguna menunjukkan cara mereka menggunakan solusi yang ada.
• Mendokumentasikan metrik dan atribut bisnis: Dengan menggunakan solusi dan input yang ada dari pemangku kepentingan, buat daftar metrik dan atribut bisnis. Dalam desain teknis, petakan bidang ke sumber data dan jelaskan logika perhitungan untuk bidang kuantitatif.
• Menyusun desain solusi: Buat mock-up berulang berdasarkan input pemangku kepentingan yang secara visual mencerminkan hasil solusi yang diharapkan. Pastikan bahwa tiruan mewakili dan memenuhi persyaratan bisnis secara akurat. Berkomunikasi dengan pengguna bisnis bahwa mock-up masih harus divalidasi (dan mungkin direvisi) selama desain teknis.
• Buat rencana solusi: Data sumber penelitian dan pertimbangan teknis yang relevan untuk memastikan bahwa desain bisnis dapat dicapai. Jika relevan, jelaskan risiko dan ancaman utama terhadap desain, dan pendekatan alternatif apa pun. Jika perlu, siapkan revisi desain solusi dan diskusikan dengan pemangku kepentingan.
• Buat perkiraan upaya: Sebagai bagian dari rencana solusi akhir, perkirakan upaya untuk membangun dan mendukung solusi. Ratakan perkiraan ini dengan informasi yang dikumpulkan selama sesi desain bisnis dan desain teknis.
• Memutuskan apakah akan melanjutkan rencana: Untuk menyimpulkan proses pengumpulan persyaratan, sajikan rencana akhir kepada pemangku kepentingan dan pembuat keputusan. Tujuan dari pertemuan ini adalah untuk menentukan apakah akan melanjutkan pengembangan solusi.

Langkah 2: Merencanakan penyebaran

Ketika tim proyek menyelesaikan persyaratan pengumpulan, membuat rencana solusi, dan menerima persetujuan untuk melanjutkan, tim proyek siap untuk merencanakan penyebaran solusi.

Tugas perencanaan penyebaran berbeda tergantung pada solusi, alur kerja pengembangan Anda, dan proses penyebaran Anda. Rencana penyebaran biasanya berkaitan dengan banyak aktivitas yang melibatkan perencanaan dan penyiapan alat dan proses untuk solusi.

Rencanakan untuk mengatasi area utama

Tim proyek harus merencanakan area utama penyebaran solusi. Biasanya, perencanaan harus membahas area berikut.

• Kepatuhan: Pastikan bahwa semua kriteria kepatuhan yang diidentifikasi dalam pengumpulan persyaratan akan ditangani oleh tindakan tertentu. Tetapkan masing-masing tindakan ini untuk orang tertentu, dan tentukan jangka waktu pengiriman dengan jelas.
• Keamanan: Tentukan bagaimana berbagai lapisan akses solusi akan dikelola, dan persyaratan aturan keamanan data apa pun. Tinjau apakah keamanan solusi akan lebih atau kurang ketat daripada konten standar di penyewa.
• Gateway data: Mengevaluasi apakah solusi memerlukan gateway data untuk menyambungkan ke sumber data. Tentukan apakah pengaturan gateway tertentu atau kluster ketersediaan tinggi diperlukan. Rencanakan siapa yang akan dapat mengelola koneksi gateway melalui peran keamanan gateway, dan cara memantau gateway. Untuk informasi selengkapnya, lihat Menyediakan akses gateway.
• Ruang kerja: Tentukan cara menyiapkan dan menggunakan ruang kerja. Tentukan apakah solusi memerlukan alat manajemen siklus hidup seperti integrasi Git dan alur penyebaran, dan apakah memerlukan pengelogan tingkat lanjut dengan Azure Log Analytics.
• Dukungan: Menetapkan siapa yang bertanggung jawab untuk mendukung dan memelihara solusi setelah penyebaran produksi. Jika individu yang bertanggung jawab atas dukungan berbeda dari tim proyek, libatkan individu ini dalam pengembangan. Pastikan siapa pun yang akan mendukung solusi memahami desain solusi, masalah yang harus diatasi, siapa yang harus menggunakannya, dan bagaimana.
• Pelatihan pengguna: Mengantisipasi upaya yang diperlukan untuk melatih komunitas pengguna sehingga mereka dapat menggunakan solusi secara efektif. Pertimbangkan apakah diperlukan tindakan manajemen perubahan tertentu.
• Tata kelola: Identifikasi potensi risiko tata kelola untuk solusi. Antisipasi upaya yang diperlukan untuk memungkinkan pengguna menggunakan solusi secara efektif, sambil mengurangi risiko tata kelola apa pun (misalnya, dengan menggunakan label dan kebijakan sensitivitas).

Melakukan penyiapan awal

Tim proyek harus melakukan pengaturan awal untuk memulai pengembangan. Aktivitas penyiapan awal dapat mencakup:

• Alat dan proses awal: Lakukan penyiapan pertama kali untuk alat dan proses baru apa pun yang diperlukan untuk pengembangan, pengujian, dan penyebaran.
• Identitas dan kredensial: Membuat grup keamanan dan perwakilan layanan yang akan digunakan untuk mengakses alat dan sistem. Menyimpan kredensial dengan efektif dan aman.
• Gateway data:Menyebarkan gateway data untuk sumber data lokal (gateway mode perusahaan) atau sumber data di jaringan privat (jaringan virtual, atau VNet, gateway).
• Ruang kerja dan repositori: Membuat dan menyiapkan ruang kerja dan repositori jarak jauh untuk menerbitkan dan menyimpan konten.

Catatan

Perencanaan penyebaran berbeda tergantung pada solusi dan alur kerja pilihan Anda. Artikel ini hanya menjelaskan tentang perencanaan tingkat tinggi dan item yang dapat ditindaklaksikan.

Untuk informasi selengkapnya tentang perencanaan penyebaran, lihat Merencanakan penyebaran untuk bermigrasi ke Power BI.

Daftar periksa - Saat merencanakan penyebaran solusi, keputusan dan tindakan utama meliputi:

• Rencanakan area utama: Rencanakan untuk mengatasi proses dan alat yang Anda butuhkan untuk berhasil mengembangkan dan menyebarkan solusi Anda. Atasi area teknis (seperti gateway data atau ruang kerja) dan juga adopsi (seperti pelatihan dan tata kelola pengguna).
• Lakukan penyiapan awal: Buat alat, proses, dan fitur yang Anda butuhkan untuk mengembangkan dan menyebarkan solusi. Dokumentasikan penyiapan untuk membantu orang lain yang perlu melakukan penyiapan pertama kali di masa mendatang.
• Uji koneksi sumber data: Validasi bahwa komponen dan proses yang sesuai ada untuk terhubung ke data yang tepat untuk memulai bukti konsep.

Langkah 3: Melakukan bukti konsep

Tim proyek melakukan bukti konsep solusi (POC) untuk memvalidasi asumsi yang luar biasa dan untuk menunjukkan manfaat awal bagi pengguna bisnis. POC adalah implementasi desain awal yang terbatas dalam cakupan dan kematangan. POC yang dijalankan dengan baik sangat penting untuk solusi besar atau kompleks karena dapat mengidentifikasi dan mengatasi kompleksitas (atau pengecualian) yang tidak terdeteksi dalam desain teknis.

Sebaiknya pertimbangkan pertimbangan berikut saat menyiapkan POC.

• Tujuan dan cakupan: Menjelaskan tujuan SOLUSI POC dan area fungsi yang akan ditanganinya. Misalnya, tim proyek dapat memutuskan untuk membatasi POC ke satu area fungsional, atau serangkaian persyaratan atau fitur tertentu.
• Data sumber: Identifikasi data apa yang akan digunakan dalam POC. Bergantung pada solusinya, tim proyek mungkin memutuskan untuk menggunakan berbagai jenis data, seperti:
  • Data produksi (riil)
  • Data sampel
  • Data sintetis yang dihasilkan yang menyerupan volume data aktual dan kompleksitas yang diamati di lingkungan produksi
• Demonstrasi: Jelaskan bagaimana dan kapan tim proyek akan menunjukkan POC kepada pemangku kepentingan dan pengguna. Demonstrasi dapat diberikan selama pembaruan rutin, atau ketika POC memenuhi kriteria fungsi tertentu.
• Lingkungan: Menjelaskan di mana tim proyek akan membangun POC. Pendekatan yang baik adalah menggunakan lingkungan kotak pasir yang berbeda untuk POC, dan menyebarkannya ke lingkungan pengembangan saat siap. Lingkungan kotak pasir memiliki kebijakan yang lebih fleksibel dan konten cairan, dan difokuskan untuk menghasilkan hasil yang cepat. Sebaliknya, lingkungan pengembangan mengikuti proses yang lebih terstruktur yang memungkinkan kolaborasi, dan berfokus pada penyelesaian tugas tertentu.
• Kriteria keberhasilan: Tentukan ambang batas kapan POC berhasil dan harus pindah ke iterasi berikutnya dan masukkan pengembangan formal. Sebelum memulai POC, tim proyek harus mengidentifikasi kriteria yang jelas kapan POC berhasil. Dengan menetapkan kriteria ini terlebih dahulu, tim proyek menentukan kapan pengembangan POC berakhir dan kapan siklus pengembangan dan validasi berulang dimulai. Tergantung pada tujuan POC, tim proyek dapat menetapkan kriteria keberhasilan yang berbeda, seperti:
  • Persetujuan POC oleh pemangku kepentingan
  • Validasi fitur atau fungsionalitas
  • Ulasan poc yang menguntungkan oleh rekan-rekan setelah waktu pengembangan tetap
• Kegagalan: Pastikan bahwa tim proyek dapat mengidentifikasi kegagalan POC. Mengidentifikasi kegagalan sejak dini akan membantu menyelidiki akar penyebabnya. Ini juga dapat membantu menghindari investasi lebih lanjut dalam solusi yang tidak akan berfungsi seperti yang diharapkan ketika disebarkan ke produksi.

Perhatian

Ketika tim proyek melakukan POC, mereka harus tetap waspada untuk asumsi dan batasan. Misalnya, tim proyek tidak dapat dengan mudah menguji performa solusi dan kualitas data dengan menggunakan sekumpulan kecil data. Selain itu, pastikan bahwa cakupan dan tujuan POC jelas bagi pengguna bisnis. Pastikan untuk berkomunikasi bahwa POC adalah iterasi pertama, dan menekankan bahwa itu bukan solusi produksi.

Catatan

Untuk informasi selengkapnya, lihat Melakukan bukti konsep untuk bermigrasi ke Power BI.

Daftar periksa - Saat membuat POC, keputusan dan tindakan utama meliputi:

• Tentukan tujuan: Pastikan bahwa tujuan POC jelas bagi semua orang yang terlibat.
• Tentukan cakupan POC: Pastikan bahwa membuat POC tidak akan mengambil terlalu banyak upaya pengembangan, sambil tetap memberikan nilai dan menunjukkan desain solusi.
• Tentukan data apa yang akan digunakan: Identifikasi data sumber apa yang akan Anda gunakan untuk membuat POC, membenarkan keputusan Anda dan menguraikan potensi risiko dan batasan.
• Tentukan kapan dan bagaimana menunjukkan POC: Rencanakan untuk menunjukkan kemajuan dengan menyajikan POC kepada pembuat keputusan dan pengguna bisnis.
• Klarifikasi kapan POC berakhir: Pastikan bahwa tim proyek memutuskan kesimpulan yang jelas untuk POC, dan jelaskan bagaimana poc akan dipromosikan ke siklus pengembangan formal.

Langkah 4: Membuat dan memvalidasi konten

Ketika POC berhasil, tim proyek bergeser dari POC ke membuat dan memvalidasi konten. Tim proyek dapat mengembangkan solusi BI dengan siklus pengembangan dan validasi berulang. Siklus ini terdiri dari rilis berulang, di mana tim proyek membuat konten di lingkungan pengembangan dan merilisnya ke lingkungan pengujian. Selama pengembangan, tim proyek secara bertahap melakukan onboarding komunitas pengguna dalam proses pilot ke versi awal (beta) solusi di lingkungan pengujian.

Tip

Pengiriman berulang mendorong validasi awal dan umpan balik yang dapat mengurangi permintaan perubahan, mempromosikan adopsi solusi, dan mewujudkan manfaat sebelum rilis produksi.

Siklus pengembangan dan validasi berulang berlanjut hingga tim proyek tiba pada kesimpulan yang telah ditentukan. Biasanya, pengembangan menyimpulkan ketika tidak ada lagi fitur untuk diterapkan atau umpan balik pengguna ke alamat. Ketika siklus pengembangan dan validasi berakhir, tim proyek menyebarkan konten ke lingkungan produksi dengan rilis produksi akhir.

Diagram berikut menggambarkan bagaimana tim proyek dapat secara berulang memberikan solusi BI dengan siklus pengembangan dan validasi.

Diagram menggambarkan langkah-langkah berikut.

Benda	Keterangan
	Tim proyek mengomunikasikan setiap rilis kepada komunitas pengguna, yang menjelaskan perubahan dan fitur baru. Idealnya, komunikasi mencakup demonstrasi solusi dan Tanya Jawab, sehingga pengguna memahami apa yang baru dalam rilis, dan mereka dapat memberikan umpan balik verbal.
	Selama validasi, pengguna memberikan umpan balik melalui alat atau formulir pusat. Tim proyek harus meninjau umpan balik secara teratur untuk mengatasi masalah, menerima atau menolak permintaan, dan menginformasikan fase pengembangan yang akan datang.
	Tim proyek memantau penggunaan solusi untuk mengonfirmasi bahwa pengguna mengujinya. Jika tidak ada penggunaan, tim proyek harus terlibat dengan komunitas pengguna untuk memahami alasannya. Penggunaan rendah dapat menunjukkan bahwa tim proyek perlu mengambil tindakan pengaktifan dan perubahan manajemen lebih lanjut.
	Tim proyek segera menanggapi umpan balik pengguna. Jika tim proyek membutuhkan waktu terlalu lama untuk mengatasi umpan balik, pengguna mungkin dengan cepat kehilangan motivasi untuk menyediakannya.
	Tim proyek menggabungkan umpan balik yang diterima ke dalam perencanaan solusi. Jika perlu, mereka meninjau prioritas perencanaan untuk mengklarifikasi dan mendelegasikan tugas sebelum fase pengembangan berikutnya dimulai.
	Tim proyek melanjutkan pengembangan solusi untuk rilis berikutnya.
	Tim proyek melakukan iterasi melalui semua langkah sampai mereka mencapai kesimpulan yang telah ditentukan, dan solusinya siap untuk penyebaran produksi.

Bagian berikut menjelaskan pertimbangan utama untuk menggunakan siklus pengembangan dan validasi berulang untuk memberikan solusi BI.

Buat konten

Tim proyek mengembangkan solusi dengan mengikuti alur kerja pengembangan normal mereka. Namun, mereka harus mempertimbangkan poin-poin berikut saat membuat konten.

• Selama setiap siklus pengembangan, perbarui dokumentasi untuk menjelaskan solusi.
• Akhiri setiap siklus pengembangan dengan pengumuman kepada komunitas pengguna. Pengumuman harus diposting ke portal terpusat, dan mereka harus memberikan deskripsi singkat tentang perubahan dan fitur baru di setiap rilis.
• Dengan setiap rilis, pertimbangkan untuk mengatur sesi untuk menunjukkan perubahan dan fitur baru kepada komunitas pengguna, dan untuk menjawab pertanyaan verbal apa pun.
• Tentukan kapan siklus pengembangan dan validasi berulang akan disimpulkan. Pastikan bahwa ada proses yang jelas untuk menyebarkan solusi ke lingkungan produksi, termasuk transisi ke aktivitas dukungan dan adopsi.

Memvalidasi konten

Setiap siklus pengembangan berulang harus disimpulkan dengan validasi konten. Untuk solusi BI, biasanya ada dua jenis validasi.

• Validasi pengembang: Pengujian solusi dilakukan oleh pembuat konten dan serekan. Tujuan validasi pengembang adalah untuk mengidentifikasi dan menyelesaikan semua masalah penting dan terlihat sebelum solusi tersedia untuk pengguna bisnis. Masalah dapat berkaitan dengan kebenaran data, fungsionalitas, atau pengalaman pengguna. Idealnya, konten divalidasi oleh pembuat konten yang tidak mengembangkannya.
• Validasi pengguna: Pengujian solusi dilakukan oleh komunitas pengguna. Tujuan validasi pengguna adalah untuk memberikan umpan balik untuk perulangan nanti, dan untuk mengidentifikasi masalah yang tidak ditemukan oleh pengembang. Periode validasi pengguna formal biasanya disebut sebagai pengujian penerimaan pengguna (UAT).

Penting

Pastikan bahwa masalah kualitas data ditangani selama validasi pengembang (sebelum UAT). Masalah-masalah ini dapat dengan cepat mengikis kepercayaan pada solusi, dan mereka dapat membahayakan adopsi jangka panjang.

Tip

Saat melakukan validasi pengguna, pertimbangkan panggilan singkat sesekali dengan pengguna utama. Amati ketika mereka menggunakan solusi. Catat apa yang sulit digunakan, atau bagian solusi apa yang tidak berfungsi seperti yang diharapkan. Pendekatan ini dapat menjadi cara yang efektif untuk mengumpulkan umpan balik.

Faktor dalam pertimbangan berikut saat tim proyek memvalidasi konten.

• Mendorong umpan balik pengguna: Dengan setiap rilis, minta pengguna memberikan umpan balik, dan menunjukkan bagaimana mereka dapat melakukannya secara efektif. Pertimbangkan untuk secara teratur berbagi contoh umpan balik dan permintaan yang telah menyebabkan perubahan terbaru dan fitur baru. Dengan berbagi contoh, Anda menunjukkan bahwa umpan balik diakui dan dihargai.
• Mengisolasi permintaan yang lebih besar: Beberapa item umpan balik memerlukan lebih banyak upaya untuk ditangani. Pastikan bahwa tim proyek dapat mengidentifikasi item-item ini dan mendiskusikan apakah item tersebut akan diimplementasikan, atau tidak. Pertimbangkan untuk mendokumen permintaan yang lebih besar untuk dibahas dalam sesi perencanaan taktis nanti.
• Mulai aktivitas manajemen perubahan: Latih pengguna cara menggunakan solusi. Pastikan untuk menghabiskan upaya ekstra untuk proses baru, data baru, dan berbagai cara bekerja. Berinvestasi dalam manajemen perubahan memiliki pengembalian positif pada adopsi solusi jangka panjang.

Ketika solusi mencapai tingkat kelengkapan dan kematangan yang telah ditentukan, tim proyek siap untuk menyebarkannya ke produksi. Setelah penyebaran, tim proyek beralih dari pengiriman berulang ke mendukung dan memantau solusi produksi.

Catatan

Pengembangan dan pengujian berbeda tergantung pada solusi dan alur kerja pilihan Anda.

Artikel ini hanya menjelaskan item perencanaan dan tindakan tingkat tinggi. Untuk informasi selengkapnya tentang siklus pengembangan dan pengujian berulang, lihat Membuat konten untuk bermigrasi ke Power BI.

Daftar periksa - Saat membuat dan memvalidasi konten, keputusan dan tindakan utama meliputi:

• Gunakan proses berulang untuk merencanakan dan menetapkan tugas: Merencanakan dan menetapkan tugas untuk setiap rilis solusi. Pastikan bahwa proses untuk merencanakan dan menetapkan tugas fleksibel dan menggabungkan umpan balik pengguna.
• Menyiapkan manajemen siklus hidup konten: Gunakan alat dan proses untuk menyederhanakan dan mengotomatiskan penyebaran solusi dan manajemen perubahan.
• Buat alat untuk mempusatkan umpan balik: Mengotomatiskan pengumpulan umpan balik dengan menggunakan solusi yang sederhana untuk Anda dan pengguna Anda. Buat formulir langsung untuk memastikan bahwa umpan balik ringkas namun dapat ditindaklanjuti.
• Menjadwalkan rapat untuk meninjau umpan balik: Temui untuk meninjau secara singkat setiap item umpan balik baru atau yang luar biasa. Tentukan apakah Anda akan menerapkan umpan balik atau tidak, siapa yang akan bertanggung jawab atas implementasi, dan tindakan apa yang harus diambil untuk menutup item umpan balik.
• Memutuskan kapan pengiriman berulang berakhir: Jelaskan kondisi kapan siklus pengiriman berulang akan disimpulkan, dan kapan Anda akan merilis konten ke lingkungan produksi.

Langkah 5: Menyebarkan, mendukung, dan memantau

Setelah siap, tim proyek menyebarkan solusi yang divalidasi ke lingkungan produksi. Tim proyek harus mengambil tindakan adopsi dan dukungan utama untuk memastikan bahwa penyebaran berhasil.

Untuk memastikan penyebaran berhasil, Anda melakukan tugas dukungan dan adopsi berikut.

• Komunikasikan rilis akhir: Sponsor eksekutif, manajer, atau orang lain dengan otoritas dan kredibilitas yang memadai harus mengumumkan rilis kepada komunitas pengguna. Komunikasi harus jelas, ringkas, dan menyertakan tautan ke solusi dan saluran dukungan yang relevan.
• Melakukan pelatihan untuk konsumen konten: Pelatihan harus tersedia untuk konsumen konten selama minggu-minggu pertama setelah rilis ke produksi. Pelatihan harus fokus pada klarifikasi cakupan solusi, menjawab pertanyaan pengguna, dan menjelaskan cara menggunakan solusi.
• Mengatasi umpan balik dan permintaan: Pertimbangkan untuk memberi pengguna saluran untuk mengirimkan umpan balik dan permintaan ke tim proyek. Pastikan bahwa umpan balik dan permintaan yang wajar dibahas dan, jika sesuai, diimplementasikan selama periode dukungan pasca-penyebaran. Bertindak berdasarkan umpan balik dan permintaan setelah rilis produksi penting. Ini menunjukkan solusi tangkas yang merespons perubahan kebutuhan bisnis.
• Rencanakan untuk terhubung dengan komunitas pengguna: Bahkan setelah periode dukungan pasca-penyebaran berakhir, pastikan bahwa pemilik solusi secara teratur bertemu dengan komunitas pengguna. Rapat ini adalah sumber umpan balik yang berharga untuk merevisi strategi BI Anda. Selain itu, mereka membantu mendukung adopsi solusi dengan mengaktifkan pengguna.
• Tindakan serah terima: Anggota tim proyek mungkin tidak bertanggung jawab untuk mempertahankan solusi. Dalam hal ini, tim harus mengidentifikasi siapa yang bertanggung jawab dan melakukan penyerahan. Penyerahan harus terjadi segera setelah rilis ke produksi, dan itu harus mengatasi solusi dan komunitas pengguna.

Perhatian

Gagal melakukan penyerahan yang efektif dapat menyebabkan masalah yang dapat dicegah dengan dukungan solusi dan adopsi selama siklus hidupnya.

Setelah penyebaran, tim proyek harus berencana untuk melanjutkan ke solusi berikutnya dalam backlog solusi yang diprioritaskan. Pastikan Anda mengumpulkan umpan balik dan permintaan baru dan membuat revisi untuk perencanaan taktis—termasuk backlog solusi—jika perlu.

Daftar periksa – Saat mempertimbangkan penyebaran solusi, keputusan dan tindakan utama meliputi:

• Buat rencana komunikasi: Rencanakan cara mengomunikasikan rilis, pelatihan, dan dukungan solusi atau tindakan adopsi lainnya. Pastikan bahwa setiap pemadaman atau masalah dikomunikasikan dan segera ditangani dalam periode dukungan pasca-penyebaran.
• Ikuti dengan rencana pelatihan: Latih pengguna untuk menggunakan solusi. Pastikan pelatihan mencakup sesi pelatihan langsung dan yang direkam selama beberapa minggu setelah rilis.
• Lakukan kegiatan serah terima: Jika perlu, siapkan serah terima dari tim pengembangan kepada tim dukungan.
• Lakukan jam kerja solusi: Setelah periode dukungan pasca-penyebaran, pertimbangkan untuk mengadakan sesi jam kerja reguler untuk menjawab pertanyaan dan mengumpulkan umpan balik dari pengguna.
• Siapkan proses peningkatan berkelanjutan: Jadwalkan audit bulanan solusi untuk meninjau potensi perubahan atau peningkatan dari waktu ke waktu. Pusatkan umpan balik pengguna dan tinjau umpan balik secara berkala antar audit.

Konten terkait

Untuk pertimbangan, tindakan, kriteria pengambilan keputusan, dan rekomendasi lainnya untuk membantu Anda dengan keputusan implementasi Power BI, lihat Perencanaan implementasi Power BI.