물류 소프트웨어

물류 관리 시스템 — 운송을 기록하는 프로그램입니다: 요청을 받고, 그것으로 경로를 짜고, 담당자를 배정하고, 화물의 이동을 지켜보며, 배송마다 무슨 일이 있었는지의 이력을 보관합니다.

차이는 한 가지 예로 드러납니다. 시스템이 없으면 요청은 메신저에, 경로는 관제 담당의 종이에, 화물의 상태는 기사의 머릿속에 있습니다. 고객에게 «내 화물이 어디 있나요»에 답하려면 세 사람에게 전화해야 합니다. 내일 몇 대의 차가 적재되는지는 아무도 모릅니다, 그 숫자를 어디에서도 세지 않았기 때문입니다.

시스템에서는 같은 것이 모두 기록입니다. 요청에는 번호, 발송인, 수령인, 기한, 현재 상태가 있습니다. 경로에는 지점 목록, 방문 순서, 담당자가 있습니다. 화물에는 말이 아니라 프로그램의 동작으로 바뀌는 상태가 있습니다. «화물이 어디 있나»에 대한 답은 몇 초면 나오고 오늘 누가 근무하는지에 좌우되지 않습니다.

예. 고객이 목요일에 운송을 요청했습니다. 담당자가 주소와 크기를 확인해 금요일 경로에 요청을 넣었고, 시스템이 다른 여섯 개 지점과 함께 그것을 기사에게 배정했습니다. 아침에 기사가 작업 목록을 열어 화물 픽업을 표시하고, 저녁에 배송을 표시했습니다. 그동안 고객에게는 상태가 바뀌어 보였고, 금요일 저녁에 회사에는 요약이 준비돼 있었습니다: 몇 개 지점을 돌았고, 몇 건이 기한을 지켰으며, 어느 배송에서 문제가 있었는지.

물류 자동화 는 세 가지 질문의 답이 관제 담당의 머릿속에 더는 들어가지 않는 지점에서 시작합니다: 지금 몇 건의 요청이 진행 중인가, 특정 화물이 어디에 있는가, 어제 두 건의 배송이 왜 다음 날로 밀렸는가.

운송 요청 — 무엇을 어디로, 언제까지, 누구 비용으로, 어떤 조건으로 보내야 하는지 확정하는 문서입니다. 이후의 모든 것 — 경로, 담당자, 상태, 문서 — 이 그 번호에 묶입니다.

요청은 세 가지 경로 중 하나로 시스템에 들어옵니다: 매니저가 만들거나, 고객이 개인 계정에서 직접 작성하거나, 회사의 다른 프로그램이 API로 전달합니다. 출처는 달라도 이후의 길은 하나입니다 — 그러지 않으면 일부 주문에만 통하는 암묵적인 처리 순서가 생깁니다.

검증 — 형식이 아니라 별도의 단계입니다. 시스템은 필수 항목이 채워졌는지, 수령인이 목록에 있는지, 화물이 허용 크기에 들어가는지, 기한이 가능한 범위인지 살펴봅니다. 미심쩍은 요청은 조용히 경로로 가지 않습니다: 알기 쉬운 사유와 함께 확인 목록에 남습니다.

요청에 담기는 것:

• 번호, 생성일, 작성자와 출처 — 누가 어디에서 등록했는지
• 고객과 결제자가 서로 다르다면 각각
• 픽업 주소와 배송 주소, 양쪽의 담당자
• 화물 구성: 이름, 개수, 무게, 부피, 포장
• 배송 기한과 수령인이 편한 시간대
• 조건: 수령 시 결제, 파손 주의, 층으로 올려야 함, 두 사람이 필요함
• 연결된 문서: 거래명세서, 청구서, 다른 시스템의 주문

배송으로의 배정 — 요청이 의도이기를 그치고 일이 되는 순간입니다. 특정 날짜의 경로에 들어가고, 담당자가 붙고, 담당자의 목록에 작업이 생깁니다. 이때부터 요청은 관제 패널에서도, 기사의 앱에서도, 고객의 이력에서도 보입니다.

일부 수정은 하루의 계획을 바꿉니다: 새 주소가 경로에서 벗어날 수도 있고, 늘어난 무게가 배정된 차에 들어가지 않을 수도 있습니다. 그런 요청은 조용히 고쳐지지 않습니다 — 사유와 함께 관제 담당에게 재계획을 위해 돌아갑니다.

