SAP ERP 관련 아이디어,

신입사원때 아이디어 제안 차원에서 써본건데

다시읽어봐도 시사할점이 있다고 생각하여 저장.

Corporate Platform

기업환경에서 사용가능한 데이터 가공, 레포팅, 권한, 형상관리를 자동화 해주는 웹 기반의 오픈소스 클라우드 플랫폼 및 마켓플레이스.  

1) 기본적인 웹베이스로 데이터가공, 레포팅, 권한, 형상관리 제공

2) 마켓플레이스를 통해 업무 프로세스 로직 개별 프로그램(모듈) 및 필요 커스터마이징 판매 및 구입

3) 마켓플레이스를 통해 대규모 데이터 처리에 대한 스트리밍 클라우드 컴퓨팅 제공 판매

 

현재의 Pain-Point

현재의 기업환경에서 트랜잭션 데이터와 레포팅용 데이터는 SAP의 ERP플랫폼과 ABAP이라는 폐쇄언어에 의존적인 경향이 있음.

수많은 기업 개별 프로세스 도입 시 불합리한 구조 - SAP패키지는 다분히 공통화된 업무 프로세스를 시스템으로 녹여낸 상태의 제품을 이용하는 측면에서의 라이센스 계약인데 많은 부서에서 기업특화 시스템을 담긴위한 공용 개발 플랫폼처럼 이용하여 불필요한 라이센스 비용 지출과 SAP의존적인 IT구조가 나타나고 있음.

SAP 플랫폼 종속력 심화 - SAP은 자기들의 회사 솔루션이 플랫폼성격으로 쓰이고 있으므로, 그동안 SDS에서 개발하고 구축한 방법론들을 자사 솔루션으로 합쳐버리고 이를 외부에 솔루션 형태로 판매하고 있음. 특히 요즘에는 클라우드 기술이 대두되면서 기존의 SDS의 사업영역(인프라 등)을 계속 침범하고 있으나 모든 ERP 솔루션이 SAP에 종속되어버려 그 위급성 조차 감지하지 못하는 상태에 이름.

개발언어로써의 ABAP의 한계와 불필요한 코드 생성 - 또한, 본질적인 행위인 개발행위가 SAP 솔루션 위에서 피상적인 형태로만 이루어지기 때문에 인력들이 IT에 대해서 근본적인 이해가 부족해지며 개발천시문화 확대 및 문서작업이 많아지는데도 불구하고 전체적인 SW 개발역량은 오히려 떨어지는 결과를 낳게됨. 또한 많은 진보된 개발 기능들이 반영되지 않아 코드는 길어지고 버그는 이와 마찬가지로 버그가 선형적으로 늘어남.

 

 

개발진행

해당 프로젝트는 다음과 같은 절차로 진행될 예정

주요 프로그래밍 언어 : Scala + Play Framework 2.5

현재, ABAP베이스 프로그래밍언어는 굉장히 명시적인 순회가 많고 키워드가 많아 코드가 굉장히 길어진다는 단점이 있음. 대규모 확장성과 간결성으로는 스칼라 및 JVM을 이용하는 것이 퍼포먼스 측면에서도 좋은 선택임.

스칼라는 함수형 프로그래밍으로 굉장히 짧은 코드로 많은 일을 할 수 있음. 그 원래 목적으로 수학적 개념에 가깝게 구현을 하면 동시성이 강하고 Scale-Out이 쉬운 코드를 작성할 수 있음.

Play Framework는 스칼라와 궁합이 제일 나은 프레임워크로써 빠르게 발전하며 웹브라우저로 가능한 기술들을 빠르게 쫓아가고 있는 편임.

향후 데이터분석이나 인메모리를 이용한 실시간 정합성 검사 측면에서도 스칼라가 차지할 수 있는 위상은 꽤나 큰것으로 느껴짐.

 

프로토타입 단계

간단하지만 꼭 필요한 기능들을 구현.

-       DB에 있는 데이터 (Column기반의 NoSQL, 혹은 RDB) 를 현재 사용자가 레포팅하는 형식으로 웹브라우저에 뿌려주며 보통 필요한 기능들 (정렬 등)을 구현할 예정.

-       간단한 프로그램 권한과 유저아이디 관리, 형상관리, 개발관리구현.

-       CRUD프로그램도 웹상에서 구현. 데이터의 Transform 단계에서의 설정마법사 제공.

-       웹소켓등을 이용해 결산작업등이 끝나면 바로 클라이언트단으로 푸시해주며, 실시간으로 작업상황 검토 가능

-       엑셀 레이아웃을 화면으로 드래그 앤 드롭을 하면 바로 레이아웃을 읽어 DB조회를 하는 레포트 프로그램 생성

-       대량의 컴퓨팅 파워가 필요할때는 인메모리기반의 스파크 이용가능 (저가형 병렬 클러스터로 구성)

-       데이터에 대한 이상치 등의 실시간 검사

