2014.10.28

BI 프로젝트가 실패하는 이유와 성공 방법

Andrew C. Oliver | InfoWorld
단순히 BI 솔루션을 구입한다고 해서 모든 게 잘 될 것이라고 믿는 건 어리석다. 우선 전략을 찬찬히 살펴야 하는데, 실패 이유와 성공 방법을 알아보자.

BI(Business Intelligence) 프로젝트는 근원적인 전략 부재의 문제로부터 자유롭지 못한 경우가 많다. 하지만 많은 기업이 BI를 운영체제나 가상화 기술과 같은 툴 선택의 관점으로 본다. 어쨌든 소프트웨어 패키지니까 그렇지 않을까 싶다.

실제 BI 프로젝트는 실제 'BI'툴, 단순한 대시보드 툴, 데이터 쿼리를 위한 검색 툴, 타블로(Tableau)와 같은 '퀵 히트(quick hits)' 툴 등 몇 가지 다른 툴들을 수반할 수 있다. 하지만 툴 선택은 본질을 파악하지 않고 먼저 접하는 값비싼 장식에 불과하다.

성공적인 첫걸음은 좋은 전략에서 시작되고, 좋은 전략은 비즈니스 요구를 알아내는 것부터 시작된다.

가장 가치있는 BI 시작은 정보와 기술을 합쳐서, 얻어진 통찰이 직접적으로 조직의 전략 실행을 반영하고 의사 결정을 더욱 잘 지원할 수 있다.

균형잡힌 스코어카드(balanced scorecard)는 전략, 기술, 성과 관리 연결을 위한 인기있는 방법이다. 응용 정보 경제학(applied information economics)과 같은 다른 방법들은 기업이 더 나은 정보의 경제적 가치를 계산하는데 도움을 주기 위해 통계적 분석, 포트폴리오 이론, 결정 과학을 결합한다.

공개된 리포팅 툴을 사용하던, 자신만의 내부 리포팅 툴을 자체 개발하던지 BI 활동이 예쁘지만 쓸모없는 대시보드와 보고서만 만들어내고 마는 게 아니라 실질적인 사업 가치를 창출하는데 초점이 맞춰지도록 하는 게 핵심이다.

많은 기업이 '데이터 주도적(data driven)'이라는 의미를 제대로 알지 못한 채 데이터 주도적인 기업이 되고자 한다. 자칭 '데이터 주도적 기업'이라고 소개하는 한 기업 고객이 있었는데, 이 기업은 자사가 상대방의 눈을 봄으로써 사람의 성격을 판단하는 리스크 관리팀의 능력에 근거해 막대한 스캔들을 피했다고 설명했다.

경영팀은 진실된 마음으로 속을 터놓고 그들이 일상적으로 어떤 데이터를 보는지, 이 데이터에 기반으로 어떤 결정을 내리는 지, 다른 길을 어떻게 선택하는 지를 결정해야 한다. 그 직속 하위 관리자도 똑같이 행동해야 한다.

자, 다음 질문에 답해보자.
있었으면 하는, 원하는 데이터가 무엇이며 이 데이터가 의사결정에 영향을 줄 수 있을까?
이 질문에 대한 대답이 모든 BI 프로젝트에 있어서 최고 경영진의 요건을 형성한다.

제대로 된 팀을 꾸리지 못하는 것 또한 큰 실수다. 팀을 구성할 때, 많은 기업이 정치적인 이유로 온갖 사람들을 모두 끌어들이거나 지원자들의 연합을 구축하는 식으로 넘어간다(일반적으로 최초의 전사적 회의에서 참여했던 이들이 구성원이 된다).

성공하기 위해서는 데이터 전문가, 데이터 분석가, 비즈니스 전문가들이 제대로 된 기술 전문가들과 힘을 합쳐야 한다. 이는 보통 외부의 도움을 의미하는데, 이 외부 전문가는 경영진과 대화하고 기술에 대해 말할 수 있어야 한다.

자사의 BI 툴에 대해 제대로 알고 있는 100명의 '툴 전문가'들을 부른다 해도 아무도 이야기를 꺼내고 나서지 않으면 도움이 안 된다.

이 모든 게 훌륭한 이야기들이지만, 만약 데이터가 각기 다른 시스템에 걸쳐 흩어져 있다면 어떨까?

