CBO는 어디까지가 좋을까?

맨날 듣는다. CBO를 지양하고 최대한 스탠다드를 추구하라고.
내가 직접 말하기도 한다. "와 저거 완전 CBO를 덕지덕지 붙여놨네. 저러면 안 돼요",라고

하지만 이게 다 아 다르고 어 다른 말이라고 생각한다. CBO도 CBO 나름이고, 스탠다드도 스탠다드 나름이다. 아마 이런 말이 나왔던 것은 과거에 스탠다드를 제대로 이해하지 못한 채 엉뚱한 프로세스로 개발된 CBO가 많았기 때문이라고 본다.

1. 무지성 CBO

그러니까,

1. 스탠다드에 이미 있는 프로세스를 CBO화

2. 스탠다드에 없는 프로세스라도, 기존 ERP와 전혀 조화를 이루지 못한 채 CBO화

속된 말로 "무지성 CBO"라고 할 수 있겠다. 이렇게 만들어진 것들은 향후 유지보수에도 악영향을 미치고, ERP의 최대 장점인 모듈 간 Integration에도 안 좋다. 업무 처리가 쓸데없이 복잡해진다. 프로세스에 구멍도 생기게 된다.

이랬기 때문에 최대한 스탠다드를 추구하는 것이 올바른 방식이란 말이 많이 퍼졌을 테다.

CO로 예를 들면 예산 통제 프로세스를 만들 때 그런 게 있다. 예산 원장을 별도 CBO 테이블에 만들어서 통제하는 방식.

실적은 스탠다드 회계원장에도 있고 약정이나 임시 전표도 추출 가능함에도, 그걸 몰라서 별도 테이블에 집어넣도록 하는 방식이랜다.

뻔히 스탠다드에 있는 트랜잭션을 별도 테이블에 넣는다? 완전 잘못 이해한 방식이라고 생각한다. (예산 통제에 누락 가능성이 생겨버린다)

과거에는 SAP 스탠다드에 대한 지식수준이 지금 같지 않았기 때문에 생각 없이 만들어진 CBO가 많았던 것 같다.

그런데 지금은? 현업도, 모듈 컨설턴트도 과거와 다르다. 훨씬 수준이 올라갔다.

요구사항은 까다로워졌고 기대하는 수준도 높아졌다.

20년 가까이 운영 경험이 쌓이면서

1. 스탠다드라도 불일치가 발생하는 걸 많이 발견했다.

2. 스탠다드라도 도저히 Best Practice라고 하기 어려운 것들도 있음을 알게 됐다.

이제는 현업들에게 무조건 스탠다드 대로 쓰라고, 그게 BP라고 우기기는 어렵게 됐다. 정히 그러고 싶으면 확실한 근거를 만들어와야 한다.

그러니 무조건 "CBO = 악, 스탠다드 = 선"이라는 이분법적인 전제는 다시 생각해봐야 하지 않을까?

CBO라고 전부 다 무지성인 건 아니다. 오히려 스탠다드를 100% 이해한 상태로 만드는 CBO는 스탠다드 그 이상의 것을 보여줄 수 있다.

1. 스탠다드에서 부족한 프로세스를 보완할 수 있다. (단, 그 과정과 결과는 스탠다드와 조화를 이뤄야 한다)

2. 스탠다드의 불일치 사항을 점검할 수 있다. (눈에 띄지 않고 모르는 채로 새어나가는 것들이 꽤 있다)

3. 스탠다드의 로직을 이해하기 쉽게 표현할 수 있다. (현업 입장에서는 블랙박스다)

4. 대량 처리 등 업무 편의성을 높일 수 있다.

물론 잘 만든 CBO에도 전제 조건은 있다. 우선 스탠다드를 100% 이해할 것