WEBVTT

00:00:08.000 --> 00:00:13.232
こんにちは皆様、Operational ITAM
ポッドキャストへようこそ。私はビル・ヴァン・ノー

00:00:13.232 --> 00:00:18.465
トです。今日は、アカウントに反映される前にプレゼ
ンテーションに含まれた節約についてお話しします。

00:00:19.135 --> 00:00:24.105
ライセンスは整理済みです。変更チケットは閉鎖され
ました。プロジェクト報告書では作業が完了している

00:00:24.105 --> 00:00:29.074
と記載されています。その後、財務部門からなぜサプ
ライヤーがまだ旧額の請求を続けているのかと問われ

00:00:29.074 --> 00:00:29.480
ました。

00:00:30.075 --> 00:00:36.360
誰もそれがプロジェクトの一部だとはもう思っていな
い。幸いなことに、請求書がみんなを再び集めた。

00:00:37.075 --> 00:00:40.460
今日、The Decision
Table：節約はどこへいったのか？

00:00:41.095 --> 00:00:47.107
おはようございます、こんにちは、あるいはこんばん
は。どこから聞いていただいてもおかまいありません

00:00:47.107 --> 00:00:52.260
。これは、企業の技術のつまらない機械を分かりやす
くする番組です。コーヒーをどうぞ。

00:00:52.935 --> 00:01:00.360
第 15 話で、更新の決定権があるのは誰かを示し
ました。その人物に実際に承認できる証拠、選択肢、

00:01:00.360 --> 00:01:01.875
条件を提供しました。

00:01:02.655 --> 00:01:08.780
今日、承認後から始めます。結果を説明できるように
なるまで、1 つの変更点に従って進めていきます。

00:01:09.495 --> 00:01:14.850
FinOps Foundation のレポートお
よび分析に関するガイドラインでは、実際の支出と意

00:01:14.850 --> 00:01:20.205
思決定の背後にある見積もりを比較することを求めて
います。これは有益な出発点です。実用的な課題は、

00:01:20.205 --> 00:01:25.560
何か問題が起きたたびに元の見積もりを変更すること
なく、それらの間の距離を説明することにあります。

00:01:26.155 --> 00:01:31.568
私の意見、明確にラベル付けされた：元のビジネスケ
ースはファイルに残すべきです。予測を更新するのは

00:01:31.568 --> 00:01:36.982
絶対に必要です。以前のバージョンも残しておき、組
織が何が変更されたかを学ぶことができるようにして

00:01:36.982 --> 00:01:42.395
ください。そうでなければ、すべてのプロジェクトは
最終的に、最後にそれをタイプした人の数値を正確に

00:01:42.395 --> 00:01:43.500
達成してしまいます。

00:01:43.835 --> 00:01:50.419
架空の企業と作成されたソフトウェア契約を用います
。これらはベンダー価格やクライアントの結果を示す

00:01:50.419 --> 00:01:55.660
ものではなく、架空の米ドル額です。1 月から
12 月までの通年を踏襲します。

00:01:56.190 --> 00:02:00.993
同社は、月額 20 ドルで
1000件のソフトウェアライセンスを契約し、月額

00:02:00.993 --> 00:02:06.175
20000 ドルを支払います。これは 1 年間で
240000 ドルに相当します。

00:02:06.850 --> 00:02:11.641
アサインメントのレビューにより、800 のソフト
ウェア席（ライセンスサブスクリプション）が継続的

00:02:11.641 --> 00:02:16.236
なビジネス要件を満たすことが確認されました。提案
される削減は 200 のソフトウェア席で、1

00:02:16.236 --> 00:02:20.928
月から開始されます。同じ単価であれば、これは月に
4000 ドル、または年間を通じて 48000

00:02:20.928 --> 00:02:22.395
ドルを削減することになります。

00:02:22.775 --> 00:02:28.884
それが私たちがもともと予測した総額です。総額とは
、変更にかかるコストを引く前の金額を指します。ま

00:02:28.884 --> 00:02:34.994
た、これは条件付きであり、数量は商業的に削減可能
であること、変更は 1 月に発効すること、そして

