WEBVTT 00:00:00.000 --> 00:00:02.000 Seorang tenaga penjualan memperbarui alamat pelang. 00:00:02.340 --> 00:00:05.620 Kemudian, bagian keuangan membuka catatan yang sama namun masih melihat alamat yang lama. 00:00:05.920 --> 00:00:06.740 Jadi alamat menembenah. 00:00:07.160 --> 00:00:09.400 Selama bertahun-tahun, memperbaikinya berarti seseorang harus mengekspor data, 00:00:09.500 --> 00:00:10.800 menyuntik memperkerja, mengirimnya melalui Surail, 00:00:10.900 --> 00:00:11.840 dan mengetik pembaruan yang sama di Surail, 00:00:11.920 --> 00:00:13.380 dan mengetik pembaruan yang sama dua kali ke aplikasi kedua. 00:00:13.520 --> 00:00:15.540 Dynamics 305 Dual Ride mengubah hal tersebut. 00:00:15.820 --> 00:00:18.020 Fitur ini menghubungkan aplikasi keuangan dan operasional 00:00:18.020 --> 00:00:19.660 dengan aplikasi pelanggan berbasis dataverse, 00:00:19.760 --> 00:00:22.180 sehingga catatan bersama seperti pelanggan dan bersama seperti pelanggan dan pesanan 00:00:22.180 --> 00:00:23.140 dan tetap sinkron secara otomatis. 00:00:23.300 --> 00:00:25.360 Bersama saya, Milko Peters dari M365FM, 00:00:25.480 --> 00:00:28.660 dan cuplikan pengetahuan ini menjelaskan Dual Ride dalam bahasa yang sederhana. 00:00:29.000 --> 00:00:30.920 Kita akan membahas apa yang berpindah, bagaimana perpindahannya, 00:00:31.060 --> 00:00:32.540 di mana Dual Ride cukup digunakan, dan di mana. 00:00:33.320 --> 00:00:36.360 Pertama, mari kita mulai dengan masalah bisnis yang menciptakan kebutuhan akan hal ini. 00:00:38.480 --> 00:00:39.840 Masalah yang diselesaikan oleh Dual Ride. 00:00:41.160 --> 00:00:43.820 Bayangkan sebuah bisnis di mana dua kelompok mengerjakan pelanggan yang sama 00:00:43.820 --> 00:00:45.640 namun menggunakan aplikasi yang benar-benar berbeda setiap hari. 00:00:46.140 --> 00:00:48.520 Aplikasi keuangan dan operasional menangani pekerjaan kantor blag. 00:00:48.520 --> 00:00:51.640 Itu mencakup uang, stok, produk, pesanan, pembelian, dan rantai pasokan. 00:00:52.080 --> 00:00:53.780 Di sini adalah perusahaan melacak apa yang dijual, 00:00:53.900 --> 00:00:55.540 apa yang bisa dikirim, apa yang harus dibayar, 00:00:55.600 --> 00:00:57.000 dan apa yang harus dibayarkan pelanggan. 00:00:57.620 --> 00:00:59.640 Aplikasi pelanggan fokus pada pekerjaan yang lebih dekat dengan pelanggan. 00:01:00.220 --> 00:01:02.120 Tim penjualan mengikuti prospek dan membangun peluang. 00:01:02.680 --> 00:01:04.380 Layanan pelanggan menangani pertanyaan dan kasus. 00:01:05.000 --> 00:01:07.360 Layanan lapangan merencanakan pekerjaan dan mengirim orang ke lokasi. 00:01:07.740 --> 00:01:09.660 Tim proyek melacak pekerjaan yang dijanjikan kepada pelanggan. 00:01:10.000 --> 00:01:11.580 Pekerjaan berbeda memerlukan layar yang berbeda. 00:01:11.580 --> 00:01:14.600 Seorang tenaga penjualan tidak seharusnya harus mengulik layar keuangan 00:01:14.600 --> 00:01:16.300 hanya untuk memperbarui kontak setelah menelepon. 00:01:16.600 --> 00:01:19.580 Namun pengguna bagian keuangan memerlukan detail pelanggan dan pesanan yang sama 00:01:19.580 --> 00:01:20.880 dengan yang dilihat tim penjualan. 00:01:21.300 --> 00:01:23.500 Karena faktur dan pengiriman bergantung pada informasi tersebut. 00:01:24.220 --> 00:01:26.880 Tanpa koneksi, satu pelanggan secara diam-diam menjadi dua catatan. 00:01:27.500 --> 00:01:28.960 Penjualan mungkin mencatat Nordwind Bike, 00:01:29.060 --> 00:01:31.200 sementara keuangan mencatat Nordwind Bicycle Company. 00:01:32.000 --> 00:01:33.760 Oh, satu catatan memiliki alamat jalan yang baru, 00:01:33.760 --> 00:01:35.620 sementara yang lain masih mengirim faktur ke kantor yang lama. 00:01:36.380 --> 00:01:38.160 Kedua catatan terlihat masuk akal sendiri-sendiri, 00:01:38.160 --> 00:01:40.460 namun keduanya tidak lagi menggambarkan hubungan bisnis yang sama. 00:01:40.940 --> 00:01:42.040 Masalah kecil muncul terlebih dahulu. 00:01:42.540 --> 00:01:45.340 Seseorang tidak dapat menemukan pelanggan karena namanya berbeda di aplikasi lain. 00:01:45.660 --> 00:01:48.040 Seorang perwakilan penjualan menjanjikan harga atau meriksa stok, 00:01:48.140 --> 00:01:49.780 namun informasinya tidak sesuai dengan sisi operasi. 00:01:50.180 --> 00:01:51.480 Keuangan perlu memproses pesanan, 00:01:51.700 --> 00:01:54.660 namun detail pelanggan memerlukan pemiksaan, surel, dan pembaruan manual lainnya. 00:01:55.120 --> 00:01:56.660 Kemudian masalah-masalah kecil itu menemukan. 00:01:56.800 --> 00:01:58.820 Seseorang mengekspor data pelanggan ke dalam bar kerja. 00:01:59.340 --> 00:02:01.720 Orang lain memperbaiki beberapa baris dan mengimpornya ke tempat lain. 00:02:02.320 --> 00:02:04.360 Orang lain memasukkan pelanggan baru ke kedua aplikasi 00:02:04.360 --> 00:02:06.240 karena tidak ada yang tahu catatan mana yang akan muncul lebih dulu. 00:02:06.580 --> 00:02:08.580 Tak lama kemudian muncul duplikat, alamat yang berbeda, 00:02:08.700 --> 00:02:11.180 dan lebih banyak waktu dihabiskan untuk meriksa data daripada menggunakannya. 00:02:11.680 --> 00:02:13.280 Semua ini terjadi bukan karena orang tidak telit. 00:02:13.640 --> 00:02:16.000 Ini terjadi karena sistem meminta orang untuk menjadi penghubungnya. 00:02:16.380 --> 00:02:17.060 Orang harus menyalin data. 00:02:17.360 --> 00:02:19.000 Orang harus mengingat aplikasi mana yang harus dibuka dulu. 00:02:19.220 --> 00:02:21.440 Orang menemukan kesalahan setelah data sampai ke tim lain. 00:02:21.760 --> 00:02:25.220 Pendekatan itu berhasil saat sistem bisnis terpisah dan tim menerima penundaan. 00:02:25.720 --> 00:02:28.380 Namun saat bagian penjualan, layanan, keuangan, dan operasional 00:02:28.380 --> 00:02:30.340 membutuhkan informasi pelanggan yang sama sepanjang hari 00:02:30.340 --> 00:02:31.960 lembar kerja menjadi alat serah terima yang buruk. 00:02:31.960 --> 00:02:34.220 Pikirkan tentang percakapan pesanan yang sederhana. 00:02:34.680 --> 00:02:36.080 Seorang pelanggan menelpon bagian penjualan 00:02:36.080 --> 00:02:37.200 bisa ke Anda mengirim ke Anda menggurup. 00:02:37.620 --> 00:02:38.240 Tempat PPI-nya. 00:02:38.840 --> 00:02:41.980 Tim penjualan membutuhkan detail produk, harga, dan stok untuk menjawabnya. 00:02:42.820 --> 00:02:45.160 Setelah pelanggan setuju, bagian keuangan dan operasional 00:02:45.160 --> 00:02:48.140 memerlukan informasi pelanggan dan pesanan yang tepat untuk memproses penjualan. 00:02:48.660 --> 00:02:49.740 Kedua belah pihak membutuhkan fakta. 00:02:49.920 --> 00:02:52.560 Bagian penjualan membutuhkan fakta tersebut di aplikasi tempat mereka. 00:02:53.040 --> 00:02:55.960 Bagian keuangan dan operasional membutuhkannya di aplikasi tempat mereka 00:02:55.960 --> 00:02:57.320 mengelola pesanan keuangan dan pengiriman. 00:02:57.320 --> 00:03:00.820 Tujuannya bukan untuk memaksa setiap tim menggunakan satu layar raksasa. 00:03:01.300 --> 00:03:04.140 Tujuannya adalah agar catatan bersama mengikuti alur yang jelas dan disepakat. 00:03:04.700 --> 00:03:06.140 Disinilah peran dual ride dimulai. 00:03:07.220 --> 00:03:10.020 Jadi, apa sebenarnya dual ride itu? 00:03:10.540 --> 00:03:11.560 Berikut definisi yang paling sederhana. 00:03:12.100 --> 00:03:13.740 Dual ride adalah koneksi bawaan Microsoft 00:03:13.740 --> 00:03:17.940 yang menyelaraskan data terpilih antara aplikasi Dynamics 365 Finance and Operations 00:03:17.940 --> 00:03:18.820 dengan Dataverse. 00:03:19.320 --> 00:03:23.100 Dataverse adalah fondasi data bersama di balik banyak aplikasi bisnis Microsoft. 00:03:23.560 --> 00:03:25.960 Dynamics 365 Sales, Customer Service, Field Service, 00:03:25.960 --> 00:03:28.200 dan bagian dari Project Operations semuanya menggunakannya. 00:03:28.660 --> 00:03:30.040 Power Automate juga bisa menggunakannya. 00:03:30.820 --> 00:03:34.060 Anda tidak perlu tahu bagaimana Dataverse menyimpan setiap catatan untuk omahami dual ride. 00:03:34.620 --> 00:03:37.960 Anggap saja sebagai area data umum di sisi aplikasi pelanggan Dynamics 365. 00:03:39.020 --> 00:03:41.040 Layangkan sebuah gedung kantor dengan kantor belakang. 00:03:41.820 --> 00:03:43.820 Kantor depan menangani percakapan dengan pelanggan. 00:03:44.540 --> 00:03:46.460 Tenaga penjualan agen layanan pekerja lapangan. 00:03:46.460 --> 00:03:50.680 Mereka semua membutuhkan layar yang membantu mereka berbicara dengan orang, 00:03:50.800 --> 00:03:52.080 melacak permintaan, dan mengelola pekerja. 00:03:52.240 --> 00:03:54.720 Kantor belakang menangani pekerjaan yang membuat perusahaan data pekerjaan. 00:03:55.040 --> 00:03:57.560 Catatan keuangan, stok, pesanan, pembelian, pengiriman kami. 00:03:58.560 --> 00:04:00.320 Kedua kantor bekerja untuk perusahaan yang sama. 00:04:00.560 --> 00:04:01.580 Namun tanpa koneksi yang tepat, 00:04:01.700 --> 00:04:04.240 seseorang harus membawa informasi dari satu sisi ke sisi lainnya. 00:04:04.720 --> 00:04:05.800 Mereka membawa formulir cetak, 00:04:05.880 --> 00:04:06.360 mengirim email, 00:04:06.480 --> 00:04:07.680 atau menyalin data ke sistem lain. 00:04:08.420 --> 00:04:09.340 Pekerjaan memang selesai, 00:04:09.500 --> 00:04:10.420 tapi memakan waktu lebih lama, 00:04:10.560 --> 00:04:11.840 dan detailnya bisa berubah di tengah jalan. 00:04:12.000 --> 00:04:13.580 Dual ride seperti pintu internal 00:04:13.580 --> 00:04:15.380 dengan petugas di antara kedua kantor tersebut. 00:04:15.960 --> 00:04:17.660 Saat catatan yang didukung berubah di satu sisi, 00:04:17.960 --> 00:04:20.560 dual ride meneruskan perubahan terkait melalui pintu itu ke sisi lainnya. 00:04:21.200 --> 00:04:22.820 Ini tidak menggabungkan setiap aplikasi raksasa. 00:04:23.400 --> 00:04:24.520 Tim salsa tetap bisa bekerja di sales. 00:04:24.860 --> 00:04:26.260 Tim keuangan tetap bisa bekerja di bagian kong. 00:04:26.540 --> 00:04:28.820 Setiap tim mempertahankan layar yang dibuat untuk pekerjaannya, 00:04:28.980 --> 00:04:31.320 sementara informasi bersama tertentu tetap terhubung di balik lain. 00:04:31.480 --> 00:04:32.380 Kata didukung itu penting. 00:04:32.920 --> 00:04:35.720 Dual ride tidak secara membabi buta menyalin setiap data di kedua sistem. 00:04:36.200 --> 00:04:39.160 Ini bekerja melalui koneksi yang ditentukan antar catatan yang saling terkait. 00:04:39.160 --> 00:04:41.920 Microsoft menyebut koneksi ini sebagai pemetaan tabel tabs. 00:04:42.880 --> 00:04:45.440 Tabel hanyalah tempat di mana aplikasi menyimpan satu jenis catatan. 00:04:45.800 --> 00:04:47.340 Tabel pelanggan menyimpan catatan pelanggan. 00:04:47.800 --> 00:04:49.040 Tabel produk menyimpan catatan produk. 00:04:49.600 --> 00:04:51.080 Tabel alamat menyimpan detail alamat. 00:04:51.600 --> 00:04:56.320 Pemetaan tabel memberitahu dual ride tabel mana di sisi keuangan dan operasi yang terhubung ke tabel mana di dataverse. 00:04:57.040 --> 00:04:59.240 Anggaplah pemetaan tabel sebagai lembar tujuan yang disepakati. 00:04:59.560 --> 00:05:01.320 Satu kolom mengidentifikasi catatan di satu sisi. 00:05:01.440 --> 00:05:04.020 Kolom lainnya mengidentifikasi catatan yang cocok di sisi lain. 00:05:04.600 --> 00:05:07.060 Sisa lembar tersebut menjelaskan kolom mana yang saling terkait. 00:05:07.060 --> 00:05:09.420 Nama, nomor telepon, baris alamat kita. 00:05:10.080 --> 00:05:11.540 Kesepakatan itu memberikan aturan koneksinya. 00:05:12.000 --> 00:05:15.860 Tanpanya, dua aplikasi mungkin menggunakan label berbeda atau menyimpan detail yang sama di tempat berbeda. 00:05:16.080 --> 00:05:18.400 Pemetaan memberitahu dual ride bagaimana detail tersebut berhubung. 00:05:18.820 --> 00:05:20.960 Jadi aplikasi tidak perlu orang untuk menafsirkannya setiap saat. 00:05:21.340 --> 00:05:26.260 Nah, orang sering mendengar nama dual ride dan berasumsi itu berarti setiap perubahan selalu bergerak dua arah. 00:05:26.700 --> 00:05:27.380 Terkadang memang begitu. 00:05:27.380 --> 00:05:31.980 Untuk pemetaan dua arah yang didukung, perubahan di dataverse dapat memperbarui catatan terkait di finance and operations. 00:05:32.680 --> 00:05:36.720 Perubahan yang didukung di finance and operations juga dapat memperbarui catatan terkait di dataverse. 00:05:37.300 --> 00:05:39.160 Kedua sisi dapat ikut serta dan pecatatan bersama yang sama. 00:05:39.720 --> 00:05:42.280 Setelah bagian dualnya, pemerintah disana mendekati waktunya tanpa. 00:05:42.800 --> 00:05:46.260 Ini bergerak cepat saat orang bekerja ahli-ahli menunggu pekerjaan terjadwal yang berjalan semalam. 00:05:47.100 --> 00:05:51.920 Pengguna memperbarui catatan yang didukung dan koneksi mengirimkan pembaruan itu saat pekerjaan masih berlangsung. 00:05:52.540 --> 00:05:54.660 Mendekati waktu nyata tidak berarti ajaib atau tanpa penundaan. 00:05:54.900 --> 00:05:58.920 Artinya, koneksi dibangun untuk pekerjaan bisnis langsung, bukan pertukaran file sekali sehari. 00:05:58.920 --> 00:06:03.240 Jika seseorang mengubah detail, tim terkait tidak perlu menunggu hingga besok pagi untuk melihatnya. 00:06:03.640 --> 00:06:07.240 Untuk mengubah cara tim pekerja, kantor depan bisa menggunakan data yang berasal dari kantor belakang. 00:06:07.720 --> 00:06:10.580 Kantor belakang bisa menerima pembaruan yang didukung dari aplikasi yang menghadap langit. 00:06:11.080 --> 00:06:15.420 Dataverse menjadi fondasi data di satu sisi, finance and operations tetap menjadi fondasi operasional di sisi lain, 00:06:15.420 --> 00:06:18.080 dan dual right menjaga catatan bersama yang disetujui tetap terhubung. 00:06:19.080 --> 00:06:20.920 Tetap saja, pintu internal langsung membutuhkan atur. 00:06:20.920 --> 00:06:25.320 Sebelum Anda membiarkan catatan berpindah ke dua arah, Anda perlu tahu di mana catatan itu harus dimulai, 00:06:25.440 --> 00:06:29.220 siapa yang bisa mengubahnya, dan sisi mana yang harus memimpin saat kedua aplikasi tidak sepakat. 00:06:30.260 --> 00:06:32.380 Data P bisa dipindahkan dan sistem mana yang memilikinya. 00:06:33.280 --> 00:06:35.220 Jadi, catatan apa saja yang bisa tetap terhubung dengan dual right? 00:06:35.660 --> 00:06:38.720 Contoh umum dimulai dengan catatan yang dibagikan banyak departemen setiap hari. 00:06:39.320 --> 00:06:46.300 Catatan pelanggan, alamat, kontak, produk, vendor, detail perusahaan, dan informasi referensi yang digunakan untuk keuangan dan pajak. 00:06:47.200 --> 00:06:48.840 Pikirkan sejenak tentang catatan pelanggan. 00:06:48.840 --> 00:06:53.640 Tim penjualan membutuhkan nama pelanggan, kontak utama, nomer telepon, dan alamat pengiriman. 00:06:54.440 --> 00:06:58.940 Tim keuangan membutuhkan catatan legal pelanggan, detail penagihan, dan informasi yang diperlukan untuk pesanan serta faktur. 00:06:59.300 --> 00:07:04.380 Jika setiap departemen menyimpan daftar pelanggan terpisah, perusahaan membuang waktu membandingkan catatan alih-alih melayani pelanggan. 00:07:05.060 --> 00:07:08.580 Dengan peta dual right yang tepat, tim-tim tersebut dapat bekerja dari detail pelanggan yang terhubung. 00:07:09.200 --> 00:07:11.640 Itu tidak berarti pengguna penjualan tiba-tiba harus mempelajari aplikasi koal. 00:07:12.080 --> 00:07:15.580 Artinya, mereka dapat bekerja dengan informasi pelanggan di Dynamics 365 Sales, 00:07:15.580 --> 00:07:19.140 sementara pengguna keuangan bekerja dengan informasi pelanggan terkait di aplikasi keuangan. 00:07:19.900 --> 00:07:22.780 Pelanggan tetap dapat dikenali sebagai pelanggan yang sama di kedua tempat tersebut. 00:07:23.680 --> 00:07:24.360 Alamat juga penting. 00:07:24.900 --> 00:07:29.500 Seorang pelanggan mungkin memiliki alamat penagihan, alamat pengiriman, dan mungkin lokasi yang perlu dikunjungi petugas lain. 00:07:29.840 --> 00:07:34.380 Detail ini tidak bisa hanya dianggap sebagai teks biasa yang disalin ke satu kota karena setiap alamat memiliki fungsi berbeda. 00:07:35.320 --> 00:07:38.260 Dual right mendukung struktur catatan bersama yang diperlukan untuk hubungan tersebut. 00:07:38.260 --> 00:07:39.560 Kontak mengikuti pola yang sama. 00:07:39.560 --> 00:07:44.260 Satu perusahaan pelanggan mungkin memiliki pembeli kontak utang usaha dan manajer layanan. 00:07:44.620 --> 00:07:46.240 Tim penjualan perlu tahu siapa yang membuat keputusan. 00:07:46.640 --> 00:07:48.500 Tim keuangan perlu tahu kemana pertanyaan penagihan ditunjuk. 00:07:48.800 --> 00:07:50.540 Tim layanan perlu tahu siapa yang menunggu di lokasi. 00:07:51.020 --> 00:07:54.060 Catatan yang terhubung membantu setiap tim melihat orang-orang yang terkait dengan pelanggan 00:07:54.060 --> 00:07:56.300 tanpa perlu membangun kembali informasi tersebut di sebab aplikasi. 00:07:56.440 --> 00:07:57.640 Produk adalah contoh umum lainnya. 00:07:58.040 --> 00:08:00.280 Perwakilan penjualan perlu tahu apa yang dijual perusahaan, 00:08:00.280 --> 00:08:02.680 berapa harga produk, dan apakah stok tersedia. 00:08:03.120 --> 00:08:05.540 Jawaban tersebut biasanya datang dari sisi operasional bisnis 00:08:05.540 --> 00:08:08.160 karena disitulah produk, stok, pembelian, dan pemenuhan dikelola. 00:08:08.740 --> 00:08:11.560 Inilah mengapa informasi produk sering dimulai dari keuangan dan operasional. 00:08:12.220 --> 00:08:14.400 Tim operasional membuat dan menyiapkan produk di sana. 00:08:15.140 --> 00:08:17.940 Setelah produk tersebut siap untuk pekerjaan yang berhubungan dengan pelanggan, 00:08:18.080 --> 00:08:20.720 dual right dapat mengirim detail produk terkait ke data first. 00:08:21.460 --> 00:08:24.100 Pengguna penjualan kemudian dapat memilih dan diskusikan produk tersebut 00:08:24.100 --> 00:08:26.860 di aplikasi mereka sendiri tanpa perlu memasukkan daftar produk untuk kedua kali. 00:08:26.940 --> 00:08:31.000 Hal itu membantu percakapan penjualan tetap berdasar pada apa yang sebenarnya dapat disediakan oleh bisnis. 00:08:31.600 --> 00:08:35.040 Detail harga dan inventaris juga dapat menjangkau penjualan melalui aplikasi yang terhubung. 00:08:35.540 --> 00:08:38.680 Alih-alih menebak apakah suatu barang tersedia, apakah harga berubah, 00:08:38.860 --> 00:08:40.340 atau apakah stok dapat menuhi janji. 00:08:40.660 --> 00:08:43.620 Tim penjualan dapat bekerja dari informasi yang terikat dengan sisi operasional. 00:08:44.280 --> 00:08:46.260 Hal itu tidak menghilangkan perlunya penilaian penjualan yang baik. 00:08:46.720 --> 00:08:49.220 Hal itu menghilangkan satu alasan yang dapat dihindari bagi stok penjualan 00:08:49.220 --> 00:08:51.140 untuk menepung gudang hanya untuk menepungasi detail dasar. 00:08:51.540 --> 00:08:54.400 Informasi vendor juga dapat terhubung di mana proses bisnis memerlukan. 00:08:54.940 --> 00:08:57.620 Detail perusahaan, struktur organisasi, data referensi keuangan, 00:08:57.740 --> 00:09:01.300 dan data referensi pajak dapat menjadi penting baik di sisi pelanggan maupun sisi operasional. 00:09:01.300 --> 00:09:05.500 Catatan yang tepat bergantung pada aplikasi dan proses yang digunakan perusahaan, 00:09:05.700 --> 00:09:06.640 namun polanya tetap sama. 00:09:07.320 --> 00:09:09.740 Bagikan catatan yang harus memiliki arti yang sama di kedua tempat. 00:09:10.500 --> 00:09:13.100 Nah, jangan berasumsi bahwa setiap catatan harus berjalan di kedua arah. 00:09:13.600 --> 00:09:14.760 Berapa aplikasi mendukung pembayaran? 00:09:15.300 --> 00:09:18.180 Perubahan dapat dimulai di Dataverse dan berpindah ke Finance and Operations, 00:09:18.440 --> 00:09:20.880 atau dimulai di Finance and Operations dan berpindah ke Dataverse. 00:09:21.240 --> 00:09:24.660 Pendekatan tersebut cocok untuk catatan di mana kedua belah pihak memiliki alasan bisnis yang tepat 00:09:24.660 --> 00:09:26.680 untuk memperbaiki pembayaran catatan. 00:09:26.680 --> 00:09:28.480 Produk memberi kita contoh yang berguna. 00:09:29.000 --> 00:09:32.080 Di banyak bisnis, Finance and Operations memiliki pembuatan produk 00:09:32.080 --> 00:09:37.540 karena operasional mengontrol master product, stok, unit, dan detail lain yang diperlukan untuk menjual dan mengirimkannya. 00:09:38.260 --> 00:09:41.940 Produk kemudian mengalir ke Dataverse tempat yang penjualan dan layanan dapat menggunakannya. 00:09:42.340 --> 00:09:45.820 Pak Aturan yang jelas, produk tidak memerlukan dua tim yang membuat versi yang saling bersaing. 00:09:46.520 --> 00:09:50.900 Satu sisi membuat dan mengatur produk, sisi lain menerima dan menggunakannya sebagai bagian dari pekerjaannya. 00:09:51.140 --> 00:09:53.280 Setiap catatan bersama memerlukan keputusan semacam itu. 00:09:53.480 --> 00:09:54.400 Dari mana catatan ini bermula? 00:09:54.400 --> 00:09:59.400 Saya mengerti, jika nama, alamat, harga, atau klasifikasi terlihat salah, tim mana yang memperbaikinya? 00:09:59.880 --> 00:10:02.620 Pertanyaan-pertanyaan itu terdengar sederhana, tetapi dapat menjaga banyak kebingungan nantinya. 00:10:03.020 --> 00:10:04.620 Koneksi dapat memindahkan perubahan dengan sang cuci. 00:10:05.100 --> 00:10:07.940 Jika tidak ada yang setuju, siapa yang memiliki perubahan tersebut juga dapat memindahkan keselamannya. 00:10:08.260 --> 00:10:12.740 Pilih pemilik untuk catatan tersebut dan, jika diperlukan, untuk detail individu dalam catatan tersebut. 00:10:13.020 --> 00:10:16.340 Misalnya, penjualan mungkin memiliki detail hubungan pelanggan dan informasi kontak utama. 00:10:17.080 --> 00:10:20.780 Keuangan mungkin memiliki detail terkait pembayaran, operasional mungkin memiliki detail produk dan stok. 00:10:20.780 --> 00:10:26.580 Pembagian tepat Anda bergantung pada cara bisnis Anda bekerja, tetapi harus ditulis dan dipahami oleh orang-orang yang menggunakan aplikasi tersebut. 00:10:27.100 --> 00:10:31.940 Ada juga dua istilah yang mungkin Anda lihat setelah dua ride memperluas Dataverse, yaitu party dan company. 00:10:32.920 --> 00:10:36.260 Party adalah cara Microsoft dalam menangani orang atau organisasi secara konsisten. 00:10:37.220 --> 00:10:44.020 Ini membantu menghubungkan orang, organisasi, kontak, dan alamat, tanpa memperlakukan setiap hubungan sebagai catatan terpisah yang tidak terkait. 00:10:44.740 --> 00:10:48.920 Company membantu Dataverse memahami konteks perusahaan bisnis yang digunakan oleh finance and operation. 00:10:48.920 --> 00:10:51.800 Anda tidak perlu menjadi ahli dalam kedua istilah tersebut pada ribet. 00:10:52.060 --> 00:10:58.660 Ketahui saja bahwa itu ada karena finance and operations menangani struktur bisnis yang perlu dikenali oleh aplikasi pelanggan saat data berpindah antar kedua sisi tersebut. 00:10:59.400 --> 00:11:04.100 Setelah data dapat bergerak ke kedua arah, proses di sekitar data tersebut menjadi sama pentingnya dengan data itu sendiri. 00:11:04.660 --> 00:11:06.240 Bagaimana perubahan berpindah antar aplikasi? 00:11:07.240 --> 00:11:10.000 Mari kita ikuti satu perubahan melalui sistem dan melihat apa yang sebenarnya terjadi. 00:11:10.620 --> 00:11:13.500 Seorang sales rep sedang menelpon pelanggan yang baru saja pindah ke kantor baru. 00:11:13.500 --> 00:11:19.440 Selama percakapan itu, perwakilan tersebut membuka catatan pelanggan di Dynamics 365 Sales dan memperbarui alamat jalan. 00:11:19.900 --> 00:11:20.600 Cukup sederhana bukan? 00:11:21.040 --> 00:11:22.200 Kemudian mereka menyimpan catatan tersebut. 00:11:22.600 --> 00:11:23.860 Disitulah bagian menariknya dimulai. 00:11:24.320 --> 00:11:28.220 Sales menyimpan perubahan itu di Dataverse yaitu sisi data untuk aplikasi yang berhadapan dengan pelanggan. 00:11:28.600 --> 00:11:33.360 Lalu dual ride memeliksa peta yang menghubungkan informasi pelanggan dan alamat antara situs ini serta finance and operations. 00:11:33.760 --> 00:11:35.720 Sistem mengirimkan perubahan yang cocok secara otomatis. 00:11:36.180 --> 00:11:39.400 Tidak ada file ekspor yang tertahan di folder bersama menunggu seseorang untuk mengambilnya. 00:11:39.400 --> 00:11:43.300 Tidak ada yang perlu mengirim email ke bagian keuangan dengan catatan, hey, tolong perbarui alamat ini. 00:11:43.780 --> 00:11:49.480 Peta sudah mengetahui kolom mana yang tertaut dan mengirimkan perubahan yang didukung langsung ke catatan pelanggan terkait di finance and operations. 00:11:50.160 --> 00:11:56.520 Jadi, pengguna keuangan dapat membuka catatan pelanggan itu nanti melihat alamat yang diperbarui dan memproses pesanan atau menyiapkan faktor tanpa hambatan. 00:11:57.060 --> 00:11:58.560 Itulah hasil praktisnya lugas dan sederhana. 00:11:59.280 --> 00:12:03.400 Dua orang tetap bekerja di aplikasi yang berbeda, tetapi tidak ada yang perlu mengetik ulang detail pelanggan yang sama. 00:12:03.920 --> 00:12:06.740 Sales serai bekerja di layar yang dirancang untuk percakapan dengan pelanggan. 00:12:06.740 --> 00:12:09.840 Pengguna keuangan bekerja di layar yang dibangun untuk pekerjaan finansial. 00:12:10.460 --> 00:12:14.140 Setiap orang melihat informasi pelanggan yang benar-benar mereka butuhkan tepat di tempat mereka membutuhkannya. 00:12:14.640 --> 00:12:16.240 Dan proses ini juga bekerja ke arah sebaliknya. 00:12:16.680 --> 00:12:20.000 Bayangkan bagian keuangan memperbarui info pelanggan yang didukung di finance and operations. 00:12:20.980 --> 00:12:24.340 Katakanlah pengguna keuangan memperbaiki detail yang termasuk dalam catatan pelanggan operasional. 00:12:25.440 --> 00:12:29.260 Dual right menggunakan peta yang sama secara terbalik dan mengirimkan pembaruan terkait tersebut ke dataverse. 00:12:29.900 --> 00:12:33.180 Kemudian sales atau aplikasi lain berbasis dataverse lainnya dapat mengambilnya. 00:12:33.180 --> 00:12:36.480 Koneksi ini bersifat sinkron untuk pekerjaan sehari-hari yang long. 00:12:36.660 --> 00:12:40.280 Sinkron berarti aplikasi mencoba menyelesaikan pembaruan terkait sebagai bagian dari momen kerja yang sama, 00:12:40.600 --> 00:12:44.460 alih-alih memasukkannya ke dalam tugas latar belakang yang mungkin berjalan 20 menit kemudian. 00:12:44.640 --> 00:12:48.080 Jika koneksi tidak dapat menyelesaikan pembaruan, masalah tersebut perlu segera ditangani, 00:12:48.200 --> 00:12:51.100 bukan tersembunyi, diam-diam sampai seseorang menyadari adanya ketidakcocokan. 00:12:51.460 --> 00:12:53.460 Perilaku itu masuk akal untuk catatan bisnis yang dibagikan. 00:12:53.600 --> 00:12:59.400 Anda tidak ingin alamat pelanggan, detail produk, atau informasi bersama lainnya menjadi tidak sinkron selama berjam-jam karena tugas page belum dijalankan. 00:12:59.400 --> 00:13:02.040 Orang membuat keputusan berdasarkan apa yang mereka lihat di layar mereka saat ini. 00:13:02.360 --> 00:13:05.180 Jadi, koneksi tersebut menjaga kedua sisi tetap sinkron saat pekerjaan berlang. 00:13:05.820 --> 00:13:08.340 Namun, pekerjaan yang sedang berjalan terkadang perlu jeda yang terkontrol. 00:13:09.020 --> 00:13:11.360 Dual ride menyertakan opsi putar jeda dan kejar ketinggalan. 00:13:11.800 --> 00:13:14.460 Kuta berarti pemetaan berjalan dan perubahan yang didukung berpindah secara norm. 00:13:14.920 --> 00:13:17.940 Jeda untuk sementara menghentikan pemetaan saat tim perlu melakukan pekerjaan terencana, 00:13:17.940 --> 00:13:20.140 menjadi dikimasalah, atau mengelola perubahan dengan aman. 00:13:20.540 --> 00:13:22.100 Tetapi jeda bukanlah tempat parkir permanen. 00:13:22.780 --> 00:13:26.020 Saat pemetaan di jeda, perubahan dapat mengantre dalam waktu dan ruang yang terbatas. 00:13:26.020 --> 00:13:29.620 Saat pemetaan dilanjutkan, fitur kejar ketinggalan akan memproses perubahan yang tertulat. 00:13:29.920 --> 00:13:32.380 Hal itu membantu tim memulihkan diri setelah gangguan yang direncana. 00:13:32.860 --> 00:13:36.540 Namun, seseorang harus bertanggung jawab atas jeda tersebut dan mengetahui kapan pemetaan harus dijalankan kembali. 00:13:37.260 --> 00:13:40.700 Sebelum semua ini dimulai dalam pekerjaan sehari-hari, ada langkah lain, yaitu sinkronisasi awal. 00:13:41.020 --> 00:13:44.280 Sinkronisasi awal membawa catatan yang ada dari kedua sisi ke titik awal yang sama. 00:13:44.680 --> 00:13:49.080 Bayangkan sebuah perusahaan yang sudah memiliki pelanggan di finance and operations serta catatan pelanggan di data first. 00:13:49.080 --> 00:13:53.180 Koneksi tidak bisa langsung dinyalakan dan berasumsi bahwa setiap catatan yang ada sudah cocok dengan sempurna. 00:13:53.600 --> 00:13:54.920 Koneksi membutuhkan geris awal. 00:13:55.220 --> 00:13:59.440 Sinkronisasi awal membantu memindahkan data yang ada sebelum orang mengandalkan pembaruan langsung. 00:14:00.180 --> 00:14:07.260 Pekerjaan itu perlu keteritian karena catatan ganda, alamat tidak lengkap, dan data uji lama tidak akan bersih dengan sendirinya hanya karena sinkronisasi dimulai. 00:14:07.760 --> 00:14:11.400 Data tersebut justru bisa menimbulkan masalah lebih cepat jika catatan tidak mengikuti aturan yang sepakat. 00:14:11.400 --> 00:14:15.800 Setelah pemetaan berjalan, orang yang mengelola dual right memperlukan tempat yang jelas untuk memperiksa kesehatannya. 00:14:16.220 --> 00:14:22.280 Dual right menyediakan catatan aktivitas dan kesalahan gabungan sehingga administrator dapat melihat apa yang diproses koneksi dan di mana kendala terjadi. 00:14:22.900 --> 00:14:24.560 Mereka juga dapat mengatur peringatan emang batas. 00:14:25.020 --> 00:14:30.100 Artinya, orang yang tepat akan mengetahui masalah sebelum pengguna menemukannya melalui pembaruan yang hilang atau gagal. 00:14:30.800 --> 00:14:33.220 Tampilan dukungan itu penting karena setiap kesalahan memiliki penyebab. 00:14:33.960 --> 00:14:35.260 Mungkin ada kolom wajib yang belum terisi. 00:14:35.380 --> 00:14:36.860 Mungkin catatan terkait belum tiba. 00:14:37.320 --> 00:14:39.460 Mungkin seseorang membuat data dengan cara yang tidak sesuai dengan pemetaan. 00:14:39.460 --> 00:14:43.980 Mencoba ulang catatan yang gagal tanpa memperbaiki penyebabnya biasanya hanya akan menyebabkan kegagalan yang sama. 00:14:44.720 --> 00:14:49.100 Pengaturan dual right yang dijalankan dengan baik akan memantau koneksi, memperbaiki penyebab kesalahan, 00:14:49.420 --> 00:14:52.520 dan menjaga pemetaan tetap fokus pada catatan yang benar-benar perlu terhubung. 00:14:53.200 --> 00:14:59.100 Dimana dual right paling cocok digunakan saat bisnis Anda menggunakan Dynamics 365 Finance atau Supply Chain Management 00:14:59.100 --> 00:15:03.880 bersama aplikasi yang berhadapan dengan pelanggan seperti sales, customer service, field service, field service, atau project operation. 00:15:04.500 --> 00:15:07.280 Aplikasi-aplikasi ini mendukung bagian yang berbeda dari percakapan bisnis yang sama. 00:15:07.280 --> 00:15:13.340 Satu tim berbicara dengan pelanggan, tim lain merencanakan pengiriman, mengelola stok, melacak biaya, atau mengirim faktur. 00:15:13.960 --> 00:15:18.820 Saat kedua grup perlu bekerja dengan data terkait sepanjang hari, dual right dapat menghubungkan pekerjaan tersebut 00:15:18.820 --> 00:15:21.060 tanpa harus memaksa semua orang menggunakan aplikasi yang sama. 00:15:21.360 --> 00:15:23.240 Ambil contoh proses prospek kekas sebagai gambaran. 00:15:23.760 --> 00:15:26.860 Seorang tenaga penjualan bekerja dengan calon pelanggan di Dynamics 365 Sales. 00:15:27.520 --> 00:15:30.920 Mereka melacak kontak, mendiskusikan produk, membuat penawaran, dan beralih pemesanan. 00:15:30.920 --> 00:15:38.800 Selama percakapan itu, tenaga penjualan membutuhkan detail pelanggan, info produk, harga, dan informasi pesanan yang berkaitan dengan sisi keuangan perusahaan. 00:15:39.540 --> 00:15:44.740 Setelah penjualan terwujud, manajemen keuangan dan rantai pasokan mengambil alih pekerjaan yang terjadi setelah janji tersebut. 00:15:45.100 --> 00:15:47.880 Bagian ini menangani pemenuhan pesanan, penagihan stok, dan catatan keuangan. 00:15:48.620 --> 00:15:50.960 Dual right membantu kedua bagian tersebut tetap terhubung. 00:15:51.440 --> 00:15:54.580 Tenaga penjualan dapat bekerja di aplikasi pelanggan yang sesuai dengan pekerjaan mereka, 00:15:54.580 --> 00:15:57.980 sementara bagian keuangan dan operasional mengelola transaksi di aplikasi yang dibuat untuk pekerjaan. 00:15:58.120 --> 00:16:02.220 Pelanggan tidak menjadi dua cerita terpisah, satu diceritakan oleh tim penjualan, dan yang lain oleh tim keuang. 00:16:02.800 --> 00:16:04.120 Field Service memberikan contoh bagus lain. 00:16:04.460 --> 00:16:08.780 Bayangkan sebuah perusahaan yang mengirim teknisi untuk memasang, memperbaiki, atau memelihara peralatan di lokasi pelanggan. 00:16:09.260 --> 00:16:15.020 Pekerja lapangan membutuhkan detail pelanggan, detail pekerjaan, serta informasi aset pelanggan mengenai barang yang dipasang atau didukung oleh perusahaan. 00:16:15.640 --> 00:16:20.680 Di balik layar, perusahaan juga perlu melacak suku cadang, biaya, pembelian, dan uang yang terkait dengan pekerjaan tersebut. 00:16:20.680 --> 00:16:23.280 Field Service berfokus pada perencanaan dan penyelesaian kunjungan. 00:16:23.700 --> 00:16:26.920 Keuangan dan operasional berfokus pada catatan operasional dan keuangan di sekitarnya. 00:16:27.440 --> 00:16:33.840 Ketika catatan tersebut terhubung dengan benar, pekerjaan teknisi tidak terpisah dari suku cadang yang digunakan, biaya pekerjaan, atau catatan pelanggan yang terhubung dengannya. 00:16:35.040 --> 00:16:39.020 Project Operations mengikuti pola yang sama, terutama bagi perusahaan yang menjual pekerjaan berdasarkan proyek. 00:16:39.360 --> 00:16:43.720 Tim proyek mungkin mengelola pekerjaan pelanggan waktu karyawan biaya terencana, dan tonggak pencapaian proyek. 00:16:44.320 --> 00:16:48.060 Bagian keuangan perlu melihat sisi finansial dari pembelian, biaya, penagihan, dan pelaporan. 00:16:48.060 --> 00:16:53.680 Tanpa koneksi, manajer proyek bisa menghabiskan terlalu banyak waktu untuk mengejar bagian keuangan demi pembaruan, 00:16:53.780 --> 00:16:56.320 sementara keuangan menunggu tim proyek mengonfirmasi apa yang terjadi. 00:16:57.120 --> 00:17:02.440 Catatan proyek yang terhubung memberikan gambaran yang lebih jelas bagi kedua grup mengenai pekerjaan saat bergerak dari janji pelanggan menjadi aktivitas finansial. 00:17:02.800 --> 00:17:07.480 Ada juga manfaat power platform yang lebih luas di sini, karena sisi aplikasi pelanggan menggunakan Dataverse, 00:17:07.740 --> 00:17:10.700 data yang disetujui di Dataverse dapat mendukung power apps dan power automate. 00:17:10.700 --> 00:17:16.760 Perusahaan mungkin membuat aplikasi kecil untuk tim internal, atau membuat alur yang merespon saat catatan bisnis mencapai titik tertentu. 00:17:17.340 --> 00:17:20.720 Itu tidak berarti setiap catatan keuangan dan operasional tiba-tiba harus ada di setiap power app. 00:17:21.060 --> 00:17:24.340 Artinya catatan yang terhubung bisa menjadi bagian dari perangkat bisnis yang lebih luas, 00:17:24.560 --> 00:17:27.600 selama perusahaan memilih tujuan tersebut dengan cermat dan melindungi data dengan baik. 00:17:28.180 --> 00:17:32.540 Satu batasan harus tetap jelas, dual right tidak mendukung Dynamics 3N Central, Business Central. 00:17:32.700 --> 00:17:36.260 Business Central dapat terhubung dengan produk Microsoft lain melalui metode lain. 00:17:36.260 --> 00:17:41.780 Namun dual right ditujukan untuk sisi keuangan dan operasional Dynamics 365 serta aplikasi pelanggan berbasis Dataverse. 00:17:42.480 --> 00:17:45.040 Ini juga bukan alat untuk menyalin setiap tabel yang Anda temukan. 00:17:45.600 --> 00:17:49.280 Sebuah catatan harus dipindahkan karena orang memerlukan catatan operasional yang sama di kedua tempat, 00:17:49.420 --> 00:17:50.940 bukan karena menyalin data terasa lebih aman. 00:17:51.300 --> 00:17:55.940 Dual right juga tidak menggantikan rencana integrasi yang lebih luas ketika perusahaan memerlukan fit pelaporan tautan ke sistem pihak ketiga, 00:17:56.060 --> 00:17:58.160 atau migrasi sistem pihak ketiga, atau migrasi data dalam skala besar. 00:17:58.340 --> 00:18:01.680 Memperlakukan setiap koneksi data sebagai pekerjaan yang sama akan cepat menimbulkan masalah. 00:18:02.740 --> 00:18:05.420 Batasan, persiapan, dan kesalahan umum. 00:18:05.420 --> 00:18:08.580 Anggaplah dual right seperti perjanjian coba tangan antara dua sistem. 00:18:09.140 --> 00:18:11.640 Mereka setuju untuk menjaga catatan bersama tertentu tetap sinkron, 00:18:11.720 --> 00:18:14.620 tetapi ini bukan pipa ajaib untuk setiap tabel, laporan, atau sistem eksternal. 00:18:14.920 --> 00:18:17.540 Sebelum Anda mengaturnya, periksa integrasi apa saja yang sudah ada. 00:18:18.200 --> 00:18:21.360 Jika koneksi lama dan dual right keduanya memperberi catatan pelanggan yang sama, 00:18:21.700 --> 00:18:22.960 Anda bisa dengan cepat membuat konflik. 00:18:23.460 --> 00:18:24.440 Itu adalah masalah yang tidak Anda ingin. 00:18:24.900 --> 00:18:26.020 Jadi sepaketi hal ada satu video. 00:18:26.520 --> 00:18:27.560 Bagaimana Anda akan memasukkan alat? 00:18:27.820 --> 00:18:29.300 Perusahaan legal malah yang memiliki setiap catatan. 00:18:29.300 --> 00:18:30.420 Siapa yang bisa melakukan perubah? 00:18:30.800 --> 00:18:32.360 Peran keamanan apa yang dibutuhkan setiap tim. 00:18:32.360 --> 00:18:35.500 Duplikat dan catatan yang tidak lengkap sebelum sinkronisasi pertama. 00:18:35.800 --> 00:18:37.360 Mulai dari peta yang telah dibuat sebelumnya oleh Microsoft. 00:18:37.780 --> 00:18:38.900 Peta tersebut sudah menghubungkan catatan. 00:18:39.120 --> 00:18:41.560 Tabel dan penyak kustom hal tersebut memerlukan pengujian yang cermat. 00:18:41.840 --> 00:18:43.780 Dan periksa tabel terkait serta dependensi peta. 00:18:44.200 --> 00:18:47.320 Karena terkadang satu catatan memerlukan catatan lain untuk ada sebelum bisa disinkronkan. 00:18:47.620 --> 00:18:49.900 Rencanakan sinkronisasi pertama Anda berdasarkan jumlah data yang kandang. 00:18:50.060 --> 00:18:52.360 Jangan menganggapnya seperti sakal rampu yang Anda nyalakan saat makan sini. 00:18:52.600 --> 00:18:53.500 Itu akan menimbulkan masalah. 00:18:53.900 --> 00:18:56.280 Peta yang dijeda tetap memerlukan pemilik dan rencana untuk umur. 00:18:56.280 --> 00:18:58.960 Perubahan yang antre dan catatan yang gagal tidak akan bertahan selama. 00:18:59.420 --> 00:19:02.140 Pantau log aktivitas, kesalahan, peringatan, dan ambang batas. 00:19:02.640 --> 00:19:06.220 Ketika ada yang gagal, temukan bidang yang hilang catatan yang rusak atau aturan yang dilanggar dibaliknya. 00:19:06.680 --> 00:19:08.380 Percobaan ulang yang berulang tidak akan memperbaiki data. 00:19:08.660 --> 00:19:11.920 Saat Anda melihat dual rate sebagai jembatan yang terkontrol, semuanya akan menjadi jelas. 00:19:13.280 --> 00:19:15.160 Kesimpulan, satu percakapan bisnis yang sama. 00:19:16.180 --> 00:19:21.500 Dual rate menjaga catatan bersama yang didukung tetap bergerak antara keuangan dan operasional serta aplikasi pelanggan berbasis data pesan. 00:19:22.160 --> 00:19:24.460 Dengan begitu, tim dapat bekerja dari data bisnis yang terhubung. 00:19:24.460 --> 00:19:31.720 Berlangganan di platform podcast favorit Anda untuk mendapatkan lebih banyak wawasan bersama saya, Mirko Peters, di emtikan episode ini 00:19:31.720 --> 00:19:36.940 kepada seseorang yang masih menghubungkan penjualan, layanan, dan keuangan melalui lembar kerja lain.