WEBVTT

00:00:00.000 --> 00:00:09.480
企業はAIライセンスを購入しトレーニングを展開し完了率を祝いますがその後同じチームがデータを手作業でコピーしメールでステータス更新を追いかけ毎月レポートを再構築するのを見ます

00:00:09.480 --> 00:00:16.340
これが無駄のパターンですツールは存在し支出は現実のものですが古いモデルは変化ではなく露出を追跡するため作業はほとんど進みません

00:00:16.340 --> 00:00:23.780
バッジは財務アナリストがより早く締め切ったかどうかを示しません出席はプロジェクトマネージャーがブロックされた決定を半分の時間で押し通したかどうかを示しません

00:00:23.780 --> 00:00:29.340
そして取り戻した時間エラーの減少またはアクションの迅速化を示すことができない場合AIはコスト項目のままです

00:00:29.340 --> 00:00:32.300
そこでこのビデオでは測定モデルをシンプルにしたいと思います

00:00:32.300 --> 00:00:38.820
節約された時間得られたスピード削減されたエラーは理論上ではなく実際のタスクの中でロイが現れ始めるのはそこです

00:00:38.820 --> 00:00:46.640
古いモデルは破綻します認定指標がロイを示さない理由ほとんどのAIトレーニングプログラムはまだコンプライアンスモデルに従っています

00:00:46.640 --> 00:00:52.200
人々はセッションに参加しモジュールを完了しおそらくクイズに合格しその後経営陣は綺麗な数字でいっぱいのダッシュボードを受け取ります

00:00:52.200 --> 00:00:57.900
完了率参加自己申告の自信見た目は整っているように見えるがまさにそれが問題なのだ

00:00:57.900 --> 00:01:04.360
整った指標は特にトレーニング終了後も作業自体が全く変わっていない場合複雑な現実を覆い隠してしまう可能性がある

00:01:04.360 --> 00:01:13.200
よくあることは単純だチームはプロンプトとは何かを学びいくつかの一般的なデモを見てその後アウトルックエクセルチームズそして従来通りの方法で実行されるレポート作成ワークフローに戻る

00:01:13.200 --> 00:01:21.180
AIについて以前より詳しくなったとしても月次レポートの作成には依然として時間がかかりすぎる引き継ぎは依然として失敗しフォローアップは誰かが送信することを覚えていなければならない

00:01:21.180 --> 00:01:30.120
つまりギャップは知識だけではなくタスクの行動にあるのださらに深く掘り下げるとほとんどの企業がここで本質を見失う作業の圧縮ではなく使用状況のノイズを測定しているのだ

00:01:30.120 --> 00:01:35.980
あなたの情報源セットの調査によると一般的なユーザーとパワーユーザーの間には生産性において4から5倍もの大きな差がある

00:01:35.980 --> 00:01:44.760
つまり平均的な導入数はほとんど何も教えてくれないということだ企業は人々はAIを使っているというかもしれないがその使用を迅速な成果につなげているのはごく一部の人だけだという事実を見落としている可能性がある

00:01:44.760 --> 00:01:50.920
そのため完了率は安心感を与えるものの価値を証明するものではありません完了率は誰かがトレーニングを完了したことを示すだけです

00:01:50.920 --> 00:01:57.640
調査で財務ベンチマークの一つであるレポートパックの処理時間がプロセスの一部で20分から45秒に短縮されたかどうかは示しません

00:01:57.640 --> 00:02:04.520
従業員が平均して月に約9時間を取り戻しているかどうかも示しませんこれは複数のコパイロット調査で明らかになっています

00:02:04.520 --> 00:02:10.960
そして意思決定が8倍早くなったかどうかまたは測定された実装で洞察を得るまでの時間が88%短縮されたかどうかは絶対に示しません

00:02:10.960 --> 00:02:15.780
これらは結果シグナルですその他はすべて設定されていますモデルにはもう一つの欠陥があります

00:02:15.780 --> 00:02:25.140
多くのパイロットは真のベースラインを確立しないため後で変化を証明できません資料の調査によるとエンタープライズAIパイロットの95%は測定可能な損益への影響をもたらしませんでした

00:02:25.140 --> 00:02:29.540
ツール自体が失敗したからではなく組織が難しい部分をスキップしたためです

00:02:29.540 --> 00:02:37.880
ワークフローの再設計所有権事前の工事後測定スキルアップ前にタスクにどれくらいの時間がかかったかがわからない場合展開後に主張を正当化することはできません

00:02:37.880 --> 00:02:43.940
リーダーが導入についてどのように話しているかを見て私はこれに気づきました彼らはよく今月コパイロットを使用した人数はと尋ねます

00:02:43.940 --> 00:02:50.340
これは最もらしく聞こえますが間違った質問ですより良い質問はどのタスクがより短くより正確になりより迅速に決定できるようになったかです

00:02:50.340 --> 00:02:53.860
なぜならAIをより頻繁に使用することは作業を圧縮することと同じではないからです

00:02:53.860 --> 00:02:58.780
人は1日10プロンプトを使用しても再作業遅延他の人が修正しなければならない不十分な出力を生み出す可能性があります

00:02:58.780 --> 00:03:02.680
したがってトレーニングは一般的なリテラシーの枠から抜け出し役割ベースの能力に移行する必要があります

00:03:02.680 --> 00:03:06.320
AIを学ぶのではなく際の説明をより迅速に構築する方法を学びます

00:03:06.320 --> 00:03:09.260
会議の雑音をアクション可能なフォローアップに変換する方法を学びます

00:03:09.260 --> 00:03:12.480
品質を損なうことなくチケット処理時間を短縮する方法を学びます

00:03:12.480 --> 00:03:16.700
バッジロジックを捨ててワークフローロジックに移行すればロイが遥かに見やすくなります

00:03:16.700 --> 00:03:19.640
測定モデル再利用された時間のフレームワーク

00:03:19.640 --> 00:03:23.940
つまりトレーニングを出席として測定するのをやめたら行動をお金に結びつけるモデルが必要になります

00:03:23.940 --> 00:03:25.400
シンプルに考えましょう

