: 지난 호 바로가기 :

 

  지난 회에는 흐름대로 활동을 그려보았습니다. 하지만 이것만으로는 프로세스를 이해 할 수 없습니다. 프로세스를 이해 할 수 있을 정도의 맵을 작성하기 위해서 다음과 같은 것들이 포함되어야 할 것입니다. 활동(Activity)로 들어오는 트랜젝션(Transaction:프로세스내에 이동하는 것들)을 어떻게 받아 들일 것인지, 작업 시간은 얼마나 걸리는지, 이때 필요한 설비나 인원은 어떤 것이며 몇 개나 필요하며, 비용은 얼마나 들어가는지...
고려해야 할 요소들이 상당히 많이 있습니다. 이것을 크게 묶어 보면 입/출력, 시간, 비용, 리소스에 대한 부분일 것입니다. 이런 것을 고려하여 작성된 이발소의 예입니다. 전회에 작성된 모델과는 다른 모습입니다. 프로세스모델은 작성하는 사람에 따라 다른 모습을 가질 수 있습니다. 지면을 줄이기 위해 서브 프로세스는 생략하였으며, 분기 되야 하는 조건 등이 빠져있어 완성된 프로세스맵은 아닙니다.

하지만 이 프로세스 맵은 작업 시간과 필요한 자원에 대한 정보는 보여 주고 있습니다. 7번 "이발을 한다"의 경우 작업자 한명이 이발용 가위1개를 가지고 20분에서 40분 사이에 걸쳐(정규분포) 작업을 하고 있는 것을 나타내고 있습니다. 이렇게 프로세스맵을 작성하면서 문제점들이 들어나는 경우가 많이 있습니다. 또한 프로세스맵을 작성하면서 해당 프로세스에 대해 보다 정확한 이해를 할 수 있다는 것도 부수적으로 얻을 수 있는 이득입니다. 이렇게 작성된 프로세스맵은 6시그마 프로젝트나 BPM프로젝트, 혹은 ERP, SCM, CRM등의 IT시스템 구축에도 사용 할 수 있습니다.

그리고, 지금부터 설명드릴 시뮬레이션을 통해서 이 프로세스가 가지고 있는 능력이나 시그마수준을 측정하고 현재 수준의 문제와 이에 대한 해결 안들을 확인하고 그 중에서 최선의 선택을 할 수 있게 됩니다. 시뮬레이션을 하기 위해서는 프로세스맵 외에 시나리오가 필요합니다. 프로세스맵은 가동하기위한 설비와 인원을 배치한 것으로 생각 하면 됩니다.

시나리오는 갖추어놓은 시스템을 어떤 식으로 운전 할 것인지 정의하는 부분입니다. 트랜젝션들은 어떤 식으로 투입되거나 투입 할 것인지 하루일정(운전시간)은 어떻게 잡을 것인지, 투입되는 트랜젝션들의 종류(특성)는 어떤 것들이 있는지 즉, 시시각각 변하는 주변환경을 적용할 수 있게 하여야 합니다. 시나리오설정을 하다 보면 프로세스가 바뀌어야 하는 경우도 발생하게 됩니다. 사업환경이 바뀌었을 때 프로세스 맵은 유지한 채로 시나리오를 바꾸어 주는 것으로 바뀌는 사업환경에 대한 분석을 할 수 도 있습니다.

한가지 측정 지표만으로 프로세스를 분석할 경우 개선후의 결과가 변화가 없는 경우가 생길 수 있습니다. 실제로 국내 굴지의 장치 산업체에서도 Bottle Neck이 발생되는 곳에 투자하는 개선안을 적용시켰지만, 결과는 좋지 않게 나온 경우가 있습니다. 원인은 Neck이 걸리는 부분이 다른 곳으로 전이되어서 일어난 현상입니다.

이렇게 시간의 흐름에 따라서 다른 모습을 보이는 프로세스를 문서화하고 그것을 분석한다는 것은 상당한 어려움과 위험 요소를 가지고 있습니다. 프로세스를 정확하게 이해 하기위해서는 어느 순간을 붙잡아서 보는 것이 아니라 프로세스의 흐름에 맞는 기간을 설정하여 그 기간에 움직이는 모습을 보는 4차원적 시각을 가져야 할 필요가 있습니다. 즉, 물리적인 공간만을 고려하는 것이 아니고 시간의 흐름에 따른 변화도 고려 되어야 한다는 것입니다.

이와 유사한 경우를 아래 사례에서도 찾을 수 있습니다. 일반적인 업무를 진행하고 있는 모습을 모델링한 예입니다. 한달간 처리하고 있는 업무량을 늘릴 것을 목적으로 진행하였습니다. 개선을 의해 적용한기본적인 사상은 자원을 추가 하는 것입니다. 자원을 추가 하여 처리량을 늘리는 단순한 발상이지만 여기에는 전에 말씀 드린 시간에 따른 변화라는 위험요소가 숨겨져 있습니다. As-Is상태를 측정 해보았을 때 아래와 같은 데이터를 얻을 수 있었습니다.

이 데이터에서 우리가 얻을 수 있는 것은 기자/작가라는 부문에서 408건의 업무가 지연 되었고 이곳이 병목 구간이라는 것을 알 수 있습니다. (다음으로 병목이 발생하는 업무는 제작부문 216건입니다.)

기자와 작가부문에 자원을 추가 하여 시뮬레이션한 결과를 보면 기자/작가 부문에 지연되는 건수는 줄지만 처리량은 오히려 줄어 버리게 됩니다. 그렇다고 다른 곳으로 병목이 옮겨 가지도 않았습니다.

이런 경우 여러 가지 상황을 적용하여 시뮬레이션을 해 보아도 되지만 six sigma 도구 중 DOE기법을 사용하여 자원(인자)을 다르게 할당하였을 때 나타나는 결과를 보게 됩니다. (DOE 과정은 생략 하였습니다.)

결과들을 모아보면

이런 결과를 볼 수 있습니다.

또 다른 어떤 경우는 업무 처리량이라는 지표는 잡았지만, 영업이익이라는 지표는 거꾸로 가버리는 경우도 발생하기도 합니다.

이렇게 동시에 여러 가지의 지표를 고려하며, 생명체처럼 서로 영향을 주는 factor들로 이루어진 프로세스에 대한 개선을 한다는 것은 개선안이 여러 가지 위험요소를 가질 수 있으며 개선 결과도 예측 하기 어렵기 때문에 지금까지 해야 한다는 당위성만 강조 되어 왔습니다. 이런 문제를 어느 정도 해소 해줄 수 있는 시뮬레이션 도구 역시 도구를 익혀야 하는 시간과 도입을 위한 비용의 문제로 사용되지 않았었습니다. 이제는 IT 기술의 발전으로 짧은 시간에 익혀서 일반적인 도구 수준의 비용으로 사용 할 수 있게 되었습니다.

다음 회에서는 최근 이슈화 되고 있는 두 가지 Lean sigma에 사용되는 VSM과 BPM에 사용되는 BPEL에 대한 부분을 말씀 드리겠습니다.