2021.07.08

기고 | 효과적인 IT프로세스 구축하기 ‘4가지 전제 조건’

Bob Lewis | CIO
조직을 효과적으로 운영하는 열쇠 중 하나는 우수하게 설계되고 관리된 프로세스를 통해 작업 결과물을 전달하는 것이다. 프로세스는 반복 가능하고 예측 가능한 결과라는 형태로 조직의 번영을 이끄는 통로라고 칭송된다. 새로울 것 없는 이야기다.

그러나 CIO가 프로세스를 설계하고 직원들에게 이용법을 교육하면서 프로세스 이니셔티브를 시작한다면 그 CIO는 대수와 삼각법을 거치지 않고 미적분에 등록한 학생이나 다름 없다. 어느 분야에서든 성공하려면 일단 전제 조건이 충족되어야 한다. 

프로세스 이니셔티브가 성공하는 데에는 4가지 전제 조건이 있다. (1) 프로세스 문화, (2) 프로세스와 프랙티스의 차이에 대한 명확한 이해, (3) 프로세스 지표를 설계하고 관리하고 해석하는 능력, (4) 프로세스의 실행에 관여하는 모든 사람들간의 신뢰이다. 

이들 전제 조건이 없다면, 어떤 프로세스 이니셔티브이든, 그것이 ITIL 기반 IT 서비스 관리이든, 표준화된 시스템 개발 수명주기이든, IT 인수 합병 지침이든 성공하기가 어렵다. 반면 이 4가지 근본 원리를 제대로 갖추고 있다면 성공하지 않기가 오히려 어렵다. 
 
Image Credit : Getty Images Bank

프로세스 문화 
‘문화’라는 용어는 다소 모소한 정의에도 불구하고 자주 쓰인다. 비즈니스 관점에서 문화는 ‘여기서 일하는 방식’을 의미한다. 모든 조직 구성원의 결정 및 업무 습관에 뿌리내린 공유된 신념과 전제의 집합이다. 

IT 조직이 프로세스 문화를 가지고 있다면 직원은 표준, 문서화된 프로세스나 절차가 정립되어 있지 않은 상황에서만 임기응변으로 대응할 것이다. 그리고 임기응변으로 대응할 때에도 이들은 미래에 비슷한 상황이 발생할 것에 대비해 포함시켜야 할 잠재적 개선을 문서화할 것이다. 

이는 ‘우리는 꽤 영리하고, 문제를 해결할 것이다’라는 전제 위에서 정립된 문화와 대조된다. 예기치 않은 무언가에 대처할 수 있다는 자신감이 본질적으로 나쁘다는 말이 아니다. 다만 현재 직면하고 있는 것과 유사한 상황을 겪었던 모든 사람보다 자신이 더 영리하다고 생각한다면 곤란하다. 

우수하게 정의된 프로세스를 통해 성공하는 조직에는 모든 관계자가 언제나 ‘여기서 일하는 방식’을 끊임없이 완벽히 이행할 의무가 있다는 태도가 내재되어 있다. 

프로세스와 프랙티스 
프로세스는 정해진 순서와 흐름에 따라 실행되는 일련의 작업이고, 반복 가능하고 예측 가능한 결과를 생성한다. 프로세스는 요리법에 비유될 수 있다. 다시 말해 지침을 정확히 준수하면 맛있는 파엘랴가 만들어진다.

프로세스를 준수하도록 구축된 조직은, 흔히 말하듯이, ‘천재가 설계하고 바보가 실행하는’ 곳이다. ‘바보’보다 ‘평균적인 둔재’가 실제 작업을 하는 사람들에게 더 적절한 표현일 수 있겠다. 그리고 프로세스 설계자가 항상 천재인 것은 아니다. 

평균적인 둔재는 천재보다 숫자가 더 많은 것이 보통이기 때문에 요리법 모델은 수많은 비즈니스 상황에서 무난하게 작용한다. 

그러나 모든 상황이 요리법에 부합하지는 않는다. 법적 소송이 한 실례이다. 모든 소송에서 동일한 방식으로 동일한 단계들을 이행하는 변호사가 있다고 하자. 자신보다 상상력이 더 뛰어난 상대방이 클라이언트의 소송 원인에 동정적일 가능성이 있는 배심원 후보를 더욱 잘 파악하고 배심원을 설득할 수 있는 그럴듯한 화법을 구사한다면 그는 소송에서 이길 가능성이 낮다. 

