아름다운프로'의 JTOP.org 백업사이트

SELECT MSysObjects.Name
FROM MSysObjects
WHERE (((MSysObjects.Type)=1));

에서

MSys로 시작하는 테이블만 걸려서 가져오면 엑세스에 있는 테이블 이름들
가져옵니다.

^^ 잊어버릴까봐.. 흔적 남기기..
==================================
특정 칼럼 감추기..

.active-column-0 {display: none!important;}

===================================

To disable column resizing on all columns - add the following stylesheet rules:

<style>
.active-box-resize {display: none;}
</style>

To disable resize on one column (for example the first one):

<style>
.active-column-0 .active-box-resize {display: none;}
</style>

본인이 점점 나이를 먹어서인지도 모르겠지만 옛날에는 IT 세계가 참 단순했다.



대기업이 시장을 지배할 당시 IT 부서가 개발한 애플리케이션들은 대부분 단일한 데이터 소스를 공유했으며 애플리케이션 클라이언트 같은 경우도 동일한 기반 코드와 플랫폼을 공유했다. 데이터는 쉽게 접근되는 파일이나 메인프레임 테이블에 존재했기 때문에 배치 문제도 없었고 애플리케이션 간 데이터 공유도 쉬웠다.



한 시대를 풍미한 클라이언트/서버(C/S) 컴퓨팅에서도 역시 파워빌더나 비주얼 베이직으로 개발된 덩치 큰 윈도우 애플리케이션 클라이언트는 ‘엔터프라이즈 데이터 모델’로 불리는 단일한 관계형 데이터베이스를 공유했다. 이를 가능케 하는 서비스 데스크톱도 회사 내에 위치해 있었다.



이 아키텍처는 애플리케이션들이 트랜잭션을 통해 다른 애플리케이션의 데이터를 업데이트하는 방식으로 데이터 공유를 허용했다.



그러나 세계는 변화하고 있다. 모든 것이 연결된 세계에서 ▲기업내 혹은 기업간 데이터 공유에 대한 필요성 ▲범용 하드웨어에 애플리케이션을 확장해야하는 필요성 ▲윈도우 데스크톱 PC에서 다른 웹사이트나 PDA, 태블릿 PC에 걸친 다양한 클라이언트를 지원할 필요성 등으로 한때 간단했던 그림이 지금은 매우 복잡해진 상태다.



과연 애플리케이션들을 이 화려한 신세계로 어떻게 가지고 나올 수 있을까? 정답은 바로 서비스 지향 아키텍처(SOA)다.



가장 단순하게 분류해보면 별도의 애플리케이션들이 각각 수행하던 기능은 SOA에서 비즈니스 서비스 집합으로 나눠지게 된다. 이 서비스들은 ‘X를 알고 싶다’와 같은 서비스 요청 메시지를 수신하고 ‘Y는 여기 있다’라는 서비스 응답 메시지를 송신함으로써 고객, 그리고 내/외부의 서비스와 서로 통신을 주고 받는다. 이런 메시지들이 플랫폼, 장비에 독립적이려면 XML과 SOAP으로 표현, 전달되야 한다는 것은 매우 당연한 사실이다.



그러나 아키텍트, 개발자들이 SOA 설계와 구현에 대해 실제적으로 생각하면서 문제가 발생한다. 여기에는 어떤 데이터 서비스를 공유하고 데이터 접근과 관리는 어떻게 할지, 데이터를 어떻게 표현할 지와 같은 것들이 있다.



이 기사에서는 SOA에 사용되는 데이터의 유형들을 살펴보고 서비스 내/외부에 존재하는 데이터의 표현 방법을 알아볼 것이다. 아래 기술되는 내용은 SOA를 고려하기 시작한 바로 그 시점에 당신의 생각을 명확히 하는데 도움이 될 것이다.



어떤 데이터를 표현해야 하나?

SOA를 구축할 때에는 4가지 데이터 유형을 우선 고려해야 한다. 이들은 서비스 외부에서 내부로 들어가는 순서에 따라 메시지 데이터, 조사 데이터, 프로세스 데이터, 비즈니스 데이터로 나눠진다. 이제 각 데이터들의 유형과 특징을 정의하고 데이터를 다룰 때 필요한 정보가 뭔지 살펴보자.



메시지 데이터

서비스 사이를 흘러 다니는 데이터를 메시지 데이터라고 한다. 이 데이터는 서비스 사용자가 원하는 업무나 동작인 ‘요청’과 그 결과로 고객이 받는 ‘응답’을 정의해준다.



서비스와 서비스 사이에는 이 데이터만이 송수신될 수 있다. 따라서 메시지 데이터는 서비스의 개방형 인터페이스를 표상하는 역할도 함께 담당한다. 이로 인해 SOA는 플랫폼 독립적인 성격을 갖게 된다.



정의에 따르면 메시지 데이터는 사용자가 요청을 구성하고 응답을 처리하는 방법을 발견할 수 있도록 하는 개방형 스키마(schema)를 요구한다. 따라서 ‘서비스에 의해 노출되는 동작’이라는 정의에 비춰볼 때 메시지 데이터는 비교적 정적인 성격을 갖는다.



그러나 변화가 생기면 분명히 버전을 명시해 관리해야 한다. 또한 메시지 데이터는 한번 작성되면 바꿀 수 없으며 변경 자체가 불가능하다.



서비스들은 생성시각, 버전 id, 대화 id, 대화 내부의 일련번호 뿐 아니라 각 메시지별로 유일 식별자를 생성해 메시지 데이터를 다룬다. 물론 보안 토큰도 여기에 포함된다.



이렇게 추가 정보를 이용하면 서비스는 생성시각을 참조해 제때 도착하지 않은 메시지를 버리는 등 메시지들을 적절한 순서로 한번만 처리할 수 있다. 또한 서비스는 여러번 도착한 메시지에 대해 이전에 만들어 캐시해놓은 응답을 보내 해결하기 위해 요청과 응답을 저장해놓는다. 이런 과정은 성능도 향상시킨다. 메시지 데이터는 조사 데이터를 이동시키는데 자주 사용된다.



조사 데이터

서비스에서 다뤄지는 두번째 데이터는 조사 데이터다. 이 유형의 데이터는 서비스 요청 동작의 일환으로 매개변수를 전달하거나 서비스 응답에서 온 데이터를 해석하는데 사용된다. 이 과정 이후 사용자는 조사 데이터를 요청하게 되며 이후 요청 메시지를 구성하기 위해 조사 데이터를 사용하게 된다.



예를 들어 기술 교육 제공 업체는 교육 장소와 업체들로 구성된 조사 데이터를 발행할 수 있다. 따라서 사용자들은 수업 스케줄을 요청할 때 유효한 값들을 전달할 수 있다.



예상하겠지만 조사 데이터도 비교적 정적이다. 그러나 변화가 있을 때는 버전 관리를 해야 한다. 즉 각 버전의 조사 데이터끼리는 변화가 없는 것이다. 메시지 데이터처럼 조사 데이터도 서비스 외부에서 사용되며 개방형 스키마를 요구한다.



서비스는 조사 데이터를 다룰 때 각 항목에 유일한 버전 id를 부여한다. 예를 들면 ‘퀼로지-위치코드-v012004’와 같은 식이다. 이 방식대로라면 사용자는 요청 작업을 수행할 때 참조 데이터 버전을 전달하기 때문에 서비스가 적절한 응답을 만들어낼 수 있다.



결국 조사 데이터는 일반적으로 정기적인 갱신 작업을 요구하게 된다. 따라서 서비스는 이메일, HTTP, 심지어 DVD까지도 사용하는 푸시(push) 방식이나 HTTP, FTP, 이메일을 이용한 풀(pull) 방식을 사용해 새로운 버전을 관심있는 가입자들에게 전달한다.



프로세스 데이터

서비스 내부에서 최초로 다뤄지는 데이터가 바로 프로세스 데이터다. 메시지나 조사 데이터와는 달리 프로세스 데이터는 각 서비스마다 고유하며 내부에 감춰지기 때문에 개방형 스키마가 필요없다.



프로세스 데이터는 서비스가 수행하는 비즈니스 절차나 기능 등을 표현한다. 대개 이 데이터들은 장기적인 동작 과정을 거쳐 완성된다. 이의 예로는 쇼핑 바구니, 구매 명령, 송장 등이 있다.



프로세스 데이터는 클라이언트나 대화에 의존적이며 단일 클라이언트에 의해 순차적으로 접근되기 때문에 병행성에 대한 요구가 낮다. 조사 데이터와 달리 동작 중에도 업데이트할 수 있으며 동작이 완료되면 일반적으로 읽기만 가능한 상태가 된다. 따라서 시간이 갈수록 참조 회수도 작아진다.



서비스 프로세스는 메시지를 요구하고 서로 대화하기 위해 서비스 사이에 프로세스 데이터를 구축하게 된다. 따라서 이들은 대화 인식자를 이용해 프로세스 데이터와 상관관계를 유지해야 한다.



서비스는 프로세스 데이터를 조작하는 다양한 기법을 사용할 수 있다. 예를 들면 프로세스가 활성화된 시간 동안 서비스는 프로세스 데이터를 객체에 캡슐화해 메모리에 캐시할 수 있다. 또한 서비스는 종료되거나 포기된 프로세스를 깨끗하게 제거할 수 있어야 한다.



비즈니스 데이터

SOA에서 사용되는 데이터의 마지막 유형은 비즈니스 데이터다. 이 유형은 고객 정보, 제품 재고, 은행 계좌들처럼 사람들이 애플리케이션을 생각할 때 떠올리는 바로 그것들이 대부분이다.



프로세스 데이터처럼 비즈니스 데이터도 각 서비스마다 고유하며 개방형 스키마를 필요로 하지 않는다. 그러나 프로세스 데이터와 달리 단일한 장기적 동작보다는 그 수명이 길며 여러 동작에 의해 동시에 변경될 수 있기 때문에 병행성에 대한 요구가 높다. 결과적으로 비즈니스 데이터는 휘발성이 강하며 본질적으로 유동적인 자료의 형태에 가깝다.



서비스가 비즈니스 데이터와 상호작용할 때 가장 중요한 부분은 단일 소유주의 원칙에 충실해야 하는 것일 것이다. 즉 서비스는 기업의 일부 데이터에 대해 소유 권한을 가져야 한다.



예를 들어 한 서비스는 고객 데이터를, 다른 서비스는 직원 데이터를 가질 수 있다. 데이터 공유가 필요한 경우 각 서비스는 변경사항을 다른 서비스에 공개하고 다른 서비스들은 내부에서 사용하기 위해 이것을 캐시한다.



