WEBVTT

00:00:08.000 --> 00:00:12.729
안녕하세요 여러분, 오퍼레이셔널 ITAM
팟캐스트에 다시 오신 것을 환영합니다. 저는

00:00:12.729 --> 00:00:17.459
빌 반 노트입니다. 오늘 우리는 계정으로
들어가기 전에 프레젠테이션에 포함된 절감액을

00:00:17.459 --> 00:00:18.465
따라가고 있습니다.

00:00:19.135 --> 00:00:24.041
라이선스가 정리되었습니다. 변경 티켓이
닫혔습니다. 프로젝트 보고서에 따르면 작업이

00:00:24.041 --> 00:00:28.947
완료되었다고 합니다. 그런데 재무부가 여전히
공급업체가 이전 금액을 청구하는 이유를

00:00:28.947 --> 00:00:29.480
묻습니다.

00:00:30.075 --> 00:00:34.684
아무도 그것이 이제 프로젝트의 일부라고
생각하지 않습니다. 다행히도 송장 덕분에

00:00:34.684 --> 00:00:36.360
모두 다시 하나로 모였습니다.

00:00:37.075 --> 00:00:40.460
오늘, 결의 테이블: 절약은 어디로 갔는가?

00:00:41.095 --> 00:00:46.796
안녕하세요, 오후가 되셨나요, 아니면 저녁
시간대이신가요. 어디서 들으시는지 상관없이,

00:00:46.796 --> 00:00:52.260
기업 기술의 덜 화려한 기계 장치를 이해
가능하게 만드는 쇼입니다. 커피를 드세요.

00:00:52.935 --> 00:00:57.782
15 번째 에피소드에서 갱신 결정을 내릴 수
있는 사람을 확립했습니다. 우리는 그

00:00:57.782 --> 00:01:01.875
사람에게 실제로 승인할 수 있는 증거, 옵션
및 조건을 제공했습니다.

00:01:02.655 --> 00:01:07.796
오늘 우리는 승인 후부터 시작합니다. 우리는
결과를 설명할 때까지 1 개 변경 사항을

00:01:07.796 --> 00:01:08.780
따라갈 것입니다.

00:01:09.495 --> 00:01:14.775
FinOps Foundation 의 보고 및
분석 가이드라인은 실제 지출과 결정 뒤에

00:01:14.775 --> 00:01:20.055
있는 추정치를 비교하도록 요구합니다. 이는
유용한 시작점입니다. 실질적인 과제는 어떤

00:01:20.055 --> 00:01:24.998
문제가 발생하든 원래 추정치를 매번 변경하지
않으면서 그 사이의 거리를 설명하는

00:01:24.998 --> 00:01:25.560
것입니다.

00:01:26.155 --> 00:01:30.955
내 의견은 명확히 표시되어 있습니다: 원래
비즈니스 사례는 파일에 그대로 두어야

00:01:30.955 --> 00:01:36.300
합니다. 예상을 업데이트하는 것은 절대적으로
필요합니다. 조직이 무엇이 변경되었는지 배울

00:01:36.300 --> 00:01:41.646
수 있도록 이전 버전을 유지하십시오. 그렇지
않으면 모든 프로젝트가 결국 마지막에 입력한

00:01:41.646 --> 00:01:43.500
숫자와 정확히 일치하게 됩니다.

00:01:43.835 --> 00:01:48.919
가상의 회사와 발명된 소프트웨어 계약을
사용하겠습니다. 이는 공급업체 가격이나 고객

00:01:48.919 --> 00:01:54.334
결과를 나타내는 것이 아닌 가상의 미국 달러
금액입니다. 우리는 1 월부터 12 월까지의

00:01:54.334 --> 00:01:55.660
일력을 따를 것입니다.

00:01:56.190 --> 00:02:02.365
회사는 소프트웨어 라이선스 1000개에 대해
라이선스당 월 20달러를 지불합니다. 월

00:02:02.365 --> 00:02:06.175
20000달러, 1년 전체로는
240000달러입니다.

00:02:06.850 --> 00:02:11.350
작업 검토 결과 800 개의 소프트웨어
라이선스가 지속적인 비즈니스 요구 사항을

00:02:11.350 --> 00:02:15.952
충족할 수 있음이 확인되었습니다. 제안된
감축은 1 월부터 200 개의 라이선스로

00:02:15.952 --> 00:02:20.554
시작되며, 동일한 단가 기준으로는 매월
4000 달러를 절감하거나 연간 48000

00:02:20.554 --> 00:02:22.395
달러를 절감하는 효과가 있습니다.

