물품 보관소와 락커를 위한 소프트웨어

락커 프로그램 — 누구에게 어떤 칸을 줄지 결정하고, 필요한 순간에 그 전자 잠금장치를 열며, 열림마다 기록을 남기는 시스템입니다: 누가, 언제, 무슨 근거로.

보통 캐비닛과의 차이는 한 가지 예로 드러납니다. 열쇠나 자물쇠가 있으면 칸은 사람이 책임집니다: 열쇠를 내주고, 번호를 기억하고, 되받습니다. 열쇠를 잃어버리면 부수어 열어야 하고, 다툼은 근무조의 기억으로 풀며, 지금 몇 칸이 비었는지는 곁에 서 있는 사람만 압니다.

자동화된 칸에는 열쇠가 없습니다. 문을 열 권리는 데이터베이스의 기록입니다: 이러이러한 코드가 이러이러한 칸에 언제까지 유효하다는 기록. 코드는 캐비닛에 가지 않고도 발급하고, 회수하고, 연장하고, 다른 사람에게 넘길 수 있습니다. 그리고 모든 대상의 모든 칸의 사용 여부가 하나의 목록에 보입니다.

예. 쇼핑몰의 방문객이 칸에 짐을 맡깁니다: 화면에 QR 코드를 스캔하면 문이 열리고, 그는 문을 닫고 갑니다. 두 시간 뒤 같은 코드로 같은 칸을 엽니다. 시스템에는 두 번의 열림 기록, 보관 시작 시각, 그리고 칸이 비어 다음 이용을 받을 준비가 됐다는 표시가 남습니다.

물품 보관소 자동화 는 세 가지 질문의 답이 담당자의 머릿속에 더는 들어가지 않는 지점에서 시작합니다: 지금 몇 칸이 쓰이고 있는가, 오늘 14:20에 그 칸을 정확히 누가 열었는가, 이틀째 놓여 있는 물건을 어떻게 할 것인가.

시스템에서 가장 물리적인 부분이고, 프로그램이 진실을 말할지가 여기에 달려 있습니다. 전자 잠금장치 는 짧은 전기 신호로 열립니다: 전압이 오면 걸쇠가 빠지고 문이 풀립니다. 잠금장치 자체는 사람에 대해서도 코드에 대해서도 아무것도 모릅니다.

컨트롤러 — 잠금장치와 센서가 연결된, 캐비닛 안의 기기입니다. 서버에서 «27번 칸을 열라»는 명령을 받아 해당 출력에 신호를 보내고 결과를 돌려줍니다. 컨트롤러 하나가 수십 개의 칸을 담당하므로 캐비닛은 하나의 통신 회선으로 시스템에 연결됩니다.

문 센서 — 추측과 사실을 가르는 것입니다. 이것이 없으면 시스템은 명령이 나갔다는 것만 압니다. 있으면 문이 실제로 열렸다는 것과 몇 초 만에 닫혔는지를 압니다. 센서의 유무는 해당 캐비닛 모델의 문제이고, 작업을 시작하기 전에 확인합니다.

장비를 연결할 때 살펴보는 것:

• 잠금장치의 종류 — 펄스식인지 유지식인지, 걸쇠의 위치를 되돌려 주는지 아닌지
• 문 센서의 유무 — 시스템이 «열렸다»와 «열려고 했다»를 구분할 수 있는지가 여기에 달려 있습니다
• 컨트롤러의 인터페이스 — 명령을 정확히 어떻게 주고 상태를 어떤 형태로 돌려받는지
• 컨트롤러당 칸의 수 — 출력이 몇 개 쓰였고 캐비닛 확장을 위해 몇 개가 남는지
• 전원 — 전기가 끊겼을 때 잠금장치가 어떻게 되는지, 예비 전원이 있는지
• 기계식 개방 — 전기 없이 칸을 여는 비상 수단이 있는지, 그 권한은 누가 갖는지

저희는 특정 상표의 잠금장치와 컨트롤러 지원을 미리 선언하지 않습니다. 연결할 장비의 구성은 제조사 문서와 기기가 밖으로 내주는 인터페이스를 보고 사전 진단에서 정합니다; 준비된 인터페이스가 없는 경우에는 호환을 약속하는 대신 작업을 시작하기 전에 따로 해결합니다.

결제 모듈이 모두에게 필요하지는 않습니다: 직원용 락커와 클럽의 탈의 칸은 돈 없이 돌아갑니다. 하지만 칸을 빌려 주는 곳에서는 돈이 이용의 한 부분이 되고, 계산 규칙은 출입 규칙만큼 엄격하게 정해져야 합니다.

금액은 어떻게 계산되는가. 요금은 칸의 규격과 시간에 묶입니다. 가장 흔한 방식은 이렇습니다: 이용당 정액, 올림 처리하는 구간(시간, 일)당 요금, 첫 시간이 이후보다 비싼 계단식 요금, 그리고 장기 정기권.

결제는 언제 이뤄지는가. 이것도 프로젝트에서 정합니다. 고른 구간만큼 선결제하고 연장할 때 추가로 내는 방식이 현장 입장에서 가장 단순하고 예측 가능합니다. 이용이 끝난 뒤 실제 시간만큼 내는 방식은 사람이 낼 것이라는 보장 — 예를 들어 카드에 금액을 미리 승인해 두는 것 — 이 필요합니다.

