PROJECT 소개
SCP(SAP Cloud Platform) 환경에서 실제 기업 주문 기반 구매 & 판매를 관리하는 Hub Application 제작
투입인원 : 5명 주요업무 •
SAP GUI SCP Web Application 데이터 연동을 위한 API 개발
SCP Web Application 데이터 연동을 위한 API 개발•
ABAP을 사용한 SAP GUI 내부 function 제작
•
HTML5 를 사용한 Web Application 제작
•
tableau를 사용한 dashboard 제작
스킬 및 사용툴HTML5 css3 SCP tableau ABAP SAP GUI
교육 과정
1.
전 과정 이해 → 클라우드 개요 → 프로젝트 과제의 이해 → SAP 프로젝트 방법론 → SCP(SAP Cloud Platform)
2.
SAP Moudle의 이해 (SD, MM)
3.
고객관리 시스템 → 구매관리 시스템 → SAP ABAP 언어 → Fiori → HTML5 & UI5 → Tableau
4.
구현 프로젝트 → 통합 테스트 → 완료 보고 및 시연
프로젝트 수행
1. 개발계획 수립
2. 요구사항 정의
3. UI & Function 설계
4. Master Data 생성
5. UI 개발
6. 통합 테스트 및 최종수정
단위 프로세스 설계
WorkFlow 설계 - Owner
WorkFlow 설계 - Customer, Shipping
기본 보기
Search
기본 보기
Search
Table 정의서 - 고객정보 Table
Table 정의서 - 제품가격정보 Table
Project 결과
1. LaunchPad
Fiori 런치패드 상에서 해당하는 Application을 카탈로그 형식으로 접근할 수 있도록 설정하였다.
Autorization 과정에서 부여한 Role에 따라 보이는 접근할 수 있는 Application이 다르다.
2. SCP Application
각 Function의 구현을 담당하는 Application의 내부 모습
수정 버튼 클릭 시 변경요청 화면으로 이동
이름, 국가, 도시, 상세주소, 우편번호, 요청사항 input 활성화
변경을 원하는 정보 입력 후 변경요청 버튼 클릭 시 “요청하였습니다.” 메시지 출력
고객정보, 제품가격, 운송정보에 대한 요청 변경사항 리스트를 조회
이력 조회 버튼 클릭 시, 과거 모든 요청 변경사항 내역 리스트를 조회
Refresh 버튼 클릭 시 업데이트
고객 이력 버튼 클릭 시 해당 화면으로 이동
전체 고객의 변경요청사항 리스트
고객번호, 고객이름, 상태 중 하나를 클릭 시 승인 및 거절 화면으로 이동
고객이 요청한 변경요청 정보를 조회
거절사유 input 활성화
승인 시 승인 버튼을 클릭하면 고객이 요청한 정보로 데이터 수정
거절 시 거절 버튼을 클릭하면 고객에게 거절사유 메시지 전달
Challenge
제품의 가격을 변경한 후에 그것을 다시 확인할 수 없다는 사실을 깨달았다. 당시 프로젝트 목적으로 사용할 수 있었던 DB테이블은 제품의 정보가 담긴 마스터 테이블밖에 없었고. 그래서 한번 정보가 수정되고 난 후에는 이전 가격을 확인하는 등의 제품 정보 변경의 이력을 관리하는 것이 불가능했다. 구매/판매를 관리하는 어플리케이션에서 변경/취소의 이력관리를 할 수 없다는 것은 실제 사용자의 관점에서 너무나도 불편한 반 쪽짜리 어플리케이션이라고 생각했고, 해당 기능을 추가하기로 결심했다.
처음에 생각했던 방법은 제품의 변경 이력이 발생할 때마다 테이블에 제품-변경(날짜) 형태로 새로운 데이터를 집어넣는 것이었습니다. 하지만 테스트를 진행할 수록 테이블에 쓰레기 데이터가 쌓이고, 다른 조에서 구현하려고 했던 이름 검색을 통한 필터링에서 제가 작성한 불필요한 데이터까지 보여지는 문제가 있었다. 또한 SAP 프로그래밍에 대해 배운지 얼마 안되어 단기간 내에 외부 DB에서 정보를 끌어오는 것도 구현하기 어려웠다.
다음으로 시도한 방법은 기존 테이블의 비어있는 행을 이용하여 그곳에 이력정보를 담는 것이었다. 처음엔 특정 문자를 기준으로 슬라이싱 하면 가능할 것이라고 생각했지만 들어갈 문자의 길이도 제각각 이고, 형태도 달라 구현하는데 어려움이 있었다.
최종적으로 구현한 방식은 보이지 않는 앱을 이용한 속임수 방식이었다. 완성품 어플리케이션에서는 보이지 않는 화면이지만 동일 서버에 또 다른 어플리케이션을 추가하고, 그곳에 리스트를 만들어 변경 이력이 있을 때마다 기록하여 DB처럼 활용하는 방법이었다. 실제 DB가 아니었기 때문에 Key값을 고려할 필요도 없었고 보여지는 용도가 아니었기 때문에 최대한 작은 사이즈로 리스트를 만들어 데이터를 많이 담을 수 있었다.
프로젝트에서 요구하지 않은 부분을 개선하려고 시도했기에 중간에 어려움이 있었지만 결국 원하는 원하는 방향으로 사용자가 만족할 수 있을만한 어플리케이션을 개발하는 성과를 이룰 수 있었다. 비록 정석적인 방법으로 구현한 것은 아니지만, 문제를 해결하기 위해 여러 가지 방법을 고민하며 그 과정에서 많은 것을 배울 수 있었고, 끈기 있게 도전하여 결국 목표를 달성하여 기억에 남는 경험이었던 것 같다.
배운점, 좋았던 점
실제 업무 프로세스의 체험
학부생 수준의 단순한 기능 구현의 어플리케이션과 다른 실제 기업에서 고객, 제품에 대한 정보를 어떤 방식으로 관리하고, Data를 처리하는지에 대한 것과 기업활동에서 가장 기본이라고 할 수 있는 구매, 판매에 관련된 프로세스를 직접 구현해보면서 해당 프로세스를 더욱 자세히 이해할 수 있는 기회였다.
주먹구구식 개발이 아닌, 단위 프로세스 설계, WorkFlow 설계에서부터 요구사항을 정의하고 하는 일련의 과정을 통해 계획적이고 체계적인 프로젝트 진행을 할 수 있었다.
다양한 지식 습득
컴퓨터공학을 전공하면서 기존에 C/C++, Python, Java, OpenGL 등 다양한 언어를 배우고, VS, Eclipse, AVR Studio, Android Studio 등 다양한 Tool & FrameWork를 사용하여 Application을 개발하는 경험을 해보았다.
하지만 SAP라는 새로운 분야에서 ABAP이라는 기존에 사용하던 개발 언어와는 전혀 다른 형태로 동작하는 새로운 언어에 대해서 배울 수 있었고, SCP라는 Cloud Platform 환경에서의 Application 개발을 체험해 볼 수 있었다.
또한, 각 프로세스를 구현하기 위한 SAP 모듈(SD, MM)과 시각화 툴 등 다양한 분야의 지식을 습득할 수 있었다.
팀워크
프로젝트를 진행하면서 가장 크게 중요성을 느낀 부분이다. 총 5명의 인원이 한 팀이 되어 한 프로젝트를 진행하였다. 당시에 나를 제외한 4명은 컴퓨터 분야 비전공자였고 개발 언어 및 개발 프로젝트 진행에 대한 지식이 없는 상황이었다. 프로젝트 초기에는 문제가 없었지만 SAP 서버에서부터 API 연동, Database 관리, Web UI 제작까지 전체적인 Application 개발을 수행해야 하는 프로젝트의 특성상 역할 분담과 지식에 차이 등에서 발생하는 프로젝트 지연이 일정에 차질을 가져오는 상황이 발생하였다. 당시 나는 Web Application 개발자와 ABAP 개발자 역할을 맡고 있었지만 유일한 컴퓨터공학 전공자로서 PM 역할도 수행하고 있었다.
PM으로서 문제를 해결하기 위한 방법으로 고안한 것은 스터디 진행이었다. 스터디를 진행하면서 느낀 점은 개개인의 개발 능력보다는 의사소통의 어려움으로 발생하는 문제가 더욱 크다는 것이었다. 프로젝트 초기에는 개발 지식이 없는 상태에서 전체적인 프로세스를 이해하려고 한다면 엄청난 시간이 소모되고, 난이도도 높을 것이라는 생각에 역할분담을 우선 수행하고 해당 분야의 지식만 우선적으로 습득하여 개발하는것을 목표로 세웠다.
하지만 전체적인 프로세스를 이해하지 못하고, 본인이 맡은 기능만 구현하려고 하였을 때 상대방이 구현하고 있는 기능과 어떻게 연결되는지 등에 대한 지식이 없어서 그것을 조율하는데 많은 시간이 소모되었었다. UI 부분 개발도 SAP 프로그램 기능에 종속적이었기 때문에 SAP 프로그램 기능 동작을 제대로 이해하고 있어야 구현할 수 있었으며, 웹 어플리케이션 제작 부분도 UI 부분이 어떻게 설계했는지에 따라 기능 구현 방식이 완전히 달라졌다.
스터디를 통해 서로가 생각했던 본인의 부분이 상대방에게 어떤 영향을 미치는지 알고, 상대방이 하고 있던 영역에 대해서도 알게 되면서 의견조율을 통해 전체 프로젝트를 잘 설계하게 되었다. 덕분에 제시간에 프로젝트를 마무리 할 수 있었다.
아쉬운 점
업무 프로세스에 대한 지식 부족
교육 초창기에 SAP ERP 및 SD, MM 등 Module에 대한 교육을 진행하였다. 나는 SAP에 관심을 가지고 들어오기보다는 Cloud에 관심을 가지고 들어온 경우여서 ERP에 대한 부분을 집중적으로 공부하지 않았다. 기존 HTML을 사용하여 Web Application을 제작해본 경험도 있었고 ABAP 언어를 배울 때에도 동작 방식은 기존에 내가 알고있던 언어들과 많이 달랐지만 여러가지 언어를 사용해본 경험이 있어 어렵지 않게 배울 수 있어서 프로젝트를 진행하는데 문제가 없을 거라고 생각했다.
하지만 실제 개발 프로젝트가 진행되면서 ERP에 대한 지식 부재는 생각보다 큰 어려움을 가져왔다. SAP 서버에서 Data를 가져오는 API를 개발해야 하는데 아무리 코드를 잘 작성할 수 있다 하더라도 해당 Data가 어떤 과정을 통해 ERP에서 외부로 나가는지에 대한 프로세스를 이해하지 못하는 상황에서 제대로 된 데이터를 추출하는데에 대한 어려움이 존재했고, 이것 이외에도 여러 난관에 봉착했다.
이를 통해서 실제 개발 과정에서는 단순한 언어 사용 능력 뿐만이 아니라 수행하는 업무를 제대로 이해하는 것이 엄청 중요하다는 것을 깨달았다.
팀워크
배운점 및 좋았던 점에서 이미 기술한 내용이지만 사실 그 과정이 그렇게 순탄하지만은 않았다. 프로젝트를 진행하는것도 힘든 상황에서 스터디를 진행하기 위해 팀원들과 일정을 조율하는 것도 굉장히 어려운 일이었고, 각자 맡은 역할의 어려움을 설득하고, 상대방과 서로의 기능 요구사항의 합의점을 찾는 것도 무척 어려웠다.
처음 프로젝트를 시작하면서 제품정보 이력관리 기능 추가구현 이외에도 다른 여러가지 기능들을 구현하려는 계획을 세웠었다. 하지만 프로젝트 중후반이 되어서야 제대로 된 한 팀이 되어서 프로젝트를 진행하였고, 그 과정에서 발생한 시간지연 등 여러가지 문제로 처음 계획을 전부 수행할 수는 없었다.
처음에 가졌던 '나는 그래도 개발 프로젝트 경험이 있으니까 내가 다른 사람들을 도우면서 프로젝트를 제대로 이끌 수 있을거야'라는 생각이 오만한 생각이었다는 것을 느꼈다. 한사람의 능력이 다른 사람보다 뛰어나다고 하더라도 톱니바퀴처럼 맞물려서 돌아가야하는 팀프로젝트에서 모든 팀원들의 조화가 이루어지지 않고 한사람이 이끌려 한다면 결국에 삐걱거리기 마련인 것 같다.
PM으로서 처음부터 팀원들 사이의 커뮤니케이션을 원할하게 만들고 팀워크를 발휘할 수 있도록 하였다면 훨씬 더 높은 수준의 결과물을 만들 수 있었을 것이라는 아쉬움이 남는다. 다시 한번 팀 프로젝트에서 팀워크의 중요성을 깨닫고 1+1 = 2가 아닌 10, 100이 될 수도 있다는 것을 깨닫는 기회였다.