00:02:22.775 --> 00:02:27.427
그것이 우리가 원래 산정했던 총
예상치입니다. 총 (Gross) 은 변경

00:02:27.427 --> 00:02:31.963
비용 전을 의미합니다. 또한 이는
조건부입니다: 수량은 상업적으로 감축

00:02:31.963 --> 00:02:37.313
가능해야 하며, 변경은 1 월에 발효되어야
하고, 남은 서비스는 여전히 요구 사항을

00:02:37.313 --> 00:02:38.360
충족해야 합니다.

00:02:39.135 --> 00:02:43.521
자본 흐름을 따르기 전에 비교하는 기준을
설정하겠습니다. 이 사례에서 재무팀은 기존

00:02:43.521 --> 00:02:48.193
서비스를 1000 개의 소프트웨어 라이선스와
동일한 20 달러 단가로 유지하는 것이 해당

00:02:48.193 --> 00:02:52.293
연도를 위한 지원 가능한 대안이라고
동의했습니다. 우리는 현재 송장과 변경되지

00:02:52.293 --> 00:02:55.440
않은 갱신 옵션을 보유하고 있어 이를
뒷받침할 수 있습니다.

00:02:55.800 --> 00:03:01.382
비즈니스 요구사항은 그대로 유지됩니다.
감소는 폐쇄된 부서를 제거하는 것이 아니라

00:03:01.382 --> 00:03:07.211
불필요한 할당을 제거합니다. 비교에 숨겨진
가격 인상, 세율 변경, 통화 변동, 또는

00:03:07.211 --> 00:03:09.320
서비스 다운그레이드는 없습니다.

00:03:10.020 --> 00:03:14.277
그 가정들이 이 예시를 읽기 쉽게
유지합니다. 본인의 기록에서는 각각 확인이

00:03:14.277 --> 00:03:14.885
필요합니다.

00:03:15.480 --> 00:03:21.612
이렇게 합의한 비교 기준이 기준선입니다.
결과를 무엇과 비교하는지 나타냅니다. 작년

00:03:21.612 --> 00:03:27.877
지출, 올해 예산, 공급업체의 최초 견적,
미래 수요 예측은 서로 다른 기준선입니다.

00:03:27.877 --> 00:03:34.275
동일한 청구서도 어느 기준선과 비교하느냐에
따라 유리하거나 불리하게 보일 수 있습니다.

00:03:34.870 --> 00:03:41.025
수요가 실제로 바뀌었다면 별도로 설명하세요.
고객이 늘었거나 다른 사업부를 인수했을 수

00:03:41.025 --> 00:03:46.666
있습니다. 승인된 비교는 유지하고, 새로운
범위와 증거를 제시하는 조정된 분석을

00:03:46.666 --> 00:03:51.795
추가하세요. 출발점을 조용히 바꾼 뒤 그
차이를 성과라고 부르지 마세요.

00:03:52.500 --> 00:03:58.092
기간도 필요합니다. 월 절감액에 12를
곱하면 해당 요율로 1년 동안의 금액을

00:03:58.092 --> 00:04:04.335
나타냅니다. 그것이 실제로 12개월의 편익이
발생했다는 증거는 아닙니다. 이 차이는 곧

00:04:04.335 --> 00:04:05.245
중요해집니다.

00:04:05.900 --> 00:04:12.153
팀 간 인계 과정에서 이런 원칙을 놓치기
쉽습니다. 미사용 할당을 발견한 사람은

00:04:12.153 --> 00:04:18.689
기회를 추정하고, 조달팀은 협상 결과를
기록하며, 실행팀은 작업을 완료로 표시할 수

00:04:18.689 --> 00:04:19.400
있습니다.

00:04:19.960 --> 00:04:25.979
재무팀은 인정된 결과를 보고할 수 있습니다.
모두 유용한 이정표지만 각각 날짜와 증거가

00:04:25.979 --> 00:04:31.998
필요합니다. 이 4가지를 모두 절감 완료로
표시하면 보고서는 실제 진행 상황을 보여주지

00:04:31.998 --> 00:04:32.625
못합니다.

00:04:33.240 --> 00:04:38.847
원래 추정치와 최신 예측 및 현재까지 확인된
결과를 함께 유지하세요. 원래 추정치가

00:04:38.847 --> 00:04:43.845
틀렸다면 짧은 설명을 남겨두세요.
합리적이었지만 상황이 변했다면 그 변화를

00:04:43.845 --> 00:04:48.964
문서화하세요. 여러분은 다음 결정을
개선하려고 하는 것이지, 아무도 이 점에

00:04:48.964 --> 00:04:52.865
대해 논의할 필요가 없도록 열을 정렬하려는
것이 아닙니다.

