비즈니스 앱 데이터베이스에서 고아 레코드 방지하기

고아 레코드가 일상 업무에 만드는 문제

고아 레코드는 여전히 존재하지만 더 이상 담당하는 사람이나 팀이 명확하지 않은 레코드입니다. 직원이 퇴사하거나 고객 계정의 담당자가 바뀌거나 팀이 통합될 때 이런 일이 자주 발생합니다. 데이터는 데이터베이스에 남아 있지만, 그 데이터를 바탕으로 한 업무는 멈춥니다.

Maya에게 배정된 지원 티켓을 예로 들어 보겠습니다. 관리자가 Maya의 사용자 계정을 삭제하면서 처리 중인 티켓을 다른 사람에게 옮기지 않으면, 해당 티켓이 모든 상담원의 작업 큐에서 사라질 수 있습니다. 고객은 답변을 기다리지만 지원팀은 다른 누군가가 그 요청을 맡고 있다고 생각합니다.

영업 레코드에서도 같은 문제가 생깁니다. 퇴사하는 영업 담당자가 수십 개의 계정, 후속 작업, 견적을 맡고 있을 수 있습니다. 대체 담당자가 없으면 갱신일을 놓치고 새로운 문의도 처리되지 않은 채 남습니다. 더 이상 회사에 다니지 않는 관리자를 가리키는 승인 요청도 멈출 수 있습니다.

실제로 나타나는 영향은 다음과 같습니다.

• 어떤 큐에도 미배정 작업이 표시되지 않아 직원이 마감일을 놓칩니다.
• 고객이 늦은 답변이나 서로 다른 안내를 받습니다.
• 관리자가 어떤 레코드를 누가 처리해야 하는지 알 수 없습니다.
• 보고서에 업무량이 빠진 채 표시되고 결과도 왜곡됩니다.
• 더 이상 접근 권한이 없어야 하는 사람에게 민감한 데이터가 계속 보일 수 있습니다.

데이터베이스에서 고아 레코드를 방지하려면 소유권을 앱 전체에 적용되는 규칙으로 다뤄야 합니다. 티켓은 상담원과 지원팀에 동시에 속할 수 있습니다. 계정은 영업 담당자에게 속하고 관련 청구서는 재무팀에 속할 수 있습니다. 사람들이 앱을 사용하기 전에 이런 관계를 정의하세요.

삭제된 사용자, 비활성 사용자, 보관된 레코드는 서로 다른 상태입니다. 사용자를 삭제하면 계정이 사라지고 그 사용자가 소유한 레코드와의 연결이 끊길 수 있습니다. 사용자를 비활성 상태로 바꾸면 이력은 남지만 앱이 그 사용자에게 새 작업을 배정해서는 안 됩니다. 레코드를 보관하면 일상적인 화면에서 숨겨지지만 감사, 보고, 복구를 위해 계속 확인할 수 있습니다.

예를 들어 완료된 지원 티켓은 정해진 기간이 지나면 보관할 수 있습니다. 반면 비활성 상담원이 맡고 있는 미처리 티켓은 팀 큐나 지정된 대체 담당자에게 옮겨야 합니다. 이 차이를 명확히 하면 누군가 처리해야 할 레코드가 보이지 않게 되는 일을 막을 수 있습니다.

각 레코드에서 소유권이 의미하는 것 정하기

양식이나 자동화를 만들기 전에 소유권을 정의하세요. 각 레코드에 대해 다음 작업을 담당하는 주체가 특정 직원인지, 팀인지, 시스템 프로세스인지 결정합니다. 고객 지원 티켓은 상담원에게 속할 수 있습니다. 영업 계정은 지역 팀에 속할 수 있습니다. 예약된 가져오기는 시스템 계정에 속할 수 있습니다.

담당자가 업무에 영향을 주는 레코드를 목록으로 정리하세요. 일반적인 예로 고객, 리드, 거래, 작업, 지원 케이스, 승인, 주문, 내부 요청이 있습니다. 별도의 조치가 필요하지 않은 레코드에는 개인 담당자가 필요하지 않을 수 있습니다. 그래도 보고와 오류 처리를 위해 팀이나 시스템 담당자는 필요할 수 있습니다.

