서비스 제공자는 다음 요소를 고려하고 평가함으로써 가치가 제대로 제공되고 있는지 가늠한다.
• Outcome
• Output
• Cost
• Risk
• Utility
• Warranty
이 요소들은 균형있게 유지되어야 한다.
온라인 뱅킹서비스는 사용자들에게 편의성을 제공하지만 서비스가 느려터지고 불안정하며 보안 위험 요소까지 존재한다면 아무도 사용하지 않을 것이다. 또한 주문하면 1시간 만에 배송되는 특급 서비스가 있다면 이는 고객에게는 매우 좋은 일이지만 이 서비스를 계속 했다가는 서비스 업체가 망할 수도 있다.
따라서 Value를 평가하는 위 요소들을 적절히 유지하여 '큰 그림'을 놓치지 말아야 한다.
우리말로 ‘결과물’로 번역되는 두 가지 용어가 있다. output과 outcome인데 ITIL에서 정의하는 이들 용어는 다음과 같다.
Output의 정의
output
"A tangible or intangible deliverable of an activity"
"활동을 한 유무형의 성과물"
Outcome의 정의
outcome
"A result for a stakeholder enabled by one or more outputs"
"한 가지 이상의 output을 통해 만들어지는 이해관계자를 위한 결과"
쉬운 예를 들면, output은 넷플릭스에서 서비스하는 각종 영화들이라고 할 수 있다. outcome은 이 영화를 통해 고객이 즐거움을 받았는지, 가족영화를 보고 아이들과 유대감을 느낄 수 있었는지를 말한다.
output은 유형적이거나 계량적으로 측정이 가능한 반면, outcome은 무형이고 정의에서 언급하였듯이 output을 통해서 나타나는 결과이다.
넷플릭스의 영화들이 output이라는 건 변함없는 사실이다.
그러나 좀비 영화를 보고 감흥을 느끼는 사람이 있는 반면 그렇지 않은 사람도 있게 마련이라 outcome은 동일한 대상에 대해 고객마다 다를 수 있다는 차이가 있다.
outcome은 같은 대상에 대해 사람마다 다를 수 있을 뿐 아니라 같은 사람이라도 시간에 따라 혹은 상황에 따라 변할 수 있다. 좀비 영화라면 빼놓지 않고 보는 사람이 그날도 새로나온 좀비물을 보려고 하다가 마침 그날 월드컵 결승전 생중계가 하는 것을 보고 채널을 돌렸다면, 그는 그가 좋아하는 스포츠라는 요소로 인해 그의 preference(선호)를 바꾸게 된 것이다.
서비스 제공자는 outcome을 지속적으로 측정하여야만 고객의 진정한 니즈를 파악할 수 있다.
Cost의 정의는 다음과 같다.
Cost
"The amount of money spent on a specific activity or resource"
"어떤 활동이나 자원에 지출되는 돈"
Cost는 크게 두 가지로 나뉜다.
1. Direct Cost 직접 비용
고객에게 직접적으로 부과되는 비용으로 여기에는 추가 요금이 발생하는 특급서비스나 교육 같은 부가 서비스가 포함되기도 한다.
2. Indirect Cost 간접 비용
인프라 비용이나 인건비 등 고객에게 직접 부과되지 않으나 일반적으로 서비스 가격 뒤에 숨어 있는 기타 비용이다.
서비스 제공자의 입장에서는 비용의 책정은 내부적인 요인 뿐 아니라 경쟁사나 시장 환경의 영향을 받기도 한다. 당연히 경쟁력 있는 가격을 원하겠지만 소비자와 서비스 제공자 모두 윈-윈 하는 수준에서 결정을 해야 한다. (Uber의 경우 저렴한 승차권을 제공해 빠르게 시장을 선점했지만 내부적인 타격이 매우 컸다)
서비스의 소비자 역시 지불하는 비용을 불필요한 부담이라고 여기지 말고 일종의 투자로 봐야 한다. 물론 이는 자신이 지불한 가격이 정당하다고 인식할 때 가능하다.
요컨데, 서비스의 Cost는 시장의 상황과 서비스 제공자의 Expense(서비스 제공을 위해 지출한 금액), 고객의 기대치 이렇게 삼박자가 맞아야 한다.
** Cost와 Expense 모두 우리말로 비용으로 해석될 수 있으나 차이가 있다. Cost는 어쨌든 쓴 돈 전체가 되고, Expense는 이 중 소모되는 금액이다. 소모되지 않고 남아 있으면 그것은 Asset이 된다.
- 고객 사은품 구입 비용(원가) : Cost
- 이벤트에서 사용한 금액(소모비용) : Expense
- 향후 이벤트를 위해 남긴 금액(자산) : Asset
소비자는 본인이 제공받는 서비스를 계속해서 분석해 볼 필요가 있다. 가령 넷플릭스에서 가장 비싼 프리미엄 요금제를 사용하고 있는 소비자가 본인의 시청 스타일을 분석하여 훨씬 저렴한 베이식 요금제로 바꾼다면 불필요한 비용을 아낄 수 있기 때문이다.
■ Risk
Risk의 정의
Risk
"A possible event that could cause harm or loss or make it more difficult to achieve objectives"
"피해나 손실을 야기하거나 목표 달성을 더 어렵게 만들 수 있는 일들"
리스크는 어차피 완벽하게 피하는 것은 불가능하다. 중요한 것은 그것들을 식별하고 관리하는 것이다.
리스크는 보통 서비스 제공자나 소비자가 부담하는데, 소비자는 아래 두 가지 경우 모두 서비스에 영향을 미치는 리스크를 인지하고 있어야 한다.
1. 서비스 제공자가 완화시키거나 제거하는 리스크. 우버 택시를 예약할 때 만일 소비자의 휴대폰 데이터가 더이상 없거나 wi-fi도 안 된다면 택시 예약이 불가하므로 이런 경우를 위해 SMS를 통해 예약이 되도록 리스크를 완화시키는 회사가 존재한다 (인도의 Ola)
2. 서비스 제공자 자체 리스크로 이에 대한 영향도를 소비자가 인지하는 경우. 해당 지역에 이용 가능한 택시가 더이상 없는 경우 소비자의 휴대폰은 잘 작동하지만 택시 서비스 자체가 불가능하다.
보통 B2B 에서 리스크는 한쪽 방향으로만 부과되지는 않는다. 리스크 관리의 소유는 서비스 제공자이지만 이를 억제하기 위해 소비자 역시 적극적인 파트너가 되어야 한다. 고객은 서비스 제공업체를 신뢰하고 성공적인 서비스가 되도록 가능한 모든 정보와 리소스를 오픈해야 한다.
리스크를 완화하기 위한 4가지 방법이 있다. 이는 프로젝트 관리 영역에서도 동일하게 다루는 내용이다.
1. 회피 Risk avoidance : 리스크를 회피하거나 제거할 수 있을 때는 그렇게 하는 것이 좋다.
예: 재택근무를 취소함으로써 직원들이 사내 시스템에 접속하지 못하거나 에러가 나는 상황을 아예 차단할 수 있다.
2. 전가 Risk transfer : 피할 수 없는 경우 리스크를 다른 당사자에게 이전한다.
예: 자동차 렌트시 추가적인 보험에 가입함으로써 발생할지 모르는 사고의 리스크를 보험회사로 전가시킨다.
3. 완화 Risk mitigation : 리스크에 대응할 수 있는 방법이 있는 경우이다. 리스크가 현실화 되었을 때 솔루션을 발동한다.
예: 서버를 이중화하여 위급상황시 fail-over를 수행한다.
4. 수용 Risk acceptance : 리스크를 완화하거나 피할 수 없고 다른 당사자에 전가할 수도 없는 경우는 선택의 여지가 없다. 겸허하게 받아들인다.
예: 한때 코로나 확진자가 다녀간 음식점을 일정기간 폐쇄했던 정부의 정책은 그냥 받아들이는 것 외에는 어쩔 도리가 없다.
■ Utility와 Warranty
Utility의 ITIL 4 정의는 다음과 같다.
Utility
"The utility is the functionality offered by a product or a service to meet a particular need"
"필요로 하는 것을 만족하기 위해 제품이나 서비스로부터 제공되는 기능"
Warranty의 정의는 아래와 같다.
Warranty
"Warranty provides assurance that a product or a service will meet its agreed requirements"
"요구사항에 대한 제품이나 서비스의 충족을 보증하는 것"
** 유틸리티와 워런트의 정의에 각각 사용된 need와 requirement를 구분하는 것이 크게 의미가 있어 보이지는 않지만, 굳이 차이를 생각해 보면, requirement가 좀더 공식적이며 정리가 된 formal한 느낌이다. need는 보통 음식이나 물, 공기처럼 기본적으로 필요한 것들에 사용되는데 이것들을 requirement라고 하지는 않는다.
사실 정의만 가지고는 대체 무슨 말을 하는 건지 알기가 어려운데, 이를 영어로 구분해 보면 좀더 감이 온다.
• Utility : Fit for purpose
• Warranty : Fit for use
유틸리티는 목적에 부합하는지, 워런티는 사용에 적합한지 를 말한다.
또한 유틸리티는 기능과, 워런티는 가용성, 용량, 보안, 연속성의 영역과 관련이 있다.
휴대폰 서비스를 예로 들면, 핵심서비스인 통화 기능이 달성되면 목적에 부합하는 것이라고 할 수 있다. ⇒ Utility
반면, 좋은 휴대폰 기기가 있더라도 통화를 위한 충분한 대역폭이 없다면 휴대폰을 사용할 수 없고, 최신의 TV가 있더라도 전력이 없으면 무용지물이듯이, 서비스의 기능을 사용할 수 있는 적합한 능력이 있어야 한다. ⇒ Warranty
결국 서비스를 통한 Value는 Utility와 Warranty가 모두 달성되어야 가능하다.
이를 다음 그림과 같이 논리 게이트로써도 표현이 가능하다. (논리 게이트를 모른다면 그냥 무시하자)
Utility
위 그림에도 나와 있듯이 유틸리티는 다음 두 가지 조건 중 하나를 만족하거나 둘 모두 만족하면 충족이 된다. (Fit for purpose)
1. Performance 지원
2. 고객의 Constraint 제거
서비스가 목적에 부합하려면 서비스의 성능을 높이거나 고객이 가진 제약사항을 없애야 한다.
Warranty
Warranty는 4가지로 구성된다.
1. Available 가용성
휴가를 갔는데 거기서는 휴대전화가 아예 터지지 않는다면 가용성 측면에서 value를 제공받지 못한 것이다.
2. Capacity 용량
휴가지에서 전화가 되긴 하나 막상 전화를 걸어도 연결이 잘 되지 않는다면 서비스의 처리 용량이 충분치 않은 것이다.
3. Continuous 연속성
전화가 걸리긴 하나 자꾸 끊어지고 전화가 됐다 안 됐다 해서 고객을 짜증나게 한다면 충분한 value를 주지 못하는 것이다.
4. Secure 보안
내 전화 통화를 누군가 엿들을 수 있다면 이는 보안과 관련된 value를 제공하지 못하는 것이다.
Warranty는 이 4가지 항목(고객이 요구하는 수준)을 모두 만족해야 사용에 적합하다. (Fit for use)
다른 예로 소셜 미디어 플랫폼을 들어보면, Utility는 다음의 것들이 될 수 있다.
1. 사용자가 관심 있는 계정을 '팔로우' 할 수 있어야 한다.
2. 사용자가 최신 또는 가장 인기 있는 콘텐츠를 볼지 말지 결정할 수 있어야 한다.
3. 사용자가 마음에 안 드는 계정을 '차단' 할 수 있어야 한다.
Warranty 요구사항은 다음과 같습니다.
1. 사용자가 액세스를 원할 때 이용가능해야 한다. (트래픽이 많아도 실패하지 않아야 함)
2. 사용자의 상세 정보를 안전하게 관리해야 한다.
3. 문제 발생시 플랫폼을 복원할 수 있어야 한다.
'ITSM_ITIL' 카테고리의 다른 글
[ ITIL 4 이해하기 ] Service Relationships 서비스 관계 - ITIL Foundation (0) | 2022.08.22 |
---|---|
[ ITIL 4 이해하기 ] Service Offering 서비스 오퍼링 - ITIL Foundation (0) | 2022.08.22 |
[ ITIL 4 이해하기 ] Value의 정의 - ITIL Foundation (0) | 2022.08.22 |
[ ITIL 4 이해하기 ] Service Management 서비스 관리 - ITIL Foundation (0) | 2022.08.22 |
[ ITIL 4 이해하기 ] DevOps에서는 운영이 더이상 필요없는가 (0) | 2022.08.22 |