CONTENTS

• 목록

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

2023년 5월 12일(금)에 진행된 제 27회 KSUG 패널 토크, “ S/4HANA로 가는 긴 여정에서 밟아야 하는 과정들 파헤쳐 보기 - 혁신을 위한 각종 계획과 실행”세션이 성료 되었습니다!

"디지털 혁신 마스터 플랜, 프로세스 혁신 기획, ERP 구축 등", 각종 계획 및 실행 활동들이 혁신을 위해 다양한 이름을 달고 추진되고 있습니다.
5월 KSUG 월간 패널 토론회에서는 이러한 활동들이 각각 어떤 목적을 가지고 수행이 되어야 하고, 상호 어떻게 연결이 되어야 하는지, 각 기업에서 추진한 실제 사례를 가지고 여러분들의 긴 여정을 계획하는데 좋은 인사이트를 드릴 수 있는 시간이였습니다!
 

<Session 1. 발표>

[KPMG] – 성공적인 DT 전환을 위한 전사 PI 및 SAP 구축 사례 소개
제목에서 알 수 있었듯이 DT 전환을 포함한 PI 및 ERP 시스템 구축과 관련하여실제 구축했던 사례를 기반으로 디지털 경영혁신의 필요성을 보여주었습니다.

DX 전략 수립을 위해서 사용하는 자사 Global Assessment Tool을 통한 진단 방법과 Didital 기반의 구축, 확산 및 고도화를 통해서 단계적으로 DT를 실행하는 로드맵 수립 절차도 인상적이었습니다. 전사 PI를 기반으로 To-Be를 수립하고 이를 구현해가는 과정과 이런 일련의 과정을 통해서 이룬 성과에 대해 알 수 있었습니다.

[BH컨설팅] – 가전 산업의 S/4HANA 도입 사례
정보화 전략 수립을 기반으로 프로세스 혁신을 통한 ERP 시스템을 구축하고 운영 서비스까지 전체를 One Stop Total Service를 제공하는 ERP 관련 전문 컨설팅 서비스 회사입니다. 이러한 경험이 매우 다양한 산업군의 기업에서 이루어졌다는 점이 놀랍습니다. 지난 달 패션 사업의 소개에 이어 이번 달에는 가전 산업에서의 PCE를 기반으로 S/4HANA 구축 사례를 기반으로 설명이 많은 도움이 되었습니다. 자사 Assessment Tool 기반의 시스템 구축 관련 수행, 현황, 방법 및 방향성 등에 대한 설명 감사 드립니다.

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

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

1) 오늘 참여한 삼정 KPMG는 대부분 알고 있다고 생각되는데, BH컨설팅은 몇 번 소개되었지만 아직도 제대로 모르시는 분들이 계실 거라서 다시 한번 회사의 강점 및 역량에 대한 소개 부탁드립니다. - 다른 파트너사 대비 BH컨설팅사가 가지고 있는 장점과 차별점은?(gominju)

(BH컨설팅) 네 BH Consulting 은 한 20년 이상 SAP를 구축경험을 갖고 있는 컨설턴트가 한 10명 정도 됩니다. 그리고 최소한 10년 이상 컨설팅 서비스를 이제 수행했던 그런 컨설턴트들이 한 20명 이상 됩니다. 이런 부분들이 이제 BH Consulting의 강점이 아닐까 생각이 듭니다.

2) S/4HANA 구축 시 방법론 측면에서 On-Premise와 어떻게 다른지요? 

(BH컨설팅) 크게 방법론 그 구축방법론은 차이가 없습니다. 단 그 인프라적인 측면에서 차이가 있다라고 이제 이해해 주시면 될 것 같습니다. 

(KPMG) 과거 이제 PCE Private Cloud도 있지만 Public Cloud도 있고 한데 일단 Private Cloud를 말씀드리면 기본적인 차이는 없습니다. 없는 게 맞고요. 맞는데 그럼에도 불구하고 BH Consulting도 마찬가지고 저희도 이제 그 동안에 많은 업력이 쌓였기 때문에 산업에 특화된 부분에 프리컴퓨레이션 이라고 해서 미리 인더스트리 별로 사전 정의된 내역 기반으로 좀 더 빠르게 좀 더 정확하게 좀 더 고객에게 최적화된 형태로 구현이 가능한 형태로 서비스를 제공한다 이렇게 보시면 될 것 같습니다.

3) S/4HANA 구축 시 CBO 개발측면에서 On-Premise와 PCE의 차이점은? 

