SLA는 고객에게 약속을 합니다. OLA는 내부 팀이 그 약속을 지킬 수 있도록 보장합니다. Trupeer를 사용하면 무료 운영 수준 합의서(OLA) 템플릿으로 시작해 브랜드 가이드라인에 맞게 커스터마이징하고, OLA를 모든 내부 팀을 공유 서비스 표준에 맞춰 정렬하는 비디오 워크스루로 전환하여 OLA 작성에 드는 시간을 몇 시간이나 절약할 수 있습니다.

운영 수준 합의서(OLA) 템플릿이란?

운영 수준 합의서(operational level agreement) 또는 OLA는 동일 조직 내 팀 간의 내부 합의로, 조직 밖의 누군가에게 한 약속을 뒷받침합니다. 서비스 데스크는 주요 장애에 대해 4시간 내 해결을 비즈니스에 약속합니다. 하지만 이 약속은 네트워크 팀, 애플리케이션 팀, 그리고 그 외 체인에 있는 모든 주체가 정해진 시간 안에 각자의 역할을 수행할 때만 성립합니다.

OLA는 이러한 내부 구성 요소를 문서로 적는 곳입니다. 계약이 아니며, 누구도 누구에게 비용을 지불하지 않습니다. 집행은 전적으로 관리 차원에서 이뤄지므로, 이것이 약점이자 계약으로는 할 수 없는 방식으로 솔직할 수 있는 이유가 됩니다.

운영 수준 합의서(OLA) 템플릿은 재사용 가능한 구조입니다. 당사자, 포함되는 서비스, 약속, 측정 항목, 검토(리뷰) 체계가 여기에 해당합니다. 이런 템플릿은 쉽게 찾을 수 있습니다. 대부분은 OLA를 완전히 준수하도록 작성할 수 있게 해주지만, 그럼에도 실패하는 OLA를 만들게 되며, 이 페이지의 나머지는 바로 그 이유에 대해 설명합니다.

OLA vs SLA: 각각이 실제로 무엇을 약속하나

이 계열에는 세 가지 문서가 있고, 이를 섞어 쓰면 실제로 문제가 발생합니다.

서비스 수준 합의서(service level agreement)는 고객 또는 비즈니스에 대한 약속입니다. 고객의 관점(보통 엔드투엔드)으로 작성되며, 전달(딜리버리) 체인 밖의 사람들에게 보고되는 문서입니다.

운영 수준 합의서(operational level agreement)는 내부 문서로, 동일 조직에 보고하는 팀 간의 합의입니다. SLA를 달성 가능하게 만들기 위해서만 존재하며, SLA에 필요하지 않은 약속은 절대 포함해서는 안 됩니다.

기반 계약(underpinning contract)은 동일 체인을 뒷받침하는 제3자, 벤더 또는 외주 제공업체와의 상업적 합의입니다. OLA와 달리 법적 효력이 있으며, 셋 중에서 보통 가장 유연성이 낮기 때문에 SLA 이후가 아니라 SLA 전에 합의해야 합니다.

실무적으로 중요한 결과는 ‘순서(시퀀싱) 규칙’입니다. 기반 계약을 먼저 합의한 다음, 그 계약이 허용하는 범위 내에서 SLA를 합의하고, 나머지를 채우는 OLA를 합의합니다. 반대로 순서를 바꾸어 진행하는 조직은, 벤더가 실제로 제공하기로 합의하지 않은 무언가를 비즈니스에 약속하는 일을 반복해서 겪습니다.

Trupeer에서 이 템플릿을 커스터마이즈하는 방법

1단계: 템플릿 섹션 열기

메인 내비게이션에서 템플릿(Templates) 섹션으로 이동하세요.

2단계: 템플릿 선택 후 열기

작업하려는 템플릿을 클릭해 열어보세요.

3단계: 템플릿 보기 확장

필요한 경우 템플릿 보기를 확장해 전체 레이아웃과 세부 정보를 더 명확히 확인하세요.

4단계: 템플릿 편집

편집(Edit)을 클릭해 선택한 템플릿을 수정하기 시작하세요.

에디터에서 다음을 할 수 있습니다:

• 새 섹션 추가

• 서식 규칙 정의 또는 업데이트

