다점포 직원 권한: 조회·입력·승인을 나누는 방법

신뢰와 접근 권한은 다른 문제입니다

직원을 믿더라도 다른 지점의 급여나 매입 정보를 업무상 볼 필요가 있는지는 별도입니다. 반대로 현장에서 해결해야 할 업무까지 막으면 매번 사장 계정으로 처리하게 됩니다. 공유 계정은 누가 어떤 판단을 했는지도 흐리게 만듭니다.

실제 업무로 권한표를 만드세요

역할 이름보다 실제 계정으로 시험하는 것이 중요합니다. 다른 지점 자료가 열리는지, 금액을 바꿀 수 있는지, 예외를 누구에게 넘기는지 확인하세요. 이동·승진·퇴사 시 권한 회수 담당자도 정합니다.

Storebase에서는 역할별 권한 카테고리를 열어 어떤 업무에 접근할 수 있는지 확인한 뒤 변경 내용을 저장할 수 있습니다. 팀이 맡을 책임 범위를 화면에서 분명히 정하는 데 도움이 되지만, 이 화면만으로 모든 제한이 실제로 적용된다고 단정하지 말고 직원 계정으로 확인하세요.

사장이 빠져도 통제는 남아야 합니다

새 권한을 준 뒤에는 제한된 기간 동안 실제 처리 사례를 확인합니다. 소프트웨어의 권한 기능이 표의 모든 행동을 지원한다고 가정하지 말고, 지원하지 않는 부분은 별도 승인 절차로 보완하세요.

목적은 직원의 손을 묶는 것이 아닙니다. 필요한 정보와 행동은 맡기고, 민감한 변경의 경계만 분명히 해서 사장이 일상적인 승인 대기열이 되지 않게 하는 것입니다.

각 행에 민감도·판단 한도·유효 기간을 더하세요

업무와 매장만 적은 권한표는 어떤 행동이 열렸는지만 보여 주므로 충분하지 않습니다. 각 행에 다루는 자료, 지점 범위, 허용 작업, 민감도, 업무 판단의 한계, 필요한 근거, 승인 경로, 종료 조건을 적으세요. 입력, 검토, 승인, 정정, 되돌리기, 내보내기, 권한 관리는 화면에서 가까워 보여도 서로 다른 행동입니다. 직급이 높다는 이유로 접근이 자동 상속되지 않도록 ‘업무상 필요 없음’이라는 결과도 명시합니다.

모든 부여에는 일하는 이유와 다시 확인할 담당자가 있어야 합니다. 임시 대체, 교육, 조사, 상시 책임에 같은 무기한 권한을 주면 안 됩니다. 시스템이 세밀한 업무 한도를 표현하지 못한다면 권한표가 기술적으로 강제된 것처럼 보이게 하지 말고 별도 확인 절차를 적으세요. 이런 간극을 미리 보이면 평범한 일을 끝내려고 관리자 계정을 빌리는 관행을 막을 수 있습니다.

자료가 민감할수록 볼 수 있다는 것과 사용할 수 있다는 것을 더 세밀하게 나눕니다. 조회가 필요한 직원에게 수정이나 내보내기까지 같이 줄 이유는 없습니다. 반대로 입력 담당자가 자신이 만든 항목의 최종 승인까지 맡아야 하는지도 별도 판단해야 합니다.

개별 권한보다 위험한 조합을 검토하세요

따로 보면 합리적인 두 권한도 함께 있으면 중요한 확인 단계를 없앨 수 있습니다. 민감한 기록을 만든 사람이 같은 건을 승인하거나, 값을 바꾼 사람이 예외를 닫거나, 지급 실행자가 최종 대사를 하거나, 접근을 부여한 사람이 자기 부여를 검토하는 경우가 그렇습니다. 실제 충돌은 매장 업무와 적용 의무에 따라 달라지므로 어디서나 쓰는 역할 분리표를 복사하지 말고 현실의 처리 흐름에서 찾으세요.

함께 두기 어려운 조합마다 역할 분리, 독립 검토, 기간 제한, 매장 제한, 다른 사람에게 가는 예외 목록 중 하나를 선택합니다. 그런 다음 위험이 없는 시험 자료로 결합 경로를 시도합니다. 긴급 대체 때문에 한 직원이 잠시 두 권한을 가져야 한다면 누가 허용했는지, 어떤 활동을 사후 확인할지, 언제 끝나는지를 남깁니다. 목적은 직원을 의심하는 것이 아닙니다. 점주가 모든 정상 입력을 직접 승인하지 않아도 오류나 오용을 발견할 수 있는 구조를 만드는 일입니다.

직원 계정에서 접근 자격을 다시 인증하세요

입사·이동·퇴사 흐름을 회귀 시험으로 만드세요. 통제된 직원 계정을 담당 매장에 배정하고 필요한 조회와 행동을 확인한 뒤, 금지된 지점과 민감 작업을 시도합니다. 역할을 바꾸고 같은 검사를 반복한 다음 배정을 제거하세요. 접근이 사라지기 전에 진행 중 업무가 새 담당자에게 넘어갔는지도 확인합니다. 결과는 관리자 기억이 아니라 권한표의 해당 행에 붙여 둡니다.

정기 검토에서는 부여된 권한과 실제 사용을 함께 봅니다. 오랫동안 쓰지 않은 민감 권한은 업무상 필요가 남아 있는지 다시 묻는 신호지만, 비수기에 사용하지 않았다는 이유만으로 계절 업무 권한을 기계적으로 없애서는 안 됩니다. 해당 업무 책임자에게 다음 사용 시점과 대체 가능성을 확인하고 유지, 축소, 만료 가운데 결론을 남기세요. 긴급 접근은 요청 사유, 승인자, 종료 시각, 수행 활동의 사후 검토를 갖춘 별도 경로로 다루고 종료 뒤 기본 권한으로 돌아왔는지 실제 계정에서 확인합니다.

달력만 기다리지 말고 권한 재검토를 시작하는 사건도 정합니다. 새 지점 배정, 직무 대행 종료, 급여·정산 책임 변경, 외부 협력 종료, 장기 휴직처럼 업무 경계가 움직인 날이 그 신호입니다. 검토자는 설정표뿐 아니라 진행 중인 과제, 저장된 내보내기, 공유된 자격 정보가 남았는지도 범위를 정해 확인합니다. 계정을 막았다는 한 줄 보고보다 어떤 접근을 회수했고 어떤 인계가 아직 열려 있는지를 보여 주는 기록이 다음 담당자의 판단에 더 유용합니다.

Storebase 역할 설정은 저장 전에 역할별 권한 범주를 검토하는 화면을 제공합니다. 이 근거만으로 모든 화면, 거래 경로, 내보내기, 남아 있는 로그인 상태, 기존 계정에서 제한이 집행된다고 증명할 수 없습니다. 기술적으로 접근할 수 있다는 사실이 상업·급여·회계 결정을 내릴 권한을 주는 것도 아닙니다. 표현 가능한 경계는 설정으로 구현하고, 영향을 받는 계정에서 다시 시험하며, 지원되지 않는 한계에는 별도 승인 단계를 유지하세요. 직원이 허용된 일을 끝내고 점주는 정해진 예외와 정기 접근 검토만 받을 때 권한 분리가 실제 시간을 돌려줍니다.