본문 바로가기

SAP CO/기본 개념

CO 관점의 E2E 프로세스 - 0. 시작하며

ERP E2E 프로세스, 이제야 시작하는 이유

블로그를 시작하면서 꼭 한 번 다뤄보고 싶었던 주제가 있다.
바로 ERP 전체 프로세스를 End-to-End 관점에서 따라가면서, CO의 비용 집계 → 배부 → 원가계산 → PA 결산까지 어떻게 연결되는지 설명하는 것이다.

사실 진작에 했어야 했지만, 오히려 너무 많이 해본 주제라 개인적으로는 좀 지겨웠다.
신입 시절에는 무척 즐겁고 재밌었지만, 어느덧 1n년이 지나면서 흥미가 다소 사라진 것도 사실이다.

그럼에도 불구하고 이 글을 쓰게 된 이유는 단순하다.
이번에 피오리를 본격적으로 다뤄볼 기회가 생겼기 때문이다.
피오리는 예전에도 해봤지만, 19~20년도 이후로는 손을 놓고 있었기에 거의 5년 만의 재도전이다.

 

왜 다시 피오리인가

갑자기 왜 이 시점에 피오리일까?

처음 피오리를 접했을 때는 솔직히 별로였다.
느리고, 생소하고, 불편하고, 무엇보다 기존 SAP GUI 대비 효율이 떨어져 보였기 때문이다.
개발 관점에서도 웹 기술이 추가되면서 공수, 난이도, 유지보수 비용이 모두 증가했고,
그 시기(19~20년경)에 도입을 검토했던 여러 사람들도 결국 외면했다. 나도 마찬가지였다.

하지만 이제는 상황이 다르다.
피오리가 등장한 지도 벌써 10년 가까이 되었고, 그 사이 기술과 사용자 경험도 많이 개선되었다고 한다.

 

챗GPT에게 물어본, 요즘 피오리의 변화

챗 GPT에게 물어본 결과

 

※ 위 내용은 챗GPT가 정리한 것이지만, What's New in SAPUI5 1.96 | SAP Help Portal과, What's New in SAPUI5 1.120 | SAP Help Portal을 출처로 하고 있다.

 

1. 일단 빨라졌다.

내가 보기에도 과거보단 빠른 것 같다. 웬만한 앱들은 이제 GUI에 비빌 만은 해진 것 같다.

 

2. Fiori Elements와 RAP의 도입으로 개발 난이도도 감소 중이다.

특히 List Report라면 ALV 개발 수준이나 심지어 유지보수뷰 개발 수준의 편의성까지 다가간 것 같다.

(나도 아직은 Fiori Element + SEGW 방식으로만 만들어본 수준이긴 하다. RAP와 v4 odata도 해봐야 한다.)

 

그리고 세월이 흐르면서 SAP GUI에 절여져 있던 나도 이제는 웹 스타일의 UI에 꽤 적응이 되었다.

 

나도 이제는 피오리에 대해 열린 마음을 좀 가져보고자 한다. 내가 피오리를 더 관심 있게 봐야겠다고 생각한 것은 그 뿐만이 아니다.

 

내가 피오리에 주목하는 두 가지 이유

1. Universal Parallel Accounting.

UPA에서 수많은 T-CODE가 사라지고 피오리로 대체된다. UPA는 Margin Analysis 이후로 CO에서는 가장 강력한 혁신이 될 거라 생각해서 관심이 많다.

 

2. AI. 

웹 UI를 기반으로 해야 AI와의 연동도 자연스러워진다. AI는 ERP 생태계에도 거대한 변화를 가져올 것이며, 그 중심에 웹기술이 있다. 나는 이 변화에 올라타고 싶다.

 

 

 


 

 

이번 시리즈의 방향

 

  1. 피오리 앱을 기준으로 구매 → 생산 → 판매 → 전표 입력 → 배부 → 원가 계산 → PA 결산까지의 흐름을 설명한다.
  2. 전 과정이 100% 피오리 앱으로만 이뤄지지는 않는다.
    SAP GUI의 T-CODE와도 비교하며 설명한다.
  3. 물류 트랜잭션이 FI와 CO에 어떻게 연결되는지를 중점적으로 보여줄 계획이다.
  4. 시나리오는 가능한 한 단순하고 보편적인 케이스만 다룬다.
    복잡한 예외 케이스는 일단 제외한다.

 

그리고 이 블로그가 늘 그래왔듯이 무조건 신기능이 좋다고 찬양하지는 않는다. 장점과 한계점을 모두 다뤄본다.
아래 레딧에서 가져온 글처럼 여전히 피오리에 대해 안 좋은 반응이 좋은 반응 보다 더 많다.

 

reddit의 어떤 게시글

 

https://www.reddit.com/r/SAP/comments/1g47uob/fiori_is_a_fucking_mess/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

 

 


 

E2E ERP 프로세스

일반적인 E2E 프로세스

 

 

End-to-End는 다음 네 가지 큰 흐름으로 나눠본다.

 

  1. P2P (Procure-to-Pay)
    → 구매요청부터 대금지불(채권 반제)까지의 흐름. Procure-to-Pay 또는 Purchase-to-Pay라고 한다. (MM 중심)
  2. P2P (Plan-to-Produce)
    → 생산계획부터 생산입고까지의 흐름. Plan-to-Produce라고 한다. (PP 중심)
  3. O2C (Order-to-Cash)
    → 주문부터 매출채권 회수까지의 흐름. Order-to-Cash라고 한다. (SD 중심)
    ※ 때로는 이 흐름이 전체 물류 프로세스를 포괄하기도 한다. 고객이 주문하면 필요한 원자재부터 구매해서 생산해야 하니까.
  4. R2R (Record-to-Report)
    → 회계 전표 기록부터 결산, 보고까지. Record-to-Report라고 한다. (FI/CO 중심)

각 섹션마다 글 하나로 정리될 수도 있고, 분량에 따라 여러 편으로 나뉘게 될 수도 있다.

 

 

 


 

마무리하며 – 다시 신입이 된 기분

요즘 공부할 게 너무 많아서 다시 신입으로 돌아간 기분이다. 그동안 쌓아온 경험이 무색하게 느껴질 만큼, 같은 출발선에 선 느낌이랄까.

특히 기술적인 부분에서는 더욱 그렇다. 정말 아무 것도 모르면서 맨땅에 헤딩하듯, 더듬더듬 길을 찾아가고 있다. 

 

컨설턴트로서 이런 기술적 공부가 필요할까? 혹자는 "컨설턴트에게 기술적 지식은 필요 없다"고 하기도 한다. 

개발을 잘하는 사람은 그만큼 소통이나 문서 작성 역량이 부족하다는 이미지가 있다. 실제로 그런 사례도 많은 것도 사실이다.

 

하지만 나는 다르게 생각한다.

 

나는,

PPT 장표도 잘 만들고 싶고,

회의와 소통도 잘 이끌고 싶고,

글도 잘 쓰고 싶고,

SAP도 잘하고 싶고,

사실 개발도 어느 정도 잘하고 싶다.

 

할 수 있지 않을까? 그러기 위해 PI와 구축 프로젝트를 번갈아 가면서 경험해왔고, 무엇보다 다 재미있으니 오래오래 할 수 있으리라고 생각한다.