• 로고를 추가하고 위치 및 관련 설정을 조정

5단계: 커스터마이즈한 템플릿 저장

필요한 모든 변경을 마친 후 저장(Save)을 클릭해 업데이트된 템플릿을 본인 템플릿으로 저장하세요.

6단계: 미리보기 및 템플릿 미세 조정

커스터마이즈한 템플릿이 어떻게 보이는지 확인하려면 미리보기(Preview)를 여세요.

미리보기 화면에서 필요하다면 직접 계속 조정할 수 있으며, 템플릿이 원하는 그대로 정확히 표시되도록 할 수 있습니다.

운영 수준 합의서(OLA) 템플릿을 사용하면:

• 작성에 드는 시간 절약: OLA에 맞춰 구성된 구조로 빈 페이지를 건너뛰세요.

• 내부 팀 정렬: 내장 필드로 모든 팀이 각자의 책임을 알 수 있습니다.

• 브랜드 유지: Trupeer의 브랜드 키트를 사용해 로고, 글꼴, 색상을 적용하세요.

• 고객 SLA 보호: 강력한 OLA는 내부 인계가 외부 약속을 깨지 않도록 막아줍니다.

• 서비스 전반 표준화: 모든 내부 합의에 동일한 OLA 템플릿을 사용하세요.

• 글로벌 팀 대응: 한 번의 클릭으로 OLA를 65+개 언어로 번역하세요.

모든 팀이 OLA를 지키는데도 SLA가 여전히 위반되는 이유

이 패턴은 서비스 관리에서 가장 흔하며, 모순처럼 보입니다.

모든 팀이 초록색(정상)으로 보고합니다. 네트워크는 1시간 안에 응답합니다. 애플리케이션은 2시간 안에 해결합니다. 서비스 데스크는 30분 내에 분류(트리아지)합니다. 월간 OLA 준수 보고서는 읽기에도 편안합니다. 그런데도 고객 SLA는 주요 장애의 3분의 1에서 위반됩니다.

설명은 간단합니다. OLA는 팀 내부에서의 시간을 측정하고, SLA는 엔드투엔드 시간을 측정합니다. 이 두 숫자 사이의 차이는 ‘전달(Transit)’입니다. 즉, 재할당 후 대기열에 앉아 있다가 픽업되기를 기다리거나, 추가 정보를 위해 다시 반송되는 시간입니다.

그 시간은 누구의 것도 아닙니다. 어떤 팀의 OLA에도 없고, 어디에도 보고되지 않으며, 종종 모든 작업 시간을 합친 것보다 더 큽니다.

즉, 실패는 성과 문제라기보다 구조적인 문제입니다. 기존 숫자를 맞추도록 팀에 압박을 더한다고 해서 도움이 되지 않는 이유는, 이미 그 숫자를 맞추고 있기 때문입니다.

OLA는 ‘작업’이 아니라 ‘인계’를 지배한다

이 문제를 해결하는 재정의(reframe)는 작지만, 문서의 목적을 바꿉니다.

일반적인 방식으로 작성된 OLA는 팀이 자기 작업을 완료하는 데 걸리는 시간을 약속합니다. 팀이 통제할 수 있는 부분이므로 팀이 서명할 의지가 있는 부분이기도 합니다. 하지만 이 변수는 애초에 없었기 때문에, 합의해도 가장 쓸모가 적은 내용입니다.

잘 작성된 OLA는 팀들이 서로 사이의 ‘인터페이스(인계 지점)’를 약속하게 만듭니다. 티켓이 전달되기 전에 티켓에 무엇이 있어야 하는지, 수신 팀이 이를 픽업하는 데 얼마나 시간이 필요한지, 티켓이 불완전할 때 무슨 일이 일어나는지, 인계 공백 동안 티켓의 소유자가 누구인지가 여기에 해당합니다.

인계가 주제가 되면, 두 가지 누락 필드가 분명해집니다. 첫째는 ‘진입 기준(entry criteria)’으로, 수신 팀의 시계가 시작되기 전에 무엇이 사실이어야 하는지입니다. 둘째는 ‘전달 시간(transit time)’ 자체에 대한 명시적 배분입니다. 그래야 팀 사이의 공백이 아무도 책임지지 않는 시간이 아니라, 누군가의 숫자가 됩니다.