(BH컨설팅) 예를 들어서 PCE Private인 경우도 안에 있는 컨텐츠 건은 고객사 것입니다. 그래서 제가 봤을 때는 그 개발적인 측면에서는 차이가 없다 라고 이해해 주시면 될 것 같고요. 단, 이제 어떤 차이점이 있냐 하면 인터페이스를 만약에 대부분 다 보면은 여러 시스템이라 인터페이스를 하게 되면 인터페이스 처리방식에 차이가 있습니다.      

(KPMG) 네 맞습니다. 동일하게 경험해 봤기 때문에 스탠다드 SAP에서 요구하는 그 요건을 조금 디테일 한 걸 맞춰줘야 되는 그런 부분이 있고요. 그 외에는 이제 클라우드 서비스다 보니까 바로 즉시에 뭔가 대응이 되거나 하는 것들은 조금 여유를 뒀으면 좋겠다 그런 식의 차이가 있는데 다만 비용 대비 효율으로 보면 효율이 훨씬 많은 측면이 있다고 생각합니다.       

4) 기존 사용중인 시스템과 원활한 호환을 위한 필수 고려사항은? 

(BH컨설팅) 방금 전에 설명을 드렸던 것처럼 인터페이스 방식인데요. 과거 이제 그 ECC같은 경우는 그 인터페이스를 할 때 소위 말해서 이제 DB 2 DB라는 방식을 허용을 어느 정도 했어요. 그런데 이제 S/4HANA PCE 쪽으로 넘어오면서 DB 2 DB방식을 완전히 수행할 수가 없습니다. 그래서 소위 말해서 요즘 같은 경우는 이제 S/4HANA를 구축하게 되면 그 RFC방식, 타 시스템에서 데이터를 끌고 가기 위한 RF방식으로 주로 이제 구현이 되고 있습니다.   

(KPMG) 동일하게 저 이슈는 항상 있었는데요. SAP가 공식적으로 제공하는 프로토콜이죠. 리모트 펑션 콜이라는 이 형태로만 진행을 해야 된다라는 그런 제약 요건은 좀 있는 것 같습니다.

5) 고객사와 수행하는 Assessment는 꼭 필요한지요? 

(BH컨설팅) 그냥 그 구축 경험으로 보면 필수사항은 아닌 것 같습니다. 단 Assessment를 수행하면 보다 더 정확하게 그 고객사의 시스템을 어떤 방식으로 어느 부분들을 집중적으로 볼지를 확인 할 수 있습니다. 그러면 실질적으로 좀 더 신뢰성 있는 시스템을 Assessment를 진행함으로써 이제 구현할 수 있지 않을까 그런 생각이 듭니다. 

(KPMG) 표현은 조금 다를 수 있는데요. 그런 것들이 저희는 이제 DX전략이라는 형태로 담아서 진행을 하기도 하고, 고객사와의 협업관계를 통해서 미니아 SP 뭐 그런 형태로 진행하기도 하고 사전 진단이라는 용어로 진행이 되기도 합니다. 말씀 주신 것처럼 그러한 과정들은 실제로 구축단계에 많은 비용이 소요되기 때문에 먼저 사전적으로 점검을 통해서 고객사의 중복투자를 막을 수도 있고, 또 포커싱 해야 되는 부분들을 잘 선정을 해서 회사의 발전에 도움이 될 수 있는 그런 방향으로 진행할 수 있기 때문에 반드시 필수적인 건 아니지만 하는 것이 서로 윈윈 할 수 있는 그런 좋은 결과를 마련할 수 있다고 생각합니다.       

6) Assessment는 어떤 절차로 진행되는지요?

(BH컨설팅) 단순하게 이렇게 설명을 드리면 아주 그냥 간략하게 설명을 드리면 우선 인터뷰나 현재 하고 계신 업무와 사용하고 계신 IT 시스템에 대한 분석 그 다음에 평가 관련된 자료들을 모아서 특정 이제 저희 BH같은 경우는 이제 보유하고 있는 툴을 활용한 평가, 그 다음에 향후 방향성 즉 개선과제 라든가 아니면 아이스피어 같은 스코프 즉 범위를 시스템을 어떻게 구현할지에 대한 범위를 결정하는 그런 절차로 진행을 하고 있습니다.   

