2017.06.15

선무당이 IT 조직을 망친다··· 조심해야 할 베스트 프랙티스 12가지

Bob Lewis | CIO

무엇이 IT조직을 실패하게 만들까? 때론 어설프게 알았던, 또는 업무에 절대 도입하지 말았어야 할 이른바 '업계 베스트 프랙티스'를 도입한 것이 원인인 때가 종종 있다.

내부 고객이라는 인식부터 차지백 제도 도입, ROI에 대한 주장까지 '멀리서' 바라보면 그럴듯한 조언들이 존재한다. 그러나 '속'을 들여 보면, IT의 성공을 보장하는 것이 아니라 실패로 이어지는 때가 많은 조언들이다.



1. 모든 사람에게 고객이라고 말한다
실패하는 방법은 간단하다. IT부서의 모든 사람들이 IT 외부사람 모두에게 "당신은 우리 고객이다. 당신의 기대를 뛰어넘는 것이 우리가 할 일이다. 당신을 행복하게 만드는 것이다"라고 말하도록 만들면 된다.

IT외 부서의 직원들은 IT의 고객이 아니다. 회사를 위해 IT가 동등하게 협력해야 하는 IT의 동료들이다.

내부 고객이라는 개념을 정당화 하면 IT는 부수적인 위치에 놓이게 된다. 다른 사업부의 직원들이 회사 사업에 도움이 되지 않아도, 더 나아가 고객들이 더 많은 제품과 서비스를 구입하도록 유도하지 못하는 경우에도 동료들을 만족시켜야 하는 위치에 놓이게 되는 것이다.

2. SLA를 만들어 '계약서'처럼 취급한다
실패하는 방법은 또 있다. SLA(Service Level Agreement)를 만들어, '내부 고객'들에게 서명하도록 만든 후 계약서처럼 취급한다. 그리고 매번 IT가 SLA를 충족했다고 주장하는 것이다.

그러면 '내부 고객'들은 IT가 해야 할 일을 하지 않는다고 말하기 시작할 것이다. 이는 관계를 소원하게 만드는 지름길이다.

성공하고 싶다면 관계에는 신뢰가 필요하고, 신뢰를 쌓기 위해서는 동료를 존중해야 한다는 점을 명심해야 한다. 동료가 IT를 좋아해야, 서로 협력해 문제를 해결할 수 있다. 계약은 관계 정립이 목적이 아니다. 신뢰가 없고, 심각한 문제가 발생했을 때 취할 조치를 규정하는 것이 목적이다.

3. '내부 사용자'를 조롱한다
잘 알고 있는 내용일 것이다. "다시 확실히 설명해 드리겠습니다. 정전 때문에 부팅이 되지 않는 것입니다. 모르겠어요?", "그 바보 같은 사람이 프린터 3상 플러그를 반대로 삽입했지 뭐야!(동료들의 낄낄거리는 비웃음)"

다른 IT직원들이 (특히 이름까지 구체적으로 언급하며) 다른 부서 동료들을 비웃을 때 동참하라. 아니 더 확실히 실패하고 싶다면, 직접 다른 부서 동료를 면전에서 비웃기 바란다. 그러면 IT부서 사람들은 하나 같이 다른 부서 사람들을 존중하지 않는다는 말이 퍼져 나갈 것이다. 이 또한 쉽게 실패할 수 있는 방법이다.

4. 차지백(Charge-backs)을 실시한다
정보기술을 사용하지 못하도록 유도하는 좋은 방법이 있다. 차지백을 실시하는 것이다. 그냥 차지백이 아니다. CPU 사이클부터 SAN, NAS 스토리지(당연히 분리), 개발자 작업시간, 헬프 데스크 지원까지 모든 비용 중심에서 발생하는 비용을 10분 단위로 상세히 항목 별로 청구하는 차지백을 만든다.

이렇게 하면 협력이 사라진다. 청구 내용이 정확한지, 청구 비용을 책임질 부서가 누구인지를 놓고 논쟁을 벌이게 될 것이다.