OLA 템플릿의 나머지는 모두 행정(관리)입니다. 이 두 가지가 바로 문서의 핵심입니다.

진입 기준: 시계가 시작되기 전에 무엇이 사실이어야 하나

멀티 팀 체인에서 가장 파괴적인 단일 행동은 ‘반송(bouncing)’입니다. 정보가 충분하지 않은 상태로 티켓이 도착하면 수신 팀이 되돌려 보내고, 그 팀의 시계가 다시 리셋됩니다.

반송은 수신 팀의 관점에서 완전히 합리적입니다. 그들은 티켓을 작업할 수 없고, 준수 여부는 자기 해결 시간으로 측정되므로, 반송은 양쪽을 모두 보호합니다. 또한 경과 시간의 상당 부분이 여기서 발생하지만, 팀을 따로 측정하는 모든 보고서에서는 보이지 않습니다.

진입 기준은 의무를 상류로 옮겨 해결합니다. 각 OLA 행에는 해당 팀이 작업을 수락하기 위해 채워져 있어야 하는 특정 필드가 나열됩니다. 네트워크 인계라면 예를 들어 장치 이름, 사이트 코드, 정확한 오류 문구, 최초 관측 시간, 그리고 다른 사용자의 영향 여부일 수 있습니다. 애플리케이션 인계라면 사용자, 트랜잭션 참조, 재현 단계, 그리고 스크린샷일 수 있습니다.

그러면 발송 팀의 약속 문구가 바뀝니다. ‘30분 내 트리아지’가 아니라 ‘30분 내 진입 기준을 충족하는 티켓 전달’이 됩니다. 같은 시계, 다른 의무이며, 이제 인센티브는 실제로 정보를 수집할 수 있는 팀에 놓이게 됩니다.

수신 팀은 거절할 권리를 유지해야 하며, 그 권리는 좁게 설정되어야 합니다. 즉, 지정된 진입 기준이 실제로 누락된 경우에만 거절이 유효해야 하고, 모든 거절은 사유와 함께 기록되어야 합니다. 기록은 반송을 보이지 않는 습관에서, 누군가가 설명해야 하는 숫자로 바꿉니다.

무료 운영 수준 합의서(OLA) 템플릿: 복사할 구조

여기서부터 복사하세요. 별표(*)가 표시된 필드는 표준 템플릿이 생략하는 항목입니다.

헤더. OLA 참조 및 버전. 당사자(Parties)로, 이름으로 표시된 두 팀. 이를 지원하는 SLA 또는 서비스. 각 측의 유효일, 검토일, 그리고 지정된 소유자.

범위(Scope). 포함되는 서비스, 시스템 또는 요청 유형, 그리고 무엇을 포함하지 않는지도 명시합니다.

서비스 시간. 각 당사자에 대한 커버리지(근무 외 시간 약정 포함)와 그 차이. 동일 체인 내 두 팀 간 서비스 시간이 맞지 않는 경우는 흔하지만 조용히 치명적인 공백이 됩니다.

약속 테이블(Commitments table). 요청 유형 또는 우선순위별로 한 행. 포함 항목: 트리거, 진입 기준, 응답 시간, 해결 또는 인계 시간, 배정된 전달 시간, 그리고 에스컬레이션 지점.

에스컬레이션(Escalation). 각 단계에서 누구에게 연락하는지, 어떤 경로로, 그리고 얼마나 지난 뒤인지. 근무 외 시간 경로도 포함하세요.

의존성(Dependencies). 이 팀이 다른 팀으로부터 필요한 것. 제3자와의 기반 계약이 있다면 그것도 포함하며, 산술을 확인할 수 있도록 각자의 시간도 함께 적어둡니다.

측정(Measurement). 무엇을, 어떤 시스템에서, 누가, 얼마나 자주 보고하는지. 응답 및 해결과 함께 반송률(bounce rate)도 포함하세요. 진입 기준이 실제로 작동하는지 보여주는 지표이기 때문입니다.

예외(Exceptions). 예를 들어 선언된 주요 장애(declared major incident) 기간이나 변경 동결(change freeze) 기간처럼, 약속이 적용되지 않는 합의된 상황.