(KPMG) 아까 간략하게 화면에서 잠깐 보여 드렸었는데요. 실제로 총 4단계 정도가 있는데 진단모델에 대해서 먼저 커스터마이징 합니다. 기본적으로 갖고 있는 모델이 있고 해당 인더스트리 해당 고객사의 요구사항에 맞춰서 핏 하게 커스터마이징한 절차로 해서 체계를 정립하고 이슈 수집을 하고 인터뷰 초안을 준비하고 현업 T/F팀과 뭐 해당내용을 정리하는 단계가 있고, 진단을 이제 실행할 때는 이제 벤치마킹 기반으로 또 인터뷰 기반으로 해서 정량적인 효과 이슈와 정성적인 이슈가 다 도출될 수 있도록 검증하는 단계를 거치고요. 그 결과에 따라서 각 영역별로 중점적으로 보완해야 될 사항 또는 이제 이런 것들은 타 사보다 높은 사항 이런 것들을 피켓분석을 하게 되면 선진사 대비 애즈 이즈 우리 회사가 갖고 있는 현재 수준을 진단을 해서 그 갭을 메꾸는 방안에 최적한 것들을 찾아주는 그런 단계로 진행을 합니다. 물론 이제 그것을 진행할 때는 갖고 있는 아까 말씀드렸던 인더스트리 별로 갖고 있는 키 이슈에 대한 풀을 갖고 있어서 먼저 빠르게 제시를 하고 수행을 하는 형태입니다.       

7) Assessment 분석 및 진단 방법에 대한 간단한 설명 부탁드립니다.

(KPMG) Assessment 뿐만 아니라 실제 PI 풀 구조나 PI 진단툴 모델부터 해서 이제 글로벌, 저희 KPMG가 150여개 국가에 갖고 있는 비즈니스 사례들을 모아 놓은 방법론들이 있어서 그 기반으로 인더스트리에 최적화된 베스트 프랙티스를 가지고 진단을 수행한다 그 게 제일 큰 강점이라고 생각합니다.  

(BH컨설팅) BH와 같은 경우는요 저희 한 20년 넘게 이제 SAP구축 컨설팅을 수행하다 보니까 다양한 산업군에 대한 그 프로세스 그런 노하우들을 보유하고 있습니다. 그런 것들을 관련된 내용들을 문서적으로 정리를 해서 그 것을 정량화 할 수 있게끔 평가할 수 있는 툴을 만들었습니다. 예를 들어서 제약산업에서는 어떠 어떠한 배치 관련된 그 프로세스가 필수다 라는 그런 부분들이 있어서 그런 내용들을 활용을 해서 평가를 수행합니다. 하다 보면 그런 내용들을 좀 더 구축단계에서는 적극적으로 활용할 수 있는 그런 자료가 되기도 합니다   

8) 프로젝트 착수를 위한 T/F 구성의 효율적 방안은? - 프로젝트 성공을 위한 내부 조직은 어떻게 준비해야 하는지요? (EricLee)

(KPMG) 원래는 제가 좀 소개를 드리고 싶어서 뒤쪽에 백업으로 좀 했는데 컨텐츠를 같이 보고 말씀을 드릴 수 있을 것 같습니다. 실제 구성해서 진행했던 사례고요. 보통 이 회사는 아까 말씀드렸던 5개 코어모듈 기반으로 중심으로 움직이다 보니까 13-4명 정도의 상주 PI가 필요했었고 그런 것들이 다행히 씨레벨의 확고한 의지와 이런 게 있었기 때문에 상주발령을 해 주셔서 그만큼 더 원활하게 또 그만큼 더 고객사의 요구사항을 잘 분석을 해서 반영할 수 있었습니다. 이 T/F T에 그래서 기본적으로 좀 필요한 스킬셋이 있거든요. 스킬셋은 해당 부문에 대해서 본인이 전 업무를 모르지만 그 모듈에 대한 전 업무를 모르지만 대표선수로서 왔다는 그런 이제 신념과 개선의지 이런 것들이 좀 필요하고요. 프로젝트 진행하고 나중에 프로젝트 종료하고 나서는 변화관리 이제 에이젼트로서 해야 되는 그 역할을 그런 것들을 심어주는 그게 좀 필요하다고 생각하고, 또 PMO의 기본적인 롤은 또 똑같이 변화관리 및 이슈 및 일정관리 하는 그런 부분에 대한 역량을 가진 분들이 T/F T 인력으로 구성이 되어야만 잘 운영이 되고 프로젝트 종료 후에 나중에 다른 변화관리 T/F T활동으로 이어질 수 있다고 생각 합니다.  

