중소기업(SMB) 시장의 본질적 모순이 점점 더 명백해짐에 따라 이들의 공통적인 특성을 찾는 더욱 의미 있는 방법론이 등장하게 될 것이다. “자원 제약적 조직(RCO: Resource-constrained organization)은 새로운 시장 기회를 찾는 벤더들을 위한 설계 중심으로 등장할 것이다. RCO는 어플리케이션 소싱, 배치와 유지보수 모범 사례의 구축에 대한 다른 접근법 및 이들 벤더 제품들 사이에 새로운 공생관계를 만들어내는 능력에 이런 새로운 솔루션의 가치가 직접 연결될 것이라는 사실을 반드시 인식해야 한다.

상황
2002년 이후, 비즈니스 어플리케이션 시장의 중심이 바뀌었다. 2002년까지 벤더의 노력은 Global 2000(G2000)에 대한 상당한 기업 전체 솔루션에 중점을 두어 왔다. 이러한 프로젝트의 인식된 가치와 가용성이 줄어들면서, G2000의 자회사와 비즈니스 단위 내부, ‘비-G2000’으로 분류될 수 있는 조직 내부의 작은 프로젝트로 중심이 이동되었다. “중소 비즈니스”는 이 그룹의 범주를 정하는 용어가 되긴 하지만 조직이 가질 수 있는 대안적인 상황을 제공하는데 있어서는 별로 가치가 없다. 대신 비슷한 요구 집합보다는 비슷한 제약 사항의 집합에 의해 조직이 구속됨을 인식하게되므로써, 용어로서의 “SMB”는 RCO라는 개념에 양보하게 되었다.

RCO는 비즈니스 어플리케이션 벤더의 노력을 이 공동체를 위해 더욱 의미 있는 솔루션으로 융합하는 개념이 될 것이다. 기업급 제품의 성능으로 짝을 지움으로써 제품을 생성하려는 이전의 시도는 비즈니스 결과에 대한 타협을 거부하는 조직들을 위해 특별히 고안된 시장 출시 모델과 기술에 양보하게 될 것이지만, 전통적으로 비즈니스 어플리케이션과 관련된 운영 예산, IT 직원과 낮은 자본 지출을 가지면 반드시 그렇게 해야만 한다.

벤더 공동체의 노력에도 불구하고 소싱, 배치와 유지보수 사례 또한 변화하지 않는 이상 RCO는 예상한 결과를 도달하지 못하게 될 것이다. 이들 생산자중 많은 수가 비즈니스 어플리케이션 시장을 정의했던 대규모 기업 전체(whole-of-enterprise) 배치로부터 기인했다. 새로운 솔루션을 지원하는 운영 모범 사례의 새로운 집합이 필요하며, 이는 다시 모범 사례를 구축하고 강화하게 될 것이다.

2006년까지 요구와 대안적인 IT 소싱, 배치와 관리 전략을 위해 고안된 어플리케이션을 통합하여 이러한 제약 내에서 선두 RCO가 어떻게 중요한 가치를 달성하게 되었는지 입증할 수 있게 될 것이다. 일부 조직은 대안이 존재할 때 자원 집약적(resource intensive) 솔루션을 배치하고 유지하게 될 것이라는 간단한 이유로 인해, 크기에도 불구하고 이러한 모범 사례는 모든 조직에 관계가 있게 될것이다. 대규모 중앙 집중식 어플리케이션 배치를 위해 현재 판매되고 있는 복잡하고 포괄적이고 맞춤에 의해 결정되는(customization-dependent) 솔루션은 점점 더 매력이 없어지게 될 것이기 때문에 RCO에 특정한 솔루션에 전념하지 않는 벤더에 대한 영향은 상당한 것이 될 것이다.

META 트렌드: 2004/05년 동안, “go live” 후 ERP 조직은 총 소유비용, 가치 전달, 가용성, 연속적 비즈니스 개선과 목표한 확장(예를 들어, 공급업체 관계 관리, 채널 관리)에 중점을 두게 될 것이다.