검토(Review). 날짜와, 정기 주기 외 검토를 트리거하는 조건.

여기까지 복사하세요. 2~3페이지로 유지하세요. 두 번 읽어야 할 만큼 긴 OLA는 장애 상황에서 참고되지 않으며, 장애 상황에서야말로 중요한 순간입니다.

OLA가 실제로 SLA에 합산되는지 확인하는 방법

무엇이든 서명하기 전에 산술을 하세요. 15분이면 충분하며, 거의 보편적으로 생략됩니다. OLA는 서로 다른 날에 서로 다른 팀과 한 번에 하나씩 협의되기 때문입니다.

이걸 유용하게 만드는 두 가지 규칙이 있습니다. 전달 시간(Transit time)은 그 자체로 한 줄에 반드시 나타나야 합니다. 그것이 바로 핵심이기 때문입니다. 그리고 모든 체인에는 여유 시간(headroom)이 필요합니다. 체인이 SLA에 정확히 합산되면, 어떤 일이든 아주 조금만 잘못되어도 SLA 위반이 발생하기 때문입니다. 10~15% 정도가 합리적인 여유 범위입니다.

합계가 SLA를 초과한다면, 정직한 선택지는 세 가지뿐입니다. SLA를 재협상하거나, 어떤 방식으로든 팀의 시간을 줄여 합산이 가능하게 만들거나, 인계를 제거하는 것입니다. 할 수 없는 것은 ‘위반을 보장하는 OLA에 서명한 뒤’ 그에 맞춰 성과를 관리하는 일입니다. 그런데 놀랍게도 많은 서비스 데스크가 바로 그 입장에 있습니다.

작업보다 전달 시간이 더 길었던 리테일러

Rendlesham Group은 약 6,000명의 직원을 두고 여러 리테일 브랜드를 운영하며, 매장과 본사를 지원하는 내부 IT 서비스 데스크를 갖추고 있습니다.

비즈니스에 대한 P2 장애 SLA는 해결까지 4시간이었습니다. P2의 위반률은 2년 동안 약 38% 수준에 머물렀습니다. 모든 팀의 OLA 준수는 매달 보고됐고, 모든 팀은 초록색이었습니다.

누군가 마침내, 위반된 P2 장애 120건 각각의 모든 상태 변경에 타임스탬프를 찍었습니다.

중앙값 기준 총 경과 시간은 6시간 51분이었습니다. 그중 3시간 12분은 티켓을 실제로 작업하는 팀 내부 시간입니다. 3시간 39분은 전달 시간(transit)이었습니다. 즉, 재할당 후 대기열에 앉아 픽업되기를 기다리거나, 다시 반송된 시간입니다.

위반된 장애에서 경과 시간의 절반 이상은 아무도 소유하지 않았고, 어디에도 보고되지 않았습니다.

가장 큰 단일 기여 요인은 반송이었습니다. 120건 중 41건이 수신 팀에 의해 최소 한 번은 ‘정보가 충분하지 않다’는 이유로 되돌려 보내졌고, 각 반송은 중앙값 기준으로 1시간 20분을 추가했을 뿐 아니라 그 팀의 시계를 리셋했습니다. 가장 흔한 두 가지 이유는 오류 문구나 스크린샷이 첨부되지 않았고, 어떤 매장에 영향을 준 장애인지 확인이 없었다는 점이었습니다.

변경은 범위가 좁았습니다. 진입 기준은 모든 OLA 행에 작성했습니다. 서비스 데스크의 약속은 ‘30분 내 트리아지’에서 ‘30분 내 진입 기준을 충족하는 티켓 전달’로 다시 작성했습니다. 인계 1회당 전달 시간 15분을 배정하고, 진입 기준이 충족된 뒤에는 수신 팀에 대해 그 시간이 카운트되도록 했습니다. 그리고 모든 반송은 사유와 함께 기록했습니다.

이후 두 분기 동안 반송률은 P2의 34%에서 9%로 떨어졌습니다. 중앙값 기준 전달 시간은 3시간 39분에서 1시간 6분으로 감소했습니다. P2 위반률은 38%에서 11%로 내려갔습니다.

