성공적인 DBM시스템을 위한 방법

성공적인 DBM시스템을 위한 방법

  

1.   솔루션 벤더를 부르기 전에 우리회사가 원하는 사항을 문서로 정리한다. 이 숙제(?)를 완료하지 않은 채 업체를 불러 현란한(?) 애기를 듣다 보면, 뒷날 선택을 위한 기준 판단도 없고 배는 계속 산으로 올라가게 된다. 그러므로 가급적 구체적으로 원하는 사항을 ‘꼭꼭 집어서’ 기술해 두어야 한다.

 

2.   최고 경영자의 확고한 지원 없이는 결코 진행하지 않는다.  이 불확실성의 시대에 장기적인 프로젝트를 진행하는 사람은 조직적 위험(?)에 특히 더 노출하게 된다. 시스템을 구축하는 일은 시간과 노력이 많이 들어가는 일이기 때문에 ‘인내심’이 적은 최고 경영자가 위에서 내려 보고 있다면 진행하지 않는 것이 좋다. 여기서 최고 경영자란 상무, 이사가 아니라 CEO를 의미한다.

 

3.   시스템의 실제 이용자를 개발 과정에 많이 참여 시켜야 한다. 자칫하면 전산팀과 기획팀만의 탁상공론으로 ‘괴물’시스템이 생산될 수 있다. 실제 이 시스템을 사용하게 될 사용자들의 피드백을 반영시키면서 개발을 진행한다. 전산 전문가가 아니기 때문에 이들을 참여 시키는 가장 좋은 방법은 Prototype을 보여 주며 의견을 수렴하도록 한다. 전산 전문가들은 이런 일을 잘못하는 경향이 있다. 말로만 하는 회의는 결론에 도달하지 못한다. 이 사용자들은 실무’감각’이 있는 사람들이다. 가시적으로 보면서 진행하면 개발작업이 훨씬 빨라 질것이다.

 

4.   초기 이용자 교육에 온갖 정성을 기울여야 한다. 파일럿 시에는 대게 일부 이용자만 교육을 받아 시험 가동에 들어 가는데, 파일럿이니까 조금씩 해보면서 시스템을 고쳐 나가겠다는 낙관적인 생각은 금물이다. 초기 이용자들은 강력한 ‘영향력’을 조직 내부에 끼치게 된다. 이 사람들이 애정을 갖고 추종자가 되도록 철저한 사용자 교육이 이루어져야 한다.

 

5.   TF미팅은 개념을 이해하기 보다는 가급적 실제 화면을 사용하자. 새로운 영업방식을 도입하는 경우이기 때문에 각자 사용하는 용어도 혼선을 야기시킬 수 있다. 같은 용도도 직원별로 달리 들릴 수 도 있다. 일단 전략이 수립된 후에는 화면을 그려 가면서 구축방안을 구체적으로 논의하자. 화면 그리는 것이 더뎌 보여도 실제 시스템 구축 프로세스 전체로 보면 훨씬 단축된다. TF구성원들의 이해도가 높아지고 균등해지기 때문이다.

 

6.   임원들에게 지속적으로 DBM진행상황을 알려 주어야 한다. 조직 내부에는 다른 중요한 사안들이 늘 새롭게 나타난다. DBM시스템 개발업무가 빛을 잃게 되는 경우가 생기면, 그 프로젝트는 점점 관심이 멀어진다. 예산, 우선순위 등도 멀어지며 심지어 소속 직원들의 숫자까지 줄어드는 일이 생긴다. DB마케팅이 고객접점 직원들에 의한 섬세한 단위 업무로 구성되어 있기 때문에 하부에서만 미주알고주알 따지다 보면 이런 일이 생기게 마련이다.

 

7.    전사적 통합DBM을 실시하려면, 전체 구성원이 같은 수준의 DBM지식을 갖고 시작하자. 내부에서는 DBM의 필요성 등이 충분히 공감대를 형성했다고 해서 시스템 구현이 쉽게 이루어지지는 않는다. 특히 기획단계 등 초기에는 각자가 보는 관점이 다르다. 상무님 개념과 부장님 개념이 다르고, 실무자들은 또 다른 시각을 가지고 있다. 어떤 사람은 ‘시스템’만 있으면 만사가 다 해결되는 것으로 아는 경우도 있다. 이런 불일치 해결 방법은 필수적인 DBM 교육과장을 모두 거치도록 하고 일을 시작해야 한다. 적어도 우리 회사 내에서는 같은 레벨로 얘기하자는 것이다.

  

-          ORACLE 매거진 Summer –