업무 시스템 접근 권한
시스템, 요청 권한, 업무상 필요한 이유, 필요한 경우 만료일을 수집하세요. 검토자가 접근을 승인하고 권한이 있는 관리자가 실제 시스템에서 권한을 부여한 뒤 요청자에게 결과를 기록해 줍니다. 요청 앱의 상태 변경이 계정 생성을 뜻하지는 않습니다.
서비스 요청 프로세스 만들기
직원이 받아야 할 결과를 정의하고, 이를 실현하는 정보, 승인, 제공 작업, 완료 확인을 계획하세요.
예제 데이터로 살펴보세요. 필드, 보기, 워크플로를 팀에 맞게 조정할 수 있습니다.
제공하려는 서비스를 문서로 정리하세요
| 결정 | 정책 예시 | 흔히 하는 실수 |
|---|---|---|
| 결과 | 직원이 사용할 노트북과 업무 공간 준비 완료 | 구매 주문만 승인된 상태에서 요청이 완료되었다고 처리하지 마세요. |
| 필요한 정보 | 업무상 필요, 위치, 날짜, 장비 요구사항 | 가능한 모든 자산 필드가 아니라 제공 결정을 좌우하는 정보를 수집하세요. |
| 승인 | 지정된 장비 검토자 | 검토 결정은 제공을 허가하는 것이며 실제 전달을 증명하지는 않습니다. |
| 제공 작업 | 노트북 준비; 도킹 스테이션 전달 | 각 작업에 담당자와 완료 내역이 필요합니다. |
| 완료 확인 | 직원이 두 항목을 모두 받았는지 확인 | 미완료이거나 진행이 막힌 작업이 있으면 최종 완료 확인을 할 수 없습니다. |
필요한 결정을 중심으로 프로세스를 구성하세요
서비스 요청과 예상치 못한 문제 구분
“직무 변경에 필요한 노트북 제공”은 정해진 서비스입니다. “기존 노트북이 충전되지 않음”은 지원 문제입니다. 담당자가 겹칠 수는 있지만 입력 정보, 결정, 종료 조건은 다릅니다.
최종 결과의 담당자 지정
팀 사이의 불명확한 사항을 해결할 수 있는 서비스 담당자를 지정하세요. 작업 담당자는 각자 맡은 일을 수행하고, 서비스 담당자는 전체 요청과 약속한 결과에 대한 책임을 유지합니다.
결정에 필요한 경우에만 승인 요구
비용 지출, 접근 권한, 예외 적용에는 사람의 검토가 필요할 수 있습니다. 위험이 낮은 일상적인 제공은 그렇지 않을 수 있습니다. 실질적인 통제 없이 업무만 늦추는 형식적인 승인은 피하세요.
정보가 부족해도 보완할 수 있게 설계
검토자가 제출 건을 돌려보내고 부족한 정보를 설명하며 수정본을 받을 수 있어야 합니다. 원래 결정을 지우거나 필드만 조용히 수정해 거절을 다른 결과로 바꾸지 마세요.
제공 완료 기준 정의
필수 작업과 각 담당자가 기록할 증빙을 정하세요. 직원은 무엇의 완료를 확인하는지 알아야 합니다. 일부 작업의 완료가 아직 끝나지 않은 연관 작업을 가려서는 안 됩니다.
요청에 따라 처리 방식도 달라야 합니다
고장 난 회의실 디스플레이
서비스 카탈로그에서 신청하는 서비스가 아니라 예상치 못한 문제입니다. 회의실과 영향도를 수집하고 담당자를 배정한 뒤 진단과 대기를 기록하고 디스플레이가 다시 작동하는지 확인하세요. 이 과정에는 사내 헬프 데스크 예제를 사용하세요.
하나의 서비스를 처음부터 끝까지 먼저 도입하세요
서비스 하나와 현실적인 사례 몇 가지로 시작
일상적인 요청, 승인이 필요한 요청, 부분 제공, 수정 요청으로 돌려보낸 제출 건, 제공 완료 사례를 사용하세요. 실제 서비스 담당자에게 각 사례가 올바른 다음 조치로 이어지는지 확인하세요.
대시보드를 추가하기 전에 멈춘 업무 검토
부족한 정보, 담당자 없는 작업, 진행을 막는 요인, 완료 확인 지연을 살펴보세요. 담당자가 이를 해결하는 데 도움이 되는 화면을 만드세요. 건수만으로는 무엇을 해야 할지 알 수 없습니다.
범위를 명확히 하며 확장
필요한 입력과 제공 내용을 설명할 수 있을 때 다른 서비스를 추가하세요. 기밀 요청, 기술 설정, 전문적인 인시던트 대응은 그에 맞게 설계된 시스템과 권한 안에서 처리하세요.
서비스 요청 프로세스 계획
서비스 요청 관리는 누가 담당해야 하나요?
약속한 결과를 이해하고 팀 간 업무 인계를 조율할 수 있는 서비스 담당자를 지정하세요. 개별 제공 작업에도 각각 담당자가 필요합니다. 대시보드 관리와 서비스 책임은 다릅니다.
소프트웨어를 고르기 전에 정책을 설계해야 하나요?
최소한 서비스 결과, 필수 정보, 필요한 경우 승인자, 작업 담당자, 완료 확인 조건을 먼저 정하세요. 그다음 앱에서 해당 결정과 예외를 실무에 맞게 처리할 수 있는지 확인하세요.
정보가 부족한 요청은 어떻게 처리해야 하나요?
구체적인 질문과 함께 돌려보내고 이력을 보존하세요. 누가 정보를 보완해야 하며 언제 진행할 수 있는지 명확히 하세요. 처리 중인 대기열에서 빼기 위해 거절 상태로 바꾸지 마세요.
소규모 팀은 어떤 지표부터 봐야 하나요?
필요한 결정부터 생각하세요. 담당자 없는 요청, 진행이 막힌 작업, 완료 확인을 기다리는 제공 건은 무엇인가요? 시작, 종료, 업무 일정, 대기 정책을 정의한 뒤 제공 시간 지표를 추가하세요.
서비스 제공과 헬프 데스크 예제는 동기화된 하나의 앱인가요?
아니요. 정해진 서비스 제공과 직원의 예상치 못한 문제를 위한 별도 예제입니다. 서로 업무를 인계해야 한다면 자동 동기화를 가정하지 말고 관계와 담당자를 설계하세요.
팀의 다음 단계 선택
문서로 정한 서비스 정책을 실제 프로세스로 구현하세요
더 많은 서비스로 확장하기 전에 예제 요청과 제공 작업으로 팀의 업무 인계를 시험하세요.