こんにちは皆様、Operational ITAM ポッドキャストへようこそ。私はビル・ヴァン・ノートです。今日は、アカウントに反映される前にプレゼンテーションに含まれた節約についてお話しします。 ライセンスは整理済みです。変更チケットは閉鎖されました。プロジェクト報告書では作業が完了していると記載されています。その後、財務部門からなぜサプライヤーがまだ旧額の請求を続けているのかと問われました。 誰もそれがプロジェクトの一部だとはもう思っていない。幸いなことに、請求書がみんなを再び集めた。 今日、The Decision Table：節約はどこへいったのか？ おはようございます、こんにちは、あるいはこんばんは。どこから聞いていただいてもおかまいありません。これは、企業の技術のつまらない機械を分かりやすくする番組です。コーヒーをどうぞ。 第 15 話で、更新の決定権があるのは誰かを示しました。その人物に実際に承認できる証拠、選択肢、条件を提供しました。 今日、承認後から始めます。結果を説明できるようになるまで、1 つの変更点に従って進めていきます。 FinOps Foundation のレポートおよび分析に関するガイドラインでは、実際の支出と意思決定の背後にある見積もりを比較することを求めています。これは有益な出発点です。実用的な課題は、何か問題が起きたたびに元の見積もりを変更することなく、それらの間の距離を説明することにあります。 私の意見、明確にラベル付けされた：元のビジネスケースはファイルに残すべきです。予測を更新するのは絶対に必要です。以前のバージョンも残しておき、組織が何が変更されたかを学ぶことができるようにしてください。そうでなければ、すべてのプロジェクトは最終的に、最後にそれをタイプした人の数値を正確に達成してしまいます。 架空の企業と作成されたソフトウェア契約を用います。これらはベンダー価格やクライアントの結果を示すものではなく、架空の米ドル額です。1 月から 12 月までの通年を踏襲します。 同社は、月額 20 ドルで 1000件のソフトウェアライセンスを契約し、月額 20000 ドルを支払います。これは 1 年間で 240000 ドルに相当します。 アサインメントのレビューにより、800 のソフトウェア席（ライセンスサブスクリプション）が継続的なビジネス要件を満たすことが確認されました。提案される削減は 200 のソフトウェア席で、1 月から開始されます。同じ単価であれば、これは月に 4000 ドル、または年間を通じて 48000 ドルを削減することになります。 それが私たちがもともと予測した総額です。総額とは、変更にかかるコストを引く前の金額を指します。また、これは条件付きであり、数量は商業的に削減可能であること、変更は 1 月に発効すること、そして残りのサービスが引き続き要件を満たすことが必要です。 資金の流れを追う前に、何を比較しているかを明確にしましょう。このケースでは、財務部門は既存のサービスを 1000 seats で、同じ 20 ドルのレートで維持することが、その年のサポート可能な代替案であると合意しています。私たちは現在の請求書と、それを支える変更のない利用可能な更新があります。 ビジネス要件はそのままです。削減は不要な割り当てを排除するもので、閉鎖された部門ではありません。比較の中に隠されている価格引き上げ、税金の変更、為替変動、またはサービスダウングレードはありません。 それらの仮定がこの例を分かりやすく保っています。ご自身の記録では、それぞれを確認する必要があります。 その同意された比較がベースラインです。それは、結果が何と比較されているかを示します。昨年の支払い、今年の予算、サプライヤーの開示見積もり、および将来の需要の予測は異なるベースラインです。同じ請求書でも、1 に対しては有利に見え、別のものに対しては不利に見えることがあります。 もし需要が本当に変化した場合、それを別に説明してください。おそらく会社がより多くの顧客をサービスしたり、別の部門を買収したりしているかもしれません。承認された比較を保ったまま、新しい範囲とその証拠を示した調整後のビューを表示してください。静かに出発点を書き換えて、その違いをパフォーマンスと呼ぶことはしないでください。 また、句点も必要です。月次削減を 12 で掛けたものがそのレートでの満 1 年を表しますが、それが 12 ヶ月の利益が発生したことを示すわけではありません。この区別がすぐに重要になるでしょう。 チーム間のハンドオフでその規律を失いやすい場所があります。未使用の割り当てを発見する人は機会を見積もるかもしれません。調達部門は交渉されたポジションを記録するかもしれません。デリバリー部門はアクションが完了であることをマークするかもしれません。 財務部門は認識された結果を報告する可能性があります。それらは有用なマイルストーンですが、独自の日付と証拠が必要です。すべて 4 つが「節約済み」とラベル付けされている場合、レポートは実際の作業の進捗状況についてあなたに何も教えてくれなくなります。 元の推定値を最新の見積もりと、現在までの実証結果と共に維持してください。もし元の推定が間違っていた場合は、簡潔な説明を残してください。合理的だったものの状況が変わった場合は、その変化を記録してください。次の意思決定を改善しようとしているので、議論する必要がないよう列を整えるのではなく、1 つの点に集中してください。 チームは予定より遅れて片付けを終了しました。1 月は引き続き 1000 の有料ライセンスサブスクリプション（ソフトウェア・シートの数）が維持されました。署名された変更は 2 月 1 日に発効します。 もう一つの違いがあります。サプライヤーはコミットメントを 850 シートにのみ削減することに同意します。これは、この架空の修正における最小値です。特定の出版者の規則に関する記述ではありません。 承認された所有者はそのオプションを受け入れ、チームは購入した 850 のライセンスサブスクリプションに対して割り当てられた 800 のソフトウェア座席を記録します。まだ支払いが行われている未割り当ての座席は 50 です。これは既に達成された別の節約ではなく、利用可能な容量です。 今、修正された予測を説明できます。1 月の計画された 4000 ドルの削減を失いました。残りの 11 ヶ月について、追加の 50 の有料ライセンスサブスクリプションは、元の目標より月額 1000 ドル高くなりました。また、元の予測の別の 11000 ドルはこの年で実現しません。 48000、タイミングによる 4000 を差し引き、保留されたコミットメントによる 11000 を差し引いた後、暦年における予想されるサブスクリプション削減額は 33000 ドルとなります。 それを確認する簡単な方法があります。2 月の請求額は、20000 から 17000 に減少する必要があります。11 ヶ月で 3000 ドル少ない、つまり 33000 ドルです。 運用上のクリーンアップは完了しても、商業的な成果が当初提案されたものより小さい場合があります。両方の記述は報告書に含まれるべきです。この作業を失敗と呼ぶことは削減を無視することになります。予測に 48000 を保持することは合意を無視することになります。 ここで証拠を接続します。承認された提案書、署名された修正条項、有効日、および割当記録を一緒に保管してください。 各々は異なる質問に答えます。我々が意図したのは何ですか？サプライヤーが合意したのは何ですか？その義務はいつ変更されましたか？チームが実際に実装したのは何ですか？ 利益記録および請求調査において参照可能な安定したレファレンスを与え、変更を反映させます。新しいプラットフォームは必要ありません。既存の更新記録内のレファレンスが十分であり、関係者が支援文書を見出せる場合です。 Microsoft のビジネスサブスクリプションライセンスの購入または削除に関するガイダンスは、ここで有用な区別を示しています。ユーザーからライセンスを割り当てる解除と、購入されたライセンスの削除とは別の手順です。削除のタイミングは請求計画と適用可能なウィンドウに依存します。料金が発生する時期を予測する前に、実際のサブスクリプションと契約を確認してください。 それは、私たちが考案した 850 シートの最小値とは別の実際の製品メカニズムです。割り当てがより少ないことを示すスクリーンショットは、割り当てについて何かを示しますが、それ自体で支払可能な数量が低いことを証明するものではありません。 アクセスを削除する前に、責任ある人々と相談して継続的なサービス、データ、および保持要件を確認してください。変更が承認されたスタッフが必要な業務を行うことを妨げる場合、請求額が安くなることは成功した結果ではありません。 我々の架空の会社も、外部の専門家による片付け完了のために 6000 ドルを支払います。この例では、それが唯一の追加実装コストであり、1 年間に発生し支払われ、財務部門はそれを利益比較に含めます。 サブスクリプション削減額 33000 ドルから、実装費用として差し引く 6000 ドルを控除し、年間予想ネットベネフィットは 27000 ドルとなります。 内部スタッフもその変更にかかり時間を費やします。その労力を記録してください。この場合、既存のキャパシティ内に収まり、追加の人件費や代替された資金化された作業が特定されていないため、追加の現金支払いを創出しているわけではありません。 もし重要な業務を代替した場合、何が代替されたかを述べ、評価してください。支払済の請求書だけが意思決定のコストの唯一のものではありません。 完了チェックもチケットステータスだけでは不十分です。サービスオーナーが、正しい割り当てが削除され、必要な人がアクセス権を保持し、購入数量が修正と一致していることを確認してください。割り当てを実際に制御するシステムから日付付きの記録を保存してください。自動化されたルールで明日にその割り当てを戻せる場合、作業を閉じる前にそのルールの所有者を特定してください。 サービスの規模に比例したチェックを行ってください。不活性なアカウントが削除されたからといって、アプリケーション全体を再テストする必要はありません。ただし、削除が行われたことと、それを不要と呼ぶ理由が妥当であることを知る必要があります。変更を要請するだけの証拠しかない場合、実装は検証されていません。 反論は妥当です：これは、わずかな削減に対して多くの確認作業のように聞こえます。努力は比例しているべきです。小さな単純な変更にはいくつかの関連レコードと短いレビューが必要になる場合がありますが、それでも有効日、実際の数量、そしてそこに至るためのコストを誰かが確立する必要があります。事実が単純であれば、計算は短くなります。 この時点で、見直された予測があります。まだ全年分の結果を確認していません。今必要なのは請求書であり、そこが私たちのケースがより興味深い点となります。 少し休憩しましょう。この作業の実用的な手順をお探しなら、Operational ITAM Store の「Validate Benefits and Report Business Outcomes」というものが 1 つあります。それは手順 F02 です。 それは、編集可能な HTML プロシージャ、SVG フローチャート、およびローカル採用と証拠チェックリストを含みます。初期入力には、合意されたベースライン、承認されたアクション、請求書または見積もり、実装コスト、通貨、期間、およびビジネス成果の証拠が含まれます。 これにより、財務部門との対話を構造化された場所から始めることができます。 組織に合わせて責任と測定決定を適応させます。 その手順は、財務チームが認識する内容を決定するものではなく、数字の背後にある記録を置き換えるものでもありません。 operationalitam.com/store のコンテンツを確認できます。これは私の有料リソースであり、購入することで番組をサポートします。今日の課題は、すでに持っている情報を使用しており、購入を必要としません。 また、podcast と実用的なリソースは operationalitam.com でご覧いただけます。もし誰かが「節約分はどこへいったのか」と繰り返し尋ねてくる場合、このエピソードを共有すると役立つかもしれません。 さて、インボイスに戻りましょう。 1 月は正しく 20000 ドルで請求されています。しかし、2 月と 3 月も 20000 ドルで請求されており、署名された修正書では 2 月以降は 17000 ドルである必要があります。4 月と 5 月は正しい 17000 ドルに達します。 5 月末日時点で、その 5 つの請求書の合計は 94000 ドルです。 私たちが変更しないベースラインは 5 ヶ月で 100000 です。現在の請求書には 6000 ドルの削減が表示されています。 その合意は異なる数値を支持しています。1 月は 20000 で、その後 4 ヶ月が 17000 の場合、合計は 88000 です。ベースラインと比較すると、5 月までには 12000 ドルの削減になるはずです。 6,000 ドルのギャップは、2 月に追加で請求された 3,000 ドルと、再び 3 月に請求されたものである。これは改正によって支持される請求上の紛争であり、契約価格のさらなる削減ではない。 この区別を明確に示してください。5月の報告締め時点では、記録済みの請求書で裏付けられる6000ドルと、係争中の追加の6000ドルを分けて示します。係争中の金額について組織の方針に基づく会計上の調整が必要かどうかは、財務部門が判断します。クレジットの発行が見込まれることは、実際に発行された証拠にはなりません。 調査は具体的であるべきです。サブスクリプション、法的実体、両方の請求書番号、関連するサービス期間、合意された数量、および改正の有効日特定してください。サプライヤーに 2 つの特定された差異を修正することを依頼してください。これは、「節約レポートが正しく見えない」というメッセージよりもはるかに解決しやすいです。 Microsoft の請求書ガイダンスは、請求日とその請求が対象とするサービス期間を区別しています。この区別はこの例を超えて重要です。今月届く文書は以前のカバー期間に関するものかもしれません。両方の日付を記録することで、遅れた修正が新しい運用改善と誤解されるのを防ぎます。 架空の事例において、サプライヤーは紛争を受け入れ、6 月に 6000 ドルのクレジットを発行します。これは 6 月の通常の 17000 ドルの請求額に適用され、その請求書に対する残額は 11000 ドルとなります。 6 月は 11,000 ドルのサービスにはなっていません。継続課金は依然として 17,000 です。6,000 は 2 月と 3 月の修正に関連しています。 そのクレジットを元の請求書に紐付け、適用時期を表示してください。財務が以前の実績期間で既に是正を認識している場合、その後の到着は当該項目を確定させます。節約レポートにおいて二重の利益を生み出してはいけません。 現金が節約されたと言いたい場合は、決済を確認してください。請求書、費用入力、貸方残高、および支払いは関連するレコードですが、それらは相互に交換可能ではありません。私たちが完了した架空の年度において、すべての関連する請求額と貸方は決済されます。その時点以前は、証拠が支持するラベルを使用してください。 今年を締めくくりましょう。7 月から 12 月にかけて、サブスクリプションは月額 17000 ドルで維持されます。さらに請求エラー、新しいソフトウェア seats、または追加のプロジェクトコストが発生しません。事業主は、継続的なサービスが合意された要件を満たしていることを確認しました。 クレジット後の最終サブスクリプション合計は 207000 ドルです。これを 1 月の 20000 に加えて、残りの 11 ヶ月を 17000 で計算することで確認できます。我々の 240000 ドルのベースラインに対して、削減額は 33000 です。 実装コストの 6,000 ドルを差し引きます。当社の示した仮定の下、暦年ベースのネットベネフィットは 27,000 ドルです。 その結果にはすでにクレジットが含まれています。それを再度加えると、利益が過大評価されます。それを除外すると、利益が過小評価されます。クレジットは請求記録を修正し、修正された義務と一致させます。 現在、元の 48000 がどうなったかを説明できます。4000 は変更が 1 ヶ月後に開始されたため失われました。11000 はコミットメントが 850 シートにしか低下しなかったため失われました。 変更の実施には 6000 が費やされました。残りの 27000 は完了したケースによって支えられています。 それは、他者が再現できる説明です。また、次のプロジェクトに有用な情報を提供します。有効日についてはさらに注意が必要です。最小コミットメントは、当初の予測が circulated される前にテストされていればよかったはずです。請求書は、技術作業が完了した後にもフォローアップが必要でした。 さて、誰かが年間化された削減を尋ねたとします。月額 3000 ドルの場合、継続的なサブスクリプションの削減額は、同じ範囲、レート、コミットメントが継続すると仮定して 12 ヶ月で 36000 となります。これはフォワードランレートです。これは今年の 33000 のグロス結果や 27000 のネット結果を置き換えるものではありません。 また、管理部門が放出された予算を別のサービスに支出する場合は、その配分を別々に報告してください。総技術予算は変わらない場合でも、元のサービスの費用はより低くなる可能性があります。同様に、総予算の低下があなたの特定の行動による削減であることを証明するものではありません。 Amazon Web Services は、ラベルがなぜ重要なのかを示す別の有用な例を提供します。その Savings Plans utilization ドキュメントは、同じ使用量に対する推定 On-Demand コストに対する総ネットセービングを定義しています。これは定義された比較です。 それは、組織の請求額が前月と比較してその分減少したことを意味するわけではありません。 Amazon Web Services、または一般的に AWS と呼ばれるものもまた、コミットメントのどの部分が使用されたかを報告します。ワークロードが削減された場合、そのコミットメントはどうなるか、および他の適格な利用がそれを吸収するかどうかを確認してください。 技術的な削減と財務的な削減は、異なる時期に発生する可能性があります。 答えは、使用状況、コミットメント、および請求証拠のすべてにあります。 当社のシートの例において、50 の未割り当ての有料シートは後に新しい採用者を収容する可能性があります。もしそうであれば、実際の再利用を記録してください。誰かが回避された購入を主張したい場合は、本来必要だった追加の購入を文書化し、財務部門と比較を合意してください。今年度の削減から生じる現金節約として、保持された容量とその後の再利用の両方を別々のものとしてカウントしないでください。 もしクレジットがいつまでも届かない場合、または記録が不完全な場合はどうすればよいでしょうか？項目を金額、証拠のギャップ、責任者、および次のアクションと共に開けておいてください。 サポートされた結果と未解決の金額を別々に報告してください。すべての問題が解決する前に、有用な結果を得ることができますが、レポートがその限界を明確にしている必要があります。 もしサービスが悪化したらどうなるでしょうか。その財務結果と並べてください。合意された指標を追跡してください：必要なアクセス、作業の完了、サポート需要、あるいはビジネスオーナーが設定した他のものなど。サブスクリプションの削減は、再作業や他での運用問題を消去するものではありません。FinOps Foundation の Quantify Business Value ガイドラインは、単なる金銭的コストだけでなく、サービスと組織のパフォーマンスを明確に含んでいます。 私の推奨は、他の人がその比較と証拠を追跡できる場合にのみ利益請求を閉鎖することです。範囲と期間を記録し、源文書を保持し、調整を説明し、同意したレビューヤーが結果を確認させます。貢献した人々をクレジットし、関与した部門の数で金を倍にすることなくください。 今日の原則はトレーサビリティです。誰かが報告された結果から始めて、承認されたアクション、実施された変更、それを支える財務記録に遡れるべきです。 授業終了。宿題です。約 1 時間を取り、アクセス権限のある記録を使用して、完了した技術変更を 1 つ選びましょう。 元の期待される利益、その基準値、および対象期間を記録してください。実行された契約または承認された変更における有効な日付を見つけます。 購入したものと実装されたものを比較し、次に影響を受けた期間をカバーする請求書および関連するクレジットを検査します。 変更の費用を記録する。元の見積もりと、あなたが支持できる結果との間のすべての実質的な違いを説明する。文書が欠落している場合は、その名称を挙げ、次のアクションを割り当てる。最後に、何が検証され、何が未解決であるかを述べる 1 つの文で終わる。そのページを財務パートナーに持っていくこと。 F02、Validate Benefits and Report Business Outcomes を Operational ITAM Store で検索し、その手順を再現可能にするためのヘルプが欲しい場合は、そちらをご覧ください。リンクはショーノートにあります。 The Decision Table にある自然な次の質問は、結果を検証した後、何がそれを再検討させることになるでしょうか。その質問を完了した記録の横に置いておいてください。私たちは、ビジネスの変化に伴い判断がどのように維持されるかについて再び触れます。 ケースファイルは開かれています。1 つの状況、1 ページ。制約、あなたがやったこと、そして起きたこと。ウェブサイトに送る前に会社名や機密情報を削除してください。1 件の価値あるものを送ってください、それに基づいてエピソードを作成します。 私はビル・ヴァン・ノートです。これは Operational ITAM Podcast です。比較を可視化して維持してください。請求書を通じて変化を追跡してください。支持できる結果を報告してください。来週にまたお話しします。お元気で。