00:03:25.400 --> 00:03:28.740
ロイは節約した時間に時間あたりのコストと導入率をかけ

00:03:28.740 --> 00:03:33.580
エラーの減少と意思決定の迅速化による価値を加えスキルアップへの投資を差し引いたものです

00:03:33.580 --> 00:03:35.120
これが全体の構造です

00:03:35.120 --> 00:03:37.000
完璧ではありませんが実用的です

00:03:37.000 --> 00:03:38.520
そしてそれがより重要なのです

00:03:38.520 --> 00:03:43.240
なぜならほとんどのAI ROIの議論は計算が抽象的になりすぎてマネージャーが信頼できなくなると破綻してしまうからです

00:03:43.240 --> 00:03:46.600
さらに簡単に言うとAIを購入しているのではなく労働時間を買い戻しているのです

00:03:46.600 --> 00:03:49.740
そしてその時間をより重要な業務に振り向けようとしているのです

00:03:49.740 --> 00:03:53.920
分析計画エスカレーション顧客対応より良い判断などです

00:03:53.920 --> 00:03:57.180
時間が余剰時間として消えてしまうと価値は弱まります

00:03:57.180 --> 00:04:01.480
時間がより早い成果やより良い意思決定としてビジネスに戻ってくると価値が現れます

00:04:01.480 --> 00:04:04.660
最も明確なシグナルである時間の回収から始めましょう

00:04:04.660 --> 00:04:07.300
フルタイム従業員1人あたりの月間節約時間を測定しますが

00:04:07.300 --> 00:04:10.480
AIが少し役立ったというものではなく特定のワークフロー内でのみ測定してください

00:04:10.480 --> 00:04:11.760
それは役に立ちません

00:04:11.760 --> 00:04:16.080
一つのタスクを追跡しExcelでデータをクリーンアップし月次祭ノートを作成し

00:04:16.080 --> 00:04:18.000
会議の要約とアクションリストを作成し

00:04:18.000 --> 00:04:20.980
同じ条件下での手動での時間とAI支援による時間を比較します

00:04:20.980 --> 00:04:23.660
同じ役割同じタスク同じ複雑さのレベル

00:04:23.660 --> 00:04:25.700
これが架空の計算を避ける方法です

00:04:25.700 --> 00:04:29.080
ほとんどの人が見落としているのは平均値はすぐに状況を歪める可能性があるということです

00:04:29.080 --> 00:04:32.360
ある人は15分節約できるかもしれませんが別の人は2時間節約できるかもしれません

00:04:32.360 --> 00:04:35.420
したがって会社全体に渡る広範な過程から始めないでください

00:04:35.420 --> 00:04:38.060
ワークフローレベルから始めて上に展開します

00:04:38.060 --> 00:04:41.780
財務アナリストが毎月何度も繰り返されるタスクでわずかな時間を節約したとしても

00:04:41.780 --> 00:04:43.660
節約できた時間はふくりで増えていきます

00:04:43.660 --> 00:04:47.300
ソースセットの調査によると従業員の時間あたりの価値が十分に高ければ

00:04:47.300 --> 00:04:49.800
控えめな月次節約でもすぐにライセンスを正当化できます

00:04:49.800 --> 00:04:51.900
次に意思決定の速度を追加します

00:04:51.900 --> 00:04:53.020
これは重要です

00:04:53.020 --> 00:04:56.180
なぜならAIの価値の多くは単純な労働力削減として現れないからです

00:04:56.180 --> 00:04:58.700
問題とアクションの間の待ち時間の短縮として現れます

00:04:58.700 --> 00:05:02.120
問題が特定されてから次の決定が下されるまでのサイクル時間を測定します

00:05:02.120 --> 00:05:04.880
一部のチームではこれは会議からフォローアップまでを意味します

00:05:04.880 --> 00:05:07.880
他のケースではサイのフラグ付けから経営陣の対応まで

00:05:07.880 --> 00:05:09.820
曖昧な話で簡単に偽装できるため

00:05:09.820 --> 00:05:12.440
トレーニング前とトレーニング後のタイミングを使用します

00:05:12.440 --> 00:05:14.420
同じチーム同じ種類の意思決定

00:05:14.420 --> 00:05:15.600
同じ承認パス

00:05:15.600 --> 00:05:17.320
研究でその裏付けがあります

00:05:17.320 --> 00:05:20.680
一部の組織はAI導入後に意思決定が8倍早くなり

00:05:20.680 --> 00:05:23.680
洞察を得るまでの時間が88%短縮されたと報告しています

00:05:23.680 --> 00:05:26.080
これらの数値はワークフローと設定に依存するため

00:05:26.080 --> 00:05:28.620
普遍的な約束として振りかざすべきではありませんが

00:05:28.620 --> 00:05:32.240
AIが情報収集と行動の間の摩擦を減らすとどうなるかを示しています

00:05:32.240 --> 00:05:34.700
そしてこれが経営幹部が気にする部分です

00:05:34.700 --> 00:05:36.380
なぜなら遅い意思決定は通常

00:05:36.380 --> 00:05:38.320
遅い文書作成よりもコストがかかるからです

00:05:38.320 --> 00:05:41.080
その後役割に基づいてもう一つの指標を選択します

00:05:41.080 --> 00:05:44.320
エラー削減は財務やコンプライアンスが重要なフローで効果的です

00:05:44.320 --> 00:05:46.860
スループットはサービス業務で効果的です

00:05:46.860 --> 00:05:48.100
意思決定ごとのコストは

00:05:48.100 --> 00:05:51.600
同じ問題が複数の人をループに巻き込む管理プロセスで効果的です

00:05:51.600 --> 00:05:53.440
ポイントは巨大なダッシュボードを作成することではなく

00:05:53.440 --> 00:05:55.540
一つの品質または出力の指標をワークフローに合わせ

00:05:55.540 --> 00:05:57.500
スピードが質の低い作業を隠さないようにすることです

00:05:57.500 --> 00:05:59.320
次にベースラインの規律です

00:05:59.320 --> 00:06:02.440
これはほとんどの人が退屈に感じるためスキップしたがる部分であり

