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

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

3
00:00:17,459 --> 00:00:18,465
따라가고 있습니다.

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

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

6
00:00:28,947 --> 00:00:29,480
묻습니다.

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

8
00:00:34,684 --> 00:00:36,360
모두 다시 하나로 모였습니다.

9
00:00:37,075 --> 00:00:40,460
오늘, 결의 테이블: 절약은 어디로 갔는가?

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

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

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

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

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

15
00:01:07,796 --> 00:01:08,780
따라갈 것입니다.

16
00:01:09,495 --> 00:01:14,775
FinOps Foundation 의 보고 및
분석 가이드라인은 실제 지출과 결정 뒤에

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

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

19
00:01:24,998 --> 00:01:25,560
것입니다.

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

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

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

23
00:01:41,646 --> 00:01:43,500
숫자와 정확히 일치하게 됩니다.

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

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

26
00:01:54,334 --> 00:01:55,660
일력을 따를 것입니다.

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

28
00:02:02,365 --> 00:02:06,175
20000달러, 1년 전체로는
240000달러입니다.

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

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

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

32
00:02:20,554 --> 00:02:22,395
달러를 절감하는 효과가 있습니다.

33
00:02:22,775 --> 00:02:27,427
그것이 우리가 원래 산정했던 총
예상치입니다. 총 (Gross) 은 변경

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

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

36
00:02:37,313 --> 00:02:38,360
충족해야 합니다.

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

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

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

40
00:02:52,293 --> 00:02:55,440
않은 갱신 옵션을 보유하고 있어 이를
뒷받침할 수 있습니다.

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

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

43
00:03:07,211 --> 00:03:09,320
서비스 다운그레이드는 없습니다.

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

45
00:03:14,277 --> 00:03:14,885
필요합니다.

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

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

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

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

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

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

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

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

54
00:04:04,335 --> 00:04:05,245
중요해집니다.

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

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

57
00:04:18,689 --> 00:04:19,400
있습니다.

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

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

60
00:04:31,998 --> 00:04:32,625
못합니다.

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

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

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

64
00:04:48,964 --> 00:04:52,865
대해 논의할 필요가 없도록 열을 정렬하려는
것이 아닙니다.

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

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

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

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

69
00:05:13,198 --> 00:05:14,935
규칙을 말하는 것이 아닙니다.

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

71
00:05:21,089 --> 00:05:26,373
라이선스 800 개를 기록합니다. 여전히
지불 중인 할당되지 않은 라이선스은 50

72
00:05:26,373 --> 00:05:30,835
개입니다. 이는 이미 달성한 다른 절감
사항이 아닌 가용 용량입니다.

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

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

75
00:05:41,741 --> 00:05:47,062
목표보다 매월 1000 달러 더 비용이
들었습니다. 원래 예상의 또 다른 11000

76
00:05:47,062 --> 00:05:49,375
달러는 올해 실현되지 않을 것입니다.

77
00:05:50,060 --> 00:05:56,360
48000에서 시행 시점 때문에 4000을
빼고, 유지된 계약 수량 때문에 11000을

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

79
00:06:01,780 --> 00:06:07,554
여기 더 간단한 확인 방법이 있습니다. 월별
청구서는 2 월에 20000 에서 17000

80
00:06:07,554 --> 00:06:12,738
으로 떨어질 것입니다. 11 개월 동안
3000 달러가 적습니다. 총 33000

81
00:06:12,738 --> 00:06:13,445
달러입니다.

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

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

84
00:06:23,071 --> 00:06:27,804
부르면 감소를 간과하게 되며, 예측에
48000 을 유지하면 합의를 간과하게

85
00:06:27,804 --> 00:06:28,255
됩니다.

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

87
00:06:35,733 --> 00:06:37,025
함께 보관하세요.

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

89
00:06:42,462 --> 00:06:47,470
무엇입니까? 그 의무는 언제 변경되었습니까?
팀이 실제로 구현한 것은 무엇입니까?

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

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

92
00:06:58,434 --> 00:07:00,685
기록에 있는 참조만으로도 충분합니다.

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

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

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

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

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

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

99
00:07:33,185 --> 00:07:36,325
자체로 낮은 지불 가능 수량을 증명하지
않습니다.

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

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

102
00:07:46,851 --> 00:07:50,285
못하게 되면 더 저렴한 청구서는 성공적인
결과가 아닙니다.

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

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