5. ROI를 고집한다
아주 중요한 프로젝트에 자금이 투입되지 않도록 만들면 IT는 이내 실패할 수 있다. 그리고 이에 도달하는 방법은 간단하다. IT거버넌스 프로세스에 명확하고 가시적인 투자 수익이 보장되어야 한다고 주장하면 된다.

이렇게 하면 손쉽게 시대에 뒤쳐질 것이다. 비즈니스 부서가 더 빨리 성과를 내도록 도와주는 기술에 예산이 투입되지 않도록 만들고, IT는 입증할 수 없는 영업 측면의 비용을 줄이는 한편, 장기적으로 매출을 증대 시키고 고객 만족을 견인하는 프로젝트들이 뒷전으로 밀릴 것이다.

6. IT프로젝트를 비호한다
비즈니스와 IT부서가 삐걱거리도록 만들고 싶은가? 프로젝트의 결과물을 소프트웨어 전달로 규정하면 된다. 즉 소프트웨어가 요구사항과 사양(명세서)을 충족하면 IT의 할 일이 끝나는 것이다.

이렇게 하면, 비즈니스 부서 관리자가 소프트웨어가 필요한 기능을 제공하지 않는다고 불평할 때, 사양을 충족하기 때문에 소프트웨어에는 아무 문제가 없다고 주장할 수 있다. 또 프로젝트가 요구 사항을 충족하지 않을 경우, 요구 사항이 잘못되었다고 주장할 수 있다. 누구의 잘못이냐고? 당연히 프로젝트를 승인한 비즈니스 부서 관리자의 잘못이다.

이러한 사태를 피하고자 한다면 효과가 있는 방법을 실천할 수도 있다. 프로젝트 명칭부터 시작한다. 그리고 소프트웨어가 아닌 비즈니스 성과를 규정한다. 세일즈포스닷컴(Salesforce.com) 구현 대신 영업 효과 향상 등을 결과물로 규정하는 것이다.




2017.06.15

선무당이 IT 조직을 망친다··· 조심해야 할 베스트 프랙티스 12가지

Bob Lewis | CIO

무엇이 IT조직을 실패하게 만들까? 때론 어설프게 알았던, 또는 업무에 절대 도입하지 말았어야 할 이른바 '업계 베스트 프랙티스'를 도입한 것이 원인인 때가 종종 있다.

내부 고객이라는 인식부터 차지백 제도 도입, ROI에 대한 주장까지 '멀리서' 바라보면 그럴듯한 조언들이 존재한다. 그러나 '속'을 들여 보면, IT의 성공을 보장하는 것이 아니라 실패로 이어지는 때가 많은 조언들이다.



1. 모든 사람에게 고객이라고 말한다
실패하는 방법은 간단하다. IT부서의 모든 사람들이 IT 외부사람 모두에게 "당신은 우리 고객이다. 당신의 기대를 뛰어넘는 것이 우리가 할 일이다. 당신을 행복하게 만드는 것이다"라고 말하도록 만들면 된다.

IT외 부서의 직원들은 IT의 고객이 아니다. 회사를 위해 IT가 동등하게 협력해야 하는 IT의 동료들이다.

내부 고객이라는 개념을 정당화 하면 IT는 부수적인 위치에 놓이게 된다. 다른 사업부의 직원들이 회사 사업에 도움이 되지 않아도, 더 나아가 고객들이 더 많은 제품과 서비스를 구입하도록 유도하지 못하는 경우에도 동료들을 만족시켜야 하는 위치에 놓이게 되는 것이다.

2. SLA를 만들어 '계약서'처럼 취급한다
실패하는 방법은 또 있다. SLA(Service Level Agreement)를 만들어, '내부 고객'들에게 서명하도록 만든 후 계약서처럼 취급한다. 그리고 매번 IT가 SLA를 충족했다고 주장하는 것이다.