레코드를 만든 사람이 현재 담당자라고 가정하지 마세요. 두 역할은 자주 다릅니다. 행사 후 코디네이터가 리드를 입력하고 영업 담당자가 후속 연락을 맡을 수 있습니다. 이력이 중요하다면 두 필드를 모두 저장하세요. «작성자»는 누가 레코드를 입력했는지 보여 주고, «현재 담당자»는 지금 누가 처리해야 하는지 보여 줍니다.

모든 소유권 필드에는 하나의 기준 데이터만 사용하세요. 영업 화면에는 계정 관리자가 표시되고 지원 화면에는 별도의 연락처 담당자가 표시된다면 직원들은 결국 서로 다른 이름을 보게 됩니다. 소유권 필드를 기본 레코드에 두고 레코드가 표시되는 모든 곳에서 같은 필드를 보여 주세요. 이렇게 하면 직원이 퇴사하거나 팀이 바뀔 때 데이터베이스에서 고아 레코드가 생기는 일을 줄일 수 있습니다.

공동 소유에는 경계가 필요합니다. «영업 및 지원» 같은 라벨은 유연해 보이지만 두 팀 모두 상대방이 답변하기를 기다리게 만들 수 있습니다. 여러 사람이 레코드를 보고 수정하거나 기여할 수 있더라도 다음 작업의 책임은 한 사람이나 한 팀에 지정하세요.

필드 옆에 정의를 쉬운 말로 적으세요. 예를 들면 다음과 같습니다. «현재 담당자는 다음 고객 연락을 책임지는 사람입니다.» 이 문장은 앱을 만드는 사람에게 분명한 기준을 주고 직원에게도 일관된 배정 방식을 알려 줍니다.

비즈니스 앱 데이터베이스 설계에서 소유권은 검사가 필요한 관계입니다. 앱은 비활성 직원을 담당자로 선택하지 못하게 하고 팀에 활성 구성원이 없을 때 대체 담당자를 보여 줘야 합니다. AppMaster의 Data Designer에서 이런 관계를 모델링하고, 비즈니스 프로세스를 통해 레코드를 만들거나 업데이트할 때 같은 소유권 규칙을 적용할 수 있습니다.

화면을 만들기 전에 관계 매핑하기

페이지가 아니라 레코드부터 시작하세요. 화면은 깔끔해 보여도 그 뒤의 데이터 연결이 불분명할 수 있습니다. 앱에 필요한 레코드를 간단히 그려 보고 각 하위 레코드를 이를 소유하거나 설명하는 레코드와 연결하세요.

고객 지원 앱을 예로 들면 고객 한 명에게 여러 티켓이 있을 수 있습니다. 각 티켓에는 메모, 작업, 첨부 파일, 메시지가 연결될 수 있습니다. 티켓은 이런 업무 레코드의 상위 레코드이고 고객은 더 넓은 맥락을 제공합니다. 이 맵을 만들면 양식이나 대시보드를 만들기 전에 고아 레코드를 방지할 수 있습니다.

업무 데이터와 참조 데이터 분리하기

참조 레코드와 진행 중인 업무를 설명하는 레코드를 분리하세요. 제품, 서비스 카테고리, 지역, 상태 라벨은 여러 곳에서 공유하는 참조 데이터입니다. 티켓, 영업 기회, 청구서, 내부 요청은 특정 사건이나 업무를 설명합니다.

티켓은 제품 카테고리를 가리킬 수 있지만 카테고리가 티켓을 소유하는 것은 아닙니다. 관리자가 카테고리를 삭제하면 앱은 영향을 받는 티켓에 대체 카테고리를 선택하도록 안내해야 합니다. 카테고리와 함께 티켓까지 삭제해서는 안 됩니다.

각 관계를 쉬운 말로 적어 두세요. 작은 표나 스케치만으로도 충분합니다.

• 고객 한 명에게 여러 티켓이 있을 수 있고 모든 티켓은 하나의 고객에 속해야 합니다.
• 티켓 하나에는 여러 메모가 있을 수 있고 모든 메모는 하나의 티켓과 한 명의 작성자에게 속해야 합니다.
• 작업은 티켓과 연결될 수 있지만 잠시 미배정 큐에 있을 수 있습니다.
• 파일은 티켓, 메모, 고객 레코드 중 하나에 속해야 직원이 용도를 알 수 있습니다.
• 제품 카테고리 하나에는 여러 티켓이 있을 수 있지만 해당 필드가 선택 사항이면 티켓에 카테고리가 없을 수도 있습니다.