105
00:08:02,750 --> 00:08:06,245
지급되며 재무부는 이를 이익 비교에
포함합니다.

106
00:08:06,960 --> 00:08:13,151
구독 감액 33000 달러에서 구현 비용으로
6000 달러를 차감하면 연도별 예상

107
00:08:13,151 --> 00:08:15,765
순편익은 27000 달러가 됩니다.

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

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

110
00:08:26,801 --> 00:08:29,860
않으므로 추가 현금 지급을 발명하지
않습니다.

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

112
00:08:35,296 --> 00:08:37,925
송장은 의사결정의 유일한 비용이 아닙니다.

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

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

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

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

117
00:08:58,835 --> 00:09:01,805
종료하기 전에 해당 규칙의 소유자를
식별하세요.

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

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

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

121
00:09:20,518 --> 00:09:21,265
않았습니다.

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

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

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

125
00:09:38,452 --> 00:09:42,805
비용이 설정되어야 합니다. 사실들이 단순하면
계산은 더 짧아집니다.

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

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

128
00:09:51,615 --> 00:09:53,345
사례가 더 흥미로워지는 지점입니다.

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

130
00:10:02,054 --> 00:10:05,402
ITAM 스토어에는Validate
Benefits and Report

131
00:10:05,402 --> 00:10:09,720
Business Outcomes라는 1 가지
절차가 있습니다. 이는 절차 F02 입니다.

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

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

134
00:10:23,512 --> 00:10:27,965
비용, 통화, 기간 및 비즈니스 결과 증거가
포함됩니다.

135
00:10:28,560 --> 00:10:32,080
이는 재무팀과 대화를 시작할 수 있는
구조화된 장소를 제공합니다.

136
00:10:32,960 --> 00:10:36,380
조직에 맞게 책임과 측정 결정을 조정하세요.

137
00:10:37,120 --> 00:10:42,440
절차는 재무팀이 인식할 내용을 결정하지
않으며, 해당 숫자 뒤의 기록을 대체하지

138
00:10:42,440 --> 00:10:43,045
않습니다.

139
00:10:43,650 --> 00:10:48,851
operationalitam.com/stor
e 에서 내용을 확인하실 수 있습니다. 이는

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

141
00:10:53,734 --> 00:10:56,175
정보를 사용하며 구매가 필요하지 않습니다.

142
00:10:56,745 --> 00:11:01,226
또한 운영 ITAM(operationalit
am.com) 에서 팟캐스트와 실용적인

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

144
00:11:05,999 --> 00:11:07,850
공유하는 것이 유용할 수 있습니다.

145
00:11:11,945 --> 00:11:13,550
좋습니다. 다시 송장입니다.

146
00:11:14,445 --> 00:11:19,285
1 월은 정확히 20000 달러로
청구됩니다. 그러나 2 월과 3 월도

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

148
00:11:24,374 --> 00:11:29,090
요구합니다. 4 월과 5 월에는 정확한
17000 달러가 도착합니다.

149
00:11:29,565 --> 00:11:33,645
5 월 말에 그 5 장의 송장 총액은
94000 달러입니다.

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

151
00:11:39,480 --> 00:11:41,470
달러의 감액이 표시되어 있습니다.

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

153
00:11:47,268 --> 00:11:51,972
17000 달러로 총계는 88000
달러입니다. 기준선과 비교하면 이는 5

154
00:11:51,972 --> 00:11:55,070
월까지 12000 달러의 감소를 의미해야
합니다.

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

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

157
00:12:06,636 --> 00:12:07,760
감축이 아닙니다.

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

159
00:12:14,433 --> 00:12:20,248
6000 과 이의 제기 중인 추가 6000
을 표시합니다. 재무부는 이의 제기 금액이

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

161
00:12:25,567 --> 00:12:28,660
크레딧이 도착했음을 증명하는 증거가
아닙니다.

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

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

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

165
00:12:47,384 --> 00:12:50,390
메시지로 해결하는 것보다 훨씬 쉽습니다.

166
00:12:51,085 --> 00:12:56,940
Microsoft의 청구서 지침은 청구 대상
서비스 기간과 청구서 날짜를 구분합니다. 이

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

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

169
00:13:08,293 --> 00:13:09,010
기록하세요.

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

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

172
00:13:19,075 --> 00:13:22,070
송장에 대해 11000 달러가 지급되도록
합니다.

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

174
00:13:27,166 --> 00:13:31,588
17,000 달러이며, 6,000 달러는 2
월과 3 월을 수정하는 것과 관련이

