블로그 이미지
Max.

calendar

        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30  

Notice

2009.07.10 09:00 Business관련

이전글에서 우리의 업무는 측정되어지고 있다는 가정하에서 그 측정을 분석하는 몇가지 툴에 대해서 이야기해보겠습니다. 만약 Trac 같은 이슈 트랙커를 사용하여 그 측정값을 가지고 있고, 지속적을 측정가능한 상태를 유지하고 있다면, 다음과 같은 몇가지 툴로 그 데이터를 분석해볼수 있습니다. 사실 대기업이나 중규모 이상의 기업은 업무프로세스를 시스템화 하여(ERP, ITSM, 그룹웨어 등), 자체적으로 분석가능한 상태를 유지하고  있습니다. 이예는 그런 시스템이 없이 개발업무를 하는 소규모 기업에 적용 가능할만한 예 입니다.

- Pareto Chart
- Run Chart
- Histogram
- Fishbone Diagram(Cause-effect Diagram)

노파심에서 말하지만, 위에 언급된 것은 비전문가인 우리가 이해하기 쉬운것만 골랐습니다. 6시그마에서 사용되는 통계 기법 툴은 아주 다양하며, 일부 고급기법은 이해하기도 어려울 정도로 복잡하기도 합니다. 6시그마 관련되어서는 여러서적이 있고, 자격증 관련 카페도 많으며, 실제 성과를 이룬 블랙밸트도 상당수 존재 합니다. 여기서는 어디까지나 실무에 바로쓸수 있는 쉬운것만 골라 설명합니다. 이제 예제를 통해서 설명해 보겠습니다.

A사의 개발분야 운영팀은 여러 고객의 사이트를 관리하고 있습니다. 각각의 사이트 마다 담당자가 정해져 있고, 그 업무 Flow는 다음과 같습니다.(업무를 고객의 요구사항 종류에 따라 여러개도 분류될수 있지만 여기서는 하나로 단순화 시켰습니다.)

고객의 Call(요구사항 접수) -> 개발팀장의 업무 분배 -> 개발착수 -> 개발완료 -> 업무종료

위 과정은 고스란히 이슈트랙커에 해당 기록이 남습니다. 각각의 개발자는 주여진 업무에 따라 개발을 진행하면 됩니다. 이제부터 팀장 또는 관리자는 해당 업무를 진행해옴으로써 무엇이 문제가 되는지 분석하기 위해 노력할 일만 남았습니다. 위와 같은 조건으로 기록이 한달 이상 지속적으로 유지되어 온다면, 아마도 아래처럼 그 데이터를 얻을수 있고, 얻는 동안에도 데이터는 지속적으로 쌓이고 있을것입니다. 업무는 계속되고 있어야 하니까요.

업무프로세스 : 고객의 Call(요구사항 접수) -> 개발팀장의 업무 분배 -> 개발착수 -> 개발완료 -> 확인 및 종료
[가상 데이터]
번호 프로세스 1.접수 2.업무분장 3.배정확인 4.개발완료 5.확인/종료
1 Task1 10 5 10 31 10
2 Task2 15 6 12 33 15
3 Task3 11 4 11 35 11
4 Task4 9 7 15 37 15
5 Task5 40 8 14 33 9
6 Task6 9 5 13 58 13
7 Task7 7 6 16 39 16
8 Task8 1 9 14 10 12
9 Task9 9 8 15 33 18
10 Task10 10 7 16 40 60
11 Task11 11 4 12 61 15
12 Task12 33 5 18 35 13
13 Task13 12 6 60 39 1
14 Task14 14 8 15 40 15
15 Task15 11 7 45 39 2
16 Task16 12 7 19 2 16
17 Task17 19 4 15 60 14
18 Task18 9 5 14 4 17
19 Task19 9 8 13 43 16
20 Task20 8 55 1 45 12
21 Task21 9 5 15 33 19
22 Task22 8 6 2 35 44
23 Task23 7 8 16 37 12
24 Task24 8 9 14 37 15
25 Task25 9 7 15 55 14
26 Task26 6 5 18 51 13
27 Task27 11 4 17 45 10
28 Task28 1 5 16 45 14
29 Task29 11 8 12 43 15
30 Task30 12 9 19 40 16
31 Task31 13 1 60 43 12
32 Task32 11 44 12 40 18
33 Task33 12 8 16 39 56
34 Task34 9 5 14 31 16
35 Task35 10 9 15 2 3
36 Task36 9 6 18 39 18

이 데이터를 기준으로 위에 나열된 분석기법들을 적용해 봅니다. (아래는 실제 엑셀로 위 데이터를 그래프로 만들어 보인 것입니다.)

Run Chart
추세 그래프라고도 하며, 데이터의 시간 경과에 따른 패턴을 분석하는데 목적이 있습니다. 현재 업무프로세스에서 어떻게 진행되고 있는지를 볼수 있어서 즉각적인 조치를 취할수도 있는 그래프 입니다. 실제 사용할때는 월별로 극단점에 대해서 코멘트를 닳고 분석시 극단점에 대해서 이유를 설명할수 있어야 합니다.

