약 1년 동안 IBM 소프트웨어그룹에서 기존과는 조금 다른 성격의 기술을 담당하고 있었습니다. 처음에는, 아니 어제까지도 전혀 다른 두 개의 기술이라고 여겼던 Situational Application과 Event Driven Architecture가 사실은 동일한 기업 문제를 해결하기 위한 것임을, 하나의 그래프로 엮어볼 수 있겠다는 아이디어가 떠올라서 다음과 같이 메모합니다.

기업 내에 존재하는 IT애플리케이션들의 기능들이 과연 그 기업의 어떤 프로세스와 상황을 대처하기 위해 만들어졌는지에 따른 기준으로 생각해보자.

IT 애플리케이션들아! 네 존재의 이유는 무엇이니?

그 기준은 오로지 하나이다. 기업의 목표가 수익 창출이라면,

기업 내에 존재하는 IT애플리케이션의 목적은 다음 3가지 중의 하나에 부합되어야만 한다.

A. 수익을 잃어버리거나 감소시키거나 손해를 크게 보지 않게 하기 위한 애플리케이션 혹은 기능.

C. 경쟁자에 비해 매우 높은 수익을 발생시키거나 기회를 잡을 수 있게 도와주는 애플리케이션 혹은 기능.

B. 그리고 기업 운영에 필요한, 적당한 ROI를 가능케 하는 애플리케이션 혹은 기능.

그렇다면 이 세가지 종류의 IT 애플리케이션들의 실제 비중은 어떨까? 이런 그래프가 아니겠는가?

비주얼에 약한 관계로 그래프가 조금 극단적으로 그려진 것을 양해해주시길…

B 구간, 즉 정상적인 기업 운영에 필요한 애플리케이션들이 정상적이게도 기업내에 가장 많은 비중을 차지하기 마련이다. 당연한 것이다. ERP나 홈페이지나 인사,회계 시스템들이 모두 B구간에 속하는 것들이다.

그러다가 기업이 IT자산 투자에 여유가 생기면 A와 C에 투자하기 시작한다.

해킹이나 서버다운과 같이 평소에는 발생하지 않지만 간헐적으로 발생하는 것만으로도 큰 영향을 미치는 A영역의 애플리케이션이나

잠재적인 고객 트렌드와 동향을 파악하고 고객의 숨은 니즈를 파악하는 덩치크고 비싸기 그지없는 BI툴이나 CRM애플리케이션들이 C영역에 속하는 애플리케이션들이다.

그런데 아주 아주 정상적인 프로세스와 흐름을 지닌 B영역의 애플리케이션에 비해서 A와 C영역의 것들은 사실 변수가 너무나 많이 존재한다.

먼저 A영역의 애플리케이션의 고충을 생각해보자.

A영역의 애플리케이션의 핵심은 바로 Risk 관리이다. 사기를 치거나 도덕적으로 옳지 못한 행동으로 이익을 챙기려는 고객의 행위는 항상 진화한다. 1년전에 구축한 모델과 룰은 메모리만 차지하는 쓰레기이다. 오늘은 오늘의 Risk 관리가 필요한게 A영역의 애플리케이션의 특징이다.

그럼 C영역의 애플리케이션은 다를까?

다를게 없다. 고객의 충성도를 높이고 더 나은 고객을 모으고 고객 니즈의 숨겨진 2%를 챙기려면 고객의 변화보다 한발짝 앞서가거나 적어도 보폭을 맞추어야만 한다. 눈치와 시간 그리고 센스의 싸움이다. 도저히 1년전에 만든 프로세스와 캠페인으로 경쟁자를 따돌릴 수 없다.

그래프상으로는 상극에 속하고 있는 A,C 두 종류의 애플리케이션은 사실 아래와 같은 동일한 특성을 가지고 있다.

• 변화가 빠르다.
• 통찰이 필요하다.
• 빠른 구현이 필요하다.
• 다양한 정보 원천으로부터의 용이한 매쉬업(연계)이 필요하다.
• 수명이 짧다.

---

댓글

chris · 2010/06/15 15:41

:( I can’t understand even a sentence. I am such a numb hear or may be its the fault of writer of presenting things in such complex manner.

데이터 복구 · 2010/07/14 21:11

안녕하세요, 좋은 주제입니다. 기업의 민첩성은 비즈니스와 조직과 의사 소통 작동, 혁신, 팀 구축 기반 모델 순발력을 사용합니다.