빈 값을 허용할 위치 정하기

일부 연결은 항상 있어야 합니다. 티켓이 없는 지원 메모는 의미를 잃으므로 이 연결을 필수로 지정하세요. 다른 연결은 잠시 비어 있어도 됩니다. 새 작업은 관리자가 담당자를 정할 때까지 미배정 큐에서 대기할 수 있습니다.

비즈니스 앱 데이터베이스 설계에서 이 차이를 명확히 하세요. 각 관계마다 직원이 비워 둘 수 있는지, 앱이 자동으로 채우는지, 연결된 레코드가 바뀌면 어떻게 되는지 결정합니다. 명확한 데이터베이스 레코드 소유권이 있으면 재할당, 보관, 보고에서 오류가 줄어듭니다.

맵이 제대로 작동하는지 확인한 뒤에 화면을 만드세요. 그러면 양식에서 필요한 필드를 요구하고, 관계없는 선택지를 숨기며, 나중에 아무도 추적할 수 없는 레코드가 만들어지는 일을 막을 수 있습니다.

새 레코드 규칙 설정하기

새 레코드가 앱에 들어오는 순간 담당자가 있어야 합니다. 직원 양식, 고객 포털, 스프레드시트 가져오기, 자동화된 워크플로를 통해 만들어지는 레코드도 모두 포함됩니다. 앱이 담당자를 잠시라도 비워 두면 후속 업무가 누락될 수 있습니다.

레코드 유형마다 기본 담당자를 설정하세요. 지원 요청은 지원 큐로 보내고 새 영업 리드는 영업 운영팀으로 보낼 수 있습니다. 기본 담당자가 항상 한 사람일 필요는 없습니다. 앱이 명확한 배정 규칙을 적용할 때까지는 공유 큐가 더 안전한 경우가 많습니다.

사람들이 실제로 일하는 방식에 맞는 규칙을 사용하세요.

• 고객의 지역이나 우편번호에 따라 계정을 배정합니다.
• 선택한 제품을 담당하는 팀으로 요청을 보냅니다.
• 업무 시간에는 새 티켓을 큐로 보냅니다.
• 진행 중인 업무가 가장 적은 팀원에게 다음 리드를 배정합니다.
• 가져오기를 제출한 직원이 검토할 때까지 가져온 레코드를 그 직원에게 남겨 둡니다.

배정 사유를 저장하세요. 리드 레코드에 «고객이 Ontario를 선택했으므로 North 영업팀에 배정됨»이라고 표시할 수 있습니다. 이렇게 하면 관리자가 규칙이 제대로 작동했는지 확인하고 직원도 수정이 필요할 때 판단할 근거를 얻습니다. 나중에 보고서에서 사용할 수 있도록 배정 사유를 비공식 메모와 분리하세요.

어떤 레코드는 규칙에 맞지 않습니다. 양식에 지역이 빠져 있거나, 가져온 파일에 익숙하지 않은 제품 코드가 있거나, 큐의 모든 구성원이 자리를 비웠을 수 있습니다. 이런 레코드를 담당자 없이 두지 마세요. «배정 필요» 같은 상태와 함께 모니터링되는 예외 큐로 보내고, 매 영업일 큐를 확인할 책임이 있는 팀을 지정하세요.

소유권 규칙은 레코드를 만드는 작업과 같은 과정에서 실행되어야 합니다. AppMaster에서는 시각적 비즈니스 프로세스로 레코드를 만들고, 담당자나 큐를 선택하고, 배정 사유를 저장하고, 담당 팀에 알릴 수 있습니다. 유효한 담당자를 지정하거나 레코드를 예외 큐에 넣은 뒤에만 프로세스가 완료되도록 하세요.

이렇게 하면 누락된 작업과 답변하지 않은 고객 요청이 나중에 정리해야 할 문제로 커지는 것을 막을 수 있습니다.

직원 변경을 위한 재할당 규칙 작성하기