00:02:34.994 --> 00:02:38.360
残りのサービスが引き続き要件を満たすことが必要で
す。

00:02:39.135 --> 00:02:44.426
資金の流れを追う前に、何を比較しているかを明確に
しましょう。このケースでは、財務部門は既存のサー

00:02:44.426 --> 00:02:49.717
ビスを 1000 seats で、同じ 20 ド
ルのレートで維持することが、その年のサポート可能

00:02:49.717 --> 00:02:55.008
な代替案であると合意しています。私たちは現在の請
求書と、それを支える変更のない利用可能な更新があ

00:02:55.008 --> 00:02:55.440
ります。

00:02:55.800 --> 00:03:02.425
ビジネス要件はそのままです。削減は不要な割り当て
を排除するもので、閉鎖された部門ではありません。

00:03:02.425 --> 00:03:09.050
比較の中に隠されている価格引き上げ、税金の変更、
為替変動、またはサービスダウングレードはありませ

00:03:09.050 --> 00:03:09.320
ん。

00:03:10.020 --> 00:03:14.694
それらの仮定がこの例を分かりやすく保っています。
ご自身の記録では、それぞれを確認する必要がありま

00:03:14.694 --> 00:03:14.885
す。

00:03:15.480 --> 00:03:22.058
その同意された比較がベースラインです。それは、結
果が何と比較されているかを示します。昨年の支払い

00:03:22.058 --> 00:03:28.636
、今年の予算、サプライヤーの開示見積もり、および
将来の需要の予測は異なるベースラインです。同じ請

00:03:28.636 --> 00:03:34.275
求書でも、1 に対しては有利に見え、別のものに対
しては不利に見えることがあります。

00:03:34.870 --> 00:03:39.989
もし需要が本当に変化した場合、それを別に説明して
ください。おそらく会社がより多くの顧客をサービス

00:03:39.989 --> 00:03:45.109
したり、別の部門を買収したりしているかもしれませ
ん。承認された比較を保ったまま、新しい範囲とその

00:03:45.109 --> 00:03:50.228
証拠を示した調整後のビューを表示してください。静
かに出発点を書き換えて、その違いをパフォーマンス

00:03:50.228 --> 00:03:51.795
と呼ぶことはしないでください。

00:03:52.500 --> 00:03:57.412
また、句点も必要です。月次削減を 12
で掛けたものがそのレートでの満 1

00:03:57.412 --> 00:04:03.917
年を表しますが、それが 12 ヶ月の利益が発生し
たことを示すわけではありません。この区別がすぐに

00:04:03.917 --> 00:04:05.245
重要になるでしょう。

00:04:05.900 --> 00:04:11.192
チーム間のハンドオフでその規律を失いやすい場所が
あります。未使用の割り当てを発見する人は機会を見

00:04:11.192 --> 00:04:16.484
積もるかもしれません。調達部門は交渉されたポジシ
ョンを記録するかもしれません。デリバリー部門はア

00:04:16.484 --> 00:04:19.400
クションが完了であることをマークするかもしれませ
ん。

00:04:19.960 --> 00:04:24.885
財務部門は認識された結果を報告する可能性がありま
す。それらは有用なマイルストーンですが、独自の日

00:04:24.885 --> 00:04:29.811
付と証拠が必要です。すべて 4 つが「節約済み」
とラベル付けされている場合、レポートは実際の作業

00:04:29.811 --> 00:04:32.625
の進捗状況についてあなたに何も教えてくれなくなり
ます。

00:04:33.240 --> 00:04:39.250
元の推定値を最新の見積もりと、現在までの実証結果
と共に維持してください。もし元の推定が間違ってい

00:04:39.250 --> 00:04:45.260
た場合は、簡潔な説明を残してください。合理的だっ
たものの状況が変わった場合は、その変化を記録して

00:04:45.260 --> 00:04:51.270
ください。次の意思決定を改善しようとしているので
、議論する必要がないよう列を整えるのではなく、1

00:04:51.270 --> 00:04:52.865
つの点に集中してください。

00:04:53.380 --> 00:04:57.862
チームは予定より遅れて片付けを終了しました。1
月は引き続き 1000 の有料ライセンスサブスク