이것이 우리가 법을 프로세스가 아닌 ‘프랙티스(practice)’라고 부르는 이유이다.  

IT에서 하는 일 중 다수는 프로세스 모델에 들어맞는다. 예를 들어 테스트 환경의 구축 같은 것이다. 

다수이지 전부라는 말은 전혀 아니다. 프로젝트 관리를 예로 들어보자. 이는 일련의 단계를 따르지만, 모든 프로젝트에서 각 단계를 동일한 방식으로 이행하는 것이 좋다는 것은 아니다.  

프로젝트 관리에는 수많은 변수가 관여하고 따라서 만능의 접근법은 있을 수 없다. 프로젝트 후원자는 프로젝트의 진행 시 발생하는 위험과 문제에 대해 저마다 다르게 반응하고, 아울러 위험과 문제 역시 프로젝트마다 다르다. 이는 핵심 프로젝트 팀의 경우에도 마찬가지다. 어떤 팀도 역량과 내부 역학이 서로 같지 않다. SME와 비즈니스 이용자는 말할 것도 없다. 

그리고 프로젝트가 생성하게 될 결과물도 마찬가지로 프로젝트마다 다르다. 예를 들어 고층 빌딩은 항공모함과 근본적으로 다르다. 

다르게 설명하면 다음과 같다. 모든 비즈니스 기능의 목적은 입력을 출력으로 변환하는 것이다 (비즈니스 기능이란 프로세스와 프랙티스를 통칭하는 용어다). 프로세스는 프로세스를 실행하는 사람이 작업 단계들을 얼마나 정확하게 준수하는가에 좌우된다. 프랙티스는 실행자의 깊이 있는 지식, 전문성, 판단에 좌우된다. 

이러한 기초적이고 원론적인 차이를 이해한다면 CIO는 상황에 맞지 않는 해법을 이용하려고 시도하는 덫에 빠지지 않는다.  

또한 프로세스와 프랙티스는 이분법적 선택이 아니라는 점도 유의해야 한다. 둘은 가능성 연속체의 기둥들에 가깝다. 프로세스에 치우친 비즈니스 기능이 있는가 하면 프랙티스에 치우친 기능도 있다. 그러나 전적으로 프로세스이거나 전적으로 프랙티스인 기능은 거의 없다. 

결론적으로, 프로세스와 프랙티스는 서로 다르고, IT 조직에게든, 현업 조직에게든 작업을 완수하는 데 동등하게 중요한 수단이다. 현재의 작업에 맞는 적절한 수단을 선택해야 한다. 

지표 
진부한 말이지만, 측정할 수 없다면 관리할 수 없다. 이는 측정을 잘못하면 관리를 잘못하게 된다는 뜻이기도 하다.

지표를 확립한다면 이는 어떤 비즈니스 기능이 건강한지 아니라면 통찰과 엄격함을 위한 조율이 필요한지를 파악하는 데 유용하다. 아래의 설명은 복잡한 주제를 매우 간단하게 요약한 것이다. 

프로세스 최적화 지표 
관리자는 아래의 6가지 지표 가운데 3가지 이하로만 프로세스를 최적화할 수 있다. 

• 고정 비용 : 프로세스가 작용하는 데 필요한 시스템 및 인프라를 갖추는 데 들어가는 1회성 투자 
• 증분 (한계) 비용 : 하나의 트랜잭션(작업)을 처리하는 데 따른 추가 비용. 증분 비용은 상각 고정 비용을 포함하지 않는다. 
• 순환 시간 : 한 작업을 처리하는 데 필요한 시간. 입력을 출력으로 변환시키는 시간이다. 
• 처리량(처리 능력) : 비즈니스 기능이 일정 시간 단위 내에 달성할 수 있는 출력의 수 
• 품질 : 규격의 준수. 다시 말해 결함의 부재. 
• 우수성 : 유연성(비정상적 상황에 적응하는 능력 및 커스터마이징 능력). 

프로세스 또는 프랙티스에 대한 지표의 확립은 이들 최적화 지표 가운데 가장 중요한 2~3가지 지표를 결정하는 것으로 시작한다. 이들이 측정에 사용된다. 2~3가지만 사용하는 이유는 지표들간의 상충이 불가피하기 때문이다. 

SLA를 버려라 
SLA(Service Level Agreement)는 비즈니스 기능을 측정하는 인기 있는 방식이지만 잘못된 방식이기도 하다. 