00:04:53.380 --> 00:04:58.002
팀이 계획보다 늦게 정리 작업을 마칩니다.
1 월에는 여전히 1000 개의 유료

00:04:58.002 --> 00:05:02.625
라이선스이 유지됩니다. 서명된 변경 사항은
2 월 1 일부터 효력을 발생합니다.

00:05:02.990 --> 00:05:07.985
또 다른 차이도 있습니다. 공급업체는 계약
수량을 850개 라이선스까지만 줄이는 데

00:05:07.985 --> 00:05:13.198
동의합니다. 이 가상의 수정 계약에서 정한
최소 수량입니다. 특정 소프트웨어 공급업체의

00:05:13.198 --> 00:05:14.935
규칙을 말하는 것이 아닙니다.

00:05:15.570 --> 00:05:21.089
인가된 소유자가 해당 옵션을 수락하고, 팀은
구매된 라이선스 850 개에 대해 할당된

00:05:21.089 --> 00:05:26.373
라이선스 800 개를 기록합니다. 여전히
지불 중인 할당되지 않은 라이선스은 50

00:05:26.373 --> 00:05:30.835
개입니다. 이는 이미 달성한 다른 절감
사항이 아닌 가용 용량입니다.

00:05:31.330 --> 00:05:36.420
이제 수정된 예상을 설명할 수 있습니다.
우리는 1 월에 계획된 4000 달러의

00:05:36.420 --> 00:05:41.741
감소를 잃었습니다. 나머지 11 개월 동안,
추가된 50 개의 유료 라이선스은 원래

00:05:41.741 --> 00:05:47.062
목표보다 매월 1000 달러 더 비용이
들었습니다. 원래 예상의 또 다른 11000

00:05:47.062 --> 00:05:49.375
달러는 올해 실현되지 않을 것입니다.

00:05:50.060 --> 00:05:56.360
48000에서 시행 시점 때문에 4000을
빼고, 유지된 계약 수량 때문에 11000을

00:05:56.360 --> 00:06:01.085
더 빼면, 해당 역년의 예상 구독료 절감액은
33000달러입니다.

00:06:01.780 --> 00:06:07.554
여기 더 간단한 확인 방법이 있습니다. 월별
청구서는 2 월에 20000 에서 17000

00:06:07.554 --> 00:06:12.738
으로 떨어질 것입니다. 11 개월 동안
3000 달러가 적습니다. 총 33000

00:06:12.738 --> 00:06:13.445
달러입니다.

00:06:13.830 --> 00:06:18.451
운영 정리 작업은 완료되었으나, 상업적
결과는 처음 제안된 것보다 작을 수

00:06:18.451 --> 00:06:23.071
있습니다. 두 문장은 모두 보고서에
포함되어야 합니다. 이 작업을 실패라고

00:06:23.071 --> 00:06:27.804
부르면 감소를 간과하게 되며, 예측에
48000 을 유지하면 합의를 간과하게

00:06:27.804 --> 00:06:28.255
됩니다.

00:06:28.845 --> 00:06:35.733
여기에서 증거를 연결합니다. 승인된 제안서,
서명된 수정안, 유효 날짜 및 할당 기록을

00:06:35.733 --> 00:06:37.025
함께 보관하세요.

00:06:37.565 --> 00:06:42.462
각각 다른 질문에 답합니다. 우리는 무엇을
의도했습니까? 공급업체가 동의한 것은

00:06:42.462 --> 00:06:47.470
무엇입니까? 그 의무는 언제 변경되었습니까?
팀이 실제로 구현한 것은 무엇입니까?

00:06:48.080 --> 00:06:53.257
변경 사항을 혜택 기록과 청구 조사에서
참조할 수 있는 안정적인 참조를 제공하세요.

00:06:53.257 --> 00:06:58.434
새로운 플랫폼이 필요하지 않습니다. 사람들이
지원 문서를 찾을 수 있다면 기존 갱신

00:06:58.434 --> 00:07:00.685
기록에 있는 참조만으로도 충분합니다.

00:07:01.400 --> 00:07:06.987
Microsoft 의 비즈니스 구독 라이선스
구매 또는 제거에 대한 지침은 여기서 유용한

00:07:06.987 --> 00:07:12.004
구분을 제시합니다. 사용자에게서 라이선스를
할당 해제하는 것과 구매한 라이선스를

00:07:12.004 --> 00:07:17.248
제거하는 것은 별도의 단계입니다. 제거
시기는 청구 방식과 적용 가능한 기간에 따라

00:07:17.248 --> 00:07:22.265
달라집니다. 요금이 부과될 시기를 예측하기
전에 실제 구독과 계약을 확인하세요.

