Itil 버전 3 서비스 전략

ITIL v3 (정보 기술 인프라 라이브러리) / 서비스 전략.
서비스 전략은 ITIL 서비스 수명주기의 중심이며 원점입니다. 서비스에 대한 서비스 제공 업체 투자의 명확성 및 우선 순위에 대한 지침을 제공합니다. 보다 일반적으로 서비스 전략은 IT 조직이 장기적으로 개선되고 발전하도록 돕는 데 중점을 둡니다. 두 경우 모두 서비스 전략은 시장 중심 접근 방식에 크게 의존합니다.
IT와 비즈니스가 그들의 비전을 일치시키는 ITIL에 대한 견해입니다. 서비스 가치 정의, 비즈니스 사례 개발, 서비스 자산, 시장 분석 및 서비스 제공 업체 유형이 주요 내용으로 다루어집니다. 다루는 프로세스 목록 :
전략 관리 서비스 포트폴리오 관리 IT 재무 관리 수요 관리 비즈니스 관계 관리.
서비스 가치를 정의 할 책임이있는이 단계가 중요하기 때문에이보기의 중요성이 있습니다. 서비스를 정의 할 때 전략에 대한 4 가지 추이 인 Perspective, Position, Plan, Pattern을 염두에 두는 것이 중요합니다.
전략 활동은 다음과 같습니다.
시장 정의 전략적 제안 개발 전략적 자산 개발 실행 준비.
원리 편집.
서비스를 정의 할 때 전략가는 아래에 명시된 것처럼 원칙 목록을 염두에 두어야합니다.
값 생성 서비스 자산 서비스 제공자 유형 서비스 구조.
단계 편집.
전략 정의의 단계는 다음과 같습니다.
서비스 제공자 유형 편집.
서비스 제공 업체에는 다음 세 가지 유형이 있으며 여기에는 해당 서비스 제공 업체와 함께 제공되는 서비스가 포함될 수 있습니다.
내부 서비스 공급자 : 조직 내에 존재하며 고유 한 비즈니스 단위에만 서비스를 제공합니다. 공유 서비스 단위 : 조직 내에 있지만 둘 이상의 비즈니스 단위에 서비스를 제공합니다. 외부 서비스 공급자 : 외부 조직을 운영합니다.
서비스 전략에는 두 가지 프로세스가 있습니다. 서비스 포트폴리오 관리와 IT 재무 관리입니다 (아래 그림 참조).
서비스 포트폴리오 관리 편집.
서비스 포트폴리오 관리자가 소유하고있는이 서비스는 4 개의 하위 프로세스로 구성됩니다.
전략적 서비스 평가 : 시장에서 현재 서비스를 평가합니다. 서비스 전략 정의 : 서비스의 전반적인 목표를 정의하고 고객 및 고객 세분화를 정의합니다. 서비스 포트폴리오 업데이트 : 전략 정의에 따라 포트폴리오에서 제공되는 서비스를 조정합니다. 전략적 계획 : 서비스 전략을 실행하는 데 필요한 프로그램 및 프로젝트를 정의하고 시작하고 제어합니다. 수요 관리 : 서비스 전략.
IT 재무 관리 편집.
재무 관리자가 소유하고 있으며 다음 네 가지 하위 프로세스로 구성됩니다.
재무 관리 지원 : 재무 계획 데이터 및 비용 관리에 필요한 구조를 정의합니다. 재무 계획 : 다음 계획 기간에 필요한 재원을 결정합니다. 재무 분석 및보고 : 재무 비용 준비 및 서비스 수익성 분석 서비스 인보이스 : 프로비저닝 된 서비스에 대한 송장을 발행합니다.

ITIL 버전 3.
버전 2 (2000)에서 버전 3 (2007)으로의 ITIL 업그레이드에는 집중적 인 변경 사항이 포함되었습니다. 운영 중심의 프로세스 세트에서부터 성숙한 서비스 관리 실무 지침 세트에 초점이 변경되면서 몇 가지 핵심적인 변화가 필요했습니다.
가장 눈에 띄는 변화 중 하나는 "IT 인프라 라이브러리"에서 "ITIL 서비스 관리 실천"에 이르는 미묘한 이름 변경이었습니다. 이것은 그 자체로 ITIL의 진화를 반영한 ​​것으로, 더 넓은 범위를 암시합니다. 사실 버전 3에 대한 전체 접근 방식은 전체 론적이며, 가치 중심적이고 비즈니스 중심적입니다.
이 새로운 비전을 지원하기 위해 전체 볼륨 세트가 재구성되고 다시 게시되었습니다 ( '서비스 수명주기 형식'). ITIL은 이제 다음과 같이 구성됩니다.
지속적인 서비스 개선 특정 시장 / 기술적 맥락에서 일반적인 핵심 가이드 라인의 적용을 다루는 보완 타이틀에 의해 지원됩니다.
개념적으로, 위의 핵심 가이드는 ITIL '서비스 수명주기'를 중심으로 진행됩니다. 이 라이프 사이클은 전략, 설계, 전환, 운영 및 서비스 개선을 통해 라이프 사이클의 모든 영역을 통해 피드백을 지원하는 논리적 흐름을 목표로합니다.