서비스 수준은 두 부분으로 된 지표이다. 이들은 (1) 허용 가능한 성과의 최소 기준과 (2) 이 최소 기준을 충족해야 하는 사건의 비율이다. 

예를 들어 레벨 1 사건에서, 서비스 창구 매니저가 순환 시간이 1차적으로 가장 중요한 최적화 지표라고 결정했다고 하자. 허용 가능한 성과의 최소 기준으로 초기 대응 시간을 5분, 해결까지의 시간을 1시간으로 정했다. 그리고 2차적으로는 95% 또는 그 이상의 수준 한 사건이 1차적으로 확립된 기준에 부합해야 한다. 

SLA는 외주 시 필요악이다. 외주를 주는 회사와 외주를 받는 회사 모두 성과가 계약 요건에 부합하는 지 알아야 하기 때문이다. 그러나 비즈니스 기능 관리의 경우 오래된 평균 및 표준 편차 지표가 훨씬 더 유용하다. 

신뢰 
IDG / Bob Lewis
계속 움직여라: 21 세기 정보 기술을 위한 선언(Keep the Joint Running: A Manifesto for 21st Century Information Technology)’에서 필자는 ‘프로세스 불신 고리(process distrust loop)’라는 개념을 소개했다. 이는 불신의 실질적 대가를 보여준다. 프로세스를 진행할 때 불신은 진행 중인 작업을 수취하는 사람 또는 집단이 해당 작업이 어떤 면에서 결함이 있다고 생각하도록 만든다. 이는 불평, 재작업, 지연, 낭비, 전반적인 불쾌감으로 이어진다. 

그러면서 다시 불신이 가중된다. 

신뢰가 있다면 심지어 설계가 부실한 프로세스조차 원활하게 진행될 수 있다. 신뢰가 없다면 어떤 프로세스도 의도한 결과를 달성할 가망이 없다. 
 
결론 
이 4가지 근본 원리, 다시 말해 프로세스 문화, 프로세스와 프랙티스의 구분, 적절한 지표를 정하고 추적할 능력, 그리고 무엇보다 모든 관여자의 신뢰가 작업을 완수하는 IT 조직을 만들어낸다.

 * Bob Lewis는 IT와 현업 관계, 전략 실행 계획에 중점을 IT 컨설턴트다. ciokr@idg.co.kr
 



2021.07.08

기고 | 효과적인 IT프로세스 구축하기 ‘4가지 전제 조건’

Bob Lewis | CIO
조직을 효과적으로 운영하는 열쇠 중 하나는 우수하게 설계되고 관리된 프로세스를 통해 작업 결과물을 전달하는 것이다. 프로세스는 반복 가능하고 예측 가능한 결과라는 형태로 조직의 번영을 이끄는 통로라고 칭송된다. 새로울 것 없는 이야기다.

그러나 CIO가 프로세스를 설계하고 직원들에게 이용법을 교육하면서 프로세스 이니셔티브를 시작한다면 그 CIO는 대수와 삼각법을 거치지 않고 미적분에 등록한 학생이나 다름 없다. 어느 분야에서든 성공하려면 일단 전제 조건이 충족되어야 한다. 

프로세스 이니셔티브가 성공하는 데에는 4가지 전제 조건이 있다. (1) 프로세스 문화, (2) 프로세스와 프랙티스의 차이에 대한 명확한 이해, (3) 프로세스 지표를 설계하고 관리하고 해석하는 능력, (4) 프로세스의 실행에 관여하는 모든 사람들간의 신뢰이다. 

이들 전제 조건이 없다면, 어떤 프로세스 이니셔티브이든, 그것이 ITIL 기반 IT 서비스 관리이든, 표준화된 시스템 개발 수명주기이든, IT 인수 합병 지침이든 성공하기가 어렵다. 반면 이 4가지 근본 원리를 제대로 갖추고 있다면 성공하지 않기가 오히려 어렵다. 
 
Image Credit : Getty Images Bank

프로세스 문화 
‘문화’라는 용어는 다소 모소한 정의에도 불구하고 자주 쓰인다. 비즈니스 관점에서 문화는 ‘여기서 일하는 방식’을 의미한다. 모든 조직 구성원의 결정 및 업무 습관에 뿌리내린 공유된 신념과 전제의 집합이다. 

IT 조직이 프로세스 문화를 가지고 있다면 직원은 표준, 문서화된 프로세스나 절차가 정립되어 있지 않은 상황에서만 임기응변으로 대응할 것이다. 그리고 임기응변으로 대응할 때에도 이들은 미래에 비슷한 상황이 발생할 것에 대비해 포함시켜야 할 잠재적 개선을 문서화할 것이다. 

