ERP 현대화 및 SAP ECC 탈출: 아무도 범위에 넣지 않은 주변 엔지니어링

모든 ERP 마이그레이션 안에는 두 개의 프로젝트가 들어 있습니다. 하나는 계획서에 적힌 프로젝트입니다. 새 시스템, 프로세스 설계, 시스템 통합 사업자입니다. 다른 하나는 넉 달째에 누군가 인터페이스를 세어 보면서 모습을 드러내는 프로젝트입니다.

그 두 번째가 우리 일입니다. 80개의 커스텀 연동, 재무가 의존하지만 주인이 없는 리포트, 데이터베이스 뷰와 대화하는 창고 단말, 구 테이블을 직접 읽는 고객 포털, 그리고 새 시스템이 받아들일 형태로 넘어가야 하는 20년치 데이터입니다. 최초 범위에 들어 있는 경우는 드물고, 일정을 결정하는 경우는 잦습니다.

왜 지금 일정에 올라와 있나

SAP ECC 6.0의 주력 유지보수는 2027년 12월 31일에 종료됩니다. 연장 유지보수를 쓰면 2030년 말까지 갈 수 있지만 추가 비용이 들고 범위도 축소됩니다. 설치 기반의 상당수가 아직 착수하지 않았고, 마이그레이션은 통상 18개월에서 36개월이 걸리며, 이를 수행할 파트너와 하이퍼스케일러 용량은 지금 예약되고 있습니다.

같은 압력이 SAP 밖에도 있습니다. Oracle EBS 고객은 자체 지원 종료 시한을 마주하고 있고, Dynamics AX와 NAV 설치 기반은 Business Central과 Dynamics 365 쪽으로 밀려가고 있으며, 10년 전에 대폭 커스터마이즈된 ERP를 그 작업을 했던 사람들이 모두 떠난 채로 돌리는 회사들이 길게 이어져 있습니다.

목적지가 무엇이든 문제의 모양은 같습니다. ERP는 섬이 아니고, 거기에 붙어 있는 것들은 대개 문서화되어 있지 않습니다.

우리가 하는 일

인터페이스 조사와 목록화

무엇이든 계획하기 전에 누군가는 실제로 무엇이 ERP와 대화하는지 확인해야 합니다. 우리는 그것을 설문지를 돌리고 기대하는 방식이 아니라 경험적으로 합니다. 데이터베이스 로그, 네트워크 트래픽, 스케줄 작업, 연동 미들웨어 설정, 소스 코드를 읽습니다.

산출물은 모든 인터페이스의 목록입니다. 방향, 프로토콜, 주기, 데이터 볼륨, 찾을 수 있다면 업무 담당자, 그리고 재구축해야 하는지 폐기할 수 있는지 그대로 적응시킬 수 있는지에 대한 판단이 붙습니다. 고객사가 예상했던 것보다 2배에서 5배 많은 인터페이스를 발견하는 일이 흔하고, 그중 적지 않은 수는 아무 데도 쓰이지 않는 것으로 드러납니다.

연동 계층 재구축

살아남아야 하는 인터페이스를 재구축하되, 새 시스템을 직접 가리키게 하기보다 추상화 계층을 향해 재구축하는 쪽을 선호합니다. 위성 애플리케이션과 ERP 사이에 연동 계층을 두면 다음 마이그레이션에서 (반드시 또 있습니다) 이 작업을 반복하지 않아도 됩니다. 또한 단일 전환 주말이 아니라 여러 차수로 나누어 애플리케이션을 옮길 수 있게 됩니다.

작업 범위는 IDoc와 BAPI 인터페이스, OData 서비스, 이전 시대의 SOAP 엔드포인트, 유럽 B2B의 절반을 여전히 돌리고 있는 플랫 파일과 SFTP 교환, 메시지 큐, 그리고 새 시스템 쪽의 최신 REST API에 걸칩니다.

데이터 마이그레이션 엔지니어링

추출, 정제, 변환, 적재, 그리고 대개 과소평가되는 대사입니다. 마이그레이션을 일회성 스크립트가 아니라 반복 실행 가능한 코드로 만듭니다. 점점 깨끗해지는 데이터에 대해 수십 번 돌리면서 결과를 매번 자동으로 비교할 수 있어야 하기 때문입니다.