Histograme
일명 돗수분포표 또는 종모양 그래프로 잘 알려진 그래프 입니다. 지금은 데이터가 작아서 종모양 스럽진 않지만, 많은 데이터가 쌓이면 비슷해 집니다.(물론 표준에 접근하지 않는 엉망인 프로세스나 공통점을 찾을수 없는 잘못된 집합에서는 다른 그림이 나올수 있습니다.) 여기서는 해당 업무프로세스를 이해하는게 목적이 있습니다. 어떤 업무를 수행하는데 하한값과 상한값이라는 기준을 마련하고, 그 기준에서 벗어나는 점들에 대한 원인분석 작업을 위한 준비를 하는데 중요한 자료가 됩니다.

Pareto
파레토는 20:80 법칙으로 잘 알려진 기법으로 가장 중요하고, 파급효과가 큰 요소(20%투자)를 먼저 해결하면, 전체의 효율에 많은 영향(80%효과)을 준다는 원리에서 나왔습니다. 절대적으로 그런것은 아니지만, 보편적으로 가장 많은 결함요소로 지목된 요소 하나를 제거하면, 그만큼 파급효과가 많다는 원리 입니다. 이 기법은 사실 아주 많은 부분에서 응용이 가능합니다. 회의에서도 어떤 안건은 먼저 해결하는야 정의 할때도 이 원리를 이용하여 보다 신속히 의사결정을 할수 있습니다.

Fishbone
인과관계 도표라고도 하는데, 이것은 지금까지 데이터에 대한 탐색과정에서 프로세스를 조하하여 어떤 것을 알아내기 위해 살펴보는 행위(중요한 소수 찾기)였다면, Fishbone은 그러한 중요한 원인(소수)으로 부터 가설을 도출하기 위한 기법에 쓰입니다. 탐색과정을 통해서 알아낸 지식을 이용하여 가장 그럴싸한 결함 원인이 무엇인가를 브레인스토밍 하여 원인을 분석하고, 가설을 도출해 냅니다. 결함해결을 목표로 주요요소(5M1P)를 대입하여 브레인스토밍 합니다.

기타 방법으로 CTQ트리와 SIPOC, 추정 평가 트리(앞에 두개가 짬뽕된) 등이 있습니다. 위에 언급된 내용을 흐름별로 간단히 도식하면 아래와 같이 나타낼수 있습니다.
이런 과정을 통해서 측정가능한 상태를 유지하는 가운데 분석될수 있는 데이터로 결함을 찾고 결함을 제거하기 위해 노력하고, 끊임없이 반복하여, 업무가 예측가능한(주요 결함을 제거하여) 상태를 유지할수 있을때 장기적인 계획을 세울수 있고, BHAG을 구상하고, 비전에 대해 이야기 할수 있습니다. 물론 선 비전과 전략, 후 표준과 개선도 좋은 방법입니다.

이 방법의 전제조건은 '측정가능해야 한다' 입니다. 이것이 사실 처음 하는 기업의 현실에서는 생각보다 어려운 일입니다. 모든 업무가 생산라인 처럼 절차적으로 진행된다기 보다는 병렬적으로 진행되니(프로세스가 미흡하거나 잘못되었거나, 아예 없거나), 측정에 변수가 너무 많습니다. 또한 XP나 스크럼을 사용하는 조직이라면, 개개인의 업무역량을 정확히 측정해 낸다는 것은 정말 어렵습니다. 병렬구조에서는 설계와 동시에 UI또는 비지니스로직을 구현한다면, 단순히 시작시간과 끝시간으로 프로세스를 측정할수 없고, 투입된 시간 또는 단위로 기록해야 하는데, 그러면 측정 때문에 개발자들의 업무효율을 오히려 헤치는 꼴이 됩니다. 적절한 타협점을 찾아야 하는데, 현실에서는 그것이 쉽지 않습니다.

여기서 혼란이 생깁니다. '임무중심의 자가발전적'인 문화 즉, 스크럼에서 문제중심으로 스크럼을 짜게 되었을때 해당 업무에 대한 해결은 어떻게 측정되고 분석되어야 하느냐 입니다. 분명, 중앙 집중식 통제에 의한 조직보다는 임무중심의 카오스적인 조직이 더 발전된 조직이라고 생각하는데, 과연 이 두가지점을 어떻게 바라봐야 하는지 말이죠. 여기서 정리가 안된듯한 느낌입니다. 많은 조직들이 업무의 품질을 높이기 위해 위와 같은 통계적 기법('측정할수 없는것은 관리(개선)할수 없다' 라는)을 적용하고 있는데(현재도), 이것은 중앙 집중식 통제 방법 중에 하나 입니다. 이것은 카오스 현상을 촉발할수 없습니다.

그럼 어떻게 해야 할까요? 통계적 기법은 상당부분 검증되어서 많은 기업들이 적용하고 있고, 인기있는 경영의 품질향상 기법 중에 하나 입니다. 또한, 스크럼 같은 개발 프로세스(업무) 기법 역시 자기조직화 부분에서 상당히 진화된 방법이라 생각 됩니다. 이 두가지가 전혀 다른 사상을 기반으로 하는데, 둘은 조화가 가능한 건지, 아니면 둘중 하나를 버려야 하는건지 고민이 필요합니다.

다음에 위와 같은 고민에 관해서 몇가지 도움이 될만한 경영전문가의 글(BSC,KPI의 폐해 같은...)을 참조하여, 그에 대해 내 문제영역에 대한 고민을 풀어 보겠습니다. 위와 같은 고민은 해당 전문가(심지여 사상가나 학자들까지도)들도 여러가지 의견이 있나 봅니다.(통계에 대한 오해는 '괴짜통계학' 책에서 힌트를 얻을수 있습니다.)

신고
posted by Max.

티스토리 툴바