먼저 대답: 경계가 쓰여지지 않고 가정되면 전환이 실패합니다.
계약서에 'IT 운영 관리'를 넣는 것만으로는 충분하지 않습니다. 안정적인 서비스는 시스템, 위치, 시간, 액세스, 종속성, 책임 및 수락 방법을 하나씩 정의합니다. 그렇지 않으면 동일한 사건이 클라이언트 팀, 서비스 제공업체 및 제품 공급업체 간에 이동하지만 모든 당사자는 해당 사건이 다른 곳에 속한다고 믿습니다. 가격이나 SLA 목표를 비교하기 전에 다음 12가지 질문에 답해 보세요.
1. 서비스 및 업무 우선순위
- 어떤 비즈니스 애플리케이션, 인프라 구성 요소, 사이트 및 사용자 그룹이 포함됩니까? 제품, 버전, 환경 및 비즈니스 소유자를 기록합니다.
- 수익, 생산 또는 법정 활동에 직접적인 영향을 미치는 서비스는 무엇입니까? 각 중요도 수준에 적절한 복구 목표와 에스컬레이션 경로가 있습니까?
- 명시적으로 제외되는 것은 무엇입니까? 생산 장비, OT, 건물 시설, 주요 개발 및 승인되지 않은 제3자 시스템은 협회의 범위에 들어가서는 안 됩니다.
2. 액세스, 자산 및 종속성
- 제공자는 실제로 어떤 모니터링, 로그, 관리 및 원격 액세스 권한을 받게 되며, 이를 승인하는 사람은 누구입니까?
- 자산 목록, 구성 관계, 인터페이스, 배치 프로세스, 백업 및 공급업체 계약이 완료되었습니까? 그렇지 않은 경우 제한된 검색 단계부터 시작하세요.
- 클라우드 제공업체, 소프트웨어 공급업체, 통신업체 및 기타 공급업체에는 무엇이 속합니까? 사례를 개설하고, 에스컬레이션하고, 변경 사항을 승인할 수 있는 사람은 누구입니까?
3. 운영 모델 및 적용 범위
- 지원 시간을 정의하는 시간대는 무엇입니까? 휴일, 연장 근무, 당직 보장, 현장 출석은 별도의 조건이 있나요?
- 사건, 문제, 변경 및 릴리스의 소유자는 누구입니까? 중대 사건을 선언하고, 전달하고, 종결하는 사람은 누구입니까?
- 티켓의 우선순위는 어떻게 정해지고 유효한 요청은 어떻게 구성되나요? 우선순위 레이블뿐만 아니라 비즈니스 영향 및 결정 기준을 정의합니다.
4. 지식, 사람 및 개선
- 어떤 문서, 녹음, 섀도잉 및 역시연이 필요합니까? 새로운 팀이 독립적으로 수행할 수 있고 퇴임하는 팀이 이를 확인한 경우에만 지식이 이전됩니다.
- 크리티컬 스킬은 한 사람에게만 의존하나요? 교체를 정의하고 보장 범위를 떠나며 제공자 보충을 수행합니다.
- 티켓 수 외에도 월별 검토에서 반복되는 문제, 근본 원인, 백로그 위험, 변경 성공 및 명명된 개선 조치를 다루나요?
실용적인 30일 전환 순서
- 1주차: 범위, 소유자, 액세스 조건, 자산 및 알려진 위험을 확인합니다. 누락된 정보 레지스터를 생성합니다.
- 2주차: 지식 세션, 티켓 분류, 에스컬레이션 매트릭스 및 운영 체크리스트를 완료합니다. 섀도우 크리티컬 작업.
- 3주차: 신입 팀이 감독 하에 실제 작업을 수행하면서 문서화 및 액세스 격차를 줄이도록 합니다.
- 4주차: 역시연을 실행하고, 해결되지 않은 위험을 검토하고 전환을 수락합니다. 허용된 범위만 안정적인 작업으로 이동합니다.
두 제안을 비교하는 방법
월별 가격과 응답 시간만 비교하지 마세요. 더 나은 테스트는 범위를 감사할 수 있는지, 소유권이 명명된 역할에 도달하는지, 종속성이 표시되는지, 전환 가정이 현실적인지, 변경 사항에 상업적 메커니즘이 있는지, 보고가 개선을 주도하는지 여부입니다. 경계가 모호한 값싼 제안은 첫 번째 주요 사건이 발생할 때까지 실제 비용을 미루는 경우가 많습니다.
Tech Alliance이(가) 시작될 수 있는 위치
시스템, 사이트, 종속성, 적용 범위 및 책임을 매핑하는 제한된 작업 검색부터 시작할 수 있습니다. 여기에서 공식적인 서비스 범위에 들어갈 수 있는 인프라, 애플리케이션, 사이트 지원 또는 공동 관리 활동을 확인합니다. 우리는 검증되지 않은 플랫폼, 24시간 보장 또는 무제한 티켓을 미리 약속하지 않습니다.