CONTENTS

• 목록

[4월  KSUG 패널 토크 : 핵심 포인트만 보기!]

2024년 4월 12일(금)에 진행된 제 38회 KSUG 패널 토크, “성공적인 S/4HANA 구축 및 마이그레이션 사례 연구”세션이 성료 되었습니다!

올해 들어서 더 많은 기업들이 S/4HANA 구축에 나서고 있습니다. 그러다보니 시장에서 전문 인력들의 부족 현상도 지속되고 있습니다.
이럴 때일수록 주도면밀한 계획을 세워야 적은 비용으로 성공적인 프로젝트를 운영할 수 있다고 많은 경험자들이 강조하고 있습니다.  

이번 달 패널 토론회에서는 해운/물류 산업에서의 구축 사례, 효과적인 S/4 마이그레이션 사례, 성공적인 BTP 활용 사례로 가장 최근에 다양한 프로젝트를 지원했던 전문가들을 모시고 참신한 인사이트를 제공해 드릴 수 있는 시간이였습니다!

<Session 1. 발표>

[Deloitte] - 해운 SAP 도입을 위한 Key Success Factor
산업 별 SAP 도입을 가끔 소개해 드리는데 오늘은 해운업에서의 SAP 도입 사례를 중심으로 설명해 주셨습니다. 업의 특성 상 영업지원 업무의 프론트엔드 시스템을 구축하고 회계 데이터 생성하는 분개엔진까지 SAP 앞면에 구축하는 것이 독특했습니다. 특히, 수익성 분석은 매우 유용할 것 같습니다. E2E 기반 구축과 함께 타 산업에서도 참조할 수 있을 것 같습니다.

[FPT Software] - FPT와 함께하는 성공적인 SAP BTP 프로젝트

KSUG 후원사 중에서 본사가 베트남 기업인 FPT가 2번째로 패널토의에 참석하셨는데요. FPT가 규모가 크면서도 글로벌하게 운영되고 있어서 놀라셨을겁니다. 한국에서도 규모가 점점 확대되고 있는 것 같습니다. 글로벌하게 운영되고 있기 때문에 글로벌 사례와 BTP 경험이 많아서 한국 기업들에게도 많은 도움이 될 것으로 기대됩니다.

[TGSOFT] - S/4HANA 전환을 준비하면서 고려해야 할 고도화 내용

지방에 있는 혁신도시의 기업들의 많은 구축과 운영 경험을 가지고 있는 티지소프트도 어느덧 KSUG 후원사 2년 차가 되면서 2번째 참석해 주셨습니다. 특히 경험이 출중한 분들을 지속 영입하여 더욱 강력해지는 티지소프트인것 같습니다. S/4HANA 고도화 성공 요소로 프로세스 자산화와 UI/UX 웹 전환도 좋은 인사이트로 생각되어 집니다. 
 

뿐만 아니라 여러분들의 사전 및 실시간 질문에 대한 전문가들의 답변을 실시간 생생한 내용으로 들을 수 있었습니다. 전문가들의 답변, 지금 바로 확인해 보세요! 

<Session 2. 패널 토의 및 실시간 Q&A>

1) FPT와 TGSOFT는 금번 패널 토의가 2번째 참석이지만, 많은 분들이 아직도 궁금해 하는 부분이 있는 것 같습니다. 그래서 일단 편안하게 회사 소개 및 강점을 간단히 소개해 주세요. 

(FPT) 네 감사합니다. 다시 한번 저희 회사 이름 기억해 주세요. FPT, Financing & Promoting Technology입니다. 글로벌 본사는 아까 회장님께서 말씀해 주셨듯이 FPT Corporation이고 베트남에 있습니다. 전 세계 22,000명의 개발자를 보유하고 있고요. 1,500명 이상의 SAP관련 전문가들을 보유하고 있습니다. 그리고 주요 거래처로는 약 20여 개의 이름만 들어도 아시는 L사, S사, C사, D사 등이 있고요. 최근 거래까지 추가를 하게 되면 중소기업 또 뭐 중견기업까지 합치면 이 수는 훨씬 많아지고 있습니다.   

(사회자) 오태정님이 질문을 주셨는데 FPT인력으로 진행하게 되면 언어장벽이나 소통에 장애가 없는지요?

(FPT) 네 가장 많이 받는 질문 중에 하나 인데요. 일단 저희 FPT코리아랑 업무를 하실 때는 한국어로 진행을 하시면 됩니다. 저희는 지금 다양한 롤들이 내부적으로 있는데요. 가장 여러분께서 일선에서 만나 보실 수 있는 롤들이 온사이트 PM 또 브리즈 소프트웨어 엔지니어 그리고 저희 컨설턴트에 해당하는 인터프리터 분들도 계십니다. 그래서 여러분 들이 프로젝트 시작부터 끝까지 모든 단계에서 미팅이나 문서 이런 내용들은 모두 한국어로 가능하시기 때문에 언어장벽을 느끼실 틈은 없다고 생각을 하는데요. 그럼에도 불구하고 여전히 존재하는 커뮤니케이션 갭들을 줄이기 위해서 저희 내부적으로도 많은 툴들을 개발하고 프로세스도 개선 중에 있습니다.  