00:07:22.720 --> 00:07:27.953
그것은 우리가 발명한 850 라이선스
최소한과는 별개의 실제 제품 메커니즘입니다.

00:07:27.953 --> 00:07:33.185
더 적은 할당량을 보여주는 스크린샷은
할당량에 대해 무엇을 증명합니다. 그것은 그

00:07:33.185 --> 00:07:36.325
자체로 낮은 지불 가능 수량을 증명하지
않습니다.

00:07:36.980 --> 00:07:41.808
접근 권한을 제거하기 전에 책임 있는
사람들과 서비스, 데이터 및 보관 요구사항이

00:07:41.808 --> 00:07:46.851
계속 유지되는지 확인하세요. 변경 사항으로
인해 승인된 직원이 필요한 업무를 수행하지

00:07:46.851 --> 00:07:50.285
못하게 되면 더 저렴한 청구서는 성공적인
결과가 아닙니다.

00:07:50.920 --> 00:07:57.373
우리의 가상의 회사도 정리를 완료하기 위해
외부 전문가에게 6000 달러를 지불합니다.

00:07:57.373 --> 00:08:02.750
이 예시에서 이는 유일한 추가 구현
비용이며, 해당 비용은 연중 발생하고

00:08:02.750 --> 00:08:06.245
지급되며 재무부는 이를 이익 비교에
포함합니다.

00:08:06.960 --> 00:08:13.151
구독 감액 33000 달러에서 구현 비용으로
6000 달러를 차감하면 연도별 예상

00:08:13.151 --> 00:08:15.765
순편익은 27000 달러가 됩니다.

00:08:16.400 --> 00:08:21.417
내부 직원들도 변경 작업에 시간을
할애합니다. 이 노력을 기록하십시오. 이

00:08:21.417 --> 00:08:26.801
경우 기존 용량 내에 포함되므로 추가
인건비나 대체된 자금 지원 작업이 식별되지

00:08:26.801 --> 00:08:29.860
않으므로 추가 현금 지급을 발명하지
않습니다.

00:08:30.380 --> 00:08:35.296
중요한 업무를 대체했다면, 대체된 것이
무엇인지 명시하고 평가하십시오. 지급된

00:08:35.296 --> 00:08:37.925
송장은 의사결정의 유일한 비용이 아닙니다.

00:08:38.500 --> 00:08:43.755
완료 확인은 티켓 상태보다 더 많은 것이
필요합니다. 서비스 소유자가 올바른 할당이

00:08:43.755 --> 00:08:48.782
제거되었는지, 필요한 사람들이 접근 권한을
유지했는지, 구매된 양이 수정 사항과

00:08:48.782 --> 00:08:54.037
일치하는지 확인해야 합니다. 할당을 실제로
제어하는 시스템에서 날짜가 기록된 기록을

00:08:54.037 --> 00:08:58.835
보관하세요. 자동화된 규칙이 내일 그
할당들을 다시 설정할 수 있다면 작업을

00:08:58.835 --> 00:09:01.805
종료하기 전에 해당 규칙의 소유자를
식별하세요.

00:09:02.460 --> 00:09:08.438
서비스에 비례하여 검사를 유지하세요. 휴면
계정이 제거되었기 때문에 전체 애플리케이션을

00:09:08.438 --> 00:09:14.415
다시 테스트할 필요는 없습니다. 다만 제거가
발생했음을 알 필요가 있으며, 불필요하다고

00:09:14.415 --> 00:09:20.518
판단한 이유가 타당함을 알아야 합니다. 변경
요청만 증거로 제시되는 경우 구현은 검증되지

00:09:20.518 --> 00:09:21.265
않았습니다.

00:09:21.980 --> 00:09:27.627
반론은 타당합니다: 이는 소소한 감소를 위해
많은 확인을 필요로 하는 것처럼 들립니다.

00:09:27.627 --> 00:09:33.040
노력은 비례해야 합니다. 작은, 단순한
변경에는 몇 개의 연결된 기록과 짧은 검토가

00:09:33.040 --> 00:09:38.452
필요할 수 있습니다. 하지만 여전히 유효
날짜, 실제 양, 그리고 도달하는 데 드는

00:09:38.452 --> 00:09:42.805
비용이 설정되어야 합니다. 사실들이 단순하면
계산은 더 짧아집니다.

00:09:43.420 --> 00:09:47.426
이 시점에서 우리는 수정된 예상을 가지고
있습니다. 아직 한 해의 결과를 완전히

00:09:47.426 --> 00:09:51.615
확인하지는 않았습니다. 이제 우리가 필요로
하는 것은 송장이며, 그것이 바로 우리의

