경험에 비추어 본 BRM 과 진로

개인적으로 BRM(Business Relationship Management) 라는 것은 2004년 ~ 2005년에 읽은 CIO 란 잡지를 통해서였다.
커리어 패쓰상 BRM 업무를 하고 싶어 이직을 했고 그리고 100% 해당 업무를 하는 부서는 아니였지만 방카슈랑스와 ING Korea 의 특성상 BRM 업무를 해야만 했고 길지는 않았지만 불꽃같은 경험을 해서 관심은 많다.

BRM 조직의 역할 정의는 아래와 같다고 한다.

△ 비즈니스 수요 예측을 기반으로 한 비즈니스 기회 발굴
△ IT시스템으로 구현되는 과정에서의 비즈니스 요건 관리
△ IT시스템의 사용과 서비스 제공과 관련한 비즈니스 서비스 모니터링
(출처 : CIO Korea)

쉽게 말하면 현업의 요구사항이나 대외 규제나 변화를 예측하거나 조사하여 IT 개발 파트에 개발 요건을 IT 부서가 이해할 수 있도록 전달하고 전체 개발 과정에서 비즈니스 측면에서 어떤 사업 영역에 어떤 기술을 사용할지 고민하고 진행해야하는 것이다.

경험적으로 보면 위와 같은 role 을 수행하는 조직은 작은 회사보다는 연관 업무의 복잡화가 많은 조직에서 많이 필요로 한다.
그리고 비슷하게나마 위의 role 을 수행하기도 할 것이다.

그렇지만 명확하게 해야할 일의 범위와 방법 등이 없는 경우가 많을 수 있다.
△ 현업에서 올라온 개발 요구안의 상세한 분석없이 IT 파트로 바이 패스
△ 대외 공문이 접수되면 접수만 하고 관련 IT 팀들이 알아서 분석, 개발하도록 방치
△ 관련 기관의 보도 자료, 신물 또는 SNS 에서의 소식을 통한 수요 조사의 미이행
△ 이전 현업 요구안의 운영 상태, ROI 분석 등의 피드백 부재
△ 영업 조직의 막무가내식 요청에 대한 무조건적인 수용으로 가용 인력의 관리 부족

따라서, 구체적으로 아래와 같은 구체적인 역할을 수행해야 한다.

△ 현업부서의 서비스 요건을 수집하는 단일 채널의 역할
△ 정기적인 설문이나 인터뷰를 통한 비즈니스 요건 수집 -> 공문, 보도자료, 뉴스, SNS 도 포함
△ 접수된 비즈니스 요구사항이 다른 비즈니스에 미치는 영향 분석 -> IT 가용 인력, target date 충돌 등 고려
△ 경쟁사와의 관계나 시장 동향에 따른 서비스 변화방향 정의
△ IT부서와의 커뮤니케이션을 위해서 비즈니스 요구 사항을 IT 요건으로 정의 -> 전사 아키텍쳐 이해를 기반으로 설명 필요
(CIO Korea 참고)

(출처 : CIO Korea)

한미 FTA 으로 미국의 글로벌 아웃소싱 회사가 국내에 진출할 것이다.
사업 영역이나 기업 문화 특성상 차이는 있겠지만 기업의 가장 큰 존재 이유는 수익성이다. 거기엔 돈이 있다.
따라서 값싸고 아웃풋 잘 나오는 동남아 인력이 내가 하고 있는 IT 유지보수나 개발을 대체 아니 한다고 볼수는 없다.

각자 하고 있는 IT 업무에 위에서의 BRM 의 역할을 평소 연습을 한다면 그 어떤 BRM 담당자보다 더 훌륭하고 IT 부서를 이해하는 BRM 담당자가 될 수 있고 그렇게 함으로써 자기의 진로와 역량이 업그레이드될 수 있다고 생각이 든다.