어떤 팀의 내부 해결 시간도 실질적으로 바뀌지 않았습니다. 더 빨리 일한 팀은 없었습니다. 아무도 소유하지 않던 시간이 단지 누군가의 몫으로 바뀐 것입니다.

운영 수준 합의서(OLA)를 단계별로 작성하는 방법

템플릿에서 시작하지 말고 SLA에서 시작하세요. 고객에게 엔드투엔드로 약속된 내용을, 시계 정의와 함께 적어두세요.

체인을 매핑하세요. 해당 유형의 요청을 순서대로 접하는 모든 팀(제3자가 있다면 그 포함)도 빠짐없이 나열합니다. 인계를 화살표가 아니라 각 단계로 그려보세요.

각 인계마다 수신 팀에 한 가지 질문을 하세요. “되돌아오지 않고 바로 작업을 시작하려면 티켓에 무엇이 필요하나요?” 이 답을 문서로 적어두면 그것이 진입 기준(entry criteria)입니다. 팀들은 이 질문에 쉽게, 정확하게 답할 수 있지만, 대부분은 이런 질문을 한 번도 받아본 적이 없습니다.

이제 위의 산술을 기준으로 시간을 합의하세요. 팀별로 따로따로가 아니라, 모두가 함께 있는 단일 대화로 진행하면 1시간이 걸리고 합산 문제를 완전히 예방할 수 있습니다.

전달 시간을 명시적으로 배분하고 누가 소유할지 결정하세요. 인계 1회당 15분은 합리적인 출발점이며, 수신 팀에 대해 카운트되어야 합니다.

측정 항목을 합의하세요. 반송률을 포함해, 어디에서 나오며 어떻게 측정되는지까지 정합니다. 도구로 생성할 수 없다면, 첫 번째 검토 때가 아니라 서명하기 전에 그 사실을 아는 것이 가치가 있습니다.

그다음 공식화하기 전에 한 분기 동안 실제로 운영해보세요. 첫 버전은 보통 한두 군데에서 틀리며, 서명이 존재하기 전에 수정하는 편이 훨씬 쉽습니다.

일반적인 OLA 실수와 각각이 초래하는 비용

체인이 아닌 팀만 측정하기. 모두 초록색인데 SLA는 위반됩니다. 가장 흔한 실패이며, 이 페이지의 주제입니다.

진입 기준이 없음. 반송은 수신 팀의 합리적인 방어 논리가 되고, 경과 시간은 보이지 않게 부풀어 오릅니다.

시간이 합산되지 않음. OLA 설정은 위반을 보장하지만, 누구도 지금까지 이를 합산해 본 적이 없습니다.

서비스 시간 불일치. 한 팀은 6시까지 커버하고 다음 팀은 5시까지 커버합니다. 5시 이후에 도착한 모든 건은 밤새 대기하게 되지만, 두 팀 모두 자기 근무 시간 안에 있다고 보기 때문에 어떤 보고서에도 드러나지 않습니다.

SLA 문구를 OLA에 그대로 복사하기. 패널티, 크레딧, 법적 문구는 여기에 들어갈 자리가 아니며, 이를 가져오면 팀들이 솔직하게 협의하기보다 방어적으로 협상하게 됩니다.

제3자와 함께 OLA 작성하기. 금전이 오간다면 그것은 기반 계약(underpinning contract)이며, 템플릿이 아니라 조달 및 법무의 개입이 필요합니다. 당사의 IT procurement policy template에는 승인 경로가 포함되어 있습니다.

서명하고 보관만 하기. 아무도 검토하지 않는 OLA는 약 1년 안에 더 이상 존재하지 않는 서비스 체인을 설명하게 됩니다.

OLA가 존재한 뒤에는 어떻게 관리하고 검토하나

구성 요소가 아니라 ‘체인’을 보고하세요. 중요한 것은 하나의 숫자입니다. SLA 대비 엔드투엔드 성과이며, OLA 지표는 이를 단독으로 두기보다 설명하기 위해 존재합니다.

분기별로 모두가 한자리에 모여 검토하세요. 양자(빌래터럴) 검토는 원래 문제를 재현합니다. 공백은 같은 대화에 함께 있지 않은 당사자들 사이에 존재하기 때문입니다.