그러면 '내부 고객'들은 IT가 해야 할 일을 하지 않는다고 말하기 시작할 것이다. 이는 관계를 소원하게 만드는 지름길이다.

성공하고 싶다면 관계에는 신뢰가 필요하고, 신뢰를 쌓기 위해서는 동료를 존중해야 한다는 점을 명심해야 한다. 동료가 IT를 좋아해야, 서로 협력해 문제를 해결할 수 있다. 계약은 관계 정립이 목적이 아니다. 신뢰가 없고, 심각한 문제가 발생했을 때 취할 조치를 규정하는 것이 목적이다.

3. '내부 사용자'를 조롱한다
잘 알고 있는 내용일 것이다. "다시 확실히 설명해 드리겠습니다. 정전 때문에 부팅이 되지 않는 것입니다. 모르겠어요?", "그 바보 같은 사람이 프린터 3상 플러그를 반대로 삽입했지 뭐야!(동료들의 낄낄거리는 비웃음)"

다른 IT직원들이 (특히 이름까지 구체적으로 언급하며) 다른 부서 동료들을 비웃을 때 동참하라. 아니 더 확실히 실패하고 싶다면, 직접 다른 부서 동료를 면전에서 비웃기 바란다. 그러면 IT부서 사람들은 하나 같이 다른 부서 사람들을 존중하지 않는다는 말이 퍼져 나갈 것이다. 이 또한 쉽게 실패할 수 있는 방법이다.

4. 차지백(Charge-backs)을 실시한다
정보기술을 사용하지 못하도록 유도하는 좋은 방법이 있다. 차지백을 실시하는 것이다. 그냥 차지백이 아니다. CPU 사이클부터 SAN, NAS 스토리지(당연히 분리), 개발자 작업시간, 헬프 데스크 지원까지 모든 비용 중심에서 발생하는 비용을 10분 단위로 상세히 항목 별로 청구하는 차지백을 만든다.

이렇게 하면 협력이 사라진다. 청구 내용이 정확한지, 청구 비용을 책임질 부서가 누구인지를 놓고 논쟁을 벌이게 될 것이다.

5. ROI를 고집한다
아주 중요한 프로젝트에 자금이 투입되지 않도록 만들면 IT는 이내 실패할 수 있다. 그리고 이에 도달하는 방법은 간단하다. IT거버넌스 프로세스에 명확하고 가시적인 투자 수익이 보장되어야 한다고 주장하면 된다.

이렇게 하면 손쉽게 시대에 뒤쳐질 것이다. 비즈니스 부서가 더 빨리 성과를 내도록 도와주는 기술에 예산이 투입되지 않도록 만들고, IT는 입증할 수 없는 영업 측면의 비용을 줄이는 한편, 장기적으로 매출을 증대 시키고 고객 만족을 견인하는 프로젝트들이 뒷전으로 밀릴 것이다.

6. IT프로젝트를 비호한다
비즈니스와 IT부서가 삐걱거리도록 만들고 싶은가? 프로젝트의 결과물을 소프트웨어 전달로 규정하면 된다. 즉 소프트웨어가 요구사항과 사양(명세서)을 충족하면 IT의 할 일이 끝나는 것이다.

이렇게 하면, 비즈니스 부서 관리자가 소프트웨어가 필요한 기능을 제공하지 않는다고 불평할 때, 사양을 충족하기 때문에 소프트웨어에는 아무 문제가 없다고 주장할 수 있다. 또 프로젝트가 요구 사항을 충족하지 않을 경우, 요구 사항이 잘못되었다고 주장할 수 있다. 누구의 잘못이냐고? 당연히 프로젝트를 승인한 비즈니스 부서 관리자의 잘못이다.

이러한 사태를 피하고자 한다면 효과가 있는 방법을 실천할 수도 있다. 프로젝트 명칭부터 시작한다. 그리고 소프트웨어가 아닌 비즈니스 성과를 규정한다. 세일즈포스닷컴(Salesforce.com) 구현 대신 영업 효과 향상 등을 결과물로 규정하는 것이다.


X