빠른 속도의 팀을 위한 ITSM
ITSM 시스템 업그레이드 시즌에 받는 고통에 대한 치료법을 위한 탐색
제품 소유자가 기존 ITSM 시스템 업그레이드의 대안에 대해 알게 된 것.
저는 레거시 ITSM 시스템을 사용하여 여러 서비스 관리 관행을 위한 기능을 개발한 스크럼 팀의 제품 소유자였습니다. 작년의 마지막 스프린트가 끝날 때쯤 저희 팀은 새로운 기능을 배우고 실험할 수 있는 혁신 스프린트를 진행했습니다. 저는 혁신 스프린트를 통해 ITSM 시스템의 새 릴리스를 살펴봤습니다. 처음에 볼 때는 새로운 기능이 아주 많아 보였습니다. 하지만 자세히 읽어보니 새 기능은 이해 관계자에게 유용하지 않았으며 기술 부채가 더 많아질 만한 것이었습니다.
레거시 ITSM 시스템에 내재된 지원 문제가 있다는 것이 분명해지자 제게는 두 가지 선택지가 있다는 것을 깨달았습니다. 그 문제를 받아들이고 제 책상 서랍을 제산제와 진통제로 가득 채우든가 아니면 더 강력하고 유연한 솔루션을 찾아봐야 했습니다.
프로세스 담당자 및 기타 이해 관계자와의 수많은 회의가 있을 거라는 생각에 머리가 지끈거리기 시작했습니다. 새 릴리스의 내용을 설명해야 하고 개발 일정이 중단되고 결과적으로 이 모든 새로운 작업의 영향이 미미할 것이라는 생각만으로도 스트레스였습니다. 얼마나 많은 기능을 사용할 수 있는지와 상관없이 업그레이드 시즌의 프로세스는 그대로 지루하고 변함없이 생산성이 떨어졌습니다.
기존 ITSM 시스템 업그레이드의 고통
이 문제를 겪어보지 않은 분들은 제가 설명하는 것이 다소 과장이라고 생각하실 수도 있으므로 저희 팀의 업그레이드 프로세스 스냅샷을 아래에 첨부했습니다. 여기에 포함된 많은 작업을 릴리스 전에서 릴리스 단계, 릴리스 후까지 3단계에 걸쳐 11개의 주요 단계로 요약했습니다.
보기만 해도 피곤해지며 전체 그림을 담아내지도 못합니다. 업그레이드를 관리하는 팀은 조직 변경 관리 문제를 해결하는 데 상당한 시간 및 노력을 들입니다. 최종 사용자는 일년에 두 번씩 겪는 서비스 배포 중단에 불만스러워 하며 그만한 가치가 없다고 생각합니다.
예전에는 저희 팀의 업그레이드 문제는 별개라고 생각했지만 사용자 그룹 회의에 참석하고 블로그 글을 읽은 후 고통스러운 업그레이드 프로세스는 어디에든 있다는 것을 깨달았습니다. 어떤 고객은 업그레이드가 8주 이상 걸린다면서 팀의 생산성이 떨어진다고 불만을 드러냈습니다.
어떤 경우에는 조직에서 업그레이드를 쉽게 하기 위해 레거시 ITSM 시스템을 “재부팅”하기도 합니다. 예를 들어 고객은 여전히 2022년 3월 샌디에이고 릴리스에 포함된 ServiceNow의 Next Experience UI를 어떻게 사용하는지 알아내기 위해 노력하고 있습니다. 일부 기업 고객은 사용자에게 미치는 영향을 파악할 때까지 기능을 비활성화하도록 선택하기도 합니다.
해결책을 찾아보면서 파트너 서비스를 이용하여 업그레이드를 하고 시스템 수정을 포기하고 단편적인 자동 테스트 기능을 사용하는 것과 같은 임시 방편이 있다는 것을 알게 되었습니다. 하지만 이 선택지 중 어떤 것도 충분히 포괄적으로 보이지 않았고 어떤 것은 다른 쪽에서 더 많은 일을 유발했습니다.
ITSM 시스템에 대한 더 효과적인 접근 방식으로 문제를 해결
제게는 두 가지 선택지가 있었습니다. ITSM 시스템의 본질적인 문제를 받아들이고 제 책상 서랍을 제산제와 진통제로 가득 채우거나 아니면 더 강력하고 유연한 솔루션을 찾아보는 것이었습니다. 답답한 마음에 Google에서 분석가의 보고서를 읽고 ITSM 분야의 친구들과 상의한 결과 Atlassian의 ITSM 솔루션인 Jira Service Management를 찾게 되었습니다.
솔직히 우리의 문제를 완화시킬 수 있을지에 대해 회의적이었습니다. 엔터프라이즈 ITSM 시스템에서 수없이 많은 시간을 일해 왔으며 Jira Software도 몇 년 동안 사용했습니다. 그래서 Jira Service Management가 문제를 해결하지 못할 것이라고 확신했습니다.
Jira Service Management의 자산 기능을 간단히 살펴보니 데이터를 구성하고 로드하기가 쉬워 보였습니다. 그런 다음 프로젝트와 서비스 할당 그룹을 만들기 시작했습니다. 구성한 지 단 몇 시간 만에(게다가 모든 설명서를 살펴본 후) IT 자산, CI 및 주요 인시던트 기능이 포함된 작업 서비스 카탈로그와 서비스 데스크를 개발했습니다.
Jira Service Management는 “현재 위치에서 시작”과 같은 애자일 방법론 요소를 통합하고 즉시 사용할 수 있는 ITIL 관행을 제공합니다. Atlassian은 도구에 초점을 맞춘 솔루션보다는 팀 중심의 접근 방식을 채택한 점을 분명히 알 수 있었습니다.
Jira Service Management 업그레이드에 대한 Atlassian의 접근 방식 | 시스템 업그레이드에 대한 레거시 ITSM 공급업체 접근 방식 |
|---|---|
| 애자일 및 워터폴 비교 | |
| Atlassian은 유연성, 협업 및 효율성을 최적화하는 Jira Service Management 업그레이드에 대한 애자일 방법론을 따릅니다. | 시스템 업그레이드에 대한 레거시 ITSM 공급업체 접근 방식 레거시 ITSM 공급업체는 구조화되고 순차적인 릴리스에 초점을 맞춘 워터폴 접근 방식을 업그레이드에 사용합니다. |
| 일정 변경 vs. 필수 연간 업데이트 | |
| Jira Service Management 고객은 환경에서 원하는 릴리스 트랙을 설정하여 변경 속도를 제어할 수 있습니다. 지속적 제품은 제공되는 즉시 변경 사항과 기능을 받게 됩니다. 번들 제품은 매월 두 번째 화요일에 그룹 단위로 변경 사항을 받습니다. | 시스템 업그레이드에 대한 레거시 ITSM 공급업체 접근 방식 레거시 ITSM 공급업체는 보통 1년에 두 번 새로운 기능이 포함된 소프트웨어 릴리스를 제공합니다. |
| 지속적인 기능 릴리스 vs. 가능한 시점에 따라 버그 수정 | |
| Atlassian의 접근 방식은 더 짧고 예측 가능한 릴리스 주기, 품질이 높은 소규모의 코드 집합, 더 투명하고 반응성이 뛰어난 기능 제공을 통해 고객에게 개선된 비즈니스 가치를 제공합니다. | 시스템 업그레이드에 대한 레거시 ITSM 공급업체 접근 방식 레거시 ITSM 공급업체는 코드 패치와 핫픽스를 필요에 따라 또는 사용 가능한 대로 제공합니다. 일반적으로 이러한 패치와 핫픽스에는 버그 수정이 포함되지만 새로운 기능은 제공되지 않습니다. |
| 느슨하게 결합된 아키텍처 vs. 긴밀하게 결합된 코드 집합 | |
| Jira Service Management는 개별 컴포넌트가 서로 독립적으로 구축되는 느슨한 결합 아키텍처를 기반으로 합니다. 느슨하게 결합된 애플리케이션을 사용하면 팀이 독립적으로 배포 및 확장되는 기능을 개발할 수 있어 더 효율적인 코드 제공/업그레이드가 가능합니다. | 시스템 업그레이드에 대한 레거시 ITSM 공급업체 접근 방식 레거시 ITSM 시스템 아키텍처는 기능이 엄격하고 상호 의존적인 방식으로 긴밀하게 결합되어 있습니다. 하나의 컴포넌트를 변경하면 애플리케이션 전체에 걸쳐 더 많은 변경이 필요한 '도미노' 효과가 생겨 전반적으로 코드 수정이 많이 이루어지고 위험이 증가합니다. |
| 진정한 클라우드 제품 vs. 사일로화된 SaaS 제품 | |
| Jira Service Management는 Atlassian의 Cloud 플랫폼을 위해 설계 및 제작되었으므로 고객은 포함된 보안, 기본 제공되는 컴플라이언스, 최대 150개의 여러 인스턴스 및 간소화된 사용자별 라이선스로 확신을 갖고 확장할 수 있습니다. | 시스템 업그레이드에 대한 레거시 ITSM 공급업체 접근 방식 레거시 ITSM 시스템은 종종 온프레미스에서 실행되도록 설계되며 공급업체는 애플리케이션을 원격으로 호스팅하기만 하면 됩니다. 진정한 클라우드 솔루션이 아니며 진정한 클라우드 시스템과 동일한 확장, 업그레이드, 가격 책정 및 보안 등의 이점을 제공할 수 없습니다. |
ITSM 시스템 업그레이드에 대한 더 적절한 접근 방식
업그레이드의 경우 Atlassian은 새로운 기능이 제공되면 플랫폼과 제품에 기능을 원활하게 도입할 수 있도록 기술 발전을 계획합니다. Atlassian의 Cloud 로드맵은 공개되어 있으므로 고객은 앞으로 제공될 기능을 항상 확인할 수 있습니다. Jira Service Management의 Cloud 기반 시스템에서는 고객이 지속적으로 또는 일정에 따라 기능을 사용할 수 있습니다. 고객은 다음을 수행할 수 있습니다.
- 주간 릴리즈 정보를 구독하여 예정된 변경 사항에 대한 최신 정보 확인
- 프로덕션 단계에 들어가기 전에 기능 변경을 실험할 수 있는 분리된 환경(샌드박스라고도 함) 만들기
- 프로덕션 환경의 릴리스 트랙(지속적 및 번들)을 설정하여 변경 속도 제어
- 지속적 개선을 제공하는 소규모의 점진적 업데이트의 이점 활용
Jira Service Management는 느슨하게 결합된 코드 집합을 기반으로 하므로 코드 유연성/재사용성이 개선되고 애플리케이션 업그레이드가 더 효율적입니다.
우리 모두는 조직이 “더 열심히가 아니라, 더 스마트하게 일할 수 있도록” 디지털 혁신을 가속화하고 싶어 합니다. Jira Service Management의 점진적인 애자일 변경 및 개선 업그레이드 위주의 접근 방식을 사용하면 더 지속적이고 빠르며 중단 없는 방식으로 계속해서 릴리스를 검증하고 최종 사용자와 소통할 수 있다는 것을 알게 되었습니다.
디지털 혁신의 여정을 시작한다면 총 소유 비용뿐만 아니라 각 애플리케이션의 핵심 아키텍처 및 구현 접근 방식을 검토하는 것이 좋습니다. 달성하려는 비즈니스 이니셔티브를 고려하고 요구 사항을 충족하고 고객과의 모든 상호 작용에 가치를 더하는 시스템을 선택하세요.
ITSM을 위한 Atlassian 전체 가이드에서 서비스 관리에 대한 Atlassian의 접근 방식 대해 자세히 알아보세요.