업무 효율의 최적화와 극대화를 이루는 법

비효율적인 프로세스란?

이미 존재하는 프로세스는 그게 효율적이든 비효율적이든 아무리 잘해봐야 큰 성과로 인정받지 못한다.

 

이십 년 가까이 회사 생활을 하면서 무수히 많은 비지니스 프로세스들을 접하고 수행을 했었다. 그중에 어떤 프로세스들은 전임자로부터 인수인계를 받는 그 순간부터 온갖 두통이 밀려오며 망했다는 느낌을 강하게 주는 것들이 있었다.

 

그런 프로세스들의 특징 중 하나는 전임자들도 비효율성 때문에 그 프로세스를 완벽하게 파악하고 있지 못할 확률이 크기 때문에 인수인계 자체도 제대로 이뤄지지 않을 가능성이 크다.

 

최악의 상황은 전임자가 회사를 떠나기 때문에 단기간에 비효율적인 프로세스의 불완전한 인수인계가 이뤄지고 홀로 남겨진 상황인데 나도 이런 최악의 순간을 겪은 적이 몇 번 있다.

 

개중에 하나는 Risk Insurance Valuation이라는 프로세스였다. 긴급재난 시에 대비하여 회사 중요 자산에 대한 보험을 들 때, 보험 회사는 피보험 회사에 존재하는 모든 자산들을 (부동산, 장비, 소프트웨어, 데이터 웨어하우스, 사무실 가구, 라이센스 등등) 현재 기준으로 다시 가치 평가를 해서 재난이 발생했을 시 복구비용을 산정하여 보험비를 책정한다.

 

기본 비지니스 요구사항(business requirements) 자체는 간단했다. 데이터 베이스에서 회사 내 모든 주요 자산 정보를 뽑고 공적인 기관에서 제공하는 인덱스를 주요 자산들의 원가에 곱해서 현재 가치를 구하는 것이었다.

 

이렇게 간단할 수 있는 프로세스를 복잡하게 만드는 요인들이 여럿 있었는데 그것을 하나씩 나열해 가며 짚어보겠다.

 

Inefficient and ineffective process

 

다수의 다양한 데이터 소스: 비지니스나 파이낸스 부서에서 데이터 소스는 보통 ERP 시스템이다. 중소, 중견 기업들의 경우 회사 내에 하나의 ERP가 존재할 확률이 크지만 대기업의 경우, 이 회사가 M&A를 통해 성장을 해왔다면 최소 2개에서 최악의 경우 5~7개의 독립적인 ERP 시스템을 운용하고 있을 경우가 많다. 거기에 Billing system이나 Asset management과 같은 독립적인 시스템이 ERP와 함께 운용이 되고 있을 겨우도 있다. 예를 들고 있던 프로세스의 경우 3개의 SAP, 1개의 PeopleSoft, 1개의 SAP inventory system, 그리고 기업 외부 정보 (인덱스)가 있어다. 다수의 시스템이 존재한다면 시스템마다 다른 방식으로 데이터를 추출해야 한다. 운이 좋은 경우 데이터베이스에 접속을 할 수 있거나 데이터 웨어하우스가 있겠지만 최악의 경우 GUI(Graphycal User Interface)를 통해 데이터를 수동으로 추출해야 한다.

 

빅데이터: 데이터의 크기가 만에서 백만 줄 정도 되면 데이터를 다루기가 상당히 쉽다. 그 정도의 사이즈는 엑셀에서도 다룰 수 있기 때문이다. 일단 백만 줄이 넘어가면 엑셀에서 프로세스를 다루기에는 엑셀 성능이 너무 떨어진다. 성능저하는 프로세싱하는 데 걸리는 시간의 증가를 가져오며, 이는 곳 비효율을 야기시킨다. 개인적인 느낌으로는 데이터를 추출할 때 최소 3~4개의 테이블을 조합해야 하고 쿼리의 결과가 약 3000만 줄 이상일 때 데이터 사이즈가 상당히 무겁다고 느껴진다. 예를 든 프로세스의 디테일 리포트의 총사이즈는 3600만 줄이었다. 그 말은 회사의 주요 자산이 3600만 개가 있고, 인덱스를 여기에 곱하는 연산을 해야 했다는 말이다.

 

