개념을 쉽게 설명하기 위해 사내 SNS라고 표현했지만, 형식은 덜 중요하다. 메신저보다 더 느슨한 대화를 표방하며 메일은 물론 사내 게시판(그룹웨어)보다도 비격식적이라는 위상만 지키면 된다.[각주:1] 이러한 소통의 장을 마련하기만 해도, 아래와 같은 이로움을 얻는다.


  1. 실질적인 지식경영의 수단
    • 메일, 문서/보고보다는 작성에 부담이 없으므로, 메신저처럼 휘발적이거나 즉각적인 응답을 요하지 않으므로 지식의 축적이 용이하다.
    • 단, SNS에 글 올리는 걸 경영진이 의식적으로 장려해야 축적이란 게 가능하다. 몇몇 사람들이 일이 많네 적네 운운하는 순간, 사내 SNS는 물을 건너가고 만다.
    • 검색 엔진과 결합하면 더할 나위가 없다. 부서나 주제에 따라 보안을 유지하기 위해 검색결과 표시에 권한체계를 반영해야 하는 수도 많다.
       
  2. 회식보다 싸게 먹히는 팀워크 강화 방안
    • 대면보다 1회 소통의 효과는 떨어져도 느슨하지만 잦은 소통은 기간을 두면 효과적이다. 얼굴 한 번 본 적이 없는데도 SNS를 통해 이미 취향을 알아서 대면하게 되면 더 빨리 어색함을 날려 버린다.
    • 한국 경영진들이 바라 마지 않던[각주:2] 조직 전반적인 일체감을 느끼게도 해준다.


아래의 보고자료도 참고하길 바란다.



***

  1. 메일을 요구해야 할 때는 분명히 있다. [본문으로]
  2. 말만 그렇고 실제로는 그렇지 않을 수도 있다. [본문으로]
저작자 표시 동일 조건 변경 허락
크리에이티브 커먼즈 라이선스
Creative Commons License


Posted by wizmusa

 SAP사의 ABAP 언어를 다루는 ABAPer는 보통의 개발자가 특정 개발 프레임워크를 활용하는 것보다 더욱 높은 비중으로 SAP가 제공하는 인프라인 BAPI, function module, Composition Environment 등을 써서 비즈니스 로직을 구현해야, 고객사의 SAP 솔루션 투자에 대한 ROI를 높여주게 된다.


 SAP의 주요 개발언어는 ABAP(Advanced Business Application Programming)으로, ABAP을 쓰는 개발자를 ABAPer라 부른다. Javaer나 C#ist 같은 용어가 없는 반면, ABAPer라는 용어가 쓰이는 현상[각주:1]은 SAP 환경이라는 특수성에 기인한 바가 크다. 종속적이라 표현해도 좋을 만큼 ABAP 개발은 SAP가 벌려 놓은 판을 충실히 따르는 게 미덕이다. 정말 버그가 적고 안정적이며 빠른 개발이 이루어진다. 이러기 위해서는 ABAPer나 IT Architect가 SAP 체계의 활용에 능해야 한다.


 더불어 ABAPer는 SAP 체계를 비롯한 일련의 비즈니스 절차에 대해서도 익숙할 필요가 있다. 스펙에 맞춰 개발만 해도 밥벌이는 할 만하지만, 단순 ABAP coder는 ABAPer로서 장수하기 힘들다. 어디나 그렇듯 경험 있는 개발자에게 거는 기대는 프로그래밍에만 있지 않기 때문이다. 컨설턴트가 있다고 해도, 어떤 비즈니스 프로세스를 보다 빨리 안정적으로 구현하거나 구현 가능성 유무를 금방 알거나 대안을 제시하되, SAP에서 기본제공하는 방식 위주로 엮어내기는 경험 많은 ABAPer만 가능한 일이다.


***


 초짜 ABAPer의 진로가 순수 개발의 영역에서 많이 벗어나는 게 눈에 띄는 것도 일반 개발자와의 차이라고 볼 수 있다. ABAP만 아주 잘해봐야 현업 고객 입장에서는 5년차와 7년차의 차이를 구분하기 힘든 만큼, ABAPer의 재량은 비즈니스에 대한 지식에 의해 빛을 보곤 한다. 이러다 보니, 봉급 인상을 따라 ERP 모듈 컨설턴트로 성장하는 일이 잦다. 특정 모듈을 잘 하는 걸로 유명한 ABAPer도 꽤 있긴 한데 컨설팅은 영 취향이 아니라 개발자로 남은 때가 많은 듯싶다.[각주:2] 이게 아니면 SAP IT Architect의 길이 있지만 한국 기업은 SAP ERP씩이나 하는데도 다소 영세한 구석이 있어서 이 역할을 필요로 하는 기업이 매우 적다.[각주:3]


