안녕하세요. 최근 SD 운영을 맏고 있는 Aisp 입니다.

 

 요즘 SD 운영을 하다가 SAP 이라는거에 대해서 생각을 해봅니다.

 

저는 처음에는 산업공학과를 나왔습니다.

프로그래밍이란건 정말 허망한 학과라고 생각을 했어요.

 

왜냐면 프로그램은 한두명의 개발자가 전체 99%를 독식하는 체제라고 생각을 했습니다.

즉 하나의 카테고리에서 상위 한두개의 프로그램만 있으면 된다고 생각했기 때문이죠.

 

그래서 소프트웨어 학과를 꿈을 쫒는( 자신도 상위 1%에 프로그램을 만들기 위해서 ) 혹은 미래를 생각하지 않는,

당장 편한 일을 하는 학과 라고 생각을 했어요. (책상에 앉아서 일하니까.)

 

그런데 막상 사회에 나와보고, SAP ABAP 코더로서 일을하며,

세상을 보니. 회사는 정말 프로그램의 전산이였습니다.

 

하나의 회사를 운영하기 위해, 수많은 프로그램이 필요했고, 그 많은 프로그램을 사람이 직접 모두 만든다는 생각은

꿈에도 못했습니다.

 

처음으로 왜 IT 학과가 존속되고, IT의 수요가 계속있는지 알게되었지요.

 

지금와서 생각해보면, 부서의 변화, 일의 변화 등등을 다 세팅사항으로 컨트롤 할 수 없고,

이유야 어찌됐든 각각의 기업이 각각의 프로그램을 만들어서 구동하고 있더라고요,

또한 프로그램을 만든다는 생각도 못했습니다. 프로그램이란, 정말 엄청난 누군가가 하늘에서 뚝 떨어지는 것이라고 생각했거든요

마치 MS 오피스나 윈도우 처럼요 .

 

여기까진 잡설이고,

 

여차저차 하여 SAP에 진입하여 ABAP 프로그래머로 성장하려다가,

SD 운영으로 출장일을 하고 있습니다.

 

SAP이 재미있는게,

 

프로그램이 정말 복잡하다는걸 느꼈다는 겁니다.

그동안 느껴왔던 프로그램과 달리 SAP은 정말 복잡하다는 생각을 하였습니다.

 

마치 게임처럼요.

기존의 다른 프로그램들은 그리고 제가 만들었던 프로그램들은 (BSP 레포팅, 혹은 일반 회사 프로그램들도)

사실 사용자 메뉴얼도 필요 없었습니다.

 

대부분 직관적인 프로그램이고, 단계가 복잡히 이어지지 않았기 때문이기도 하겠지요.

이전에 더존 ERP를 배운적 있었는데 이 프로그램 조차 사용자 메뉴얼이 그닥 필요하지 않았습니다.

교수님의 얘기나 추측, 예상 만으로도 충분히 프로그램을 사용할 수 있었죠.

자재를 만든다거나, 입고처리, 출고처리, 예외상황은 한두건 정도.. 대부분 조금만 익히면

전체 프로그램 구동에는 문제가 없었습니다.

 

그리고 ABAP개발을 하면서도 못느꼈습니다.

대부분 CBO 프로그램은 복잡하지가 않았고(만드는게 복잡하더라도) 구동 자체는 목적만 알면

프로그램 컨트롤은 버튼 몇개가 끝이기 때문이지요.

 

그런데 운영을 해보니 SAP은 정말 또다른 신세계 였습니다.

수많은 컨트롤 영역이 있고,

 

또한 단계가 계속 물고 이어져서 이 프로세스가 다음 프로세스에 어떻게 영향을 미치는지,

이 프로세스 처리가 어떤 영향을 끼치는지 명확히 깨닫기가 힘들 정도 입니다.

(아직도 SD에서 회계처리를 하면 그 프로세스가 회계 어디에 꽃히는지,

그리고 그 처리가 회계에서 어떤 영향을 미치는지, 그럼 회계는 그 정보를 가지고 어떤처리를 하는지,

또한 그 처리는 다음에 어떤 영향을 미치는지. 아직도 잘 모르겠고,

설명하려면 많은 지식과 학습이 필요할꺼같습니다. )

 

그러다 보니, SAP이 게임보다도 복잡한 프로그램이라고 생각했고,

왜 메뉴얼이 없을까를 생각하게 되었습니다.

 

이다지 복잡한 프로그램인데, 각각의 영역이 어떤 의미를 가지고,