신뢰가 걸린 곳은 대사입니다. 재무는 적재가 성공했다는 이유로 마이그레이션을 승인하지 않습니다. 잔액이 맞고, 건수가 맞고, 남은 차이가 설명되고 서면으로 수용되었기 때문에 승인합니다.

ERP보다 오래 남는 자체 애플리케이션

대부분의 회사에는 구 ERP 주변에 만들어진, ERP가 하지 못하던 무언가를 담고 있는 애플리케이션이 있습니다. 구성기, 가격 산정 도구, 현장 단말, 고객 포털, 그리고 어느 순간 업무의 뼈대가 되어 버린 계획용 스프레드시트입니다. 어떤 것은 새 시스템의 표준 기능 안으로 흡수해 없애야 합니다. 어떤 것은 실제 경쟁력이며, 곧 바뀔 데이터베이스 스키마에 용접된 상태를 벗어나 독립된 애플리케이션으로 제대로 다시 만들어야 합니다.

우리는 그 둘을 구분하도록 돕고, 남길 가치가 있는 쪽을 만듭니다.

리포팅과 그림자 데이터 영역

오래 운영된 ERP에는 반드시 그 바깥에 리포트, 추출물, 스프레드시트 층이 자랍니다. 이것들은 전환 시점에 요란하게 깨지고, 계획에 들어 있는 경우는 거의 없습니다. 우리는 그것을 목록화하고, 업무가 실제로 의존하는 것을 가려내어, 새 데이터 모델에 맞춰 또는 그 변화로부터 리포트를 차단해 주는 리포팅 계층 위에 다시 만듭니다.

폐기와 데이터 보존

구 시스템에는 전원을 내린 뒤에도 법적으로 수년간 보관해야 하는 기록이 들어 있습니다. 보존 규정을 지키자고 ECC를 10년 동안 읽기 전용으로 켜 두는 것은 비싼 방법입니다. 우리는 감사인과 과세당국이 실제로 요구하는 검색과 내보내기 경로를 갖춘 접근 가능한 아카이브로 추출하도록 구축해, 구 시스템을 끌 수 있게 만듭니다.

우리가 하지 않는 일

SAP 기능 컨설팅 회사가 아닙니다. FI/CO를 구성하지 않고, 프로세스 템플릿을 설계하지 않으며, S/4HANA 프로그램을 총괄하는 파트너도 아닙니다. 그것들은 전문 영역이며 전문가를 쓰셔야 합니다.

우리는 그 파트너 옆에서, ERP가 닿지만 ERP 프로그램이 다루지 않는 모든 것을 맡는 엔지니어링 팀입니다. 실무에서는 고객사가 프로그램에서 자기 쪽을 지키기 위해 직접 계약하거나, 프로그램을 수행하는 시스템 통합 사업자의 하도급으로 참여합니다.

S/4HANA 전환 전체를 책임질 회사를 찾고 계신다면 우리는 그 회사가 아니라고 말씀드립니다. 세 번째 대화가 아니라 첫 번째 대화에서 말씀드리는 편이 낫다고 봅니다.

우리가 일하는 자리

S/4HANA 프로그램 옆에서: 연동 재구축, 데이터 마이그레이션 엔지니어링, 위성 애플리케이션 작업, 레거시 자산 폐기입니다.

SAP를 완전히 떠나는 마이그레이션: Odoo, Dynamics 365 Business Central, ERPNext, Netsuite 또는 업종 특화 시스템으로 옮기는 경우이며, S/4HANA가 과한 중견기업에서 가장 흔합니다. 여기서는 연동과 데이터 작업이 프로젝트의 대부분을 차지합니다.

Oracle, Dynamics AX/NAV, Infor 환경: 같은 수명주기 압력을 받고 있지만 관심은 덜 받는 곳들입니다.

아예 마이그레이션하지 않는 기업: 당분간 그대로 가기로 결정했고, 그동안 주변 시스템을 현대화하고 인터페이스를 지원 가능한 상태로 만들며 위험을 줄여야 하는 경우입니다.

프로젝트 진행 방식

디스커버리, 3~6주. 인터페이스 목록, 데이터 품질 진단, 위성 애플리케이션 검토, 그리고 주변 자산이 실제로 어떤 모습인지에 대한 보고서입니다. 이 단계는 의도적으로 단독 계약으로도 제공합니다. 여러 고객사가 이 결과를 근거로 시스템 통합 사업자 제안의 범위와 금액을 다시 협상했고, 그것만으로 비용 이상을 회수했습니다.