00:04:57.862 --> 00:05:01.878
リプション（ソフトウェア・シートの数）が維持され
ました。署名された変更は 2 月 1

00:05:01.878 --> 00:05:02.625
日に発効します。

00:05:02.990 --> 00:05:08.962
もう一つの違いがあります。サプライヤーはコミット
メントを 850 シートにのみ削減することに同意

00:05:08.962 --> 00:05:14.935
します。これは、この架空の修正における最小値です
。特定の出版者の規則に関する記述ではありません。

00:05:15.570 --> 00:05:20.838
承認された所有者はそのオプションを受け入れ、チー
ムは購入した 850 のライセンスサブスクリプシ

00:05:20.838 --> 00:05:26.105
ョンに対して割り当てられた 800 のソフトウェ
ア座席を記録します。まだ支払いが行われている未割

00:05:26.105 --> 00:05:30.835
り当ての座席は 50 です。これは既に達成された
別の節約ではなく、利用可能な容量です。

00:05:31.330 --> 00:05:35.413
今、修正された予測を説明できます。1
月の計画された 4000

00:05:35.413 --> 00:05:41.077
ドルの削減を失いました。残りの 11
ヶ月について、追加の 50 の有料ライセンスサブ

00:05:41.077 --> 00:05:46.741
スクリプションは、元の目標より月額 1000
ドル高くなりました。また、元の予測の別の

00:05:46.741 --> 00:05:49.375
11000 ドルはこの年で実現しません。

00:05:50.060 --> 00:05:54.869
48000、タイミングによる 4000
を差し引き、保留されたコミットメントによる

00:05:54.869 --> 00:06:00.147
11000 を差し引いた後、暦年における予想され
るサブスクリプション削減額は 33000

00:06:00.147 --> 00:06:01.085
ドルとなります。

00:06:01.780 --> 00:06:07.277
それを確認する簡単な方法があります。2
月の請求額は、20000 から 17000

00:06:07.277 --> 00:06:13.445
に減少する必要があります。11 ヶ月で 3000
ドル少ない、つまり 33000 ドルです。

00:06:13.830 --> 00:06:19.309
運用上のクリーンアップは完了しても、商業的な成果
が当初提案されたものより小さい場合があります。両

00:06:19.309 --> 00:06:24.789
方の記述は報告書に含まれるべきです。この作業を失
敗と呼ぶことは削減を無視することになります。予測

00:06:24.789 --> 00:06:28.255
に 48000
を保持することは合意を無視することになります。

00:06:28.845 --> 00:06:36.002
ここで証拠を接続します。承認された提案書、署名さ
れた修正条項、有効日、および割当記録を一緒に保管

00:06:36.002 --> 00:06:37.025
してください。

00:06:37.565 --> 00:06:43.484
各々は異なる質問に答えます。我々が意図したのは何
ですか？サプライヤーが合意したのは何ですか？その

00:06:43.484 --> 00:06:47.470
義務はいつ変更されましたか？チームが実際に実装し
たのは何ですか？

00:06:48.080 --> 00:06:53.907
利益記録および請求調査において参照可能な安定した
レファレンスを与え、変更を反映させます。新しいプ

00:06:53.907 --> 00:06:59.734
ラットフォームは必要ありません。既存の更新記録内
のレファレンスが十分であり、関係者が支援文書を見

00:06:59.734 --> 00:07:00.685
出せる場合です。

00:07:01.400 --> 00:07:06.956
Microsoft のビジネスサブスクリプション
ライセンスの購入または削除に関するガイダンスは、

00:07:06.956 --> 00:07:12.513
ここで有用な区別を示しています。ユーザーからライ
センスを割り当てる解除と、購入されたライセンスの

00:07:12.513 --> 00:07:18.069
削除とは別の手順です。削除のタイミングは請求計画
と適用可能なウィンドウに依存します。料金が発生す

00:07:18.069 --> 00:07:22.265
る時期を予測する前に、実際のサブスクリプションと
契約を確認してください。

00:07:22.720 --> 00:07:28.370
それは、私たちが考案した 850 シートの最小値
とは別の実際の製品メカニズムです。割り当てがより