00:09:51.615 --> 00:09:53.345
사례가 더 흥미로워지는 지점입니다.

00:09:58.000 --> 00:10:02.054
잠깐 쉬어볼까요? 이 작업에 대한 실용적인
절차를 원하신다면, Operational

00:10:02.054 --> 00:10:05.402
ITAM 스토어에는Validate
Benefits and Report

00:10:05.402 --> 00:10:09.720
Business Outcomes라는 1 가지
절차가 있습니다. 이는 절차 F02 입니다.

00:10:10.440 --> 00:10:17.048
그것은 편집 가능한 HTML 절차, SVG
흐름도 및 현지 채택과 증거 체크리스트를

00:10:17.048 --> 00:10:23.512
포함합니다. 시작 입력에는 합의된 기준선,
승인된 조치, 송장 또는 견적서, 구현

00:10:23.512 --> 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.440
절차는 재무팀이 인식할 내용을 결정하지
않으며, 해당 숫자 뒤의 기록을 대체하지

00:10:42.440 --> 00:10:43.045
않습니다.

00:10:43.650 --> 00:10:48.851
operationalitam.com/stor
e 에서 내용을 확인하실 수 있습니다. 이는

00:10:48.851 --> 00:10:53.734
저의 유료 리소스이며, 구매는 쇼를 지원해
줍니다. 오늘의 과제는 이미 가지고 있는

00:10:53.734 --> 00:10:56.175
정보를 사용하며 구매가 필요하지 않습니다.

00:10:56.745 --> 00:11:01.226
또한 운영 ITAM(operationalit
am.com) 에서 팟캐스트와 실용적인

00:11:01.226 --> 00:11:05.999
리소스를 찾을 수 있습니다. 누군가 절감액이
어디로 갔는지 계속 묻는다면, 이 에피소드를

00:11:05.999 --> 00:11:07.850
공유하는 것이 유용할 수 있습니다.

00:11:11.945 --> 00:11:13.550
좋습니다. 다시 송장입니다.

00:11:14.445 --> 00:11:19.285
1 월은 정확히 20000 달러로
청구됩니다. 그러나 2 월과 3 월도

00:11:19.285 --> 00:11:24.374
20000 달러로 청구되는데, 서명된
수정안은 2 월부터 17000 달러를

00:11:24.374 --> 00:11:29.090
요구합니다. 4 월과 5 월에는 정확한
17000 달러가 도착합니다.

00:11:29.565 --> 00:11:33.645
5 월 말에 그 5 장의 송장 총액은
94000 달러입니다.

00:11:34.285 --> 00:11:39.480
우리의 5 개월간 변경되지 않은 기준선은
100000 입니다. 현재 송장에는 6000

00:11:39.480 --> 00:11:41.470
달러의 감액이 표시되어 있습니다.

00:11:42.105 --> 00:11:47.268
계약은 다른 수치를 지지합니다. 1 월에
20000 달러, 그 다음 4 개월 동안

00:11:47.268 --> 00:11:51.972
17000 달러로 총계는 88000
달러입니다. 기준선과 비교하면 이는 5

00:11:51.972 --> 00:11:55.070
월까지 12000 달러의 감소를 의미해야
합니다.

00:11:55.645 --> 00:12:01.140
6,000 달러의 격차는 2 월에 추가로
부과된 3,000 달러와 다시 3 월에

00:12:01.140 --> 00:12:06.636
부과된 금액입니다. 이는 수정안으로
뒷받침되는 청구 분쟁이며, 계약 가격의 추가

00:12:06.636 --> 00:12:07.760
감축이 아닙니다.

00:12:08.495 --> 00:12:14.433
그 구분을 명확히 유지하세요. 5 월 보고
마감일에는 현재 기록된 송장에 의해 지원되는

00:12:14.433 --> 00:12:20.248
6000 과 이의 제기 중인 추가 6000
을 표시합니다. 재무부는 이의 제기 금액이

00:12:20.248 --> 00:12:25.567
조직 정책 하에서 회계 조정이 필요한지
여부를 결정합니다. 예상 크레딧은 해당

00:12:25.567 --> 00:12:28.660
크레딧이 도착했음을 증명하는 증거가
아닙니다.

00:12:29.345 --> 00:12:35.495
조사는 구체적이어야 합니다. 구독, 법적
실체, 두 개의 송장 번호, 관련 서비스

00:12:35.495 --> 00:12:41.644
기간, 합의된 수량 및 수정안의 유효일을
식별하십시오. 공급업체가 식별한 2 가지

