시스템 연동, 엑셀로 옮겨 적는 일을 줄이려면?
주문은 쇼핑몰에서 받고, 재고는 ERP에서 확인하고, 배송 정보는 엑셀로 내려받아 다시 등록합니다.
프로그램은 여러 개인데, 그 사이를 연결하는 일은 직원이 합니다.
시스템 연동은 서로 다른 프로그램이 데이터를 주고받아 중복 입력과 수작업을 줄이도록 연결하는 작업입니다. 다만 정보를 보내는 기능만 만들면 끝나는 것은 아닙니다.
어떤 데이터를 기준으로 삼고, 변경이나 오류가 생기면 어떻게 처리할지까지 정해야 옮겨 적던 일을 실제로 줄일 수 있습니다.
연결했는데 왜 다시 확인해야 할까요?
쇼핑몰 주문을 ERP로 자동 전송했다고 가정해보겠습니다.
처음에는 담당자가 주문서를 내려받지 않아도 돼 편합니다.
그런데 고객이 옵션을 바꾸거나 일부 상품을 취소하면 ERP에는 처음 접수한 정보가 그대로 남습니다.
결국 직원은 두 화면을 열고 주문이 달라졌는지 확인해야 합니다.
주문을 가져오는 기능은 있지만 주문이 바뀌는 상황까지 연결하지 않은 것입니다.
그래서 연동 범위를 정할 때는 ‘주문 정보 전송’이라는 항목을 더 구체적으로 풀어야 합니다.
언제 주문을 가져오는지, 변경된 내용은 언제까지 반영하는지, 이미 출고를 시작했다면 누가 확인해야 하는지 정해야 합니다.
데이터가 한 번 이동하는 것과 업무가 끝까지 이어지는 것은 다릅니다.
같은 상품인데 이름부터 다릅니다
시스템 연동을 시작하면 연결 방식보다 데이터 정리가 먼저 필요한 경우도 있습니다.
쇼핑몰에서는 ‘화이트 대형’, 창고에서는 ‘WH-L’, 거래명세서에서는 ‘백색 대’라고 기록한 상황을 생각해보세요.
사람은 문맥을 보고 같은 상품이라고 판단할 수 있지만, 시스템에는 이를 구분하고 연결할 기준이 필요합니다.
상품명뿐 아니라 거래처, 옵션, 단위도 마찬가지입니다.
한쪽은 낱개로, 다른 쪽은 박스로 수량을 관리한다면 숫자만 그대로 보내서는 재고가 맞지 않을 수 있습니다.
따라서 연동 전에 공통으로 사용할 코드를 정하거나 각 시스템의 항목을 연결하는 대응표를 만들어야 합니다.
이 과정에서 중복과 누락을 정리하지 않으면 자동화가 잘못된 정보를 더 빠르게 퍼뜨릴 수도 있습니다.
어느 쪽 정보가 맞는지 정했나요?
두 시스템에서 같은 항목을 수정할 수 있다면 값이 달라졌을 때 적용할 기준이 필요합니다.
예를 들어 담당자가 ERP에서 배송지를 수정했는데 쇼핑몰의 이전 주소가 다시 전달된다면 어떻게 해야 할까요?
마지막으로 들어온 값을 무조건 적용하면 직원이 확인해서 고친 내용을 되돌릴 수 있습니다.
그래서 항목과 처리 단계별로 어느 시스템을 기준으로 삼을지 정해야 합니다.
주문 접수 전에는 쇼핑몰 정보를 따르되, 출고 준비 이후의 주소 변경은 담당자 확인을 거치게 하는 식입니다.
구체적인 기준은 실제 운영 방식에 맞춰야 합니다.
모든 데이터를 양쪽에서 자유롭게 수정하도록 만드는 것보다 입력하는 곳과 확인하는 곳을 구분하는 편이 업무를 단순하게 만들 수 있습니다.
실시간으로 연결해야 좋은 연동일까요?
새 정보가 생길 때마다 바로 전달하는 방식이 항상 필요한 것은 아닙니다.
재고 부족으로 중복 판매가 발생할 수 있는 업무와 하루가 끝난 뒤 실적을 모으는 보고 업무는 요구하는 갱신 속도가 다릅니다.
모든 정보를 실시간으로 맞추려 하면 처리할 상황과 장애 대응 범위가 늘어날 수 있습니다.
먼저 “정보가 얼마나 늦어지면 문제가 생기나요?”라고 물어보세요.
즉시 반영할 항목, 일정 간격으로 갱신할 항목, 담당자 확인 후 전달할 항목을 나누면 필요한 수준에 맞춰 연동 범위를 정할 수 있습니다.
실시간이라는 표현보다 업무에 필요한 시점에 정확한 정보가 있는지가 중요합니다.
실패했을 때 사람이 무엇을 볼 수 있나요?
연결 대상 시스템이 잠시 응답하지 않거나 필수 정보가 빠져 전송에 실패할 수도 있습니다.
이때 실패한 사실을 알 수 없다면 직원은 주문이 누락된 뒤에야 문제를 발견하게 됩니다.
반대로 같은 정보를 무작정 다시 보내면 중복 등록을 막는 처리가 없는 경우 같은 주문이 여러 번 만들어질 수 있습니다.
누락과 중복을 확인할 기준
어떤 주문을 처리했는지 구분하고, 실패한 건만 찾아 다시 처리할 수 있어야 합니다.
전송 기록에는 오류 원인을 확인할 정보도 필요합니다.
사람이 처리할 예외
모든 오류를 자동으로 해결하려고 할 필요는 없습니다.
상품 코드가 없는 주문처럼 판단이 필요한 건은 담당자가 확인할 목록으로 남기는 방법도 있습니다.
자동화 이후에도 남는 업무가 무엇인지 보여야 운영자가 어디에 개입해야 하는지 알 수 있습니다.
API가 있다고 바로 연결되는 것은 아닙니다
API는 시스템끼리 데이터를 주고받는 데 사용하는 대표적인 연결 수단입니다.
하지만 API를 제공한다는 설명만으로 필요한 작업이 모두 가능한지는 알 수 없습니다.
조회만 가능한지 수정도 가능한지, 필요한 항목을 제공하는지, 접근 권한과 이용 조건은 무엇인지 확인해야 합니다.
API가 없거나 기능이 제한적이라면 파일 업로드나 다른 연결 방식을 검토할 수 있습니다.
이때도 운영 안정성과 유지관리 부담을 함께 비교해야 합니다.
기술 이름부터 고르기보다 주고받을 정보와 처리할 업무를 먼저 정해야 하는 이유입니다.
오코랩스는 직원이 연결하던 구간부터 봅니다
시스템 연동의 효과는 연결한 프로그램 수보다 반복 입력과 확인 작업이 얼마나 줄었는지로 살펴야 합니다.
오코랩스는 직원이 어떤 화면에서 정보를 확인하고, 어디로 옮기며, 어떤 예외를 직접 처리하는지부터 살펴봅니다.
그 흐름을 바탕으로 데이터 기준과 전송 시점, 오류 처리와 담당자의 확인 범위를 정리합니다.
같은 내용을 여러 프로그램에 입력하고 있다면 현재 사용하는 시스템과 반복 작업 하나를 알려주세요.
오코랩스가 먼저 연결할 업무와 필요한 개발 범위를 정리하는 것부터 함께하겠습니다.
시스템 연동, 엑셀로 옮겨 적는 일을 줄이려면?
주문은 쇼핑몰에서 받고, 재고는 ERP에서 확인하고, 배송 정보는 엑셀로 내려받아 다시 등록합니다.
프로그램은 여러 개인데, 그 사이를 연결하는 일은 직원이 합니다.
시스템 연동은 서로 다른 프로그램이 데이터를 주고받아 중복 입력과 수작업을 줄이도록 연결하는 작업입니다. 다만 정보를 보내는 기능만 만들면 끝나는 것은 아닙니다.
어떤 데이터를 기준으로 삼고, 변경이나 오류가 생기면 어떻게 처리할지까지 정해야 옮겨 적던 일을 실제로 줄일 수 있습니다.
연결했는데 왜 다시 확인해야 할까요?
쇼핑몰 주문을 ERP로 자동 전송했다고 가정해보겠습니다.
처음에는 담당자가 주문서를 내려받지 않아도 돼 편합니다.
그런데 고객이 옵션을 바꾸거나 일부 상품을 취소하면 ERP에는 처음 접수한 정보가 그대로 남습니다.
결국 직원은 두 화면을 열고 주문이 달라졌는지 확인해야 합니다.
주문을 가져오는 기능은 있지만 주문이 바뀌는 상황까지 연결하지 않은 것입니다.
그래서 연동 범위를 정할 때는 ‘주문 정보 전송’이라는 항목을 더 구체적으로 풀어야 합니다.
언제 주문을 가져오는지, 변경된 내용은 언제까지 반영하는지, 이미 출고를 시작했다면 누가 확인해야 하는지 정해야 합니다.
데이터가 한 번 이동하는 것과 업무가 끝까지 이어지는 것은 다릅니다.
같은 상품인데 이름부터 다릅니다
시스템 연동을 시작하면 연결 방식보다 데이터 정리가 먼저 필요한 경우도 있습니다.
쇼핑몰에서는 ‘화이트 대형’, 창고에서는 ‘WH-L’, 거래명세서에서는 ‘백색 대’라고 기록한 상황을 생각해보세요.
사람은 문맥을 보고 같은 상품이라고 판단할 수 있지만, 시스템에는 이를 구분하고 연결할 기준이 필요합니다.
상품명뿐 아니라 거래처, 옵션, 단위도 마찬가지입니다.
한쪽은 낱개로, 다른 쪽은 박스로 수량을 관리한다면 숫자만 그대로 보내서는 재고가 맞지 않을 수 있습니다.
따라서 연동 전에 공통으로 사용할 코드를 정하거나 각 시스템의 항목을 연결하는 대응표를 만들어야 합니다.
이 과정에서 중복과 누락을 정리하지 않으면 자동화가 잘못된 정보를 더 빠르게 퍼뜨릴 수도 있습니다.
어느 쪽 정보가 맞는지 정했나요?
두 시스템에서 같은 항목을 수정할 수 있다면 값이 달라졌을 때 적용할 기준이 필요합니다.
예를 들어 담당자가 ERP에서 배송지를 수정했는데 쇼핑몰의 이전 주소가 다시 전달된다면 어떻게 해야 할까요?
마지막으로 들어온 값을 무조건 적용하면 직원이 확인해서 고친 내용을 되돌릴 수 있습니다.
그래서 항목과 처리 단계별로 어느 시스템을 기준으로 삼을지 정해야 합니다.
주문 접수 전에는 쇼핑몰 정보를 따르되, 출고 준비 이후의 주소 변경은 담당자 확인을 거치게 하는 식입니다.
구체적인 기준은 실제 운영 방식에 맞춰야 합니다.
모든 데이터를 양쪽에서 자유롭게 수정하도록 만드는 것보다 입력하는 곳과 확인하는 곳을 구분하는 편이 업무를 단순하게 만들 수 있습니다.
실시간으로 연결해야 좋은 연동일까요?
새 정보가 생길 때마다 바로 전달하는 방식이 항상 필요한 것은 아닙니다.
재고 부족으로 중복 판매가 발생할 수 있는 업무와 하루가 끝난 뒤 실적을 모으는 보고 업무는 요구하는 갱신 속도가 다릅니다.
모든 정보를 실시간으로 맞추려 하면 처리할 상황과 장애 대응 범위가 늘어날 수 있습니다.
먼저 “정보가 얼마나 늦어지면 문제가 생기나요?”라고 물어보세요.
즉시 반영할 항목, 일정 간격으로 갱신할 항목, 담당자 확인 후 전달할 항목을 나누면 필요한 수준에 맞춰 연동 범위를 정할 수 있습니다.
실시간이라는 표현보다 업무에 필요한 시점에 정확한 정보가 있는지가 중요합니다.
실패했을 때 사람이 무엇을 볼 수 있나요?
연결 대상 시스템이 잠시 응답하지 않거나 필수 정보가 빠져 전송에 실패할 수도 있습니다.
이때 실패한 사실을 알 수 없다면 직원은 주문이 누락된 뒤에야 문제를 발견하게 됩니다.
반대로 같은 정보를 무작정 다시 보내면 중복 등록을 막는 처리가 없는 경우 같은 주문이 여러 번 만들어질 수 있습니다.
누락과 중복을 확인할 기준
어떤 주문을 처리했는지 구분하고, 실패한 건만 찾아 다시 처리할 수 있어야 합니다.
전송 기록에는 오류 원인을 확인할 정보도 필요합니다.
사람이 처리할 예외
모든 오류를 자동으로 해결하려고 할 필요는 없습니다.
상품 코드가 없는 주문처럼 판단이 필요한 건은 담당자가 확인할 목록으로 남기는 방법도 있습니다.
자동화 이후에도 남는 업무가 무엇인지 보여야 운영자가 어디에 개입해야 하는지 알 수 있습니다.
API가 있다고 바로 연결되는 것은 아닙니다
API는 시스템끼리 데이터를 주고받는 데 사용하는 대표적인 연결 수단입니다.
하지만 API를 제공한다는 설명만으로 필요한 작업이 모두 가능한지는 알 수 없습니다.
조회만 가능한지 수정도 가능한지, 필요한 항목을 제공하는지, 접근 권한과 이용 조건은 무엇인지 확인해야 합니다.
API가 없거나 기능이 제한적이라면 파일 업로드나 다른 연결 방식을 검토할 수 있습니다.
이때도 운영 안정성과 유지관리 부담을 함께 비교해야 합니다.
기술 이름부터 고르기보다 주고받을 정보와 처리할 업무를 먼저 정해야 하는 이유입니다.
오코랩스는 직원이 연결하던 구간부터 봅니다
시스템 연동의 효과는 연결한 프로그램 수보다 반복 입력과 확인 작업이 얼마나 줄었는지로 살펴야 합니다.
오코랩스는 직원이 어떤 화면에서 정보를 확인하고, 어디로 옮기며, 어떤 예외를 직접 처리하는지부터 살펴봅니다.
그 흐름을 바탕으로 데이터 기준과 전송 시점, 오류 처리와 담당자의 확인 범위를 정리합니다.
같은 내용을 여러 프로그램에 입력하고 있다면 현재 사용하는 시스템과 반복 작업 하나를 알려주세요.
오코랩스가 먼저 연결할 업무와 필요한 개발 범위를 정리하는 것부터 함께하겠습니다.