블로그가 뜸합니다 - CO-PA 설계와 관련하여

 
 
마지막 게시물을 남긴지 2달이 넘어가는데 SAP 관련하여 뭔가 새로운 글을 쓸 내용은 없어서
간단한 근황이라도 남기려고 합니다.
 
 

1. 요즘 프로젝트

 
지금은 제조업이 아닌 다른 산업의 PI 프로젝트를 하고 있습니다. 이제 2달 정도 되었네요. 이게 바빠서 요새 글이 뜸했습니다.
 
여기 오기 전까지는 제조업이 아닌 경우의 CO라면 더 쉽지 않을까 싶었는데 막상 해보니 전혀 그렇지 않네요.
오히려 더 어렵습니다.
 
뭐가 더 어렵냐? 하면 비즈니스를 이해하기가 더 어렵습니다.
 
SAP CO 스탠다드의 대다수의 기능은 제조업 기준에서 잘 흘러가도록 되어 있고, 스탠다드만 잘 공부해도 그게 곧 베스트 프랙티스가 되어서 웬만하면서 어디가서나 어렵지 않게 먹힙니다. 그에 반해 제가 지금하는 산업 같은 경우에는 스탠다드 기능 자체가 많이 부족합니다.
 
SAP를 단순히 회계만을 위한 시스템으로 구성하고 타 영역은 다 웹시스템으로 돌리는 경우라면,
CO의 범위도 그에 따라 축소시킬 수 있겠지만 공교롭게도 제가 지금 하고 있는 프로젝트에서는 그러지는 못할 것 같네요.
 
결국은 CO-PA가 대부분의 목표이긴 한데, 이 CO-PA의 Value Flow가 일반적인 SD나 FI로 간단히 들어오는 구조가 아니다보니 고민이 깊습니다. 매출 유형도 여러 가지고 이 유형마다 특색이 다른데, 이를 마치 스탠다드처럼 발생 시점과 연계해서 최대한 PA 직과를 고민해야 합니다.
 
 

2. CO-PA 설계에 있어서 고려할 점

 
그래서 요즘 느끼는 게 일반 제조업에서의 CO-PA 설계와는 아예 다른 접근이 필요한 것 같다는 겁니다.
 
제조업의 경우 SAP의 조직구조와 자재/플랜트로부터 파생되는 정보들, 그 외에 SD와 연계한 마켓 세그먼트 정보들은 어느 정도 뻔한 면이 있는데요. 여긴 제조업이 아니다보니 아예 처음부터 고민을 해야 하겠더군요.
 
일단 비즈니스적으로 분석에 인사이트를 줄 수 있는 부분은 차치하고, 기술적인 관점에서 아래와 같은 5개의 분류 기준을 만들어봤었습니다.
 
1. 변경가능성에 따른 분류: 해당 특성은 가변적인가, 영구적인가?
2. 배부레벨에 따른 분류: 해당 특성 레벨로 배부 적수 집계가 필요한가, 그렇지 않은가?
3. 발생 원천에 따른 분류: 조직, 제품, 고객 중 어디에 해당하는가?
4. 입력 시기에 따른 분류: 발생시점에 입력하는가, 결산시점에 입력하는가?
5. 파생 방법에 따른 분류: 해당 특성은 최소단위인가, 파생단위인가?
 
1번 변경가능성에 있어서는 예를 들어 제품그룹이나 조직구조 같은 것들이 해당합니다. 제품계층구조 등의 그룹이 리포팅 목적으로 변경되거나 조직구조가 변경되어 과거 데이터까지 소급해서 볼 필요가 있다면? 일반적으로는 리얼라인먼트라는 기능을 활용합니다만, 이는 CO-PA 데이터를 직접 수정하는 것이기 때문에 퍼포먼스 문제가 있는 편이라 가급적이면 최소화하는 게 좋습니다.
 
그렇다면 그런 특성들은 굳이 CO-PA에 직접 기록하지 않고 테이블 Join을 통해서 리포팅하는 게 오히려 나을 수 있죠. 과거 CO-PA는 KE30 피벗 리포트를 이용하기 위해서는 무조건 테이블에 직접 기록이 필요했지만, S/4HANA 시대에서는 굳이 필요 없다고 봅니다. CDS 뷰를 구성해서 Analytic View로 보면 되니까요.
 
