01 · 화면보다 현재 업무 흐름을 먼저 그리세요
업무시스템 개발은 화면 목록부터 만드는 것보다 지금 일이 어떤 순서로 진행되는지 파악하는 것이 먼저입니다. 누가 입력하고, 누가 승인하며, 어떤 시점에 상태가 바뀌고, 어떤 데이터가 다음 단계로 넘어가는지 정리해야 합니다.
엑셀과 메신저, 종이장부가 섞여 있다면 같은 정보를 여러 번 입력하는 구간과 담당자 사이에서 누락되는 구간을 찾는 것이 좋습니다.
02 · 데이터와 권한을 함께 설계하세요
하나의 데이터라도 관리자, 직원, 거래처가 볼 수 있는 범위가 다를 수 있습니다. 수정 권한과 삭제 권한도 분리해야 할 수 있습니다. 누가 언제 무엇을 바꿨는지 이력이 필요한 업무도 있습니다.
초기 DB 구조가 업무 개념과 맞아야 나중에 통계·검색·자동화를 붙이기 쉽습니다.
03 · 상태 변경의 기준을 하나로 정하세요
주문, 작업, 재고, 정산 같은 데이터는 여러 화면에서 상태를 바꾸기 시작하면 서로 불일치하기 쉽습니다. 실제 업무 이벤트를 기준으로 상태 변경 지점을 정하는 것이 중요합니다.
예를 들어 재고를 주문 시점에 줄일지, 출고 완료 시점에 줄일지, 실제 바코드 스캔을 기준으로 할지에 따라 전체 로직이 달라집니다.
입출고 스캔을 재고 변화의 기준으로 고정
금산골드에서는 재고가 주문 상태에 따라 여러 번 바뀌지 않도록 실제 입고·출고 스캔을 기준으로 두고, 해당 데이터가 가격 재계산과 정산·미수금·리포트로 연결되게 설계했습니다.
구축 사례 보기 ↗04 · 자동화는 반복 업무부터 적용하세요
알림, 가격 계산, 상태 전환, 리포트 집계, 외부 API 호출처럼 사람이 반복해서 처리하는 업무는 자동화 후보가 됩니다. 다만 예외가 많거나 판단이 필요한 업무를 무리하게 자동화하면 오히려 관리가 어려워질 수 있습니다.
AI/API도 필요한 경우 연동할 수 있지만 지속 사용료와 운영 비용까지 포함해 실제 효과를 기준으로 결정하는 편이 좋습니다.
05 · 한 번에 ERP 전체를 만들 필요는 없습니다
가장 불편한 업무 한두 개를 먼저 시스템화하고 실제 사용 후 다음 기능을 확장하는 방식이 안전할 수 있습니다. 초기부터 모든 부서를 묶으면 요구사항이 커지고 실제 사용자 피드백을 반영하기 어려워질 수 있습니다.
핵심 데이터 구조만 확장 가능하게 설계하면 주문→재고→정산→통계처럼 단계적으로 연결할 수 있습니다.
06 · 상담 전에 준비하면 좋은 자료
완벽한 요구사항 문서가 없어도 됩니다. 현재 쓰는 자료가 오히려 실제 업무를 이해하는 데 도움이 됩니다.