직원 변경이 발생하면 몇 시간 안에 처리 중인 업무의 담당자가 사라질 수 있습니다. 영업 담당자가 퇴사하거나, 지원 상담원이 다른 팀으로 이동하거나, 관리자가 육아휴직을 시작할 수 있습니다. 각각의 상황에 대해 누가 업무를 이어받고 무엇이 이동하며 얼마나 빨리 처리해야 하는지 적은 규칙이 필요합니다.

과거에 만들어진 모든 레코드가 아니라 현재 진행 중인 레코드를 옮기세요. 활성 영업 기회, 해결되지 않은 지원 티켓, 승인 요청, 이번 달 마감인 작업에는 새 담당자가 필요합니다. 앱이 이력을 유지한다면 종료된 거래와 완료된 티켓은 이전 직원과 계속 연결해도 됩니다.

누군가 자리를 비우기 전에 모든 팀의 대체 담당자를 정하세요. 지정된 동료나 팀 리더일 수도 있고, 관리자가 정리할 책임을 지는 공유 큐일 수도 있습니다. 모든 업무를 일반 계정에 몰아넣는 방식은 피하세요. 사람들은 그곳의 업무를 누군가 처리할 것이라고 생각하기 쉽습니다.

재할당 규칙에는 다음 내용이 있어야 합니다.

• 퇴사, 역할 변경, 휴직처럼 이동을 일으키는 사건
• 활성 상태로 간주하는 레코드 상태
• 기본 수신자와 그 선택을 변경할 수 있는 사람
• 이전 담당자, 이동 날짜, 사유를 앱에 기록하는 방법
• 관리자가 재할당을 검토해야 하는 시점

레코드 이력에 이전 담당자의 이름을 남기세요. 현재 담당자는 누가 마지막으로 고객과 이야기했는지 알아야 하고, 관리자는 감사 추적이 필요할 수 있습니다. 이전 값을 저장하지 않은 채 덮어쓰지 마세요. «팀 이동으로 6월 12일 Maya Patel에서 Jordan Lee로 담당자 변경» 같은 이력은 현재 책임을 혼동하지 않으면서 맥락을 제공합니다.

긴급도에 따라 기한을 정하세요. 관리자가 우선순위가 높은 티켓과 기회를 영업일 기준 하루 안에 검토하고, 우선순위가 낮은 레코드는 3영업일까지 기다리게 할 수 있습니다. 기한이 지나면 관리자에게 알리거나 레코드를 에스컬레이션 큐로 보내세요.

AppMaster의 Data Designer에서 현재 담당자, 이전 담당자, 이동 사유, 우선순위, 검토 기한을 모델링할 수 있습니다. Business Process는 직원 상태가 바뀐 뒤 대상 레코드를 옮기고 관리자에게 검토 작업을 만들 수 있습니다. 규칙이 인수인계 스프레드시트에만 남지 않고 앱 안에 보이게 됩니다.

조용히 삭제하지 말고 보관 작업 선택하기

삭제는 깔끔해 보이지만 나중에 팀에 필요한 맥락까지 없애는 경우가 많습니다. 완료된 고객 요청이 청구 결정을 설명할 수 있고, 오래된 공급업체 레코드가 과거 구매를 뒷받침할 수 있습니다. 출시 전에 어떤 레코드를 종료, 보관, 삭제할 수 있는지 정하고 각 작업의 의미를 분명히 하세요.

업무가 끝났지만 일반적인 이력에 남아 있어야 한다면 종료를 사용하세요. 예를 들어 지원 상담원이 해결된 티켓을 종료할 수 있습니다. 직원은 티켓과 메시지를 읽을 수 있지만 다시 열지 않는 한 답변을 추가할 수 없습니다.

일상 업무에는 더 이상 필요하지 않지만 보고, 감사, 향후 분쟁에 중요할 수 있는 레코드는 보관하세요. 보관된 계정은 기본 목록과 검색 결과에서 사라지지만 권한이 있는 직원은 보관 필터로 찾을 수 있어야 합니다. 담당자, 생성 날짜, 상태 이력, 관련 파일, 보관 사유를 유지하세요. 이런 정보는 몇 달 뒤 다음과 같은 질문에 답해 줍니다. 누가 이 결정을 내렸고 왜 그렇게 했는가?

