프로세스는 제조업에서 ‘공정’이라는 이름으로 널리 사용되는 용어다. 제조업에 있어서의 프로세스는 하드웨어적인 설비에 근접한 인력의 물리적인 작업을 중심으로 진행이 되기 때문에 ‘관찰’하기가 쉽다.
하지만, IT분야에서의 프로세스는 대부분의 활동들이 물리적인 작업이 아니기 때문에 제조업의 프로세스처럼 ‘관찰’하기가 쉽지않다. 이런 연유로, IT조직의 경영층 또는 중간 관리자들은 IT실무자들을 중심으로 실행되는 IT프로세스들이 잘되고 있는 지를 알아내는 데 실패하거나, 어려움을 호소하고 있다.
이번 칼럼에서는 IT조직의 프로세스 관찰에 대해 이야기 해보겠다.
[edit]
1 프로세스에 대한 관찰 #
‘관찰’이라는 말은 사물이나 현상을 객관적으로, 주의깊게 살펴보는 것을 의미한다. 기업내에서 작동하고 있는 ‘프로세스’를 객관적인 시각에서 주의깊게 살펴보는 ‘관찰’이라는 활동은, 프로세스 자체를 수행하느라, 그 내부에 ‘매몰’되는 것을 피하고, 프로세스의 실제 모습과 문제점을 짚어내는 데 매우 중요한 역할을 한다.
따라서 프로세스 관찰은 글로벌 경영기법을 갖춘 기업에서는 거의 예외없이 수행하고 있는 활동이며, 국내 최고 수준의 IT기업들도 여러가지 방법으로 이를 적용했거나, 적용을 고려 중에 있다.
[edit]
2 프로세스 관찰이 없는 IT조직 #
국내 IT조직들이 수행하는 업무들을 관찰해보면, 아직도 상당수의 IT조직들이 프로세스를 ‘실행’하는 데에만 모든 자원을 투입하고 있다. 자신들이 수행하고 있는 프로세스를 객관적으로 관찰하는 역할이 조직내에서 존재하지 않는 것이다. 이러한 IT조직들은 다음과 같은 특징들을 보인다.
-교과서적인 프로세스가 정의되어 있다.
-현실의 프로세스와 교과서적인 프로세스와는 차이가 있다.
-프로세스 우회 경로가 널려 있으며, 똑똑한(?) 직원들이 애용한다.
-프로세스의 의도와 목적이 달성되고 있는지는 아무도 모른다.
-예외 사항을 처리할 수 있는 유연성이 없다.
-측정 지표가 없다.
-현실의 프로세스와 교과서적인 프로세스와는 차이가 있다.
-프로세스 우회 경로가 널려 있으며, 똑똑한(?) 직원들이 애용한다.
-프로세스의 의도와 목적이 달성되고 있는지는 아무도 모른다.
-예외 사항을 처리할 수 있는 유연성이 없다.
-측정 지표가 없다.
[edit]
3 코끼리를 냉장고에 넣는 방법 #
코끼리를 냉장고 넣는 방법에 대한 유머가 한때 유행했었다. 유머에 의하면 코끼리를 냉장고에 넣는 방법은 ‘냉장고 문을 연다’-> ‘코끼리를 넣는다’-> ‘냉장고 문을 닫는다’이다. 만약 코끼리가, 냉장고 크기에 비해 얼마나 큰 동물인지를 모르는 사람이 있다면, 그 사람은 이 방법에 ‘문제가 있다’고 ‘인식’하지 못한다.
IT조직의 변경관리프로세스의 일반적인 순서는 ‘변경을 요청한다.’-> ‘변경을 접수한다.’->’변경영향을 평가한다.’-> ‘변경계획을 수립한다.’->’변경을 실행한다.’->’변경을 테스트한다.’ 이다. IT내부의 실체를 경험해보지 못한 사람은 이 프로세스가 전혀 문제가 없다고 인식할 것이다.
그러나 실제 IT조직에서는 첫번째 활동인 ‘변경을 요청한다.’에서부터 문제가 발생할 수 있다. 변경이 누락되거나, 의도적으로 변경을 요청하지 않는 사례가 IT조직에 빈번하게 발생한다. 즉, 변경 요청이 일어나지 않아서 전체적인 후단의 작업이 깡그리 부정이 되는 경우가 있을 수 있다는 것이다.
프로세스에 대한 객관적인 관찰을 수행하지 않는 IT조직은 이러한 예외사항을 찾아내기가 어려울 수밖에 없으며, 정상적으로 요청된 변경에 대해서만 집중하게 되고, 프로세스가 정상이라는 결론을 내릴 수 있는 함정에 빠질 수가 있다.
[edit]
4 IT프로세스 관찰의 한계 #
앞서 언급한 것처럼 IT 영역에서의 프로세스는 관찰이 어렵다. 실제 IT조직에서 프로세스 관찰을 하려면, 많은 부분을 기록이나 데이터에 의존할 수 밖에 없다. 그러나 그런 기록이나 데이터가 없거나 부실하다면, 사실상 관찰 활동이 불가능하다.
장애프로세스를 관찰한다고 가정하자. 장애프로세스의 목적은 일반적으로 ‘최대한 빠른 시간내에 원상태로 복구’하는 것이다. 그러나, 이러한 목적을 근간으로 장애프로세스를 관찰한다고 가정한다면, 장애가 실제 발생했을 때, 관찰자가 ‘참관’하는 것 말고는, 그간의 장애를 기록한 장애보고서등을 검토해보면서 장애프로세스를 유추해 볼 수 밖에 없다.
그러나 전통적인 IT조직의 장애보고서는 최대한 빠른 시간내에 원상태로 복구했는지를 판단할 수 있는 정보를 포함하고 있지 않는 경우가 많다. 이런 IT조직에서는 장애프로세스를 관찰할 수 없을 뿐더러, 장애프로세스가 ‘작동’되고 있는지조차 확신을 가지지 못한다.
[edit]
5 박제된 프로세스 #
프로세스를 기획하거나 수행하는 IT담당자들이 가장 많이 하는 질문중의 하나가 ‘이런 식으로 프로세스를 수행해도 되나요?’이다. 이러한 질문의 솔직한 의도는 속칭 ‘안전빵’을 기대하는 것이다. 책이나, 표준, 또는 뛰어난 IT조직에서 이런 식의 프로세스를 수행하고 있다면 괜찮다는 것이다.
경험상, 문제점과 사례를 IT담당자들에게 알려주기는 하지만, 정답인지 아닌지를 기대하는 듯한 분위기는 곤혹스럽기 그지없다. 왜냐하면, 지구상의 천차만별 비즈니스, 조직, 사람 그리고 조직내에서 만들어내는 문화 내에서, IT프로세스의 정답을 주장하는 사람이 있다면, 그 사람은 IT업계의 ‘허경영’이기 때문이다.
책이나 국제표준에서 언급하고 있는 IT프로세스들은 수 많은 프로세스 중에 나름 괜찮은 프로세스를 참조해서 기술한 것이다. 따라서, 이러한 프로세스들은 참조용이자 기본 베이스라인일 뿐이지, 우리 조직에 꼭 맞는 프로세스는 아니라는 것이다.
프로세스를 모방하는 것의 이득은 한계가 있다. 그 한계안에 머물러 있는 IT조직들에게서 자주 발견되는 것이 ‘박제된 프로세스’다. 박제된 프로세스를 수행하고 있는 IT조직들은 프로세스내의 개별 활동들에 대해서 ‘왜 해야되는데?’라는 질문에 답변하지 못한다.
따라서, 프로세스 관찰은 IT조직이 고유하게 가지는 프로세스의 의도와 목적을 항상 염두에 두고 실행해야 한다. 그래야만 박제된 프로세스의 틀에서 벗어나, IT조직이 원하는 프로세스를 가질 수 있다.