(TGSOFT) 아까 회장님께서도 좋은 말씀 많이 해 주셨는데요. 저희 TGSOFT는 나산 혁신도시에서 발전사에 대한 유지보수 사업 부분들을 스타트를 해서 그렇게 만들어진 안정된 인력풀을 바탕으로 지금 서울에 사무소를 개원해 가지고 여러 고도화 작업이라든지 ERP 컨버젼에 대한 여러 업무들을 수행하고 있고요. 최근에는 뭐 S사라든지 H사 등등과 여러 기술적인 부분들로 인해서 저희가 좋은 협력관계를 갖고 있습니다.  

2) 오늘 S/4 HANA 라는 공통적인 주제는 있지만 내용이 조금씩 다르게 진행이 되고 있거든요. 그래서 해운업 구축, BTP 성공적 활용 및 S/4 HANA 전환 시 고도화 추진 등 주제가 조금씩 다르지만 S/4HANA 도입을 기반으로 하고 있습니다. 그렇다면 기존 ECC 대비 S/4HANA로 구축 시 핵심적으로 좋아지는 점과 주 변화 사항은 무엇인가요?

(Deloitte) 먼저 SAP 데이터 활용 측면에서 가장 중요한 부분은 임베디드 에널리틱스라고 생각을 하고 있습니다. 그게 왜냐하면 제가 SAP데이터 활용하고 분석을 잘 해야 되는데 별도의 분석계 예를 들어 BW라든지 이런 부분을 도입하기 좀 힘들거나 이럴 경우에는 임베디드 에널리틱스에 있는 기본기능을 활용해서 분석계를 좀 가성비 있게 꾸릴 수 있는 체제가 된다고 생각을 하고 있습니다. 

(사회자) 그런 부분들은 컨설턴트의 도움 없이도 가능한가요?

(Deloitte) 일단 기본적으로는 어떤 것을 분석할 것인가? 어떤 것을 내가 데이터를 활용할 것인가? 그리고 분석을 위해서 SAP내에 어떤 필드를 내가 사용할 것인가? 이런 부분들을 정해야 되기 때문에 같이 협업하는 것이 더 좋을 것으로 판단하고 있습니다.  

(TGSOFT) S/4 HANA의 전환에 대해서 초기 부분에 대해서는 단순하게 시스템이 빨라진다는 것만 부각이 되었는데요. S4나 S와 같이 심플이라는 부분들이 요새 화두가 되고 있습니다. 단순히 시스템만 있는 게 아니라 여러 기존에 있는 클라우드에 있는 여러 플랫폼들 에서 S/4 HANA하고 같이 커넥션이 되면서 여러 가지 시너지를 많이 만들어 내고 있고요. 아까처럼 분석툴에 대한 부분들도 있고 여러 업무 자동화에 대한 부분들도 있고 그런 부분에서 좀 더 민첩하게 시장변화에 맞게 대응할 수 있는 좋은 플랫폼인 것 같습니다. 

3) S/4HANA에는 대량 데이타의 신속한 처리, 플랫폼 기반 및 지능화 기능 사용 용이와 같은 장점이 많지만, 기업들은 프로젝트 구축에 많은 자원이 소요 되므로 구축 후 효율적인 사용이 매우 중요합니다. S/4HANA 구축이나 마이그레이션을 위해서 사전에 준비해야 할 사항이나 주요 고려 사항은 무엇인가요? (ITman, hashtag, KSUG, 예스맨, 힘내, ksman, tj1156, 이기정, 양광진)

(Deloitte) 첫 번째는 마이그레이션이 가장 중요한 부분인데 말씀하셨듯이 첫 단추 입니다. 그런데 너무나 당연한 얘기겠지만 마이그레이션을 잘하기 위해서는 마이그레이션 해야 되는 데이터 자체의 볼륨을 줄이는 것이 중요하다고 생각합니다. 예를 들어서 업무협조를 통해서 오픈 오더를 최대한 줄인다든지 또는 ARAP 이런 부분들을 좀 AP라든가 이런 부분들을 미리 줄인다든지 이런 것들도 되게 중요하다고 생각할 수 있고요. 두 번째는 근래에는 CBO프로그램들이 워낙 많기 때문에 CBO프로그램에 대한 설정이라든가 CBO프로그램 데이터 마이그레이션 이 부분들도 놓치지 않고 하셔야 되는 부분이 있습니다. 마지막으로는 워낙 기본이긴 한데 마이그레이션의 기본원칙을 잘 정의하는 것이 중요할 것 같습니다. 첫 번째는 어떤 항목을 선정할 것인가 그리고 누가 할 것인가 누가 데이터 클렌징하고 어떻게 클렌징할 것인가 어떻게 검증을 빨리 할 것인가 어떻게 업로드 잘할 것인가 이런 부분에서 원칙을 명확히 세우고 그리고 명확하게 표로 관리하시는 게 좋을 것 같습니다.