175
00:13:31,588 --> 00:13:32,090
있습니다.

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

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

178
00:13:43,899 --> 00:13:46,150
번째 이익을 생성해서는 안 됩니다.

179
00:13:46,725 --> 00:13:51,329
현금이 절약되었다고 말하려면 정산
(settlement) 을 확인하세요.

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

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

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

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

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

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

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

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

188
00:14:36,487 --> 00:14:38,585
절감액은 33000입니다.

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

190
00:14:45,997 --> 00:14:46,925
달러입니다.

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

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

193
00:14:59,268 --> 00:14:59,935
것입니다.

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

195
00:15:05,695 --> 00:15:09,924
달 후에 시작되었기 때문에 손실되었고,
11000 은 약속이 850 개의

196
00:15:09,924 --> 00:15:13,095
라이선스으로만 줄어들 수 있었기 때문에
손실되었습니다.

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

198
00:15:18,602 --> 00:15:20,020
사례에 의해 지원됩니다.

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

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

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

202
00:15:36,274 --> 00:15:37,820
추적을 필요로 했습니다.

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

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

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

206
00:15:56,904 --> 00:15:59,220
27000을 대체하지 않습니다.

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

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

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

210
00:16:14,593 --> 00:16:15,800
증명하지는 않습니다.

211
00:16:16,435 --> 00:16:20,436
Amazon Web Services 는
라벨이 중요한 이유에 대한 또 다른 유용한

212
00:16:20,436 --> 00:16:23,904
예를 제공합니다. 해당 서비스의
Savings Plans 활용 문서에는

213
00:16:23,904 --> 00:16:28,083
동일한 사용량에 대한 추정 On-Demand
비용 대비 총 순편익 (total net

214
00:16:28,083 --> 00:16:31,195
savings) 이 정의되어 있습니다. 이는
명확한 비교입니다.

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

216
00:16:36,915 --> 00:16:42,140
Amazon Web Services, 또는
일반적으로 AWS 라고 불리는 서비스도 해당

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

218
00:16:47,147 --> 00:16:51,175
일이 발생하고 다른 자격 있는 사용량이 이를
흡수하는지 확인하세요.

219
00:16:51,775 --> 00:16:55,735
기술적 감축과 재무적 감축은 서로 다른
시기에 발생할 수 있습니다.

220
00:16:56,415 --> 00:17:00,140
정답은 사용량, 계약 및 청구 증거에 모두
있습니다.

221
00:17:00,855 --> 00:17:06,626
라이선스 사례에서 구매했지만 할당하지 않은
50개 라이선스는 나중에 신규 입사자에게

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

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

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

225
00:17:23,938 --> 00:17:24,440
마세요.

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

227
00:17:30,819 --> 00:17:34,495
격차, 책임자, 그리고 다음 조치와 함께
열어두세요.

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

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

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

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

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

233
00:18:00,377 --> 00:18:05,305
않습니다. FinOps Foundation
의 Quantify Business

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

235
00:18:10,347 --> 00:18:11,035
포함합니다.

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

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

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

239
00:18:29,572 --> 00:18:31,415
금액을 늘려 잡지 마세요.

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

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

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

243
00:18:49,366 --> 00:18:52,675
사용하여 완료된 기술 변경 사항 1 개를
선택하세요.

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

245
00:19:00,106 --> 00:19:02,720
변경에서 유효 날짜를 찾아보세요.

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

247
00:19:09,794 --> 00:19:10,785
검토하십시오.

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

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

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

251
00:19:27,568 --> 00:19:30,305
그 페이지를 재무 파트너에게 가져가십시오.

252
00:19:30,800 --> 00:19:34,412
F02, Validate Benefits
and Report Business

253
00:19:34,412 --> 00:19:38,453
Outcomes 를 Operational
ITAM Store 에서 찾아서 해당 절차를

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

255
00:19:42,880 --> 00:19:47,586
The Decision Table 에서 다음
질문은 자연스럽게 발생합니다: 결과를 확인한

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

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

258
00:19:55,845 --> 00:19:56,325
것입니다.

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

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

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

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

263
00:20:17,151 --> 00:20:21,061
유지하세요. 청구서를 통해 변화를
추적하세요. 지원할 수 있는 결과를

264
00:20:21,061 --> 00:20:24,560
보고하세요. 다음 주에 다시
말씀드리겠습니다. 안녕히 계세요.