어디에 영향을 미치며, 무엇을 하기위해서 무엇이 필요한지. 쉬운 메뉴얼 하나 없다는게

당황스러웠습니다. (물론 소위 말하는 SD 교재를 정식으로 배우지 못했고, 동영상강의도 조금만 들었지만

말그대로 컨설팅하기 위한 교재 이며, 각각 프로세스에 대한 정의가 아닌 전체적인 흐름을 배우는걸로 판단하였습니다.)

 

이유는 아마 각각의 세팅사항 때문이 아닐까 합니다.

프로세스 영역부터 각기 만드는것이고, 컨설팅 하기 떄문에

 

정확히 이 트랜잭션은?? 하는것이고 어디에 영향을 미친다 라고

획일화 해서 얘기할 수 없는 것이지요.

 

즉 사용자는 이 프로그램을 어떻게 세팅했는지를 알아야 하거나.

혹은 세팅을 만들어논 사람이 알려주는 대로 받아 먹어야 한다는 것입니다.

 

이게 재밌는 이야기 입니다.

 

저는 사용자고, SAP이란 프로그램을 사서 사용하고 있는데,

이 프로그램이 정확히 어떤 영향을 미치는지 알 수 없고, SAP에게 물어볼 수 없고 왜냐면

그 프로그램은 각각의 세팅으로 이루어져 있기 때문에..

 

SAP,

컨설팅,

사용자

라는 삼박자로 참 신기한 현상을 펼치는거 같습니다.

 

보통은 개발자, 사용자라는 두 체제로. 모르는 부분이나 합당하지 않은 부분은 명확한 설명을 요구하고

또한 개발자는 사용자가 돈을 지불하는 만큼 정확한 프로그램에 대한 정의를 내려 가르쳐 준다 생각합니다.

마치 사용설명서 처럼요. (기업이 사용설명서를 만드는건 의무라고 생각해요. 인심쓰는 선택이 아니라는 거죠.

왜냐면 사용자의 알권리, 정확히 사용할 권리가 있다고 생각하기에. 또한 명확한 사용법을 알리지 않고

일어난 일들에 대한 책임은 기업에게 있기 때문에 )

 

그런데 SAP이라는 이 3강체제가 재밌는거 같습니다.

중간에 컨설팅이라는 업체가 껴있고, 프로그램 자체는 컨설팅에서 세팅해주며,

이 업체가 제대로 가르쳐 주지 않으면 사용자는 당해낼 도리가 없다는 것이죠.

사용자가 세팅사항을 배워서 프로그램을 이해하라는건 아니지 않을까요 ?

 

결론은 SAP운영을 하다가 하나의 현상에 대해서 막혔습니다.

자동차 같은 경우도 취급명세서를 읽고 명확히 사용하는 편인데,

 

이 현상을 해결하려니

SAP이란건 사실 정형화된 하나의 프로세스를 가지고 있는게 아니더라고요.

 

각각의 컨설팅과 세팅사항이 있기에 SAP에게 명확히 메뉴얼을 요구할 수 있는것도 아니고,

그렇기에 사실 SAP-SD 통합 사용자 메뉴얼!! 이란게 있지 않다 생각합니다. 

 

사실 SAP-SD 사용자 메뉴얼은 컨설팅 업체에서 만들어 배포해주는거 밖에 없잖아요.

그마저도 컨설팅 업체에서 대충 작성해서 만들어 준다면

사용자는 받기만 하는 입장 요구할수 없는 입장이기도 하고. 컨설팅 업체가 떠나버리면.

 

그래서 항상 운영인력을 끼고 가야하는거 같기도 하고.

저는 운영이지만 실제 사용자가 얼마나 불편한지 한번 생각해 보았습니다.

 

나는 돈을 지불했다 -> 그러니 당당하다 -> 무엇을 하다 모른다 -> 나를 왜 모르게 했느냐 ->

그럼 해결하려면 어떤걸 알아야 하느냐 -> 그럼 어디에 물어야 하느냐 -> 왜 빨리 알려주지 않느냐 ->

 

이런 스타일이 제 스타일인데. 참 공식적으로 어디에 물어야 할지 모르겠고,

이지 아밥분들과 회사분들께 물어 겨우겨우 연맹하고 있네요.

 

와. 말이 길었네요.

정말 다년간 혹은 십수년을 하신분들은 또 시각이 많이 다르겠지요 ?

여튼 복잡한 감정은 생각으로 풀어내기가 힘드네요.

 

이만 초보 SD운영자의 푸념이였습니다. ..