-       간단한 표현식으로 필드 바꿔치기, 필드 특성 복사하기, 필드값으로 다른 필드값 유추하기를 시각화된 매핑 테이블에서 설정 가능하게끔 함.

-       모든 셀렉션스크린 드래그앤드롭 가능. (마스터화된 셀렉션 필드 저장가능)

-       화면상 그리드에서 표현식을 제공해 엑셀 수작업을 최대한 줄이게끔.

-       SAP상 복사-붙여넣기가 안되거나 데이터 테이블 조회시 다운로드 되는 현상 제거.

 

SDS입장에서의 수익

새로운 플랫폼을 통한 기업B2B 시장에서의 중개자

SAP이 ERP 패키지 하나로 각종 데이터 레포팅 등의 기능도 해당 사의 솔루션으로 흡수했듯이 SDS가 SAP이 신경쓰지 못하는 괴랄한 UX와 개발도구의 불편함, 그리고 수많은 보일러플레이트 코드를 제거하고 간단하게 웹브라우저로 기본 기능을 제공하므로써 플랫폼의 이점을 가져갈 수 있다.

또한 해당 기본기능들을 오픈소스화 하여 Github에서 확인된 사람에 한해 Contributor로 활동할수 있게 하여 계속적인 업데이트로 트렌드를 따라갈 수 있게 해주며 SDS는 그 중간에서 마켓플레이스와 검증된 마켓플레이스용 모듈과 클라우드 컴퓨팅 서비스를 제공하면서 수수료와 수익을 얻을 수 있으며, 필요한 정제된 데이터 등에 대해서도 거래가 가능하도록 확장 가능함. 필요하다면 해당 모듈에대한 커스터마이징에 대한 요청도 받을 수 있도록 도와줌.

 

유지보수에 대한 책임강화 및 즉시성, 단순SI로부터의 탈피

판매되는 모듈 및 커스터마이징 책임 여부가 확실하므로 오너십을 가지고 개별 프로그램들이 운영될 뿐만 아니라, 개개인이 노하우를 가지고 자신만의 프로그램을 공유할 수 있음. SI의 고질적인 병폐는 책임유무에 따른 프로젝트 실패, 그리고 동기부여가 개발자에게 충분히 안되는 문제가 있는데 이를 해결해줄것으로 보임. 사용자 입장에서는 새로운 시스템을 도입하기 위해 갖가지 PoC나 하드웨어 구입은 하지 않아도 되며 마켓플레이스에 존재하는 프로그램이나 프로세스에 대한 Trial을 클라우드에서 제공하는 것을 이용하면 됨.

 

기존 ABAP상에서 반복적으로 생산해 왔던 코드 제거

기존에 당연히 제공되어야 할 기능을 수동으로 코딩을 하느라 많은 효율성의 낭비가 있었음. Period Lock체크, 프로그램에 대한 세부권한체크, 사용자에게 보여주는 ALV의 세팅, 타임스탬프 관리, 데이터의 정합성 검토 및 자릿수 체크등의 코드를 일일히 작성하느라 코드가 굉장히 길어지고 버그가 양산되는 경향이 있음. 또한 Activate을 통하여 컴파일 에러를 확인하여야 하는데, 이러한 점은 IDE에서 자동적으로 미리미리 파악하여 컴파일이 되지 않음을 미리 알려줘야함. 또한, 사용하지 않는 메서드라든지 변수등이 미리 감지가 불가능하기 때문에 결국 숙련되지 않은 소수를 제외하고는 더러운 코드가 양산됨. 이러한 반복적인 코딩은 죄다 간단한 드래그 앤 드랍 세팅과 직관적인 UI로 커버가 가능함. 현재 부서에서 ALV 대용으로 세팅을 통해서 화면을 조작하는 진일보된 방식으로 개발이 되고 있는데 이를 확장해서 전 개발 분야에서 공통적인 부분은 추상화를 하고 간단한 설정을 통해서 핵심만 개발할수 있도록 도와주어야 함.

 

레포팅 시 고질적인 기본 문제 해결

SAP ERP기반의 ALV프로그램은 당시에는 엑셀을 어느정도 따라간 좋은 기능이였을지는 몰라도 현 상황에서는 문제가 많은 방법이다. ALV는 다음과 같은 문제점이 있다. 스크롤시 로딩이 안되어서 GUI가 다운되버리는 문제라든지, 간단한 복사 붙여넣기도 스크롤을 내려 데이터를 로딩하지 않으면 정상적으로 작동하지 않는 문제, 대용량 데이터 엑셀 다운로드 시 선형시간보다 훨씬 많은 시간이 걸린다든지 하는 문제가 있다. 이와 별개로 현재의 웹브라우저에서 백만건 이상 테이블 조회 결과를 뿌려주더라도 아무런 성능상의 제약이 없을 뿐더러 Lazy Loading방식도 구현 가능함.