WEBVTT 00:00:00.000 --> 00:00:03.440 Sistem tiket terletas-retas. Anda mendapatkan angka-angkanya, antreannya, dan sebornya. 00:00:04.120 --> 00:00:07.740 Namun kenyataannya, model itu hanya mengukur masalah setelah sistem sudah gagal. 00:00:08.240 --> 00:00:10.720 Bagian yang mahal dari masalah ini biasanya dimulai jauh lebih awal. 00:00:11.080 --> 00:00:14.280 Dimulai saat karyawan kehilangan 10 menit, lalu 20, hingga akhirnya menyerah. 00:00:14.560 --> 00:00:16.400 Mereka mencoba lagi. Mereka bertanya pada akan kerja. 00:00:16.580 --> 00:00:20.020 Mereka melewatkan rapat atau membagikan file yang salah karena jalur yang benar-benar berarti berfungsi. 00:00:20.160 --> 00:00:22.180 Dan itulah bagian besar tim dukungan masih belum lihat. 00:00:22.680 --> 00:00:25.480 Model dukungan internal terbaik saat ini bukanlah tentang triase yang lebih cepat. 00:00:25.840 --> 00:00:27.980 Ini tentang menghapus kebutuhan akan triase sepenuhnya. 00:00:27.980 --> 00:00:36.380 Bayangkan agen otonom di dalam Microsoft 365 yang mengawasi konteks mendeteksi hambatan lebih awal dan bertindak sebelum seseorang berpikir untuk membuka portal. 00:00:37.580 --> 00:00:43.880 Dalam episode ini, saya ingin menunjukkan mengapa model hubdesk rusak, apa yang benar-benar menggantikannya, dan bagaimana Anda dapat mengaturnya tanpa menciptakan kekacauan. 00:00:44.340 --> 00:00:48.900 Jika perubahan ini penting bagi pekerjaan Anda, berlanggananlah ke M365FM karena satu tingkat lebih dalam. 00:00:49.160 --> 00:00:51.380 Masalah sebenarnya bukanlah antrean, melainkan model di baliknya. 00:00:52.060 --> 00:00:55.020 Kematian tiket. Alur dukungan lama masih ada di mana-mana. 00:00:55.020 --> 00:00:58.480 Sesuatu rusak, mengguna menyadarinya, mengguna mencoba menjelaskannya. 00:00:59.000 --> 00:01:05.020 Kemudian TI menerjemahkan penjelasan itu ke dalam kategori prioritas dan mungkin grup penugasan asal masuk keantrean. 00:01:05.500 --> 00:01:07.800 Seseorang melakukan triase. Orang lain meminta detail lebih lanjut. 00:01:08.220 --> 00:01:11.500 Tim lain terlibat. Waktu terus berjalan sementara pekerjaan sebenarnya tetap macet. 00:01:11.920 --> 00:01:15.960 Proses itu terasa normal karena sudah lazim. Tetapi lazim dan efektif bukanlah hal yang sama. 00:01:16.760 --> 00:01:19.760 Tiket bukanlah dukungan. Tiket adalah bukti bahwa dukungan datang terlambat. 00:01:19.760 --> 00:01:23.900 Saat tiket bahkan belum ada, karyawan sudah mengalami hambatan dan kehilangan konteksnya. 00:01:24.660 --> 00:01:27.440 Mereka sudah mengalihkan perhatian dari pekerjaan yang sedang mereka coba lakukan. 00:01:27.980 --> 00:01:30.380 Antrean bukanlah lainnya. Antrean adalah catatan kegagalan. 00:01:30.840 --> 00:01:34.380 Di ekosistem Microsoft 365 yang besar, triase manual menjadi hambatan sebenarnya. 00:01:34.940 --> 00:01:36.440 Ini tidak terjadi karena tim dukungan malas. 00:01:37.140 --> 00:01:40.960 Ini terjadi karena manusia diminta melakukan sesuatu yang tidak lagi sesuai dengan skala lingkungan tersebut. 00:01:41.420 --> 00:01:43.820 Anda memiliki lebih banyak pengguna, perangkat, aplikasi, dan kebijakan. 00:01:43.820 --> 00:01:49.380 Anda memiliki lebih banyak kasus unik yang melintasi tim. SharePoint, Exchange, Intune, dan Entra secara bersamaan. 00:01:50.180 --> 00:01:52.160 Belum tidak hanya bertambah. Kombinasinya yang bertambah. 00:01:52.860 --> 00:01:56.320 Disitulah modal lama rusak. Kebanyakan tim merespons dengan menambahkan lebih banyak struktur. 00:01:56.660 --> 00:01:59.220 Mereka membangun portal lain, bot lain, atau aturan pelutian lain. 00:01:59.680 --> 00:02:03.440 Namun kenyataannya, itu hanya menambah satu lapisan lagi antara karyawan dan penjelesaian masalah. 00:02:03.880 --> 00:02:09.060 Sistem masih menunggu pengguna untuk menyadari masalahnya, menjelaskannya, dan meminta bantuan dengan cara yang tepat. 00:02:09.060 --> 00:02:17.140 Pekerjaan tidak dimulai di portal dukungan, melainkan di Teams, di Outlook, di dokumen yang dibutuhkan seseorang saat ini, atau rapat yang dimulai 30 detik lagi. 00:02:17.720 --> 00:02:21.900 Disanalah permintaan dukungan sebenarnya bermula, dan model tiket sama sekali terlepas dari momen tersebut. 00:02:22.440 --> 00:02:24.980 Biaya tersebutnya jauh lebih besar daripada yang ditunjukkan oleh laporan Anda. 00:02:25.360 --> 00:02:26.120 Perangkat beralian kontek. 00:02:26.700 --> 00:02:28.760 Insiden duplikat menumpuh di bawah label yang berbeda-beda. 00:02:29.060 --> 00:02:30.220 Artikel pengetahuan menjadi usaha. 00:02:30.760 --> 00:02:34.640 Analis menghabiskan sepanjang hari untuk menyortir, mengarahkan, dan mengklarifikasi alih benar-benar berbalik sesuatu. 00:02:34.640 --> 00:02:40.940 Waktu penyelesaian menjadi lama, karena setiap serah terima menambah penundaan, dan setiap penundaan menghilangkan konteks aslinya. 00:02:41.500 --> 00:02:44.740 Penelitian tentang AI gen dan operasional TI menunjukkan masalah struktural yang sama. 00:02:45.380 --> 00:02:48.480 Setidaknya 80% payah masih terjebak dalam pekerjaan reaktif bergaya. 00:02:48.900 --> 00:02:51.820 Angka itu penting karena memberitahu Anda kemana sebenarnya tenaga kerja dicurah. 00:02:52.320 --> 00:02:54.980 Itu tidak masuk ke dalam ketahanan atau pencegahan, melainkan ke dalam reaksi. 00:02:55.360 --> 00:02:59.080 Begitu Anda melihatnya, tiket melihat terlihat bukan sebagai model operasi, melainkan sebagai sebuah gejala. 00:02:59.480 --> 00:03:02.240 Ini adalah gejala dari sistem yang hanya merespon setelah kerusakan terlihat. 00:03:02.240 --> 00:03:05.180 Jadi pertanyaan selanjutnya bukan bagaimana memproses tiket lebih cepat, 00:03:05.240 --> 00:03:07.500 melainkan apa yang harus dilakukan sistem sebelum tiket diperlukan. 00:03:08.240 --> 00:03:09.280 Model karyawan tak terlihat. 00:03:09.760 --> 00:03:10.940 Jadi apa yang sebenarnya menggantikan tiket? 00:03:11.400 --> 00:03:14.140 Ini bukan sekadar chatbot lain yang berada di atas kekacauan yang sama, 00:03:14.260 --> 00:03:16.820 dan jelas bukan pintu depan yang lebih cantik untuk antrean lama yang sama. 00:03:17.480 --> 00:03:20.880 Perubahan ini jauh lebih dalam karena karyawan tak terlihat adalah pekerja operasional 00:03:20.880 --> 00:03:23.200 yang hidup di dalam lingkungan Microsoft 365 Anda. 00:03:24.160 --> 00:03:27.260 Agen ini memiliki identitasnya sendiri, cakupan kerja yang ditentukan, 00:03:27.360 --> 00:03:30.880 ingatan tentang apa yang dilakukannya kemarin, dan aturan ketat tentang apa yang boleh dan tidak boleh disentuh. 00:03:30.880 --> 00:03:32.100 Perbedaan itu penting. 00:03:32.780 --> 00:03:36.520 Chatbot menunggu Anda mengetik perintah, tetapi karyawan tak terlihat memantau perubahan kondisi. 00:03:37.060 --> 00:03:39.660 Ia memulai dari konteks, alih-alih memulai dari percakapan. 00:03:40.260 --> 00:03:44.320 Karena ia dapat melihat status masuk, kesehatan perangkat, status lisensi, dan bagaimana file dibagikan, 00:03:44.600 --> 00:03:45.940 ia tidak perlu menunggu hambatan muncul. 00:03:46.700 --> 00:03:49.340 Alih-alih bertanya bagaimana ia bisa membantu setelah sesuatu rusak, 00:03:49.460 --> 00:03:51.500 ia terus-menerus menanyakan pertanyaan berbeda di latar belak. 00:03:51.500 --> 00:03:55.300 Apa yang menyimpang dari kondisi yang dibutuhkan karyawan ini untuk melakukan pekerjaannya saat ini? 00:03:56.020 --> 00:03:57.040 Disitulah segalanya berubah. 00:03:57.440 --> 00:03:59.660 Model ini tertanam langsung di dalam pekerjaan itu sendiri. 00:03:59.660 --> 00:04:02.980 Ketika seseorang bergabung dalam rapat dan perutian audio gagal, 00:04:03.120 --> 00:04:05.700 atau tamu tidak dapat membuka file yang baru saja dikirimkan, 00:04:05.840 --> 00:04:08.000 dunia lama akan membuat laporan dan serah terima. 00:04:08.720 --> 00:04:10.800 Dalam model baru ini, agen langsung mengenali polanya, 00:04:10.920 --> 00:04:13.140 memeriksa apakah kondisinya sesuai dengan masalah yang diketahui, 00:04:13.360 --> 00:04:15.140 lalu mengambil tindakan aman untuk memperbaikinya. 00:04:15.860 --> 00:04:18.320 Mungkin ia mereset jalur atau memicu pemeriksaan kebijakan, 00:04:18.320 --> 00:04:21.460 atau mungkin mengalihkan permintaan dan meminta MFA sebelum mendokumentasikan perbaikannya. 00:04:22.240 --> 00:04:22.780 Intinya sederhana. 00:04:23.300 --> 00:04:27.300 Respons pertama tidak lagi mengharuskan manusia membaca deskripsi yang samar dan menebak apa yang terjadi. 00:04:27.300 --> 00:04:31.020 Hal ini terasa tak terlihat jika berjalan lancar karena tidak ada ruang tunggu 00:04:31.020 --> 00:04:32.900 dan tidak perlu mengisi formulir pilih kategori. 00:04:33.160 --> 00:04:34.720 Dukungan muncul sebagai alur yang kembali normal. 00:04:35.200 --> 00:04:36.440 Karyawan cukup kembali bekerja, 00:04:36.780 --> 00:04:39.840 dan dalam banyak kasus mereka bahkan tidak pernah melihat mesin yang bekerja di balik layar. 00:04:40.300 --> 00:04:42.880 Anda sudah bisa melihat bagaimana hal ini mengumpul logika penempatan staffan. 00:04:43.300 --> 00:04:45.600 Model lama mempekerjakan orang untuk menyerap volume, 00:04:45.820 --> 00:04:48.440 memilah permintaan, dan perbaiki konteks yang rusak antar tim. 00:04:48.980 --> 00:04:51.520 Model baru membutuhkan lebih sedikit orang untuk melakukan triase, 00:04:51.800 --> 00:04:53.760 dan lebih banyak orang untuk melancang pagar pembatas, 00:04:53.960 --> 00:04:54.920 menentukan kondisi yang diinginkan, 00:04:54.920 --> 00:04:56.680 dan mengawasi perilaku agen tersebut dari waktu kewak. 00:04:56.880 --> 00:04:58.100 Manusia tetap berada dalam sistem, 00:04:58.360 --> 00:05:00.420 tetapi seluruh bentuk pekerjaan harian mereka berubah. 00:05:01.080 --> 00:05:03.800 Penelitian tentang AI gen dalam dukungan terus mengarah ke arah ini. 00:05:04.620 --> 00:05:07.320 Dukungan rutin dapat beralih ke penanganan berbasis pengecualian, 00:05:07.760 --> 00:05:11.620 yang menciptakan peningkatan efisiensi yang masif ketika lingkungan dan kebijakannya dibatasi dengan baik. 00:05:12.160 --> 00:05:13.920 Bagian terakhir itu vital, karena ini bukan sihir. 00:05:14.560 --> 00:05:16.340 Jika data Anda lemah atau proses Anda berantakan, 00:05:16.680 --> 00:05:19.640 agen tidak akan menjadi pintar hanya karena Anda memutuskan untuk menyebutnya otonom. 00:05:19.640 --> 00:05:24.080 Semua ini menjadi masuk akal bagi saya ketika saya berhenti menganggap agen sebagai fitur perangkat lunak 00:05:24.080 --> 00:05:26.380 dan mulai melihatnya sebagai karyawana manusia dengan tanda pengenal. 00:05:26.940 --> 00:05:28.380 Pekerjaan nyata membutuhkan identitas, 00:05:28.620 --> 00:05:29.680 deskripsi pekerjaan, izin, 00:05:29.960 --> 00:05:30.880 dan manajer untuk melapor. 00:05:31.420 --> 00:05:35.340 Agen membutuhkan hal yang persis sama karena nilainya berasal dari tindakan yang andal di dalam sistem, 00:05:35.500 --> 00:05:37.220 bukan dari bahasa cerdas di jendela obrolan. 00:05:37.940 --> 00:05:39.880 Karyawan yang tidak terlihat ini bukan sekadar trik UI. 00:05:39.880 --> 00:05:44.280 Ini adalah lapisan dukungan baru yang mengawasi gesekan di seluruh aset Microsoft 365, 00:05:44.840 --> 00:05:45.880 bertindak sesuai kebijakan, 00:05:46.100 --> 00:05:49.100 dan mengarahkan perhatian manusia pada pengecualian yang benar-benar memerlukan penilaian. 00:05:49.940 --> 00:05:52.340 Setelah model itu jelas, pertanyaan berikutnya menjadi sangat praktis. 00:05:52.820 --> 00:05:53.960 Bagaimana cara kerja pre-MT yang sebenar? 00:05:54.620 --> 00:05:55.440 Arsitektur pre-MT 00:05:55.440 --> 00:05:59.000 Jadi, bagaimana cara kerja pre-MT di dalam Microsoft 365? 00:05:59.560 --> 00:06:02.720 Pergeserannya bergerak dari permintaan dan respons ke penawaran peristiwa dan orkestrasi. 00:06:03.200 --> 00:06:05.860 Itu terdengar teknis, tetapi modelnya sederhana setelah Anda membedahnya. 00:06:05.860 --> 00:06:11.080 Pertama, sesuatu di lingkungan berubah, kemudian sistem menafsirkan apakah perubahan itu berarti risiko atau penyimpangan. 00:06:11.200 --> 00:06:14.640 Dan akhirnya, sistem mengambil tindakan yang disetujui menggunakan alat yang sudah ada tumpukan Anda. 00:06:15.140 --> 00:06:15.960 Nah, dengan lapisan peristiwa. 00:06:16.560 --> 00:06:19.280 Microsoft tiga-an sinyal di mana-mana, yang berarti Entra. 00:06:19.760 --> 00:06:23.400 Entra melihat perilaku masuk sementara Inton melacak postur dan kepatuhan perangkat. 00:06:24.460 --> 00:06:26.080 Defender mengawasi aktivitas mencurigakan, 00:06:26.360 --> 00:06:29.260 dan Teams menunjukkan kepada Anda dengan tepat kapan rapat gagal atau kualitas pengen. 00:06:29.720 --> 00:06:32.420 SharePoint dan Actions mengungkap pola akses serta aktivitas konten, 00:06:32.420 --> 00:06:35.900 dan sementara, sinyal kesehatan layanan memberitahu Anda saat platform itu sendiri yang bermasalah. 00:06:36.440 --> 00:06:39.860 Saat Anda menambahkan tindakan pengguna di atasnya, Anda memiliki aliran konteks yang konsep. 00:06:40.160 --> 00:06:42.200 Kebanyakan organisasi mengumpulkan sinyal-sinyal tersebut, 00:06:42.340 --> 00:06:44.560 tetapi sangat sedikit yang benar-benar menggunakannya sebagai sistem pendukung. 00:06:44.720 --> 00:06:46.160 Peristiwa mentah saja tidak membantu, 00:06:46.620 --> 00:06:48.960 karena mereka membutuhkan lapisan penalaran untuk memahami kebisingnya tersebut. 00:06:49.260 --> 00:06:51.940 Disinilah karyawan tak terlihat berhenti menjadi sekadar teater otomatisasi 00:06:51.940 --> 00:06:53.340 dan mulai bertindak layaknya operatornya. 00:06:53.440 --> 00:06:54.680 Agen melihat sinyal tersebut, 00:06:55.040 --> 00:06:57.160 membandingkan status saat ini dengan status yang diinginkan, 00:06:57.160 --> 00:06:59.260 dan memutuskan kelas tindakan apa yang aman untuk diambil. 00:06:59.480 --> 00:07:01.820 Masalah audio rapat tidak sama dengan masuk yang berisiko 00:07:01.820 --> 00:07:04.620 dan tautan berbagi yang rusak berbeda dari ketidakcocokan lisensi. 00:07:05.240 --> 00:07:07.140 Agen harus mengklasifikasikan masalahnya terlebih dahulu 00:07:07.140 --> 00:07:08.700 karena mengambil tindakan tanpa klasifikasi 00:07:08.700 --> 00:07:10.020 hanya akan menciptakan kesalahan lebih cepat. 00:07:10.360 --> 00:07:11.160 Kemudian dibalak orkestrasi. 00:07:12.060 --> 00:07:13.300 Setelah agen memahami masalahnya, 00:07:13.480 --> 00:07:15.380 ia dapat menggunakan mekanisme yang tepat untuk merespon. 00:07:15.680 --> 00:07:17.560 Itu bisa berupa power automate untuk alur kerja, 00:07:17.560 --> 00:07:18.780 co-pilot studio untuk logika, 00:07:18.880 --> 00:07:20.740 atau Microsoft Grab untuk tindakan sistem dan konteks. 00:07:21.160 --> 00:07:21.860 Alatnya memang penting, 00:07:21.860 --> 00:07:24.000 tetapi poin yang lebih besar adalah bagaimana mereka saling keruh. 00:07:24.460 --> 00:07:26.240 Anda tidak sedang membangun suatu perintah cerdas, 00:07:26.400 --> 00:07:27.680 melainkan rantai yang dapat mendeteksi, 00:07:27.840 --> 00:07:29.280 memutuskan bertindak, dan memverifikasi. 00:07:29.780 --> 00:07:31.220 Pagian terakhir itu seringkali terlewatkan. 00:07:31.640 --> 00:07:32.920 Sistem yang mengoreksi diri sendiri 00:07:32.920 --> 00:07:34.400 tidak berhenti begitu tindakan diambil. 00:07:34.940 --> 00:07:36.080 Sistem ini menjalankan perulangan 00:07:36.080 --> 00:07:37.580 di mana ia mendeteksi masalah, 00:07:37.720 --> 00:07:39.160 menguji kondisi, menerapkan perbaikan, 00:07:39.320 --> 00:07:41.340 dan memverifikasi hasil sebelum mencatat apa yang terjadi. 00:07:41.580 --> 00:07:43.580 Penelitian tentang logika pengoreksian mandiri 00:07:43.580 --> 00:07:45.340 memperjelas bahwa sistem ini bekerja melalui 00:07:45.340 --> 00:07:46.600 pola umpan balik dan koreksi 00:07:46.600 --> 00:07:48.900 alih-alih satu jawaban terisolasi dari model bahasa. 00:07:49.580 --> 00:07:50.400 Jika tindakan pertama, 00:07:50.580 --> 00:07:52.620 sistem memerlukan cara untuk menilai alasannya 00:07:52.620 --> 00:07:54.220 sehingga ia dapat merevisi langkah berikutnya 00:07:54.220 --> 00:07:55.840 sambil tetap berada dalam batas yang ditentukan. 00:07:56.360 --> 00:07:57.580 Anda dapat membayangkan ini dengan jelas 00:07:57.580 --> 00:07:58.920 dalam beberapa kasus Microsoft 3. 00:07:59.400 --> 00:08:00.960 Ketika pengguna diblokir karena lisensi 00:08:00.960 --> 00:08:02.540 dan cakupan kebijakan mereka tidak cocok, 00:08:02.880 --> 00:08:04.340 agen mendeteksi ketidakcocokan tersebut 00:08:04.340 --> 00:08:05.580 dan memeriksa profil peran yang dituju. 00:08:06.160 --> 00:08:07.580 Ia menerapkan koreksi yang diizinkan, 00:08:07.740 --> 00:08:09.140 mengonfirmasi pengguna memiliki akses, 00:08:09.240 --> 00:08:10.200 dan mencatat perubahan tersebut 00:08:10.200 --> 00:08:11.520 tanpa perlu bertanya kepada siapapun. 00:08:11.520 --> 00:08:13.600 Jika masuk yang berisi kemuncul di Entra, 00:08:13.780 --> 00:08:15.220 agen melihat peristiwa risiko tersebut 00:08:15.220 --> 00:08:17.180 dan segera meriksa aturan akses bersyarat Anda. 00:08:17.840 --> 00:08:19.520 Ia meminta verifikasi yang lebih kuat 00:08:19.520 --> 00:08:21.600 atau memblokir akses berdasarkan kebijakan Anda 00:08:21.600 --> 00:08:23.620 lalu mencatat hasilnya untuk ditinggalkan manusia nanti. 00:08:24.260 --> 00:08:25.500 Saat tautan berbagi yang kedaluar 00:08:25.500 --> 00:08:26.600 se terus gagal di SharePoint, 00:08:26.880 --> 00:08:28.340 agen membandingkan calur izin saat ini 00:08:28.340 --> 00:08:29.880 dengan aturan berbagi yang diharapkan. 00:08:30.780 --> 00:08:31.900 Agen mengganti akar yang rusak 00:08:31.900 --> 00:08:33.720 dengan disetujui dan mengirimkan tautan 00:08:33.720 --> 00:08:35.060 yang diperbaiki dalam konteksnya 00:08:35.060 --> 00:08:37.540 yang menyelesaikan masalah sebelum analis meja bantuan 00:08:37.540 --> 00:08:38.660 harus membaca tiket berjudul 00:08:38.660 --> 00:08:39.680 Masalah Akses Mendesak. 00:08:40.720 --> 00:08:42.100 Dukungan rapat adalah contoh bagus lainnya. 00:08:42.640 --> 00:08:43.760 Jika perangkat ruangan gagal 00:08:43.760 --> 00:08:45.540 atau jalur bergabung terputus beberapa detik 00:08:45.540 --> 00:08:46.440 sebelum panggilan dimulai, 00:08:46.580 --> 00:08:47.880 agen dapat mendeteksi kondisi tersebut 00:08:47.880 --> 00:08:48.760 dan memvalidasi kerusakan. 00:08:49.060 --> 00:08:50.700 Agen mencoba langkah pemulihan berisi koran rendah 00:08:50.700 --> 00:08:51.960 dan memberitahu penyelenggaraan di Teams 00:08:51.960 --> 00:08:53.020 dengan pembaruan status tepat 00:08:53.020 --> 00:08:54.040 di tempat pekerjaan berlangsung. 00:08:54.700 --> 00:08:56.760 Lapisan komunikasi itu adalah bagian besar dari desainnya. 00:08:57.380 --> 00:08:59.060 Dukungan harus ada di tempat gangguan itu terjadi. 00:08:59.880 --> 00:09:01.400 Jika pekerjaan Anda dilakukan di Teams, 00:09:01.500 --> 00:09:02.880 Outlook, dan ruang kerja M365, 00:09:02.880 --> 00:09:04.820 maka dukungan juga harus menjawab Anda di sana. 00:09:05.760 --> 00:09:07.360 Anda tidak perlu menarik pengguna ke tempat lain 00:09:07.360 --> 00:09:09.240 saat Anda bisa menemunya sesuai konteks peristiwa. 00:09:09.940 --> 00:09:11.600 Semua ini tidak berarti otomatisasi penuh 00:09:11.600 --> 00:09:13.640 untuk setiap tugas karena itu akan sangat gegabah. 00:09:14.340 --> 00:09:16.240 Tindakan berisi koran rendah dapat berjalan otomatis 00:09:16.240 --> 00:09:17.460 tetapi perubahan berdampak tinggi 00:09:17.460 --> 00:09:18.540 tetap memerlukan persetujuan. 00:09:18.880 --> 00:09:19.980 Jalur persetujuan tersebut 00:09:19.980 --> 00:09:22.160 harus menjadi bagian dari arsitektur sejak awal, 00:09:22.300 --> 00:09:23.640 bukan ditambahkan di kemudian hari. 00:09:24.120 --> 00:09:24.900 Agen harus bertindak, 00:09:24.980 --> 00:09:25.640 kapan harus bertindak, 00:09:25.740 --> 00:09:26.400 kapan harus bertanya, 00:09:26.500 --> 00:09:27.480 dan kapan tempatnya harus bertanya. 00:09:27.980 --> 00:09:29.680 Dan setelah Anda membangunnya ke dalam alur kerja, 00:09:29.680 --> 00:09:31.880 percakapan tidak lagi mengenai fitur otomatisasi. 00:09:32.240 --> 00:09:33.400 Percakapan beralih kekendali, 00:09:33.760 --> 00:09:34.200 tata kelola, 00:09:34.440 --> 00:09:35.040 kepercayaan, 00:09:35.280 --> 00:09:36.020 dan identitas agen. 00:09:36.520 --> 00:09:38.180 Ketika dukungan mulai bertindak sendiri, 00:09:38.280 --> 00:09:39.740 pertanyaan sudah muncul seketika 00:09:39.740 --> 00:09:41.660 siapa sebenarnya yang melakukan pekerjaan itu? 00:09:42.400 --> 00:09:43.560 Jika jawabannya tidak jelas, 00:09:43.680 --> 00:09:44.680 seluruh model akan berantak. 00:09:45.280 --> 00:09:46.800 Agen tidak bisa hadir di lingkungan Anda 00:09:46.800 --> 00:09:48.440 sebagai pembantu sama dengan akses luas 00:09:48.440 --> 00:09:49.320 tanpa pemilik yang jelas. 00:09:49.700 --> 00:09:51.300 Agen membutuhkan identitas nyata di entra. 00:09:51.620 --> 00:09:52.900 Agen membutuhkan pemilik bernama, 00:09:53.020 --> 00:09:53.800 lingkup yang ditentukan, 00:09:53.940 --> 00:09:55.380 dan siklus hidup yang dimulai dan berakhir 00:09:55.380 --> 00:09:56.380 karena alasan spesifik. 00:09:56.380 --> 00:09:58.320 Jika agen tersebut dapat membaca data, 00:09:58.520 --> 00:09:59.340 memicu alur kerja, 00:09:59.480 --> 00:10:00.900 atau mengirim pesan kepada pengguna Anda, 00:10:01.020 --> 00:10:01.820 Anda harus mengelolahnya 00:10:01.820 --> 00:10:03.000 sebagai peserta aktif di penyewa. 00:10:03.320 --> 00:10:04.400 Anda tidak bisa memperlakukannya 00:10:04.400 --> 00:10:05.580 seperti fitur yang dinyalakan seseorang 00:10:05.580 --> 00:10:06.180 kalau dilupakan begitu. 00:10:06.440 --> 00:10:07.880 Inilah mengapa identitas agen 00:10:07.880 --> 00:10:08.940 sangat penting bagi sistem. 00:10:09.660 --> 00:10:11.000 Anda perlu tahu persis apa agen itu, 00:10:11.160 --> 00:10:12.400 sistem mana yang bisa diaksesnya, 00:10:12.720 --> 00:10:14.400 dan siapa yang dihubungi ketika ada masalah. 00:10:14.960 --> 00:10:16.560 Hak akses terkecil harus menjadi dasar di sini. 00:10:16.840 --> 00:10:18.380 Anda tidak bisa puas dengan kemudahan yang luas 00:10:18.380 --> 00:10:19.420 atau meyakinkan diri sendiri 00:10:19.420 --> 00:10:20.760 bahwa Anda akan memperketat izinan. 00:10:21.360 --> 00:10:23.000 Karena dapat luas dari agen pendukung sepenuhnya 00:10:23.000 --> 00:10:24.960 bergantung pada izinnya merancang izin tersebut 00:10:24.960 --> 00:10:27.200 adalah bagian inti dari merancang dukungan. 00:10:28.360 --> 00:10:30.840 Agen 365 berfungsi sebagai lapisan kontrol 00:10:30.840 --> 00:10:32.080 yang diperlukan dalam pengaturan ini 00:10:32.080 --> 00:10:33.500 karena memberikan pandangan yang jelas 00:10:33.500 --> 00:10:34.640 terhadap seluruh ekosistem agen. 00:10:35.060 --> 00:10:36.180 Ini menyediakan registri, 00:10:36.320 --> 00:10:37.260 alur kerja persetujuan, 00:10:37.380 --> 00:10:38.180 dan tempelat kebijakan 00:10:38.180 --> 00:10:39.800 yang menjaga semuanya tetap berjalan dengan aman. 00:10:40.240 --> 00:10:41.720 Meskipun bagian-bagian tersebut terdengar 00:10:41.720 --> 00:10:42.820 seperti tugas administratif, 00:10:42.880 --> 00:10:44.540 hal itu menyelesaikan masalah struktural yang sangat besar. 00:10:44.880 --> 00:10:46.200 Kebanyakan organisasi tidak kesulitan 00:10:46.200 --> 00:10:47.200 karena kekurangan fitur AI, 00:10:47.520 --> 00:10:49.040 tetapi karena mereka tidak dapat melihat 00:10:49.040 --> 00:10:50.300 atau mengontrol apa yang sudah berjalan 00:10:50.300 --> 00:10:50.940 di lingkungan mereka. 00:10:51.520 --> 00:10:52.900 Penelitian mengenai poin ini sangatlah jadat. 00:10:53.340 --> 00:10:54.840 Hanya sebagian kecil dari perusahaan besar 00:10:54.840 --> 00:10:56.500 yang dapat menginventarisasi sepenuhnya 00:10:56.500 --> 00:10:58.320 setiap agen yang saat ini berjalan di sistem mereka. 00:10:58.980 --> 00:11:00.340 Sebelum para pemimpin mulai berbicara 00:11:00.340 --> 00:11:01.640 tentang memperluas dukungan otonom, 00:11:01.720 --> 00:11:03.420 mereka harus menjawab pertanyaan yang jauh lebih seder. 00:11:03.880 --> 00:11:05.440 Apakah kita bahkan tahu agen mana yang ada 00:11:05.440 --> 00:11:06.780 dan apa yang mereka lakukan saat ini? 00:11:07.280 --> 00:11:08.520 Pengawasan juga harus disesuaikan 00:11:08.520 --> 00:11:09.580 dengan tingkat risiko yang terlibat. 00:11:10.080 --> 00:11:11.120 Agen produktivitas pribadi 00:11:11.120 --> 00:11:12.180 yang bekerja di lingkup terbatas 00:11:12.180 --> 00:11:12.820 adalah satu hal, 00:11:12.960 --> 00:11:14.800 tetapi agen kolaboratif yang menyentuh konten bersama 00:11:14.800 --> 00:11:16.000 adalah hal yang sama sekali berbeda. 00:11:20.300 --> 00:11:21.140 Kategori risiko berbeda. 00:11:21.520 --> 00:11:23.280 Inilah mengapa model zona risiko pribadi, 00:11:23.420 --> 00:11:25.120 kolaboratif, dan perusahaan sangatlah penting. 00:11:25.600 --> 00:11:26.960 Model kontrol Anda harus meningkat seiring 00:11:26.960 --> 00:11:27.740 dengan dampak yang mengintip. 00:11:28.560 --> 00:11:30.000 Jika Anda memperlakukan setiap agen, 00:11:30.360 --> 00:11:31.840 dengan sama, pekerjaan risiko rendah 00:11:31.840 --> 00:11:33.280 akan tergubur dalam persetujuan yang lambat 00:11:33.280 --> 00:11:34.560 sementara pekerjaan risiko tinggi lolos 00:11:34.560 --> 00:11:35.260 dengan pengawasan yang. 00:11:35.440 --> 00:11:37.980 Minimal, tumpukan kontrol Anda di Microsoft 3 S&P 5 00:11:37.980 --> 00:11:39.360 harus terlihat familiar bagi tim Anda. 00:11:39.780 --> 00:11:41.280 Anda menggunakan identitas di entra, 00:11:41.420 --> 00:11:42.540 batas data melalui preview, 00:11:42.700 --> 00:11:43.800 dan pemantauan melalui defender. 00:11:44.240 --> 00:11:45.600 Anda menerapkan ketentuan akses 00:11:45.600 --> 00:11:46.740 melalui akses kondisional, 00:11:46.740 --> 00:11:48.300 dan memastikan auditabilitas 00:11:48.300 --> 00:11:49.580 sudah terintegrasi sejak awal. 00:11:49.900 --> 00:11:51.120 Anda harus dapat merekonstruksi 00:11:51.120 --> 00:11:52.240 dengan tepat apa yang terjadi 00:11:52.240 --> 00:11:53.140 tanpa harus menebak-nebak 00:11:53.140 --> 00:11:54.220 setelah insiden terjadi. 00:11:54.700 --> 00:11:56.020 Pengawasan manusia harus dirancang 00:11:56.020 --> 00:11:56.680 ke dalam logika, 00:11:56.960 --> 00:11:58.580 bukan diimprovisasi saat terjadi krisis. 00:11:59.160 --> 00:12:00.080 Tindakan berdampak tinggi 00:12:00.080 --> 00:12:00.920 harus selalu berhenti 00:12:00.920 --> 00:12:02.060 untuk mendapatkan persetujuan menurut. 00:12:02.520 --> 00:12:03.400 Penalaran harus dicatat 00:12:03.400 --> 00:12:04.200 dalam bentuk yang benar-benar 00:12:04.200 --> 00:12:05.480 dapat diksa dan dipahami oleh orang lain. 00:12:05.960 --> 00:12:07.540 Anda perlu memiliki jalur pemulihan, 00:12:07.680 --> 00:12:09.840 rollback sebelum tindakan otonom pertama dijalankan. 00:12:10.460 --> 00:12:11.660 Jika agen memperbarui akses 00:12:11.660 --> 00:12:12.980 atau mengubah kebijakan perutean, 00:12:12.980 --> 00:12:14.100 seseorang harus memiliki cara 00:12:14.100 --> 00:12:15.080 untuk melecak keputusan itu 00:12:15.080 --> 00:12:16.100 dan membatalkannya dengan bersih. 00:12:16.480 --> 00:12:17.680 Ada faktor lain yang sering dilewatkan 00:12:17.680 --> 00:12:18.220 para pemimpin 00:12:18.220 --> 00:12:19.640 karena demo awal terlihat sangat bagus. 00:12:20.180 --> 00:12:20.920 Biar pengerjaan ulang. 00:12:21.660 --> 00:12:23.200 Jika agen menciptakan siklus pembersihan 00:12:23.200 --> 00:12:23.740 untuk tim Anda, 00:12:23.920 --> 00:12:24.900 penghematan yang diproyeksikan 00:12:24.900 --> 00:12:25.660 akan hilang seketika. 00:12:26.080 --> 00:12:27.080 Ini adalah pajak pengerjaan ulang. 00:12:27.360 --> 00:12:28.620 Ini adalah waktu yang dihabiskan 00:12:28.620 --> 00:12:29.900 untuk memperbaiki hasil yang buruk, 00:12:29.980 --> 00:12:31.040 membalikkan tindakan yang salah 00:12:31.040 --> 00:12:32.160 atau mengejar efek samping 00:12:32.160 --> 00:12:32.760 yang tidak diinginkan. 00:12:33.040 --> 00:12:34.240 Jika tim Anda menghemat 10 menit 00:12:34.240 --> 00:12:34.800 dalam eksekusi 00:12:34.800 --> 00:12:36.000 tetapi menghabiskan 8 menit 00:12:36.000 --> 00:12:37.060 untuk membersihkan kekacauan, 00:12:42.980 --> 00:12:43.820 bukan kebijakan yang rapi 00:12:43.820 --> 00:12:44.560 atau pengumuman peluncuran. 00:12:44.780 --> 00:12:45.760 Kepercayaan muncul dari bukti 00:12:45.760 --> 00:12:46.160 saat berjalan. 00:12:46.520 --> 00:12:47.180 Orang perlu melihat 00:12:47.180 --> 00:12:48.040 apa yang dilihat agen, 00:12:48.120 --> 00:12:48.820 apa yang diputuskannya, 00:12:48.900 --> 00:12:50.020 dan apa yang benar-benar berubah dalam sistem. 00:12:50.180 --> 00:12:51.040 Begitulah cara Anda membangun 00:12:51.040 --> 00:12:52.100 kepercayaan pada dukungan otong. 00:12:52.440 --> 00:12:54.220 Buktinya harus terletak pada perilaku 00:12:54.220 --> 00:12:54.780 alat tersebut, 00:12:54.920 --> 00:12:55.940 bukan pada pencitraan proyeknya. 00:12:56.700 --> 00:12:58.260 Setelah fondasi tata kelola itu kuat, 00:12:58.360 --> 00:12:59.160 percakapan akhirnya 00:12:59.160 --> 00:13:00.860 bisa beralih dari jargon keamanan 00:13:00.860 --> 00:13:01.960 ke bahasa eksekutif. 00:13:02.600 --> 00:13:03.420 Apa sebenarnya perubahan ini 00:13:03.420 --> 00:13:04.160 bagi laba perusahaan? 00:13:05.020 --> 00:13:06.560 ROI baru dari dukungan yang tak terlihat. 00:13:07.100 --> 00:13:08.020 Begitu para pemimpin 00:13:08.020 --> 00:13:08.980 menerima model kendali, 00:13:09.080 --> 00:13:10.420 pertanyaan keuangan pun mulai bergeser. 00:13:10.720 --> 00:13:11.340 Dalam model lama, 00:13:11.560 --> 00:13:12.160 nilai dukungan diukur 00:13:12.160 --> 00:13:13.060 dari pekerjaan yang terlihat 00:13:13.060 --> 00:13:14.000 seperti tiket yang ditutup, 00:13:14.100 --> 00:13:14.820 panggilan yang ditangani, 00:13:14.960 --> 00:13:15.700 dan performa SLA. 00:13:16.220 --> 00:13:17.480 Angka-angka tersebut tetap penting, 00:13:17.560 --> 00:13:18.740 tetapi hanya menggambarkan reaksi 00:13:18.740 --> 00:13:19.520 terhadap suatu masalah. 00:13:19.820 --> 00:13:20.780 Angka-angka itu tidak memberitahu 00:13:20.780 --> 00:13:21.700 Anda berapa banyak gangguan 00:13:21.700 --> 00:13:22.660 yang tidak pernah sampai ke antrean 00:13:22.660 --> 00:13:23.680 atau berapa banyak terselamatkan 00:13:23.680 --> 00:13:24.720 atau waktu karyawan terselamatkan 00:13:24.720 --> 00:13:25.620 karena masalah di atas lebih awal. 00:13:25.760 --> 00:13:27.020 Itulah masalah akutansi yang mendasar. 00:13:27.520 --> 00:13:28.260 Dukungan yang tak terlihat 00:13:28.260 --> 00:13:28.840 menciptakan nilai 00:13:28.840 --> 00:13:29.740 melalui ketidakhadirannya. 00:13:30.060 --> 00:13:30.760 Anda melihat nilainya 00:13:30.760 --> 00:13:31.660 ketika tidak ada tiket, 00:13:31.760 --> 00:13:32.560 tidak ada eskalasi, 00:13:32.920 --> 00:13:33.580 dan tidak ada analis 00:13:33.580 --> 00:13:34.620 yang menghabiskan 20 menit 00:13:34.620 --> 00:13:35.640 untuk menyusun ulang masalah 00:13:35.640 --> 00:13:36.820 dari catatan yang tidak lengkap. 00:13:38.000 --> 00:13:39.020 Jika Anda hanya mengukur upaya 00:13:39.020 --> 00:13:40.020 yang terlihat dari tim dukungan, 00:13:40.100 --> 00:13:40.840 Anda melewatkan hasil 00:13:40.840 --> 00:13:41.960 yang sebenarnya Anda inginkan. 00:13:42.440 --> 00:13:43.640 Anda menginginkan pekerjaan yang stabil 00:13:43.640 --> 00:13:44.560 dengan lebih sedikit gangguan. 00:13:44.820 --> 00:13:46.380 Volume tiket adalah sinyal yang lemah 00:13:46.380 --> 00:13:47.360 jika berdiri sendiri. 00:13:47.860 --> 00:13:48.780 Pernuruan tiket bisa berarti 00:13:48.780 --> 00:13:49.480 permintaan turun, 00:13:49.660 --> 00:13:50.560 tetapi bisa juga berarti 00:13:50.560 --> 00:13:51.660 lingkungan menjadi lebih sehat 00:13:51.660 --> 00:13:52.980 dan lapisan dukungan menjadi lebih cepat. 00:13:52.980 --> 00:13:54.460 Itu adalah dua cerita yang sangat berbeda. 00:13:55.120 --> 00:13:56.560 Eksekutif memerlukan perangkat KPI 00:13:56.560 --> 00:13:57.840 yang dapat membedakan keduanya. 00:13:58.720 --> 00:13:59.720 Anda harus mulai dengan melihat 00:13:59.720 --> 00:14:00.640 tingkat resolusi otonom. 00:14:01.380 --> 00:14:01.980 Ini bukan tentang 00:14:01.980 --> 00:14:02.840 berapa banyak percakapan 00:14:02.840 --> 00:14:03.520 yang dilakukan buat, 00:14:03.860 --> 00:14:04.560 melainkan berapa banyak 00:14:04.560 --> 00:14:05.780 kejadian dukungan yang diselesaikan 00:14:05.780 --> 00:14:06.600 dari awal hingga akhir 00:14:06.600 --> 00:14:07.380 tanpa sentuhan manusia. 00:14:07.860 --> 00:14:08.980 Anda juga perlu melacak pengurangan 00:14:08.980 --> 00:14:10.100 dalam rata-rata waktu penyelesaian. 00:14:10.680 --> 00:14:11.740 Dalam lingkungan berbasis AI, 00:14:11.880 --> 00:14:12.900 alur kerja yang berat pada diagnosis 00:14:12.900 --> 00:14:13.880 seringkali melihat peningkatan 00:14:13.880 --> 00:14:15.280 dikisaran 40 hingga 60 persen. 00:14:15.660 --> 00:14:16.720 Kemudian Anda bisa melihat biaya 00:14:16.720 --> 00:14:18.020 per resolusi dan produktivitas 00:14:18.020 --> 00:14:19.220 pengguna yang telah Anda dapatkan kembali. 00:14:19.920 --> 00:14:21.560 Metrik terakhir itu mudah untuk dilewatkan 00:14:21.560 --> 00:14:22.560 karena tidak tercantum rapi 00:14:22.560 --> 00:14:23.920 dalam laporan layanan standar. 00:14:24.640 --> 00:14:25.520 Namun di situ lain yang sebenarnya 00:14:25.520 --> 00:14:26.140 seringkali berada. 00:14:26.840 --> 00:14:27.780 Seseorang yang terhambat 00:14:27.780 --> 00:14:28.720 selama 15 menit 00:14:28.720 --> 00:14:30.000 bahkan sebelum mereka membuka tiket 00:14:30.000 --> 00:14:31.560 telah menciptakan biaya bagi perusahaan. 00:14:32.040 --> 00:14:32.920 Ketika Anda mengalikannya 00:14:32.920 --> 00:14:33.720 dengan gangguan rapat 00:14:33.720 --> 00:14:34.860 dan hambatan akses di seluruh 00:14:34.860 --> 00:14:35.540 penyewa besar, 00:14:35.660 --> 00:14:36.900 kerugian tersembunyi jauh lebih besar 00:14:36.900 --> 00:14:38.100 daripada yang ditunjukkan antrean. 00:14:38.860 --> 00:14:39.940 Inilah mengapa model biaya 00:14:39.940 --> 00:14:40.660 ketidak bertindakan 00:14:40.660 --> 00:14:41.720 sangat penting untuk kasus bisnis. 00:14:42.200 --> 00:14:43.460 Anda menghitung jam yang dihabiskan 00:14:43.460 --> 00:14:44.120 untuk upaya manual 00:14:44.120 --> 00:14:45.480 sebelum dukungan formal dimulai. 00:14:46.140 --> 00:14:47.420 Lalu Anda tambahkan biaya kesalahan 00:14:47.420 --> 00:14:48.200 dan pekerjaan yang berulang. 00:14:48.480 --> 00:14:49.820 Tiba-tiba argumen untuk pencegahan 00:14:49.820 --> 00:14:51.280 tidak lagi terdengar seperti teori. 00:14:51.820 --> 00:14:52.540 Anda tidak hanya mendani 00:14:52.540 --> 00:14:53.660 lapisan dukungan futuristik. 00:14:54.280 --> 00:14:55.260 Anda sedang menghapus beban 00:14:55.260 --> 00:14:56.440 yang telah ada dalam pekerjaan 00:14:56.440 --> 00:14:57.560 harian Anda selama bertontak. 00:14:57.880 --> 00:14:59.120 Ekonomi dari kasus yang spesifik 00:14:59.120 --> 00:15:00.100 membuat hal ini semakin jelas. 00:15:00.420 --> 00:15:01.620 Penelitian mengenai dukungan TI 00:15:01.620 --> 00:15:02.700 berbasis agen menempatkan 00:15:02.700 --> 00:15:03.440 penanganan manusia 00:15:03.440 --> 00:15:05.080 di angka sekitar 8.75 masalah. 00:15:05.580 --> 00:15:06.100 Sebaliknya, 00:15:06.260 --> 00:15:07.400 penanganan agen yang spesifik 00:15:07.400 --> 00:15:09.180 bisa turun di bawah 50 sen per masalah 00:15:09.180 --> 00:15:10.460 setelah sistem dikembangkan. 00:15:10.920 --> 00:15:11.540 Ini tidak berarti 00:15:11.540 --> 00:15:12.460 setiap tindakan dukungan 00:15:12.460 --> 00:15:13.100 akan semurah itu 00:15:13.100 --> 00:15:14.200 dan para pemimpin harus 00:15:14.200 --> 00:15:15.400 berhati-hati dengan rata-rata yang. 00:15:15.920 --> 00:15:17.280 Kualitas telemetri dan tata kelola 00:15:17.280 --> 00:15:18.960 akan selalu memengaruhi biaya akhir 00:15:18.960 --> 00:15:20.000 namun arah trennya 00:15:20.000 --> 00:15:21.080 tidak dapat disangkal. 00:15:21.660 --> 00:15:22.180 Ini adalah momen 00:15:22.180 --> 00:15:23.140 di mana TI beranjak 00:15:23.140 --> 00:15:24.480 dari narasi pusat biaya yang lama. 00:15:25.040 --> 00:15:26.120 Bukan karena dukungan menghilang 00:15:26.120 --> 00:15:27.300 tetapi karena dukungan berubah 00:15:27.300 --> 00:15:28.600 menjadi lapisan reliabilitas 00:15:28.600 --> 00:15:30.020 yang melindungi produktivitas karyawan 00:15:30.020 --> 00:15:30.840 di latar belakang. 00:15:31.700 --> 00:15:32.420 Bisnis merasakan ini 00:15:32.420 --> 00:15:33.700 sebagai pekerjaan yang lebih lancar 00:15:33.700 --> 00:15:34.760 bukan sebagai peristiwa dukungan 00:15:34.760 --> 00:15:35.280 yang dramatis. 00:15:35.280 --> 00:15:36.240 Anda mendapatkan 00:15:36.240 --> 00:15:37.060 lebih sedikit gangguan 00:15:37.060 --> 00:15:37.820 pemulihan lebih cepat 00:15:37.820 --> 00:15:38.760 dan lebih sedikit tenaga kerja 00:15:38.760 --> 00:15:39.620 yang terbuang untuk perutean 00:15:39.620 --> 00:15:40.100 dan gratifikan. 00:15:40.440 --> 00:15:41.480 Namun pengukuran yang buruk 00:15:41.480 --> 00:15:42.020 bisa dengan mudah 00:15:42.020 --> 00:15:42.740 memasukkan kemajuan. 00:15:43.600 --> 00:15:44.700 Jika telemetri Anda lemah 00:15:44.700 --> 00:15:45.860 agen mungkin hanya 00:15:45.860 --> 00:15:46.520 meringkas kegagalan 00:15:46.520 --> 00:15:47.280 lebih cepat alih-alih 00:15:47.280 --> 00:15:48.100 benar-benar mencegahnya. 00:15:48.340 --> 00:15:48.980 Jika pengerjaan ulang 00:15:48.980 --> 00:15:49.920 tetap tidak masuk dalam dashboard 00:15:49.920 --> 00:15:50.460 atau akan dashboard 00:15:50.460 --> 00:15:51.460 akan terlihat jauh lebih bersih 00:15:51.460 --> 00:15:51.860 daripada kenyata. 00:15:52.040 --> 00:15:53.240 Jika waktu yang diperoleh kembali 00:15:53.240 --> 00:15:54.080 justru bocor kembali 00:15:54.080 --> 00:15:55.300 ke aktivitas bernilai rendah 00:15:55.300 --> 00:15:56.040 para pemimpin akan 00:15:56.040 --> 00:15:56.980 melebih-lebihkan keuntungannya. 00:15:56.980 --> 00:15:57.900 Kasus keuangan 00:15:57.900 --> 00:15:58.820 harus tetap berlandaskan 00:15:58.820 --> 00:15:59.780 bukti kuat seperti insidan 00:15:59.780 --> 00:16:00.200 yang dicegah 00:16:00.200 --> 00:16:01.280 dan berkurangnya sentuhan manual. 00:16:01.980 --> 00:16:02.700 Anda harus mengukur 00:16:02.700 --> 00:16:03.340 waktu yang benar-benar 00:16:03.340 --> 00:16:03.800 dikembalikan 00:16:03.800 --> 00:16:04.620 untuk pekerjaan bermanfaat. 00:16:05.100 --> 00:16:06.000 Setelah Anda mengukurnya 00:16:06.000 --> 00:16:06.520 dengan tepat 00:16:06.520 --> 00:16:07.440 fungsi dukungan tidak lagi 00:16:07.440 --> 00:16:08.260 terlihat sebagai beban 00:16:08.260 --> 00:16:09.020 yang perlu dipangkas. 00:16:09.340 --> 00:16:10.180 Fungsi tersebut mulai terlihat 00:16:10.180 --> 00:16:11.220 sebagai kapasitas operasional 00:16:11.220 --> 00:16:11.960 yang akhirnya didapatkan 00:16:11.960 --> 00:16:12.420 kembali bisnis. 00:16:13.000 --> 00:16:14.300 Apa dampaknya bagi tim mendukung? 00:16:14.940 --> 00:16:15.920 Pikirkan apa dampaknya 00:16:15.920 --> 00:16:16.920 bagi tim di lapangan 00:16:16.920 --> 00:16:17.740 karena pergeseran ini 00:16:17.740 --> 00:16:18.480 sebenarnya bukan tentang 00:16:18.480 --> 00:16:19.480 memangkas jumlah karyawan 00:16:19.480 --> 00:16:20.440 lainkan tentang mengubah 00:16:20.440 --> 00:16:20.980 apa yang sebenarnya 00:16:20.980 --> 00:16:21.580 dilakukan orang Anda 00:16:21.580 --> 00:16:22.060 sepanjang hari. 00:16:22.560 --> 00:16:23.400 Dalam pengaturan lama 00:16:23.400 --> 00:16:24.920 sebagian besar kapasitas dukungan Anda 00:16:24.920 --> 00:16:25.560 habis dimakan oleh 00:16:25.560 --> 00:16:26.440 pengaturan ulang kata saat 00:16:26.440 --> 00:16:27.060 di perutian tiket 00:16:27.060 --> 00:16:27.860 dan siklus klarifikasi 00:16:27.860 --> 00:16:28.340 yang tiada akhir. 00:16:28.620 --> 00:16:29.380 Anda memiliki staff 00:16:29.380 --> 00:16:30.380 yang mengejar pembaruan 00:16:30.380 --> 00:16:31.660 dan memindahkan data antar sistem 00:16:31.660 --> 00:16:32.460 yang tidak pernah dirancang 00:16:32.460 --> 00:16:33.260 untuk saling terhubung. 00:16:33.340 --> 00:16:34.260 Tidak ada pekerjaan tersebut 00:16:34.260 --> 00:16:35.020 yang membuat lingkungan 00:16:35.020 --> 00:16:35.480 lebih stabil. 00:16:35.720 --> 00:16:36.300 Itu hanya menjaga 00:16:36.300 --> 00:16:37.240 agar antrean tidak meluap. 00:16:37.560 --> 00:16:38.420 Ketika agen mengambil 00:16:38.420 --> 00:16:39.240 alih pekerjaan rutin 00:16:39.240 --> 00:16:40.260 yang dapat diprediksi tersebut 00:16:40.260 --> 00:16:41.180 upaya manusia akhirnya 00:16:41.180 --> 00:16:42.040 naik ke level berikutnya. 00:16:42.040 --> 00:16:43.260 Insinyur pendukung 00:16:43.260 --> 00:16:43.840 mulai menghabiskan 00:16:43.840 --> 00:16:44.260 waktu mereka 00:16:44.260 --> 00:16:44.980 untuk mendefinisikan 00:16:44.980 --> 00:16:46.080 seperti apa kondisi yang sehat 00:16:46.080 --> 00:16:46.900 dan menyempurkan logika 00:16:46.900 --> 00:16:47.480 di persetujuan. 00:16:48.100 --> 00:16:48.740 Mereka fokus pada 00:16:48.740 --> 00:16:49.840 peningkatan sumber pengetahuan, 00:16:49.980 --> 00:16:51.060 menguji perilaku kebijakan, 00:16:51.260 --> 00:16:52.060 dan memastikan agen 00:16:52.060 --> 00:16:52.740 tetap berada dalam 00:16:52.740 --> 00:16:53.660 batasan yang telah diberikan. 00:16:54.080 --> 00:16:54.800 Itu adalah pekerjaan 00:16:54.800 --> 00:16:55.640 yang sama sekali berbeda 00:16:55.640 --> 00:16:56.420 dari sekadar menatap 00:16:56.420 --> 00:16:57.320 alih subjek sepanjang hari 00:16:57.320 --> 00:16:58.020 dan mencoba menempat 00:16:58.020 --> 00:16:58.560 apa yang sebenarnya 00:16:58.560 --> 00:16:59.160 menginginkan pengguna. 00:16:59.720 --> 00:17:00.520 Disinilah tepatnya 00:17:00.520 --> 00:17:01.700 sebagian besar penyebaran terhenti. 00:17:02.380 --> 00:17:03.100 Organisasi mencoba 00:17:03.100 --> 00:17:04.100 mempertahankan proses lama 00:17:04.100 --> 00:17:04.740 mereka yang rusak 00:17:04.740 --> 00:17:05.760 dan hanya menempatkan agen 00:17:05.760 --> 00:17:06.200 di atasnya 00:17:06.200 --> 00:17:06.880 sambil mengharapkan 00:17:06.880 --> 00:17:07.540 hasil yang lebih baik. 00:17:08.040 --> 00:17:08.720 Namun prosesnya 00:17:08.720 --> 00:17:09.400 tetap reaktif, 00:17:09.580 --> 00:17:10.040 serah terimanya 00:17:10.040 --> 00:17:10.720 masih berantakan, 00:17:10.960 --> 00:17:11.700 dan pengetahuan dasarnya 00:17:11.700 --> 00:17:12.220 masih lemah. 00:17:12.900 --> 00:17:13.420 Agen tersebut 00:17:13.420 --> 00:17:14.380 hanya menjadi lapisan cat 00:17:14.380 --> 00:17:15.460 baru pada dinding yang rapuh. 00:17:15.860 --> 00:17:16.720 Mungkin ia bisa menjawab 00:17:16.720 --> 00:17:17.460 pertanyaan lebih cepat 00:17:17.460 --> 00:17:18.480 tetapi tidak bisa memperbaiki 00:17:18.480 --> 00:17:19.060 model dukungan 00:17:19.060 --> 00:17:19.880 yang dibangun di atas keterlut. 00:17:20.040 --> 00:17:20.560 Cara yang lebih baik 00:17:20.560 --> 00:17:21.240 adalah dengan merancang 00:17:21.240 --> 00:17:21.780 ulam pekerjaan itu. 00:17:22.100 --> 00:17:22.880 Anda harus memutuskan 00:17:22.880 --> 00:17:23.720 tugas mana yang tetap 00:17:23.720 --> 00:17:24.460 dilakukan manusia 00:17:24.460 --> 00:17:25.060 karena memerlukan 00:17:25.060 --> 00:17:26.480 penilaian atau komunikasi sensitif. 00:17:26.920 --> 00:17:27.760 Kemudian Anda memutuskan 00:17:27.760 --> 00:17:28.480 pekerjaan mana yang 00:17:28.480 --> 00:17:29.460 beralih ke alur otonom 00:17:29.460 --> 00:17:30.180 karena hasilnya dapat 00:17:30.180 --> 00:17:31.420 diprediksi dan tindakannya aman. 00:17:31.800 --> 00:17:32.840 Pembagian ini sangat penting 00:17:32.840 --> 00:17:33.520 karena tim pendukung 00:17:33.520 --> 00:17:34.120 tidak akan hilang. 00:17:34.640 --> 00:17:35.300 Mereka hanya baru menjadi 00:17:35.300 --> 00:17:36.160 orang yang merancang kontrol 00:17:36.160 --> 00:17:37.220 dan menangani pengecualian. 00:17:37.620 --> 00:17:38.420 Itu berarti cara kita 00:17:38.420 --> 00:17:39.680 melatih orang juga harus berubah. 00:17:40.280 --> 00:17:41.080 Tim perlu belajar 00:17:41.080 --> 00:17:42.140 cara mengawasi sistem 00:17:42.140 --> 00:17:42.600 alih-alih 00:17:42.600 --> 00:17:44.000 hanya menjalankan tugas manual. 00:17:44.640 --> 00:17:45.320 Mereka perlu memahami 00:17:45.320 --> 00:17:46.140 logika pemulihan, 00:17:46.480 --> 00:17:47.040 tinjauan audit, 00:17:47.260 --> 00:17:48.080 dan cara menguji agen 00:17:48.080 --> 00:17:49.040 sebelum diluncurkan. 00:17:49.600 --> 00:17:50.400 Mereka juga harus bisa 00:17:50.400 --> 00:17:51.100 mengetahui kapan 00:17:51.100 --> 00:17:51.960 suatu model gagal 00:17:51.960 --> 00:17:52.920 karena alur kerja buruk 00:17:52.920 --> 00:17:53.460 yang otomatis 00:17:53.460 --> 00:17:54.620 tetaplah alur kerja yang buruk. 00:17:54.900 --> 00:17:55.480 Itu hanya akan merusak 00:17:55.480 --> 00:17:56.100 segaranya lebih cepat. 00:17:56.520 --> 00:17:57.180 Jika Anda melakukan 00:17:57.180 --> 00:17:58.300 perekrutan untuk masa depan ini, 00:17:58.400 --> 00:17:58.860 Anda mungkin tidak 00:17:58.860 --> 00:17:59.760 membutuhkan general selain 00:17:59.760 --> 00:18:00.180 untuk mulai. 00:18:00.440 --> 00:18:01.400 Anda membutuhkan seseorang 00:18:01.400 --> 00:18:02.220 yang dapat mengatur alur 00:18:02.220 --> 00:18:02.900 di seluruh tumpukan 00:18:02.900 --> 00:18:03.740 Microsoft 365 00:18:03.740 --> 00:18:04.740 dan menentukan kontrol 00:18:04.740 --> 00:18:05.320 yang menjaga agar 00:18:05.320 --> 00:18:06.160 agen tetap terkendali. 00:18:06.500 --> 00:18:07.340 Anda menginginkan orang 00:18:07.340 --> 00:18:08.740 yang dapat meningkatkan lingkungan 00:18:08.740 --> 00:18:09.820 agar permintaan dukungan 00:18:09.820 --> 00:18:10.800 benar-benar turun 00:18:10.800 --> 00:18:11.600 alih-alih terus menumpul. 00:18:11.980 --> 00:18:12.760 Jadi bagaimana Anda 00:18:12.760 --> 00:18:13.900 memulainya tanpa mengubahnya 00:18:13.900 --> 00:18:15.220 menjadi proyek transformasi besar 00:18:15.220 --> 00:18:16.140 yang memakan waktu bertentang? 00:18:16.140 --> 00:18:17.280 Langkah terbaik adalah 00:18:17.280 --> 00:18:18.380 memilih satu alur tunggal 00:18:18.380 --> 00:18:19.360 yang menyebabkan kesekan 00:18:19.360 --> 00:18:19.820 terus-menerus 00:18:19.820 --> 00:18:20.300 di lingkungan 00:18:20.300 --> 00:18:21.460 Microsoft 365 Anda. 00:18:21.740 --> 00:18:22.380 Perbaikan akses 00:18:22.380 --> 00:18:23.100 biasanya merupakan 00:18:23.100 --> 00:18:24.000 kandidat yang tepat, 00:18:24.080 --> 00:18:24.940 tetapi Anda juga bisa 00:18:24.940 --> 00:18:25.880 melihat dukungan rapat 00:18:25.880 --> 00:18:26.500 atau serah terima 00:18:26.500 --> 00:18:27.000 ke petuhan perang. 00:18:27.140 --> 00:18:27.880 Tidak masalah mana 00:18:27.880 --> 00:18:28.820 yang Anda pilih 00:18:28.820 --> 00:18:30.040 selama polanya sering terjadi 00:18:30.040 --> 00:18:31.400 dan Anda tahu persis 00:18:31.400 --> 00:18:32.060 seperti apa hasil 00:18:32.060 --> 00:18:32.980 yang sukses itu seharusnya. 00:18:33.380 --> 00:18:34.400 Setelah Anda memiliki target, 00:18:34.720 --> 00:18:35.340 Anda harus menentukan 00:18:35.340 --> 00:18:35.940 dasar-dasarnya 00:18:35.940 --> 00:18:36.840 dengan disiplin yang nyata. 00:18:37.200 --> 00:18:37.920 Anda perlu mengetahui 00:18:37.920 --> 00:18:39.080 seperti apa kondisi yang sehat 00:18:39.080 --> 00:18:39.940 dan peristiwa spesifik 00:18:39.940 --> 00:18:40.740 mana yang memberitahu Anda 00:18:40.740 --> 00:18:41.840 bahwa segala sesuatunya melembang. 00:18:42.240 --> 00:18:43.140 Putuskan tindakan mana 00:18:43.140 --> 00:18:44.480 yang aman untuk diotomatisasi 00:18:44.480 --> 00:18:45.180 dan di mana tepatnya 00:18:45.180 --> 00:18:46.420 eskalasi manusia perlu dimulai. 00:18:46.980 --> 00:18:48.240 Sebelum Anda meluncurkan apapun, 00:18:48.400 --> 00:18:49.100 pastikan Anda memiliki 00:18:49.100 --> 00:18:50.500 garis dasar untuk jumlah tiket, 00:18:50.580 --> 00:18:51.100 sentuhan manual, 00:18:51.240 --> 00:18:52.000 dan berapa lama pengguna 00:18:52.000 --> 00:18:52.940 menunggu perbaikan saat ini. 00:18:53.360 --> 00:18:54.200 Anda juga harus menerapkan 00:18:54.200 --> 00:18:54.800 tata keloa Anda 00:18:54.800 --> 00:18:55.380 sejak hari pertama. 00:18:55.820 --> 00:18:57.060 Berikan agen identitas khusus, 00:18:57.160 --> 00:18:58.180 tetapkan pemilik manusia, 00:18:58.320 --> 00:18:59.080 dan atur-aturan 00:18:59.080 --> 00:19:00.160 persetujuan yang jelas. 00:19:00.880 --> 00:19:01.960 Setiap tindakan yang diambil 00:19:01.960 --> 00:19:02.800 agen harus dicatat. 00:19:03.460 --> 00:19:04.540 Anda juga harus punya rencana 00:19:04.540 --> 00:19:05.340 saat agen tersebut 00:19:05.340 --> 00:19:05.980 dipensiunkan 00:19:10.740 --> 00:19:12.040 berjalan seluruh model operasi 00:19:12.040 --> 00:19:12.720 Anda mulai berubah. 00:19:13.060 --> 00:19:14.020 Dukungan berhenti bertindak 00:19:14.020 --> 00:19:14.760 seperti meja depan 00:19:14.760 --> 00:19:15.800 yang hanya bereaksi terhadap asal. 00:19:16.620 --> 00:19:17.120 Sebaliknya, 00:19:17.360 --> 00:19:18.200 ia mulai berperilaku 00:19:18.200 --> 00:19:19.180 seperti mesin keandalan 00:19:19.180 --> 00:19:20.060 yang dibangun langsung 00:19:20.060 --> 00:19:20.620 ke dalam sistem. 00:19:21.540 --> 00:19:22.720 Dukungan bergeser dari reaksi 00:19:22.720 --> 00:19:23.100 yang terlihat 00:19:23.100 --> 00:19:24.160 menjadi pencegahan yang tersemak. 00:19:24.740 --> 00:19:25.660 Tiga itu bukanlah layanannya. 00:19:26.080 --> 00:19:26.560 Itu adalah bukti 00:19:26.560 --> 00:19:27.660 bahwa layanan datang terlalu terang. 00:19:32.450 --> 00:19:33.330 Jika ingin lebih banyak 00:19:33.330 --> 00:19:35.070 tentang M365 Copilot, 00:19:35.250 --> 00:19:35.910 ajur keamanan, 00:19:35.990 --> 00:19:36.870 dan model operasi AI 00:19:36.870 --> 00:19:38.690 berlangganlah ke M365 FM 00:19:38.690 --> 00:19:39.610 dan beri ulasan. 00:19:40.210 --> 00:19:41.030 Terhubunglah dengan saya, 00:19:41.210 --> 00:19:41.710 Mirko Peter, 00:19:41.710 --> 00:19:43.030 di link ini untuk topik berikutnya 00:19:43.030 --> 00:19:43.650 yang ingin Anda bahas.