00:12:41.644 --> 00:12:47.384
차이점을 수정하도록 요청하십시오. 이는
'절감 보고서가 이상해 보입니다'라는

00:12:47.384 --> 00:12:50.390
메시지로 해결하는 것보다 훨씬 쉽습니다.

00:12:51.085 --> 00:12:56.940
Microsoft의 청구서 지침은 청구 대상
서비스 기간과 청구서 날짜를 구분합니다. 이

00:12:56.940 --> 00:13:02.676
구분은 이 사례 밖에서도 중요합니다. 이번
달에 받은 문서가 이전 기간에 관한 것일 수

00:13:02.676 --> 00:13:08.293
있습니다. 늦게 이루어진 정정을 새로운 운영
개선으로 오인하지 않도록 두 날짜를 모두

00:13:08.293 --> 00:13:09.010
기록하세요.

00:13:09.645 --> 00:13:14.526
우리의 가상의 사례에서 공급자는 이의를
받아들여 6 월에 6000 달러 크레딧을

00:13:14.526 --> 00:13:19.075
발행합니다. 이는 6 월의 정상적인
17000 달러 청구액에 적용되어 해당

00:13:19.075 --> 00:13:22.070
송장에 대해 11000 달러가 지급되도록
합니다.

00:13:22.845 --> 00:13:27.166
6 월은 11,000 달러의 서비스가 되지
않았습니다. 반복되는 요금은 여전히

00:13:27.166 --> 00:13:31.588
17,000 달러이며, 6,000 달러는 2
월과 3 월을 수정하는 것과 관련이

00:13:31.588 --> 00:13:32.090
있습니다.

00:13:32.765 --> 00:13:38.332
그 크레딧을 원래 송장들과 연결하고 적용
시기를 표시하세요. 재무가 이미 이전 기간에

00:13:38.332 --> 00:13:43.899
수정을 인식했다면, 그 후의 도착은 해당
항목을 해결합니다. 이는 절감 보고서에서 두

00:13:43.899 --> 00:13:46.150
번째 이익을 생성해서는 안 됩니다.

00:13:46.725 --> 00:13:51.329
현금이 절약되었다고 말하려면 정산
(settlement) 을 확인하세요.

00:13:51.329 --> 00:13:56.623
송장, 비용 항목, 청구 조정 잔액, 그리고
지급은 관련 기록이지만 서로 대체할 수

00:13:56.623 --> 00:14:01.457
없습니다. 우리 가상의 완료된 연도에서 모든
관련 청구와 청구액 조정은 모두

00:14:01.457 --> 00:14:05.830
정산되었습니다. 그 시점 이전에는 증거가
지지하는 라벨을 사용하세요.

00:14:06.525 --> 00:14:11.511
연도를 마무리하겠습니다. 7 월부터 12
월까지 구독은 매월 17000 달러로

00:14:11.511 --> 00:14:16.730
유지됩니다. 추가 청구 오류, 새로운
라이선스 또는 추가 프로젝트 비용이 발생하지

00:14:16.730 --> 00:14:22.180
않습니다. 서비스 책임자는 지속되는 서비스가
합의된 요구 사항을 충족함을 확인합니다.

00:14:22.700 --> 00:14:29.593
청구액 조정을 반영한 최종 구독료 합계는
207000달러입니다. 1월의 20000에

00:14:29.593 --> 00:14:36.487
17000씩 11개월을 더해 확인할 수
있습니다. 기준선 240000달러와 비교하면

00:14:36.487 --> 00:14:38.585
절감액은 33000입니다.

00:14:38.880 --> 00:14:45.997
구현 비용 6,000 달러를 뺍니다. 명시된
가정 하에 연도별 순편익은 27,000

00:14:45.997 --> 00:14:46.925
달러입니다.

00:14:47.530 --> 00:14:53.666
청구액 조정은 이미 이 결과에 포함되어
있습니다. 다시 더하면 편익이 과대평가되고,

00:14:53.666 --> 00:14:59.268
제외하면 과소평가됩니다. 이 조정은 청구
기록을 수정된 계약상 의무에 맞추는

00:14:59.268 --> 00:14:59.935
것입니다.

00:15:00.515 --> 00:15:05.695
이제 원래 48000 에 무슨 일이 있었는지
설명할 수 있습니다. 4000 은 변경이 한

00:15:05.695 --> 00:15:09.924
달 후에 시작되었기 때문에 손실되었고,
11000 은 약속이 850 개의

00:15:09.924 --> 00:15:13.095
라이선스으로만 줄어들 수 있었기 때문에
손실되었습니다.

00:15:13.695 --> 00:15:18.602
변경 사항을 구현하는 데 6000 이
지출되었습니다. 나머지 27000 은 완료된