성공적인 BI 프로젝트는 비즈니스 통합이나 데이터 통합이 기본이다(여기서 주의해야 할 것은 가상 스키마 메타-매트릭스 제품을 절대 구입하지 말라. 모두 다 형편없다).

이 시점에서 하둡, 데이터 호수(data lake), 기업 데이터 허브, 데이터 웨어하우스는 유행이 아니라 필수가 된다.

핵심 운영체제에 대한 피드(Feed)를 요청하는 것만큼 IT 부서를 긴장시키는 것도 없다. 게다가 수많은 BI 툴은 저마다 자원에 목말라 있다.

자신의 BI 프로젝트 요구 사항은 어떤 데이터가 얼마나 많이, 그리고 얼마나 자주, 얼마나 '실시간'이 되어야 하는지, 그리고 DW 기술로 피드돼야 하는 지를 결정해야 한다.

성공 방법의 일부분으로 IT가 포인트-투-포인트(point-to-point) 연결을 중단하고 모든 것을 중앙의 데이터 허브를 통해 연결하는 데이터 호수로의 허브-앤-스포크(hub-and-spoke)식 통합을 시작하기로 약속하는 것이다.

다시 말하면, 관리가 쉽지 않은 시스템들의 작은 피드 수백 개 대신, 하나의 큰 피드가 필요하다는 말이다.

BI 개발업체의 영업직원들이 어떻게 말하든, 자신의 운영 시스템을 무너트리지 않은 채 데이터에 쉽게 접속하게 해 주는 작업은 자신이 그 부하를 같이 안고 갈 수 있도록 데이터웨어하우스(DW)나 데이터 호수를 배치하지 않은 이상 아주 어려운 일이다.

비즈니스 요건과 하둡, 테라데이터 등등 자신이 지원받아야 할 기술을 근거로 한다면 자신에게 알맞는 BI 툴을 선택할 수 있을 것이다.

- 자신에게 필요한 데이터 애널리틱스 유형을 지원하는 툴은 어떤 것인가?
- 이 툴은 자사 내 누가 이용하게 되는가?


수많은 BI 툴은 시스템 전문가들이 즉각적인 개입을 필요로 하지만, 다른 BI 툴들은 아주 간단해서 기초적인 SQL 기술만 가진 비즈니스 분석가도 활용할 수 있다. 자신의 모든 활용 사례에 적합하기 위해서는 아마도 한 가지 이상의 툴이 필요할 것이다.

이제 숙제를 마쳤고, 활용 사례를 식별했고, 좋은 팀을 꾸렸고, 데이터 통합 프로젝트를 시작했고, 알맞은 툴을 선택했다.

드디어 끝판 대장이 나오는 단계에 다다랐다. 이제 정말 어려운 부분이다.
자신의 비즈니스와 결정을 데이터와 보고서에 근거해 조직을 변화시키는 것이다. 관리자는 다른 모든 인간처럼 변화에 저항적이기 마련이다.

게다가 BI 프로젝트들은 정해진 시작과 끝이 있어서는 안 된다. "데이터 주도'는 한시적으로 끝나는 달리기 경주가 아니기 때문이다.

불필요한 보고서들을 줄이고 데이터에서 새로운 기회를 찾기 위해서는 프로세스가 필요하다. 어떤 경우에는 우연히, 어떤 경우에는 지능적인 관리자가 그들이 이해하지 못하는 것을 봤을 때, 무엇뿐만 아니라 왜까지 묻는다.

자, 지금까지 설명한 것을 다음과 같이 '할 것'과 '하지 말 것'을 간단하게 정리했다.

- 툴 선택 프로젝트를 단순하게 행하지 말라.
- 제대로 된 팀을 골라서 꾸려라.
- 데이터를 통합해 전체 시스템을 마비시키지 않으면서도 성능 전반의 쿼리가 가능하게 하라.
- 단순히 툴만 고르지 말고 자신의 요건과 활용 사례에 적합한 툴을 선택하라.
- 데이터가 자신의 의사 결정과 필요한 경우 조직의 구조를 바꿀 수 있게 하라.
- 불필요한 애널리틱스를 없애고 새로운 애널리틱스를 찾는 프로세스를 확립하라.


이런 주의사항을 명심해 제대로 일을 처리하면 성공적인 BI 프로젝트를 가질 수 있게 될 것이다. editor@itworld.co.kr