00:06:02.440 --> 00:06:05.140
まさにそれが多くのロイ主張が後で崩れる理由です

00:06:05.140 --> 00:06:07.060
トレーニングの前にタスクの時間を計測し

00:06:07.060 --> 00:06:09.240
手戻りをカウントし引き継ぎにかかる時間を記録します

00:06:09.240 --> 00:06:11.720
次にターゲットを絞ったスキルアップの後で同じテストを実行します

00:06:11.720 --> 00:06:13.480
タスクが変更された場合はそれを記録します

00:06:13.480 --> 00:06:15.300
ボリュームが変更された場合はそれを記録します

00:06:15.300 --> 00:06:17.200
データ品質が向上した場合はそれを記録します

00:06:17.200 --> 00:06:19.040
明確な比較はケース全体を保護します

00:06:19.040 --> 00:06:20.580
導入は依然として重要ですが

00:06:20.580 --> 00:06:22.160
トロフィーではなく常数としてです

00:06:22.160 --> 00:06:24.540
有給状態のライセンスはモデルを低下させます

00:06:24.540 --> 00:06:28.900
情報源の調査によると大企業でのアクティブシート利用率は平均55%であり

00:06:28.900 --> 00:06:32.060
これは多くの有料容量がワークフローに投入されないことを意味します

00:06:32.060 --> 00:06:34.640
したがってユーザーがログインしたかどうかだけを尋ねるのではなく

00:06:34.640 --> 00:06:37.600
トレーニングされた行動がターゲットタスクで繰り返し現れたかどうかを尋ねます

00:06:37.600 --> 00:06:39.920
それが追跡する価値のある導入シグナルです

00:06:39.920 --> 00:06:41.800
もう一つの区別が重要です

00:06:41.800 --> 00:06:44.500
総節約時間は生み出された価値とは異なります

00:06:44.500 --> 00:06:46.180
アナリストが1時間を節約した場合

00:06:46.180 --> 00:06:47.960
その1時間はより深い分析

00:06:47.960 --> 00:06:49.380
より迅速なエスカレーション

00:06:49.380 --> 00:06:49.980
より良い計画

00:06:49.980 --> 00:06:52.760
またはより多くの顧客作業に振り向けられた場合にのみ意味を持ちます

00:06:52.760 --> 00:06:55.720
つまり完全なモデルとは時間を有効活用し

00:06:55.720 --> 00:06:57.140
それを再配置することです

00:06:57.140 --> 00:06:59.420
こうしてAIはソフトウェア投資ではなく

00:06:59.420 --> 00:07:01.480
運用レバレッジのように見えるようになります

00:07:01.480 --> 00:07:03.580
しかしロイが最初に現れるのは

00:07:03.580 --> 00:07:05.700
ロイ密度が高い3つの役割です

00:07:05.700 --> 00:07:07.020
モデルが明確になったら

00:07:07.020 --> 00:07:08.840
次の問題はどこから始めるかです

00:07:08.840 --> 00:07:09.920
全員から始めるのではなく

00:07:09.920 --> 00:07:11.720
最も声の大きい部署から始めるのでもありません

00:07:11.720 --> 00:07:13.300
反復作業が多く文書が多く

00:07:13.300 --> 00:07:16.060
周囲のすべてを遅らせる小さな意思決定が詰まっている作業から始めましょう

00:07:16.060 --> 00:07:18.620
AIのスキルアップが効果を発揮するのはまさにそこです

00:07:18.620 --> 00:07:20.280
一つの行動をトレーニングすると

00:07:20.280 --> 00:07:22.100
それが毎週何十回も現れ

00:07:22.100 --> 00:07:24.540
人員を増やすことなく効果が積み重なっていきます

00:07:24.540 --> 00:07:26.540
財務アナリストは構造化データ

00:07:26.540 --> 00:07:28.100
繰り返し行われるコメント

00:07:28.100 --> 00:07:28.660
称号

00:07:28.660 --> 00:07:29.980
レポートサイクルなど

00:07:29.980 --> 00:07:32.380
手作業に負担がかかる作業が週の大半を占めるため

00:07:32.380 --> 00:07:33.880
このリストの上位に位置します

00:07:33.880 --> 00:07:35.040
彼らはExcelを使い

00:07:35.040 --> 00:07:36.380
入力データをクリーンアップし

00:07:36.380 --> 00:07:37.380
バージョンを比較し

00:07:37.380 --> 00:07:38.400
動きを説明し

00:07:38.400 --> 00:07:40.680
生の数値を経営人が行動できるものに変換します

00:07:40.680 --> 00:07:41.400
これはまさに

00:07:41.400 --> 00:07:44.580
役割ベースのAIスキルがすぐに負荷を軽減できる種類の仕事です

00:07:44.580 --> 00:07:45.040
なぜなら

00:07:45.040 --> 00:07:46.120
摩擦の原因は通常

00:07:46.120 --> 00:07:47.260
深い判断ではないからです

00:07:47.260 --> 00:07:48.260
判断を下す前の作業

00:07:48.260 --> 00:07:48.980
つまり収集

00:07:48.980 --> 00:07:49.400
構成

00:07:49.400 --> 00:07:50.040
走行作成

00:07:50.040 --> 00:07:50.440
チェック

00:07:50.440 --> 00:07:51.040
書き直しです

00:07:51.040 --> 00:07:51.640
調査によると

00:07:51.640 --> 00:07:53.740
財務チームは毎月大幅なコスト削減を報告しており

00:07:53.740 --> 00:07:54.820
一部のパイロットプロジェクトでは

00:07:54.820 --> 00:07:56.620
レポート作成作業が長い手作業のサイクルから

00:07:56.620 --> 00:07:58.740
遥かに早い初行作成へと移行していることが示されています

00:07:58.740 --> 00:07:59.560
このパターンは

00:07:59.560 --> 00:08:01.180
見出しの数字よりも重要です

00:08:01.180 --> 00:08:03.120
アナリストはアナリストであることをやめませんが

00:08:03.120 --> 00:08:05.060
出力の最初のバージョンを作成するのに

