EY한영 Korea Portal 모바일 시스템

배경 · 업무 프로그램 24개, 사내에서 가장 많이 쓰이는 포털

EY한영은 회계감사와 세무, 컨설팅, 재무자문을 제공하는 글로벌 회계·컨설팅 기업이다. 임직원 3,800명이 드나드는 사내 포털 Korea Portal이 2018년부터 운영되고 있었다. 근무 시간을 적는 타임시트, 비용 처리, 구매, 사내 결재 문서인 기안서까지 업무가 더해지면서 포털에 담긴 업무 프로그램은 24개가 됐다. 한 달 평균 200만 회 조회되는, 사내에서 가장 많이 쓰이는 시스템이었다. 이 포털을 모바일에서도 쓸 수 있게 만드는 일을 제안 단계부터 맡았다.

문제 · 사내망 밖에서 멈추는 결재

이 포털은 사내망 안에서만 열렸다. 밖에서 쓰려면 VPN이 설정된 회사 PC가 필요했다. EY 쪽에서 공유받은 현황으로는 임직원의 약 70%가 외부에서 일한다. 외근이나 이동 중에는 결재를 올리는 쪽도 승인하는 쪽도 포털에 접속하기 어려웠다. 주말 개인 일정 중에도 급하게 결재를 처리해야 하는 상황이 있었다.

포털 자체의 문제도 있었다. 기능이 하나씩 붙어 온 시스템이라 화면 구성이 기능마다 달랐다. 업무는 요청하고 승인받는 순서로 흐르는데, 화면은 그 순서대로 놓여 있지 않았다. 포털을 쓰는 상황을 요청할 때, 승인할 때, 조회할 때로 나눠 보니 막히는 곳이 저마다 달랐다. 요청할 때는 필요한 기능이 어디 있는지 찾아야 했고 화면끼리 이어지지도 않았다. 승인할 때는 거쳐야 할 단계가 많은데 알림과 리마인드가 부족했다. 조회할 때는 필요한 숫자가 한눈에 들어오지 않았다.

리서치 · 사람마다 다르게 열리는 포털

옮길 대상은 이 포털을 실제로 누가 어떻게 쓰는지 확인한 다음 정하기로 했다. 기존 포털을 화면 단위로 열어 As-Is 문서를 만들고, 메인과 타임시트, 기안서, Finance, 서약서, 임직원 검색까지 여섯 갈래를 열 페이지에 정리했다. 정리해 보니 이 포털은 사람마다 다르게 열렸다. 좌측 메뉴는 최대 열네 개인데, 소속과 직급, 담당 업무에 따라 접근 권한이 갈려 계정마다 보이는 항목이 달랐다. 화면 구조를 그대로 옮기면 모바일에서도 사람마다 다른 앱이 된다.

다만 화면만 봐서는 임직원이 어떤 기능을 실제로 자주 쓰는지, 그 일을 언제 어디서 처리하는지 알 수 없었다. 그래서 임직원 인터뷰를 진행했다. 자주 쓰는 기능과 불편한 점, 모바일에서 먼저 보고 싶은 정보, 업무를 처리하는 장소와 시점을 물었다.

인사이트 · 기능 목록에서 '밖에서 막히는 일'로

모바일화의 목표를 '포털을 그대로 옮기는 것'으로 잡으면 업무 프로그램 24개를 전부 만들어야 한다. 밖에 있는 사람이 막히는 지점은 조회가 아니라 결재였다. 요청이 밀리면 그다음 승인도 밀렸다. 그래서 무엇을 옮길지 정하는 기준을 '기능 목록'에서 '밖에서 막히는 일'로 바꿨다.

서약서와 임직원 검색도 같은 기준으로 함께 골랐다. 서약서는 보안과 주식 거래에 관해 월·분기·연 단위로 동의 팝업이 뜨는 문서고, 임직원 검색은 이름을 찾은 자리에서 곧바로 전화와 메일로 이어진다. 둘 다 결재는 아니지만 밖에서 바로 처리되는 편이 낫다고 봤다.

탐색 · 기능 여덟 개, 개발 환경 3안 비교

기능은 임직원이 얼마나 자주 쓰는가와 모바일에서 쓸 만한가, 두 가지로 걸렀다. 그 기준으로 고른 여덟 개는 메인 대시보드, 타임시트 제출과 승인, 기안서 승인, 구매 승인, 거래처 대금을 처리하는 AP 전표 승인, 서약서, 임직원 검색이다. 이 가운데 다섯이 결재를 올리거나 처리하는 화면이다. 밖에서 막히는 일을 기준으로 잡은 만큼, 고른 기능도 결재에 모였다.