00:15:18.602 --> 00:15:20.020
사례에 의해 지원됩니다.

00:15:20.695 --> 00:15:25.690
그것은 다른 사람이 재현할 수 있는
설명입니다. 또한 다음 프로젝트에 유용한

00:15:25.690 --> 00:15:31.041
정보를 제공합니다. 유효 날짜는 더 많은
주의를 필요로 했습니다. 최소한의 약속은

00:15:31.041 --> 00:15:36.274
원래 예측가 배포되기 전에 테스트되었어야
합니다. 기술 작업이 완료된 후 청구는

00:15:36.274 --> 00:15:37.820
추적을 필요로 했습니다.

00:15:38.515 --> 00:15:44.917
연간 환산 절감액을 묻는다고 가정해 봅시다.
월 3000달러라면 동일한 범위, 요율,

00:15:44.917 --> 00:15:50.775
계약 조건이 유지될 때 12개월의 반복
구독료 절감액은 36000입니다. 이는

00:15:50.775 --> 00:15:56.904
앞으로의 연간 환산 수치입니다. 올해의 비용
차감 전 절감액 33000이나 순편익

00:15:56.904 --> 00:15:59.220
27000을 대체하지 않습니다.

00:15:59.775 --> 00:16:04.604
관리자가 방출된 예산을 다른 서비스에
지출하는 경우 해당 할당을 별도로 보고해야

00:16:04.604 --> 00:16:09.544
합니다. 총 기술 예산이 유지되더라도 원래
서비스의 비용은 더 적을 수 있습니다.

00:16:09.544 --> 00:16:14.593
또한, 총 예산이 낮아진다고 해서 반드시
여러분의 특정 행동이 감소를 초래한 것임을

00:16:14.593 --> 00:16:15.800
증명하지는 않습니다.

00:16:16.435 --> 00:16:20.436
Amazon Web Services 는
라벨이 중요한 이유에 대한 또 다른 유용한

00:16:20.436 --> 00:16:23.904
예를 제공합니다. 해당 서비스의
Savings Plans 활용 문서에는

00:16:23.904 --> 00:16:28.083
동일한 사용량에 대한 추정 On-Demand
비용 대비 총 순편익 (total net

00:16:28.083 --> 00:16:31.195
savings) 이 정의되어 있습니다. 이는
명확한 비교입니다.

00:16:31.855 --> 00:16:36.200
그것은 조직의 청구가 지난달에 비해 그
금액만큼 감소했다는 것을 의미하지 않습니다.

00:16:36.915 --> 00:16:42.140
Amazon Web Services, 또는
일반적으로 AWS 라고 불리는 서비스도 해당

00:16:42.140 --> 00:16:47.147
커밋먼트가 얼마나 사용되었는지 보고합니다.
워크로드가 감소하면 해당 커밋먼트에 어떤

00:16:47.147 --> 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.626
라이선스 사례에서 구매했지만 할당하지 않은
50개 라이선스는 나중에 신규 입사자에게

00:17:06.626 --> 00:17:12.146
제공할 수 있습니다. 실제로 재사용했다면
기록하세요. 구매를 피했다고 주장하려면

00:17:12.146 --> 00:17:18.293
재사용하지 않았을 경우 필요했을 추가 구매를
문서화하고 재무팀과 비교 기준에 합의하세요.

00:17:18.293 --> 00:17:23.938
남은 수량과 그 수량의 재사용을 모두 올해
절감액과 별개의 현금 절감으로 계산하지

00:17:23.938 --> 00:17:24.440
마세요.

00:17:25.115 --> 00:17:30.819
청구액 조정이 결코 도착하지 않거나 기록이
불완전한 경우라면? 항목을 금액, 증거

00:17:30.819 --> 00:17:34.495
격차, 책임자, 그리고 다음 조치와 함께
열어두세요.

00:17:34.995 --> 00:17:39.921
지원된 결과와 해결되지 않은 금액을 별도로
보고하세요. 모든 문제가 해결되기 전에

00:17:39.921 --> 00:17:44.300
유용한 결과를 얻을 수 있지만, 보고서가 그
한계를 명확히 해야 합니다.

00:17:44.790 --> 00:17:49.947
서비스가 더 나빠진다면 어떻게 될까요? 그
결과를 재무적 성과와 함께 고려하세요.

00:17:49.947 --> 00:17:55.563
합의된 측정 항목을 추적하세요: 필요한 접근
권한, 작업 완료, 지원 수요 또는 사업자가

00:17:55.563 --> 00:18:00.377
설정한 다른 항목 등. 구독 감소는
재작업이나 다른 곳의 운영 문제를 지우지