00:08:05.060 --> 00:08:06.060
費やす時間を減らします

00:08:06.060 --> 00:08:07.360
この変化がうまくいけば

00:08:07.360 --> 00:08:09.100
実際のキャパシティが回復し

00:08:09.100 --> 00:08:10.040
多くの場合

00:08:10.040 --> 00:08:13.300
対象となるタスクで30%から50%の範囲になり

00:08:13.300 --> 00:08:15.980
クローズドサイクルは最後に慌てることなく進み始めます

00:08:15.980 --> 00:08:18.400
プロジェクトマネージャーもロイの高いゾーンですが

00:08:18.400 --> 00:08:19.600
理由は異なります

00:08:19.600 --> 00:08:20.600
彼らの仕事は

00:08:20.600 --> 00:08:21.320
調整負荷

00:08:21.320 --> 00:08:22.360
ステータス収集

00:08:22.360 --> 00:08:23.020
会議メモ

00:08:23.020 --> 00:08:23.920
アクション追跡

00:08:23.920 --> 00:08:24.680
リスクログ

00:08:24.680 --> 00:08:25.400
フォローアップ

00:08:25.400 --> 00:08:27.520
ステークホルダーへのアップデートに埋もれてしまいます

00:08:27.520 --> 00:08:28.720
どれも些細なことではなく

00:08:28.720 --> 00:08:30.300
情報が意思決定につながらず

00:08:30.300 --> 00:08:30.760
チャット

00:08:30.760 --> 00:08:31.700
プレゼンテーション

00:08:31.700 --> 00:08:33.160
または未完成のメモに留まっていると

00:08:33.160 --> 00:08:34.640
全てが遅延の原因となります

00:08:34.640 --> 00:08:35.200
そのため

00:08:35.200 --> 00:08:38.880
PMがワークフロー内でAIを使用するようにトレーニングされると

00:08:38.880 --> 00:08:40.420
フローにメリットが現れます

00:08:40.420 --> 00:08:42.820
以前は6時間かかっていた終時準備サイクルは

00:08:42.820 --> 00:08:44.400
ようやくアクションの抽出

00:08:44.400 --> 00:08:46.580
ドラフトの更新がすでに使用しているツール内で

00:08:46.580 --> 00:08:48.400
行われるようになれば2時間まで短縮できます

00:08:48.400 --> 00:08:49.500
さらに重要なのは

00:08:49.500 --> 00:08:52.000
出力がアクションに適した状態で届くことです

00:08:52.000 --> 00:08:54.480
会議で何が起こったかを再現する必要はありません

00:08:54.480 --> 00:08:54.980
リスク

00:08:54.980 --> 00:08:55.700
担当者

00:08:55.700 --> 00:08:56.180
期限

00:08:56.180 --> 00:08:57.660
次の行動を確認できます

00:08:57.660 --> 00:08:58.160
そのため

00:08:58.160 --> 00:09:01.940
このような環境では意思決定サイクルが25%から40%早くなります

00:09:01.940 --> 00:09:03.820
スピードはタイピングの速さからではなく

00:09:03.820 --> 00:09:06.380
議論と実行の間の遅延を減らすことから生まれます

00:09:06.380 --> 00:09:06.860
次に

00:09:06.860 --> 00:09:10.520
ボリュームが経済的な作業の大部分を担う最前線の運用とサポートがあります

00:09:10.520 --> 00:09:11.400
これらのチームは

00:09:11.400 --> 00:09:12.320
繰り返される質問

00:09:12.320 --> 00:09:13.640
繰り返しのコミュニケーション

00:09:13.640 --> 00:09:14.300
知識の検索

00:09:14.300 --> 00:09:15.120
ケースの要約

00:09:15.120 --> 00:09:16.800
システム間の頻繁な切り替えを処理します

00:09:16.800 --> 00:09:18.860
ここでは小さな節約が重要になります

00:09:18.860 --> 00:09:19.340
なぜなら

00:09:19.340 --> 00:09:21.100
それが1日中発生するからです

00:09:21.100 --> 00:09:24.120
サポートのワークフローが12分から7分に短縮されると

00:09:24.120 --> 00:09:25.120
その差は何百

00:09:25.120 --> 00:09:26.740
何千ものやり取りに及び

00:09:26.740 --> 00:09:28.380
突然スループットが向上し

00:09:28.380 --> 00:09:30.760
通常の解決策である人員を増やすことなく

00:09:30.760 --> 00:09:32.360
チームはただスピードを上げるだけでなく

00:09:32.360 --> 00:09:33.880
目標範囲内に止まり

00:09:33.880 --> 00:09:35.080
正確さを維持し

00:09:35.080 --> 00:09:37.280
応答品質を安定させる必要があります

00:09:37.280 --> 00:09:37.820
そのため

00:09:37.820 --> 00:09:38.840
これらの役割では

00:09:38.840 --> 00:09:40.920
初期段階でより厳密なプロンプトパターンと

00:09:40.920 --> 00:09:42.280
狭いユースケースが効果的です

00:09:42.280 --> 00:09:43.580
応答案を作成し

00:09:43.580 --> 00:09:45.240
適切な知識を抽出し

00:09:45.240 --> 00:09:46.380
ケースを要約し

00:09:46.380 --> 00:09:48.120
エッジケースは人間が確認します

00:09:48.120 --> 00:09:49.480
この規律が確立されると

00:09:49.480 --> 00:09:52.400
20%から40%の範囲のスループット向上は

00:09:52.400 --> 00:09:53.220
誇張ではなく

00:09:53.220 --> 00:09:54.920
信憑性のあるものに見え始めます

00:09:54.920 --> 00:09:55.520
したがって

00:09:55.520 --> 00:09:57.000
選択ルールはシンプルです

00:09:57.000 --> 00:09:58.200
公平に感じられるからといって

00:09:58.200 --> 00:09:59.380
トレーニングを組織全体に

00:09:59.380 --> 00:10:00.420
均等に分散させてはいけません

00:10:00.420 --> 00:10:01.240
AIが反復

00:10:01.240 --> 00:10:01.960
文書化