ERP 벤더는 성숙중에 있는 ERP 고객들에게 강화된 구현 후(post-implementation) 서비스를 제공할 것이다. 2004-07년의 기간 동안, ERP 벤더는 마이크로소프트 그리고 감소중인 소규모 ERP 벤더들과 더욱 공격적으로 경쟁하면서 미드마켓에 침투하기 위한 노력을 배가할 것이다. 2007년까지 ERP 벤더는 기업간 통합을 지원하기 위해 웹 서비스를 포용하게 될 것이다.

역 관계: 비즈니스 어플리케이션 비용과 조직 크기
일반적으로 정보 기술, 구체적으로 비즈니스 어플리케이션은 소규모 조직에게 더욱 비싸다(그림 1 참조). 메타 그룹의 2004 IT 세계 벤치마크 보고서에 따르면, 조직의 수입 규모가 줄어들면서 운영 비용 비율과 수입 모두로써의 IT 지출은 증가했다.

이 같은 추세는 일반적으로 IT에 적용될 뿐만 아니라 구체적으로 비즈니스 어플리케이션에도 적용된다(그림 2 참조). 메타 그룹의 보고서 21세기 ERP 어플리케이션으로부터 가치 유도는 비즈니스 어플리케이션에 같은 비용 상관관계가 존재한다고 파악했다.

그림 2. 조직 규모별 상대적 ERP 총 소유비용

그러므로, 2 계층(Tier)  조직을 위한 ERP TCO는 1 계층 기업보다 138%나 많다. 3 계층 조직은 2 계층 기업보다 150%나 더 높고 1 계층 조직보다 253%나 더 높다(그림 3 참조). 조직 크기에 관계없이 자본 대 운영 지출 사이의 분산은 놀랍게도 비슷하긴 하지만 이러한 상황 모두가 발생하고 있다.

그림 3. 자본 대 운영 비용에 지출된 IT 예산 비율

자본과 운영 지출 비율은 같지만 수입 규모가 줄어들면서 조직에 대한 총 비용이 증가하는 경우, 어플리케이션 자체와 관련된 비용 구조는 문제가 된다고 주장할 수 있는 경우가 있다. 당사의 2004 IT 세계 벤치마크 보고서의 자료에 따르면 자원 가용성이 증가함에 따라 비즈니스 어플리케이션에 적용되는 비용과 노력은 불균형적으로 증가한다.(그림 4와 5 참조). 어플리케이션 유지와 어플리케이션 개발을 위한 상근 직원의 배치는 가장 작은 표본 그룹의 경우보다 각각 38%와 40% 높았다. 작은 조직이 어플리케이션 FTE 사용에 더욱 효율적이기 때문일까? 이전에 언급한 더 높은 TCO를 고려해보면 이러한 결론은 의심의 여지가 있다. 대신, 대규모 조직의 어플리케이션 유지와 개발 FTE 비율은 실제로는 이들 제품에 필요한 비율일 것이다. 소규모 조직이 그러한 기능에 적절하게 직원을 배치하지 못한 것은 다른 중요한 IT 기능 분야에 직원을 배치해야 하기 때문이었다. 그렇다면 자연히 다음에 나오게 될 문제는 상당한 추가적인 자원이 충당된 후에만 언급할 수 있는 비즈니스 어플리케이션에서의 “가치 잠재력(value latency)”이 있다는 것이다.

그림 4. 조직 규모별 FTE 할당

그림 5. 1계층과 3계층사이의 FTE 할당 비율의 변화

아마도 현재의 상태는 비즈니스 어플리케이션이 2002년까지 시장을 정의해온 중앙 집중식 자원-집약적 배치의 세계에 전개되었기 때문에 발생했을 것이다. 풍요의 시기동안 많은 제품이 구축되고 시장 지향 제품이 나왔으며 이와 함께 다음을 포함한 상당 수의 고비용 그리고 종종 유연성없는 비용 구조를 가져왔다:

. 전체 조직의 수입/비용 기반에 걸쳐 상환할 때 대규모 미국/유럽 조직이 저렴하다고 간주한 기반에서 구축된 초기 라이센스 비용

. 어플리케이션 정가의 고정 비율에 기반한 가격 구조로부터 발생했던 높은 유지보수 가격
. 무모한 커스터마이징을 초래했던 툴킷-설계 접근법
. 기능과 특징의 양에 중점을 둔 아웃소싱 전략
. 맞춤 중심의 설계와 기능 중심 소싱 전략으로 인한 불충분하게 의무가 부가되고 값비싼 전문 서비스 계약
. 종종 별도의 어플리케이션 서버, EAS 기술과 BI 프레임워크를 요하는 단편화된 서브시스템, 모두 합쳐져서 통합 및 직원 비용 증가시키고 비즈니스 어플리케이션 설계가 서비스-지향, 모델-위주 아키텍처로 이동함에 따라 더 높은 통합 및 직원 비용의 가능성이 존재한다.

이러한 결과를 초래한 것은 하나의 요소만이 아니다. 벤더와 고객 모두 공생적 관계를 구축하며, 이 관계에서 벤더는 증가하는 자원을 요하는 제품을 공급하는 반면, 점점 더 많은 전문적 기술로 부흥하고 있는 IT 부서는 다양하고 복잡하고 분산된 비즈니스 어플리케이션과 관련된 비용을 간과하고 있다. 기능이 풍부한 어플리케이션에 대한 선호와 구매한 제품을 맞춤화하려는 습관에 가까운 욕구는 IT 부서와 벤더의 행동을 정당화할 수 있는 연료를 제공하기 때문에 비즈니스 사용자들은 결백하지는 않다. 모든 당사자는 불충분한 소비의 조용한 공모에 동참하는 것 같다.

관련 비용이 손익 계산서에 묻히기 때문에 불충분한 시스템이 대규모 조직 내에서 숨겨지기도 한다. 비효율성을 감출 수 없다는 간단한 이유로 인해, 비즈니스 어플리케이션 벤더와 그들의 1 계층 고객(수입이 10억 달러 이상)이 상호작용하는 패러다임을 RCO에 대하여 유지할 수 없다. 무익함은 계속 반복된다는 속담을 있지만 다른 결과를 기대하면서
RCO는 새로운 공생관계를 만들게 될 대안적인 패러다임을 반드시 추구해야 한다. 감소된 자원 소싱, 배치와 유지보수 모범 사례와 동일한 기술 플랫폼의 실현을 허용하는 일련의 운영 모범 사례를 가능하게 해주는 기술 플랫폼에 의존하는 공생관계를 만들어야 한다.

RCO 패러다임: 기술과 운영 모범 사례사이의 새로운 공생관계 구축

반직관적이기는 하지만 RCO는 축소된 또는 낡은 기술 프레임워크(일부 밴더는 SMB 고객을 위해 클라이언트/서버 기반 제품을 옹호)를 필요로 하지 않는다. 사실, 이는 자체 기술형 XML 모델 서비스 인터페이스(불투명한 소프트웨어 API에 대한 전통적인 강조와 대조하여)에 대한 서비스-지향 아키텍처(SOA)의 중점을 기반으로 구축된 차세대 아키텍처이다. 메타그룹은 이러한 진화적 개념을 위해 “모델-지향적 아키텍처(MOA)”를 사용하기 시작하고 있다. 벤더와 RCO, IT 조직(ITO)과 비즈니스 사이의 균형을 변경시키는 수단이 이러한 적응형 인프라에 내재되어 있기 때문에 모델-지향적 아키텍처는 RCO에게 중요하다. MOA는 RCO 중심의 소싱, 배치와 유지보수 전략을 가능하게 해주는 기술적 토대가 될 것이다.