법적, 운영상, 보고상 용도가 전혀 없는 레코드만 삭제하세요. 임시 초안, 중복 테스트 항목, 실수로 만든 빈 레코드가 대표적인 예입니다. 결제, 완료된 업무, 서명된 문서, 기타 연결된 이력이 있는 레코드는 삭제하지 못하게 하세요.

비활성 레코드를 실제로 비활성화하기

보관 상태에는 그에 맞는 규칙이 필요합니다. 직원이 계속 작업을 추가하고 금액을 변경하거나 다른 사람에게 레코드를 배정할 수 있다면 보관이라는 표시의 의미가 약해집니다. 일반적인 수정을 막고 보관된 항목에 대한 자동 알림이나 후속 작업도 중지하세요.

다음과 같은 제한된 작업만 허용할 수 있습니다.

• 레코드와 이력을 봅니다.
• 사유를 기록하고 복원합니다.
• 권한이 있을 때 내보냅니다.
• 정책상 필요하면 내부 준수 메모를 추가합니다.

일반적으로 레코드를 복원할 수 있는 사람은 관리자나 관리 권한을 가진 사용자가 정해야 합니다.

보존 기간 설정하기

각 보관 레코드를 얼마나 오래 사용할 수 있는지 적어 두세요. 기간은 레코드 유형에 따라 달라질 수 있습니다. 완료된 내부 요청은 거래 이력이 있는 고객 계정보다 짧은 기간만 필요할 수 있습니다. 기간이 끝나면 지정된 관리자가 회사 정책에 따라 영구 삭제할지 검토할 수 있습니다.

AppMaster에서는 Data Designer에서 Active, Closed, Archived 같은 상태를 모델링할 수 있습니다. Business Process 규칙으로 수정을 막고 일상 화면에서 보관된 데이터를 숨기면 문서로 작성한 정책을 일관된 앱 동작으로 바꿀 수 있습니다.

예외를 위한 에스컬레이션 경로 만들기

소유권 규칙으로도 예상하기 어려운 상황은 생깁니다. 고객이 더 이상 존재하지 않는 팀에 속하거나, 인수인계 전에 직원이 퇴사하거나, 가져오기 과정에서 담당자 없는 레코드가 만들어질 수 있습니다. 이런 레코드에는 눈에 보이는 목적지와 정리 책임자가 필요합니다.

«미배정 고객 레코드» 또는 «소유권 검토» 같은 이름의 예외 큐를 만드세요. 유효한 담당자가 없는 모든 레코드를 자동으로 이곳에 보내세요. 모두 볼 수 있지만 아무도 책임감을 느끼지 않는 일반 받은편지함은 피하세요.

관리자나 소규모 운영 그룹에 큐 검토를 맡기세요. 앱은 각 항목이 큐에 들어온 이유, 도착한 시점, 마지막으로 검토한 사람을 기록해야 합니다. 이 이력이 있으면 같은 레코드가 결정 없이 사람 사이를 계속 이동하는 일을 막을 수 있습니다.

위험도에 맞춰 기한 정하기

레코드 유형에 따라 검토 시간을 다르게 설정하세요. 담당자가 없는 새 지원 티켓은 한 시간 안에 처리해야 할 수 있지만, 비활성 공급업체 연락처는 며칠을 기다려도 됩니다. 하나의 획일적인 규칙이 아니라 지연으로 발생하는 비용을 기준으로 기한을 정하세요.

예를 들면 다음과 같습니다.

• 담당자가 없는 긴급 지원 케이스는 즉시 큐로 보내고 30분 뒤 당직 관리자에게 알립니다.
• 배정되지 않은 활성 영업 기회는 다음 영업일까지 검토합니다.
• 정보가 불완전한 가져오기 레코드는 5영업일 안에 검토합니다.
• 퇴사한 계정 관리자가 맡던 계정은 다음 예정된 고객 연락 전에 재할당 대상으로 표시합니다.

기한이 지나면 지정된 관리자에게 알리세요. 관리자가 조치하지 않으면 정해진 시간 뒤 두 번째 담당자나 팀으로 항목을 보내세요. 단계는 짧게 유지해야 합니다. 승인 단계가 길면 고객이 기다리게 됩니다.