시스템의 결제 부분에 속하는 것:

• 요금 — 규격, 현장, 시간대, 요일에 따라
• 금액 계산 — 실제 이용 시간에 따라, 올림 규칙과 함께
• 연장 — 이용을 끝내지 않고 추가 구간만큼 더 결제
• 기한 초과 — 결제한 시간을 넘긴 부분에 대한 별도의 요금
• 환불 — 칸 인도가 실패하면 돈은 현장에 남지 않고 돌아갑니다
• 결제와 이용의 연결 — 양방향입니다: 이용에서 결제가 보이고, 결제에서 칸과 시각이 보입니다
• 대사 — 매일 처리 내역을 결제 서비스의 내역과 맞춰 봅니다

경계를 분명히 밝힙니다. 구체적인 결제 수단 — 카드, 비접촉 결제, QR, 앱 결제, 지폐 인식기를 통한 현금 — 은 연결된 결제 서비스와 캐비닛의 장비에 달려 있습니다. 이는 어느 프로젝트에서나 쓸 수 있는 내장 기능이 아니라 사전 진단에서 구성을 정하는 연동입니다. 세무 처리에 대한 요구는 국가의 법과 기기 모델이 정합니다.

캐비닛은 지켜보는 사람 없이 서 있고, 그것이 캐비닛의 본질입니다. 그러므로 고장은 시스템이 스스로 알아채야 합니다 — 그러지 않으면 물건이 든 칸이 열리지 않은 방문객이 알려 주게 됩니다.

상시 관찰하는 것:

• 캐비닛과의 통신 — 컨트롤러가 제때 신호를 보내는지, 허용 간격보다 오래 침묵하는지
• 잠금장치의 응답 — 명령대로 칸이 열리는지, 센서가 결과를 확인해 주는지
• 문의 상태 — 닫힘, 열림, 기준보다 오래 열림, 명령 없이 열림
• 전원 — 캐비닛에 전원이 들어오는지, 언제 끊겼는지
• 주변기기 — 스캐너, 화면, 카드 리더, 결제 부품이 작동하는지
• 컨트롤러 오류 — 모델이 지원한다면 컨트롤러가 스스로 알리는 코드

침묵도 이벤트입니다. 통신에 잡히지 않는 캐비닛은 «다 평온하다»는 뜻이 아닙니다: 이백 개 칸과 그 안의 물건에 대해 아무것도 모른다는 뜻입니다. 그래서 통신 두절은 관찰의 빈칸으로 남지 않고 잠금장치 고장과 똑같은 이벤트를 만듭니다.

고장 난 칸은 어떻게 되는가. 자동으로 선택에서 빠집니다: 다음 사람에게 권하지 않습니다. 그 칸에 대해 캐비닛 번호, 칸 번호, 고장 설명이 담긴 작업이 서비스 팀에 만들어집니다. 칸을 순환으로 되돌리려면 작업 완료 표시가 있어야 합니다 — 저절로 «낫지» 않습니다.

장비 관리의 방식은 저희가 다음 시스템에서 쓰는 것과 같습니다 IoT 모니터링: 지표, 기준, 지속 시간, 이벤트, 담당자. 다른 점은 여기에서 재는 것이 온도가 아니라 잠금장치의 응답과 통신의 유무라는 것뿐입니다.

시스템은 데이터를 많이 쌓지만 그중 쓸모 있는 것은 몇 가지뿐입니다. 실질적인 의미가 있는 질문은 네 가지입니다: 칸이 충분한가, 어떤 크기가 필요한가, 어디에서 시간이 새는가, 어떤 장비를 손볼 때가 됐는가.

이용률이 보여 주는 것. 한 달 평균 수치가 아니라 시간과 요일에 따른 분포입니다: 평균 45%인 현장이라도 토요일 14시에서 18시 사이에는 소형 칸이 하나도 비어 있지 않을 수 있습니다. 해법은 캐비닛을 통째로 늘리는 것이 아니라 필요한 크기의 칸을 더하는 것입니다.

현장별로 계산하는 지표:

• 이용률 — 시간, 요일, 규격에 따른 사용 중 칸의 비율
• 회전율 — 한 칸을 기간 동안 몇 번의 이용이 지나가는지
• 평균 이용 시간 — 규격별로, 요일별로 따로
• 인도 거절 — 필요한 크기의 빈 칸이 없어 사람이 칸을 받지 못한 횟수
• 기한 초과 — 기한을 넘긴 이용의 비율과 그 이용이 칸을 붙잡고 있던 시간
• 장비의 가용성 — 칸이 순환에서 빠져 있던 시간과 그 사유
• 매출 — 유료 보관의 경우: 현장별, 규격별, 기간별

인도 거절은 가장 과소평가되는 지표입니다. 사용 현황은 누구에게나 보이지만, 와서 빈 칸을 찾지 못하고 돌아간 사람은 일반적인 통계에 아예 남지 않습니다. 그런데 캐비닛을 늘려야 하는지에 답하는 것이 바로 이 숫자입니다.

리포트는 파일로 내려받을 수 있고 일정에 따라 만들 수도 있습니다 — 예를 들어 매달 1일에 모든 현장을 한꺼번에.