(BH컨설팅) 거의 BH Consulting 같은 경우도 거의 비슷합니다. 그래서 조금 더 저희가 항상 고객사에 이제 제안을 할 때는 이 내용과 유사하게 제안하는데 좀 더 구체적으로 좀 설명을 드리면 예를 들어서 재무팀에 PI인 경우는 재무팀에서 5년 이상 근무하신 분, 그리고  최소 결산을 2번 이상 수행하신 분 그리고 SCM같은 경우는 구매업무나 아니면 물류업무나 재고관리 업무에서 최소한 5년 정도는 업무를 수행하신 분 이렇게 해서 제안을 드리고 있습니다.

9) 이호승님이 과연 어떤 인력이 필요하느냐? 구축 후 유지보수는 어떻게 했냐는데 지금 이제 말씀 주신 것처럼 업무에 대한 역량을 많이 가지고 계신 분들이 T/F에 오시는 게 일단 성공의 반을 차지하는 것 같고요. 특히 ERP를 하다 보면은 지금까지는 단위업무에만 잘 알아도 됐지만 크로스펑션 과제들 일단 물동과 재무가 연결되는 부분, 물동간 연결되는 부분들을 많이 아시는 분이 필요한데 그런 분들이 회사에 많이 확보되지 않은 경우가 많거든요. 근데 그럴 경우에는 프로젝트 경험이 많은 사람들을 활용해서 하는 게 적은 비용으로 효율적으로 할 수 있다 이렇게 정리를 할 수 있겠습니다. 그렇죠?

(KPMG) (BH컨설팅) 네 맞습니다.

(KPMG) 간단하게 첨언을 더 드리자면 실제로 옆에 전무님께서 말씀하신 것처럼 구체적인 그런 스킬셋을 요구를 합니다. 하는데 실제 본인이 해야 되는 업무 인력에 그 피트한 부분들 때문에 적당한 인력을 배치를 못해주는 경우들이 많아요. 그래서 대표님 말씀 주신 것처럼 오히려 그럴 거면 다양한 과정을 거쳐서 여러 부서를 거쳐서 많은 경험을 오히려 보유하신 그런 분들이 오시면 또 프로젝트에 도움이 되는 경우가 많더라고요.   

10) S/4HANA 구축 전 사전 준비를 위해서 강조하고 싶은 점과 그 주된 이유는?

(BH컨설팅) 네 먼저 설명을 드리면 항상 프로젝트는 구축하는 단계에 들어가면요 “현재 하는 업무 어떻게 하고 계십니까?” 라고 물어보면 뭔가 문서적으로 있으면 좋거든요. 그런데 항상 보면은 말로 이렇게 설명을 해주세요. 또는 인터뷰를 통해서 파악하게 되고 그 다음에 이제 관련된 마스터 데이터라고 하죠. 기준정보들 이런 것들을 “어떤 기준정보들을 사용하고 계세요?” 라고 이제 “어떻게 사용하고 계세요?” 라고 하면 “우리는 이런 벤더마스터 커스터먼 마스터 만들어 사용합니다” 라고 이렇게 설명을 해주세요. 그런데 이제 좀 더 그것을 이제 구축단계 전에 좀 더 현재 사용하고 있는 기준정보 한번 전체적으로 이제 로우 데이터라고 하죠. 데이터를 다운 받아서 확인하는, 확인하고. 그 다음에 현재 하고 계신 업무들을 좀 문서화해서 정리해 놓으면 아무래도 이제 구축할 때 좀 수월하게 접근할 수 있지 않을까 그런 생각이 듭니다. 

(KPMG) 뭐 PI가 되건 ERP구축이 되건 사전준비 자료를 먼저 저희가 요청을 드립니다. 요청을 드리는데 그래서 말씀 주신 것처럼 구두상으로 전달을 받는 것도 좋지만 저희는 어쨌든 데이터 기반으로 정량적인 분석을 좀 해서 뭔가 개선 포인트를 찾아야 되기 때문에 특히 이제 기준정보 같은 경우는 뭐 PI단계 거치고 구축단계 거쳐서 ERP전체 핵심의 50%를 담당하는 부분이라서 실제 해야 되는 것들이 초반부터 저희 끝날 때까지 기준정보가 끝까지 따라 다니거든요. 그래서 그런 것들을 초기에 먼저 정제된 데이터를 받아서 뭔가 대비하고 준비하는 과정들을 구성하는 게 필요하다고 보여지고요. 그 외에는 기준정보 말고 조직체계 관련된 정보 이런 것들이 준비가 필요하다고 생각 합니다.    

11) DX 전환까지 검토한다면 추가적인 사전 준비사항은 무엇인가요? - DX 전환 검토 시 사전 준비사항은?(관심유저)