(FPT) 네 앞에서 대부분 좋은 말씀을 많이 해 주셔서요. 저는 기술역량 부분과 비용적인 부분 두 가지로만 나눠서 설명 드리도록 하겠습니다. 기술역량적인 부분에서 구축과 운영에 대해서 필요한 기술력이 먼저 확보돼야 된다는 것은 가장 중요한 내용일 것 같습니다. 아무래도 S/4HANA의 특징을 잘 알고 관련 SAP 기술들에 대한 검증경험을 갖고 어떤 부분이 뭐 커스터마이징이 돼야 되는지 혹은 커스터마이징 되지 않고 S/4HANA에서 활용할 수 있는지에 대한 이해와 기술력을 가지고 있는 그런 업체와 같이 업무를 하는 것이 중요할 것 같고요. 또 비용적인 측면을 고려하는 게 중요할 것 같습니다. 총 비용은 인력비용과 프로젝트 기간에 따라 결정이 되는데요. 이런 인력비용을 가장 줄일 수 있는 방법 중에 하나가 풍부한 경험력을 가진 값싼 인력을 소싱할 수 있는 저희 업체를 선택해 주시는 것도 가장 좋은 방법 중에 하나 일 것 같습니다.   

(TGSOFT) 기존에 모든 큰 프로젝트를 보면은 프로젝트 자산화를 먼저 이룩한 다음에 그 다음에 프로젝트를 진행했습니다. 그런데 지금 요새는 많은 회사들이 이런 부분들을 좀 덜 중요시 해 가지고 진행을 하다 보니까 S/4HANA를 전환을 하고 난 다음에도 많은 어려움이 있고 또 이걸 갖고 어떻게 활용을 해야 될지에 고민들을 많이 하고 있는데요. 다시 초심으로 돌아가서 제가 생각하는 것은 각 업무영역에 비즈니스 프로세스라든지 여러 자산들을 만들어 놓고 거기서 변화관리를 통해서 내가 뭐를 어떻게 해나갈지에 대한 방향성을 갖고 하는 게 좋다는 것을 저희가 몇 년 동안 저희가 저희 회사에서 IS PM을 진행을 하면서 느꼈던 부분들이고요. 이런 경험을 바탕으로 오늘 이 시간을 거쳐서 많은 분들께 그런 좋은 포인트들을 소개시켜 드리기 위해서 오늘 이 자리에 나왔습니다.   

4) 클라우드로 데이터 마이그레이션 이제 중요 데이터의 손실이 없는지? 또한 마이그레이션 시 데이터 일관성 유지가 가능한지? (양광진, 이기정)

(TGSOFT) 지금 이제 S/4HANA에 마이그레이션 할 때는 여러 가지가 있지만 컨버젼을 만약 예를 들어서 말씀을 드리면 컨버젼은 이런 전환할 때 디앰오로라는 툴을 쓰고요 이 디앰오로라는 툴은 여러 데이터들이 이관될 때마다 계속해서 검증을 하게 됩니다. 그렇기 때문에 저희가 여러 프로젝트를 띄웠지만 이 중간에 데이터가 유출되는 경우는 단 한번도 없었습니다. 그리고 질문을 쭉 보다 보니까 대용량의 데이터들이 이관됐을 때 어떻게 하면 속도 클라우드에 특히 어떻게 할까 고민을 많이 하시는데요. SAP는 그것에 대한 많은 옵션들을 갖고 있고요. 뭐 DODMO라든지 시스템무브 라든지 여러 기술적인 방법을 통해 가지고 NDDT를 이용하는 방법들도 있는데요. 그런 프로젝트의 경험이 있는 분들하고 같이 진행을 한다고 하면은 시간에 대한 문제, 용량에 대한 문제점들은 크게 문제 없이 프로젝트를 이루어 갈 수 있다고 생각됩니다.    

(Deloitte) 보안 쪽으로 말씀해 주셔서 저는 데이터 일관성 쪽에서 말씀을 좀 드리겠습니다. 데이터 일관성은 사실 데이터의 종류에 따라서 일관성이 단절된 것도 있고 일관성이 있는 부분들이 있습니다. 예를 들어서 그래서 저희가 그 데이터의 일관성을 위해서는 일단 저희가 통합테스트를 많이 하고 하기 때문에 사전에 정의된 그리고 제약까지 정의된 제약 내에서 어떻게 이 데이터를 잘 활용할 것인가 잘 활용하고 이렇게 마이그레이션을 해 봤더니 잘 활용이 되더라 이런 부분들을 상호 검증하는 작업을 통합테스트 및 여러 테스트에서 검증하는 것이 중요할 것 같습니다.   