잘못된 배정을 쉽게 신고하게 만들기

실수를 가장 먼저 발견하는 사람은 현장 직원인 경우가 많습니다. 각 레코드에 간단한 «배정 문제 신고» 작업을 제공하세요. «잘못된 지역»이나 «고객이 공급업체를 변경함»처럼 짧은 사유를 입력하게 한 뒤 이력을 지우지 않고 레코드를 예외 큐로 옮깁니다.

AppMaster에서는 Data Designer에서 상태와 담당자 필드로 큐를 모델링할 수 있습니다. Business Process는 기한을 설정하고 이메일, SMS, Telegram 알림을 보낼 수 있습니다. 직원은 앱 인터페이스에서 문제를 신고하고 프로세스가 적절한 검토자에게 전달합니다.

명확한 에스컬레이션 경로가 있으면 불확실성을 해결하는 동안에도 레코드가 활성 상태로 유지됩니다. 또한 관리자에게 숨겨진 미배정 업무 더미가 아니라 측정 가능한 검토 목록을 제공합니다.

예시: 퇴사하는 영업 담당자

한 영업 담당자가 금요일에 퇴사 의사를 알렸습니다. 이 담당자는 고객 계정 38개, 진행 중인 견적 11개, 여러 개의 견적 초안을 맡고 있습니다. 팀이 사용자 계정만 비활성화하면 해당 레코드가 일상 작업 큐에서 사라지거나 담당자가 불분명해질 수 있습니다. 작은 공백이 곧 갱신 누락과 답변하지 않은 고객 요청으로 이어집니다.

영업 관리자는 아직 처리가 필요한 계정부터 확인해야 합니다. 앱은 모든 활성 계정을 지역 팀 리더에게 배정할 수 있습니다. 팀 리더는 각 계정을 새 담당자에게 배정할 때까지 책임을 집니다. 채용에 시간이 걸리더라도 직원 변경 중 데이터베이스 레코드 소유권을 명확하게 유지할 수 있습니다.

진행 중인 견적은 퇴사한 담당자가 아니라 계정을 따라가야 합니다. 계정이 North 지역 팀 리더에게 이동하면 진행 중인 견적도 함께 이동합니다. 새 담당자는 이전 담당자의 레코드를 뒤지지 않아도 거래 이력, 연락처, 다음 작업을 확인할 수 있습니다.

견적 초안에는 다른 규칙이 필요합니다. 고객 연락도 없고 예정된 후속 조치도 없으며 최근 업데이트도 없는 초안은 계속 처리할 가치가 없을 수 있습니다. 관리자는 이를 삭제하지 않고 보관할 수 있습니다. 보관된 초안은 참고용으로 남지만 활성 영업 목록을 복잡하게 만들거나 알림을 발생시키지 않습니다.

지역 데이터가 없는 계정도 있을 수 있습니다. 이런 레코드를 수동 검토 큐로 보내고 영업 운영 관리자에게 알리세요. 담당자는 고객 위치, 계정 메모, 현재 계약을 확인한 뒤 담당자를 배정합니다. 앱에는 누가 검토를 맡았고 언제 끝내야 하는지가 표시되어야 합니다.

AppMaster에서는 관리자가 담당자를 퇴사 예정 상태로 표시할 때 Business Process가 계정 상태와 지역을 확인하도록 만들 수 있습니다. 프로세스는 레코드를 재할당하고 조건에 맞는 초안을 보관하며 예외 사항에 대한 검토 작업을 만들 수 있습니다. 각 작업에 명확한 이력이 남아 고아 레코드가 생기지 않습니다.

출시 전에 소유권 규칙 테스트하기

소유권 규칙은 다이어그램에서는 잘 작동해도 첫 번째 바쁜 주에 실패할 수 있습니다. 짧은 테스트를 진행하면 실제 고객 요청, 청구서, 지원 케이스가 비활성 직원 아래에서 멈추기 전에 빈틈을 찾을 수 있습니다.

가능하면 현실적인 데이터의 복사본을 사용하세요. 서로 다른 역할의 사용자를 만들고 관련 항목이 있는 레코드를 배정합니다. 연락처와 거래가 있는 계정이나 작업과 첨부 파일이 있는 프로젝트가 좋은 예입니다. 일반적인 업무뿐 아니라 예상하기 어려운 상황도 테스트하세요.