하지만 그럼에도 불구하고 2번 사항을 고려해서 직접 기록이 필요한 것들은 특성으로 추가해줘야 합니다. 특정 특성 조합별로 배부적수를 산출하려면 테이블에 기록해야 하니까요. 
 
하여, 1번과 2번을 고려해서 우리는 이 특성을 테이블에 직접 기록할 것인지, 또는 다른 기준정보 테이블과 Join하여 리포팅할 것인지 정해야 합니다.
 
3번 같은 경우는 SAP의 조직구조와 기준정보 Key Data를 구성하면서 자연스레 작성되는 부분이죠. 타 모듈과 협업이 필요합니다.
 
4번, 5번을 고려하면서는 이제 각 모듈별 Value Flow를 고민해야 합니다. 이 부분은 SAP 스탠다드라면 그냥 그걸 공부하면 되는 부분이지만, 스탠다드를 활용하기 어려운 비즈니스라면 마치 스탠다드를 설계하듯이 내가 구성해줘야 합니다. 
 
이 부분이 정말 어려워요. 이 부분 때문에 모든 모듈 회의에 들어가서 해당 비즈니스를 촘촘하게 보고 있습니다. 아시겠지만, 이 부분을 그냥 타 영역 컨설턴트가 100% 진행하게끔 두면, CO-PA를 위한 정보는 생략될 수 있거든요. 그 분들이 우리 CO까지 고려해주진 잘 않기 때문에...
 
그리고 위 5가지 사항에 추가로 성능 이슈를 고려해야 합니다. 아래 2가지를 추가로 고민해야 해요.
 
1. 테이블 Join을 한다면 해당 테이블 수는 몇 개인가?
2. 특성이 가로 열 데이터이고, 특성치는 세로 행 데이터이다. 둘의 곱에 따른 데이터 볼륨은 어느 정도로 예상되는가?
 
1번의 경우 직접 기록보다 테이블 Join을 택했다면, 그게 얼마나 퍼포먼스에 영향을 줄지 봐야 합니다. Join할 필드와 테이블 수는 몇 개인지, 깊이는 몇 단계인지 등등이요.
 
2번의 경우가 중요한데, 예를 들어 자재코드를 특성으로 정했다면, 해당 자재코드의 수가 특성치로서 몇 개나 될지 봐야 합니다. 그리고 그 단위로 배부 레벨로 쓸 거라면 배부될 때 데이터가 몇 배로 뻥튀기 될 건지 봐야 합니다. 여기에 추가로 분석항목별로 어느 레벨까지 배부할 것인지도 봐야겠죠.
 
이렇게 데이터 볼륨을 예측해보다 보면, 어떤 경우는 CO-PA를 스탠다드로 전표로 치는 게 맞는지 의심이 들 수도 있습니다. 너무 많은 대량의 데이터라면 스탠다드 CO-PA의 전표 처리 퍼포먼스는 부족할 수도 있거든요.
 
그런 경우라면 아예 별도의 CO-PA 테이블을 구성하든지, 또는 스탠다드의 확장 원장(Extenstion Ledger) 기능을 모방해서 유사한 별도의 테이블을 만들고, 총계정원장 테이블(ACDOCA)과 Summary하고 Join해서 보는 방식으로도 구상해볼 수 있죠.
 
 

3. 하여간 어렵다.

 
하여간 이런 저런 점을 다 고려해야 하는데 지금 느낌상으로는 개발이 많아질 것 같습니다. 일단 여기 구조상 스탠다드 배부 기능을 아예 쓸 수가 없어 보이고요. 저 스스로 무덤을 파는 게 아닌가 싶긴 하지만... 그런 방향으로 가고 있습니다.
 
그리고 개발에 착수하기 전에 미리 데이터 볼륨을 어느 정도는 시뮬레이션을 해놔야 확실하게 방향을 정할 수 있을 것 같아요.
 
게다가 기존의 기준정보 체계도 잘못된 부분이 있어서, 그 부분까지 대수술을 하려면... 여러모로 고생이 예상되네요.