세 가지를 보세요. 인계별 반송률(bounce rate)은 진입 기준이 어디에서 개선되어야 하는지 알려줍니다. 인계별 전달 시간(transit time)은 대기열이 어디에서 형성되는지 알려줍니다. 그리고 OLA가 설명하지 않는 경로로 진행된 장애의 비율은 문서가 현실에서 벗어났다는 신호입니다.

팀이 재조직될 때, 시스템이 팀 간에 이동할 때, 제3자가 체인에 새로 들어올 때, 또는 SLA가 변경될 때 정기 주기 외 검토를 트리거하세요. 이 네 가지는 연간 검토 주기가 가정하는 것보다 훨씬 더 자주 발생합니다.

OLA, SLA 또는 기반 계약: 무엇이 필요하신가요?

약속이 전달(딜리버리) 조직 밖의 누군가에게 하는 것이라면(외부 고객이든, 제공받는 내부 비즈니스 유닛이든) 그것은 SLA입니다.

같은 조직 내부의 두 팀 사이에서, 금전이 오가지 않는다면 그것은 OLA입니다.

상업적 계약에 따라 공급업체와 맺는 것이라면 기반 계약(underpinning contract)이며, 이 템플릿이 아니라 법무 및 조달이 필요합니다.

애매한 경우는 공유 서비스 센터 또는 차지백(chargeback) 모델을 가진 내부 팀입니다. 이는 OLA와 SLA 사이에 위치합니다. 실무적인 답은 OLA로 작성하고 패널티에 대한 문구는 모두 빼는 것입니다. 내부 패널티 체계는 방어적 행동을 안정적으로 만들어내고, 더 나쁜 서비스로 이어지기 때문입니다.

이 모든 것 위에 얹히는 고객을 위한 정의와 응답 문구는, 당사의 help desk response template과 ticket and resolution template에서 실제로 엔드 유저가 보는 레이어를 다룹니다.

Word 또는 Excel에서 OLA 템플릿을 받을 수 있나요?

계약서(agreement)용 Word는 범위, 예외, 검토 섹션이 문장(산문)으로 구성되어 있고 문서가 서명 승인을 위해 배포되기 때문입니다.

Excel은 특히 두 부분에 적합합니다. 약속 테이블(Commitments table)에서는 진입 기준, 시간, 전달 시간 배분을 정렬하고 확인할 수 있는 열(column)로 두고 싶을 때 사용합니다. 그리고 산술 시트(arithmetic sheet)에서는 각 체인이 SLA에 합산되는지 확인하고, 여유 시간이 없는 항목을 표시합니다. 두 번째 시트는 종종 협의하려던 내용 자체를 바꾸기 때문에, 먼저 만드는 것이 가치가 있습니다.

서명 버전은 소스에서 내보낸 PDF로 받으세요. 작업 버전은 편집 가능하게 유지하세요. 첫 분기 이후 실제 반송이 발생한 뒤 진입 기준을 조정해야 할 가능성이 높기 때문입니다.

OLA와 현실을 같은 속도로 유지하는 방법

OLA는 끊임없이 변하는 작업 체인을 설명합니다. 팀은 재조직되고, 시스템은 이동하며, 도구는 바뀌고, 문서는 누구도 마지막으로 업데이트하는 대상이 됩니다.

가장 빨리 오래된 정보가 되는 부분은 진입 기준(entry criteria)입니다. 진입 기준은 티켓에 무엇이 포함되어야 하는지를 설명하는데, 티켓에 무엇이 포함되어야 하는지는 현재 사용 중인 도구와 현재 프로세스가 실제로 어떻게 작동하는지에 달려 있기 때문입니다.

Trupeer AI는 기반 절차를 최신 상태로 유지하는 비용을 낮춰 도움을 줍니다. 트리아지 또는 인계 프로세스를 한 번 기록하면, 서비스 데스크가 따라 할 수 있고 어떤 정보가 수집되는지 명확히 보여주는 단계와 화면이 캡처된 문서 절차가 생성됩니다. 도구가 바뀌면 다시 ‘쓰기’가 아니라 ‘재기록’하세요.

기록하세요. 브랜딩하세요. 번역하세요. Trupeer하세요.