5) 기존 ERP를 사용하는 대부분 기업들이 많은 Customizing을 사용하고 있어서 S/4HANA 도입 시 기존 Customizing에 대한 검토가 중요합니다. 이 때 반영 해야 할 내용과 주요 기준은 무엇인가요? 

(Deloitte) 저는 커스터마이징이라고 해서 처음에는 이제 SAP 스탠더드 커스터마이징이라고 생각을 했었는데 그게 아니라 CBO에 대한 부분이군요. 저는 원칙은 명확합니다. 10명이 할 수 있는 일을 1명이 할 수 있다면 업무 효율성 차원에서는 커스터마이징 하는 것이 CBO개발하는 것이 맞다고 생각을 하는데 다만 불필요한 난 개발 이런 부분들은 필요가 없겠죠. 저는 회사에서 정책을 세워서 프로젝트 할 때 “아 이 부분들은 데이터 공유 업무 활용성 그리고 데이터의 같이 활용할 수 있다”는 그 측면에서 요 부분은 반드시 시스템이 해야 된다라는 부분이라면 반드시 해야 된다고 생각하는데요. 일반적으로 저는 QCDR관점에서 접근하고 있습니다. 퀄리티, 스피드, 리스크 이런 부분들을 감소시키는 방법, 증가시키는 방법, 좋은 부분을 증가 시키는 방법 이런 면에서 CBO개발이 돼야 된다고 생각을 하고 있습니다.  

(FPT) 저는 앞에서 말씀해 주신 내용과 좀 인라인 되는 내용인데요. 가장 중요한 게 이제 기존에 커스터마이징을 했었던 기능들이 S/4HANA의 기존에 있는 기능인지를 확인을 하시고 S/4HANA에 있다 라면은 그 것을 활용해서 쓸 수 있도록 방안을 만드셔야 되고 없는 기능이다 라고 하실 때는 그 것에 대해서 어떻게 프로세스를 정립을 해서 마이그레이션을 통해서 커스터마이징이 필요한 내용들을 관리를 할지에 대해서 내부적으로 논의를 하고 그것에 대한 내용들을 각 그 스테이크 홀더들하고 온라인에서 정의하는 게 가장 중요할 것 같은 요인이라고 생각합니다. 

(TGSOFT) 아까도 제가 자꾸만 이제 프로젝트 자산에 대해서 말씀을 드리는데요. 저희가 CBO에 관련된 가장 큰 변화에 대한 부분들은 이 프로젝트가 과연 향후에 지금까지 운영하면서 더 나은 프로세스로 발전할 수 있는가에 대한 변화관리에 대한 부분으로 접근을 해봐야 될 필요가 있다고 생각을 하고요. 그러기 위해서는 기존에 있던 업무 프로세스에 대한 정확한 구분이 돼야 되고 그게 어떤 식으로 발전할 수 있고 S/4HANA에서는 어떤 식으로 변화돼서 좀 더 향상된 기능으로 서비스를 할 수 있을까에 대한 고민을 해야 되고요. 그렇게 함으로 인해서 표준기능들을 최대한 활용하는 방법도 있고, CBO에 대한 부분들 특히 이제 외부로 빠지는 경험들 같은 경우에는 이것 부분들을 향후에 어떻게 유지보수 할 수 있는 단계까지 고민을 해 본다고 한다면은 그런 커스터마이징에 대한 여러 난관들은 차근차근 풀어나갈 수 있다고 생각됩니다.   

6) 외부 환경 변화에 대응을 신속하게 할 수 있는 유연한 ERP 시스템 구축이 가능한지요? 

(Deloitte) 일단은 항목마다 약간 다를 수 있을 것 같습니다. 그런데 기본적으로 크게 시스템 RNR관점에서 좀 말씀을 드리겠습니다. 외부환경에 적극적으로 플렉시블하게 대응할 수 있고 그리고 하다가 안 맞으면 버리고 새로 개발하고 예를 들어서 새로 도입하고 이런 부분들은 엄밀히 말하면 프론트엔드 시스템의 주요 특징이라고 할 수 있겠습니다. SAP는 기간시스템이고 ERP이기 때문에 전사데이터를 같이 표준화시켜서 잘 활용하고 데이터를 견고히 관리하는데 좀 더 적합한 시스템이라고 생각을 하고 있습니다. 그래서 시스템 RNR을 나눠서 프론트엔드 단이 해야 될 부분은 프론트엔드 단에서 SAP가 해야 될 부분은 SAP에서 이렇게 좀 구분을 해서 하면은 좀 좋지 않을까 생각하고 SAP가 데이터를 유연하게 가져간다라는 의미는 표준화된 프로트엔드 시스템에서 생성된 표준화된 데이터를 SAP에서 받아들여서 이걸 어떻게 잘 활용할 수 있는가 이 부분에 좀 더 중점을 둬야 된다고 생각을 하고 있습니다. 