(KPMG) 기본적으로 이제 저희가 아까 설명 드렸던 내용들 중에 회사의 디지털 전환을 위한 성숙도를 분석하는 이제 그런 단계들을 거칩니다. 이제 그 말은 현재 시스템 사용이 어떻게 되고 ERP코어 기반인 기반시스템을 중심으로 어떤 환경들이 현재 제공되고 있고, 이 환경들은 얼마나 업그레이드가 가능하고 얼마나 최신 트렌드를 반영해서 적용이 가능할거냐 라는 것들을 판단하고 분석을 해야 되는데 그것은 저희가 모르는 거거든요. 기존에 애즈 이즈 시스템 담당자 또는 ITE부서 등등에서 그런 현황과 업그레이드 또는 신기술이 적용 가능한 부분에 대한 내부적인 분석이 필요한데요. 그런 것들이 준비가 되어야 되는데 실제 용역을 나가보면 전사시스템 체계도를 회사에서 모르는 경우들이 왕왕 있어요. 아까 말씀 해주신 것처럼 그래서 저희가 실제 분석을 하면서 애즈 이즈 시스템 버전 15까지를 만들어 봤어요. 그러니까 하면서 뭐가 하나씩 하나씩 나오는 그런 케이스들이 있는데 물론 저희는 어쨌든 해야 되는 과정이라고 생각은 할 수는 있습니다만 전체적인 부분에서 그 시간을 좀 더 줄였으면 뭔가 더 좋은 변화된 최적화된 회사에 도움이 되는 밸류를 줄 수 있는 그런 시간으로 좀 활용할 수 있었지 않았을까 라는 생각을 좀 많이 해 봅니다. 

12) 제 경험상 투비 수립할 때 애즈 이즈 파악이 다 끝나면 행복한 회사고요. 좀 심한 회사 같은 경우는 이제 개발 다 끝나서 테스트하는 단계에서도 애즈 이즈가 그 때 파악되는 경우도 왕왕 있기 때문에 정말 이 애즈 이즈 파악은 굉장히 중요한 것 같습니다. (KPMG) 하나만 더 말씀드리면 아까 설명 드릴 때 그 회사, 저희가 수행한 회사 같은 경우에 저희가 시스템을 도입하고 PI를 하고 시스템을 도입할 때는 빅뱅방식이라고 해서 일괄적으로 대대적인 혁신을 하고 변화를 하는 방법도 있습니다. 그런데 그럼에도 불구하고 이걸 단계별로 구분을 해서 간 이유는 물론 비용이 많이 투입되는 예산의 문제도 있겠지만 또 인력의 리소스에 대한 문제도 있습니다. 또 그것도 그건 이제 어떻게 보면 부차적인 문제일 수 있고요. 실제로는 핵심이 되는 선후인 관계에 있는 것들이 먼저 정리가 돼야 그 다음 단계로 나간다라는 것들이 있기 때문에 우선순위를 저희가 당연히 가이던스 드리고 권고를 합니다. 권고를 드리면 그 부분에 대한 의사결정을 하는 체계가 제때 제 때 갖춰져야 뭔가 진행하는데 원할 하게 되지 않을까 이렇게 생각을 합니다.       

13) DT여정에서 가장 먼저 준비해야 되는 게 무엇인지? (최재경)

(KPMG) 중꺾마입니다. 꺾이지 않는 마음. PI는 피 나고 이 갈리는 과정이거든요. 이게 PI가 그냥 PI를 하는 게 아니고요. 정말로 혁신이라는 말이 그 가죽으로 이렇게 벗겨질 정도로 뭔가 쇄신을 하는 과정이기 때문에 정말 기존 애즈 이즈 프러스 이 회사가 계속해서 비즈니스가 이건 생물체처럼 환경에 따라서 또 회사가 번창함에 따라서 또 사업부도 새로 생기고 신 사업도 하게 되고 하면서 이제 고정된 형태로 비즈니스가 이루어 지는 게 아니기 때문에 이 것을 깨기 위한 새롭게 가기 위한 그 과정이 PI를 하는 과정이라고 생각되고요. 그러한 PI과정들을 통해서 설계된 프로세스와 휘뎅겐 분석을 통해서 회사에 최적화하는 과정을 거친다고 생각합니다. 그래서 그런 중간에 가장 핵심인 PI단계를 하기 위한 아까 말씀드렸던 꺾이지 않는 마음이 중요하다고 생각합니다.     

14) 구축 검토 시 초기 Sizing 및 규모 예측은 어떻게 하는지요? - (이호승)