00:10:01.960 --> 00:10:03.080
意思決定負荷を通じて

00:10:03.080 --> 00:10:04.600
出力を増幅させる場所に配置します

00:10:04.600 --> 00:10:05.340
財務部門は

00:10:05.340 --> 00:10:06.300
分析準備において

00:10:06.300 --> 00:10:07.700
測定可能な圧縮を実現します

00:10:07.700 --> 00:10:08.780
プロジェクト管理部門は

00:10:08.780 --> 00:10:10.880
調整を通じてより迅速な動きを実現します

00:10:10.880 --> 00:10:12.120
運用及びサポート部門は

00:10:12.120 --> 00:10:13.160
明確なサービス指標で

00:10:13.160 --> 00:10:14.240
ボリュームの増加を実現します

00:10:14.240 --> 00:10:15.400
役割は異なりますが

00:10:15.400 --> 00:10:16.260
パターンは同じです

00:10:16.260 --> 00:10:17.520
情報が意思決定の準備が

00:10:17.520 --> 00:10:18.800
整うのに近い状態で届くため

00:10:18.800 --> 00:10:20.200
作業の摩擦が少なくなります

00:10:20.200 --> 00:10:20.540
そして

00:10:20.540 --> 00:10:22.300
誰がツールを使用したかを問うのをやめて

00:10:22.300 --> 00:10:24.240
どのワークフローが短縮されたかを問うようになると

00:10:24.240 --> 00:10:25.020
シグナルが強くなるため

00:10:25.020 --> 00:10:25.940
例に進む際にも

00:10:25.940 --> 00:10:27.340
この視点を使い続ける必要があります

00:10:27.340 --> 00:10:28.360
ワークフローの証拠

00:10:28.360 --> 00:10:30.480
具体的な前後比較の事例が3つあります

00:10:30.480 --> 00:10:30.860
では

00:10:30.860 --> 00:10:32.300
具体的に見ていきましょう

00:10:32.300 --> 00:10:32.780
なぜなら

00:10:32.780 --> 00:10:34.680
ここでAI ROIが正当化されるか

00:10:34.680 --> 00:10:36.300
役員会のキリになるかが決まるからです

00:10:36.300 --> 00:10:37.840
まずは財務を見てみましょう

00:10:37.840 --> 00:10:40.320
ターゲットを絞ったスキルアップを行う前は

00:10:40.320 --> 00:10:42.940
月次レポートのサイクルが5日かかることがあります

00:10:42.940 --> 00:10:45.260
これは分析自体に5日かかるからではなく

00:10:45.260 --> 00:10:46.980
アナリストが数字を集めたり

00:10:46.980 --> 00:10:48.240
書式をチェックしたり

00:10:48.240 --> 00:10:49.360
解説を書いたり

00:10:49.360 --> 00:10:51.860
同じスタイルの再説明を何度も書いたりするのに

00:10:51.860 --> 00:10:53.160
時間をかけすぎているからです

00:10:53.160 --> 00:10:54.620
トレーニングされた動作によって

00:10:54.620 --> 00:10:56.020
このシーケンスが変わります

00:10:56.020 --> 00:10:57.800
アナリストは白紙から始めるのではなく

00:10:57.800 --> 00:11:00.580
AIを使用して解説の最初の走行を作成し

00:11:00.580 --> 00:11:02.200
カテゴリ間の動きを要約し

00:11:02.200 --> 00:11:03.940
レビューのために説明を構成します

00:11:03.940 --> 00:11:05.880
締め作業がなくなるわけではありません

00:11:05.880 --> 00:11:07.800
アナリストは引き続き数字を検証しますが

00:11:07.800 --> 00:11:09.660
手動でのドラッグ&ドロップがなくなり

00:11:09.660 --> 00:11:11.020
サイクルは5日から2日になります

00:11:11.020 --> 00:11:13.280
本当のメリットはその後に起こることです

00:11:13.280 --> 00:11:14.200
節約された時間は

00:11:14.200 --> 00:11:15.940
より見栄えの良いレポートに使われるのではなく

00:11:15.940 --> 00:11:16.860
シナリオプランニング

00:11:16.860 --> 00:11:17.640
例外レビュー

00:11:17.640 --> 00:11:19.400
意思決定者とのより迅速なフォローアップに使われます

00:11:19.400 --> 00:11:21.260
次にプロジェクト管理を見てみましょう

00:11:21.260 --> 00:11:22.620
根本的な問題は通常

00:11:22.620 --> 00:11:23.800
努力不足ではありません

00:11:23.800 --> 00:11:24.700
断片化です

00:11:24.700 --> 00:11:25.620
メモは1箇所にあり

00:11:25.620 --> 00:11:26.820
アクションは別の場所にあり

00:11:26.820 --> 00:11:28.940
リスクは誰も見返す時間のない会議に埋もれています

00:11:28.940 --> 00:11:31.440
PMはステータスを使用可能な形式にするだけで

00:11:31.440 --> 00:11:32.880
週に6時間も費やすことがあります

00:11:32.880 --> 00:11:34.440
役割ベースのスキルアップの後

00:11:34.440 --> 00:11:35.660
ワークフローが変わります

00:11:35.660 --> 00:11:38.020
会議のメモは一貫したパターンで要約されます

00:11:38.020 --> 00:11:40.540
アクションは担当者と期限と共に抽出されます

00:11:40.540 --> 00:11:42.700
PMが事後に手動で再構築しないため

00:11:42.700 --> 00:11:44.900
リスクとブロックが早期に明らかになります

00:11:44.900 --> 00:11:47.060
準備時間は6時間から2時間に短縮され

00:11:47.060 --> 00:11:48.720
より大きなメリットは下流にあります

00:11:48.720 --> 00:11:50.620
エスカレーションはより早く行われます

00:11:50.620 --> 00:11:53.260
利害関係者はすぐに行動できるアップデートを受け取ります

00:11:53.260 --> 00:11:55.120
フォローアップが遅れたり不完全だったり

00:11:55.120 --> 00:11:57.680
不明瞭だったりするために決定が停滞することが少なくなります

