업무 시스템 현대화를 오프쇼어 개발 파트너에게 맡길 때, “기존 기능을 모두 유지한다”는 요구는 쉽게 합의할 수 있어 보입니다. 하지만 기존 화면 목록만으로는 지금도 필요한 기능, 서로 중복되는 기능, 사용자가 명확하지 않은 기능을 구분하기 어렵습니다.
SIer, CTO, DX 담당자에게 제안하는 첫 단계는 개발 범위를 확정하기 전에 기능별로 재개발, 임시 유지, 추가 조사, 폐지 후보를 정리한 의사결정 목록을 만드는 것입니다.
1. 화면보다 업무를 먼저 확인하기
각 기능을 누가, 어떤 업무에서, 언제 사용하는지, 그 결과를 누가 받는지 기록합니다. 업무 부서와의 인터뷰 내용을 기존 문서, 출력 보고서, 자동 처리 일정 등 확인 가능한 자료와 대조합니다.
일정 기간 접속 기록이 없었다는 사실만으로 사용하지 않는 기능이라고 판단해서는 안 됩니다. 기간 마감 처리, 연간 업무, 드물게 발생하는 상황을 별도로 확인하세요. 다른 시스템이 해당 기능의 결과를 사용하는지도 살펴봐야 합니다.
2. 결정마다 근거와 승인자를 남기기
검토 목록에는 기능, 업무 책임자, 사용 근거, 의존 관계, 처리 방향, 승인자, 재검토일을 기록할 수 있습니다. 처리 방향은 다음 네 가지로 구분합니다.
- 재개발: 업무상 필요가 여전히 존재하며 유지해야 할 결과가 명확한 경우입니다.
- 임시 유지: 의존 관계가 남아 있으므로 유지 기한과 운영 책임자를 지정합니다.
- 추가 조사: 판단 근거가 부족하므로 질문, 답변 담당자, 확인 기한을 정합니다.
- 폐지 후보: 대체 수단이 있거나 필요가 사라진 경우로, 업무 책임자의 승인을 받아야 합니다.
개발팀은 기술적 영향을 평가하고, 업무상 필요 여부는 고객 측의 권한 있는 담당자가 결정합니다. 답변이 없다는 이유로 기능 제거에 동의했다고 간주하지 않습니다.
3. 가상 사례: 비슷해 보이는 두 매출 보고서
한 SIer가 일본 기업의 주문 관리 시스템을 재구축한다고 가정해 보겠습니다. 기능 목록에 비슷한 매출 보고서가 두 개 있어, 프로젝트팀은 개발 범위를 줄이기 위해 하나로 통합하자고 제안합니다.
회계 부서에 확인한 결과, 두 번째 보고서는 연간 대사에 사용되며 월간 보고서와 취소 주문 처리 규칙이 다르다는 사실을 알게 됩니다. 이때는 대사 업무의 요구사항을 유지하고 규칙을 명확히 한 뒤, 데이터 소스를 공통으로 사용할 수 있는지 검토하는 것이 적절합니다. 화면 통합 여부는 별도로 판단합니다. 이는 설명을 위한 가상 사례이며 TECHNEST의 프로젝트나 성과가 아닙니다.
4. 제외하는 기능도 계획에 명시하기
기능 폐지에 합의했다면 과거 데이터를 어떻게 조회할지, 누가 문의에 대응할지, 어떤 조건에서 결정을 재검토할지 기록합니다. 데이터 보관 방안은 별도로 합의하세요. 기능을 폐지한다고 해서 데이터를 자동으로 삭제하는 것은 아닙니다.
승인된 목록을 개발 요구사항 및 인수 기준과 함께 관리합니다. 일본과 베트남 팀이 공통 기능 ID와 의사결정 기록을 사용하면 같은 대상을 기준으로 확인할 수 있습니다. 미확정 항목은 가정이나 조사 과제로 명시하고, 설명 없이 견적에 포함하거나 제외하지 않도록 합니다.
5. TECHNEST와 함께 검토하기
TECHNEST는 일본 시장을 대상으로 업무 시스템 설계·개발과 레거시 현대화를 수행해 온 다년간의 경험을 갖추고 있으며, 일본 컨설팅 파트너와도 협업하고 있습니다. 구체적인 업무 흐름 하나와 처리 방향을 결정하지 못한 기능 목록을 바탕으로 논의를 시작할 것을 제안합니다.
업무 시스템 서비스를 살펴보거나 TECHNEST에 문의하세요. 개발에 앞서 조사 범위와 합의할 산출물을 함께 정리하겠습니다.