(BH컨설팅) 세 가지 측면으로 볼 수 있을 것 같아요. 하나는 뭐냐 하면 그 업무에서 투입될 컨설턴트가 어느 분야로 들어 올건지 그 다음에 SAP 유저 ID 그 다음에 DB사이징 업무 부분 같은 경우는 이제 제안서에 가서 이제 제안을 했어요. 이제 스콥이 결정되면 거기에 맞게 이제 그 컨설턴트와 아니면 PI를 인원을 섭외하면 될 것 같고요. 그 다음에 SAP ID 같은 경우는 실질적으로 직원수가 몇 명인지 그 다음에 향후에 SAP를 사용할 인력이 몇 명인지 이렇게 이제 보시면 되고, DB 사이징 같은 경우는 과거 ECC를 사용했던 회사 같은 경우에 그 이론적으로는 1/8 입니다. 단 실질적으로 구축 경험을 해보면 한 DB사이징 한 40% 정도는 줄어 들더라고요. 그 것을 감안해서 결정하면 되지 않을까 합니다.          

(KPMG) 일단 뭐 업무적인 스콥이나 이런 것들은 아까 전략이나 PI단계나 이런 걸 거치면서 이제 정교화해서 업무의 범위와 기간 등은 그렇게 확정이 됩니다. 되는데 그럼 이제 규모, 하드웨어 사이징이나 라이센스 부분 이런 것들을 할 때는 이제 기존에 SAP를 쓰지 않은 회사 같은 경우에는 SAP에서 제공하는 툴이 있습니다. 퀵사이저라는 툴이 있어서 레가시 시스템 기준이지만 거기서 사용하는 트랜잭션 트래픽 수 뭐 등등을 입력하게 되면 SAP 기준으로 컨버전 해서 어느 정도의 규모가 될거라는걸 산정해주는 툴이 있으니까 그 걸 이제 활용해서 하기도 하고요. 그 다음에 S/4HANA로 전환하는 형태에서는 이제 SAP에서 HANA 데이터 DB모델링하고 메모리 용량을 제공해주는 SAP 노츠가 있어서 그 기반으로 해서 저희가 가이드 드리고 검토를 합니다.           

15) 기존 ECC에서 S/4HANA로 전환 시 주의해야 할 점과 S/4HANA Conversion시 사전에 고려해야 할 점은? 

- S/4HANA 전환 시 주의해야 할 점은? (동글이)

- S/4HANA Conversion시 사전 고려사항은? (타이쿤안) 

- S/4HANA 전환 시 현업에서 어떤 방향성을 갖고 해야 되는지? (양해리)

(BH컨설팅) 네 여러 가지가 있겠지만 한 두 가지 측면을 말씀드리면 한 가지는 뭐냐 하면 인터페이스 정책, 좀 전에 설명 드렸던 것처럼 RFC방식을 사용해야 되는 제약조건이 하나가 따르고요. 그 다음에 이제 크게 ECC에서 S/4HANA로 넘어오면서 바뀐 게 그 마스터입니다. 마스터 중에서 커스터머 밴더마스터, 이 체계가 이제 BP라는 마스터 체계로 이제 변경이 됐거든요. 이런 측면에서 좀 더 검토를 해 보면 좋지 않을까 이제 이런 생각이 듭니다.     

(KPMG) 동일하게 제일 크게 바뀐 게 말씀주신 것처럼 이제 BS 파트너라는 체계로 거래처 관리하는 체계가 바뀌었다는 게 가장 크고요. 그런 부분 때문에 통합관리, 과거에는 구매처, 고객 따로 따로 관리됐던게 이제 통합관리 되다 보니까 그럼 RNR에 대한 변화도 불가피 합니다. 또 여신관리, 채권관리, 채무관리 하는 것들에 대해서도 뭔가 변화가 있을 거라고 보여지고 마찬가지로 데이터 클렌징이나 마이그레이션 하는데도 당연히 영향을 받습니다. 단순히 이제 기존시스템에서 사용하던 CBO프로그램을 컨버젼 하는 그런 케이스들도 있을 건데요. 이제 그 부분도 정말 기존에 사용하던 개발했던 CBO프로그램이 향후에 쓰임이 맞을 거라는 걸 먼저 선별을 좀 해서 적용하는 게 좋을 것 같습니다.          

16) SAP Best Practice란 무엇인가요? 또 이 SAP Best Practice가 산업군별로 되어 있는지요?