00:07:28.370 --> 00:07:34.019
少ないことを示すスクリーンショットは、割り当てに
ついて何かを示しますが、それ自体で支払可能な数量

00:07:34.019 --> 00:07:36.325
が低いことを証明するものではありません。

00:07:36.980 --> 00:07:42.907
アクセスを削除する前に、責任ある人々と相談して継
続的なサービス、データ、および保持要件を確認して

00:07:42.907 --> 00:07:48.834
ください。変更が承認されたスタッフが必要な業務を
行うことを妨げる場合、請求額が安くなることは成功

00:07:48.834 --> 00:07:50.285
した結果ではありません。

00:07:50.920 --> 00:07:58.505
我々の架空の会社も、外部の専門家による片付け完了
のために 6000 ドルを支払います。この例では

00:07:58.505 --> 00:08:06.090
、それが唯一の追加実装コストであり、1 年間に発
生し支払われ、財務部門はそれを利益比較に含めます

00:08:06.090 --> 00:08:06.245
。

00:08:06.960 --> 00:08:11.594
サブスクリプション削減額 33000
ドルから、実装費用として差し引く 6000

00:08:11.594 --> 00:08:15.765
ドルを控除し、年間予想ネットベネフィットは
27000 ドルとなります。

00:08:16.400 --> 00:08:22.037
内部スタッフもその変更にかかり時間を費やします。
その労力を記録してください。この場合、既存のキャ

00:08:22.037 --> 00:08:27.674
パシティ内に収まり、追加の人件費や代替された資金
化された作業が特定されていないため、追加の現金支

00:08:27.674 --> 00:08:29.860
払いを創出しているわけではありません。

00:08:30.380 --> 00:08:35.738
もし重要な業務を代替した場合、何が代替されたかを
述べ、評価してください。支払済の請求書だけが意思

00:08:35.738 --> 00:08:37.925
決定のコストの唯一のものではありません。

00:08:38.500 --> 00:08:44.774
完了チェックもチケットステータスだけでは不十分で
す。サービスオーナーが、正しい割り当てが削除され

00:08:44.774 --> 00:08:51.049
、必要な人がアクセス権を保持し、購入数量が修正と
一致していることを確認してください。割り当てを実

00:08:51.049 --> 00:08:57.323
際に制御するシステムから日付付きの記録を保存して
ください。自動化されたルールで明日にその割り当て

00:08:57.323 --> 00:09:01.805
を戻せる場合、作業を閉じる前にそのルールの所有者
を特定してください。

00:09:02.460 --> 00:09:08.522
サービスの規模に比例したチェックを行ってください
。不活性なアカウントが削除されたからといって、ア

00:09:08.522 --> 00:09:14.584
プリケーション全体を再テストする必要はありません
。ただし、削除が行われたことと、それを不要と呼ぶ

00:09:14.584 --> 00:09:20.646
理由が妥当であることを知る必要があります。変更を
要請するだけの証拠しかない場合、実装は検証されて

00:09:20.646 --> 00:09:21.265
いません。

00:09:21.980 --> 00:09:28.240
反論は妥当です：これは、わずかな削減に対して多く
の確認作業のように聞こえます。努力は比例している

00:09:28.240 --> 00:09:34.501
べきです。小さな単純な変更にはいくつかの関連レコ
ードと短いレビューが必要になる場合がありますが、

00:09:34.501 --> 00:09:40.761
それでも有効日、実際の数量、そしてそこに至るため
のコストを誰かが確立する必要があります。事実が単

00:09:40.761 --> 00:09:42.805
純であれば、計算は短くなります。

00:09:43.420 --> 00:09:49.819
この時点で、見直された予測があります。まだ全年分
の結果を確認していません。今必要なのは請求書であ

00:09:49.819 --> 00:09:53.345
り、そこが私たちのケースがより興味深い点となりま
す。

00:09:58.000 --> 00:10:02.153
少し休憩しましょう。この作業の実用的な手順をお探
しなら、Operational ITAM

00:10:02.153 --> 00:10:05.475
Store の「Validate
Benefits and Report