이는 ‘우리는 꽤 영리하고, 문제를 해결할 것이다’라는 전제 위에서 정립된 문화와 대조된다. 예기치 않은 무언가에 대처할 수 있다는 자신감이 본질적으로 나쁘다는 말이 아니다. 다만 현재 직면하고 있는 것과 유사한 상황을 겪었던 모든 사람보다 자신이 더 영리하다고 생각한다면 곤란하다. 

우수하게 정의된 프로세스를 통해 성공하는 조직에는 모든 관계자가 언제나 ‘여기서 일하는 방식’을 끊임없이 완벽히 이행할 의무가 있다는 태도가 내재되어 있다. 

프로세스와 프랙티스 
프로세스는 정해진 순서와 흐름에 따라 실행되는 일련의 작업이고, 반복 가능하고 예측 가능한 결과를 생성한다. 프로세스는 요리법에 비유될 수 있다. 다시 말해 지침을 정확히 준수하면 맛있는 파엘랴가 만들어진다.

프로세스를 준수하도록 구축된 조직은, 흔히 말하듯이, ‘천재가 설계하고 바보가 실행하는’ 곳이다. ‘바보’보다 ‘평균적인 둔재’가 실제 작업을 하는 사람들에게 더 적절한 표현일 수 있겠다. 그리고 프로세스 설계자가 항상 천재인 것은 아니다. 

평균적인 둔재는 천재보다 숫자가 더 많은 것이 보통이기 때문에 요리법 모델은 수많은 비즈니스 상황에서 무난하게 작용한다. 

그러나 모든 상황이 요리법에 부합하지는 않는다. 법적 소송이 한 실례이다. 모든 소송에서 동일한 방식으로 동일한 단계들을 이행하는 변호사가 있다고 하자. 자신보다 상상력이 더 뛰어난 상대방이 클라이언트의 소송 원인에 동정적일 가능성이 있는 배심원 후보를 더욱 잘 파악하고 배심원을 설득할 수 있는 그럴듯한 화법을 구사한다면 그는 소송에서 이길 가능성이 낮다. 

이것이 우리가 법을 프로세스가 아닌 ‘프랙티스(practice)’라고 부르는 이유이다.  

IT에서 하는 일 중 다수는 프로세스 모델에 들어맞는다. 예를 들어 테스트 환경의 구축 같은 것이다. 

다수이지 전부라는 말은 전혀 아니다. 프로젝트 관리를 예로 들어보자. 이는 일련의 단계를 따르지만, 모든 프로젝트에서 각 단계를 동일한 방식으로 이행하는 것이 좋다는 것은 아니다.  

프로젝트 관리에는 수많은 변수가 관여하고 따라서 만능의 접근법은 있을 수 없다. 프로젝트 후원자는 프로젝트의 진행 시 발생하는 위험과 문제에 대해 저마다 다르게 반응하고, 아울러 위험과 문제 역시 프로젝트마다 다르다. 이는 핵심 프로젝트 팀의 경우에도 마찬가지다. 어떤 팀도 역량과 내부 역학이 서로 같지 않다. SME와 비즈니스 이용자는 말할 것도 없다. 

그리고 프로젝트가 생성하게 될 결과물도 마찬가지로 프로젝트마다 다르다. 예를 들어 고층 빌딩은 항공모함과 근본적으로 다르다. 

다르게 설명하면 다음과 같다. 모든 비즈니스 기능의 목적은 입력을 출력으로 변환하는 것이다 (비즈니스 기능이란 프로세스와 프랙티스를 통칭하는 용어다). 프로세스는 프로세스를 실행하는 사람이 작업 단계들을 얼마나 정확하게 준수하는가에 좌우된다. 프랙티스는 실행자의 깊이 있는 지식, 전문성, 판단에 좌우된다. 

이러한 기초적이고 원론적인 차이를 이해한다면 CIO는 상황에 맞지 않는 해법을 이용하려고 시도하는 덫에 빠지지 않는다.  

또한 프로세스와 프랙티스는 이분법적 선택이 아니라는 점도 유의해야 한다. 둘은 가능성 연속체의 기둥들에 가깝다. 프로세스에 치우친 비즈니스 기능이 있는가 하면 프랙티스에 치우친 기능도 있다. 그러나 전적으로 프로세스이거나 전적으로 프랙티스인 기능은 거의 없다. 