(BH컨설팅) SAP 이제 자료를 보면 그 Best Practice라고 해서 각각 산업군별로 해 갖고 문서를 갖고 있습니다. 그 파워포인트 라든가 아니면 그런 자료방 들이 있는데 그런 자료방 들은 이제 그 각각의 모든 오픈 소스는 아니고요. 해서 이제 그런 문서 플로우, 업무 플로우죠. 그런 자료들을 갖고 있는 것이 그 다음에 SAP에 들어 담겨있는 기능 이 것이 바로 이제 Best Practice라고, SAP Best Practice라고 표현을 합니다. BH같은 경우는 이러한 자료들을 기반으로 해서 과거 구축경험을 토대로 해서 한 단계 업그레이드를 시켜 놓은 것을 저희는 BH Consulting의 SAP Best Practice다 라고 설명을 드리고 있습니다.

(삼정 KPMG) 요즘 제가 알고 있기로는 SAP도 당연히 여러 산업군에서 비즈니스를 해 왔고 좀 더 완결성이 있는 체계로 해서 프로세스 체계를 잡은 걸 이제 Best Practice라고 합니다. 그래서 그러한 부분들은 실제 퍼블릭 ERP쪽에서는 시나리오 스콥아이템이라는 형태를 해서 프로세스 체계를 가지고 컴프레이션까지 연계되는 그런 형태로 알고 있고요. 저희 혹시 자료 잠깐만 띄워 주실 수 있을까요? 이제 그러한 것들이 저희도 이제 KPMG에서도 SAP의 Best Practice와 같은 형태로 해서 표준 템플릿이나 실제 산업체 인더스트리별로 솔루션을 갖고 있는데요. 이렇게 갖고 있게 된 배경자체가 KPMG가 갖고 있는 150여개 국가에서 수행한 인더스트리별 사례들을 기반으로 Practice를 산업별로 나래비를 해서 솔루션처럼 패키지화해서 저희가 갖고 있거든요. 이런 것들이 이제 SAP가 갖고 있는 것들에 추가해서 리딩되는 업종, 리딩 하는 산업에 최적화한 형태로 좀 더 선진화했다 이렇게 생각하시면 될 것 같습니다.    

17) To-Be 수립 시 Gap 분석은 어떻게 하는지요?

(BH컨설팅) 일반적으로 이제 구축단계에서 갭 분석을 하게 되면요. 먼저 이제 To-Be 프로세스를 그립니다. 그 다음에 SAP를 이제 개발시스템을 이제 설치를 하죠. 그러면 그런 To-Be 프로세스와 SAP 그 설치된 개발시스템에서 각각의 그 풀로 하나 하나를 이제 수행을 합니다. 수행을 하면서 “어 이것은 SAP에 적용이 되네 안 되네” 이제 이런 방식으로 갭 분석을 이제 수행하게 됩니다.    

(KPMG) 비슷한데 좀 더 말씀을 드리면 저희가 To-Be 프로세스를 설계한 아까 PI부터 해서 거쳐서 프로세스 체계를 잡았습니다. 이렇게 잡았을 때 프로토타이핑 이라고 해서 지금까지 확정된 아니면 이 회사의 표준화된 인더스트리별 아까 사례로 말씀 드렸던 프리컨피그레이션 된 내역을 기반으로 먼저 고객하고 소통하고 이런 형태로 시스템이 구성이 될 거라는 것을 교육 및 그런 정보를 활용을 하게 되는데요. 그렇게 하면서 프로세스 설계된 거 내역 기반으로 SAP 프로토타이핑에 의해서 설치된, 구현된 내역하고의 차이점들을 비교 분석을 하게 됩니다. 해서 “아 정말 이 것은 다 좋은데”, “우리 회사의 산업특성 상 또는 컴플라이언스 이슈상 이것은 리포팅이 별도로 되야 돼요” 또 “세무목적이랑 감사목적 때문에 필요한 사항들이 있어요”라는 것들은 커스터마이징이나 애드온 형태로 개발이 추가되는 사항이고요. 또 PI단계를 거쳐서 이 것들은 갭이긴 하나 이번에 프로세스 혁신에 의해서 워커라운드로 해서 “아 신시스템에 신 ERP표준에 맞게 글로벌 표준에 맞게 우리 프로세스를 바꿉시다” 라고 하는 부분들은 워커라운드라고 해서 SAP의 To-Be시스템의 모델을 수용을 하게 됩니다. 그렇게 하면서 프로세스를 핏하게 수용하는 부분이 있고 워커라운드로 개선하는 부분이 있고, 개발이 되는 부분으로 나눠져서 분석이 된다고 보시면 될 것 같습니다.  

18) 구축 시 PI를 수행하는 주요 이유는? 또한 PI를 수행하지 않으면 어떤 문제점이 발생하는지요?