00:11:57.680 --> 00:11:59.480
変わったのはPMの肩書ではなく

00:11:59.480 --> 00:12:01.520
情報が使用可能になるスピードです

00:12:01.520 --> 00:12:05.320
次に数学が非常にすぐに非常に明確になるサポートと運用があります

00:12:05.320 --> 00:12:07.300
一般的なケースから始めましょう

00:12:07.300 --> 00:12:09.300
平均処理時間は12分です

00:12:09.300 --> 00:12:11.440
これは担当者が正しい回答を探し

00:12:11.440 --> 00:12:12.800
回答を1から作成し

00:12:12.800 --> 00:12:13.940
ケースを要約してから

00:12:13.940 --> 00:12:16.100
すでに処理が遅れている次のケースに移るためです

00:12:16.100 --> 00:12:17.380
集中的なスキルアップの後

00:12:17.380 --> 00:12:19.740
担当者はAIを使用して回答の下書きを作成し

00:12:19.740 --> 00:12:21.460
承認された知識からより迅速に検索し

00:12:21.460 --> 00:12:23.360
構造化されたケースの要約を作成することで

00:12:23.360 --> 00:12:24.560
繰り返しの検索を減らします

00:12:24.560 --> 00:12:27.180
処理時間は12分から7分に短縮できます

00:12:27.180 --> 00:12:28.500
それだけでも重要ですが

00:12:28.500 --> 00:12:31.080
より重要なシグナルはもう一つの安定性です

00:12:31.080 --> 00:12:33.240
ターゲット内で解決されるケースが増えます

00:12:33.240 --> 00:12:34.980
回答が急いで手動で作成するのではなく

00:12:34.980 --> 00:12:36.440
根拠のある下書きから始まるため

00:12:36.440 --> 00:12:37.980
最初の応答の質が向上します

00:12:37.980 --> 00:12:40.800
また人員を増やすことなくチームに余裕が生まれます

00:12:40.800 --> 00:12:43.320
3つのケースすべてにおいて構造は同じです

00:12:43.320 --> 00:12:44.940
ベースラインタスクから始めます

00:12:44.940 --> 00:12:46.780
そのタスク内の動作をトレーニングします

00:12:46.780 --> 00:12:48.200
ワークフローが短くなります

00:12:48.200 --> 00:12:50.400
そして解放されたリソースが有用な場所に移動します

00:12:50.400 --> 00:12:51.940
この再現可能な構造が重要なのは

00:12:51.940 --> 00:12:53.520
ビジネスケースの信頼性を保つためです

00:12:53.520 --> 00:12:55.140
魔法を主張しているわけではありません

00:12:55.140 --> 00:12:56.760
時間がどこに費やされ何が変わり

00:12:56.760 --> 00:12:58.680
チームがその利益をどのように活用したかを示しています

00:12:58.680 --> 00:13:00.000
調査の外部ベンチマークは

00:13:00.000 --> 00:13:01.440
内部の証拠を置き換えることなく

00:13:01.440 --> 00:13:02.780
このパターンを裏付けています

00:13:02.780 --> 00:13:04.720
マイクロソフトコパイロットの調査全体を通して

00:13:04.720 --> 00:13:06.680
ユーザーは平均して毎月の時間を節約でき

00:13:06.680 --> 00:13:08.520
多くのユーザーがより早く良い最初のドラフトを

00:13:08.520 --> 00:13:09.820
作成できるようになったと報告しています

00:13:09.820 --> 00:13:10.840
測定された導入では

00:13:10.840 --> 00:13:12.840
AIが汎用アシスタントとして不動するのではなく

00:13:12.840 --> 00:13:14.700
実際のワークフローに結びつけられている場合

00:13:14.700 --> 00:13:16.480
チームは洞察を得るまでの時間が短縮され

00:13:16.480 --> 00:13:18.300
意思決定のスピードも向上したと報告しています

00:13:18.300 --> 00:13:19.480
これらのベンチマーク信号は

00:13:19.480 --> 00:13:21.580
社内の結果が孤立したものではないことを示すため有用ですが

00:13:21.580 --> 00:13:22.880
ケースを裏付けるものでなければならず

00:13:22.880 --> 00:13:24.200
ケースを支えるものでなければなりません

00:13:24.200 --> 00:13:26.380
そしてそれがリーダーに必要な規律です

00:13:26.380 --> 00:13:28.760
AIがプロセスに影響を与えたかどうかを問うのではなく

00:13:28.760 --> 00:13:30.160
プロセスが遅延が少なくなり

00:13:30.160 --> 00:13:31.040
手戻りが減り

00:13:31.040 --> 00:13:33.860
熟練した人材をより有効に活用できるようになったかどうかを問うべきです

00:13:33.860 --> 00:13:35.140
これらのケースのいずれにおいても

00:13:35.140 --> 00:13:37.060
AIは役割を取り除いたわけではありません

00:13:37.060 --> 00:13:40.060
情報が到着してからアクションが開始されるまでの遅延を取り除いたのです

00:13:40.060 --> 00:13:41.220
これがメリットです

00:13:41.220 --> 00:13:44.420
しかしこれは周囲のシステムが管理されている場合にのみ有効です

00:13:44.420 --> 00:13:46.540
出力がずれたりソースが混乱したり

00:13:46.540 --> 00:13:49.880
リスクの高いワークフローで人々が即興で作業を始めたりすると

00:13:49.880 --> 00:13:53.280
見かけ上の利益は隠れた修正作業によって消えてしまう可能性があるからです

00:13:53.280 --> 00:13:55.700
ロイを保護する厳格なガバナンス

00:13:55.700 --> 00:13:58.220
さて生産性の向上よりも刺激的ではないため

00:13:58.220 --> 00:14:00.300
多くのAIコンテンツが省略している部分

00:14:00.300 --> 00:14:01.380
ガバナンスについてです

00:14:01.380 --> 00:14:04.640
しかしこれを省略すると出力が不十分だと隠れたレビュー作業

00:14:04.640 --> 00:14:05.560
弱い意思決定