따라서 서비스 데이터의 공개는 늘어나는 각 식별자들과 함께 버전이 관리돼야 한다. 서비스의 소유자만이 데이터를 업데이트 해야 하며 소유자가 아닌 사용자에 의한 변화 요청이 제기될 경우 소유권을 가진 서비스는 변경 작업을 진행한 이후 관심있는 가입자에게 해당 데이터를 재공개하는 절차를 밟아야 한다.



데이터 유형을 다루고 저장하는 방법은?

데이터 유형이 정의되면 이것을 처리하고 저장하기 위해 어떤 기술을 사용해야 할지 궁금할 것이다. 바로 XML, 객체, SQL이 기술의 핵심을 이룬다.



메시지 데이터

메시지 데이터는 개방형 스키마과 이질성을 요구하므로 SOAP을 이용한 모델이 가장 적합하다. 따라서 WSDL을 이용한 메시지 스키마를 발행할 수 있다. 또한 생성시각과 보안과 같이 구현하고자 하는 메시지 데이터 기능의 일부는 WS-*와 같은 SOAP 표준이나 MS의 웹서비스 인핸스먼트(WSE) 2.0과 같은 툴킷으로 구현할 수 있다.



서비스 내부에서는 동일성을 구현하기 위해 관계형 데이터 내부에서 인식 속성이 메시지 데이터에 XML 형태로 저장될 수 있다. 속성에 질의문이 주어질 가능성이 크기 때문에 이 방식이 권장될 수 있긴 하지만 불변성 측면에서 볼 때 메시지 내용을 자주 읽고 파싱(parsing)하는 것은 좋지 않다.



또한 메시지를 저장하면 감사, 그리고 향후 진행될 분석이 가능해진다. 그러나 유형 정의에 비춰볼 때 메시지 데이터는 가장 생명이 짧다. 또한 분석에 사용되지 않는다면 더 쉽게 저장될 수 있다.



메시지 데이터에 대한 또다른 측면은 서비스 간 메시지 송신이 이뤄질 때 어떤 일이 발생하는가에 관한 것이다. 독립적으로 전개되는 다중 서비스에 메시지 구조가 사용되는 조직 환경에서는 메시지가 서비스에 의해 소비되기 이전에 표준 스키마로 변환되도록 조치하는 것이 좋다. 이는 조사, 비즈니스 데이터를 각 서비스가 다른 형태로 표현할 때 일어날 수 있는 문제점들을 미연에 방지해주며 데이터 변환의 횟수를 획기적으로 줄일 수 있다.



조사 데이터

조사 데이터는 공개적이며 개방형 스키마를 요구하기 때문에 XML로 모델링돼야 한다. 즉 버전 정보를 표시하면서 조사 데이터의 스키마를 WSDL로 나타내는 방식이 좋다. 데이터베이스 측면에서 볼 때 조사 데이터는 한번만 기록되고 XML에 의해 직접 추출될 수 있기 때문에 성능 증가의 목적으로 관계형 테이블의 XML로 저장될 수 있다.



또한 관계형 테이블에 조사 데이터를 저장함으로써 버전 관리도 쉬워진다. 서비스는 내부적으로 메모리에 현 조사 데이터를 캐시할 수 있다. 이렇게 되면 사용자가 조사 데이터를 요청할 때 응답시간을 단축할 수 있다.



프로세스 데이터

프로세스 데이터는 서비스에 고유하기 때문에 XSD로 발행되거나 XML로 표시될 필요가 없다. 따라서 대개 표준화된 관계형 데이터베이스 테이블로 저장되며 예를 들면 비쥬얼 스튜디어 닷넷 ‘위드비(Whidbey)’와 함께 출하될 오브젝트스페이스(ObjectSpaces)와 같은 객체 보존 계층을 사용해 서비스 내부에 캡슐화된다.



이와 같은 방식으로 서비스는 메모리에서 프로세스 데이터를 완전한 객체로 처리하고 ASP.NET 캐싱 엔진과 같은 캐시 기술을 활용할 수 있다. 프로세스가 완료되거나 대기 상태에 들어가면 객체는 객체보존 계층을 이용해 데이터베이스에 차례로 나열된다.



프로세스 데이터는 단일 대화 내부에서 순차적으로 업데이트되기 때문에 병행성에 대해 낙관적일 수 있다. 분석을 위해 중요한 프로세스 데이터를 저장하는 것도 필요하다. 그러나 만들어진지 오래될수록 데이터들은 아카이브 형태로 보존될 것이다.



비즈니스 데이터

프로세스 데이터처럼 비즈니스 데이터는 서비스에 고유하며 XML로 표현되지 않는다. 물론 일부가 응답 메시지로 보내지는 경우는 예외다. 이런 경우 정형화된 XSD가 생성돼 다른 서비스들이 이 데이터를 해석할 수 있다.



따라서 비즈니스 데이터는 표준화된 관계형 테이블에 저장되며 COM+와 같은 트랜잭션 관리자에 의해 관리되는 구성요소를 통해 캡슐화된다. 이것은 트랜잭션 과정에서 병행성을 비관적으로 만들어 잠금을 보장하기 위한 것이다.



구성요소 자체는 데이터에 상태와 상관없는 접근을 제공하는데 이것은 높은 휘발성과 병행성 때문이다. 비즈니스 데이터는 프로세스 데이터와 결합돼 분석에 사용된다.



모델 산출

아래 그림에는 여기서 논의된 4가지 데이터 유형이 요약돼 있다. SOA를 개발할 때 독자들이 소속된 기업의 데이터를 위치시킬 수 있는 그림을 그리는데 도움이 됐으면 한다. 여기에는 SOA에서 사용되는 4가지 데이터를 강조하고 있으며 이들이 어떻게 표현되고 처리되는지 보여주고 있다. @

http://images.zdnet.co.kr/images/2004/06/69587-1.jpg

SOA 개념상 모델

골드랫박사와 Q&A에서 이루어진 내용 몇 가지

Q: 한국에서는 6시그마가 한창인데 TOC와 6시그마는 어떻게 틀리며, 어떻게 서로 공존할 수 있는지 박사님께서 시원한 답을 주시길 바랍니다.
A: TOC가 6시그마와 틀린 것은 굳이 설명을 하자면 6시그마는 변동성을 줄여서 기업이익을 극대화하는 것이라고 말씀드릴 수 있습니다.

즉 y=f(x)라는 함수에서 y값을 움직이는 x인자를 찾아서 해결책을 찾는 반면에 TOC는 기업의 목적인 돈을 벌지 못하게 방해하는 제약을 찾아서 끊임없이 없애는 활동으로서 대별할 수 있습니다.

특히 차이점은 6시그마는 시장에 제약이 있을 때 Solution을 주기 어렵다는 것입니다.

그러나 TOC는 제조현장에 제약이 있을 때 능력 제약을 해결한 후에는 제약이 다른 곳으로 옮겨가는데 특히 시장(Market)으로 옮겨갔을 때 TOC에서는 마피아 오퍼라는 것이 있는데 TOC에서는 market에 제약이 있든 R&D에 제약이 있던지 그것을 해결할 수 있는 Solution이 이미 적용되어 성과를 보았다는 것입니다. 6시그마는 그것을 해결할 수 있는 방법에 한계가 있다는 것입니다.

이것이 첫 번째 틀린점이며, 두 번째는 TOC에서는 모든 비 제약을 제약에 종속시킨다는 말이 있는데 이것이 6시그마와 틀린 점입니다.

즉 TOC에서는 제약에 맞춰서 모든 Resource들이 종속되어야 하며 그 이상의 능력은 신기루에 불과하다는 것이 가장 큰 룰 입니다.

또한 6시그마가 잘못되었다고는 하지 않습니다. TOC와 비교했을 때 집중하는 강도가 낮다는 말입니다. 6시그마도 훌륭한 혁신기법입니다. 단지 TOC에서 핵심문제를 찾아서 그곳에 6시그마를 TOOL로 하여 변동성을 줄이는 데는 효과적으로 활용 할 수 있습니다.

TOC와 6시그마는 이렇게 서로 TOC에서 기업의 제약을 찾아서 6시그마로 변동성을 최소화하는데 서로가 적절하게 활용될 수 있다는 말입니다.

그러나 TOC를 변동성을 줄이는 한가지 방법으로 취급한다면 그것은 틀린 것 입니다.

TOC는 돈을 번다는 것에 초점이 맞춰져 있습니다. 그것을 명심하십시오.

현재에도 미래에도 지속적으로 돈을 벌도록 하는 것이 바로 TOC입니다.

Q: 한국에서 TOC를 전파하기 위해서는 CEO들을 움직여야 하는데 박사님께서는 어떻게 TOC를 한국에 전파하기 위해서 CEO들을 움직여야 한다고 생각하십니까?

A: 한국의 CEO들은 다른 나라 CEO들과 틀린 점이 없습니다. 그 분들도 돈을 번다는 것에는 마찬가지입니다. 그러나 CEO들을 우선 설득하기 위해서는 여러분들이 즉 TOC를 어느 정도 아시는 분들이 TOC를 기업에 적용하여 성공사례를 많이 만들어야 합니다.

왜냐하면 TOC는 사실 상식이라고 생각하기 때문입니다.

그것이 CEO들을 설득하기가 어렵습니다.

상식적인 것을 현재 하고 있지 않아서 기업이 돈을 벌지 못하고 있다는 것을 인정하지 않는 다는 것입니다.

그러나 TOC를 적용하여 성과를 낸다면 정말 그것이 훌륭하다는 것을 CEO들은 인정하고 전 기업에 확산이 될 것입니다. 여러분들이 힘써서 TOC를 전파하는 파수꾼이 되십시오. 감사합니다.

마지막으로 TOC를 정리하겠습니다.


TOC라는 것은 전세계적으로 이미 성과가 검증되었습니다.
여러분들이 TOC를 받아들이든 그렇지 않든 간에 TOC는 계속 발전할 것이며 TOC를 받아들이는 기업은 반드시 성공하리라 생각합니다. TOC는 반드시 기업은 돈을 벌어야 한다는 명제를 달성 하는데 초점이 맞춰져 있다는 것을 명심하시길 바라며 이상으로 한국 기업인들에게 감사 인사를 드립니다. 감사합니다.

또한 이번 컨퍼런스에서는 귀중한 한 사람이 말레이시아에서 왔습니다.

