brunch

You can make anything
by writing

C.S.Lewis

by Peter Jul 03. 2020

시스템으로 만들기

솔루션이 아닌 프로세스 지향

스타트업 다니는 후배에게서 '시스템이 없어서 힘들다'라고 말하는 것을 들었습니다. 제대로 정의된 업무 라인이 없어서 일을 하나 하는 데 맨 땅에서 시작하느라 번번이 너무 힘들다는 것이죠. 그런데 시스템이 제대로 없는 것은 큰 회사도 마찬가지입니다. 오히려 거대한 레거시 시스템이 조직을 발목 잡고 있는 부분도 많으니까요. 새로운 것을 시도해 보려고 해도 기존 시스템 구축에 쏟아부은 돈이 너무 많아 시스템에 종속되어 업무에 필요한 자유를 잃어버리는 일 말입니다. ERP나 그룹웨어, 상용 분석 소프트웨어의 편리함을 이야기하는 부분도 많지만 편리하게 상용화된 프로그램 이면에는 보지 못하는 것을 볼 생각이 안 들게 만든다는 맹점도 있습니다.



이런 전통적인 기업에서 '시스템'이라고 말하는 것은 보통 레거시와 관련된 개념이 많습니다. 시스템이 솔루션 지향적인 것은 실체가 있는 접근으로 좋지만 문제는 시스템을 구축하는 목적 자체를 잃고 수단에 개념이 매몰될 소지가 있다는 것이죠.



예를 들어 한 업체에서 새로운 상품을 개발한다고 합시다. 상품을 만드는 사람 입장에서 가장 필요한 것은 시장의 수요를 미리 읽는 일입니다. 전문적인 부분이니 사람마다 역량 차이가 있는 일이죠. 이 사람들 중에서 일부가 좋은 감각으로 현재 많은 고객이 사용하고 있지 않지만 트렌드를 선도하는 일부 고객이 이제 막 지갑을 연 상품을 찾아 상품화시켜 많은 매출을 올립니다. 기업은 이런 성공 사례를 더 많이 만들고 싶어 합니다. 그러면서 성공 사례를 시스템으로 만들어서 사람의 감각이 아닌 데이터가 말하게 하는 문화를 만들자는, 말하는 사람도 그게 정확히 무엇인지 모르면서 방향은 맞다고 생각하는 내용을 던지죠. 뭐 취지는 훌륭합니다.



하지만 이런 일을 누가 어떻게 주도권을 갖고 푸느냐에 따라 결과는 많이 달라집니다. 시간상으로 한 시점에서 성공 사례를 만든 상품 기획자의 판단 기준을 전문가 시스템으로 구현하여 외부 데이터와 내부 데이터를 수집해 그중에서 나름 세운 로직에 맞는 데이터만 보여주고 여기서 상품을 고르게 하는 게 가장 많이 접근하는 방식입니다. 무엇을 보느냐를 정리해 준다는 데서는 의미 있는 일이겠지만 이런 성공 모델이 얼마나 유효할지는 아무도 검증해 줄 수 없다는 치명적인 단점이 있습니다. 거기다 ‘시스템 = IT = 대시보드’로 생각하는 사람이 많다는 문제가 있죠. 막상 다른 상품 기획자들이 상품을 찾을 때 그렇게 많은 비용을 들여 투자한 대시보드나 솔루션을 업무 프로세스 어딘가에서 고정적으로 사용해야 가치가 그나마 있는 것이지만 보통 시스템을 만들 때 이런 고민은 별로 하지 않는 경우가 많습니다.



시스템이란 것은 결국 업무 프로세스를 말하는 것이지만 경영의 주도권을 시스템에 내어 주기 싫은 부분은 제거하지 않은 채 시스템 구현이 이뤄집니다. 막상 상품 소싱을 잘한 기획자도 자기 노하우를 굳이 전사적으로 알려줄 이유도 의무도 없고 시장이 변화하면서 그 성공은 폐기해야 할 가장 무서운 편견이 되어버립니다. 성공한 기업이 진부한 상품을 변주하는 이유와 같습니다.



시스템으로 일한다는 것은 거창하고 무거운 IT 솔루션을 도입하는 게 아닙니다. 데이터 분석의 결과가 내부에서 설명되고 현업의 업무 프로세스에 고정적으로 활용되면서 서로 피드백을 통해 살아 움직이는 문화가 되는 게 진정한 시스템이라고 할 수 있죠. 기업에 수많은 대시보드를 만들어서 KPI들을 나열하는 프로젝트를 해도 업무 프로세스가 바뀌지 않으면 아무런 의미 없는 낭비가 되어 버립니다.



일부 기업에서는 현업에게 직접 SQL로 본인이 보고 싶은 KPI를 대시보드로 구현하라고 합니다. 차라리 그게 낫습니다. 사람 한 명만 건너도 프로세스에서는 비용이 들고 왜곡이 발생합니다. 우리 회사가 지향하는 역량이 단순히 물건이나 서비스를 만드는 것 이상으로 인사이트 기반의 가치를 만든다면 이런 변화는 장려할만합니다. 의미 없는 리포트가 구축되고 실제 사용자 수를 추적해 보면 한 달에 몇 번 방문하지도 않는 페이지를 위해 많인 비용을 쓰는 일을 만들지 않기 위해서 말이죠.



결국 시스템으로 일이 안착하기 위해 필요한 것은 '보여주기'가 아닌 '실제적인 프로세스 적용'을 위한 작은 걸음에 있습니다. 처음부터 무거운 IT 솔루션 구축은 ‘처음부터 완벽한 것’이라는 다소 최근 비즈니스 환경에 맞지 않는 생각이 전제되어 있는 것입니다. 작지만 빠른 시스템은 꼭 IT라고 예전에 생각한 것이 아닐 수도 있습니다.

매거진의 이전글 인과관계와 상관관계
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari