흐름의 연결은 데이터의 연결

프로세스 정리의 마지막은 전산 데이터들의 연관성을 한 눈에 펼치는 것

프로세스의 정리에 대해 이전의 아티클에서 다룬 적이 있습니다. 실물의 흐름과 정보의 흐름, 그리고 이것을 관통하는 양적 개념인 자금과 수량의 흐름이 모든 부분에 흐르고 있어야 한다는 내용으로 다루었습니다. 많은 기업에서 이런 컨셉을 토대로 업무 순서도 등을 그리고 이것을 시스템에 심는 작업을 합니다. 그래서 현재 업무 프로세스가 전산화되어 실물과 정보를 실시간으로 확인하고 정기적으로 유량적 실적을 엑스포팅하는 관리 작업을 하게 됩니다. 하지만 시간이 지나면 업무의 흐름은 시장의 변화에 대응하여 바뀔 수 밖에 없고 전산에 심었던 여러가지 프로세스들은 제거 혹은 변경의 니즈를 필연적으로 받을 수 밖에 없습니다. 이 때 과거의 업무 프로세스가 정리된 순서도가 없다면 전체 무엇이 있는지 알 길이 없이 수정 작업을 해야 하며 기업 입장에서는 오라클이나 SAP에 비싼 비용을 주고 만든 각 페이지들이 관리되지 않는 일이 발생합니다.

처음에 업무 프로세스를 전산으로 옮길 때 마지막으로 해야 할 작업으로 이런 업무 프로세스가 녹아든 전산 데이터들이 각 페이지 간에 어떤 연관성이 있는지 각 프로세스 코드별로 연결하는 한 장의 정리도가 필요합니다. 각 코드별로 어떤 정보의 입력과 출력이 코드와 코드 사이에 지나가는지 알 길이 없다면 업무 프로세스를 정리한 표는 그저 잘 정리된 보고서에 불과합니다. 전산 상의 데이터 코드들이 어떤 상관관계에 있는지 상시적으로 전체 한 페이지를 관리하고 직원들이 열람하고 개선할 방향을 전산팀에 역으로 제안해주지 않는다면 각각의 코드들은 개별로 존재하면서 비용만 발생시키고 사장되게 되는 것입니다. 낱개로 존재하는 코드들은 결국 직원들이 활용하지 않습니다. 그런데 그게 어디 어떻게 존재하는지 전산 담당자도 알 길이 없죠. 이렇게 되면 이런 것만 날 잡고 따로 점검하고 제거해야 하는 또 다른 일이 벌어집니다. 처음에 전산 데이터들의 연관관계를 한 페이지에 관리하면 힘이 덜 들 일을 두 번 하게 되는 일이 벌어집니다.

이런 일이 벌어지게 되는 원인은 전산으로 업무 프로세스 정리하는 일이 정확히 '누구의 일이냐' 혹은 '내 일이다'라고 맏는 사람이 없기 때문입니다. 보통 업무 프로세스는 기업에서 PI팀 등에서 주관부서로 관계되는데 이런 기능을 맡는 부서가 없거나 있다고 해도 이것이 기획자와 개발자와의 연결 상에 서로 책임을 미루는 일이 벌어지면 공유지에 떨어진 공처럼 처리할 사람이 없어지고 서로 미루게 되고 그 사이 둘 중 한 명만 담당자가 교체되면 나머지는 모르쇠가 되고 프로세스는 그대로 있으면서도 방치되는 일이 벌어지게 되는 것입니다.

따라서 최초 기업에서 프로세스를 전산으로 심는 값비싼 작업을 진행할 때 마무리인 전산 데이터 코드를 업무 프로세스 순서도처럼 정리하여 한 눈에 정보의 입출력이 전산 프로세스 어디를 지나는지 전 직원이 알 수 있는 정리가 필요합니다. 그리고 PI팀은 직원들이 사용하면서 말하는 불편한 인터페이스나 작업 자체가 바뀐 부분에 대해서 합의된 순서도를 기초로 바꾸는 작업을 진행해야 합니다. 이렇게 되면 낱개로 단독으로 존재하는 전산 프로세스가 없고 괜히 비싼 돈 들여 개발한 레포트가 아무도 모른 채 잠자는 일은 없어질 것입니다. 중요한 것은 이런 PI를 기획하는 작업자와 개발자 간의 책임소재를 한 팀으로 만들어 줄 수 있는 전담팀으로 만드는 작업과 이들의 성과지표를 단순히 돈으로 측정할 수 있느냐라는 개념을 떠나 업무 처리 속도와 정확도를 기초로 성과 인정을 해주는 리더의 이해도에 달려 있습니다.