프로세스 개발 당시 테크놀로지의 부재: 예를 든 프로세스는 약 내가 프로세스를 맡기 약 10년 전에 개발이 되었는데 그렇다고 해도 2010년 초반에 테크놀로지들이 부족했던 것은 아니었다. 그 당시에도 Python, R, SQL과 같은 프로그래밍 언어들이 존재했고 그 외에 다양한 data analytics 앱들이 존재했다. 문제는 프로세스 개발자가 가진 테크놀로지의 부재이다. 그 10년 전 그 개발자는 회계사였지 진짜 프로그램 개발자가 아니기 때문에 그런 문제가 발생하는데 물론 당시에 그 개발자가 가장 기술적이었기 때문에 개발을 맡은 것이었고 본인이 가진 기술을 총동원해서 개발을 했겠지만 최적화된 시스템을 만들지 못했다면 비효율이 존재할 수밖에 없다. 

 

다수의 도구를 사용한 프로세스: 이것은 위 테크놀로지의 부재와 연개 되는 것인데, Python, R, SQL과 같은 가장 효율적이고 강력한 툴을 사용하지 못했기 때문에, 이 개발자는 한 가지 도구를 사용하다가 한계에 부딪히면 다른 도구를 사용하는 치명적인 오류를 범했다. 이는 대개 비지니스 계열을 전공한 전문직 사람들이 스스로 가진 기술을 사용하여 프로세스를 개발할 때 벌어지는 일인데, 예를 든 프로세스의 경우, 개발자는 일단 엑셀을 사용해서 프로세스를 만들기 시작하다 데이터의 크기 때문에 엑셀에서 막히자 액세스(MS Access)를 사용해서 간단한 데이터베이스를 구축하고 쿼리와 매크로를 사용하여 문제를 해결하려고 했다. 하지만 액세스도 한계 용량이 있었고, 회사 네트워크 공유 폴더에 저장하고 사용할 시 퍼포먼스에 큰 문제가 있었기 때문에 Tableau라는 소프트웨어를 도입했다. 막판에 데이터 웨어하우스가 도입되었는지 SQL를 사용한 프로세스까지 만들어졌으니, 새로운 담장자는 이 경우, 엑셀, 액세스, Tableau, SQL을 전부 다 알고 있어야 할 뿐만 아니라 비지니스에 대한 전문지식까지 알고 있어야 했다. 

 

폴더를 꽉 채운 파일들: 그렇다 보니 처음 폴더를 열었을 때 기함을 토할 수밖에 없었던 것이, 7개의 새로운 폴더들과 열개 이상의 엑셀 파일들과 3개의 액세스 파일들, 두 개의 Tableau 파일들, 다양한 SQL 스크립트들과 그들의 옛날 버전인 듯 보이는 온갖 파일들이 나를 반기고 있었기 때문이었다. 도대체 어디서 시작하여 어디에서 끝나야 할지 알 수가 없었다. 

 

다큐멘트의 부재 혹은 업데이트가 안됨: 미국은 SOX Compliance라고 하여 기업 내 프로세스들과 재정재무표에 대해 강력한 내부규제를 가한다. 그 노력의 일환으로 모든 프로세스들은 체계적으로 문서화가 되어야 하고 프로세스에 대한 가이드라인이 세워진다. 그러한 다큐먼트를 Desktpo Procedure라고 부르며 매분기 혹은 매년 프로세스 수행자와 검토자가 다큐먼트를 업데이트하고 검토한다. 시간이 지나면서 시스템, 규제, 정책, 그리고 사람 같은 온갖 요소들이 변화함에 따라 프로세스에도 많은 변화가 찾아오기 때문이다. 하지만 그 변화의 속도를 미처 따라가지 못하게 되면 필연적으로 문서들은 새로운 변화들이 누락되거나 완전하게 다큐먼트가 되지 않기 때문에 실제 프로세스와 많은 차이가 발생하게 된다. 

 

앞서 비효율적인 프로세스들이 가지고 있는 전반적인 특성에 대해 알아보았다. 운이 나쁘게도 내가 맡았던 프로세스가 그 모든 비효율의 요인들을 가지고 있었던 프로세스였다. 종종 프로세스의 비효율성은 프로세싱 타임으로도 측정될 수 있는데, 내 기억으론 전임자가 전적으로 그 프로세스만 한 것은 아니었으나 약 3달에 걸쳐 데이터를 추출하고 가공해서 리포트를 만들어 냈던 기억이 난다.

 