다름아닌 EAN이라는 TOCFE의 아시아 지역책임자로써 현재 말레이시아 및 아시아에서 학교에 무상으로 TOC를 전파하고 있습니다.

특히 학생들이 TOC를 활용하여 본인들의 문제와 학습에 대한 많은 것 들을 해결해 나가는 활동을 지원하는 TOCFE 아시아 책임자인 Ean에 의하여 TOCFE 소개가 이루어졌습니다.  

한국에도 TOCFE를 활성화 시키기 위해서 향후 일정을 잡고 있습니다.

이렇게 이틀간의 일정이 모두 마무리 되었으며 한가지 아쉬움이 있다면 한국의 기업이 아직도 6시그마 그늘에서 벗어나지 못하고 있다는 것이 아쉬움으로 남습니다.

사실 한국TOC컨설팅에서는 한국기업에 TOC를 올바르게 전파하고자 노력하고 있으면서 많은 기업들이 ,이번 컨퍼런스에 참석하지 못함이 한국에 TOC가 전파되는 것이 너무 뒤지지는 않을까 하는 생각입니다.
특히 한국에서 골드랫 박사와의 4일간은 한국TOC컨설팅에도 많은 도움이 되었으며 앞으로 한국기업에 어떻게 TOC를 전파해야 하는지도 골드랫 박사에게 많은 조언을 들을 수 있음을 이번 컨퍼런스의 가장 큰 수확이라고 생각합니다.

그리고 골드랫 박사는 전폭적인 지원을 한국TOC컨설팅에 하기로 하였으며 한국을 다시 방문하는 날까지 한국에 TOC를 올바르게 전파할 것을 당부하였으며, 한국 TOC컨설팅은 골드랫 박사의 기대에 부흥하기 위해서 한국에 올바른 TOC를 전파하여 한국기업들이 국제 경쟁력을 갖추는데 손색이 없도록 올바른 TOC전파의 전도사가 되도록 노력하겠습니다.

여러가지 골드랫박사에 대해서 많은 이야기를 나누었지만 지면에 쓰는 것이 한계가 있어서 다른 기회를 통해서 나누고자 합니다.

-----------------------------------------------------------------------------------

TOC창시자 골드랫 박사를 초빙하여 2004년 한국최초로 TOC 컨퍼런스& CEO포럼을 그랜드힐튼 호텔에서 약 250여명 정도를 참석시킨 가운데 성황리에 개최하였다.

이 자리에는 삼성전자, 엘지전자, KT, 현대 중공업, 이랜드 등 대기업 및 중견기업 사장님, 임원 그리고 혁신관련 담당자 분들이 한자리에 모여 TOC의 새로운 혁신 이론과 성공사례 등을 습득하는 TOC의 한마당이 되었다.

첫째 날 골드랫 박사의 강연을 시작으로 마지막 날 골드랫 박사의 Q&A까지 한 시간도 낭비 할 수 없는 귀한 시간들이 전개 되었다. 특히 골드랫 박사가 이번 컨퍼런스에서 차지하는 비중이 거의 60%이상 할애되어 TOC의 탄생과 TOC에 대한 한국의 현주소와 전세계에 활용되고 있는 TOC의 최신 Version인 Viable Vision까지  폭넓게 골드랫 박사의 쌍방대화형식의 특유한 강연으로 긴장감 있게 진행되었다.

특히 골드랫박사는 한국의 TOC현주소에 대해 TOC를 받아들인 다른 나라에 비해서 15년 정도 뒤떨어져 있다고 말했다.  그것은 특히 이튿날 전국 경제인 연합회 CEO조찬회에서의 일이었다.



약 150여명의 CEO들이 참석한 조찬회에서 골드랫박사는 다음과 같은 질문을 하였다.

“혹시 더 골을 읽으신 분 손 한번 들어 주세요.”라고 거기서 손을 든 CEO는 고작 4사람 정도였다.

그것을 보고서 참으로 한국에는 TOC가 전파되는 데는 많은 시간이 필요하며 기업들이 어떻게 경쟁력을 갖출 것인가에 대해서 본인이 직접 컨설팅한 GM사의 사례를 통하여 TOC를 설명하였으며, “한국의 CEO들이 정말로 기업을 운영하시는데 현재의 매출액이 4년 후에 순이익과 같게 만들 수 있는가”라는 질문에 모두가 의아해 하는 분위기였다.



뒤이어 CEO들에게 골드랫박사 자신이 만든 Viable Vision에 대해서 한국의 CEO들에게 언급하였다. 짧은 시간에 모든 것을 말 할 수 없음을 아쉬워하며 한국의 CEO들과 아쉬움을 뒤로 하 후 다시 이틀째 일정을 위해 호텔로 돌아 왔다. 오는 도중에 차 안에서 한국의 TOC 수준에 대해서 15년이나 뒤졌다는 이야기를 다시 한번 확인하는 계기가 되었다고 한국의 CEO들로부터 그렇게 인상을 받았다고 했다. 하루라도 빨리 TOC를 받아들여야 세계기업들과의 경쟁에서 살아 남을 수 있다는 말을 하면서 이틀 일정을 시작하였다.  

TOC란?



제약이론으로 알려진 Theory of Constraints의 두음문자 표현이 TOC입니다. TOC는 약 25년전 이스라엘의 물리학자 Eliyahu M. Goldratt 박사가 창안한 공장의 생산개선기법에 그 유래를 두고 있지만, 그 영역을 점차 확대해 현재는 조직의 경영전반을 다루는 경영철학으로 확고하게 인정되고 있습니다.  

TOC는 그 보급을 위해 Goldratt 박사가 1987년 설립한 Avraham Y. Goldratt Institute (AGI)를 중심으로 전세계적인 네트웍을 형성하고 있는데, 유독 일본과 우리 나라는 90년대 후반이 되도록 TOC에 대한 개념조차 제대로 소개되어 있지 않은 상황이었습니다.

그러던 중, 1999년 말경에 "제약경영 (정남기 저)"이란 제목의 TOC 전반에 대한 소개서가 발간된 것은 여간 다행스런 일이 아닙니다.  

TOC가 지향하는 바는 우선 영리기업을 필두로, 비영리단체, 공공기관, 군대, 학교 그리고 개인에 이르기까지 광범위합니다.  

TOC 적용의 목표는 적용 대상의 업무성과 개선입니다. 대상의 성격에 따라 목표는 다르겠으나. 영리기업으로 국한해 본다면, 돈을 버는 것이 목표이며 돈을 벌기 위해 기업의 기능과 직원들은 업무성과를 지속적으로 개선해 가야 합니다. 문제는 어떤 방법이냐 입니다. 이미 수많은 경영 기법들이 소개되어 실행되고 있지만, 단발성의 국지적인 효과에 그치고 마는 경우, 너무 복잡해서 실행이 사실 상 불가능한 경우 또 노력이 너무 많이 들어 투자효과가 미약한 경우가 너무나 많았습니다. 지금 업무에 적용되고 있는 경영 기법들이라 하더라도, 조직 전체의 관점이 결여되고 부분적인 단기 개선에 그치는 것이 대부분입니다.  

이에 비해 TOC는 조직의 전체최적화의 관점에서 고객만족을 최우선으로 하여 지속적인 개선을 도모하는 지극히 상식적인 경영 철학입니다.  

적용분야별로 사용되는 도구를 살펴보면,  

1) 회사전반에 걸쳐 업무성과를 저해하는 핵심문제를 찾아내서 현상타개적인 해결방안을 마련해 실행에 옮기는 思考 프로세스(Thinking Process),  
2) 생산의 최적화를 위한 DBR(Drum-Buffer-Rope),  
3) 프로젝트 소요일정의 획기적 단축을 위한 크리티컬 체인(Critical Chain),  
4) 현금흐름을 중시하는 관리회계인 Throughput 회계 로 나누어 볼 수 있습니다.


왜 TOC인가?

TOC를 도입한 기업들이 업무성과에서 큰 개선을 이루었다는 보고는 많이 있습니다. 그중 하나를 소개합니다.  

1998년 제 33 차 뉴질랜드 Operation Research 학회 연차 학술대회에 빅토리아 대학 경영학과 교수, Steve J. Balderstone과 Victoria J. Mabin이 보고한 논문 "A Review of Goldratt's Theory of Constraints(TOC) - Lessons from the international literature"에 전세계 82개 제조업에 대한 TOC 적용 사례에 대해 분석한 내용을 요약하면, 다음과 같습니다.  
리드 타임: 평균 69% 단축  
납기 준수율: 60% 개선
재고수준: 50% 감소  
업무처리 소요시간: 66% 단축  
매출/Throughput: 68% 증가  

'90년대 후반이 되면서, 미국이 IT산업에서는 물론, 제조업에서도 세계시장에서 막강한 경쟁력을 발휘하자, 그 배후에 무엇이 있는지, 일본이 찾아낸 것이 바로 TOC입니다.  

위 논문의 TOC 성공사례가 미국을 중심으로 서구권에 집중되어 있다는 사실은, '80년대 이후 TQM, JIT를 필두로 생산기술, 공장운영에 관한 한 세계 제일이라고 자부하며 안주하던 일본 제조업들을 반성과 함께 큰 위기감에 빠지게 하였습니다.

TOC가 일본에 본격적으로 알려지기 시작한 것은 고작 4년 전의 일이지만, 지금 Fujitsu, Hitachi, NEC, Sony 등 대기업을 중심으로, 우선 생산의 개선을 위해 그 적용을 서두르고 있습니다.  

우리 기업들도, 무엇보다도 e-Business 시대의 세계시장에서 경쟁력을 강화하고, 이익을 극대화하기 위해 더 늦지 않게 TOC를 도입해야 합니다.

이제 우리도 서둘러 TOC를 도입할 때입니다.

내용출처: http://www.gmsco.co.kr에서 복사해 왔습니다

현재까지 나온 Lomboz 는.. eclipse RC1을 지원하는 버젼은 없으나..
여기의
http://www.okjsp.pe.kr/bbs?act=VIEW&bbs=TOOL&seq=45335
버젼을 사용하면 이용이 가능하다.

단, JBoss3.2.4 버젼부터는 두가지 파일..
jboss-boot.jar 와 javax.servlet.jar 파일이 통합되고하여
설정상에 변화를 가져온듯하다.

그래서.. 결론...

현재까지 나온 Lomboz를 이용한 JBoss 사용에는.. 3.2.4 은 제대로 동작을
하지 않는다..
현재까지의 나온 것으로는... 3.2.3까지는 가능하다..