SOP creator는 OLA가 의존하는 절차를 다루며, 당사의 IT SOP template는 그중 무엇을 유지할 가치가 있는지 결정하는 방법을 다룹니다. Documentation은 합의서와 절차를 함께 유지하고, 설정 안내는 문서 템플릿 설정 가이드에 있습니다.

자주 묻는 질문

Word에서 무료 운영 수준 합의서(OLA) 템플릿이 있나요?

위 구조는 진입 기준과 표준 템플릿이 생략하는 전달 시간 배분 필드를 포함해 Word 또는 Google Docs에 그대로 붙여넣을 수 있습니다. 잠금 해제 다운로드도 없고, 양식도 없습니다. 약속 테이블은 스프레드시트에 유지하고 참조하세요. 이 부분은 정렬하고 합산해야 하기 때문입니다.

PDF에서 무료 운영 수준 합의서(OLA) 템플릿이 있나요?

당사자들이 합의한 뒤 서명 버전을 PDF로 내보내고, 작업 복사본은 편집 가능하게 유지하세요. 진입 기준은 거의 항상 첫 분기 이후에 조정이 필요합니다. 실제로 어떤 티켓이 반송되는지 확인할 수 있기 때문입니다.

Excel에서 무료 운영 수준 합의서(OLA) 템플릿이 있나요?

Excel은 약속 테이블과 산술 확인을 위한 가장 적합한 장소입니다. 인계 1회당 1행이 있는 시트와, SLA 대비 누적 합계를 두고 10% 미만의 여유 시간이 있는 체인을 표시합니다. 협의 전에 이 시트를 먼저 만들면, 협의되는 내용 자체가 바뀌는 경우가 많습니다.

운영 수준 합의서(OLA) PDF 예시는 어디에서 찾을 수 있나요?

여러 ITSM 벤더와 정부 기관이 문서 형태로 OLA 및 SLA 템플릿을 공개하며, 구조 측면에서는 충분히 합리적입니다. 콘텐츠가 아니라 섹션을 기준으로 읽어보세요. 어떤 공개 예시의 약속은 다른 조직의 체인이며, 그 시간은 그것을 뒷받침하기 위해 만들어진 SLA 밖에서는 의미가 없기 때문입니다.

운영 수준 합의서(OLA)는 누가 서명하나요?

각 측에 지정된 소유자(Owner)로, 서비스 관리 기능이 아니라 해당 팀의 딜리버리에 대해 책임지는 매니저여야 합니다. 서비스 관리만 서명하는 OLA는 희망사항입니다. 그 문서를 리소스로 뒷받침해야 하는 사람은 회의에 없었기 때문입니다.

서비스 데스크는 OLA를 몇 개나 필요로 하나요?

대부분의 팀이 예상하는 것보다 적습니다. 작업을 정기적으로 주고받는 팀 페어(pair)마다 1개씩 필요하며, 서비스마다 1개씩이 아니라 단일 약속 테이블에서 모든 요청 유형을 커버하는 방식이 좋습니다. 대략 12개를 넘어서면 유지보수가 제약이 되고, 문서는 검토 주기보다 더 빠르게 구식이 됩니다.

운영 수준 합의서(OLA)에 패널티가 있어야 하나요?

아니요. 집행할 법적 관계가 없고, 내부 패널티 체계는 안정적으로 방어적 행동을 만들어냅니다. 팀은 작업을 거절하고, 시계 시작 시점에 대해 다투며, 결과(outcome)보다 자기 숫자를 최적화합니다. 대신 체인을 엔드투엔드로 보고하세요. 그러면 누구도 벌금을 내지 않아도 공유된 결과가 눈에 보이게 됩니다.

OLA는 얼마나 자주 검토해야 하나요?

분기별로 모든 당사자가 참석한 상태에서 검토하고, 팀이 재조직될 때, 시스템이 팀 간에 이동할 때, 제3자가 체인에 들어올 때, 또는 기반이 되는 SLA가 변경될 때는 정기 주기 외 검토도 함께 진행하세요. 분기별 주기는 문서의 이탈(drift)을 잡아내고, 트리거는 문서가 하룻밤 사이에 현실과 맞지 않게 되는 변화를 포착합니다.