구축, 본 프로그램과 병행합니다. 연동 계층, 마이그레이션 파이프라인, 애플리케이션 재구축을 귀사 일정과 전환 목표일에 맞춰 진행합니다.

전환 지원, 리허설, 대사 실행, 그리고 테스트에서 끝내 제대로 돌려보지 못했던 인터페이스가 마침내 돌아가는 하이퍼케어 기간을 포함합니다.

폐기, 새 시스템이 안정되고 아카이브가 승인된 뒤에 진행합니다.

기술

애플리케이션 쪽은 Java, .NET, Python, Node.js, PHP. SAP 인터페이스 기술은 IDoc, BAPI, RFC, OData. 미들웨어는 MuleSoft, Apache Camel, Kafka, Azure Integration Services. 데이터베이스는 SQL Server, Oracle, DB2, HANA, PostgreSQL. 클라우드는 AWS와 Azure. 기존 자산이 더 오래된 것 위에서 돌고 있다면 (ERP 옆의 Delphi, VB6, PowerBuilder, COBOL 같은 것들) 그것은 놀랄 일이 아니라 익숙한 영역입니다.

자주 묻는 질문

SAP ECC 지원은 정확히 언제 종료되나요?

SAP ECC 6.0의 주력 유지보수는 2027년 12월 31일에 종료됩니다. 연장 유지보수는 추가 비용과 축소된 범위로 2030년 말까지 이용할 수 있습니다. 조건이 다르므로 사용 중인 인핸스먼트 팩과 계약에 대한 구체적인 내용은 SAP에 직접 확인하십시오.

이미 시스템 통합 사업자를 선정했습니다. 어디에 들어오시나요?

그 옆입니다. 통합 사업자가 ERP 전환을 맡고, 우리는 그 주변 자산을 맡습니다. 인터페이스, 데이터 엔지니어링, 위성 애플리케이션, 리포팅, 폐기입니다. 이 분담은 흔하고, 통합 사업자가 자기 전문 시스템에 집중할 수 있게 하며, 보통 계약 사이로 빠지는 부분에 책임자를 만들어 둡니다.

SAP를 완전히 벗어나는 것이 현실적인가요?

일부 기업에는 그렇습니다. 업무 중 표준으로 처리되는 비중이 얼마인지, 커스터마이즈에 들어 있는 부분이 얼마인지, 더 작은 플랫폼이 귀사의 물량과 규제 요구사항을 감당할 수 있는지에 달려 있습니다. 중견 제조사와 유통사에는 실제 선택지이고, 복잡한 다국적 그룹에는 좋지 않은 선택지입니다. 디스커버리 단계는 논쟁이 아니라 판단할 근거를 제공합니다.

인터페이스 목록화에는 얼마나 걸리나요?

중견 규모 환경 대부분에서 3~6주입니다. 대체로 접근성에 좌우됩니다. 로그, 소스 코드, 미들웨어 설정, 그리고 그것이 왜 존재하는지 기억하는 사람에게 얼마나 빨리 닿을 수 있느냐입니다.

시스템을 끈 뒤에도 감사를 위해 조회 가능하게 유지할 수 있나요?

가능합니다. 감사인과 과세당국이 요구하는 보존기간, 검색, 내보내기 기능을 갖춘 조회 가능한 아카이브로 추출하도록 구축합니다. 라이선스가 걸린 ERP를 10년 동안 읽기 전용으로 켜 두는 것보다 대개 훨씬 저렴합니다.

아직 마이그레이션하지 않기로 하면 어떻게 되나요?

그것도 정당한 결정이며, 특히 연장 유지보수가 2030년까지 가능하다는 점에서 그렇습니다. 그 경우 할 일은 그동안의 위험을 줄이는 것입니다. 인터페이스를 문서화하고 안정화하며, 아무도 쓰지 않는 것을 걷어내고, ERP 주변 애플리케이션을 현대화해 정작 옮길 때 주변 자산이 걸림돌이 되지 않게 하는 것입니다.

시작하기

무엇을 운영하고 계신지, 의사결정의 어느 단계에 계신지, 통합 사업자가 이미 선정되었는지 알려 주십시오. 주변 자산이 비용으로 얼마나 돌아올지, 그리고 우리라면 어디에서 시작할지 말씀드리겠습니다.

인터페이스 및 데이터 디스커버리 범위를 잡으시려면 문의해 주십시오.