(FPT) 외부환경 변화에 빠르게 적용한다는 항목에 대해서는 제가 또 저희 회사랑 연관 지어서 설명을 드릴 수 밖에 없을 것 같은데요. 아무래도 신기술도 많이 연관이 되어 있고 또 통합환경을 요구하는 S/4HANA에 대해서 고객 분들이 이런 것들을 구축할 경우에 이것에 대한 경험이 많은 또 업체를 선정을 하셔야 되고 또 이 것에 대한 경험을 기반으로 컨설팅을 받으셔서 어떤 항목들이 여러 분들 고객사들의 환경에 가장 잘 맞는지에 대한 고민을 충분히 하신 다음에 그런 다음에 거기에서 필요한 내용들을 아까 말씀해 주신 스탠다드 기능이라면 바로 적용을 해서 사용을 하시고 또 구현이 필요하다 라면 또 역시 그것도 고민을 하셔서 프로젝트를 진행하셔야 지만 그런 변화되는 비즈니스 환경에서 고객들이 경쟁우위를 취할 수 있다고 생각을 합니다.     

(TGSOFT) S/4HANA에 가면서 가장 크게 걸림돌이 되는 것 중에 하나가 웹에 대한 환경들입니다. 기존의 SAP에 Web Gui가 아닌 SAP Gui가 아닌 웹 환경에 대해서는 지원이 별로 없어서 다 CBO로 개발이 됐는데 SAP가 점점 더 Fiori라는 부분들을 많이 확대하고 나서부터는 기존에 SAP프로세스하고 Fiori프로세스를 같이 쓰기에는 굉장히 어려운 부분들이 많이 있거든요. 그래서 저희는 그런 부분을 좀 해결하기 위해서 H사 같은 경우는 저희가 Fiori를 위한 개발 구축방법론에 대한 부분들도 틀을 만들어서 지금 같이 협업하고 있는데요. 그렇게 업무적으로 이미 바뀐 화면들 예전에 SAP Gui에서 웹 형태로 바뀐 부분들을 빠르게 대체를 하고 아까 회장님께서 말씀하셨듯이 BTP서비스를 활용해 가지고 바뀐 유저환경에 맞게 빨리 개선돼야 될 필요가 있다고 생각이 됩니다.   

7) 해운업 지체가 독특한 프로세스도 많고 복잡한 Indusry라 생각되는데, 이러한 비지니스를 모두 커버할 수 있는지요? 또 해운업에서는 굳이 SCM을 사용하지 않고 FCM만 사용을 했는데 이게 가능할 수 있었는지? 

(Deloitte) 네 먼저 왜 해운업에서 FCM만 사용하는지 먼저 말씀을 드리겠습니다. 아까 말씀하셨듯이 이 시스템을 도입할 때는 시스템 목적 자체를 정확하게 정의해야 됩니다. 해운업에서 SAP는 회계데이터 기장이라든가 회계데이터 생성도 있고 재무재표 생성도 있지만 분석을 위한 베이스 데이터를 생성하는 것도 상당히 중요한 항목입니다. 특히 회원사는 글로벌사 로서 해외 지사들을 많이 가지고 있습니다. 그렇기 때문에 글로벌 경영플랫폼으로도 많이 사용해야 되는데요. 먼저 해운업에서는 SAP에서는 회계데이터를 주로 생성한다고 말씀 드렸는데요. 영업 단에서 프론트엔드 시스템 단에서는 주로 구매 오더, 영업 세일즈 오더, 빌딩 뭐 이런 부분들을 하는데 만약 SAP에서 그런 부분들을 동일하게 만들게 된다면 데이터의 중복이 되게 됩니다. 시스템 기능상의 중복이고 데이터의 중복이 있고요. 그리고 그 데이터를 정합성을 검증하는 것 조차 어떻게 보면 비효율하고 낭비입니다. 그래서 시스템의 목적을 명확히 해서 영업시스템에서는 프론트엔드 단의 일을 정말 잘하고 SAP에서는 회계기장과 분석데이터를 잘 생성해야 하는 것 이렇게 주로 나눠서 일을 처리를 하고 있습니다.  

8) 해운업 ERP 구축 시 가장 신경 써야 하는 항목과 Risk가 가장 큰 사항은 무엇인가요? 

