SAP 운영에서 구축으로 넘어가기 위해 필요한 능력

 

운영에서 구축으로 넘어가서 적응하기는 쉽지 않다고들 한다. 어떤 이들은 운영 경력을 구축에 비해 낮은 수준이라며 폄하하기도 한다.

 

하지만 꼭 그렇지만은 않다. 나도 운영으로 시작했다. 운영도 운영 나름이다. 내 경우는 운이 좋게도 운영이라고 단순히 '현재 상태를 유지하는 것'만 하진 않았다. 내가 다니던 회사는 웬만한 고도화나 롤아웃 프로젝트, 심지어 신규 법인 구축까지도 우리가 직접 수행했었다.

 

덕분에 여러 고도화 프로젝트를 경험할 수 있었고, 운영하면서 장기적으로 구축 이후에 해당 프로세스가 어떻게 흘러가는지까지 살필 수 있는 기회가 됐었다.

 

아무튼 그렇다고는 해도, 순도 100% 운영만 하다가 구축으로 넘어가서 제 몫을 제대로 해내긴 어려운 일이다. 그럼 최소한 어떤 능력을 갖추고 있어야 성공적으로 구축에 넘어갈 수 있을까?

 

지금부터 내 사례와 함께 구축에서 필요한 '최소한의 능력'을 얘기해보고자 한다. (최소한의 능력이다. 남보다 특출나기 위해서가 아니다. 기본적으로 제 몫을 하려면 이 정도는 갖춰야 한다고 생각한다.)

 

 

 

 

---

 

 

1. Module Configuration 능력

 

첫 번째는 자기 모듈의 컨피그레이션 능력이다. 다시 말해 "IMG 할 줄 아는지? Functional Process를 모두 이해하고 있는지?"다. 구체적으로 짚어 보면 다음과 같다.

 

 

• 모듈 IMG를 모두 알고 있는가? 각 항목을 언제 어디서 어떻게 쓰는지 알고 있는가?
• 마스터 데이터, 표준 T-CODE의 기능과 의미를 다 알고 있는가?

 

허나 지식을 단순히 이해만 하는 데서 그치면 안 된다. 본인이 책이나 문서를 읽고 알았다고 해서 그것이 전부라 착각하면 안 된다. 반드시 "자기 몸으로 직접 그걸 수행할 수 있는지"를 점검해봐야 한다. 따라서

 

 

 

• (그 결과) 빈 깡통 서버에서 처음부터 집을 짓듯이 IMG와 마스터 데이터를 세팅하고 트랜잭션을 다 처리할 수 있는가?

 

결론적으로는 바로 이 능력이 필요하다. 빈 깡통에서 모든 걸 만들 줄 알아야 한다.

 

그럼 어떻게 이 능력을 키울까? 어렵지 않다. 해보면 된다. 당장 지금부터.

 

운영을 하고 계신 상황이라면 개발 서버든 QA 서버든 남는 서버가 있을 것이다. 그 서버를 이용해서 처음부터 하나씩 만들어보면 된다. 아예 이런 연습 전용의 샌드박스 서버가 있으면 제일 좋겠지만, 그럴 여건이 안 된다면 그냥 개발 서버를 이용해도 괜찮다. (QA 서버는 아무래도 좀 부담스러우리라 본다. 주기적으로 클라이언트 카피도 할 것이고)

 

내 경우는 현재 이 회사로 와서 구축을 시작하기 전에 이 사이클을 5번은 해봤다. 그리고 이 회사 와서도 2~3번은 더 해봤던 것 같다. 프로젝트와 상관 없이. 

 

나는 5번 해봤지만 그건 어쩌다보니 그렇게 된 거고, 내 생각엔 적어도 3번 이상은 해봐야 한다고 생각한다. 그래야 몸에 익혀진다. 단순히 시스템에 입력하는 데에 그치지 않고 그 내용을 캡쳐해서 본인 만의 매뉴얼을 만들면 더 좋다.

 

이 방법이 왜 좋은가? 때론 이 방법은 실제 구축보다도 좋다. 왜냐하면 실제 구축에서는 경험할 수 없는 여러 실험들도 해볼 수 있기 때문이다. SAP PRESS 책이나 SAP HELP 문서에 있는 표준 프로세스도 해볼 수 있고, 일반적으로 국내 회사에서 잘 쓰지 않는 방법도 해볼 수 있다. 해보고 나야 그게 더 좋은 방법인지 아닌지 직접 느낄 수 있다. 그래야 해당 기능에 대한 자기만의 견해도 생긴다.

 

또한 여러 비즈니스 요구에 맞닥 드릴 때, 내가 알고 있는 방법, 기능이 많아야 그걸 창의적으로 조합해낼 수 있다. 이건 마치 알고 있는 어휘가 많을 수록 더 고급스러운 문장을 만들어낼 수 있는 것과 같다.

 

 

 

2. 검증 능력

 

두 번째는 검증 능력이다. 쉽게 말해 "구멍이 없어야 한다"는 뜻이다. 사실 이거는 능력이라기 보다는 소양에 더 가깝다. 

 