00:10:05.475 --> 00:10:09.720
Business Outcomes」というものが
1 つあります。それは手順 F02 です。

00:10:10.440 --> 00:10:15.579
それは、編集可能な HTML
プロシージャ、SVG フローチャート、およびロー

00:10:15.579 --> 00:10:22.035
カル採用と証拠チェックリストを含みます。初期入力
には、合意されたベースライン、承認されたアクショ

00:10:22.035 --> 00:10:27.965
ン、請求書または見積もり、実装コスト、通貨、期間
、およびビジネス成果の証拠が含まれます。

00:10:28.560 --> 00:10:32.080
これにより、財務部門との対話を構造化された場所か
ら始めることができます。

00:10:32.960 --> 00:10:36.380
組織に合わせて責任と測定決定を適応させます。

00:10:37.120 --> 00:10:42.213
その手順は、財務チームが認識する内容を決定するも
のではなく、数字の背後にある記録を置き換えるもの

00:10:42.213 --> 00:10:43.045
でもありません。

00:10:43.650 --> 00:10:49.179
operationalitam.com/stor
e のコンテンツを確認できます。これは私の有料リ

00:10:49.179 --> 00:10:54.708
ソースであり、購入することで番組をサポートします
。今日の課題は、すでに持っている情報を使用してお

00:10:54.708 --> 00:10:56.175
り、購入を必要としません。

00:10:56.745 --> 00:11:01.432
また、podcast と実用的なリソースは
operationalitam.com でご覧い

00:11:01.432 --> 00:11:06.424
ただけます。もし誰かが「節約分はどこへいったのか
」と繰り返し尋ねてくる場合、このエピソードを共有

00:11:06.424 --> 00:11:07.850
すると役立つかもしれません。

00:11:11.945 --> 00:11:13.550
さて、インボイスに戻りましょう。

00:11:14.445 --> 00:11:18.913
1 月は正しく 20000
ドルで請求されています。しかし、2 月と 3

00:11:18.913 --> 00:11:22.884
月も 20000
ドルで請求されており、署名された修正書では 2

00:11:22.884 --> 00:11:26.608
月以降は 17000
ドルである必要があります。4 月と 5

00:11:26.608 --> 00:11:29.090
月は正しい 17000 ドルに達します。

00:11:29.565 --> 00:11:33.645
5 月末日時点で、その 5 つの請求書の合計は
94000 ドルです。

00:11:34.285 --> 00:11:39.703
私たちが変更しないベースラインは 5 ヶ月で
100000 です。現在の請求書には 6000

00:11:39.703 --> 00:11:41.470
ドルの削減が表示されています。

00:11:42.105 --> 00:11:48.021
その合意は異なる数値を支持しています。1 月は
20000 で、その後 4 ヶ月が 17000

00:11:48.021 --> 00:11:52.678
の場合、合計は 88000
です。ベースラインと比較すると、5 月までには

00:11:52.678 --> 00:11:55.070
12000 ドルの削減になるはずです。

00:11:55.645 --> 00:12:00.693
6,000 ドルのギャップは、2
月に追加で請求された 3,000 ドルと、再び

00:12:00.693 --> 00:12:06.877
3 月に請求されたものである。これは改正によって
支持される請求上の紛争であり、契約価格のさらなる

00:12:06.877 --> 00:12:07.760
削減ではない。

00:12:08.495 --> 00:12:14.789
この区別を明確に示してください。5月の報告締め時
点では、記録済みの請求書で裏付けられる6000ド

00:12:14.789 --> 00:12:21.082
ルと、係争中の追加の6000ドルを分けて示します
。係争中の金額について組織の方針に基づく会計上の

00:12:21.082 --> 00:12:27.376
調整が必要かどうかは、財務部門が判断します。クレ
ジットの発行が見込まれることは、実際に発行された

00:12:27.376 --> 00:12:28.660
証拠にはなりません。

00:12:29.345 --> 00:12:35.872
調査は具体的であるべきです。サブスクリプション、
法的実体、両方の請求書番号、関連するサービス期間

00:12:35.872 --> 00:12:42.398
、合意された数量、および改正の有効日特定してくだ
さい。サプライヤーに 2 つの特定された差異を修