(Deloitte) 첫 번째는 해운업 업무의 특성은 프론트엔드 단에서 업무를 처리하고 그 데이터를 기반으로 SAP에서 또 다른 데이터를 생성해 내는 즉 시스템간의 엔드투엔드 관점에서 뭔가 협업이 이루어져야 됩니다. 즉 시스템간의 협업, 개발의 협업 그리고 인터페이스 테스트에 대한 협업이 잘 되어야 되고요. 그리고 두 번째는 더 중요한 부분인데요. 부서간의 협업입니다. 예를 들어서 SAP에서는 어떤 데이터를 활용하고 싶은데 프론트엔드 단에서 그 데이터를 입력하거나 하지 않으면은 문제가 될 수 있습니다. 그래서 부서간에 서로 협업을 통해서 내가 원하는 데이터를 전사적으로 원하는 데이터를 정의하고 그 데이터를 잘 연계해서 SAP에서 잘 활용하게 하는 것 이 부분이 중요한데 이런 협업이 잘 안되면 문제가 되게 됩니다. 해운업에서는 가장 중요한 게 시스템간의 협업 부서간의 협업 그리고 인터페이스라고 생각을 하고 있습니다.  

9) 해운사의 경우 SAP의 FCM 데이터 중 분석 데이터 활용이 중요한 것 같은데, 이를 위해서 BW와 SAC를 반드시 도입해야 하는지? 또한 해운업 에서 분석계 도입 시 중요한 점은?

(Deloitte) 먼저 저는 분석계 도입이 필요하고 괜찮은 좋은 항목이라고 생각을 합니다. 그런데 다만 분석계 도입할 때 너무 크게 도입하시는 것보다 예전의 방법을 사용해서 작게 도입하시는 게 좋은데 결국 가성비라고 생각합니다. 아까 임베디드 애널리틱스라고 말씀을 드렸는데 SAP에는 내장되어 있는 무료로 쓸 수 있거든요. 그래서 임베디드 애널리틱스를 사용해서 좀 우리회사에 맞는 그리고 써보니 이런 것도 좋더라 향후 확장할 때 어떻게 하면 좋더라 라는 부분들에서 경험을 쌓으신 다음에 요즘 크게 BW도입 하신다거나 하는 부분이 좋을 것 같습니다. 그리고 중요한 부분은 분석계를 도입하실 때 너무 그래픽 위주로 화려한 거 위주로 많이 도입하시는데요. 크게 두 가지 영향이 있다고 생각을 합니다. 경영자 분 들이 좋아하시는 것 그리고 보셔야 되는 부분들 EIS겠죠. 그리고 실무자 분들이 실제 내가 데이터를 만들어내기 위해서 분석을 하기 위해서 쓰시는 부분이 있는데요. 실무자가 사용하지 않는 분석계 시스템은 경영자도 사용하지 않습니다. 왜냐 하면 실무자가 만들어낸 데이터의 의미를 경영자들도 알고 싶어 하시기 때문에 실무자가 먼저 쓸 수 있는 시스템 그 것부터 먼저 중점을 둬서 도입을 해야 된다고 생각하고 있습니다.     

10) FPT는 글로벌하게 운영을 하고 있는데, BTP 구축 경험 있는 나라는 어디이며 FPT가 성공적으로 제공한 SAP BTP 프로젝트 수는? 또한 BTP 프로젝트 구현 시 주요 과제 내용은?

(FPT) 일단 세가지로 질문을 제가 압축할 수 있을 것 같은데요. 첫 번째 FPT 는 당연히 베트남, 일본, 한국, 유럽, 미국 국가에서 BTP를 수행한 경험이 있습니다. 그리고 저희 FPT소프트웨어가 글로벌리 18개의 SAP BTP 프로젝트를 수행했고, 지금 한국에서도 대기업 S사와 또 L사와 함께 SAP BTP를 수행 하고 있습니다. 그리고 두 번째, 세 번째 질문일 것 같은데요. BTP 프로젝트를 수행하는 동안 직면한 주요 과제로 이해를 했는데요. 저는 이것을 두 가지로 좀 나눠볼 수 있을 것 같습니다. 기술적인 부분을 먼저 좀 살펴 볼 수 있을 것 같은데요. 아무래도 복잡한 통합요구 사항들에 대해서 다양한 이종간의 시스템들의 데이터 통합이 가장 어려운 항목 중에 하나 일 것 같습니다. 각 시스템들의 데이터 표준을 정의하고 API에 대한 표준도 정의를 하고 또 필요에 따라서 통합 플랫폼을 미들웨어 뭐 이런 것들을 사용해서 데이터 통합을 최대한 단순히 하는 게 가장 중요한 기술적 핵심사항일 것 같습니다. 이에 대한 이해를 바탕으로 데이터 변환 맵핑 작업들을 하면서 자동화를 시켜 나가는 게 좀 중요할 거 같고요. 기술적인 부분 외에 또 핵심적인 항목으로는 조직 내에 변화관리일 것 같습니다. 아까 전무님께서도 말씀을 해 주셨듯이 새로운 기술이 도입이 되고 나면 조직 내에서는 사용자들이 학습을 해야 되고, 또 조정된 프로세스를 받아들여야 되는데 이런 것들은 다 프로세스와 또 조직 내에 변화관리를 통해서 가능할 것 같습니다. 또 이를 위해서는 이제 연관된 스테이크홀더 들과 함께 이런 내용들을 얘기를 하고 조직 내 피드백들을 관리해서 잘 관리를 해야 될 것 같습니다.           