***


 2015년 현재, 한국 기업이란 곳이 워낙 효율 위주로 돌아가서 정작 효과는 놓치기 십상이라 경력자로서 불안하기는 ABAPer나 일반 개발자나 매한가지이다. 3년차가 넘어가면서도 계속 개발일을 하고 싶다면 영어를 공부하는 게 어떨까 한다. 면식 있는 ABAPer/컨설턴트 부부도 호주로 이민 갔고[각주:4], 아일랜드나 이런 저런 영어권 나라에서 SAP 기술자를 우대한다는 얘기를 들으니 타향살이 하는 것도 괜찮겠다 싶다. 일종의 진입장벽이 있는 SAP 세계와는 달리 일반 개발자는 보다 명확한 증빙이 필요하다고 한다. 오픈 소스 프로젝트에 참여하거나 프로젝트 포트폴리오를 잘 갖추면 되지 않을까 한다.


 그런데 이러니 저러니 해도 한국에서 무려 IT 사업을 하거나 소소하게라도 프로젝트 일을 이어 하는 사람도 많다. 다 인연 닿는 만큼 할 수 있고, 마음 가는 대로 갈 수 있는 것인가 보다.


***


 개발자라고 하면 왠지 혼자 일하는 이미지가 먼저 떠오른다. 굳이 다른 사람들과 같이 일한다고 하면 기획자나 디자이너가 생각나지 않을까? 그런데 개발자들은 생각보다 좀 많이 협업을 한다. 일단 좀 큰 업체에서 일하는 개발자는 DBA나 Data warehouse 관리자와 일하는 때가 많다. 개발자끼리도 주고 받을 게 많아 회의를 해야 할 때가 잦으며 말로만 떠들어서는 안 되니, 문서작업도 의외로 많이 해야 한다.


 ABAPer는 보통 개발자보다 협업할 일이 많다. ERP 구축 프로젝트 정도 되면 혼자 개발할 도리가 없다. 현업 사용자와 다른 모듈 개발자와 컨설턴트와 PM과 회의하며 스펙 문서를 주고 받다 보면 이거 개발은 언제 하나 싶을 때도 흔할 것이다. 현업 업무의 불확정성(!)에서 오는 나비효과는 살뜰하게 말단 개발자에게까지 광풍을 몰아 오기 때문이다.


 때문에 ABAP의 세계로 들어 온 개발자로서 대리급이 되면서부터는[각주:5], 대화와 소통의 기술을 갈고 닦아야 제 기량을 잘 발휘한다는 인상을 줄 수 있다. 더불어 SAP standard를 잘 알아야 현업의 니즈를 유연하게 수용할 수 있도록 이끌어 나가며 인간적인 삶에 한 걸음 더 다가가게 된다. 컨설턴트와 싸우라는 얘기는 당연히 아니고, 적절하게 주장할 정도는 되어야 두루두루 좋다.[각주:6]


***

  1. 정작 SAP는 교육과정 소개나 여타의 공식문서에서 ABAPer라는 어휘를 쓰지 않는 편이다. [본문으로]
  2. 현업 고객을 상대하는 건 주로 컨설턴트로, ABAPer는 그런 번잡한 일은 거의 하지 않는다. 그냥 개발만 줄창 한다. [본문으로]
  3. Project Manager나 BC 기술자가 하면 된다고 생각들 한다. (애초에 SAP Korea에서도 얘기한 적이 없을 듯) [본문으로]
  4. 또 다른 IT 부부는 고기집을 냈고;;; [본문으로]
  5. 그전까지야 죽어라 ABAP을 파야 한다. [본문으로]
  6. 윈윈. [본문으로]
저작자 표시 동일 조건 변경 허락
크리에이티브 커먼즈 라이선스
Creative Commons License


Posted by wizmusa
이전버튼 1 2 3 4 5 ... 228 이전버튼

블로그 이미지
SAP BW/BO/BI, MS BI, IT기획 멀티 플레잉의 기록
wizmusa
Yesterday168
Today23
Total408,928

글 보관함

최근에 받은 트랙백

달력

 « |  » 2015.07
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31