00:12:42.398 --> 00:12:48.925
正することを依頼してください。これは、「節約レポ
ートが正しく見えない」というメッセージよりもはる

00:12:48.925 --> 00:12:50.390
かに解決しやすいです。

00:12:51.085 --> 00:12:57.404
Microsoft の請求書ガイダンスは、請求日
とその請求が対象とするサービス期間を区別していま

00:12:57.404 --> 00:13:03.723
す。この区別はこの例を超えて重要です。今月届く文
書は以前のカバー期間に関するものかもしれません。

00:13:03.723 --> 00:13:09.010
両方の日付を記録することで、遅れた修正が新しい運
用改善と誤解されるのを防ぎます。

00:13:09.645 --> 00:13:13.748
架空の事例において、サプライヤーは紛争を受け入れ
、6 月に 6000

00:13:13.748 --> 00:13:17.499
ドルのクレジットを発行します。これは 6
月の通常の 17000

00:13:17.499 --> 00:13:22.070
ドルの請求額に適用され、その請求書に対する残額は
11000 ドルとなります。

00:13:22.845 --> 00:13:28.416
6 月は 11,000 ドルのサービスにはなって
いません。継続課金は依然として 17,000

00:13:28.416 --> 00:13:32.090
です。6,000 は 2 月と 3
月の修正に関連しています。

00:13:32.765 --> 00:13:38.952
そのクレジットを元の請求書に紐付け、適用時期を表
示してください。財務が以前の実績期間で既に是正を

00:13:38.952 --> 00:13:45.140
認識している場合、その後の到着は当該項目を確定さ
せます。節約レポートにおいて二重の利益を生み出し

00:13:45.140 --> 00:13:46.150
てはいけません。

00:13:46.725 --> 00:13:52.884
現金が節約されたと言いたい場合は、決済を確認して
ください。請求書、費用入力、貸方残高、および支払

00:13:52.884 --> 00:13:59.043
いは関連するレコードですが、それらは相互に交換可
能ではありません。私たちが完了した架空の年度にお

00:13:59.043 --> 00:14:05.202
いて、すべての関連する請求額と貸方は決済されます
。その時点以前は、証拠が支持するラベルを使用して

00:14:05.202 --> 00:14:05.830
ください。

00:14:06.525 --> 00:14:11.526
今年を締めくくりましょう。7 月から 12
月にかけて、サブスクリプションは月額 17000

00:14:11.526 --> 00:14:16.853
ドルで維持されます。さらに請求エラー、新しいソフ
トウェア seats、または追加のプロジェクトコ

00:14:16.853 --> 00:14:22.180
ストが発生しません。事業主は、継続的なサービスが
合意された要件を満たしていることを確認しました。

00:14:22.700 --> 00:14:28.169
クレジット後の最終サブスクリプション合計は
207000 ドルです。これを 1 月の

00:14:28.169 --> 00:14:34.158
20000 に加えて、残りの 11 ヶ月を
17000 で計算することで確認できます。我々の

00:14:34.158 --> 00:14:38.194
240000
ドルのベースラインに対して、削減額は 33000

00:14:38.194 --> 00:14:38.585
です。

00:14:38.880 --> 00:14:45.039
実装コストの 6,000 ドルを差し引きます。当
社の示した仮定の下、暦年ベースのネットベネフィッ

00:14:45.039 --> 00:14:46.925
トは 27,000 ドルです。

00:14:47.530 --> 00:14:53.732
その結果にはすでにクレジットが含まれています。そ
れを再度加えると、利益が過大評価されます。それを

00:14:53.732 --> 00:14:59.935
除外すると、利益が過小評価されます。クレジットは
請求記録を修正し、修正された義務と一致させます。

00:15:00.515 --> 00:15:05.184
現在、元の 48000
がどうなったかを説明できます。4000 は変更が

00:15:05.184 --> 00:15:08.426
1
ヶ月後に開始されたため失われました。11000

00:15:08.426 --> 00:15:13.095
はコミットメントが 850
シートにしか低下しなかったため失われました。

00:15:13.695 --> 00:15:17.466
変更の実施には 6000
が費やされました。残りの 27000