11) 그렇다면, FPT가 전 세계적으로 보유하고 있는 SAP 자원 규모와 한국에서의 FPT 규모와 상세 내역이 어떻게 되나요?

(FPT) FPT는 현재 전 세계적으로 1,500명 정도의 SAP 전문인력을 보유하고 있습니다. 물론 이들은 950개 이상의 인증 받은 SAP 공인 인증서를 또 가지고도 있고요. 또 SAP리소스 중 대부분 70%정도가 베트남에 계신데요. 그리고 한국에서는 한국의 FPT에서 SAP관련된 한국어를 담당하는 직원들은 한국인이 저를 포함해서 한60명 정도 되시고 오프쇼어로는 한국어 가능자가 80명 정도 돼서 통 140여명의 리소스를 가지고 저희는 SAP BTP를 지원하고 있습니다.  

12) 프로젝트 추진 시 커뮤니케이션은 당연히 한국어로 한다고 했는데요. 그러면 문서나 산출믈도 당연히 한국어로 진행 되는지요? 

(FPT) 네 처음에 PPT, 아까 제가 소개할 때 말씀 드렸듯이 처음부터 끝까지 저희랑 프로젝트 이야기를 하실 때 한국어로만 하시면 됩니다. 물론 영어랑 베트남어를 원하시면 그 것도 가능하죠. 그리고 프로젝트 구성인원을 다시 한번 설명 드리면 온사이트 PM에 해당하는 한국인 그리고 브릿지 엔지니어라고 한국인 BM 고객사 베트남인 이 세 개를 연결해 주는 엔지니어가 있고요. 또 SAP개발인력은 한국어 가능인력으로 저희가 구성을 해서 운영을 하고 있습니다. 그럼에도 불구하고 또 전문적인 통역이 필요하다면 그 것 역시도 추가가 가능합니다.   

13) S/4HANA 구축 시 발생할 수 있는 이슈와 이를 해결하는 TG소프트 노하우와 차별점은 무엇인가요?

(TGSOFT) 네 그 컨버젼을 진행하면서 발생할 수 있는 이슈들을 크게 세가지로 나눌 수가 있습니다. 첫 번째가 데이터에 대한 이슈가 있을 수가 있고요. 시간에 대한 이슈 그 다음에 안정화에 대한 이슈가 나올 수가 있습니다. 먼저 데이터에 대한 이슈같은 경우는 우리가 과연 기존에 있던 많은 양의 데이터들을 다 옮겨야 되는지 아니면 일부만 옮겨도 되는지에 대한 고민들을 하는데요. 기본적으로 상법은 10년 그 다음에 회게법은 5년의 데이터를 가지고 가야 되는데 그렇게 크게 이 부분들이 EIS나 그렇게 분석하지 않는다고 하면은 마이그레이션을 통해 가지고 데이터를 마이그레이션 팀에 내려 놓고 나머지 부분만 옮길 수 있는 방법이라든지 아니면 다 필요하다고 하면 이 부분들을 저희가 업타임에도 그러니까 실제 운영시간에도 미리 어느 정도 일부분을 옮겨 놓고 이 부분들을 진행 할 수 있는 그런 기술적인 해결할 방안들이 있고요. 또 저희회사는 그런 것에 여러 라이센스가 있는 친구들이 있기 때문에 그런 부분에 충분히 도움을 드릴 수가 있고요. 두 번째 시간에 대한 부분들인데요. 아까도 말했지만 이런 많은 데이터에 가장 큰 문제가 되는 부분들은 오픈타임에 있습니다. 지금 고객들은 비즈니스 타임을 다운타임을     

24시간 48시간 어떤 회사들은 72시간 다양하게 줄 수 있지만 그 시간이 넘어감에 대해서는 다 이게 크나큰 비즈니스 임팩트로 많은 비용들이 소모되는 부분들이 있거든요. 그래서 저희는 그런 부분들을 어떻게 하든지 최소화시켜 가지고 할 수 있는 여러 노하우를 많이 가지고 있고요. 가장 중요한 부분들은 이런 부분들이 맞게 옮겨졌다고 하더라도 이 바뀐 시스템이 안정화되지 않는다면 아무 소용이 없습니다. 그래서 이런 부분들에 대해서 통합테스트라든지 여러 테스트할 수 있는 오랜 경력을 갖고 있는 그런 전문가들을 투입함으로 인해서 이런 이슈들을 최소화 하는데 고객들한테 많은 도움을 드릴 수 있다고 자신할 수 있습니다.    

14) 컨버젼 완료 후 운영 시 발생할 수 있는 문제점은 무엇이며, 이와 관련된 대책은 어떻게 대응할 수 있나요? 

