사건이 아니라 흐름을 본다
어느 부서에서 자꾸 같은 종류의 오류가 났다.
팀장은 담당자를 불러 주의를 줬다.
다음 달에도 비슷한 오류가 났다. 또 주의를 줬다.
그다음 달에도 반복됐다.
세 번째 회의 때, 팀장이 지쳐서 이런 말을 했다.
“대체 왜 이 사람은 같은 실수를 반복하는 건가요.”
그 자리에서 나는 조용히 물었다.
“그 담당자가 작업을 시작할 때, 필요한 정보가 제때 전달되고 있나요?”
잠시 침묵이 흘렀다.
알고 보니 정보 전달이 항상 늦었고, 당일 오전에야 작업 지시가 왔다.
그 상태에서 서둘러 처리하다 보니 오류가 난 것이었다.
문제는 담당자가 아니었다.
흐름이었다.
무언가 잘못됐을 때, 우리는 주로 결과만 본다.
오류가 났다. 기한을 넘겼다. 성과가 안 나왔다.
그리고 그 결과를 만든 사람을 찾는다.
그런데 결과 뒤에는 언제나 흐름이 있다.
어떤 정보가, 어떤 순서로, 어떤 사람을 거쳐, 어디서 끊겼는가.
결과만 보면 사람이 보인다.
흐름을 보면 구조가 보인다.
“오류가 나기 전에, 어떤 단계가 있었나.”
“어느 지점에서 정보가 끊기거나 늦어졌나.”
“어떤 상황이 이 사람을 서두르게 만들었나.”
이런 질문들이 시선을 결과에서 흐름으로 옮겨 준다.
내가 현장에서 배운 한 가지가 있다.
결과에서 원인을 찾으면, 사람이 보인다.
흐름에서 원인을 찾으면, 구조가 보인다.
자신을 탓하는 사람들에게 묻고 싶은 게 있다.
“당신이 일하는 데 필요한 정보가, 제때 제대로 전달되고 있는가.”
“당신에게 주어진 시간과 자원은 그 일을 잘 할 수 있는 수준인가.”
“실수를 하게 만드는 환경적 조건이 있지 않은가.”
만약 이 흐름 어딘가에 문제가 있다면,
그건 당신의 능력 문제가 아니다.
흐름의 설계 문제다.
물론 개인의 책임이 없다는 뜻은 아니다.
다만 ‘나는 왜 이렇게 못 하지’보다,
‘어떤 흐름이 이 결과를 만들었지’를 먼저 보자는 것이다.
� 이 결과를 만들어낸 흐름은 무엇인가.
이 질문이 시선을 결과에서 구조로 이동시킨다.
그러면 비로소 바꿀 수 있는 것이 보인다.
프로세스 관점은 직장에서만 필요한 게 아니다.
일상의 반복되는 문제에도 똑같이 적용된다.
밤에 잠들기 어렵다면 —
오늘 하루 어떤 흐름이 이 상태를 만들었는지 본다.
아이와 매일 같은 이유로 충돌한다면 —
그 충돌이 일어나는 흐름을 본다.
운동을 작심삼일로 끝낸다면 —
무엇이 3일째 되는 날 흐름을 끊는지 본다.
흐름이 보이면 바꿀 수 있는 지점이 보인다.
그 지점 하나를 바꾸면, 결과가 달라진다.
결과만 보지 말고 흐름을 보라.
원인은 항상 앞단에 있다.
규격이 아니라 구조를 본다 · RISA™ 별이온