이 글의 핵심
Zdjęcia ilustracyjne
이 글은 문서 워크플로우에 대한 질문에 "있습니다, EZD로 일하고 있으니까요"라고 대답하는 사무국장과 관청 경영진을 위한 것입니다.
EZD급 시스템이 실제로 하는 일
기업 세계와 비교한다면, EZD급 시스템은 행정 전용 고객관리시스템에 가장 가깝습니다. 주민, 기업, 기관 등 상대방 데이터베이스를 보유하고 있습니다. 접수 창구, ePUAP(전자정부포털), e-Doręczenia(전자송달), 전자우편 등 접수 경로를 갖추고 있습니다. 문서를 등록하고, 사건을 개설하고, 담당 부서에 배정하고, 처리 절차를 진행하고, 회신을 작성해 발송한 뒤, 최종적으로 문서를 보존 처리로 넘기는 일을 가능하게 합니다.
이는 상당한 범위이며 관청 업무의 기반입니다. 관청은 무엇보다 사건(업무)을 처리하는 곳이기 때문에, 대부분의 문서가 바로 이 경로를 거칩니다. 그렇기 때문에 EZD급 시스템 도입은 중요하며 미룰 이유가 없습니다.
하지만 이는 문서관리규정(instrukcja kancelaryjna)에 따라 운영되는 서신 및 사건 워크플로우일 뿐입니다. 관청에서 생성되는 모든 문서의 워크플로우는 아닙니다.
EZD는 기록이 잘 정리된 문서수발실과 같습니다. 무엇이 들어왔는지, 누구에게 전달되었는지, 그로부터 어떤 사건이 생겼는지, 그리고 회신으로 무엇을 보냈는지를 압니다. 하지만 관청에는 채용을 진행하는 인사 담당자, 의회 회의 자료를 준비하는 의회 사무국, 교육 신청서를 모으는 총무 부서도 있습니다. 이들은 각각 고유한 문서와 결재 경로를 가지고 있습니다. 문서수발실은 이를 직접 관리하지 않으며, 때로는 등록만 할 뿐입니다.
EZD 밖에 존재하는 문서들
일반적인 관청의 문서 워크플로우를 하나씩 나열하기 시작하면 목록은 금세 길어집니다. 공석 채용 공고와 지원자 평가, 회의록까지 포함한 전체 채용 절차가 있습니다. 휴가 신청서를 비롯한 각종 인사 문서가 있습니다. 상급자의 승인과 예산 확인을 거치는 교육 신청서가 있습니다. 비용 정산이 따르는 직원 출장과 의원 출장이 있습니다. 관련 문서를 동반하는 이사회 의결안 초안, 회의 안건 초안, 그리고 이사회 회의 전반의 운영이 있으며, 그 옆에는 의회 본회의 운영이 있습니다. 마지막으로 KSeF 시대의 송장 워크플로우 글에서 다룬 비용 관련 문서들도 있습니다.
이 문서들은 각각 고유한 경로를 가지고 있습니다. 누가 작성하는지, 누가 검토하는지, 누가 수정하는지, 누가 승인하는지, 그 데이터가 어느 시스템으로 들어가는지가 모두 다릅니다. 오늘날 이러한 경로는 대개 종이로, 전자우편으로, 혹은 엑셀 문서로 진행됩니다. 일부는 인사 시스템이나 의회 운영 시스템 같은 업무별 시스템이 처리하지만, 이들 시스템이 서로 연결되어 있는 경우는 드뭅니다.
프로세스 플랫폼이란 무엇인가
완전한 의미에서의 문서 워크플로우란 서신뿐 아니라 어떤 프로세스든 처리할 수 있는 능력을 뜻합니다. 이를 위한 것이 바로 프로세스 플랫폼이며, 워크플로우 시스템이나 BPM이라고도 불립니다. 이러한 플랫폼은 프로세스를 두 가지 방식으로 정의할 수 있게 해줍니다. 첫 번째는 미리 정해진 경로입니다. 신청서가 상급자에게, 그다음 인사 부서에, 그다음 승인 단계로 넘어가는 식입니다. 두 번째는 사람들이 진행 과정에서 직접 만들어가는 경로로, 문서를 서로 주고받으며 검토, 수정, 승인을 거치고 각 버전을 보존하는 방식입니다.
그러나 가장 중요한 것은 사람의 손이 닿지 않는 영역에서 일어나는 일입니다. 프로세스 플랫폼은 부수적인 작업을 자동화합니다. 신청서 데이터를 바탕으로 완성된 PDF 문서를 생성하고, 인사 시스템이나 재무·회계 시스템에 데이터를 자동으로 입력하며, 기한을 관리하고, 미처리된 승인 건을 알립니다. 이 과정에서 시스템 간 데이터 일관성을 유지해야 합니다. 그래야 동일한 직원, 거래 상대방, 예산이 시스템마다 다른 값을 갖는 일이 없습니다.
EZD와 프로세스 플랫폼은 서로 경쟁하지 않습니다. EZD는 사건과 서신을 관리하고, 플랫폼은 나머지 워크플로우를 관리합니다. 내부 워크플로우에서 생성된 문서가 사건의 일부가 되면, 연동을 통해 EZD로 전달됩니다.
변화 속도가 중요한 이유
플랫폼을 선택할 때는 첫 번째 애플리케이션을 얼마나 빨리 만들 수 있는지에만 주목하기 쉽습니다. 그러나 그 후에 그것을 얼마나 쉽게 수정하고 새 버전을 내놓을 수 있는지도 그만큼 중요합니다. 프로세스가 전자적으로 작동하기 시작해야 비로소 사람들은 무엇을 단순화할 수 있는지 보게 됩니다. 아무런 가치를 더하지 않는 단계, 아무도 읽지 않는 항목, 다른 승인과 합칠 수 있는 결재 같은 것들입니다.
이러한 수정마다 공급업체에 발주하고 몇 주씩 기다려야 한다면, 프로세스는 첫 번째 버전에 그대로 머무릅니다. 반대로 버전 이력을 유지하면서 빠르고 안전하게 수정을 적용할 수 있다면, 프로세스는 조직과 함께 성숙해 갑니다.
구매가 아니라 전환
바로 여기에 디지털 전환의 핵심이 있습니다. 조직이 일하는 방식 자체를 바꾸는 것입니다. 업무가 실제로 어떤 작업을 필요로 하는지, 그중 무엇을 시스템이 수행할 수 있는지, 무엇을 인공지능에 맡길 가치가 있는지, 그리고 어떤 문서를 직접 작성하는 대신 자동으로 생성할 수 있는지를 고민합니다. 시스템 구매는 이러한 변화를 위한 도구일 뿐입니다.
하지만 이 모든 것은 일상적으로 제대로 작동해야 합니다. 담당자가 있어야 하고, 보안과 백업이 갖춰져 있어야 하며, 누가 어떤 방식으로 프로세스를 변경할 수 있는지에 대한 명확한 규칙이 있어야 합니다. 그렇기 때문에 도구를 선택하기 전에 어떤 시스템이 무엇을 담당하고 시스템 간에 데이터를 어떻게 주고받는지를 정하는 전략 및 목표 아키텍처를 마련해 두는 것이 중요합니다.
어디서부터 시작할까
좋은 첫걸음은 서신과 사건 처리를 제외한 관청 내 문서 워크플로우 목록을 작성하는 것입니다. 각 워크플로우에 대해 누가 참여하는지, 연간 몇 번이나 반복되는지, 현재 어디에 존재하는지(종이, 전자우편, 엑셀 문서, 업무별 시스템), 그리고 그 데이터가 어느 시스템으로 들어가는지를 정리합니다. 이러한 목록을 보면 어떤 워크플로우가 가장 빈번하고 가장 번거로운지, 즉 어디서부터 시작해야 할지가 드러납니다. 이를 준비하는 데 도움이 되는 것이 시스템 및 프로세스 인벤토리입니다.