UBL의 1.0 draft가 공개 되었네요.
곧 정식 릴리즈와 2.0으로의 행보가 빠르게 진행될꺼 같습니다.

현재로서는 CCTS를 기반으로 하여 그 윗단을 정의하는 방식으로
되어지는거 같은데.. ebXML과의 연계 및 관련 행보가 사뭇 궁금해집니다. ^^

좀 더 자세한 것은 더 공부해서 올리도록하고.. 오늘은 간단히 UBL 사이트만
링크하고 사라집니다.

http://www.oasis-open.org/committees/ubl/

Java and .NET Interoperability 문제점 및 한계 :
- 전체적인 아키텍쳐가 방대해짐.
- WAS와 MS제품군 모두가 포함되어 비용적으로 커질 수 있슴.
- 사용 Interoperability 이용시 추가 비용 또 발생.
- 교환 메시지에 따른 추가 개발등에 따른 추가 시간 요소 발생
- 프리젠테이션 레이어를 .NET으로 하는 것도 큰 의미가 없슴.
  (프리젠테이션 레이어만을 위한 OS 및 서버 필요하게 됨.)

결론 :
- 프로젝트 규모가 큰 경우에 적용
- 기업내 통합 솔루션에 활용 가치 높음
- 전체 프로젝트 시간 관리 중요함
- 비지니스 협업 모델에 활용하기에는 기술적인 요소만으로는 부족함.

Updating VICS CPFR®: Frequently Asked Questions
May 2004

Why update the VICS CPFR model?

When the VICS CPFR Guidelines were initially published in 1998, they offered a best practices framework for future collaboration efforts. Since then, there have been over 300 actual pilot and production implementations of CPFR involving over 1500 companies. The new model addresses many shortcomings and incorporates innovations based upon real project experiences.

The VICS CPFR Committee also sought to address two contrasting goals in this update: to make CPFR simpler and more understandable to business executives, while providing more detailed guidance to implementers than before.

What has changed in the new model?

Collaboration Participants: The consumer has been placed at the center of the model, rather than off to one side, so the ultimate focus of collaborative efforts is clear.

Collaboration Activities: CPFR has been transformed from a linear process to an iterative cycle of four activities: Strategy & Planning, Demand & Supply Management, Execution and Analysis. These Collaboration Activities rebalance the original model, maintaining the emphasis on planning and forecasting, while increasing the emphasis on execution and analysis. While activities are presented in a logical order, they are not numbered, and no predetermined sequence is implied.

Collaboration Tasks: Eight Collaboration Tasks replace the “9-steps” of the original CPFR model. Steps 4, 5, 7 and 8 have been consolidated into a single “Exception Management” task, making room for new Order Fulfillment and Performance Assessment tasks.
CPFR Scenarios: Predefined CPFR scenarios are provided for different trading relationships:

Retail Event Collaboration, for highly promoted channels or categories
DC Replenishment Collaboration, for goods that are replenished through customer distribution centers
Store-level Collaboration, for direct store delivery or retail DC-to-store distribution
Collaborative Assortment Planning, for apparel and seasonal goods
If the CPFR model’s changing, why not change the CPFR name?

CPFR is recognized as a best practice worldwide. While the model has been refined, the basic elements of the process remain the same. CPFR practitioners who have reviewed the updated model see it as a more accurate expression of the work that they’ve already been doing.

How do these changes apply to my business?

The updated model should help CPFR program managers gain executive support by offering a clearer, high-level picture of the process, linked to familiar enterprise business processes. The CPFR scenarios have also made CPFR more flexible and adaptable to different industries, geographies and distribution methods. European retailers, apparel manufacturers and direct store delivery categories are all addressed in the scenarios that have been developed.

Where can I learn more?
A good introduction to CPFR is the CPFR Overview, a 17-page summary of the guidelines. This document is available on the CPFR website (www.cpfr.org).

More detailed information can be found in business process guides published for each CPFR scenario. As of May 2004, only the Retail Event Collaboration business process guide has been published. (It is available on the CPFR website as well.) Additional documentation, including project implementation guides, case studies and ROI assessment tools, is in development.

Retailers, manufacturers, solution providers and consultants are encouraged to attend quarterly VICS CPFR where practitioners share best practices and the industry guidelines are developed.

좀지난 자료이긴하지만... 한국경제 2001-09-17 15:42]
=====================================

CPFR (Collaborative Planning Forecasting and Replenishment System)은 수요예측이나 판매계획 정보를 소매업과 메이커가 공유하는 비즈니스 모델이다.
이를 통해 수요예측이나 상품보충 등의 분야에 상호 협력시스템을 구축해 제조물류 소매업간의 "공급 체인 매니지먼트(SCM)"를 행하는 것이다.

이 시스템은 의류 등의 생산유통 전과정에서 자원과 시간의 낭비를 최대한 배제한다.

미국에선 제조 판매간의 동맹전략인 QR(Quick Response)의 표준화를 위해 설립된 "자주적인 민간 사업간 통신규격 위원회"인 VICS (Voluntary InterindustryCommerce Standard Association)가 중심이 돼있다.

미국 "통일 코드 위원회"인 UCC(Uniform Code Council)도 이 프로젝트를 지원하고 있다.

그리고 이것은 지난 93년부터 의류잡화 부문의 QR과 식품부문의 ECR(EfficientConsumer Response) 등과 같은 제조판매의 협동화를 더욱 확대 발전시킨 제도라 할 수 있다.

<> 미국의 CPFR 파일롯 프로젝트 =CPFR을 시행하면 <>매출증가 <>이익증대 <>판매예측 <>발주예측 <>업무효율화 <>발주와 배송의 정확도 향상 <>고객서비스 향상 <>현금 흐름 및 자산회전율의 개선 등을 기대할 수 있다.

지난 98년 VICS가 중심이 되어 5개의 파일롯트 프로젝트를 추진하였으며 그중 4개의 사례를 소개하고자 한다.

우선 지난 98년부터 99년까지 실시된 베그만(Wegman)과 나비스코(Nabisco)의 사례다.

베그만은 뉴욕 펜실바니아 뉴저지주 등에 58개 점포를 전개하고 있는 소매업체이며 나비스코는 비스켓과 스낵류 등을 생산하는 세계적 메이커다.

이용기술은 VICS의 EDI(전자 데이터 교환)메시지, 엘셀 쉬트(Excel Sheet), 이메일 등 기존의 정보 기술을 사용했다.

땅콩관련 제품 22아이템과 애완동물 상품을 대상으로 실시한 결과 대상 카테고리 제품 판매가 타 소매업에서는 8% 감소했지만 양사의 매출은 13%정도 늘어났다.

이후 양사는 공동화 프로젝트를 더욱 확대하고 있다.

K마트와 킴벌리 클라크(Kimberly-Clark)의 사례도 있다.

K마트는 세계적인 할인 양판점이며 킴벌리 클라크는 전 세계에 지사를 갖고 있는 일용품 메이커이다.

K마트의 경우 2천1백개의 점포의 14곳의 물류센터, 16개의 아이템을 대상으로 실험을 실시했다.

실험 결과 매출이 14% 증가했을 뿐만 아니라 계절판매 예측 향상과 재고수주 개선이라는 이득을 얻었다.

킴벌리 클라크도 하루 판매 예측의 용이성 등으로 상당한 성과를 거뒀다.

세계 최대의 소매업인 월마트(WalMart)와 월마트에 의류를 납품하는 사라 리 어패럴(SARA Lee Apparel)도 성공 케이스로 분류된다.

실험 대상은 부인용 스커트, 바지 등의 23개 아이템이었으며 지난 98년 7월부터실시됐다.

실험 개시 24주간후 양사의 매출은 33% 증가되고 점포 재고는 14%가 줄어들었다.

세계 1백40여개국에 화장품 일용품 식품 건강용품 위생용지 등을 제공하는 종합메이커인 프락터&갬블(Proctor & Gamble)과 다국적 소매업체인 테스코(Tesco)도확실한 효과를 봤다.

소매점의 POS데이터와 연동해 재고량 보충량을 자동으로 계산해 상품을 보충하는 방식인 CRP(Continuous Replenishment Program)을 앞세워 거래선 물류센터의재고를 50% 삭감하는데 성공한 것.

미국외 다른 지역에서도 발주예측 향상과 함께 물류센터 소매점의 재고가 줄어들고 예측의 정확도는 높아졌다.

<> CPFR에 이용되는 정보기술 =해당 정보기술의 7가지 원칙은 <>대상이 되는 두기업간 이용정보의 표준채택 <>시스템 확장성 확보(상품수, 거래기업수, 데이터교환수 등) <>데이터의 비밀유지 <>시스템 관리의 용이성(시스템 관리비용의 증가 억제) <>복구력(하드 소프트의 고장에 대한 신속복구) <>디자인 공개(양사간의 신속한 접속을 위한 신속한 협동관계) <>협동관계 (정보 접근, 실행 프로그램 등의 시스템 정리) 등이다.

미국 이외의 나라들도 CPFR의 도입을 적극 추진하고 있다.

프랑스는 유럽통일상품코드기관인 EAN(European Article Number)과 식품에 대한효율적 소비자 대응시스템 기관인 ECR(Efficient Consumer Response)가 중심이돼 작년 4월부터 파일롯트 프로젝트를 추진하고 있다.

1차 계획에 참여한 업체는 소매업계에서는 까르푸 까시노 등 10개사이며 메이커로는 3M, 헨켈(Henkel), 네슬레(Nestle), 킴벌리 클라크, 크래프트 푸드 서비스(Kraft Food Service), P&G,레버(Lever)등 24개사이다.

또한 영국(네슬레 세인스베리 테스코) 스페인(에로스키 헨켈) 이탈리아 등도 파일롯트 프로젝트를 진행하고 있다.

<> CPFR의 향후 예상 =CPFR도입의 성공여부 관건은 기업간 정보의 공유와 기능분담의 명확화라는 두가지 점이라 생각한다.

정보의 공유는 데이터 베이스의 공유와 변경 데이터를 상대기업으로 순식간에 피드백 시키므로 가능해진다.

물론 정보시스템의 인프라 정비도 필요하다.

그리고 기능 분담은 코스트 분석에 기초해 효율적인 관계를 구축하는 것이며 이경우 역할 분담의 방해가 있어서는 안된다.

우리나라도 현재의 유통시장 규모와 발전 추세로 보아 공급 체인 매니지먼트의가장 효율적 시스템인 CPFR의 도입은 필연적이라 생각한다.