결론적으로, 프로세스와 프랙티스는 서로 다르고, IT 조직에게든, 현업 조직에게든 작업을 완수하는 데 동등하게 중요한 수단이다. 현재의 작업에 맞는 적절한 수단을 선택해야 한다. 

지표 
진부한 말이지만, 측정할 수 없다면 관리할 수 없다. 이는 측정을 잘못하면 관리를 잘못하게 된다는 뜻이기도 하다.

지표를 확립한다면 이는 어떤 비즈니스 기능이 건강한지 아니라면 통찰과 엄격함을 위한 조율이 필요한지를 파악하는 데 유용하다. 아래의 설명은 복잡한 주제를 매우 간단하게 요약한 것이다. 

프로세스 최적화 지표 
관리자는 아래의 6가지 지표 가운데 3가지 이하로만 프로세스를 최적화할 수 있다. 

• 고정 비용 : 프로세스가 작용하는 데 필요한 시스템 및 인프라를 갖추는 데 들어가는 1회성 투자 
• 증분 (한계) 비용 : 하나의 트랜잭션(작업)을 처리하는 데 따른 추가 비용. 증분 비용은 상각 고정 비용을 포함하지 않는다. 
• 순환 시간 : 한 작업을 처리하는 데 필요한 시간. 입력을 출력으로 변환시키는 시간이다. 
• 처리량(처리 능력) : 비즈니스 기능이 일정 시간 단위 내에 달성할 수 있는 출력의 수 
• 품질 : 규격의 준수. 다시 말해 결함의 부재. 
• 우수성 : 유연성(비정상적 상황에 적응하는 능력 및 커스터마이징 능력). 

프로세스 또는 프랙티스에 대한 지표의 확립은 이들 최적화 지표 가운데 가장 중요한 2~3가지 지표를 결정하는 것으로 시작한다. 이들이 측정에 사용된다. 2~3가지만 사용하는 이유는 지표들간의 상충이 불가피하기 때문이다. 

SLA를 버려라 
SLA(Service Level Agreement)는 비즈니스 기능을 측정하는 인기 있는 방식이지만 잘못된 방식이기도 하다. 

서비스 수준은 두 부분으로 된 지표이다. 이들은 (1) 허용 가능한 성과의 최소 기준과 (2) 이 최소 기준을 충족해야 하는 사건의 비율이다. 

예를 들어 레벨 1 사건에서, 서비스 창구 매니저가 순환 시간이 1차적으로 가장 중요한 최적화 지표라고 결정했다고 하자. 허용 가능한 성과의 최소 기준으로 초기 대응 시간을 5분, 해결까지의 시간을 1시간으로 정했다. 그리고 2차적으로는 95% 또는 그 이상의 수준 한 사건이 1차적으로 확립된 기준에 부합해야 한다. 

SLA는 외주 시 필요악이다. 외주를 주는 회사와 외주를 받는 회사 모두 성과가 계약 요건에 부합하는 지 알아야 하기 때문이다. 그러나 비즈니스 기능 관리의 경우 오래된 평균 및 표준 편차 지표가 훨씬 더 유용하다. 

신뢰 
IDG / Bob Lewis
계속 움직여라: 21 세기 정보 기술을 위한 선언(Keep the Joint Running: A Manifesto for 21st Century Information Technology)’에서 필자는 ‘프로세스 불신 고리(process distrust loop)’라는 개념을 소개했다. 이는 불신의 실질적 대가를 보여준다. 프로세스를 진행할 때 불신은 진행 중인 작업을 수취하는 사람 또는 집단이 해당 작업이 어떤 면에서 결함이 있다고 생각하도록 만든다. 이는 불평, 재작업, 지연, 낭비, 전반적인 불쾌감으로 이어진다. 

그러면서 다시 불신이 가중된다. 

신뢰가 있다면 심지어 설계가 부실한 프로세스조차 원활하게 진행될 수 있다. 신뢰가 없다면 어떤 프로세스도 의도한 결과를 달성할 가망이 없다. 
 
결론 
이 4가지 근본 원리, 다시 말해 프로세스 문화, 프로세스와 프랙티스의 구분, 적절한 지표를 정하고 추적할 능력, 그리고 무엇보다 모든 관여자의 신뢰가 작업을 완수하는 IT 조직을 만들어낸다.

 * Bob Lewis는 IT와 현업 관계, 전략 실행 계획에 중점을 IT 컨설턴트다. ciokr@idg.co.kr
 

X