A를 100개 입력했으면 정말 100이 맞는지 다시 한 번 확인해야 한다. 어찌보면 당연한 일이지만 이것조차 하지 않는 분들을 많이 봤다. 당연히 구멍이 생긴다.

 

예를 들면 우리 CO의 경우 코스트센터별 비용 계획 데이터를 엑셀로 업로드했다고 해보자. 업로드 다 했으면? 당연히 그게 제대로 올라갔는지를 확인해봐야 한다. 검증 포인트는 각 작업마다 다른데 예를 들면 아래와 같다.

 

 

• 100을 입력했으면 정말 총합 100이 맞는지
• 각 구성요소별로 틀린 부분은 없는지
• CBO 프로그램의 결과뿐만 아니라 스탠다드 리포트로 확인해도 차이가 없는지
• 파생되는 트랜잭션은 정상 작동하는지

기본 중의 기본이다. 새로운 CBO 프로그램을 개발했거나, 데이터를 업로드했거나, 마스터 데이터를 구성했거나, 컨피그레이션을 새로 잡았거나 하면 기본적으로 확인해봐야 한다. 이 때 엑셀이나 쿼리를 잘 다루면 훨씬 빠르고 정확하게 검증할 수 있다. 

 

나는 이게 당연하다고 생각하고 살았는데 의외로 대충하는 분들을 가끔 봐서 쓴다.

 

 

 

3. Technical Skill

 

다음은 SAP에 대한 테크니컬 스킬이다. 다시 말해 ABAP이다. ABAP 몰라도 된다고 하는 분들 물론 많은 걸로 안다. 나도 밖에서 말은 그렇게 한다. 하지만 내 속마음은 조금 다르다. ABAP을 잘 알면 잘 알수록 그만큼 빨리 퇴근한다.

 

요즘 나는 CBO를 개발할 때 이렇게 한다.

 

1. 먼저 스펙을 작성하면서 필요한 화면을 그려본다. 그리고 해당 화면에 필요한 필드와 테이블을 적어본다.

2. 필요한 필드와 테이블로 CDS 뷰를 만든다. (사전 검증) CDS 뷰로 사전 검증을 마치고 스펙 작성을 완료한다.

3. 개발이 완료되면 테스트를 해본다.

4. 애매한 부분이 있다면 디버깅하면서 코드도 살펴본다. (물론 케이스를 여러 개 만들어서 여러 번 테스트해보기도 해야 하지만, 코드로 확인할 역량이 된다면) 더 빠르고 확실하게 체크할 수 있다.

5. 자잘한 오류나 데코레이션은 (개발 선생님과 상의 하에) 직접 수정한다.

 

여기서 핵심은 CDS 뷰를 이용한 사전검증이다. 이 덕분에 사후 검증하는 시간을 대폭 단축할 수 있다. 일반적인 사후 검증은 개발 선생님과 소통하는 시간을 포함하면 훨씬 더 많은 시간이 걸린다.

 

이렇게 하려면 ABAP에 대한 어느 정도 지식이 있어야 하고, CDS 뷰를 구성할 수 있을만큼 SQL 능력도 있어야 한다. 또 효율적인 사후 검증을 위해서 엑셀 스킬도 익히면 익힐수록 좋다.

 

내 경우는 운영을 할 때 ABAP은 모두 내 스스로 작성하는 걸 1원칙으로 했고(남의 것 통채로 Copy & Paste 금지), 어떤 코드든 의미를 모르는 채로는 쓰지 않도록 했다. 그래서 처음에는 구문을 쓰면서 나 스스로 이해하기 위한 주석을 덕지덕지 달곤 했었다.

 

많은 사람들이 컨설턴트에게 ABAP은 그저 읽을 줄만 아는 정도만 되면 된다고 한다. 하지만 그걸 배우는 가장 빠른 방법은 스스로 해보는 것이다.

 

엑셀이나 파워포인트 같은 툴은 경영분석이나 회계팀분들이 잘한다. 그분들이 만든 파일을 뜯어보거나 또는 옆에서 직접 하는 걸 보면서 좋아 보이는 게 있으면 물어보면서 배웠다.

 

 

 

 

---

 

 

그 외 문서 작성 능력, 커뮤니케이션 능력, 발표 능력 등

 

이 능력은 사실 회사생활하면 어디서나 필요한 능력이기에 따로 언급하지 않았다.

 

다만 문서 작성 능력에 대해서만 언급하자면, 이 능력은 컨설팅 펌에서는 마치 심장과도 같은 핵심 중의 핵심 능력이다. 반드시 갖추어야 할 능력이며 이게 떨어지면 동료들에게조차 비웃음을 당한다.

 

최소한 쪽팔리지 않을 수준만큼은 갖추고 넘어오는 게 좋다. 잘만든 PPT 슬라이드는 따로 모아두고 많이 보면 좋다. 이또한 본인이 많이 만들어봐야 는다.

 

이 능력은 처음부터 잘할 수는 없다. 어느 정도 기본기를 갖춘 상태에서 넘어온 후, 여기서도 계속 배워야 한다고 생각한다. 아마 운영에 있을 때보다 훨씬 많은 문서 작성 기회(?)가 있을 것이다. 피하지 말 것!!!