유통선진국이란 유통비용을 최소화 할 수 있는 능력을 뜻하기도 하는바 정부와민간기업의 깊은 관심을 기대해 본다.

CFRP하면.. 생각나는 것이..
www.cpfr.org 나 vics 만이였는데.. 하나 더 있네요..
========================================

Links for more information on CPFR®:
www.cpfr.org
www.vics.org
EAN.UCC XML and Business Message Standards
(http://www.uc-council.org/smp/xml_schemas_and_business_messa.html)

참고 :
CPFR® is a Registered Trademark of Voluntary Interindustry Commerce Standards (VICS)
==========================================
덧붙여 설명하자면...
CPFR에 대한 관련 XML 메시지 표준의 정리는..
EAN.UCC 이쪽에서 정의가 되어지네요.

<html>
<head>
<title>Select의 값을 iframe으로 불러오는것</title>
</head>

<body>
<select onchange="window.open(value,'iframe')">
<option selected>리스트보기</option>
<option>---------------------</option>
<option value="01.htm">1</option>
<option value="02.htm">2</option>
<option value="03.htm">3 </option>
</select><br>
<iframe src="about:blank"  frameborder=1 name=iframe></iframe>
</body>
</html>

에서.. onchange="window.open(value,'iframe')"는 select태그에 효과가 나는 이벤트이며, =의 뒤에있는것은 속성들입니다.
window.open()는 윈도우를 열겠다는것이고, value 는 option태그에 있는 value의 값을 넣겠다는뜻..
그리고 iframe는 iframe의 name의 값입니다.

= FLO 모델 =
네모 : 공정..(추상적인 작업 또는 논리적인 작업)
동그라미 : 리소스
세모 : 원자재/반제품/완제품

Extreme Programming

Customer Team Member – Teams have someone (or a group of people) representing the interests of the customer. They decide what is in the product and what is not in the product.

Planning Game - XP is an iterative development process. In the planning game, the customer and the programmers determine the scope of the next release. Programmers estimating the feature costs. Customers select features and package the development of those features into small iterations (typically 2 weeks). Iterations are combined into meaningful end user releases.

User Story – A User Story represents a feature of the system. The customer writes the story on a note card. Stories are small. The estimate to complete a story is limited to no greater than what one person could complete within a single iteration.

Small Releases – Programmers build the system in small releases defined. An iteration is typically two weeks. A release is a group of iterations that provide valuable features to the users of the system.

Acceptance Testing – The customer writes acceptance tests. The tests demonstrate that the story is complete. The programmers and the customer automate acceptance tests. Programmers run the tests multiple times per day.

Open Workspace – To facilitate communications the team works in an open workspace with all the people and equipment easily accessible.

Test Driven Design – Programmers write software in very small verifiable steps. First, we write a small test. Then we write enough code to satisfy the test. Then another test is written, and so on.

Metaphor – The system metaphor provides an idea or a model for the system. It provides a context for naming things in the software, making the software communicate to the programmers.

Simple Design – The design in XP is kept as simple as possible for the current set of implemented stories. Programmers don’t build frameworks and infrastructure for the features that might be coming.

Refactoring – As programmers add new features to the project, the design may start to get messy. If this continues, the design will deteriorate. Refactoring is the process of keeping the design clean incrementally.

Continuous Integration – Programmers integrate and test the software many times a day. Big code branches and merges are avoided.

Collective Ownership – The team owns the code. Programmer pairs modify any piece of code they need to. Extensive unit tests help protect the team from coding mistakes.

Coding Standards – The code needs to have a common style to facilitate communication between programmers. The team owns the code; the team owns the coding style.

Pair Programming – Two programmers collaborate to solve one problem. Programming is not a spectator sport.

Sustainable Pace –The team needs to stay fresh to effectively produce software. One way to make sure the team makes many mistakes is to have them work a lot of overtime.

출처 : http://www.objectmentor.com/processImprovement/index

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
<HEAD>
<META http-equiv="content-type" content="text/html; charset=euc-kr">
<TITLE> Jasko Sample Script </TITLE>

<!---- [1단계] 아래의 소스코드를 <HEAD>와 </HEAD> 사이에 붙여 넣으세요 ---->

<SCRIPT LANGUAGE="JavaScript1.1">
<!--
function right(e) {
if (navigator.appName == 'Netscape' &&
(e.which == 3 || e.which == 2))
return false;
else if (navigator.appName == 'Microsoft Internet Explorer' &&
(event.button == 2 || event.button == 3)) {
alert("마우스의 오른쪽 버튼은 사용할 수 없습니다");
return false;
}
return true;
}

document.onmousedown=right;
document.onmouseup=right;
if (document.layers) window.captureEvents(Event.MOUSEDOWN);
if (document.layers) window.captureEvents(Event.MOUSEUP);
window.onmousedown=right;
window.onmouseup=right;
// -->
</script>

<!------------------------- 여기까지 ---------------------------------->

</HEAD>

<BODY>

<img src="../img5.jpg"><br><br>
<a href="http://www.jasko.co.kr">자바스크립트 소스</a>

<br><br>

마우스 우측버튼을 클릭 해 보세요


</BODY>
</HTML>

원하는 곳의 소스 훔쳐보기 - 마우스 오른쪽 버튼금지 사이트도 OK


<SCRIPT LANGUAGE="JavaScript">
<!-- Original:  Alfie Pugh (alfiep@lineone.net) -->

<!-- Begin
function viewSource() {
document.getSource.view.value="Please wait!";
setTimeout("document.getSource.view.value='View Source!'",6000);
window.location.href= "view-source:" + document.getSource.url.value;
return false;
}
//  End -->
</script>
</HEAD>

<BODY>

<center>
원하시는 곳의 URL 을 입력한후, 버튼을 클릭하세요
<br>
<br>
<form name=getSource onSubmit="return viewSource();">
<input type=text name=url value="http://">
<br>
<br>
<input type=submit name=view value="소스 훔쳐보기">
</form>
</center>

<body oncontextmenu="return false" onselectstart="return false" ondragstart="return false">

<h1>마우스 오른쪽 버튼, 텍스트 드래그기능 잠그기</h1>

한국형 CRM의 구축 방법론



한국형 CRM의 구축방법론을 논하기 전에 먼저 한국형 CRM의 개념을 다시 살펴본다. 한국형 CRM은 제품화된 패키지도 아니고 솔루션도 아니다. 한국형 CRM이라고 해서 외국 CRM 패키지나 솔루션, 방법론을 거부하는 것도 아니다. 그동안 우리나라에서 CRM 구현을 해온 결과를 반성하고 우리나라 기업 현실에 맞는 CRM을 구축하자라는 제안이다.

굳이 '한국형'이라는 말을 붙이는 이유는 'CRM은 문화'라는 필자의 견해에서 비롯된 것이다. 외국 CRM에는 채널 통합, 프론트오피스와 백오피스의 통합과 같은 좋은 사상이 있다. 이러한 사상은 받아들이되 우리나라 기업의 변화 무쌍한 고객관리 프로세스를 외국 문화 환경에서 정의한 프로세스에 짜 맞추려는 오류를 범하지 말아야 한다는 생각이다.

ERP는 선진기업의 경영 노하우가 그 내부 프로세스에 녹아있기 때문에 글로벌을 지향하는 우리나라 기업이 기존의 프로세스를 그대로 사용하기보다는 선진 프로세스를 도입할 필요가 있다.

그러나 CRM의 프로세스는 고객과 연결되어 있는 부분이 많기 때문에 고객에게 선진 고객 관리 프로세스를 맞추라고 강요할 수 없다. 기업은 고객이 원하는 프로세스에 맞추어야 하기 때문이다.





한국형 CRM의 출발



1. 데이터와 프로세스

일단 구축 방법론이라는 것을 잊고 가장 기본적인 데이터와 프로세스에 대해서 생각해보자.

·고객 데이터 분석에 근거한 타겟 마켓팅을 하려면 당연히 고객 데이터가 있어야 한다.

·타겟 마켓팅을 효과적으로 하려면 마켓팅 프로세스가 있어야 한다.

여기서 우리는 고객 데이터-->타겟 마켓팅-->프로세스라는 일련의 단계를 생각할 수 있다.

타겟 마켓팅은 고객을 세분화하고 세분화된 고객에 맞는 상품과 서비스를 조합하며 포인트 제공, 디스카운트와 같은 오퍼를 만들어서 그 고객이 선호하는 채널을 선택해서 마켓팅을 하는 것이다. 여기에는 4가지 차원이 있다. 고객군, 상품/서비스, 오퍼, 채널이다. 고객을 세분화하는 것도 어렵지만 최종 결과인 고객의 반응도(response rate)를 최적화하기 위해서 4개의 차원을 서로 조합해야 하기 때문에 타겟 마켓팅은 많은 경험이 필요하다.

불행하게도 대부분의 기업이 CRM을 구축할 때, 이 3 단계가 모두 없다.

① 고객 데이터가 분산되어 있고 데이터 자체도 정비가 안되어 있다.

② 고객 데이터 분석에 의한 고객군을 나누고 이에 따른 타겟 마켓팅을 해본 경험이 없다.

③ 이러한 타겟 마켓팅을 보다 효과적으로 하기 위한 전사적인 프로세스가 없다.

물론 CRM에 대한 경험이 없고 데이터가 정비가 안되었기 때문에 CRM 프로젝트를 추진하는 것이다. 그러나 CRM 프로젝트 성공을 위해서는 프로젝트 추진 순서가 매우 중요하다.

당연한 결론이지만 프로젝트 추진하는 큰 방향은 3가지이다.



2. 바텀업 구축 방식

CRM 프로젝트를 하면서 가장 편하게 제시되는 방식이다.

"고객 데이터를 먼저 정비하고 그 다음 타겟 마켓팅을 해보자. 그리고 프로세스는 나중에 생각하자" 이 방법이 가장 편하게 제시되는 이유는

·일단 고객 데이터를 정비할 필요성은 이미 기업내에 알려진 사실이고 누구나 인식하고 있기 때문이다.

·현업(마켓팅 부서)이 타겟 마켓팅이라는 것을 해보지 않았기 때문이다.

바로 이점이 바텀업(bottom-up) 구축 방식의 문제점으로 부각이 될 수 밖에 없다.

이 방식으로 프로젝트를 진행하면 우선 현업의 요구 사항을 모으기가 어렵다. 현업도 CRM에 대해서 많은 정보가 없으며, 실제 데이터에 의한 타겟 마켓팅을 해본 경험이 없으므로 원하는 요구사항을 내놓기 어렵다.

바텀업 방식은 데이터를 정비하고 통합시키기는 것이 먼저이기 때문에 CRM 패키지 구현보다는 데이터 웨어 하우스를 먼저 구현한다.

여기에 필요 이상 많은 데이터가 들어가게 되거나 구축 후에 필요한 데이터는 없는 경우가 많다. 결국 이러한 방식은 CRM 시스템을 구축하고도 제 마켓팅에 활용되기보다는 조회용으로 사용되기 쉽다. 이러한 상황에서 CRM 프로세스를 정의하는 것은 거의 불가능하다.

바텀업 방식으로 구축한 회사의 고민은 구축된 CRM 시스템을 어떻게 활용할 것인가에 집중되어 있다. CRM의 용도를 찾지 못하고 CRM을 구축하는 것은 참으로 불행한 일이다. 우리나라에서 프로세스적인 CRM의 도입이 늦어지고 있는 이유가 바로 이런 점이다. 타겟 마켓팅을 성공적으로 수행한 경험이 없기 때문이다.



3. 탑다운 구축 방식

"아니다. 그 많은 데이터를 어떻게 정비를 하는가. 먼저 CRM 비전을 도출하고 비지니스 프로세스를 정의하여 타켓 마켓팅의 방향을 설정하고 여기에서 요구되는 데이터 항목들을 뽑아서 이것을 중심으로 데이터 정비를 하자"라는 주장이 있다.

이것은 탑다운(top-down) 방식이며 우리나라에서는 지금부터 도입되기 시작하고 있다.

우리나라의 대부분의 기업에서는 CRM 프로세스라는 것이 없다. 좀 더 정확히 말하자면 세분화된 고객군(customer segmentation)에 근거한 기업 내부의 고객 관리 프로세스가 없다는 것이다. 이런 현실에서 아무리 전략과 프로세스를 디자인한다고 해도 우리나라처럼 변화 무쌍한 고객 관리를 하는데 과연 프로세스를 정한 것이 얼마나 갈까?

이 탑다운 방식은 세부적인 비즈니스 프로세스를 정의하는데 어려움이 있기 때문에 대개 외국 패키지를 도입할 경우가 많다. 실제로 프로젝트를 하면서 'to-be 프로세스'를 정의할 때, 기존 CRM 패키지가 갖고 있는 기능과 프로세스를 조금 변형시키거나 심지어 그대로 복사하는 경우가 있다. 이것은 올바른 컨설팅 방법이 아니다.

물론 탑다운 방식이 잘못되었다거나 나쁘다는 것이 아니다. CRM분야에서 가장 앞서 나가는 기업이라면 어느 정도 기업내의 고객 관리 프로세스도 존재한다. 이미 존재하는 마켓팅 프로세스, 고객 데이터 구축 등을 새롭게 정의하고 채널 통합, 온라인·오프라인 통합, PRM과 같은 진일보된 CRM을 구현하기 위해서는 탑다운 방식을 고려할 필요가 있다. 이미 CRM에 대한 경험이 있기 때문이다.

결론적으로 CRM에 대한 경험이 부족한 회사는 탑다운 방식은 피하라고 말하고 싶다.



4. 미들업다운 구축 방식

필자가 소개하는 미들업다운(middle-up-down) 전략은 D&I컨설팅사가 LG칼텍스정유의 CRM 프로젝트를 구현하면서 채택한 것이다.

필자는 LG칼텍스정유와 D&I컨설팅사의 미들업단운 전략을 한국적인 상황과 문화를 토대로 하여 분석적 CRM의 장점과 프로세스적인 CRM의 장점을 통합하여 이를 고도화하려고 모색하고 있다.



고객이해와 고객관계



우리나라에서 CRM 추진이 어려운 이유는 고객에 대한 구체적인 이해(customer identification) 없이 CRM 시스템을 구축하려는 데 있다. 현실(fact)에 충실하지 않고, 고객에 대한 이해 없이 세우는 CRM 전략과 시스템 구축은 실 사용자로부터 외면당하고 있다.

따라서 한국형 CRM 구축 방법은 CRM 비전과 전략으로 들어가서 결국은 패키지를 도입하는 top-down 방식이나 데이터 웨어하우스를 먼저 구축하고 데이터 분석으로 들어가는 바텀업 방식보다는 고객이해를 충실히 하고 사실에 근거한 팩트 베이스 마켓팅(fact-based marketing)으로 고객관계(customer relationship)에 접근하는 미들업다운 방식을 채택한다.



고객이해를 폭넓게 하여 타겟 마켓팅을 했을 경우 고객관계에 접근하기 쉬워지고 이로서 고객반응을 수집하여 분석하면 고객에 대한 이해가 깊어진다. CRM은 끊임없이 변화·발전하므로 영속적인 변화 관리를 통해서 고객관계를 폭넓고 깊게 할 수 있다.

CRM 프로젝트는 먼저 고객이해가 선행되어야 하고, 그 경험을 바탕으로 서서히 고객관계을 맺어가는 방향으로 진전되어야 한다.



미들업다운 방식



한국형CRM의 접근 방식은 미들업다운 일수 밖에 없는 이유는 고객사가 전혀 그 고객사의 고객데이터를 분석하여 캠페인을 해본 경험이 없는 우리나라의 현실을 반영한 것이기 때문이다.

프로젝트 초기에는 아주 작게 고객 샘플 데이터를 가지고 기본적인 분석을 거쳐서 실제 고객 세그먼트를 나누고 각 세그먼트에 대해 다양한 캠페인을 해보는 것이다. 샘플의 규모가 크지 않아서 비용도 적게 들고 샘플링을 잘하면 전체 고객의 성향을 그대로 반영할 수 있다. 그래서 각 고객 세그먼트의 다양한 캠페인에 대한 반응을 알아 낼 수 있다.

이것을 하다가 보면 어떤 고객에 어떤 오퍼를 주어야 고객이 움직이는가를 이해 할 수 있다. 휴면고객이 우수고객으로 변화하는 상황을 이해하면 마켓팅에서 다양한 비지니스 관점이 포착이 된다. 이것을 근간으로 해서 데이터의 요구가 도출이 되고 구축해야 할 데이터 웨어하우스의 데이터 항목이 결정되면 사용자 요구가 분명해지고, 앞으로 해야 할 비즈니스 프로세스를 정할 수 있다. 고객 데이터 분석과 타겟 마켓팅을 실제로 해보면서 CRM을 구축하는 방식이다.

실제로 미들업다운 방식이 좋은 이유는 초기 비용을 극소화하면서 전체 프로젝트의 성공여부를 조기에 진단할 수 있다는 점이며 프로젝트 실패에 대한 위험을 최소화시킬 수 있다는 점이다.

어찌 생각하면 서구에서는 80년대 말 90년대 초부터 시작된 DBM을 통해서 많은 고객 데이터를 분석하고 캠페인을 통해서 고객 세그먼트의 움직임을 체득하고 있었고 이를 바탕으로 DW와 CRM을 구축한 것이 바로 미들업다운이라고 할 수 있다.

또 한가지 중요한 점은 테스트 마켓팅의 데이터 분석과 타겟 마켓팅이 전사로 확대되는 과정에서 프로세스를 정의하긴 하지만 근간이 되는 것은 데이터 분석이라는 점이다. 한국형 CRM은 분석적 CRM과 프로세스적CRM을 통합하나 기본적인 골격은 분석적 CRM이라는 입장이다. 분석적 CRM은 고객관리의 인텔리전스이고 프로세스적 CRM은 고객관리를 최적화하는 것이 목적이다. 프로세스적인 CRM은 분석적 CRM의 도움을 받아서 끊임없이 최적화를 지향해야 하기 때문이다.



미들업다운 전략의 세부 내용



다음은 미들업다운 전략의 포괄적인 청사진을 그린 것이다.

중요 포인트는 파일럿 프로젝트 단계와 본 프로젝트 단계를 나누었다는 점이다 . 그러나 실제 프로젝트는 여러 개의 단계로 나누어 수행할 수 있다.



파이럿 프로젝트 단계는 팩트 베이스 마켓팅 전략을 수립하고 실제 테스트 마켓팅을 수행하여 그 결과를 토대로 본 프로젝트의 윗 단계인 CRM 전략을 수립하고 아래 단계인 IT 전략을 수립한다. 그리고 팩트 베이스 마켓팅을 전사적으로 확대할 수 있는 전사 확대 전략을 수립한다.

팩트 베이스 마켓팅은 환경 분석, 정보 분석, 테스트 마켓팅으로 나누며 구체적으로

·환경분석에서는 고객에 대한 이해를 위해 고객정보의 파악, 고객 가치 산정, 고객 특성 지표 개발, 고객세분화, 고객점수화 등을 한다.

·정보 분석에서는 주로 고객분석, 상품/서비스 분석, 채널분석을 중심으로 하며 그 결과를 활용할 방안을 도출한다.

·테스트 마켓팅에서는 캠페인의 목적에 따른 종류, 대상과 규모를 결정하고 최적의 오퍼와 채널을 믹스하여 타rpt 마켓팅을 수행한다.

팩트 베이스 마케팅의 결과는 이를 전사적으로 확대할 방향을 제시하는 데 사용된다.



한국형 CRM 전략



미들업다운 구축 방법론 중에서 윗 부분인 CRM 전략을 중점적으로 논의하고자 한다. 다음 호에서는 IT전략과 아키텍처 및 컴포넌트를 언급하도록 하겠다.



고객관점의 CRM 비전 수립



CRM은 IT개념이 아니라 비지니스이며 기업 경영철학이다.

CRM의 목적은 고객 만족과 이로부터 오는 매출 증가이다. CRM은 고객의 니즈를 파악하여, 고객이 원하는 제품/서비스를, 고객이 원하는 방법과 채널로, 고객이 원할 때 제공해 주기 위한 것이다. CRM은 이를 위한 위한 기업의 전략, 프로세스, 조직, 시스템, 변화 관리 전체를 말한다.

CRM은 공급 과잉 시대의 기업 생존의 도구이다.

기술의 혁신, 인터넷의 등장으로 좋은 질, 싼 가격, 광범위한 유통망 등으로 승부하는 시대는 지나가고 있다. 오직 차별화할 수 있는 수단은 서비스의 차별화이다.



현대의 가치사슬(value chain)



과거의 가치사슬



과거 기업내 가치사슬(Value chain)은 프로세스 통합, 스피드, 경비 절감에 목적을 두고 있으며 표준화된 제품을 값싸고 질 좋게 만들어 신속하게 고객에 판매하였다.



현대의 가치사슬



현대와 미래의 가치사슬은 고객이 주도하고 결정한다. 고객이 원하는 제품/서비스를 고객이 원하는 시간에 고객이 원하는 가격과 질로, 고객이 원하는 방법으로 제공해야 한다. 이것이 바로 CRM이다.



타사업 진출 가능성



한 기업이 고객관계가 좋으면, 다시 말해서 CRM이 제대로 구축되어 있고 잘 활용되어 있으며 타 기업과 전략적 제휴를 통해서 고객에게 무엇이든 팔 수 있다. 타 사업에 진출 가능하다.



고객에 대한 단일한 관점(single view)

현재 고객 데이터는 상품별, 부서별로 분산되어 있다. 이것은 필연적으로 부서별로 고객에 대한 이해가 다를 수밖에 없다. 이것은 CRM하는데 결정적인 걸림돌이 된다. 따라서, 고객에 대한 단일한 관점을 유지하려면, 분산되어 있는 고객 데이터를 고객별로 통합하는 것이 필연적이다. 이것은 결국 채널 통합을 위한 기초가 될 것이다.



고객 관계 전략

우리나라에서 고객과 관계를 맺고 이를 유지하는 일은 오래 전부터 해온 일이다. 그러나 우리나라 기업에서는 특정 부서, 특정 영업사원을 중심으로 고객과 관계를 맺어 왔으며 이를 전사적으로 공유하는 일은 해오지 않았다. 그러나, 지금까지의 CRM 추진은 전사적 데이터를 중심으로 전사적인 고객관계를 유지하는 전사적 관점에서 추진되어 왔다.

그러나, 때에 따라서는 데이터 웨어하우스에 있는 수 테라바이트의 고객데이터 보다 특정 영업사원이 갖고 있는 고객관계 정보가 더욱 가치 있을 때가 있다.

한국형 CRM은 이 두 가지를 모두 추진한다. 부서별로, 영업사원별로 고객과 관계는 계속 유지하도록 도와주며 전사적인 CRM 추진은 채널 통합과 CRM-eCRM 통합 등 다양한 통합을 지향한다.

다시 말해서, 분산과 통합을 동시에 추진한다. 이를 어떻게 구현할 것인가는 IT 전략에서 다루는 부분이고 IT 통합 기술의 발전으로 분산과 통합을 동시에 추진할 수 있다.

통합의 관점에서 보면 다음과 같은 통합을 들 수 있다.

·채널통합 전략



채널 통합은 서구 CRM 패키지의 기본 사상이다. 한국형 CRM은 이러한 사상을 받아들여 내부적으로 고객관계를 증진시키는 핵심 전략으로 사용한다.

프론트 오피스에 해당하는 판매, 마케팅, 서비스를 가상적으로 일원화할 수 있다. 즉, 고객이 기업내 어떤 조직과 연결해도 고객에 대한 통합 정보를 바탕으로 고객이 원하는 것을 즉시 제공할 수 있다.

부서별로 시너지 효과를 창출할 수 있다. 서비스 조직에서 상품 판매(telesales)도 가능하며 지역 판매조직에서 지역별 마케팅도 가능하며 이는 중앙 마케팅 부서와 바로 연계할 수 있다.

인터넷에서 상품판매, 마케팅, 서비스 등 다양하게 활용하여 일대일 맞춤 서비스를 가능하게 한다.

마케팅 부서에서 고객정보를 파악하여 고객에 대한 상품과 서비스를 믹스하여 판매부서, 서비스조직, 인터넷 조직에 실시간으로 제공함으로서 고객의 니즈에 기반한 판매와 서비스를 제공할 수 있다.

채널이 통합되어 있어 각 채널별 마케팅 캠페인의 수행 결과를 바로 수집하여 다음 캠페인에 수렴할 수 있으며 각 채널별, 상품별, 고객별 캠페인의 결과를 분석할 수 있다.



이러한 채널 통합의 결과로 고객관계를 폭넓고 고객의 로열티를 높임으로서 타 사업 진출의 토대가 된다..





·CRM과 eCRM의 통합 전략



한국형 CRM은 인터넷을 적극적으로 활용한다. 초기에 인터넷을 활용한 eCRM은 기존 CRM을 오프라인 CRM과 차별하면서 독자적인 영역을 추구해 왔으나 채널충돌(channel conflict)을 피할 수 없었다. 서구에서 자동차 판매, 도서 판매, 보험 판매는 기존 채널의 판매 조직과 인터넷 판매가 정면 승부를 할 수 밖에 없었다. 그러나, 한국형 CRM은 CRM과 eCRM을



쩝... 짤렸네..끝부분이..



장동인

D&I 컨설팅 공동사장

어떤 웹프로그램이나 입력을 받는 필드가 있습니다.

이게시판에서도 이름과 패스워드 이메일 홈페이지 그래고 내용을 입력 받는데

많은 분들이 Tab키를 이용해 다른 입력 폼으로 이동을 합니다.

이때 탭키로 이동의 순서를 지정할 수 있는 Tip을 말씀해 드리겠습니다. 아래의 내역을 메모장등에 복사하셔서 테스트 해보시기 바랍니다.
<input type=text tabindex=1 name=1>

<input type=text tabindex=4 name=2>

<input type=text tabindex=3 name=3>

<input type=text tabindex=2 name=4>


이동을 시작하고 싶은 부분에서 다음에 이동을 하고자 하는 부분까지 Tabindex=1, Tabindex=2 .....
써주시면 간단하게 해결되는 HTML 태그입니다. 필요하신분들 모두 유용하게 사용하시길 바랍니다.

위의 Tab key를 눌렀을때 이동 순서 name1 -> name4 -> name3 -> name2 이렇게 되겠죠 ^0^

출처 : http://www.4offline.org/bbs/view.php?id=Tip&page=2&page_num=20&category=&sn=off&ss=off&sc=off&keyword=&select_arrange=headnum&desc=asc&no=13

struts의 ApplicationResource를 사용함에 있어서.. 문제가 좀 되기는하지만,
일단 기본 환경설정상으로의 한글처리 방법을 적어봅니다.

1. velocity.properties 파일에.. 아래 내용 추가
input.encoding = EUC-KR
output.encoding = EUC-KR

2. tomcat의 server.xml 에서 connect  부분에.. URIEncoding 추가
<Connector port="8080"
               maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
               enableLookups="false" redirectPort="8443" acceptCount="100"
               debug="0" connectionTimeout="20000"
               disableUploadTimeout="true"  URIEncoding="EUC-KR" />

=========================================
1만 했으시에는 화면상의 한글은 잘되는데 파라메터 처리에서 한글 깨짐

- ebXML : Electronic Business using eXtensible Markup Language
- BPSS : Business Process Specification Schema
- CPP : Collaboration Protocol Profile
- CPPA : Collaboration Protocol Profile and Agreement
- CC : Core Component
- TA : Technical Architecture
- RIM : Registry Information Model
- RS : Registry Services
- MS : Message Service
- Reg/Rep : Registry/Repository
- REQ : Requirements
- GROSS : Glossary
- CCSD : Core Component Supplemental Documents
- IIC : Implementation, Interoperability and Conformance

www.ebxml.org 사이트정리

1. 메뉴구성
        상단 메뉴 :
                - 메뉴 구성 : About/Industry Support/News/SPECS/REPORTS/REFERENCE/WHITE PAPERS/WORKING GRUOPS
                - 메뉴 분석 :
                        1. About/Industry Support/News 메뉴는 좌측메뉴의 About/Industry Support/News and Articles과 동일
                        2. SPECS/REPORTS/REFERENCE/WHITE PAPERS 메뉴는 http://www.ebxml.org/specs/index.htm 페이지내에 링크
                           좌측의 SPECS/DOCUMENTS 대분류 내용과 동일
                        3. WORKING GRUOPS 메뉴는 좌측의 메뉴의 TECHNICAL COMMITTEES의 Overview 메뉴와 동일
                - 분석 결과 : 상단메뉴의 모든 내용은 좌측 메뉴의 일부분임.
        좌측 메뉴 :
                - 메뉴 구성 :
                        1. 대분류 : ebXML / 'SPECS/DOCUMENTS' / TECHNICAL COMMITTEES / ebXML-DEV LIST
                        2. 소분류 :
                                ebXML (대분류) :
                                        - About : ebXML의 간단한 소개와 가치, FAQ, Contacts
                                        - Industry Support : 표준단체, 산업체그룹, 벤더와 사용자들에 대한 정보
                                        - News and Articles : Article, 릴리즈소식, OASIS 뉴스레터, Contacts
                                        - Tools : ebXML Tool들의 공급업체 (범위: 대형소프트웨어 벤더에서부터 신생 솔루션 벤더까지)
                                                          (OASIS Member Products / Open Source Tools / Other Products 로 구분)
                                        - Implementations : ebXML 구현체(Application) 리스트
                                        - Case Studies : ebXML 성공 이야기(구현사례)
                                        - Certification : 사용자의 ebXML 인증정보의 공유 또는 프로그램 테스트 위한 안내
                                        - Logo : ebXML로고의 사용정보
                                        - Presentations : 프리젠테이션 자료
                                        - Events : 행사 및 모임 안내
                                        - Resources : ebXML 관련 정보들
                                                                  (관련 사이트, 책, 교육, 레포트, 문서, XML정보)
                                        - Acronyms : ebXML의 약칭(두문자어)과 간단한 설명
                                        - Marketing : ebXML기반 솔루션의 사업촉진, 대화, 성공을 위한 계획(공포/관련문서)
                                        - Initiative Archive : 최초 시작시의 정보들
                                          ( Original Project Teams / Mail List Archives / F2F Meeting / Documents / Overview )
                                SPECS/DOCUMENTS (대분류) :
                                        - Specifications : Technical Specifications(TA,BPSS,RIM,RS,REQ,CPP,CPA,MS)
                                        - Technical Reports : bpOVER,bpWS,bpPATT,bpPROC,ccOVER,ebCCD&A,ebCNTXT,ccCTLG,
                                                                                  ebCCNAM,ebCCDOC,ccDRIV,ccSTRUCT,secRISK
                                        - Reference Materials : ebGLOSS
                                        - White Papers : bpTAREV, bpTAREV, rrUDDI, secREG
                                        - Translations : 문서 번역 링크 (프랑스어)
                                TECHNICAL COMMITTEES (대분류)
                                        - Overview : ebXML의 위원회 활동 (기술적 업무활동 : UN/CEFACT and OASIS)
                                                OASIS : ebXMLMessaging Services, Registries and Repositories, Collaborative Protocol Profile
                                                                and Implementation, Interoperability and Conformance
                                                UN/CEFACT : Core Components and Business Process Models                
                                        - Business Process : OASIS ebXML Business Process TC
                                        - Core Components : UN/CEFACT Techniques and Methodologies Group (TMG)
                                        - Collaboration Protocol : OASIS ebXML Collaboration Protocol Profile and Agreement TC
                                        - Messaging : OASIS ebXML Messaging Services TC
                                        - Registry / Repository : OASIS ebXML Registry TC
                                        - Implementation : OASIS ebXML Implementation, Interoperability and Conformance TC
                                ebXML-DEV LIST (대분류)
                                        - Subscribe : 메일링 리스트 등록
                                        - Archives : 메일링 보관소
                - 메뉴 분석 :
                        1. 대분류 ebXML/'SPECS/DOCUMENTS'는 www.ebxml.org 내에서 구성
                        2. 대분류 TECHNICAL COMMITTEES 는 www.oasis-open.org와 www.untmg.org 에서 구성
                        3. 대분류 ebXML-DEV LIST 는 메일링 기능
                - 분석 결과 : 특이사항 없음.

1. IDES 가 교육용 SAP SERVER PROGRAM 맞나요?

2. 맞다면, 설치후 사용 만료 기간은 어떻게 되나요?

3. IDES 페키지가 6장 인데, 6장만 있으면 되는건지, 아니면 몇장 인가요?

===========================================

1. IDES는 SAP 교육용 프로그램 맞습니다.

2. SAP에 관련된 모든 사용권한은 두가지 입니다. 인스톨 시 Installation No.를 신청할 때 Permanent 또는 temporary 이 두가지 중에 어느 것으로 신청하느냐에 따라 만료하는 기간은 다릅니다. 그런데 대체로 Temporary로 신청해서 필요할 즈음에 다시 받는 그런 방식을 선택하고 있습니다.

3. 6장만 있으면 된다는 아니다.. 라고 말씀 드리고 싶네요. IDES CD를 신청하면 우선적으로 Package되어 들어오는 Box 안에는 약 15개 전후의 CD가 들어 있습니다. 물론 인스톨 시에 모두 사용하는 것은 아니지만요... 그 중 인스톨하는데 꼭 필요한 CD는 아래 적어드리겠습니다.
- ORACLE CD 1장(즉 DBMS CD 1장) , Kernel Oracle 1장 , IDES DB Export CD 6장
상기 CD 이외에 Install 관련 Document를 기록한 CD가 있습니다. 그 CD 안에 Install Guide를 순서적으로 천천히 읽어보시면 필요한 CD가 무엇인지 그때그때 찾으실 수 있으실 겁니다. 인스톨하시면서 읽으시면 찾는 정도가 좀 느리실 겁니다. 우선 읽어보시고 인스톨 시에 체크한 부분만 휙휙... 넘어가세요~~~

① FI : Financial management 재무회계
② CO : controlling 관리회계
③ AM : sset Managemen, 자산관리
④ PS : project system 프로젝트 관리
⑤ OC or WF : Office Communication or Work Flow 사무자동화
⑥ IS : Industry Solutions 업종별 솔루션
⑦ SD : sales and distribution 판매관리
⑧ MM : material management 자재 및 구매관리
⑨ PP : production planning and control 생산관리
⑩ QM : quality management 품질관리
⑪ PM : plant management 설비관리
⑫ HR : human resource 인사관리
기타
TR : treasury 자금관리
IM : invest management 투자관리

상세 참조..
http://mkseong.uniadnet.com/sapintro.htm

도움이 : 자이오넥스 김백면선임.. ^^ 땡스..

사이트의 Velocity Tools을 처음 접하시는 분은
Generic Tools / VelocityView Tools / VelocityStruts
3개의 큰 카테고리(!)와 그 안에 세분화 된 Tool이 있다는 것을
어렵게 이해할 수 있답니다.
한눈으로 파악하기 좋게 옮겨봤습니다.


================================================
Generic Tools
--------------------------------------------------------------------------------------
DateTool :
A tool for manipulating and formatting dates.

MathTool :
A tool for performing floating point math.

NumberTool :
A tool for formatting numbers.

IteratorTool :
A convenience tool to use with #foreach loops. It wraps a list to let the designer specify a condition to terminate the loop, and reuse the same list in different loops.

RenderTool :
A tool to evaluate and render arbitrary strings of VTL (Velocity Template Language).

==================================================
VelocityView Tools
--------------------------------------------------------------------------------------
AbstractSearchTool :
Abstract view tool for doing "searching" and robust pagination of search results.

CookieTool :
View tool for convenient cookie access and creation.

LinkTool :
The LinkTool provides methods to work with URIs:

ParameterParser :
View tool for easy parsing of ServletRequest parameters.

ViewRenderTool :
This tool expose methods to evaluate the given strings as VTL (Velocity Template Language) and automatically using the current context

==================================================
VelocityStruts
--------------------------------------------------------------------------------------
ActionMessagesTool :
View tool to work with the Struts action messages.

ErrorsTool :
This tool deals with Struts error messages.

FormTool :
Struts has support to parse incoming HTTP requests and populate a Java bean with the submitted request

MessageTool :
The MessageTool is used to render internationalized message strings.

SecureLinkTool :
Tool to be able to use Struts SSL Extensions with Velocity

StrutsLinkTool :
The StrutsLinkTool extends the standard LinkTool to add methods for working with Struts' Actions and Forwards

TilesTool :
View tool to use struts-tiles with Velocity

ValidatorTool :
View tool that works with Struts Validator to produce client side javascript validation for your forms.

=============================================

Actually, I have just realized there is no need for copy-pasting since
JSP 2, because it has a new feature, preludes and codas, which are
statically included JSP segments.

In the web.xml you have something like:

  <jsp-config>
    <jsp-property-group>
      <url-pattern>*.jsp</url-pattern>
      <include-prelude>/myprelude.jspf</include-prelude>
    </jsp-property-group>
  </jsp-config>

And then you put this into /myprelude.jspf:

<%@ taglib prefix="c" uri="http://java.sun.com/jstl/core"; %>
<%@ taglib prefix="my" tagdir="/WEB-INF/tags" %>

This will be apparently inserted at the beginning of all JSP pages, so
you can use the "my" and "c" prefixes in the JSP pages without using
"taglib" directives in the JSP page itself.

tools such as Ant or Maven are the foundation for continuous integration. You can build on that foundation by using a dedicated continuous integration tool like CruiseControl, Gump or AntHill.

ant
http://ant.apache.org

maven
http://maven.apache.org

CruiseControl
http://cruisecontrol.sourceforge.net/

Gump
http://jakarta.apache.org/gump/

AntHill
http://www.urbancode.com/projects/anthill/

== client side ==

junit.jar: obviously this is needed for the JUnit Test Runner and because the Cactus XXXTestCase classes extend the JUnit org.junit.framework.TestCase class.

cactus.jar: well, this is the Cactus jar containing all Cactus classes,

your test classes: these are your test classes that extend the Cactus XXXTestCase classes,

servlet.jar or j2ee.jar: these are the Servlet API / J2EE API interfaces. This is needed on the client side classpath because your test cases extend one or several of XXXTestCase which use class variables that are Servlet / J2EE objects (HttpSevletRequest, PageContext, ...). You can get this jar either from your servlet engine or from the Sun Web Site

httpclient.jar: needed for Cactus Cookie handling.

commons-logging.jar: Cactus uses the Jakarta Commons Logging facade framework to provide seamless Cactus logging using any existing Logging framework (Log4j, LogKit, JDK 1.4 Logging, etc). It is also needed for Commons HttpClient.

logging framework jar(optional): The logging framework to use (Log4j jar, LogKit jar, etc). It is optional as it is only needed for internal Cactus logging and in addition, the Commons Logging framework provides a simple logger that logs on the console.

httpunit.jar, Tidy.jar and xerces.jar (optional): only needed if you wish to use HttpUnit in your endXXX() methods (see the HttpUnit Howto tutorial). The 3 jars mentioned above are part of the HttpUnit distribution.

aspectjrt.jar: AspectJ runtime jar.


If you have the habit of using class variables for the classes to test (as opposed to declaring them within the testXXX() method), you'll also need to put your classes under test in the client side classpath.

If you are using Log4J as the logging framework, you will also need to put a log4j.properties Log4j configuration file in your client side classpath (See the Config Howto tutorial).



---------------------------------------------------------------------

== server side ==

WEB-INF/lib/cactus.jar: the Cactus main jar,

WEB-INF/lib/junit.jar: this is needed because the Cactus XXXTestCase extends the JUnit org.junit.framework.TestCase class.

WEB-INF/classes/ : obviously as their testXXX() methods will get executed in the container.

WEB-INF/classes/ : will be called by your test classes.

aspectjrt.jar: AspectJ runtime jar.

WEB-INF/lib/commons-logging.jar: Cactus uses the Jakarta Commons Logging facade framework to provide seamless Cactus logging using any existing Logging framework (Log4j, LogKit, JDK 1.4 Logging, etc). It is also needed for Commons HttpClient.

WEB-INF/lib/logging framework jar (optional): The logging framework to use (Log4j jar, LogKit jar, etc). It is optional as it is only needed for internal Cactus logging and in addition, the Commons Logging framework provides a simple logger that logs on the console.


If you have several webapps that use cactus you can put all Cactus jars in a place loaded by your container System classloader (provided your container correctly sets the Context classloader). The location is container-dependent; for example for Tomcat 4.x, you can put the jars in TOMCAT_HOME/common/lib.

If you are using Log4J as the logging framework, you will also need to put a log4j.properties Log4j configuration file in your server side classpath (usually in WEB-INF/classes).
-------------------------------------------------------------------------

# 이상적인 모양
- Mock Object : 도메인 로직 검사
- Cactus : 통합 테스팅
- HttpUnit : 기능 테스트
- JXUnit : Building Suites of Test Data with XML
- DBUnit : dataset

1. Mock Object
http://www.mockobjects.com

2. Cactus
http://jakarta.apache.org/cactus

3. HttpUnit
http://httpunit.sourceforge.net

4. JXUnit
http://jxunit.sourceforge.net/

5. DBUnit
http://dbunit.sourceforge.net/

Struts Applications

The Struts/SourceForge site hosts sample applications and related components based on the Apache Struts Web application framework.

http://struts.sourceforge.net/

==============================================