00:15:17.466 --> 00:15:20.020
は完了したケースによって支えられています。

00:15:20.695 --> 00:15:26.442
それは、他者が再現できる説明です。また、次のプロ
ジェクトに有用な情報を提供します。有効日について

00:15:26.442 --> 00:15:32.190
はさらに注意が必要です。最小コミットメントは、当
初の予測が circulated される前にテス

00:15:32.190 --> 00:15:37.820
トされていればよかったはずです。請求書は、技術作
業が完了した後にもフォローアップが必要でした。

00:15:38.515 --> 00:15:44.518
さて、誰かが年間化された削減を尋ねたとします。月
額 3000 ドルの場合、継続的なサブスクリプシ

00:15:44.518 --> 00:15:50.521
ョンの削減額は、同じ範囲、レート、コミットメント
が継続すると仮定して 12 ヶ月で 36000 

00:15:50.521 --> 00:15:56.525
となります。これはフォワードランレートです。これ
は今年の 33000 のグロス結果や 27000

00:15:56.525 --> 00:15:59.220
のネット結果を置き換えるものではありません。

00:15:59.775 --> 00:16:05.507
また、管理部門が放出された予算を別のサービスに支
出する場合は、その配分を別々に報告してください。

00:16:05.507 --> 00:16:11.238
総技術予算は変わらない場合でも、元のサービスの費
用はより低くなる可能性があります。同様に、総予算

00:16:11.238 --> 00:16:15.800
の低下があなたの特定の行動による削減であることを
証明するものではありません。

00:16:16.435 --> 00:16:21.389
Amazon Web Services は、ラベ
ルがなぜ重要なのかを示す別の有用な例を提供します

00:16:21.389 --> 00:16:24.320
。その Savings Plans
utilization

00:16:24.320 --> 00:16:28.769
ドキュメントは、同じ使用量に対する推定
On-Demand コストに対する総ネットセービ

00:16:28.769 --> 00:16:31.195
ングを定義しています。これは定義された比較です。

00:16:31.855 --> 00:16:36.200
それは、組織の請求額が前月と比較してその分減少し
たことを意味するわけではありません。

00:16:36.915 --> 00:16:40.640
Amazon Web
Services、または一般的に AWS と呼ば

00:16:40.640 --> 00:16:45.854
れるものもまた、コミットメントのどの部分が使用さ
れたかを報告します。ワークロードが削減された場合

00:16:45.854 --> 00:16:51.069
、そのコミットメントはどうなるか、および他の適格
な利用がそれを吸収するかどうかを確認してください

00:16:51.069 --> 00:16:51.175
。

00:16:51.775 --> 00:16:55.735
技術的な削減と財務的な削減は、異なる時期に発生す
る可能性があります。

00:16:56.415 --> 00:17:00.140
答えは、使用状況、コミットメント、および請求証拠
のすべてにあります。

00:17:00.855 --> 00:17:06.812
当社のシートの例において、50 の未割り当ての有
料シートは後に新しい採用者を収容する可能性があり

00:17:06.812 --> 00:17:12.769
ます。もしそうであれば、実際の再利用を記録してく
ださい。誰かが回避された購入を主張したい場合は、

00:17:12.769 --> 00:17:18.726
本来必要だった追加の購入を文書化し、財務部門と比
較を合意してください。今年度の削減から生じる現金

00:17:18.726 --> 00:17:24.440
節約として、保持された容量とその後の再利用の両方
を別々のものとしてカウントしないでください。

00:17:25.115 --> 00:17:30.222
もしクレジットがいつまでも届かない場合、または記
録が不完全な場合はどうすればよいでしょうか？項目

00:17:30.222 --> 00:17:34.495
を金額、証拠のギャップ、責任者、および次のアクシ
ョンと共に開けておいてください。

00:17:34.995 --> 00:17:40.236
サポートされた結果と未解決の金額を別々に報告して
ください。すべての問題が解決する前に、有用な結果

00:17:40.236 --> 00:17:44.300
を得ることができますが、レポートがその限界を明確
にしている必要があります。