00:14:05.560 --> 00:14:07.980
そして当初誰も想定していなかったリスクが発生するため

00:14:07.980 --> 00:14:09.480
ロイモデルはすぐに弱体化します

00:14:09.480 --> 00:14:11.520
まずはデータ境界から始めましょう

00:14:11.520 --> 00:14:14.760
AIは承認されたデータソースと明確なアクセスルール

00:14:14.760 --> 00:14:17.580
そして信頼できる入力データのみを使用するべきです

00:14:17.580 --> 00:14:19.140
ソースが古かったり乱雑だったり

00:14:19.140 --> 00:14:20.520
間違った場所から取得されたりすると

00:14:20.520 --> 00:14:21.920
出力は宣伝されているように見えても

00:14:21.920 --> 00:14:23.900
チームを間違った方向に導いてしまう可能性があります

00:14:23.900 --> 00:14:25.160
これはコストがかかります

00:14:25.160 --> 00:14:26.740
必ずしも目に見える形ではありませんが

00:14:26.740 --> 00:14:30.260
再確認、手戻り、承認の遅延、そして信頼の喪失という形でコストが発生します

00:14:30.260 --> 00:14:32.560
したがって運用ルールはシンプルに保つ必要があります

00:14:32.560 --> 00:14:35.420
管理されたデータを入力しレビュー可能な出力を出力します

00:14:35.420 --> 00:14:38.520
そして責任が実際に存在するループに人間を残しておきます

00:14:38.520 --> 00:14:42.240
AIはドラフトを作成したり要約したりパターンを提案したりできますが

00:14:42.240 --> 00:14:45.220
承認、例外、最終決定は依然として人間が行います

00:14:45.220 --> 00:14:46.820
これは単なる用心深さではなく

00:14:46.820 --> 00:14:50.060
スピードのメリットを享受しながら意思決定の質を保護する方法です

00:14:50.060 --> 00:14:54.300
特に財務、プロジェクトリスク、顧客案件、または規制上の影響があるあらゆる分野では

00:14:54.300 --> 00:14:57.020
プロンプトだけでなく誰かが判断を下す必要があります

00:14:57.020 --> 00:14:59.120
ここでユースケースの分離が役立ちます

00:14:59.120 --> 00:15:02.800
リスクの低い作業、つまり要約、メールの下書き、会議のアクション

00:15:02.800 --> 00:15:04.480
最初のコメントから先にスケールアップします

00:15:04.480 --> 00:15:07.180
これらはメリットが分かりやすく、デメリットも見つけやすいため

00:15:07.180 --> 00:15:08.880
習慣を身につけるのに適しています

00:15:08.880 --> 00:15:11.420
次にAIが思考の構造化を支援するものの

00:15:11.420 --> 00:15:13.020
ループを単独で閉じるわけではない

00:15:13.020 --> 00:15:14.660
監視された分析サポートに進みます

00:15:14.660 --> 00:15:19.000
高リスクの自動化は、ワークフローが財務、法律、またはサービスのリスクを伴うようになると

00:15:19.000 --> 00:15:22.360
誤った出力のコストが急速に上昇するため、狭く管理されたままになります

00:15:22.360 --> 00:15:25.160
分離がなければ、企業はすべてを混同してしまいます

00:15:25.160 --> 00:15:29.800
会議の要約と機密性の高い意思決定プロセスを同じリスクを伴うものとして扱いますが、そうではありません

00:15:29.800 --> 00:15:34.000
そして、人々がその境界を認識できない場合、ツールを過信するか、完全に避けるかのどちらかになります

00:15:34.000 --> 00:15:35.440
どちらも価値を損ないます

00:15:35.440 --> 00:15:36.740
標準も重要です

00:15:36.740 --> 00:15:39.120
ランダムなプロンプトはランダムな作業を生み出します

00:15:39.120 --> 00:15:48.120
すべての従業員が要約、下書き、分析を要求する独自の方法を考案すると、品質はあちこちに広がり、管理者はビジネス価値ではなくスタイルの違いをレビューすることになります

00:15:48.120 --> 00:15:52.260
共有プロンプトパターン、役割ガイド、簡単な例によってこのズレを軽減できます

00:15:52.260 --> 00:15:56.120
プロンプトが戦略だからではなく、反復可能な行動が手戻りを減らすからです

00:15:56.120 --> 00:15:58.540
また、展開後も測定を止めることはできません

00:15:58.540 --> 00:16:03.360
節約された時間、導入の深さ、例外発生率、手戻り、出力品質の低下をリアルタイムで把握する必要があります

00:16:03.360 --> 00:16:06.260
そうしないと、初期の成果が後々の劣化を覆い隠してしまう可能性があります

00:16:06.260 --> 00:16:09.600
チームは書類上は早く見えるかもしれませんが、修正作業がどこかで積み上がっているかもしれません

00:16:09.600 --> 00:16:10.820
それはロイではありません

00:16:10.820 --> 00:16:13.260
それはコストがシステムの別の部分に移動しただけです

00:16:13.260 --> 00:16:15.320
そして、これが経営幹部のポイントです

00:16:15.320 --> 00:16:18.460
ガバナンスは価値を遅らせるのではなく、価値が過大評価されるのを防ぎます

00:16:18.460 --> 00:16:24.120
リーダーは賢いと感じる者に資金を提供するのではなく、監査、比較、そして結果が疑問視された時に弁護できる者に資金を提供します

00:16:24.120 --> 00:16:32.880
したがって、AIプログラムがクリーンな入力、明確な所有権、妥当な階層、測定された成果を示すことができれば、それは実験ではなく運用規律のように見えます

00:16:32.880 --> 00:16:40.680
これらのコントロールがモデルに組み込まれると、AIの使用拡大は熱意への欠けではなく、管理されたビジネス上の選択のように見えます

00:16:40.680 --> 00:16:42.180
無駄のないスケーリング

00:16:42.180 --> 00:16:44.880
パイロットから運用モデルへの拡大方法

00:16:44.880 --> 00:16:48.100
次に犯す間違いは、時期焦燥に規模を拡大することです