(TGSOFT) 네 가장 중요한 것은 테스트를 했음에도 테스트를 한 줄 모른다는 거죠. 왜냐 하면 구축팀하고 운영팀은 별개로 운영이 되다 보니까 이 부분들이 같이 진행을 하지 않고 의사소통의 채널이 없는 겁니다. 그래서 아까 자산에 대해서도 항상 그 부분을 많이 강조한 부분들은요. 저희가 컨버젼을 함에 있어서 진행됐던 여러 이슈나 또 문제점들에 대한 상태 진행형들을 공유해서 운영 시에 나타날 수 있는 그런 상황들 그리고 운영할 때 바로 그 부분들이 어떠한 변경 점인지 찾아볼 수 있는 그런 자산화를 관리하는 게 가장 중요하다고 생각이 됩니다.  

15) 지금 당장 컨버젼 계획은 없지만, 향후 효율적인 추진을 위해서 사전에 미리 준비 해놓으면좋은 점들은 무엇이 있나요? 그리고 컨버젼을 추후 진행 할 계획이지만, 앱을 새롭게 구축하거나 재 구축 할 경우 컨버젼 시 다시 구축해야 하는지요?

(TGSOFT) 네 프로젝트를 지금 하지 않더라도 미리 준비해야 됐을 때 가장 중요한 부분들은 우리가 갖고 있는 시스템이 어떻게 변경돼야 할지 변경에 대한 방향을 갖고 있는 게 중요하고요. 또 그렇게 하기 위해서 많이 바뀌게 되는 부분들의 프레스 변화를 하기 위해서 여러 직원들이 변화관리에 대한 델타교육이라든지 그런 교육들을 미리 만들어 놓을 수 있으면 굉장히 좋겠죠. 그 다음에 웹으로 전환시킨다고 했을 경우에도 기존에 지금 있는 시스템들이 아마 보시면 아시겠지만 10년 이상 돼가지고 리소스도 관리되지 않고 여러 개발에 대한 더 이상의 발전이 없는 시스템 같은 경우는 빨리 여러 경영에 대한 사상들이 조금은 좀 약간 시프트 돼가지고 클라우드 환경이라든지 BTP시스템으로 전환되면서 로우코드로 만약에 진행이 된다고 하면은 사전에도 어느 정도는 일부 구축이 될 수 있고 그 다음에 구축 후에도 이 시스템을 그대로 운영을 할 수 있어서 많은 도움이 될 거라 생각이 됩니다.  

16) 해운사의 경우 S/4HANA 도입을 검토 시 Public Cioud와 Private Cloud 중에서 선택할 경우 고려사항 및 좋은 경우는? 특히 해운사의 고유 특성을 반영하기 위해서 CBO가 많다고 했는데, 그럼 “Fit to Standard”와 같은 Clean Core는 어떻게 되는지요?

(Deloitte) 일단 말씀드린 대로 CBO관련된 부분이 가장 크게 중요한 상황일 것 같습니다. 즉 코어에 클린코어면 좋지만 코어 외에 얼마나 많은 CBO를 개발할 수 밖에 없느냐 이 것이고요. 그럼 만약 개발해야 되는 CBO가 많다면 아무래도 퍼블릭 보다는 프라이빗 클라우드가 좀 낫지 않을까라는 생각을 좀 하고 있고요. 그리고 해운 같은 경우는 아무래도 프론트 시스템에서 많은 데이터가 생성되고 그 데이터를 받아 들여서 SAP에서 추가로 생성해야 되기 때문에 CBO를 많이 만들어야 되는 것은 어떻게 보면 피할 수도 없을 것 같습니다.     

17) 해운사의 경우 본사와 해외법인의 Instance 전략을 어떻게 수립하는 것이 좋은가요?

(Deloitte) 네 먼저 해운업의 해외법인의 특성을 보면은 본사를 위해서 서비스를 제공하는 것이 주 업무입니다. 그렇게 되면 본사하고의 트랜잭션이 많기 때문에 하나의 싱글 인스턴스에서 싱글 클라이언트로 가는 것이 가장 유리할 것으로 판단하고 있습니다.

18) 그렇지만 본사는 예를 들어서 쓰고 해외법인은 퍼블릭 클라우드를 쓴다 할지 하더라도 프론트엔드 때문에 쉽지는 않아 보이는데?

(Deloitte) 아마 보통은 같은 프론트엔드를 공유하게 됩니다. 같은 프론트엔드를 공유해서 하기 때문에 크게 문제는 없을 것 같습니다.

19) 그럼 프론트엔드 시스템하고 퍼블릭 클라우드 연계는 용이하게 이루어 질 수 있는지? 

(Deloitte) 그 부분이 인터페이스 부분인데요. 연계는 됩니다만 아무래도 개발이 많아지니까 그런 부분이 제약사항이 될 수 있습니다.

이어서 20번~ 26번 질문 및 답변 확인하러 가기