레코드가 앱에 들어오는 모든 경로 테스트하기

레코드는 기본 생성 양식 외에도 여러 경로로 들어옵니다. 직원이 스프레드시트를 가져오거나, 연동 시스템이 리드를 추가하거나, 자동 프로세스가 밤새 지원 티켓을 만들 수 있습니다. 모든 경로가 담당자를 지정하거나 레코드를 공유 큐로 보내는지 확인하세요.

다음과 같은 검사를 실행하세요.

• 관련 역할별로 직접 레코드를 만들고 예상한 담당자가 표시되는지 확인합니다.
• 담당자 정보가 빠진 파일을 가져오고 앱이 대체 규칙을 따르는지 확인합니다.
• 각 연동 또는 자동화 프로세스를 통해 테스트 레코드를 보냅니다.
• 하위 레코드가 정책에 정한 대로 상위 소유권을 상속하는지, 담당자를 요구하는지, 무시하는지 확인합니다.

영업 담당자가 지정되지 않은 가져온 리드는 담당자 필드가 비어 있는 채 남지 않고 영업 큐로 가야 합니다. 담당자 없는 상태는 오류 메시지보다 발견하기 어려운 경우가 많습니다.

직원 변경과 차단된 작업 시뮬레이션하기

활성 업무를 맡은 테스트 사용자를 비활성화하세요. 앱이 그 사용자의 레코드를 보여 주고, 정한 대체 담당자나 큐로 옮기며, 팀에 필요할 때 이전 담당자를 레코드 이력에 보존하는지 확인합니다. 그런 다음 대체 담당자로 로그인해 이동된 업무를 열고 수정할 수 있는지 확인하세요.

활성 하위 레코드가 남아 있는 상위 레코드를 보관해 보세요. 미처리 티켓이 있는 고객 계정에서 규칙에 맞는 작업이 실행되어야 합니다. 보관을 막거나, 관련 레코드도 보관하거나, 관리자에게 결정을 요청할 수 있습니다. 앱이 하위 레코드를 사용할 수 없는 상위 레코드 아래에 조용히 남겨서는 안 됩니다.

마지막으로 권한을 검토하세요. 일반 직원은 자신의 팀 안에서 담당자를 바꿀 수 있지만 관리자만 팀 사이에서 업무를 이동하거나 퇴사한 동료의 레코드를 재할당할 수 있습니다. 관리자 계정만 사용하지 말고 실제 역할 계정으로 이런 제한을 테스트하세요.

AppMaster를 사용하면 이러한 검사를 비즈니스 앱에 넣을 수 있습니다. 비즈니스 프로세스로 담당자를 필수로 지정하고, 미배정 업무를 큐로 보내며, 관련 레코드에 아직 처리할 일이 있으면 보관 작업을 막으세요. 앱을 게시하기 전에 같은 프로세스를 테스트하고, 직원이 규칙을 기억하기를 기대하지 말고 규칙 자체를 수정하세요.

출시 전 빠른 점검

실제 업무를 시작하기 전에 비즈니스 앱의 소유권을 최종 점검해야 합니다. 영업, 지원, 운영, 사용자 계정을 관리하는 사람들과 함께 점검하세요. 직원 역할이 바뀌어도 중요한 모든 레코드에 책임지는 사람이나 팀이 남아 있어야 합니다.

가능하면 현실적인 레코드의 테스트 복사본을 사용하세요. 고객, 거래, 지원 요청, 청구서, 내부 작업을 만듭니다. 그런 다음 담당자의 상태를 바꾼 뒤 각 화면에 무엇이 표시되는지 확인하세요.

• 모든 중요한 레코드 유형에 현재 담당자, 공유 큐, 지정된 대체 팀 중 하나를 설정합니다.
• 각 비활성 사용자에게 누가 절차를 시작하고 누가 승인하는지를 포함한 문서화된 이동 절차가 있는지 확인합니다.
• 샘플 레코드를 보관하고 권한이 있는 직원이 검색, 필터, 관련 고객 이력을 통해 다시 찾을 수 있는지 확인합니다.
• 매주 월요일 아침처럼 정해진 일정에 예외 큐를 검토할 사람을 한 명 지정합니다.
• 대체 담당자를 정하기 전에 담당자가 퇴사한 거래처럼 누락되거나 충돌하는 데이터가 있는 레코드를 테스트합니다.