00:18:00.377 --> 00:18:05.305
않습니다. FinOps Foundation
의 Quantify Business

00:18:05.305 --> 00:18:10.347
Value 가이드라인은 금전적 비용뿐만
아니라 서비스 및 조직 성과를 명시적으로

00:18:10.347 --> 00:18:11.035
포함합니다.

00:18:11.670 --> 00:18:17.330
다른 사람이 비교 기준과 증거를 따라갈 수
있을 때에만 편익 검증을 마무리하길

00:18:17.330 --> 00:18:23.385
권합니다. 범위와 기간을 기록하고 원본
자료를 보관하며 조정 사항을 설명하고 합의된

00:18:23.385 --> 00:18:29.572
검토자가 결과를 확인하게 하세요. 기여한
사람들의 공로는 인정하되, 참여 부서 수만큼

00:18:29.572 --> 00:18:31.415
금액을 늘려 잡지 마세요.

00:18:32.090 --> 00:18:37.649
오늘의 원칙은 추적 가능성입니다. 누군가는
보고된 결과에서 시작하여 승인된 조치,

00:18:37.649 --> 00:18:43.455
구현된 변경 사항 및 이를 뒷받침하는 재무
기록으로 거슬러 올라갈 수 있어야 합니다.

00:18:43.890 --> 00:18:49.366
수업 종료입니다. 숙제를 여기 둡니다. 약
한 시간을 확보하고 접근 권한이 있는 기록을

00:18:49.366 --> 00:18:52.675
사용하여 완료된 기술 변경 사항 1 개를
선택하세요.

00:18:53.280 --> 00:19:00.106
원래 예상되는 이득, 그 기준선 및 해당
기간을 기록하세요. 실행된 계약 또는 승인된

00:19:00.106 --> 00:19:02.720
변경에서 유효 날짜를 찾아보세요.

00:19:03.280 --> 00:19:09.794
구입한 것과 구현된 것을 비교한 다음, 해당
기간을 포괄하는 송장 및 관련 크레딧을

00:19:09.794 --> 00:19:10.785
검토하십시오.

00:19:11.500 --> 00:19:16.856
변경 비용 기록을 하십시오. 원래 추정치와
지원할 수 있는 결과 사이의 모든 주요

00:19:16.856 --> 00:19:21.855
차이점을 설명하십시오. 문서가 누락된 경우
해당 문서를 명시하고 다음 조치를

00:19:21.855 --> 00:19:27.568
지시하십시오. 검증된 내용과 해결되지 않은
사항을 서술하는 1 문장으로 마무리하십시오.

00:19:27.568 --> 00:19:30.305
그 페이지를 재무 파트너에게 가져가십시오.

00:19:30.800 --> 00:19:34.412
F02, Validate Benefits
and Report Business

00:19:34.412 --> 00:19:38.453
Outcomes 를 Operational
ITAM Store 에서 찾아서 해당 절차를

00:19:38.453 --> 00:19:42.065
반복 가능하게 만드는 데 도움이 되도록
하세요. 링크는 쇼 노트에 있습니다.

00:19:42.880 --> 00:19:47.586
The Decision Table 에서 다음
질문은 자연스럽게 발생합니다: 결과를 확인한

00:19:47.586 --> 00:19:51.811
후, 이를 다시 검토하게 만드는 요인은
무엇일까요? 이 질문을 완료된 기록 옆에

00:19:51.811 --> 00:19:55.845
두세요. 우리는 비즈니스가 변화함에 따라
결정이 어떻게 견디는지 다시 돌아올

00:19:55.845 --> 00:19:56.325
것입니다.

00:19:56.835 --> 00:20:02.217
사례 파일은 열려 있습니다. 1 상황, 1
페이지. 제약 조건, 수행한 작업 및 발생한

00:20:02.217 --> 00:20:07.487
결과입니다. 웹사이트를 통해 전송하기 전에
회사 이름과 민감한 정보를 제거하세요. 1

00:20:07.487 --> 00:20:11.860
가치 있는 작업을 보내주시면, 이를 바탕으로
에피소드를 제작하겠습니다.

00:20:12.315 --> 00:20:17.151
나는 빌 반 노트입니다. 이는 오퍼레이셔널
ITAM 팟캐스트입니다. 비교를 가시적으로

00:20:17.151 --> 00:20:21.061
유지하세요. 청구서를 통해 변화를
추적하세요. 지원할 수 있는 결과를

00:20:21.061 --> 00:20:24.560
보고하세요. 다음 주에 다시
말씀드리겠습니다. 안녕히 계세요.