그렇다면 기업에서 이런 비효율적인 프로세스를 맡아서 성공적으로 해내다면 리더들에게 성과를 냈다는 어필이 되고 훗날에 있을 고과에 크게 반영이 될 것인가 궁금할 것이다.

 

이미 존재하는 프로세스는 그게 효율적이든 비효율적이든 아무리 잘해봐야 큰 성과로 인정받지 못한다.

 

그렇다면 이 비효율적인 프로세스를 효율적인 개선 한다면? 그것은 크나큰 성과이고 바로 리더들의 눈에 뜨이게 되는 경험을 할 것이다.

 

효율적인 프로세스란?

효율적인 프로세스는 버튼 하나로 처음과 끝까지 모든 일을 처리할 수 있는 프로세스이다.

Effective and efficient one-button process

결론부터 말하자면 약 한 달간 SQL과 R을 사용해서 개발한 결과 버튼 하나를 누르면 약 15분 안에 기존과 동일한 리포트가 나오는 프로그램을 개발했고 6년이 지난 지금까지도 아무 이상 없이 돌아간다는 소식을 들었다.

 

그렇다면 그러한 효율적인 프로세스의 특징은 무엇일까?

 

간소화 (Streamlined): 미국 회사에서 일을 하면서 아주 많이 쓴 단어 중에 하나가 streamline (간소화)이다. 효율적인 프로세스는 간소하다. 시작과 끝이 분명하고 그 중간 역시 깔끔하고 간결해서 누구나 쉽게 알아볼 수 있고 그 프로세스를 쉽게 수행할 수 있으며, 메니져는 쉽게 리뷰를 할 수 있어야 한다.

 

자동화 (Automation): 결국에 내가 생각하는 가장 효율적인 프로세스는 간소화가 된 프로세스를 자동화시켜 사람 손으로 하는 프로세스가 전무한 프로세스로써, 사람은 프로그램이 생산한 결과물들을(리포트이던, 감가상각 스케줄이던, 분석이든 뭐든) 리뷰하는 일에 집중할 수 있게 할 수 있어야 한다.

 

문서화 (Documentation): 간결화되고 자동화된 것으로만으로도 큰 성과이지만 상장기업인 경우에는 외부감사를 항상 염두에 두어야 한다. 특히 SOX Compliance를 항상 염두에 두고 프로세스를 개발해 나아가야 한다. 문서화의 경우 프로세스 자체에 대한 자세한 비지니스 요구사항과 프로세스에 대한 디테일한 사항들이 있어야 하며, 자동화 프로세스를 운용했을 때 IPE (Information Provided by Entity)의 대한 요구사항을 어떻게 만족시키는가도 깊게 고려해야 한다.

 

통합화 (Consolidation): 아이폰이 한 기기에 통신, 인터넷, 음악을 통합시켜서 센세이션을 일으킨 것처럼, 하나의 플랫폼에서 프로세스를 간소화시키고 자동화시키면서 동시에 문서화를 진행시킬 수 있다면 왜 사용하지 않겠는가? 그리고 그것이 SOX Compliance까지 가능하다면? R Markdown이나 Jupyter Notebook이 바로 그 해법이다. 이 둘 중 하나의 응용 프로그램을 사용하면 모든 것을 한자리에서 충족시킬 수 있음을 Big4의 하나인 EY(Ernst and Young)의 외부 감사원들과 기업 내의 내부 감사원들의 승인을 받음으로써 충분히 증명이 되었다. 

 

나는 프로세스가 효율적이 된 결과물을 Digital Desktop Procedure라고 명명하였는데 회사 내에서 고유 명사가 되었다. 코딩, 데이터 시각화, 데이터 프로세싱, 데이터 분석 및 리포팅, journal entry나 transaction의 생성 등등의 모든 과정이 하나의 플랫폼에서 완성되고 실행될 수 있는 프레임을 개발하였고, 이 프레임 안에서 지금도 수많은 프로세스들이 현장에서 효율적으로 되어가는 과정을 거치고 있다.

R Markdown 링크

Jupyter Notebook 링크

 

비효율적인 프로세스를 효율적으로 개선시키는 과정에 대하여

Documenting [ Data Access > ETL > Data Processing > Visualization > Modeling > Communicating ]

비효율적인 프로세스를 효율적으로 개선시켰던 과정이 궁금하다면? 클릭! (준비 중)