2014.10.28

BI 프로젝트가 실패하는 이유와 성공 방법

Andrew C. Oliver | InfoWorld
단순히 BI 솔루션을 구입한다고 해서 모든 게 잘 될 것이라고 믿는 건 어리석다. 우선 전략을 찬찬히 살펴야 하는데, 실패 이유와 성공 방법을 알아보자.

BI(Business Intelligence) 프로젝트는 근원적인 전략 부재의 문제로부터 자유롭지 못한 경우가 많다. 하지만 많은 기업이 BI를 운영체제나 가상화 기술과 같은 툴 선택의 관점으로 본다. 어쨌든 소프트웨어 패키지니까 그렇지 않을까 싶다.

실제 BI 프로젝트는 실제 'BI'툴, 단순한 대시보드 툴, 데이터 쿼리를 위한 검색 툴, 타블로(Tableau)와 같은 '퀵 히트(quick hits)' 툴 등 몇 가지 다른 툴들을 수반할 수 있다. 하지만 툴 선택은 본질을 파악하지 않고 먼저 접하는 값비싼 장식에 불과하다.

성공적인 첫걸음은 좋은 전략에서 시작되고, 좋은 전략은 비즈니스 요구를 알아내는 것부터 시작된다.

가장 가치있는 BI 시작은 정보와 기술을 합쳐서, 얻어진 통찰이 직접적으로 조직의 전략 실행을 반영하고 의사 결정을 더욱 잘 지원할 수 있다.

균형잡힌 스코어카드(balanced scorecard)는 전략, 기술, 성과 관리 연결을 위한 인기있는 방법이다. 응용 정보 경제학(applied information economics)과 같은 다른 방법들은 기업이 더 나은 정보의 경제적 가치를 계산하는데 도움을 주기 위해 통계적 분석, 포트폴리오 이론, 결정 과학을 결합한다.

공개된 리포팅 툴을 사용하던, 자신만의 내부 리포팅 툴을 자체 개발하던지 BI 활동이 예쁘지만 쓸모없는 대시보드와 보고서만 만들어내고 마는 게 아니라 실질적인 사업 가치를 창출하는데 초점이 맞춰지도록 하는 게 핵심이다.

많은 기업이 '데이터 주도적(data driven)'이라는 의미를 제대로 알지 못한 채 데이터 주도적인 기업이 되고자 한다. 자칭 '데이터 주도적 기업'이라고 소개하는 한 기업 고객이 있었는데, 이 기업은 자사가 상대방의 눈을 봄으로써 사람의 성격을 판단하는 리스크 관리팀의 능력에 근거해 막대한 스캔들을 피했다고 설명했다.

경영팀은 진실된 마음으로 속을 터놓고 그들이 일상적으로 어떤 데이터를 보는지, 이 데이터에 기반으로 어떤 결정을 내리는 지, 다른 길을 어떻게 선택하는 지를 결정해야 한다. 그 직속 하위 관리자도 똑같이 행동해야 한다.

자, 다음 질문에 답해보자.
있었으면 하는, 원하는 데이터가 무엇이며 이 데이터가 의사결정에 영향을 줄 수 있을까?
이 질문에 대한 대답이 모든 BI 프로젝트에 있어서 최고 경영진의 요건을 형성한다.

제대로 된 팀을 꾸리지 못하는 것 또한 큰 실수다. 팀을 구성할 때, 많은 기업이 정치적인 이유로 온갖 사람들을 모두 끌어들이거나 지원자들의 연합을 구축하는 식으로 넘어간다(일반적으로 최초의 전사적 회의에서 참여했던 이들이 구성원이 된다).

성공하기 위해서는 데이터 전문가, 데이터 분석가, 비즈니스 전문가들이 제대로 된 기술 전문가들과 힘을 합쳐야 한다. 이는 보통 외부의 도움을 의미하는데, 이 외부 전문가는 경영진과 대화하고 기술에 대해 말할 수 있어야 한다.

자사의 BI 툴에 대해 제대로 알고 있는 100명의 '툴 전문가'들을 부른다 해도 아무도 이야기를 꺼내고 나서지 않으면 도움이 안 된다.

이 모든 게 훌륭한 이야기들이지만, 만약 데이터가 각기 다른 시스템에 걸쳐 흩어져 있다면 어떨까?