화물 — 물리적으로 옮겨지는 것입니다. 시스템에서는 요청과 이어진 별도의 기록입니다: 한 요청이 여러 개의 화물을 실을 수 있고, 한 번의 운행이 여러 요청의 화물을 실을 수 있습니다.

이렇게 나누는 것은 기록의 엄격함을 위해서가 아닙니다. 가장 자주 받는 질문에 답하는 것이 바로 화물 단위입니다: 몇 개가 나갔는지, 다 도착했는지, 어느 것이 파손됐는지, 무엇이 되돌아왔는지.

화물 상태의 모든 변화는 시각과 작성자가 붙은 이벤트입니다. 그래서 운송의 이력이 통째로 복원됩니다: 몇 시에 화물을 가져갔고, 어디에서 담당자 사이에 인계됐으며, 언제 수령인에게 전달됐고 누가 그것을 확인했는지.

담당자 사이의 인계 — 부수적인 결과가 아니라 별도의 작업입니다. 창고에서 분류장으로, 거기에서 주소로 가는 화물은 책임자가 최소 두 번 바뀝니다. 인계마다 명시적으로 기록합니다, 그러지 않으면 분실했을 때 어느 구간에서 없어졌는지 말할 수 없습니다.

«누구의 잘못인가»에 대한 답도 여기에서 나옵니다 — 잘못한 사람을 찾는다는 뜻이 아니라 구간을 가린다는 뜻으로. 수령인이 발견한 파손은 화물이 특정 담당자 앞으로 잡혀 있던 구간에 묶입니다.

창고와 물류는 단체 대화방을 공유하는 두 부서가 아니라 한 프로세스의 두 구간입니다. «모였지만 인계되지 않은» 화물과 «인계됐지만 표시되지 않은» 화물은 서로 다른 두 상태이고, 그것을 혼동하면 비쌉니다.

하나의 디지털 프로세스라는 말은 한 가지를 뜻합니다: 창고와 배송 사이의 모든 전환이 메시지가 아니라 동작으로 기록된다는 것. 창고 담당자가 피킹을, 기사가 화물 인수를, 수령인이 수령을 표시합니다. 이 표시들 사이에서 화물은 언제나 특정 구간 앞으로 잡혀 있습니다.

접점이 창고에 주는 것: 무엇이 이미 나갔고 무엇이 이틀째 출고 구역에 서 있는지 보입니다. 물류에 주는 것: 아직 모이지 않은 화물로 경로를 짜지 않고, 실을 것이 생기기 전에 기사가 문 앞에 오지 않습니다.

완전한 창고 관리 — 입고, 적치, 재고 조사, 배치와 유통기한 — 는 별도의 페이지에서 다룹니다. 여기에서는 접점만 설명합니다: 창고가 물류에 무엇을 넘기고 무엇을 돌려받는지.

리포트는 데이터가 동작하는 순간에 시스템으로 들어오는 곳에서만 의미가 있습니다. 상태를 저녁에 «하루를 마치며» 찍는다면 어떤 리포트든 실제로 벌어진 일과 무관한 말끔한 그림을 보여 줄 것입니다.

쌓인 데이터로 계산하는 것:

• 배송 건수 — 하루, 한 주, 한 달; 방면별, 고객별, 담당자별
• 완료된 주문과 문제가 있는 주문 — 기한 안에 배송된 비율과 다르게 끝난 것들의 목록을 사유와 함께
• 배송 소요 — 요청에서 전달까지, 그리고 배송 인계에서 수령까지의 실제 시간
• 이용률 — 차와 담당자에게 지점, 무게, 부피가 얼마나 돌아가고 얼마가 남는지
• 경로의 효율 — 근무조당 지점 수, 계획대로 닫힌 비율, 정차 사이의 시간
• 작업 이력 — 요약 수치만이 아니라 개별 사례를 확인하기 위한 출처

지표의 정의는 한 번 정해 모든 리포트가 함께 씁니다. «기한 내 배송»은 관제 담당의 리포트와 책임자의 리포트에서 같은 것을 뜻해야 합니다 — 그러지 않으면 같은 날의 두 요약이 맞지 않고, 둘 다 신뢰를 잃습니다.

리포트는 파일로 내려받고, 일정에 따라 만들며, API로 외부 분석 시스템에 보낼 수도 있습니다 — 보내는 내용의 구성은 프로젝트가 정합니다.