RCO가 직면한 위험은 2가지이다.첫째, MOA는 아직 사용할 수 없다. 둘째, 하부 구성요소가 고도의자원 가용성을 가정하여 단편적으로 제공된다면 MOA는 실행 가능한 옵션이 되지 못할 것이다. 대신, RCO는 더 적은 부분의 이동으로 MOA를 만들어서 이와 관련된 비용과 복잡성을 줄여야 한다. 우리는 이를 어플리케이션 통합 대 통합된 어플리케이션 사이의 선택이라고 부른다. RCO는 반드시 후자에 중점을 두어야 한다.

좋은 소식은 어플리케이션 벤더 공동체가 낮은 총 소유비용(TCO)으로 통합된 어플리케이션을 제공하기 시작했다는 점이다. 하지만 제품과 사례 사이에 새로운 RCO기반의 공생관계를 만드는 것이 목표이기 때문에 운영 행태가 자원 집약적 어플리케이션 배치의 세상에서 발생한 행태로부터 변화하지 않는 경우, 그러한 새로운 어플리케이션은 가치가 없게 될 것이다. 모범 사례는 RCO 패러다임을 위한 토대인 4가지의 “주제”로부터 발생해야 한다:

. 복잡성 교정을 위한 통합(Consolidate to cure complexity): 비용과 복잡성은 서로 밀접하게 연관되어 있으며 RCO 패러다임의 가장 중요한 요소 중 한가지는 통합(consolidation)을 통한 단일성(simplicity)의 적극적인 추구이다. 이 원칙을 이해하는 열쇠는 메타 그룹의 기업 기술 모델(사례 2127, 2150 및 Delta 2770 참조)이다. 통합은 기술 상용화의 세력을 고려한다. 간단한 어플리케이션 벤더 통합보다 더욱 필수적인 활동, 전략적 플랫폼 제공자(예를 들어, SAP NetWeaver,  오라클 어플리케이션 프레임워크,마이크로소프트 닷넷)에 대한 확고한 결정도 필요하다. 모든 아웃소싱, 운영과 수요 관리 활동은 처음부터 명확한  종말(end-of-life) 전략을 가지고 플랫폼 통합을 지원하도록 설계되어야 한다.

. 공유성 포용(Embrace commonality): 총 소유비용의 37%로, 전문 서비스는 ERP 배치의 가장 큰 단일 비용 요소이다. 이는 대부분의 조직이 잘 이해하고 있는 사실이다. 높은 컨설팅 비용은 조직이 ERP 솔루션을 구현하지 못하게 만드는 가장 큰 원인으로 언급되기도 한다. 우리의 조사를 자세히 살펴보면 모든 경우에 있어 ERP 배치의  가장 큰 2개의 비용 요소는 업무 재설계와 맞춤 코드(custom code) 개발이다. 많은 경우 업무 재설계가 보장되기는 하지만 이 모든 재설계 작업이 진정으로 시장 차별적 프로세스를 유발하는지, 표준 비즈니스와 업계 프로세스를 수행하는데 있어 조직의 특유한 성질을 나타내는 어플리케이션을 수정하는 수단일 뿐인지는 두고 볼 일이다. 메타 그룹의 “21세기 ERP의 가치 유도”에서 배운 주요한 교훈 중 한가지는 “일반적 단순 선택(going vanilla)” (일반적인 구현)의 중요성이다. 하지만 이 의도를 갖고도 많은 조직들은 이 목표를 달성하지 못한다. 단순 선택을 현실화 시키는데 있어 핵심적인 열쇠는 비즈니스를 다르게 만드는 것이 아니라 같게 만드는 것이 무엇인지 연구해서 이를 자동화시키는 상용화 프로세스를 적극적으로 추구하는 것이다. 이는 비즈니스의 모든 프로세스가 별개의 것으로 간주될 때 발생하는 자체 부과된 복잡성을 제거하는 것을 의미한다. 대신, 그 조직들은 보편적 업계 방법에 부합하지 않는(out-of-the-box) 비즈니스 프로세스가 조직 내 어디에 적용되어야 하는지 판단하고 결과적으로 맞춤화/비즈니스 프로세스 관리 노력이 어디에 중점을 두어야 하는지 판단하는 수단인 선행적인 프로세스 상용화에 착수하게 될 것이다.