Itil 버전 3 서비스 전략
이 모델은 센터에서 지속적인 서비스 개선 관행 N, 기술 및 프로세스 N에 의해 ​​제공되는 반복 루프에 존재하는 서비스 설계, 전환 및 운영에 대한 관행과 기술 N을 제공하는 서비스 전략 N을 보여줍니다.
사실 서비스 전략 및 지속적인 서비스 개선에서 프로세스, 기능 및 기술로 제시되는 것의 명확한 구별이 없습니다. 개념적으로 그들은 다른 세 가지 '수명주기'프로세스에서 눈에 띄며 전략, 개선 및 디자인의 전환, 운영 요소의 라이프 사이클 단계를 통해 호출됩니다.
다섯 개의 ITIL 버전 3 서적 (서비스 수명주기 단계)은 다음과 같습니다.
서비스 전략.
Chief Author - David Cannon, HP.
경제 기술 투자 수익률 분석 서비스 관리 방법론 R.
변경을위한 OGC 위임장, ITIL® 핵심 간행물 업데이트를위한 프로젝트 요구 사항 © The Stationery Office 2009 년 9 월, 3 페이지
서비스 설계.
Chief Author - Lou Hunnebeck, 제 3의 하늘.
기술 활동 요구 사항 엔지니어링 데이터 & amp; 정보 관리 응용 프로그램 관리.
서비스 전환.
수석 저자 - 스튜어트 랜스, HP.
프로세스 서비스 자산 및 구성 관리 R 유효성 검사 및 테스트 릴리스 및 배포 관리 변경 관리 평가 지식 관리 R.
활동 커뮤니케이션 관리 & amp; 헌신 관리기구 & amp; 이해 관계자 변경 이해 관계자 관리.
서비스 운영.
수석 저자 - ITSM Strategies Inc. 의 Randy Steinberg
활동 모니터링 및 IT 운영 제어 메인 프레임 관리 서버 관리 & amp; 지원 네트워크 관리 스토리지 & amp; 아카이브 데이터베이스 관리 디렉토리 서비스 관리 데스크탑 지원 미들웨어 관리 인터넷 / 웹 관리 기능 및 데이터 센터 관리 정보 보안 관리 & amp; 서비스 운영 운영 활동 개선 N.
지속적인 서비스 개선 (CSI)
Chief Author - Vernon Lloyd, FoxIT.
과학 수사대 (CSI)는 다른 서비스 관행과 똑같이 취급되어야합니다. 전면 계획, 교육 및 인식, 진행중인 스케줄링, 생성 된 역할, 소유권 할당 및 성공으로 확인 된 활동이 필요합니다. CSI는 정의 된 활동, 투입물, 산출물, 역할 및보고가있는 프로세스로 계획되고 계획되어야합니다.
방법 CSI R ROI for CSI R Assessment 벤치마킹 서비스 측정 및보고.
업데이트 내용.
변경 사항 처리.
v3 서비스 전략, 재무 관리는 v2 개념을 확장하여 주요 대상을 공공 기관에서 민간 부문 조직으로 전환합니다. v3 서비스 전략, 수요 관리는 ITIL v2의 용량 관리에서 다루어졌습니다. v2 Capacity Management의 분할은 설계 요소가 아닌 전략적 요구 관리로 v3 고려 사항을 강조합니다. v3 서비스 전략, 서비스 포트폴리오 관리는 ITIL v2 Application Management R에서 시작됩니다. ITIL v2에서는 서비스 수준 관리에 대해서만 설명했습니다. ITIL v3은 서비스 수준의 특성을 다루기 전에 서비스 포트폴리오를 개념화하고 식별해야 할 필요성을 인식하여 서비스를 근본적으로 다시 생각하는 것입니다. ITIL v2 서비스 레벨 관리는 몇 가지 별개의 프로세스로 나뉩니다. v3 SLM 프로세스는 IT 비즈니스 라인 (LOB)과의 관계 개발 및 유지 보수와 더 밀접하게 관련됩니다. 이 비즈니스를 수행하는 주요 방법은 LOB 및 외부 공급 업체를 포함한 서비스 체인 참여자 간의 서면 합의입니다. v3 서비스 카탈로그 관리 (Service Catalog Management)는 IT 서비스의 전용 카탈로그에 대한 필요성을 상세히 설명하고 신뢰할 수있는 정보로 최신 상태를 유지하는 절차를 소개합니다. V3는 고객 서비스 카탈로그 (SLA가 정의한 고객이 볼 수있는 서비스)와 기술 서비스 카탈로그 (SLA에 서비스를 제공하는 데 필요한 지원 / 공유 서비스, 구성 요소 및 CI)를 구분합니다. 공급 업체 관리는 Underpinning Contracts 관리에 반영되었습니다. R v2 Service Review 활동은 현재 ITIL v3 지속적 서비스 개선에 포함되어 있습니다. 서비스 관리 (Service Strategy)는 IT 서비스에 대한 사용자 / 비즈니스 요구 관리를 목표로합니다. 용량 관리 (서비스 설계)는 'v2 설명 가용성 및 가용성을 철저히 준수합니다. ITIL v3의 IT 서비스 연속성 관리 프로세스는 ITIL v2와 동일합니다. v3는 IT 보안 관리를 서비스 설계 핵심 볼륨의 일부로 취급하므로이 프로세스를 서비스 수명주기에보다 잘 통합 할 수 있습니다. v3 프로세스가 업데이트되어 새로운 보안 문제를 설명합니다. 변경 관리의 범위는 IT 운영에 영향을 미치는 서비스 변경을보다 명확하게 포함하도록 확장됩니다. 변경 관리와 마찬가지로 더 넓은 범위의 "서비스 자산"을 포함하도록 구성 관리의 범위가 확장됩니다. 따라서 서비스 자산 및 구성 관리 N에 대한 프로세스의 이름 변경. 구성 관리 데이터베이스 (CMDB)는 구성 관리 시스템 (CMS)에 의해 대체되었으며, 이는 중요한 시스템 지식 관리 시스템 (SKMS)보다 한 단계 정밀한 수준입니다. v2 릴리즈 관리는 다음 세 가지 프로세스로 나뉩니다. v3 릴리스 & amp; 배포 관리는 릴리스 계획 및 테스트 영역에서보다 많은 세부 사항을 제공합니다. 테스트 구성 요소는 별도의 v3 프로세스 (서비스 유효성 검사 및 테스트)로 분리 (또는 복제)되었습니다. 이 새로운 프로세스는 기존 및 제안 된 서비스와 IT 인프라의 맥락에서 서비스 변경의 성능을 결정할 수있는 일관되고 표준화 된 수단을 제공하기 위해 CMMI 유효성 검사 프로세스의 기초를 제공합니다. 이 새로운 프로세스는 CMMI 검증 프로세스 기반을 근본적으로 갖추고 있습니다. R v3은 조직의 기업 지식을 고유 한 프로세스 (서비스 전환 라이프 사이클 단계 내)로 캡처하는 데 대한 v2 참조를 수집합니다. 지식 관리 (KM)는 ITIL v2의 다양한 프로세스, 특히 애플리케이션 관리 및 "서비스 관리 구현 계획"N에서 다루어졌습니다. v3 사건 관리 (서비스 중단)와 서비스 요청 (사용자의 표준 요청 (예 : 암호 재설정))을 구별합니다. v3 사건 관리는 사건 탐지에서 다루어졌고 형성되었습니다 ITIL v2 ICT 인프라 관리의 차별화 된 프로세스 N. 인시던트 관리는 더 이상 서비스 요청을 수행하지 않습니다. 대신에 Request Fulfillment라는 새로운 프로세스가 있습니다. 긴급 상황을 처리하기위한 전용 프로세스가 있습니다. ( "주요 사건") 새로운 문제 프로세스 "주요 문제 검토"가 v3에 도입되어 주요 문제점의 해결 내역을 검토합니다. 그것의 근원을 결정하고 그것의 재발을 방지한다. v3 액세스 관리는 ITIL v2 보안 관리 N에서 다룹니다. v3 서비스 측정 및보고는 ITIL v2 서비스 레벨 관리에서 다루었습니다. R v3 7 단계 서비스 개선 프로세스는 ITIL v2 - 서비스 관리 구현을 계획하는 D에서 소개 된 기술 및 프로세스의 상세화입니다.
더 큰 상업화.
ITIL 저작 팀에 대한 검토는 대형 민간 기업 D의 의견을 보여줍니다. Hewlett-Packard에서 5 명, Pink Elephant에서 2 명, Accenture, Guillemont Rock, Connectsphere에서 한 명씩 있습니다. 공공 부문은 카네기 멜론 대학 (Carnegie Melon University) 의원과 정부 R에 뿌리를두고있는 수석 건축가 (Chief Architect)가 대표합니다. 민간 부문으로의 전환은 ITIL 구현을위한 ROI (Return on Investment) 시연에 대한 사용자의 우려를 반영하여 고의적으로 이루어졌습니다. 비즈니스 전략 및 지속적인 서비스 개선 섹션은이 요청을 반영합니다.
서비스 전략, 5.3 절.
보험 연장.
ITIL V3의 규모, 2009 년 4 월 29 일 IT 회의론.
공공 및 민간 부문 조직의 다소 다른 초점을 수용하고자하는 욕망은 프로세스 / 절차의 철저한 진화에 대한 진화하는 탐색에서 단지 하나의 요소 일뿐입니다. - 비즈니스 관리의 논리적 영역에 속하는 프로세스의 지속적인 포함은 27 개의 프로세스를 생성했습니다 (인용되는 대상과 프로세스로 인용되는 대상에 따라 수는 다릅니다).
그 중 하나는 v2가 지배적 인 시대에 소스를 점진적으로 포함시키는 것입니다. 서비스 지원 및 서비스 제공이 ITIL v2 (마스터 인증 커리큘럼)의 핵심 이었지만 비즈니스 관점, ICT 인프라 관리, 보안 관리, 계획 전달 서비스 관리 (구현) 및 애플리케이션 관리 작성 누락 된 요소로 인해 IT 운영의 전 세계를 포괄 할 수 있습니다. 모든 것을 포괄해야하고, 범위 작업에서 생성 된 족쇄를 늘리려면 필연적으로 실용주의와 모든 논리가 단순하고 잘 표현 된 틀을 압도하는 것처럼 보입니다.
서비스 라이프 사이클은 Design - Transition - Operate로 제한되어있을 때 견고한 프레임 워크이지만 v2 애드온 프로세스를 수용해야하는 필요성은 표현 된 모델과 잘 부합하는 부속 장치 (Service Strategy and Service Improvement)를 만들어 신뢰성과 유용성을 희생합니다. '우수 사례 도서관'의 조직 원리.
서비스 전략의 요소 중 상당수는 비즈니스 관리 서적에서 찾을 수 있습니다. 비즈니스 모범 사례를 구성합니다. IT가 비즈니스로 실행되어야하므로 이러한 원칙이 적용됩니다. 그러나 ITIL 베스트 프랙티스로 비즈니스 모범 사례를 다시 만드는 것이 필요합니까? 이것은 Project Management N에 대해서는 수행되지 않았습니다.
ICG는 ITIL 구현을위한 비즈니스 사례를 작성하는 방법을 보여줄 수있는 많은 요청으로 투자 수익 (ROI)에 대한 포괄적 인 적용 범위가 나타나 옹호자가 고위 경영진에게 필요성을 확신시킬 수 있음을 나타 냈습니다. 재무 원칙 및 ROI의 광범위한 적용 범위는 이러한 요구 사항을 충족시키기위한 것이었지만, 나는 그 표를 놓친다 고 생각합니다. 실제 요구 사항은 ITIL 구현을위한 ROI에 대한 중요한 사실 및 데이터에 대한 것이 었으며 ROI를 수행하는 방법에 대한 비공식적 인 논의가 아닙니다. 실제로 IT 부서의 재무 담당 임원 대다수는 재무 관리 및 / 또는 회계학 학위를 보유하고 있으며 이러한 기술에 정통합니다. 나는 그들이 지침을 위해 ITIL을 언급하는 것을 의심한다.
게다가, 자료의 제시에있어서의 철저한 필요성은 일관되게 따르지 않는다. 재무 관리 원칙이 필요한 경우 인적 자원 원칙이 제시되지 않는 이유는 무엇인지, 또는 앞서 언급 한 프로젝트 관리 원칙은 무엇입니까?
주제 재배치 - 서비스 라이프 사이클 프레임 워크.
이와는 대조적으로 ITIL v3은 서비스 전략, 서비스 설계, 서비스 전환, 서비스 운영 및 지속적인 서비스 개선이라는 5 개의 새로운 책으로 구성되었습니다. IT 서비스 관리를위한 비즈니스 중심 전략을 개발하는 방법 선택한 전략을 지원하도록 시스템을 설계하는 방법 새로 설계된 시스템을 프로덕션 환경으로 전환하는 방법 (사람 및 프로세스 측면에서도 마찬가지 임) 기술로서) 지속적인 방식으로 운영을 지원하는 방법 프로세스와 운영을 계속 개선하는 방법 R.
수명주기의 정의.
"원료 구입 또는 천연 자원의 생산에서 최종 폐기에 이르기까지 제품 시스템의 연속적이고 상호 연결된 단계." 아르 자형.
허용되는 전환에 의해 연결된 일련의 상태 라이프 사이클은 구성 항목, 문제점 보고서 및 변경 문서에 대한 승인 프로세스를 나타냅니다.
비즈니스 프로세스의 정의.
"하나 이상의 종류의 입력을 받아들이고 고객에게 가치있는 출력을 생성하는 활동의 모음입니다." 아르 자형.
".. 명확하게 정의 된 인도 물 또는 결과로 이어지는 사건에 대한 대응 단계의 일련의 실행."R.
이 두 가지 정의를 검토하면 "라이프 사이클"은 제품의 출생 - 사망 - 사망을 반복하는 일종의 높은 수준의 과정임을 입증해야합니다. ITIL 서비스 수명주기는 프로세스로 구성됩니다. 조직의 인력 및 프로젝트에서 사용하기위한 ITSM 절차의 우수 사례 라이브러리를 설명합니다. CMMI 용어로 조직 전체에서 배운 모범 사례와 교훈을 공유함으로써 조직 학습 및 프로세스 개선을 지원하는 프로세스 자산 라이브러리입니다. 이 일련의 표준 프로세스는 프로젝트별로 구성되어 조직 고유의 프로세스를 생성합니다. 이는 정의 된 프로세스의 구현뿐만 아니라 조정을 지원하기 위해 다른 비 IT 조직 프로세스 자산 (예 : 인적 자원)으로 보완 될 수 있습니다.
ITIL 최상 프로세스는 다른 프로세스 또는 프로세스 요소로 구성 될 수 있습니다. D. 프로세스 아키텍처는 프로세스의 프로세스 요소를 연결하는 규칙을 제공합니다. 조직의 표준 프로세스 집합에는 여러 프로세스 아키텍처가 포함될 수 있습니다.
위에 제시된 버전 3 개념 스키마에서 ITIL 프로세스는 두 가지 유형으로 나뉩니다. 자체 포함 된 프로세스 (고유 한 입력, 하위 프로세스 및 결과 집합)는 공통 단계로 된 상자 내에서 활동의 대기업입니다.
실제로 이러한 상자와 내용의 의미를 파악하는 것은 어렵습니다. 이는 ITIL 설명이 서비스 라이프 사이클을 상세히 설명하는 어려운 질문을 우회하여 라이프 사이클 아키텍처의 일관된 프리젠 테이션 (프로세스가 어떻게 상호 연결되는지)을 소책자 내에서 다양한 길이와 처리에 대한 설명을 제공하기 때문입니다. 실제로, 설명 된 많은 프로세스는 5 개의 각 소책자 중 2 개 이상에 요소가 있습니다. 하나의 책 또는 다른 책에서 그들의 배치는 거의 임의적으로 보인다 (예 : 용량, 사용 가능 및 연속성은 상호 의존성이 높고 각각 디자인, 전환 및 작동의 강력한 요소를 가짐).
서비스 개선 및 서비스 측정 프로세스가 CSI 활동이 시작되기 전까지는 작동하지 않는다는 것을 제안하는 일련의 별개의 프로세스로서의 "지속적인 개선"의 처리는 특히 문제가됩니다. CSI 프로세스는 운영 측면에서 관련이있을뿐 아니라 다른 네 가지 수명주기 프로세스 (즉, 전략, 설계, 전환, 운영) 중 많은 부분이 정의 된 성숙도 수준에서 더 관련이있는 하위 요소 (즉, 원자 프로세스 요소)를 가지고 있습니다 CMMI에 따르면). "우수 사례"로서의 ITIL 프로세스는 다른 프로세스 (즉, 낮은 성숙도를 달성하는 데 필요한 사전 요구 사항)가 존재한다고 가정합니다. CSI 프로세스로 서비스보고 및 서비스보고를 인용하면 ITIL v3는 CMI를 CMMI 성숙도 레벨 4 D - 양적 관리 방식으로 배치하는 것으로 보입니다.
서비스 전략 및 지속적인 서비스 개선은 다른 세 가지 수명주기 단계에서 수행해야합니다. ROI (Return on Investment) - 모든 라이프 사이클 단계에 똑같이 적용되는 금융 기법으로 이니셔티브가 실행 가능한지 여부를 결정합니다. 지식 관리는 모든 서비스 수명주기 단계와 관련이 없거나 무관 한 포괄적 인 프로세스입니다. "지식 관리는 전체 수명주기 프로세스는 모든 라이프 사이클 부문과 관련이 있으며 따라서 각 출판물의 관점에서 ITIL 전체에서 참조되며 다른 ITIL 간행물에서 어느 정도 다루어집니다 R "
오른쪽의 묘사는 서비스 수명주기를보다 체계적으로 보여줍니다. 이는 조직 변경 관리 프로세스 R과 거의 유사합니다. 서비스 수명주기의 핵심 요소입니다. 서비스 전환 (예 : 라이프 사이클의 "수명"요소는 프레임 워크의 중심에 있습니다.) 서비스 디자인은 입력 및 서비스 작업입니다. 또한 ICOM N 사용법에 따라 서비스 전략이이를 주도하는 기본 메커니즘입니다 RfC는 프로세스 시작을위한 기본 메커니즘이자 트리거 인 경우도 있습니다. 지속적인 서비스 향상은 메커니즘이기도합니다. 서비스 전략에는 모델을 제어하는 ​​컨트롤이 포함되어 있습니다. 최고 수준 서비스 수명주기 모델의 ICOM 렌더링은 두 번째 그래프.
서비스 수명주기의 최상위 노드에 대한 이러한 처리는 수명주기 프로세스를 분해하기위한 출발점으로 서비스 전환을 배치합니다. 이점이 있습니다 :
IT 조직이 운영의 중심에 주요 관심사를 두었습니다. - "알려진 신뢰할 수있는 환경"에 대한 변경은 IT 조직이 해결해야 할 첫 번째 사항 중 하나입니다. 제시된 서비스 수명주기 모델에서 두 개의 ITIL 영역을보다 정확하게 상황화합니다 프로세스 수명주기 프레임 워크에 쉽게 맞지 않습니다 (따라서 수많은 ITIL 라이프 사이클 모델 묘사의 중심과 주변에 배치).
정보 아키텍처.
CIs의 '완전한'재고 조사를 위해 인수에서 폐기까지 전체 수명주기 관리를 제공합니다. 비즈니스, 사례, 계획, 관리, 조직, 지식, 사람, 프로세스, 자본, 시스템, 애플리케이션, 정보, 인프라, 시설, 사람, 서비스 모델, 수용 기준, 유형 및 무형 자산, 소프트웨어, 요구 사항 및 계약, 미디어, 예비 부품. R은 "직원의 경험"을 포함 R은 "날씨, 사용자 수 및 행동, 조직의 성과 수치"에 대한 데이터 포함 R 공급 업체 및 파트너의 요구 사항, 능력 및 기대 R 사용자의 기술 수준 기록 R 모든 RFC, 인시던트, 문제 , 알려진 오류 및 릴리스 R 그룹화, CI 분류 및 정의 R 모든 CI의 고유 한 이름 지정 및 레이블 지정 R 이러한 모든 항목은 compoentn 분석 구조, 서비스 구성, 소유권, 종속성, 릴리스 패키징, 제품 구성, 지원 등 여러 유형의 관계로 관련됩니다 선적 서류 비치. R은 "스키마", "연결", "연결", "사용"및 "설치"R을 포함하여 스키마 맵핑, 조정 및 통합을 통해 통합 된 문서 저장소, 파일 저장소, CMDB, 이벤트 및 경고, 동기화, ETL 및 / 또는 마이닝 R은 쿼리 및 분석, 보고, 예측, 모델링 및 대시 보드를 위해이 통합 데이터에 대한 도구를 제공합니다. 모든 데이터의 기준선 및 스냅 샷을 얻습니다. 이 모든 데이터의 전체적인 검증 및 감사. 경영 정보 모델 R 데이터의 사용을 측정 R 보고서의 유용성을 평가 R. 등등.
IT Sceptive는 ITIL V2 CMDB가 어리석은 아이디어라고 생각했지만 모든 사람이 동의하지는 않았습니다. 분명히 큰 비율의 독자는 ITIL V3의 SKMS가 새로운 수준의 부조리에 빠져 있음을 알 수 있습니다.
Ian Clayton, IT 회의론자.
현재이 스펙트럼의 데이터를 다루는 Enterprise Resource Management 시스템은 없습니다. "격차"는 데이터 요소의 통합 부족, 서로 다른 책임 및 IT 운영 측면에서 잘못 정의 된 거버넌스로 인해 발생합니다. 그러나 찰스 베츠 (Charles Betz)에 따르면, 대기업들은이 상황을 바로 잡기 위해 진전을 이루고있다.
Charles T Betz, IT 회의론자.
SKMS는 물론 베스트 프랙티스 추상화, 즉 추상화인데, 그 이유는 "베스트 프랙티스"의 가장 기본적인 정의가 " 는 입력 작업 R (즉, 실생활 예제)을 제공하고 현재 운영 인스턴스가 없거나이를 달성 할 수있는 실질적인 방법이 아닌 이론적 인 프리젠 테이션이 아닌 최상의 작업으로부터 수집 및 에뮬레이션을 의미합니다. 그러나 이것은 ITIL의 전체 개념에 "모범 사례"모음으로 질문합니다.
베스트 프랙티스의 웹 정의는 다음과 같이 진행됩니다. "가장 좋은 방법은 경험과 연구를 통해 신뢰할 수있는 결과로 이어지는 것으로 입증 된 기술 또는 방법입니다." 여기서 "경험"이라는 단어를보십시오. Wikepedia는 또한 베스트 프랙티스는 다수의 사람들에게 시간이 지남에 따라 입증 된 반복 가능한 절차를 기반으로 작업을 수행하는 데있어 가장 효율적 (최소 노력)과 효과적인 (최상의 결과) 방법으로 정의 할 수 있습니다. '지식의 몸 (Body of Knowledge)'의 정의는 다음과 같습니다 : "주제에 관한 모든 가능한 지식, 또는 주제에 관한 모든 출판 된 자료를 수집합니다. 적어도 현재 ITIL이 무엇인지 명확히해야한다는 것이 중요하다고 생각합니다. "우수 (우수) 사례 수집"또는 "ITSM 지식 체계"
실제로, ITIL v3의 SKMS 또는 CMS에 대한 암시 또는 언급 된 정보 시스템 중 개념적으로 미숙하고 많은 작업이 필요합니다. 서비스 전환 - 자산 및 구성 관리 E에서 제공되는 묘사에 유의하고 이것을 지식 관리 묘사 E와 대조하십시오. "통합 CMDB"는 "SKMS"로 바뀌지 만 SKMS에 대한 설명은 통합 CMDB보다 훨씬 큽니다. 분명히 ITSM 베스트 프랙티스 데이터 관리를 제시 할 때 많은 작업이 취소됩니다.
공통 접근법 발산.
이 단점은 OGC에 의해 인정되었습니다. 2009 년 9 월, 새로운 버전 3 판, 5.1 절의 릴리스에 대한 업데이트에서는 다음을 포함하는 사업 범위를 정의합니다.
변경을위한 OGC 위임장, ITIL® 핵심 간행물 업데이트를위한 프로젝트 요구 사항 © The Stationery Office 2009 년 9 월, 3 페이지
재 작성을위한 범위를 벗어나는 것은 "사용을 채택한 조직이나 ITIL 자격을 취득한 사람이 현재 직장에서이 방법을 사용하고 있는지 여부에 관계없이"ITIL의 현재 사용을 무효로 할 것입니다. N.
추가 조음이 필요한 개념.
공급 체인 휴리스틱 확장.
정의 구성 요소 초점 - 개별 IT 기술 구성 요소의 성능, 사용 및 용량에 대한 관리, 제어 및 예측. 서비스 중심 - 실제 운영중인 IT 서비스 사용 및 작업 부하의 종단 간 성능 및 용량을 관리, 제어 및 예측합니다. 비즈니스 포커스 - 비즈니스 요구 사항 및 계획을 IT 서비스 및 IT 인프라 요구 사항으로 변환합니다.
비즈니스 프로세스 통합 : IT는 종종 상향식 통합을 사용하여 기술 및 응용 프로그램 구성 요소의 패치 워크를 결합합니다.
IT 인프라와 비즈니스를 연계시키는 전체적인 하향식 접근 방식. 비즈니스 서비스 관리는 IT 및 비즈니스 서비스가 D에 영향을 미치는지에 대한 관리, 모니터링 및보고의 지속적인 관행입니다.
서비스 레코딩은 적절한 서비스에 비용 항목을 지정합니다.
서비스 중단 비용은 서비스의 재정적 가치를 측정하며, 특정 기간 동안의 생산성 손실 및 수익의 가치를 반영합니다.
운영 및 자본 계획 프로세스.
공통적이고 공정하게 표준화되어 있으며 기업 기획주기의 일환으로 IT 지출을 기업 재무 시스템으로 전환하는 작업을 포함합니다.
준수 사례는 적절하고 일관된 회계 방법 및 / 또는 관행이 사용되고 있음을 입증합니다.
IT 서비스 전술 기획 (IT Service Tactical Planning) - 전략 계획을 전략 계획으로 번역하여 서비스의 명확하고 구체적인 단기 목표를 설정합니다. 서비스 개선 계획 (Service Improvement Plan) - IT 서비스 개선을 구현하기위한 공식 계획.
이는 정보, 비즈니스 프로세스, 응용 프로그램, 인프라 등의 책임에 대해 잘 정의 된 역할을 가진 조직 구조를 구현함으로써 수행 할 수 있습니다. R.
Business / IT Alignment는 비즈니스 조직이 정보 기술 (IT)을 효과적으로 사용하여 비즈니스 목표 (일반적으로 개선 된 재무 성과 또는 시장 경쟁력)를 달성 할 수있는 바람직한 상태입니다.
IT 전략적 계획 R - 정기적 인 계획으로 장기 계획을 수립합니다. 장기 계획은 명확하고 구체적인 단기 목표를 설정하는 운영 계획으로 정기적으로 번역되어야한다. 이것들은 다음을 포함해야합니다 :
의사 소통 - 정책 및 표준 D는 고객 조직에 수립되고 전달됩니다.
인사 관리 - R을 채용, 고용, 수의, 보상, 훈련, 평가, 평가 및 홍보하는 건전하고 공정하며 투명한 인사 관리 관행. 품질 관리 - 명확한 개발 단계, 명확한 산출물 및 명시 적 책임을 제공하여 품질 관리 표준 및 시스템을 구현하고 유지 관리합니다. R. 프로젝트 관리 프레임 워크 - 프로젝트 관리의 범위와 경계를 정의하는 일반적인 프로젝트 관리 프레임 워크를 수립하고 주기적으로 검토하고 프로젝트 관리 방법론을 채택하여 수행 된 각 프로젝트에 적용합니다. D.
서비스 제공을 지원하는 데 필요한 모든 CI의 세부 사항은 IT 서비스와 지원 서비스, 구성 요소 및 CI 간의 인터페이스 및 종속성에 대한 지원 팀, 공급 업체 및 구성 관리와의 인터페이싱을 포함합니다.
고객에게 전달 된 모든 IT 서비스의 세부 사항.
비즈니스 단위 R과 IT 서비스에 의존하는 비즈니스 프로세스와의 관계.
하나 이상의 고객 기반에 대한 서비스 또는 서비스 그룹의 성능 모니터링.
Underpinning Agreements (UA) N.
SLA 목표 달성 - 서비스 체인의 일부를 구성하는 내부 및 외부 그룹과의 공식 계약. UA는 서비스가 서비스 체인에서 만나야하는 운영 요구 사항에 중점을 두며 인프라의 특정 구성 요소 N로 나타낼 수 있습니다.
개별 IT 기술 구성 요소의 성능, 사용 및 용량에 대한 관리, 제어 및 예측
운영중인 실제 IT 서비스 사용 및 작업 부하의 종단 간 성능 및 용량을 관리, 제어 및 예측합니다.
단기 수요 관리는 IT 인프라 스트럭쳐 R에서 중요한 자원의 부분적인 고장이 발생한 경우 발생할 수 있습니다.
비즈니스 요구 사항 및 계획을 서비스 및 IT 인프라 요구 사항으로 변환하여 IT 서비스의 향후 비즈니스 요구 사항을시기 적절하게 정량화, 설계, 계획 및 구현할 수 있도록합니다.
구성 요소 가용성 및 비 가용성의 모든 측면 : MTTR, MTRS, MTBSI, MTBF와 같은 측정을 사용하여 구성 요소 가용성에 대한 모니터링, 측정, 분석 및보고.
서비스 가용성 및 비 가용성의 모든 측면과 구성 요소 가용성의 영향 또는 서비스 가용성에 대한 구성 요소 비 가용성의 잠재적 영향.
서비스 손실로 인한 비즈니스 영향의 정량화.
심각한 서비스 중단이 실제로 발생할 가능성을 결정합니다. 위협 수준 및 조직이 해당 위협에 취약한 정도에 대한 평가입니다.
IT 서비스 연속성 계획.
일단 결정이 내려지면 재난 상황에서 IT 시스템, 네트워크 및 텔레 커뮤니케이션을 복구하고, 서비스 중단이 해결되면 정상적인 작동으로 비즈니스 리턴을 관리하는 데 필요한 정보.
Determination of the likelihood that a disaster will actually occur. This is an assessment of the level of threat and the extent to which an organization is vulnerable to that threat.
Documentation describing the roles, responsibilities and actions necessary to resume business processes following a business disruption.
Part of many components and systems that needs to be continuously managed.
Part of many services that needs to be continuously managed.
ITIL v3 Service Lifecycle: Access Management is the Operational process associated with monitoring the security of a service.
Specific security policies that address each aspect of strategy, control and regulation.
A comprehensive security strategy, closely linked to the business objectives, strategies and plans.
For suppliers of operational products or services R .
Commodity Supplier Management.
For suppliers that provide low-value and/or readily available products and services, which could be alternatively sourced relatively easily (e. g. paper or printer cartridge suppliers).
For relationships involving significant commercial activity and business interaction R .
For significant 'partnering' relationships that involve senior managers sharing confidential strategic information to facilitate long-term plans R .
Maintaining the status and integrity of components and systems.
Maintaining the status and integrity of logical CIs.
Defines the overall approach to organizing testing and allocating testing resources R .
What is to be tested and the test scripts that define how each element will be tested.
Many different types of tests might be used to verify that the service meets the user and customer needs as well as the service provider's requirements for managing, operating and supporting the service.
Depend on the type of service and channel of delivery. Functional testing is covered in many testing standards and best practices.
Includes many non-functional tests. These tests can be conducted at several test levels to help build up confidence in the service release: Service Test and Evaluation R Service Test R Service Operational Readiness Test R Service Release Test R.
The portion of a service or IT infrastructure that is normally released together according to a Release Policy R .
Release and Deployment Models.
Standard models that detail the approach, mechanisms, processes, procedures and resources required to build and deploy releases on time and within budget R .
Deciding the best way to break down a major deployment into components and determining the appropriate deployment approach for each R .
Changes affecting baselined components and systems R.
Changes affecting baselined logical CIs R .
Improve the organization by altering how work is done by impacting one or more of the following organizational operations: Processes Systems Organization structure Job roles.
Knowledge needs to be transferred to other parts of the organization at specific points in the lifecycle.
Establishing Data and Information Requirements.
Designing data and information items content and form.
Defining an Information Architecture.
Architecture matched to the organizational situation and the knowledge requirements R.
Governance Organizational changes underway and planned Roles and responsibilities Funding Policies, processes, procedures Methods for Knowledge Management Technology and other resource requirements Performance measures.
Most CIs are designed to communicate certain information about themselves by polling D or by a programming hook inserted into an application.
Detected by an agent running on the same system, or transmitted directly to a management tool specifically designed to read and interpret the meaning of the event.
Determine which Events trigger actions.
Assign Actions to Events D.
What actions need to be taken to deal with the Event.
Identification - user(s) impacted and Service Desk contacted Logging - incidents fully logged and date/time stamped Categorization - allocate suitable incident categorization coding Proritization - agree and allocate an appropriate prioritization code R Initial Diagnosis - try to discover the full symptoms of the incident and to determine exactly what has gone wrong and how to correct it asap R Escalation - When unresolved then pass incident to correct people (Tier II) to resolve Investigation and Diagnosis - support groups involved with the incident handling will investigate and diagnose what has gone wrong Resolution and Recovery - test and apply measures that restore service to normal operating characteristics Closure - Verify that users are satisfied and agree to the cessation of recovery actions.
A separate procedure, with shorter timescales and greater urgency R . The Major Incident procedure should include the dynamic establishment of a separate major incident team under the direct leadership of the Incident Manager, formulated to concentrate on this incident alone to ensure that adequate resources and focus are provided to finding a swift resolution.
Not covered but conceptually would be included in Service Level Management by a Customer Service Representative.
IT Service Continuity Management.
Service-wide outages invoke a distinct set of procedures covered by IT Service Continuity Management (ITSCM)
Business-wide outages invoke a distinct set of procedures covered by a Business Continuity Plan (BCP).
Detection - suspicion or detection of an unknown cause of one or more incidents Logging - recording of relevant details Categorization - Using Incident categories Proritization - same way and for the same reasons as incidents R Diagnosis - diagnose the root cause of the problem R Workaround - implementation of a temporary method to restore service, perhaps with lower functionality. Known Error Recording - maintain history of treatment for subsequent investigations Resolution - test and apply resolution R Closure - When any change has been completed and reviewed the Problem Record should be formally closed.
After every major problem (as determined by the organization's priority system), while memories are still fresh a review should be conducted to learn any lessons for the future R .
Not covered but conceptually would be included in Service Level Management by a Customer Service Representative.
IT Service Continuity Management.
Service-wide outages invoke a distinct set of procedures covered by IT Service Continuity Management (ITSCM). Diagnosis and recovery procedures may well involve the direct assistance of the hardware or software vendor to implement a workaround and resolve the root cause of the service failure.
Business-wide problems invoke a distinct set of procedures covered by a Business Continuity Plan (BCP).
Service Selection - Selection of a service from a defined list (eg. Service Catalogue).
Approval - an estimate of the cost must be produced and submitted to the user/manager for financial approval. In some cases further approval may be needed R Fulfillment - Simple requests may be completed by the Service Desk while others will have to be forwarded to specialist groups and/or suppliers for fulfillment. Closure - Following check that the user is satisfied with the outcome.
Underlying difficulty identified which is adversely impacting upon service quality. Service Level Management must, in conjunction with CSI N and Availability Management, instigate a SIP to identify and implement whatever actions are necessary to overcome the difficulties and restore service quality. R.
A systematic approach to help an organization optimize its underlying processes to achieve more efficient results. BIP attempts to reduce variation and/or waste in processes, so that the desired outcome can be achieved with better utilization of resources R .
Request for access to a system or component R .
Request for access to a service R .
Access Management executes the policies and regulations defined during Service Strategy and Service Design.
Verify that the user requesting access is who they say they are and they have a legitimate requirement for that service.
Identity Change Control.
Changing access rights on the basis of employment change D .
Logging And Tracking Access.
Validation of the rights provided according to defined policies. Exceptions should be handled by Incident Management.
Removing Or Restricting Rights.
According to defined guidelines a User's rights to access may be revoked.
Step 1 - Defining What Should be Measured - driven by business requirements. Step 2 - Defining What Can be Measured - limitations on what can actually be measured R . Step 4 - Processing the Data - process the data into the required format R Step 5 - Analyzing the Data - Data analysis transforms the information into knowledge of the events that are affecting the organization R . Step 6 - Presenting and Using the Information - utilizing reports, monitors, action plans, reviews, evaluations and opportunities R . Step 7 - Implementing Corrective Action - identify issues, present solutions and explain how the corrective actions to be taken will improve the service.
Step 3 - Gathering the Data R / Service Metrics R - the results of the end-to-end service R .
Starting at the bottom, the technology domain areas will be monitoring and reporting on a component basis. This is valuable as each domain area is responsible for ensuring the servers are operating within defined guidelines and objectives. At this level, measurements will be on component availability, reliability and performance. The output of these measurements will feed into the overall end-to-end service measurement as well as the Capacity and Availability Plans R .
Individual measurements combined to provide a view of the customer's experience R .
Better Conceptualization of Service Strategy - Governance.
ITIL v3 CSI, Section 8.3 Governance.
Placing Governance in the CSI book (instead of Service Strategy) positions it in the context of service improvement and not a key element in service strategy.
Integrating CMMI Concepts.
ITIL Information Architecture - the SKMS.
Many sections within ITIL v3, particularly those closely paralleling processes, have an Information system identified to support activities, but there is only a brief section on Knowledge Management, if any, elaboration of the kind of information needed to support the activities. Presumably, this is to be left to the software vendors supplying these supporting tools, opening up the field for innovation and vendor differentiation.
This section is will collect the pieces scattered throughout the five ITIL v3 publications and "fill in the gaps" as best as possible when notable omissions are evident.
Central repository of the users' requirements R , including Application Sizing R . Key data: Requirement ID - this is a unique ID that never changes and is used for traceability Source - the business area or users who requested the requirement or the document where the requirement was raised. Owner - the user who accepts ownership of the requirement. Priority - the level of importance and need for a requirement. Requirement Description - a succinct description of the requirement. Business Process - the type of business activity involved E Justification - sets out the reasons for requesting the requirement. Related Requirements - Interdependent requirements by their Requirements ID Change History - the entries in this section provide a record of all the changes that have affected the requirement R .
Customer Engagement Plan.
main relationships between IT and the business and how these relationships and necessary communication to wider stakeholders will be managed.
Service Portfolio Database.
Service packages come with one or more service level packages (SLP). Each SLP provides a definite level of utility or warranty from the perspective of outcomes, assets and the PBA of customers. Each SLP is capable of fulfilling one or more patterns of demand. SLPs are associated with a set of service levels, pricing policies, and a core service package (CSP).
Definitive repository containing official IT documents R . Foremost amongst this kind of information are the policies and directives underpinning service delivery. Also included would be IT strategies and strategic plans, constraints, financial budgets and plans.
User Profiles (UP) are based on roles and responsibilities within organizations for people, and functions and operations for processes and applications D . UPs provide information on the roles, responsibilities, interactions, schedules, work environments and social context of related users.
Service Accounting Costs - the translation of corporate accounting categories to IT service categories for budgetary and cost performance monitoring.
TCO/TCU data on service costs.
IT expenditures maintained in corporate financial systems as part of the corporate planning cycle.
Details of all the IT services delivered to the customer, together with relationships to the supporting services, shared services, components and CIs necessary to support the provision of the service to the business D .
Details of all the IT services delivered to the customer, together with relationships to the business units and the business process that rely on the IT services D .
Definitive Document Library.
Definitive repository containing official IT documents R . Foremost amongst this kind of information are the policies and directives underpinning service delivery.
Services consist of one or more service level packages (SLP). Each SLP provides a definite level of utility or warranty from the perspective of outcomes, assets and the PBA of customers. Each SLP is capable of fulfilling one or more patterns of demand.
An SLA structure to ensure that all services and all customers are covered in a manner best suited to the organization's needs.
Unlikely to be a single database, and probably exists in several physical locations. Data from all areas of technology, and all components that make up the IT services, can then be combined for analysis and provision of technical and management reporting R .
Transaction response times, transaction rates, workload volumes, SLM thresholds, etc N .
Future business plans R of the organization need to be considered and the effects on the IT services understood.
Data on component availability and unavailability such as MTTR, MTRS, MTBSI, MTBF, Availability.
Data on service availability and unavailability and the impact of component Availability, or the potential impact of component unavailability on service availability.
The business critical elements of the business process supported by an IT service.
Should cover a period of one to two years, with a more detailed view and information for the first six months.
The impact of a failure for all Mission and/or Business Critical applications and systems.
The likelihood that a disaster or other serious service disruption will actually occur to one or more services.
IT Service Continuity Strategy.
The results of the BIAs and RAs will enable appropriate Business and IT Service Continuity strategies to be produced in line with the business needs R .
Plans that describe the sequence of actions, and the parties responsible for carrying them out, in response to a series of identified risks, with the objective of restoring normal business operation as soon as possible for Mission and/or Business critical applications and systems.
Comprehensive security strategy, linked to business objectives, strategies and plans.
Information relating to suppliers and contracts, as well as all the information relating to the operation of the supporting services provided by suppliers R .
Account for, manage and protect the integrity of physical CIs through the service lifecycle by ensuring that only authorized components are used and only authorized changes are made.
Account for, manage and protect the integrity of documentary CIs through the service lifecycle by ensuring that only authorized material is referenced and followed and only authorized changes are made.
Library of test models, test cases, test scripts and test data that can be re-used R.
Throughout the deployment process, appropriate records will be created and maintained. As CIs are successfully deployed, the CMS will be updated. R .
History of the deployment itself, who was involved, timings etc., training records, access rules and levels.
Typically a new or changed service will be introduced with identified errors, which while not according to the original Service Design specification are nonetheless minor enough in nature to be acceptable in live operation. These may well be under active investigation and resolution by the service builders, or may be considered acceptable. In either case the errors will be deployed into the live error database as an element of the deployment of the live service. This information will be available through the SKMS to the service desk who will then be able to link incidents reported against these known errors R .
Formal communication seeking an alteration to one or more CIs R .
Formal communication seeking change to a service offering CIs R .
A database for each device that contains information about that device, including its operating system, BIOS version, configuration of system parameters, etc. R .
Incident Records Unique reference number Incident classification Date and time of recording and any subsequent activities Name and identity of the person recording and updating the Incident Record Name/organization/contact details of affected user(s) Description of the incident symptoms Details of any actions taken to try to diagnose, resolve or re-create the incident Incident category, impact, urgency and priority Relationship with other incidents, problems, changes or Known Errors Closure details, including time, category, action taken and identity of person closing the record.
Reference Tables/Material Incident and problem history Incident categories Action taken to resolve incidents Diagnostic scripts R.
This will help it to identify the CIs affected by the incident and also to estimate the impact of the incident.
Provides valuable information about possible resolutions and workarounds.
Storage of previous knowledge of incidents and problems - and how they were overcome. The Known Error Record should hold exact details of the fault and the symptoms that occurred, together with precise details of any workaround or resolution action that can be taken to restore the service and/or resolve the problem R .
Usually handled by the Incident Management Databasewith Service Requests being handled as a particular type of 'incident' R .
Identify information is filed and the file is associated with a corporate identity, usually an employee or contractor number and an identity that can be used to access corporate resources and information, usually a user identity or 'username' and an associated password.
Associated with component and application-based metrics such as performance, availability etc.
Captured in the form of CSFs, KPIs and activity metrics for the service management processes R .

The IT Skeptic reviews ITIL V3 book "Service Strategy"
This post has been podcast.
[Updated: My review of ITIL V3 "Service Strategy" is no longer available at the original website so I am reposting it here.] If V2 taught us how to walk, V3 teaches us to run. Trouble is, many organizations are still sitting down.
The first of the five books in the ITIL Version 3 core suite, Service Strategy is ITIL’s bid for credibility outside the back-room. Well actually, much of Version 3 is a cry for acceptance at higher levels in the organisation (or a power grab for more of the business depending on your perspective). But Service Strategy leads the charge, making an effective case for delivery of IT as a service, and for a strategic, analytical and theoretical approach to such delivery.
One group of readers will consider this book an excellent solution to address some fundamental problems with ITIL versions 1 and 2: the lack of a theoretical and philosophical vision; the relegation of business considerations to a backwater book seldom referenced; and, frankly, an inadequate emphasis on IT as a service despite all the claims in the introductions to the ITIL books (count the references to service catalogue in the Version 2 books). Whether they agree with Service Strategy or not, the academics, theorists, pontificators and philosophers of ITSM will consider this book one of the most interesting things to happen to the sector in a decade.
Another group of readers will reject Service Strategy as an upstart attempt to give some white collar credibility to a blue collar framework. ITIL comes from the wrong side of the tracks. Operations people wouldn’t know a strategy if it stood up in their porridge. Their grasp of architecture stops at Visio diagrams of a physical network. Previous attempts to extend ITIL’s tentacles into solutions development, procurement and other aspects of the IT business have been seen off with the contempt they deserved, but this book returns with a land-grab at a whole new level of presumptuousness.
And a third group will discard it in bemusement or frustration. Service Strategy reads like a university textbook.
Heck, it is a university textbook. The first seventy-plus pages are a systematic and comprehensive documentation of the body of theory behind modern business analysis based on value networks and dynamic systems, with a particular focus on how these apply to the delivery of operational services within the organisation or to customers of the organisation.
Then we return to planet Earth with a second seventy-odd pages of more execution-oriented approach to the processes that live in this book: Service Portfolio Management, Demand Management and Financial Management. However, the heavily theoretical tone remains, and many practitioners will find this a burden. They will want to cut to the chase. I predict that more pragmatic theory-stripped versions of this part of the book will be highly successful publications for those who can get through the copyright minefield OGC are busily laying (this means probably only itSMF and a few chosen others).
Finally there is a third seventy pages of theory and strategy for the organisation and operation of an IT operations business unit. It seems very good, but will again spawn an industry simplifying and explaining it for those who have a job to do.
The book claims to be targeted at “IT organisations” (p10). I don’t see this happening. Even in the largest organisations, one person at most will have the will, interest, time and priorities to study hundreds of pages of densely packed theory.
The target audience for this book is ITIL consultants who can pre-digest it and deliver only the essential conclusions to users. Consultants can study it as one module of their master’s certification, though heaven knows what many will make of it, what exactly can be distilled into a short course, or how much will be assimilated over a few days. This book would be a suitable foundation for a semester’s full-time university paper. Lucky for me that I have a background in electrical engineering systems theory, a graduate degree in operations research, and a lifetime’s reading of scientific literature, or I’m not sure how I would have otherwise survived my first encounter with it.
I predict the book will only really come into its own (a) at the Advanced ITIL certification level, the new level introduced in Version 3 which is yet to be defined and (b) at tertiary institutions offering qualifications in ITSM. Actually (a) and (b) may well prove to be the same thing, i. e. OGC/APMG will look to more substantial institutions to deliver Level 3 certification than the comparatively light-weight operators that constitute current ITIL trainers.
As a result this book presents the same conundrum that all five books in the suite do: ITIL has been taken to another level of maturity and sophistication. That is all well and good for those who are (a) already on the journey and (b) have a business need to grow beyond Version 2’s simpler view of the ITSM world. It is more problematic for those just starting to look at ITIL.
Regardless of what anyone may try to tell you, ITIL V3 is more complex than V2. ITSM is a deeper and more advanced discipline than a decade ago. Not only are some of the processes more advanced – and Financial Management in this Service Strategy book is an excellent example of that – but many areas that could be quietly neglected in simpler V2 installations are now more tightly integrated and brought back into prominence: the “lost processes” have been re-discovered. Examples are Service Catalogue Management, Information Security Management, and Supplier Management.
So the problem is that there is not – as yet – an ITIL Lite for those who don’t need the rocket science. This is subtly different to ITIL for Small Scale Implementations. What we need is ITIL for Beginners Big or Small, for those making the first steps which may or may not later grow into what we have now with V3: ITIL for ITSM Geniuses. V3 tells us how to run, V2 told us how to walk, and many organisations are still sitting down.
The fact that we don’t have ITIL for Beginners leads me to my second prediction: Version 2 will prove much more resilient than OGC hopes. Their plans were to kill it off in 2008, but I think there will remain a strong demand for training, consulting and books long after that - unless OGC move quickly to get a red-book-plus-blue-book beginners’ subset out as part of the complementary publications.
Please don’t look to this review for detailed criticism of the content of the Service Strategy book. I have had a year of exploration to absorb it and I am barely starting. Once I assimilate it I'll need another year to really understand it especially in a practical context, and more time still to prioritise the insights.
The whole ITSM community will be chewing on Service Strategy for years to come. Quite a few will find it indigestible. Others will find it full of long-term nourishment.
Published in The Skeptical Informer, June 2007, Volume 1, No. 5.
Previous story: ITIL’s dead elephant: CMDB can't be done Next story: ITIL V3 Certification points system: the magic number 21.5.
Published in The Skeptical Informer, February 2009, Volume 3, No. 2.
Previous story: A list of Request Classes to help out ITIL Next story: itSMF International needs to unite the ITIL community.
Excellent review. I found.
Excellent review. I found the Strategy book took about 30 attempts and I still haven't read, digested let alone tried to apply it all.
For the V3 Expert bridge multiguess exam all you need to do is read the 70 pages on the handful of processes.
PS: just bought your Owning ITIL book - will let you know how I go.
Service Strategy.
Just finished teaching the Service Strategy Lifecycle class for one of the light-weight trainers. The audience was a group of consultants who are expecting to become ITIL experts in 5 weeks.
Yes, the SS book is written like a university text, but not a well-written one. As one of the candidates pointed out, one paragraph will be written in double-speak and the next will be written in short cryptic sentences which assume you have assimilated every concept that preceeded it in the book.
In my opinion this is not really acceptable for material intended to be used as a reference work.
Remember - you are being certified in ITIL.
First - my sympathies. I have taught ITIL since 1997 and it has traditionally required substantial input from the instructor, especially at the 'practitioner' and now capability and lifecycle levels - to operationalize the concepts - make them seem real.
Unfortunately, much of Strategy seems to be an effort to discover the New World of service management based upon a predominantly outsourcer and IT perspective. Its content is generally in conflict with pre-existing concepts and proven methods used within the mature non-IT service management industry and as used to develop business strategies.
It is critical that an IT organization uses methods to develop a service strategy that is consistent in its language and compatible in its methods with that used by the enterprise - period. ITIL Service Strategy does not - so tread cautiously.
Take a moment to check out other great sources such as Marketing Management (Philip Kotler), Service Management and Marketing (Gronroos) and Service Management and Operations (Haksever, render, Russell, Murdick) - all largely ignored by Strategy. Note - all these sources are IT agnostic. Add in poorly positioned references to Porter's value chain and a complete lack of customer relationship management, market research, and requirements management and you have the recipe for a a painful instructor experience.
Remember - this is ITIL's view of the fundamentals of a Service Strategy. If you wish to be certified in ITIL's view - please realize you will have to add a ton of stuff from external sources to be able to actually build, or help build a strategy, often part of a responsibility to manage an IT budget in the millions of dollars.
Once you have gained the ITIL view - also note - you need to understand how the business builds their strategy and its your responsibility to show you can decipher this, and develop an integrated service strategy.
Try Reading the 12 hour MBA.
Great resource and could also go under favorite books.
the 12 hour MBA is a summary of the topics you would cover in an MBA. Each chapter has exercises to help drive the points home. I found it really beneficial to re read after I got the Expert certification. Its a practicial application of the concepts in the Service Strategy book. And..biggest benefit helps you understand the General's Point of View and language.
Misunderstood strategy.
I see the SS book as a major misunderstanding. Yes, it describes a lot of modern business theory. The recent events on Wall Street should have opened our eyes to be a bit more skeptical on these theories. I wonder how useful are the V3 based IT strategies that were created before last summer.
The misunderstanding is in the nature of strategies the SS book explains. These models are for the generals who are playing with armies. In most cases IT people are the support staff in charge of supply. IT strategy is not done on based on market spaces but under the limitations of corporate strategy. The SS book is not tied to the rest of books. There are some strategic elements in itil but the SS books ignores those.
Your mess for less.
I spent today immersed in a strategy workshop with the CIO and his captains. The topics of interest were only those from Service Strategy: portfolio management, product management, relationship management, service lifecycle, customer portfolios, utility and warranty, and so on.
I knew what we were in for when the CIO walked in with a copy of the book. He is using the economic climate as a call for action, to make dramatic changes to how IT is positioned in the organization; from passive-order-taker to business partner. Of course, embedded in the plan were cost reduction opportunities such as the rationalization of his portfolio of services.
Clearly we live on different planets.
". IT people are the support staff in charge of supply."
I think this "strategy" is a sure fire way to extinction in today's climate. In fact, there's been a dramatic uptick in the outsourcing of organizations who cling, along with religion and guns, even tighter to this model. IBM is doing a nice business taking over these moribund organizations with the mantra "your mess for less."
Maybe just at the different sides of the planet.
It would be good if IT could be a business partner, nothing wrong with that. I do not think that the a few days study of the SS book is a good guide to it.
In my world the CIO's are not very interested in studying ITIL. They tend to leave it to the lower levels like the IT Infrastructure managers, Service Desk managers etc. It is not unusual that the CIO is an MBA so the theory is already familiar.
Interesting Review.
An interesting review, Skeptic. It caused me to step back and reflect upon other professions.
What is to be thought of doctors, for example, whose annual reading is at best made up of two or three formulaic thrillers? Who, by virtue of their profession's class system, are increasingly rewarded as their knowledge of medicine narrows.
Or what do we make of the banker, called upon to make real decisions in a time of instability and inflation, who has never heard of John Law or has endeavored to forget who he was or what he did?
Or the economist who thinks even less of railway bubbles and the crash of 1880. What does it mean when he talks seriously of the catastrophe which awaits if debts are forgiven, given he doesn't know that the entire civilation of Athens - upon which we still model western civilization - was created through Solon's wiping out of all crippling loans. Or indeed that America's economic strength in the 20th century was in part the result of constant financial defaultings during the 19th century.
What do we think of the professor of English who views fiction as an exercise separate from society? Rendering literature inaccessible except to the most intimately initiated. And in the process, who becomes himself incapable of understanding the movements of the outer world?
I'd say therein lies the tragedy.
Voltaire used to ridicule the elite of his day by pointing out -- through well-placed scepticism, of course -- they were pitifully ignorant. They simply bought knowledge and advice. The elite's ignorance was so profound that it made them incapable of leading.
Voltaire was not arguing that in order to lead you must be a Renaissance man. But there was a need for general and in-depth knowledge in some direction. And on that foundation there was a need to be interested in the ideas and creations of one's time. To read, to think, to ask questions, and to talk in wide circles, well beyond any particular competence.
The technocrats of our day make the old seem profound and civilized by comparison.
Dool, this is not ITIL specific but your comments/comparison using doctors is very ill informed. In order for a Doctor to remain a specialist he/she is required to attend conferences, read publications, publish etc. Also while specialising in a specific field they do narrow the scope of their knowledge but are increasing the depth of it in their chosen field. To specialise means to get very good in a certain area because it is impossible in a working lifetime of a person to be good at everything. I don't understand why the public loves to criticise doctors - Doctors are probably paid less than you while actually doing something useful - like helping sick people feel better.
Voltaire's Bastards.
Coming from a family of doctors, perhaps I presume to know at least a little about doctors and the medical profession - and some context. For example and to my earlier point:
Doctors were once at the centre of political, social and cultural change. Today, a doctor tends to reach his summit when his view of the human body consciously limits itself to a single organ. They've become technocrats. His is an abstract profession involving narrower and narrower bands of knowledge.
This is precisely what John Saul called "Voltaire's Bastards." Those who hold the absolute belief that the solution to our problems must be a more determined application of rationally organized expertise - ignoring or even disdaining the greater context.
The reality is, as Voltaire pointed out, is that our problems are largely the product of that application.
I hold no derision towards doctors. This is not a commentary on the profession as it is an observation to what Saul described as, "the West's love affair with the ideology of pure reason has made us crippingly dependent on process-minded experts who rational systems are bereft of both meaning and morality."
We are way off topic so I'll move on.
off topic on this blog?
Pardon? "the West's love affair with the ideology of pure reason has made us crippingly dependent on process-minded experts who rational systems are bereft of both meaning and morality" is off topic on this blog? Bang on target I'd say and nicely complementary to Shelley Gare's quote "Anything that can't be put into numerical form is somehow regarded as immaterial or ephemeral, even though we should all know that the most important things in life can never be measured."
Its lawyers not doctors.
Your comments make about as much sense to an ignoramus such as me as the Service Strategy book will make to the ITIl fanzine. thank you once again for endorsing the Skeptics point - while trying to shoot it down. Sometimes a degree of ignorance is worth a pound of sense when trying to get to the nub of an issue. The 5 whys are proof of that concept.
Oops I forgot to make the lawyer point.
I was distracted . its lawyers that draw the ire of mere mortals not doctors. Lawyers will adopt any perspective to make a buck - for or against the point being discussed. they 'interpret' the law as it best suits their side of the case. Doctors have a professional code "preserve life". Lawyers have a variable code that they can adapt to the current situation. ITIL V3 has turned us all into lawyers - it lacks the specific promised guidance touted by many of those who are close to the core and loud during the may 30 launch. Now they, like all of us, need to turn to our doctor code to help folks diagnose the problem and find a remedy that is in the best interest of the customer.
Just a few Voltairisms to even your quote up:
Doubt is not a pleasant condition, but certainty is absurd.
Judge of a man by his questions rather than by his answers.
I disapprove of what you say, but I will defend to the death your right to say it.
What do we say of the service management professional who know nothing but ITIL.
narrow un-contexted views.
Other pages in this "book"
Speaking at Pink Elephant ITSM Conference (#PINK18) in Orlando, Florida on February 18-21.
DevOps for Everyone with Rob England.
Talking about my presentation at DOES UK.
ITIL Change is much misunderstood in the DevOps world.
The IT Skeptic on DevOpsTV at DOES16 San Francisco with the awesome Damon Edwards.
A white paper on my Standard+Case model.
Recently, Gene Kim and I interviewed each other about DevOps.
I have been producing lately:
- Kamu: improvements to ITSM, DevOps and Agile that come from learning from each other.
- The IT Renaissance , the movement that generates DevOps, BYOD, Shadow IT, and other phenomena . this year's Big Idea.
Disclosure.
I don't get paid to say nice things and I don't get paid to review anything.
You may have noticed Google and Amazon ads on the site, as well as ads for my books and merchandise. I make money off them, but sod all. At least it covers the hosting with a bit left over .
ITIL® is a Registered Trade Mark of AXELOS Limited.
PRINCE2® is a Registered Trade Mark of AXELOS Limited.
M_o_R® is a Registered Trade Mark of AXELOS Limited.
P3O® is a Registered Trade Mark of AXELOS Limited.
MSP® is a Registered Trade Mark of AXELOS Limited.
P3M3® is a Registered Trade Mark of AXELOS Limited.
MoV® is a Registered Trade Mark of AXELOS Limited.
MoP® is a Registered Trade Mark of AXELOS Limited.
ITIL® is registered in the U. S. Patent and Trademark Office.
ITIL Live™ is a trademark of TSO, The Stationery Office.
prISM® is a registered trademark of itSMF International Inc.
COBIT® is a Registered Trade Mark of the Information Systems Audit and Control Association and the IT Governance Institute.
Microsoft® is a Registered Trade Mark of Microsoft Corp. in the United States and/or other countries.
USMBOK™ is a trademarks of the SM101.
CMM® and CMMI® are Registered Trade Marks of Carnegie Mellon University.
ISO® is a Registered Trade Mark of the International Organisation for Standardisation.
KCS was developed by the Consortium for Service Innovation™, serviceinnovation. org The KCS Academy, KCS and Adaptive Organization are service marks of the Consortium for Service Innovation™.
DevOps isn't a trademark of anyone.
Except where indicated otherwise, all contents of this site are © Copyright Two Hills Ltd twohills. co. nz.
Except where indicated otherwise, the text on this page by Two Hills Ltd is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.
Content must be attributed to "© Copyright Two Hills Ltd twohills. co. nz by Rob England, The IT Skeptic" plus the URL of the source material.
RSS feeds may be used without permission. Permission is granted for anyone to link to this site.
By accessing or viewing this site, you are deemed to have agreed to the Terms and Conditions and to our Privacy Policy.
The contents of this site are unmoderated submissions from authenticated and unauthenticated users. As such they cannot and do not represent the views of Two Hills Ltd.
Use of any trademarks on this website is not intended in any way to infringe on the rights of the trademark holder.
This site is developed, maintained and hosted by Two Hills Ltd.