(KPMG) 아까 잠깐 다 말씀드렸는데요. 회사가 기존에 “애즈 이즈가 어때요~” “아 요거대로 해주세요~” 이런 회사들도 많거든요. 그런데 분명 비즈니스 환경이 변했고 사업부도 커졌고, 실제 회사의 환경도 바뀌었고 외부 환경도 바뀌었기 때문에 이제 그러한 것들을 같이 업무 프로세스와 시스템 프로세스를 연계해서 혁신해 나가는 과정이다. 그렇기 때문에 반드시 PI를 통해야만 신 시스템 기반으로 신 비즈니스 넥스트, 향후를 도모할 수 있는 시스템으로 구현이 된다 라고 말씀드리겠습니다.   

(BH컨설팅) 네 거의 대동소이 합니다.

19) 프로젝트 수행 시 T/F 현업 PI R&R은 무엇이며 사전 준비사항은? - S/4HANA 구현 시 프로젝트 참여하는 현업의 방향성은? (양해리)

(KPMG) 실제 프로젝트 하는 과정에서는 저희 T/F T 인력들이 그 현업에 있는 부분들을 대표해서 온 역할을 하는 거고, 그럼 이제 실제 전문적으로 뭔가 구축단계나 구현단계에 들어갔을 때는 이제 코디네이터 역할을 하면서 그 현업을 인벌브 해서 그 요구사항 기반으로 프로세스 설계 및 개발이 된 것을 검증을 받습니다. 그럼에도 불구하고 현업의 분들은 통합테스트라는 과정에서 2차, 3차되는 과정에서 유저 어셉턴스 테스트라는 과정을 거치게 됩니다. 실제 Go-Live 하기 전에 정말 최종 사용자들 기준으로 “아 이정도 프로세스로 적용이 되면 시스템을 잘 쓸 수 있겠다”라는 단계를 적용할 때 유저 어셉턴스 테스트에 메인 역할을 한다 이렇게 생각하시면 될 것 같습니다. 

(BH컨설팅) 한 세가지 측면이 있을 것 같습니다. 하나는 뭐냐 하면 기준정보 정비 및 검증 그 다음에 또 하나는 뭐냐 하면 말씀드렸던 것은 정확한 테스트 그리고 또 하나는 뭐냐 하면 오픈 데이터 준비 이렇게 세 가지 측면으로 설명 드릴 수 있겠습니다.   

20) PCE로 S/4HANA 구현 시 BC 담당자 역할 변화는?(BH컨설팅) BC역할은 기존에 이제 온프라미스 같은 경우는 모든 시스템과 서버라든가 네트워크를 구축한다 라고 보시면 향후에 이제 S4/HANA 이제 클라우드 개념이 강해졌지 않습니까? 이렇게 되면 주로 이제 담당하는 역할은 메신저 역할입니다. 그러니까 실질적으로 클라우드를 보유하고 있는 회사, 우리가 서비스를 위한 회사와 연결 그 SAP를 어떻게 구축하고 클라이언트를 뭐 언제 카피할 거며 이제 이런 그 메신저 역할을 주로 하게 됩니다.  

21) PCE로 구현하면 운영 시 비용 절감 요소는?

(BH컨설팅) 한번 구축된 과거 사례를 보면 두 가지 측면이 있을 것 같습니다. 그 첫 번째는 뭐냐 하면 서버 등의 인프라에 대한 비용, 초기비용 그 다음에 SAP 라이센스 비용 온프라미스는 한번 사오면 되는 건데 마치 이제 S4/HANA PCE 같은 경우는 과금 방식 이거든요. 그러한 초기 투지비용이 많이 다운된다 라고 이해해 주시면 될 것 같습니다.      

(KPMG) 간략하게 이것도 많이 보셨던 내용들 중에 하나일 수 있는데요. 실제 빙산 위로 보이는 부분이 뭐 동일하게 보이지만 실제 아래쪽에 온프라미스를 유지하게 되면 해야 되는 많은 태스크들이 있습니다. 그래서 인력의 유지보수 비용, 하드웨어 관리비용, 등등 이런 것도 있는데 말씀 주신 것처럼 클라우드 방식을 사용하게 되면 구독료 방식으로 적용이 되기 때문에 실제로 고객사의 회사마다 차이는 있을 수 있습니다. 라이센스 수도 있고 규모도 있고 차이는 있는데 최소한 5년, 7년 정도 까지는 TCO가 클라우드가 훨씬 유리한 걸로 그렇게 판단이 됐습니다.     

22번~ 26번 질문 및 답변 확인하러가기 <<