00:17:44.790 --> 00:17:50.239
もしサービスが悪化したらどうなるでしょうか。その
財務結果と並べてください。合意された指標を追跡し

00:17:50.239 --> 00:17:55.688
てください：必要なアクセス、作業の完了、サポート
需要、あるいはビジネスオーナーが設定した他のもの

00:17:55.688 --> 00:18:01.138
など。サブスクリプションの削減は、再作業や他での
運用問題を消去するものではありません。FinOp

00:18:01.138 --> 00:18:06.475
s Foundation の Quantify
Business Value ガイドラインは、単

00:18:06.475 --> 00:18:11.035
なる金銭的コストだけでなく、サービスと組織のパフ
ォーマンスを明確に含んでいます。

00:18:11.670 --> 00:18:18.630
私の推奨は、他の人がその比較と証拠を追跡できる場
合にのみ利益請求を閉鎖することです。範囲と期間を

00:18:18.630 --> 00:18:25.591
記録し、源文書を保持し、調整を説明し、同意したレ
ビューヤーが結果を確認させます。貢献した人々をク

00:18:25.591 --> 00:18:31.415
レジットし、関与した部門の数で金を倍にすることな
くください。</PASSAGE>

00:18:32.090 --> 00:18:39.825
今日の原則はトレーサビリティです。誰かが報告され
た結果から始めて、承認されたアクション、実施され

00:18:39.825 --> 00:18:43.455
た変更、それを支える財務記録に遡れるべきです。

00:18:43.890 --> 00:18:51.442
授業終了。宿題です。約 1 時間を取り、アクセス
権限のある記録を使用して、完了した技術変更を 1

00:18:51.442 --> 00:18:52.675
つ選びましょう。

00:18:53.280 --> 00:19:00.184
元の期待される利益、その基準値、および対象期間を
記録してください。実行された契約または承認された

00:19:00.184 --> 00:19:02.720
変更における有効な日付を見つけます。

00:19:03.280 --> 00:19:09.620
購入したものと実装されたものを比較し、次に影響を
受けた期間をカバーする請求書および関連するクレジ

00:19:09.620 --> 00:19:10.785
ットを検査します。

00:19:11.500 --> 00:19:17.855
変更の費用を記録する。元の見積もりと、あなたが支
持できる結果との間のすべての実質的な違いを説明す

00:19:17.855 --> 00:19:24.210
る。文書が欠落している場合は、その名称を挙げ、次
のアクションを割り当てる。最後に、何が検証され、

00:19:24.210 --> 00:19:30.305
何が未解決であるかを述べる 1 つの文で終わる。
そのページを財務パートナーに持っていくこと。

00:19:30.800 --> 00:19:34.247
F02、Validate Benefits
and Report Business

00:19:34.247 --> 00:19:38.198
Outcomes を Operational
ITAM Store で検索し、その手順を再現可

00:19:38.198 --> 00:19:42.065
能にするためのヘルプが欲しい場合は、そちらをご覧
ください。リンクはショーノートにあります。

00:19:42.880 --> 00:19:47.948
The Decision Table にある自然
な次の質問は、結果を検証した後、何がそれを再検討

00:19:47.948 --> 00:19:53.015
させることになるでしょうか。その質問を完了した記
録の横に置いておいてください。私たちは、ビジネス

00:19:53.015 --> 00:19:56.325
の変化に伴い判断がどのように維持されるかについて
再び触れます。

00:19:56.835 --> 00:20:03.022
ケースファイルは開かれています。1 つの状況、1
ページ。制約、あなたがやったこと、そして起きたこ

00:20:03.022 --> 00:20:09.209
と。ウェブサイトに送る前に会社名や機密情報を削除
してください。1 件の価値あるものを送ってくださ

00:20:09.209 --> 00:20:11.860
い、それに基づいてエピソードを作成します。

00:20:12.315 --> 00:20:16.777
私はビル・ヴァン・ノートです。これは
Operational ITAM Podcast

00:20:16.777 --> 00:20:21.862
です。比較を可視化して維持してください。請求書を
通じて変化を追跡してください。支持できる結果を報

00:20:21.862 --> 00:20:24.560
告してください。来週にまたお話しします。お元気で
。