만드는 방식은 웹앱과 하이브리드 앱, 네이티브 앱 세 가지를 놓고 비교했다. 사내 업무 도구는 배포한 뒤에도 손볼 일이 계속 생긴다. 네이티브 앱은 iOS와 안드로이드를 따로 만들어야 하고, 고칠 때마다 앱 마켓 심사를 거친다. 하이브리드 앱도 업데이트할 때마다 같은 심사를 받는다. 웹앱은 고친 내용이 곧바로 반영되고, 사내 보안 정책 안에서 관리하기도 수월하다. 기기 호환성과 비용, 업데이트 속도, 보안 관리를 함께 따져 웹앱으로 정했다.

해결 1 · 공용 상세 화면과 역할별 하단 버튼

기안서와 구매, AP 전표는 같은 문서를 요청자와 승인권자가 함께 본다. 두 역할에 화면을 따로 만들면 같은 내용을 두 벌로 관리한다. 그래서 상세 화면은 하나로 두고, 역할에 따라 달라지는 다음 행동만 화면 아래 버튼으로 나눴다. 문서를 보는 자리에서 바로 결정할 수 있도록 승인권자에게는 반려와 승인 두 버튼을 나란히 뒀다. 요청자 화면에는 [승인자 Reminder 메일 발송] 하나만 하단에 놓았다. 문서를 올린 사람이 이 화면에서 이어서 할 수 있는 행동이라, 다른 버튼과 섞지 않고 바로 눈에 들어오게 했다.

해결 2 · 첫 화면에 남긴 판단 정보

승인권자는 이 화면에서 승인할지 반려할지부터 정한다. 그래서 기안서와 구매, AP 전표는 목록 화면을 열 때 조회 조건을, 상세 화면을 열 때 승인자 목록과 첨부파일을 접힌 상태로 둔다. 문서 제목과 요청자, 금액처럼 판단에 바로 쓰이는 정보만 첫 화면에 남겼다. 승인자 목록과 첨부파일은 결정한 뒤에 확인해도 되는 정보라, 필요한 사람만 펼쳐 보도록 설계했다. 기간 조회 규칙은 타임시트까지 네 메뉴가 함께 쓴다. 메뉴를 옮길 때마다 조회 방법을 새로 익히지 않도록 하나로 맞췄다. 조회 범위는 접속한 날을 기준으로 이전 열한 달부터 이후 한 달까지다. 한 주 치를 묶어 제출하고 승인하는 문서라 타임시트만 주 단위로 고른다.

해결 3 · 목록에서 끝나는 일괄 승인과 단건 반려

타임시트는 임직원이 한 주 동안 어느 프로젝트에 몇 시간을 썼는지 적어 올리는 문서다. 승인하는 쪽은 이 문서를 한꺼번에 여러 건 본다. 한 건씩 상세로 들어갔다 나오는 구조는 그 흐름을 매번 끊는다. 그래서 목록에 접고 펼치는 보기를 넣었다. 펼치면 프로젝트 단위(Engagement) 안에 있는 사람별 입력이 목록에 바로 보이고, 그 자리에서 승인과 반려까지 끝난다.

승인은 전체 선택으로 여러 명을 처리하고, 반려는 한 번에 한 사람만 고르게 했다. 반려에는 사유가 따라붙기 때문에, 사람마다 다른 사유를 적을 수 있도록 단건으로 나눴다. 반려 사유는 다섯 자 이상 입력해야 [반려] 버튼이 활성화된다. 한두 글자로 끝난 사유가 제출한 사람에게 그대로 가지 않도록 최소 길이를 걸었다.

해결 4 · 상태별 건수 대시보드와 배지 규칙

홈은 대시보드로 열린다. 작성 중과 승인 요청, 반려, 승인 대기 네 상태의 건수를 맨 위에 놓고, 그 아래에 기안서와 AP 전표, 구매의 결재 필요 현황을 이어서 보여 줬다. 밖에서 앱을 여는 사람에게 가장 급한 정보는 자기 차례가 온 건이다.

상태 배지는 모양과 자리를 고정했다. 다만 이름은 통일하지 않았다. 타임시트는 작성하는 쪽과 승인하는 쪽이 쓰는 상태 이름부터 다르고, 기안서와 구매, AP 전표는 '승인 진행 중'과 '승인 완료'를 쓴다. 단계 수가 다른 업무에 같은 이름을 붙이면 승인이 몇 단계 남았는지가 오히려 흐려진다. 이름보다 배지 모양으로 먼저 알아보게 하고, 용어를 맞추는 일은 다음 과제로 남겼다.

결과 · 이어진 고도화 11건

구축이 끝난 지 반년 만에 고도화 계약이 이어졌다. 타임시트 여섯 건과 감사 독립성 확인, 급여 조회, 구매 청구 일정, IT 소모품 대여, 총무 방문증 신청까지 열한 건을 더 했다. 새로 그린 화면은 9월과 10월 두 차례에 걸쳐 실제 서비스에 올라갔다. 급여 조회는 구축 때 고른 여덟 개에 없었다. 모바일로 옮길 범위를 고도화에서 한 번 더 넓혔다.