. 일반화의 환영(Salute generalization): 메타 그룹은 고정 IT 비용에서 가변 IT 비용으로의 이전 추진을 지지한다(ED Delta 302 참조). ITO에서 가장 많은 비용은 직원에 대한 것이며, 2006/2007년까지 총 IT 비용의 55%- 60%로 증가할 것으로 예상된다(Delta 2927 참조). RCO는 일반화된 직원 역량 대 전문화된 직원 역량을 추구함으로써 이 중요한 자원 제약을 가장 잘 언급할 수 있다. 이는 별개로 수행될 수 없으며 플랫폼 통합이라는 첫 번째 주제와 내재적으로 연계되어 있다. 예를 들어, 배치와 관리를 위한 별도의 기술 집합을 필요로 하는 J2EE 어플리케이션 서버에 구축된 어플리케이션은 마이크로소프트 윈도우 서버의 같은 어플리케이션 서비스를 활용하는 어플리케이션 대 일반화된 기술 집합을 달성하기 위한 최적의 수단은 아니다. 직원 일반화는 광범위한 어플리케이션 유지보수 요건에 대한 기술을 보급함으로써 비용을 절감한다. 우리의 조사에 따르면 고성능 IT 팀은 인프라의 성능 또는 “완전한 툴세트 역량”을 모든 팀 구성원이 상당한 작업량을 수행하기 위한 선결 요건으로 간주한다. 신속한 팀 재구성(team reaggregation)과 이로 인한 신속한 프로젝트 이행은 IT 표준화를 촉진하는 것 같다. 직원들은 팀 구성 전에 일반적인 툴세트에 익숙해져야 하기 때문에, 경험이 많은 CIO는 수평적으로 통합된 IT 인프라(예를 들어, 공통 백본, 공유 서비스 -ED Delta 303 참조)로의 수렴을 촉진하기 위해 팀 기반의 원칙을 추진하고 있다.

. 모든 것에 앞서는 프로세스(Process uber alles ): 어플리케이션 기능과 특성은 추상적이며 비즈니스 요구를 포장해서 재판매할 수 있는 형식으로 변환하는 방법이 된다. 실제로 일련의 프로세스 내에서 운영되는 비즈니스 그리고 밀접한 정보 시스템은 이 현실을 변환에서 손실되는 비즈니스 의미의 확률을 너 낮게 나타낼 수 있다. 프로세스-중심성은 2가지 이유로 반드시 RCO를 위한 토대가 되어야 한다. 첫째, 프로세스는 MOA의 중심에 위치하게 될 것이다. 이 아키텍처의 미래 가능성을 실현하기 위해 RCO는 이에 중점을 두기 시작해야 한다. 둘째, 프로세스-중심성은 비즈니스와 IT 사이의 연계를 구축하여, 상호간에 보장된 의무를 구축하도록 도와준다.

결론
RCO는 그들의 자본, 직원과 운영 제약 내에서 비즈니스 결과물을 달성하게 될 새로운 기술과 프로세스 공생 관계 구축을 위해 노력해야 한다. RCO 패러다임의 4가지 주제는 이러한 상호작용에 대한 메커니즘이다.

비즈니스 영향: RCO 패러다임은 상당한 자원 절감과 함께 IT에 기반한 비즈니스 결과의 달성을 지원하는 운영상 모범 사례와 기술 프레임워크를 구축하는 장기적인 전략이다.