앱을 만든 사람이 도움을 주지 않아도 직원이 이 점검을 수행할 수 있어야 합니다. 관리자가 몇 분 안에 고객 요청 30건을 옮기지 못한다면 규칙이 문서에만 존재할 수 있습니다. 앱에는 명확한 작업, 확인 메시지, 변경한 사람의 기록이 필요합니다.

권한도 테스트하세요. 지원 상담원은 보관된 케이스를 볼 수 있어야 하지만 다시 열 수는 없어야 합니다. 부서 리더는 자기 팀 안에서 업무를 재할당할 수 있지만 민감한 레코드를 관련 없는 팀으로 옮겨서는 안 됩니다.

AppMaster에서 이런 점검을 비즈니스 프로세스에 넣고 배포 전에 테스트하세요. 유효한 담당자가 없는 레코드를 위한 예외 큐를 만들고, 큐를 처리할 책임이 있는 사람에게 상태가 보이게 하세요. 아무도 검토하지 않는 큐는 고객이나 동료가 알아차릴 때까지 문제를 숨길 뿐입니다.

규칙을 비즈니스 앱에 적용하기

워크플로를 만들기 전에 소유권 규칙을 작성하세요. 관리자, 지원 상담원, 개발자가 같은 결정을 내릴 수 있을 만큼 쉬운 말로 적습니다. 예를 들면 다음과 같습니다. «각 고객 계정에는 한 명의 활성 계정 담당자가 있습니다. 담당자가 퇴사하면 영업 관리자가 영업일 기준 하루 안에 대체 담당자를 지정합니다. 이전 담당자는 읽기 전용 이력에 남습니다.»

모든 규칙을 앱의 필드, 상태, 작업으로 바꾸세요. 계정 레코드에는 담당자, 팀, 배정 날짜, 보관 상태가 필요할 수 있습니다. 재할당 작업에서는 새 담당자를 필수로 입력하게 하고 누가 변경했는지 시간과 함께 기록해야 합니다. 그러면 직원이 스프레드시트로 우회하지 않고 명확한 절차를 따를 수 있습니다.

AppMaster를 사용하면 애플리케이션을 처음부터 직접 작성하지 않고도 이런 내부 앱을 만들 수 있습니다. Data Designer로 계정, 연락처, 작업과 그 관계를 모델링하세요. 그런 다음 Business Process Editor로 재할당 요청을 전달하고, 새 담당자가 존재하는지 확인하며, 요청이 너무 오래 대기하면 관리자에게 알리세요.

실용적인 첫 버전에는 담당자 없는 레코드 목록, 사유를 필수로 입력하는 재할당 양식, 이력을 보존하는 보관 작업, 예외 처리를 위한 관리자 큐, 기한이 지난 배정을 보여 주는 보고서를 포함할 수 있습니다.

처음 몇 주 동안 이 보고서를 자주 검토하세요. 관리자 큐에 레코드가 쌓이면 원인을 찾습니다. 어떤 팀이 지나치게 많은 이동을 받거나, 관리자가 업무를 배정할 권한이 없거나, 앱이 진행 중인 작업을 확인하지 않고 보관을 허용할 수 있습니다.

라우팅 규칙을 조정한 뒤 현실적인 직원 변경 상황으로 바뀐 경로를 테스트하세요. 계정을 만들고 작업과 연락처를 배정한 다음 담당자를 제거하고 계정을 재할당합니다. 관련 레코드가 모두 직원이 예상하는 위치에 계속 표시되는지 확인하세요.

모든 예외를 미리 예측하는 것이 목표는 아닙니다. 고객 이력, 업무 항목, 책임이 사라지기 전에 예외를 처리할 수 있는 눈에 보이는 장소를 제공하는 것이 중요합니다. AppMaster에서 워크플로를 만들고 테스트한 뒤 직원에게 공개하면 일상적인 담당자 변경을 안정적으로 처리할 수 있습니다.