00:16:48.100 --> 00:16:55.180
パイロットプロジェクトで有望な結果が出れば、経営人は興奮し、実際に成果を生み出したパターンが確立される前に、ライセンスが社内全体に拡散されてしまいます

00:16:55.180 --> 00:16:56.960
これが資金流出の原因です

00:16:56.960 --> 00:17:00.860
ツールが機能しなくなったからではなく、ツールを中心とした運用モデルが構築されなかったからです

00:17:00.860 --> 00:17:03.400
より良い道は、小規模かつ具体的なものから始めることです

00:17:03.400 --> 00:17:05.760
各ターゲットロールごとに3から5つのワークフローを選択します

00:17:05.760 --> 00:17:12.180
10個ではなく、考えられるすべてのユースケースではなく、繰り返し実行され、摩擦が目に見える形で存在し、ビジネス上の関連性が明確なワークフローのみを選択します

00:17:12.180 --> 00:17:14.260
何も変更される前にベースラインを把握します

00:17:14.260 --> 00:17:17.860
次に、一般的な機能の説明ではなく、タスクそのものについて従業員をトレーニングします

00:17:17.860 --> 00:17:21.420
財務アナリストは、まずAIの可能性について幅広く学ぶ必要はありません

00:17:21.420 --> 00:17:28.160
必要なのは、解説文の作成を短縮する方法、繰り返し使用するスプレッドシートをより早く整理する方法、そしてやり取りを減らして再分析を構成する方法を知ることです

00:17:28.160 --> 00:17:30.980
次に、厳格な成功基準を設けた短いパイロットサイクルを実行します

00:17:30.980 --> 00:17:32.500
時間の節約は実現しましたか?

00:17:32.640 --> 00:17:33.980
サイクルタイムは短縮されましたか?

00:17:34.080 --> 00:17:35.360
品質は安定していましたか?

00:17:35.440 --> 00:17:38.120
トレーニングを受けたユーザーは最初の1週間後もそのパターンを使い続けましたか?

00:17:38.220 --> 00:17:39.640
これらが重要なシグナルです

00:17:39.640 --> 00:17:43.200
アクティブ利用が減少したり、手戻りが増加したりした場合は、まだ拡張しないでください

00:17:43.200 --> 00:17:46.340
まずはワークフロー、ガイダンス、またはサポートを改善してください

00:17:46.340 --> 00:17:48.820
規律のない成長は混乱を招くだけです

00:17:48.820 --> 00:17:52.840
ここで役立つのは、各ステークホルダーの言葉で語る証明パックを作成することです

00:17:52.840 --> 00:17:56.320
CFOは、回収された労働力と回避された無駄のコストビューを求めています

00:17:56.320 --> 00:18:00.320
Qは、サイクルタイム、スループット、およびサービスの信頼性の改善を求めています

00:18:00.320 --> 00:18:05.760
LINEマネージャーは、チームがより多くの仕事を吸収できるか、より迅速に対応できるか、または手動管理を削減できるかを知りたいと思っています

00:18:05.760 --> 00:18:09.000
したがって、次のフェーズを要求するときに、ベンダーの広範な主張を提示しないでください

00:18:09.000 --> 00:18:12.600
一度に一つのワークフローに関連付けられた、自社環境からの役割レベルのデータを提示してください

00:18:12.600 --> 00:18:14.320
予算も変更する必要があります

00:18:14.320 --> 00:18:19.780
AIへの支出の多くは、組織化されているように見えても定着しない一般的な認定や単発のトレーニングイベントに費やされています

00:18:19.780 --> 00:18:25.440
より強力なモデルは、ワークフローに組み込まれたコーチング、共有プロンプトライブラリ、およびマネージャー主導の強化に資金を投入します

00:18:25.440 --> 00:18:28.920
これらは、有用なデモを繰り返しの行動に変えるメカニズムだからです

00:18:28.920 --> 00:18:31.860
ソースセットの調査も、その方向性を示しています

00:18:31.860 --> 00:18:38.480
業績の高い組織は、主な解決策として、外部認定よりも内部プログラムの設計とマネージャーのサポートに多くの費用をかけています

00:18:38.480 --> 00:18:42.040
拡張は、役割のグループとユースケースの改装に従って行うべきです

00:18:42.040 --> 00:18:47.000
ある財務チームがレポート作成と称号のサポートで価値を証明したら、隣接する財務ワークフローに移行します

00:18:47.000 --> 00:18:51.680
PMがステータスレポートとアクション追跡で成果を上げたら、関連する調整パターンに移行します

00:18:51.680 --> 00:18:53.780
このようなスケーリングは形を保ちます

00:18:53.780 --> 00:18:57.340
包括的なライセンスは、使用が機能よりも早く広がるため、滅多にうまくいきません

00:18:57.340 --> 00:19:00.580
そして、全ての展開決定の前に、一つの質問を常に念頭に置いてください

00:19:00.580 --> 00:19:02.280
これは作業の流れを変えましたか?

00:19:02.380 --> 00:19:04.760
答えが、いいえ、の場合は、立ち止まってください

00:19:04.760 --> 00:19:10.440
利益はAIアクセスを追加することからではなく、ビジネスが測定できる方法で入力からアクションへのパスを変更することから生まれるからです

00:19:10.440 --> 00:19:12.180
つまり、シフトはシンプルです

00:19:12.180 --> 00:19:19.720
ロイはトレーニングの量から生まれるのではなく、人々がすでに言っている作業の中で、より短いタスク、より迅速な意思決定、よりクリーンな実行から生まれます

00:19:19.720 --> 00:19:29.560
今週、財務、プロジェクト管理、またはサポートのいずれかのワークフローを選択し、ターゲットを絞ったスキルアップの後、手動バージョンとAI支援バージョンを比較し、回復した能力がどこに使われるかを確認してください

00:19:29.560 --> 00:19:41.080
もし今回の記事でマイクロソフトAIに対する考え方が変わったなら、M365FMポッドキャストを公読し、レビューを残し、リンクトインで渡し、ミルコピーターズとつながり、次に解決してほしいワークフローのボトルネックを私に送ってください