성공적인 BI 프로젝트는 비즈니스 통합이나 데이터 통합이 기본이다(여기서 주의해야 할 것은 가상 스키마 메타-매트릭스 제품을 절대 구입하지 말라. 모두 다 형편없다).

이 시점에서 하둡, 데이터 호수(data lake), 기업 데이터 허브, 데이터 웨어하우스는 유행이 아니라 필수가 된다.

핵심 운영체제에 대한 피드(Feed)를 요청하는 것만큼 IT 부서를 긴장시키는 것도 없다. 게다가 수많은 BI 툴은 저마다 자원에 목말라 있다.

자신의 BI 프로젝트 요구 사항은 어떤 데이터가 얼마나 많이, 그리고 얼마나 자주, 얼마나 '실시간'이 되어야 하는지, 그리고 DW 기술로 피드돼야 하는 지를 결정해야 한다.

성공 방법의 일부분으로 IT가 포인트-투-포인트(point-to-point) 연결을 중단하고 모든 것을 중앙의 데이터 허브를 통해 연결하는 데이터 호수로의 허브-앤-스포크(hub-and-spoke)식 통합을 시작하기로 약속하는 것이다.

다시 말하면, 관리가 쉽지 않은 시스템들의 작은 피드 수백 개 대신, 하나의 큰 피드가 필요하다는 말이다.

BI 개발업체의 영업직원들이 어떻게 말하든, 자신의 운영 시스템을 무너트리지 않은 채 데이터에 쉽게 접속하게 해 주는 작업은 자신이 그 부하를 같이 안고 갈 수 있도록 데이터웨어하우스(DW)나 데이터 호수를 배치하지 않은 이상 아주 어려운 일이다.

비즈니스 요건과 하둡, 테라데이터 등등 자신이 지원받아야 할 기술을 근거로 한다면 자신에게 알맞는 BI 툴을 선택할 수 있을 것이다.

- 자신에게 필요한 데이터 애널리틱스 유형을 지원하는 툴은 어떤 것인가?
- 이 툴은 자사 내 누가 이용하게 되는가?


수많은 BI 툴은 시스템 전문가들이 즉각적인 개입을 필요로 하지만, 다른 BI 툴들은 아주 간단해서 기초적인 SQL 기술만 가진 비즈니스 분석가도 활용할 수 있다. 자신의 모든 활용 사례에 적합하기 위해서는 아마도 한 가지 이상의 툴이 필요할 것이다.

이제 숙제를 마쳤고, 활용 사례를 식별했고, 좋은 팀을 꾸렸고, 데이터 통합 프로젝트를 시작했고, 알맞은 툴을 선택했다.

드디어 끝판 대장이 나오는 단계에 다다랐다. 이제 정말 어려운 부분이다.
자신의 비즈니스와 결정을 데이터와 보고서에 근거해 조직을 변화시키는 것이다. 관리자는 다른 모든 인간처럼 변화에 저항적이기 마련이다.

게다가 BI 프로젝트들은 정해진 시작과 끝이 있어서는 안 된다. "데이터 주도'는 한시적으로 끝나는 달리기 경주가 아니기 때문이다.

불필요한 보고서들을 줄이고 데이터에서 새로운 기회를 찾기 위해서는 프로세스가 필요하다. 어떤 경우에는 우연히, 어떤 경우에는 지능적인 관리자가 그들이 이해하지 못하는 것을 봤을 때, 무엇뿐만 아니라 왜까지 묻는다.

자, 지금까지 설명한 것을 다음과 같이 '할 것'과 '하지 말 것'을 간단하게 정리했다.

- 툴 선택 프로젝트를 단순하게 행하지 말라.
- 제대로 된 팀을 골라서 꾸려라.
- 데이터를 통합해 전체 시스템을 마비시키지 않으면서도 성능 전반의 쿼리가 가능하게 하라.
- 단순히 툴만 고르지 말고 자신의 요건과 활용 사례에 적합한 툴을 선택하라.
- 데이터가 자신의 의사 결정과 필요한 경우 조직의 구조를 바꿀 수 있게 하라.
- 불필요한 애널리틱스를 없애고 새로운 애널리틱스를 찾는 프로세스를 확립하라.


이런 주의사항을 명심해 제대로 일을 처리하면 성공적인 BI 프로젝트를 가질 수 있게 될 것이다. editor@itworld.co.kr

X