KR20160039552A - 자동 작업 처리 - Google Patents

자동 작업 처리 Download PDF

Info

Publication number
KR20160039552A
KR20160039552A KR1020150137847A KR20150137847A KR20160039552A KR 20160039552 A KR20160039552 A KR 20160039552A KR 1020150137847 A KR1020150137847 A KR 1020150137847A KR 20150137847 A KR20150137847 A KR 20150137847A KR 20160039552 A KR20160039552 A KR 20160039552A
Authority
KR
South Korea
Prior art keywords
task
user
tasks
team
box
Prior art date
Application number
KR1020150137847A
Other languages
English (en)
Inventor
로르 까니스
크리스토프 안젤리니
파스칼 망텔레
악셀 프트렐라
줄리앙 뒤멩
Original Assignee
아마데우스 에스.에이.에스.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 아마데우스 에스.에이.에스. filed Critical 아마데우스 에스.에이.에스.
Publication of KR20160039552A publication Critical patent/KR20160039552A/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management
    • G06Q10/103—Workflow collaboration or project management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/953—Querying, e.g. by the use of web search engines
    • G06F16/9535—Search customisation based on user profiles and personalisation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G06Q10/063—Operations research, analysis or management
    • G06Q10/0631—Resource planning, allocation, distributing or scheduling for enterprises or organisations
    • G06Q10/06311—Scheduling, planning or task assignment for a person or group
    • G06Q10/063112—Skill-based matching of a person or a group to a task
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/12—Accounting
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Systems or methods specially adapted for specific business sectors, e.g. utilities or tourism
    • G06Q50/10—Services
    • G06Q50/14—Travel agencies
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/102—Entity profiles
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials

Abstract

본 발명은 자동 작업 처리를 위한 방법, 시스템 및 컴퓨터 프로그램 제품에 관한 것이다. 작업 처리 모듈은 수입 회계 문제의 해법과 관련하여 복수의 작업을 규정하는 데이터를 수신한다. 각 작업에 대하여, 이 모듈은 계층적 전자 파일링 시스템에 배치되는 복수의 인박스(inbox)들 중 어느 것에 작업이 배정되어야 하는지를 결정한다. 이러한 결정은 작업과 연관되는 작업 템플릿 내의 데이터에 사용자 또는 팀 프로파일을 일치시키는 것에 기초할 수도 있다. 이 모듈은 각 작업에 대한 긴급사항을 결정하고, 작업들이 그 긴급사항에 기초하여 해결되는 순서를 선택할 수도 있다. 모듈은 작업을 인증하는 것에 대한 예상된 영향에 기초하여 인증을 위하여 해결된 작업들을 선택할 수 있고, 넓은 인증된 작업의 샘플을 유지할 수 있다. 작업의 해결 및 인증과 관련되는 이력 데이터는, 키 성능 표시자를 제공하고, 인증 선택 파라미터를 결정하기 위하여 데이터베이스 내에 저장될 수도 있다.

Description

자동화된 태스크 처리{AUTOMATED TASK HANDLING}
본 발명은 자동화된 태스크 처리에 관한 것이다.
본 발명은 일반적으로 컴퓨터 및 컴퓨터 소프트웨어에 관한 것이며, 특히, 여행 상품의 판매 및 이용과 관련된 수익 회계 태스크를 관리하는 방법, 시스템 및 컴퓨터 프로그램 제품에 관한 것이다.
여행 산업에서, 항공 티켓은, 여행사와 같은, 간접 판매자를 통해 판매될 수 있다. 간접 판매자는 통상 여행자의 여행 계획을 만족시키는 이용가능한 항공편을 체크하고 일단 매칭되는 항공편이 발견되면, 여행자를 위해 항공편을 예약하고 대금을 징수한다. 대금은 간접 판매자 또는 발권 항공사(validating carrier)에 의해 징수될 수 있다. 그 다음에, 운항사(operating carrier)는 수취된 대금에서 서비스 비용에 대해 보상받을 수 있다.
가끔, 항공사는 티켓에서 수익 회계 문제(revenue accounting issue)를 검출할 수 있다. 회계 문제는 부적절한 가격의 티켓, 비례배분(proration) 또는 세금 계산 문제, 티켓의 매칭되지 않는 사용, 출발 제어와 전자 티켓(e-ticket) 서버 사용 데이터 간의 불일치(discrepancy), 회계 규칙 디폴트(accounting rules default), 또는 가격책정이 잘못되거나(mispriced) 또는 부적절하게 사용된 티켓을 나타내는 다른 어떤 문제를 포함할 수 있다. 수익 회계 문제가 있다는 결정에 응답하여, 항공사는 하나 이상의 태스크들을 완료하여 상기 문제를 바로잡으려 할 수 있다.
항공 산업에서 매일 발생하는 거래의 수가 크기 때문에, 수익 회계 시스템들은 통상 많은 태스크들이 매일 시스템 작업자들에 의해 수행될 것을 요구한다. 그러한 태스크들은 티켓에 오류가 있는 경우의 결정, 상기 오류가 교정될 수 있는 방법의 결정, 발권 항공사의 전자 티켓팅 시스템(Electronic Ticketing System) 및 운항사의 출발 제어 시스템(Departure Control System)의 데이터 간의 불일치의 조사 및 조정(reconciling), 및 발견되는 어떤 오류들을 해결하기 위한 문서의 발행을 포함할 수 있다. 각각의 태스크를 해결하는 것은 종종, 시정 문서(corrective documents)의 생성, 검증, 및 발행을 포함하여, 상당한 양의 수작업적 개입을 필요로 하기 때문에, 항공사들은 이러한 수익 회계 태스크들을 처리하기 위해 많은 수의 작업자들을 채용할 수 있다. 따라서, 항공사들은 통상 수익 회계와 관련된 태스크들 및 작업 흐름(workflow)의 관리에 상당한 자원을 소모한다.
따라서, 시스템 사용자들에게 태스크들의 할당, 태스크들에 대해 제안된 해결책들의 평가, 및 작업 흐름의 모니터링을 포함하여, 수익 회계 프로세스들과 연관된 태스크들의 처리를 돕는 개선된 시스템, 방법, 및 컴퓨터 프로그램 제품이 필요하다.
본 발명의 일 실시예에서, 복수의 팀 인박스들(team inboxes)을 이용하여 복수의 태스크들을 관리하는 방법이 제공된다. 상기 방법은, 상기 복수의 태스크들 중 각 태스크에 대해, 상기 태스크의 유형을 결정하는 단계, 상기 태스크의 상기 유형에 매칭되는 팀 프로파일을 갖는 하나 이상의 팀 인박스들을 결정하는 단계, 및 상기 매칭되는 팀 프로파일을 갖는 상기 하나 이상의 팀 인박스들 중 하나에 상기 태스크를 추가하는 단계를 포함한다. 상기 방법은, 복수의 사용자들 중 각 사용자에 대해, 상기 복수의 팀 인박스들 중 하나 이상에 대한 액세스를 인가하는(authorizing) 단계, 및 상기 사용자가 액세스하도록 인가되지 않은 각 팀 인박스에 대한 액세스를 거부하는 단계를 더 포함하며, 상기에서 각 팀 인박스는 상기 팀 인박스 내 태스크들에 대해 액세스를 갖는 사용자들의 가상 팀을 정의한다.
본 발명의 다른 실시예에서, 상기 복수의 태스크들을 관리하는 시스템이 제공된다. 상기 시스템은 프로세서 및, 명령어들이 상기 프로세서에 의해 실행될 때, 상기 시스템으로 하여금, 상기 복수의 태스크들 중 각 태스크에 대해, 상기 태스크의 상기 유형을 결정하고, 상기 태스크의 상기 유형에 매칭되는 상기 팀 프로파일을 갖는 상기 하나 이상의 팀 인박스들을 결정하며, 상기 매칭되는 팀 프로파일을 갖는 상기 하나 이상의 팀 인박스들 중 하나에 상기 태스크를 추가하도록 하는 상기 명령어들을 저장하는 메모리를 포함한다. 상기 명령어들은 추가적으로 상기 시스템으로 하여금, 상기 복수의 사용자들 중 각 사용자에 대해, 상기 복수의 팀 인박스들 중 상기 하나 이상에 대한 액세스를 인가하고, 및 상기 사용자가 액세스하도록 인가되지 않은 각 팀 인박스에 대한 액세스를 거부하도록 하며, 상기에서 각 팀 인박스는 상기 팀 인박스 내 태스크들에 대한 액세스를 갖는 사용자들의 상기 가상 팀을 정의한다.
본 발명의 다른 실시예에서, 명령어들을 포함하는 비일시적 컴퓨터 판독가능 저장 매체를 포함하는 컴퓨터 프로그램 제품이 제공된다. 상기 명령어들은, 상기 프로세서에 의해 실행될 때, 상기 프로세서로 하여금, 상기 복수의 태스크들 중 각 태스크에 대해, 상기 태스크의 상기 유형을 결정하고, 상기 태스크의 상기 유형에 매칭되는 상기 팀 프로파일을 갖는 상기 하나 이상의 팀 인박스들을 결정하며, 상기 매칭되는 팀 프로파일을 갖는 상기 하나 이상의 팀 인박스들 중 하나에 상기 태스크를 추가하도록 구성될 수 있다. 상기 명령어들은 추가적으로 상기 프로세서로 하여금, 상기 복수의 사용자들 중 각 사용자에 대해, 상기 복수의 팀 인박스들 중 상기 하나 이상에 대한 액세스를 인가하고, 및 상기 사용자가 액세스하도록 인가되지 않은 각 팀 인박스에 대한 액세스를 거부하도록 하며, 상기에서 각 팀 인박스는 상기 팀 인박스 내 태스크들에 대한 액세스를 갖는 사용자들의 상기 가상 팀을 정의한다.
본 명세서에 포함되고 본 명세서의 일부를 이루는 첨부 도면들은 본 발명의 다양한 실시예들을 도시하고, 상기에 주어진 본 발명의 일반적 설명과 하기에 주어지는 실시예들의 상세한 설명과 함께, 본 발명의 실시예들을 설명하는 역할을 한다.
도 1은 네트워크를 통해 통신하는 복수의 컴퓨터 시스템들을 포함하는 예시적 작업 환경의 개략도이다.
도 2는 도 1의 예시적 컴퓨터 시스템의 개략도이다.
도 3은 도 1의 상기 컴퓨터 시스템들 중 하나 이상에 의해 주관될(hosted) 수 있는 태스크 처리 모듈, 태스크 해결 데이터베이스, 및 수익 회계 모듈을 도시하는 개략적인 블록도이다.
도 4는 도 3의 상기 태스크 처리 모듈에 의해 지원되는 사용자들의 가상 팀을 정의하는 인박스들의 계층 구조(hierarchical structure)로 체계화된 인박스를 각각 갖는 복수의 시스템 사용자들을 도시하는 개략도이다.
도 5는 태스크가 도 4의 상기 가상 팀의 구성원들에게 할당되는 것을 도시하는 개략도이다.
도 6은 팀 인박스를 표시하는 상기 태스크 처리 모듈에 의해 발생되는 사용자 인터페이스의 개략도이다.
도 7은 사용자 인박스를 표시하는 도 6의 상기 사용자 인터페이스의 개략도이다.
도 8은 작업자(operator)를 위한 사용자 인박스(user inbox), 및 검증자(validator), 감독자(supervisor), 및 관리자(manager)를 위한 모니터링 인박스들(monitoring inboxes)을 포함하는 계층적 인박스 구성의 개략도이다.
도 9는 상기 모니터링 인박스를 표시하는 도 6의 상기 사용자 인터페이스의 개략도이다.
도 10은 검증 창(validation window)을 표시하는 도 6의 상기 사용자 인터페이스의 개략도이다.
도 11은 태스크 이력을 표시하는 도 10의 상기 검증 창의 개략도이다.
도 12는 잔무(backlog) KPI 창을 표시하는 도 6의 상기 사용자 인터페이스의 개략도이다.
도 13은 마감 시간 KPI 창을 표시하는 도 6의 상기 사용자 인터페이스의 개략도이다.
도 14는 소요 시간 KPI 창을 표시하는 도 6의 상기 사용자 인터페이스의 개략도이다.
도 15는 일일 활동(daily activity) KPI 창을 표시하는 도 6의 상기 사용자 인터페이스의 개략도이다.
도 16은 검증 KPI 창을 표시하는 도 6의 상기 사용자 인터페이스의 개략도이다.
도 17은 도 3의 상기 태스크 처리 모듈에 의해 실행될 수 있는 해결된 태스크를 검증하는 프로세스를 도시하는 흐름도이다.
본 발명의 실시예들은 글로벌 유통 시스템(Global Distribution System, GDS)과 통신할 수 있는, 수익 회계 시스템(revenue accounting system)과 같은, 컴퓨터 시스템에 의해 구현될 수 있다. 상기 수익 회계 시스템 및 GDS는, 항공 티켓의 간접 판매자들과 여행 상품 제공자와 각각 연관되는 복수의 컴퓨터 예약 시스템들 간의 상호 연결을 용이하게 하는, 처리(processing) 및 데이터베이스 기능들을 제공할 수 있다. 항공 여행의 맥락에서, 상기 컴퓨터 시스템은 여행자들이 간접적 판매 채널들을 통해 항공 티켓 및 다른 여행 상품들을 예약하도록 구성될 수 있다. 이러한 간접적 판매 채널들은 항공사에 의해 제공될 서비스들에 대한 온라인 여행사들 또는 다른 업무 주체들(entities)을 포함할 수 있다. 상기 간접 판매자들은 상기 예약된 티켓에 대해 여행자들로부터 대금을 수취하고, 상기 수취된 대금에서 상기 제공된 서비스의 비용으로 상기 항공사에 보상하거나 또는, 상기 여행자들이 상기 항공사에 직접 대금 지불하도록 하여 보상할 수 있다.
상기 컴퓨터 시스템은 항공사들이 수익 회계 시스템에 의해 발생되는 태스크들을 관리할 수 있도록 하는 태스크 처리 모듈(task handling module)을 제공할 수 있다. 이 태스크들은, 상기 간접 판매자에 의한 잘못된 가격책정과 같이, 티켓의 판매나 이용 또는 다른 거래에서 검출되는 문제들에 관한 것일 수 있다. 상기 태스크 처리 모듈은 태스크들을 수신, 할당, 및 검증하는 인박스들의 계층적 배치를 이용하여 자동으로 태스크들을 처리하는 통합 관리 시스템을 제공할 수 있다. 인박스들의 이 계층적 배치는 사용자들의 가상 팀들을 포함할 수 있다.
태스크들의 자동 할당을 용이하게 하기 위해, 각 태스크는 태스크 템플릿(task template)과 연관될 수 있다. 상기 태스크 템플릿은 파라미터들 및 업무 데이터(business data)를 포함할 수 있다. 상기 파라미터들은 태스크 유형을 정의할 수 있고, 상기 태스크를 팀 인박스에 전송하기(route) 위해 상기 태스크 처리 모듈에 의해 이용될 수 있다. 상기 업무 데이터는, 상기 태스크에 대해 평가되어야 할 키 값(key-value)을 식별하는 데이터(예를 들면, 근본적인(underlying) 메모 금액 또는 탑승 지점(board point))와 같은, 태스크에 첨부되는 다른 데이터를 포함할 수 있다. 상기 태스크 템플릿은 또한 검증 싸이클을 트리거시키는지(trigger) 여부를 결정함에 있어 평가되어야 할 파라미터들, 및 태스크 우선순위 또는 중요도 수준(severity level)을 설정하는데 이용되어야 할 파라미터들을 정의할 수 있다.
신규 태스크에 대한 작업을 시작하고자 하는 팀 내의 사용자들은 상기 태스크 처리 모듈이 다음 태스크를 할당할 것을 요청할 수 있다. 그 다음에, 상기 태스크 처리 모듈은 상기 태스크의 긴급성 및 상기 사용자의 사용자 프로파일에 기반하여 상기 사용자가 수신해야 할 다음 태스크를 자동으로 결정할 수 있다. 상기 긴급성은 적어도 부분적으로 상기 태스크와 연관된 마감 시간(deadline)에 의존할 수 있으며, 상기 긴급성은 태스크들이 그것들의 마감 시간에 근접함에 따라 증가한다. 이로써 상기 태스크 처리 모듈은, 상기 태스크의 상기 긴급성 및 상기 태스크가 할당되는 상기 사용자의 숙련기술(skills) 및 경험에 기반하여, 태스크들의 할당을 최적화할 수 있다.
상기 태스크 처리 모듈은 발생부터 종결(closure)까지 상기 태스크들의 이력(history)을 추적하여, 또는 상기 태스크 및 상기 태스크를 해결하기 위해 일하는 각 사용자에 대한 감사 추적(audit trail)을 유지하여 작업 흐름 관리를 용이하게 할 수 있다. 이를 위해, 상기 태스크 처리 모듈은 태스크 해결 데이터베이스에 태스크 관련 데이터를 저장하고 검색할 수 있다. 상기 태스크 해결 데이터베이스는 태스크들의 해결에 관한 이력 데이터 뿐만 아니라, 팀별, 사용자별, 및 태스크 유형별 기준으로 수신, 종결, 및 검증된 태스크들의 수를 추적하는 핵심 성과 지표들(Key Performance Indicators, KPIs)의 발생에 이용되는 데이터를 저장할 수 있다. 상기 태스크 처리 모듈은, 이용가능한 검증 자원들의 영향을 최적화하는 모델에 기반하여, 검증을 위해 어떤 해결된 태스크들을 선택할지를 결정하기 위해 상기 이력 데이터를 추가적으로 이용할 수 있다. 이로써 상기 태스크 처리 모듈은 작업 흐름, 수익(revenue), 및 상기 태스크들을 처리하는 상기 사용자들의 평가의 관리를 용이하게 할 수 있다.
이제 도 1을 참조하면, 본 발명의 일 실시예에 따른 작업 환경(operating environment, 10)은 GDS(12), 여행 상품 제공자 시스템 또는 항공사 시스템(14), 간접 판매자 시스템 또는 여행사 시스템(16), 사용자 시스템(18), 전자 티켓팅 시스템(Electronic Ticketing System, ETS, 20), 및 출발 제어 시스템(Departure Control System, DCS, 22)을 포함할 수 있다. 상기 GDS(12), 항공사 시스템(14), 여행사 시스템(16), 사용자 시스템(18), ETS(20), 및 DCS(22) 각각은 복수의 시스템들 중 하나를 나타낼 수 있고, 데이터의 교환을 가능하게 하는 하나 이상의 개인 또는 공용 네트워크들(예를 들면, 인터넷)을 포함하는 네트워크(24)를 통해 통신할 수 있다.
상기 GDS(12)는 여행사, 발권 항공사(validating carrier), 또는 다른 간접 판매자들이 상기 GDS(12)를 통해 상기 항공사 시스템(14) 상에서 예약할 수 있도록 함으로써 상기 항공사 시스템(14)과 상기 여행사 시스템(16) 간의 통신을 용이하게 하도록 구성될 수 있다. 이를 위해, 상기 GDS(12)는 상기 네트워크(24)를 통해 복수의 항송사 시스템들에 대한 링크들(links)을 유지할 수 있다. 이 링크들은 상기 GDS(12)가 예약 요청들을 상기 발권 항공사의 상기 항공사 시스템(14) 또는 여행사 시스템(16)으로부터 운항사(operating carrier)에 대한 해당 항공사 시스템(14)으로 전송하도록(route) 할 수 있다. 이로써 상기 항공사 및 여행사 시스템들(14, 16)은 상기 GDS(12)에 대한 단일 연결을 통해 다수의 항공사들에 대한 항공편을 예약할 수 있다.
상기 항공사 시스템(14)은 상기 GDS(12) 또는 여행사 시스템(16)이 항공 티켓을 예약하고 대금을 지불할 수 있도록 하는 컴퓨터 예약 시스템(Computer Reservation System, CRS)을 포함할 수 있다. 상기 항공사 시스템(14)은 또한, 발권 항공사가 상기 운항사에 의해 제공되는 좌석을 위한 티켓을 판매할 수 있도록 하기 위해, 직접 아니면 상기 GDS(12)를 통해, 다른 항공사 시스템들과 상호작용할 수 있다. 그 다음에, 상기 운항사는 상기 제공된 서비스에 대해 상기 발권 항공사에게 대금청구할 수 있다. 간접 판매자들로서의 역할을 하는 업무 주체들 및 여행 서비스 제공자들로서의 역할을 하는 업무 주체들 간의 대금청구(billing)는 대금청구 서비스 제공자(Billing Service Provider, BSP)(미도시) 시스템에 의해 제공될 수 있다. 본 발명의 일부 실시예들에서, 특정 항공사에 대한 상기 ETS(20) 및 DCS(22)는 상기 항공사의 해당 항공사 시스템에 의해 제공될 수 있다.
상기 사용자 시스템(18)은 상기 네트워크(24) 또는 다른 어떤 적절한 연결을 통해 상기 GDS(12) 및 상기 항공사 시스템(14) 중 하나 이상과 통신할 수 있다. 이로써 상기 사용자 시스템(18)은 사용자들에게 상기 GDS(12) 및/또는 상기 항공사 시스템(14)에 대한 터미널 또는 다른 적합한 인터페이스를 제공할 수 있다. 이로써 사용자들은 태스크들을 해결 또는 달리 관리하기 위해 상기 사용자 시스템(18)을 통해 상기 GDS(12) 및 상기 항공사 시스템(14)과 통신할 수 있다.
상기 ETS(20)는 해당 항공사에 의해 발행된, 전자 티켓과 같은, 티켓의 예약 및 사용의 기록들을 유지하도록 구성되는 컴퓨터 시스템을 포함할 수 있다. 상기 ETS(20)는 상기 ETS(20)에 의해 저장된 데이터를 이용하여 상기 항공사에 의해 발행된 티켓들의 상태를 추적할 수 있다. 이 데이터는, 적어도 부분적으로, 승객에 의해 예약된 하나 이상의 예약들을 정의하는 하나 이상의 예약 기록들을 포함하는 승객 이름 기록(Passenger Name Record, PNR)의 형태로 저장될 수 있다. 상기 PNR은 또한 구입한 여행 서비스들의 이용을 추적할 수 있다. 상기 PNR은 해당 PNR에 고유한 기록 로케이터(record locator)에 의해 식별될 수 있고, 특정 여행, 서비스, 승객, 또는 승객들의 집단에 대한 일정을 정의하는 기록들을 포함할 수 있다. 상기 일정은 다수의 항공사들로부터의 서비스들(예를 들면, 항공편, 버스, 및 또는 철도 구간), 호텔 예약, 렌터카 예약, 또는 다른 어떤 여행 관련 서비스들을 포함한다.
상기 DCS(22)는 티켓들에 의해 예약된 상기 여행 상품들이 이용됨에 따라 상기 티켓들의 자동화된 처리를 제공한다. 이 처리는 탑승권 및 예약된 여행 서비스 수령시 교환되는 다른 쿠폰들을 포함할 수 있다. 상기 DCS(22)는 또한 위탁 수하물(checked baggage), 여행자에 의한 티켓 사용, 및 공항 체크-인 및 탑승을 추적할 수 있다. 이러한 서비스들을 수행하기 위해, 상기 DCS(22)는 상기 ETS(20) 및, 비한정적으로 체크-인 키오스크(kiosk), 체크-인 웹 사이트, 및 여행자들의 모바일 장치들을 포함하는, 다양한 컴퓨팅 장치들과 협동적으로 작동할 수 있다. 상기 DCS(22)는, 예를 들면, 여행자가 공항에 체크-인하거나 또는 비행기에 탑승하는 것에 응답하여, 각 여행 상품이 이용됨에 따라 상기 전자 티켓에 의해 식별되는 상기 여행 상품의 상태를 표시하기 위해 상기 PNR을 갱신할 수 있다.
이제 도 2를 참조하면, 작업 환경(10)의 상기 GDS(12), 항공사 시스템(14), 여행사 시스템(16), 사용자 시스템(18), ETS(20), 및 DCS(22)는, 예시적 컴퓨터 시스템(30)과 같은, 하나 이상의 컴퓨터 장치들 또는 시스템들 상에서 구현될 수 있다. 상기 컴퓨터 시스템(30)은 프로세서(32), 메모리(34), 대용량 저장 메모리 장치(36), 입출력(input/output, I/O) 인터페이스(38), 및 인간 기계 인터페이스(Human Machine Interface, HMI, 40)를 포함할 수 있다. 상기 컴퓨터 시스템(30)은 또한 상기 네트워크(24) 및/또는 I/O 인터페이스(38)를 통해 하나 이상의 외부 자원들(42)과 작동적으로 결합될 수 있다.
상기 프로세서(32)는 마이크로프로세서, 마이크로컨트롤러, 디지털 신호 프로세서, 마이크로컴퓨터, 중앙 처리 장치, 필드 프로그램가능 게이트 어레이, 프로그램가능 논리 장치, 상태 기계, 논리 회로, 아날로그 회로, 디지털 회로, 또는 상기 메모리(34)에 저장된 작업 명령어들(operational instructions)에 기반하여 (아날로그 또는 디지털) 신호들을 조작하는 다른 어떤 장치들로부터 선택되는 하나 이상의 장치들을 포함할 수 있다. 메모리(34)는, 비한정적으로 읽기 전용 메모리(read-only memory, ROM), 랜덤 액세스 메모리(random access memory, RAM), 휘발성 메모리, 비휘발성 메모리, 정적 랜덤 액세스 메모리(static random access memory, SRAM), 동적 랜덤 액세스 메모리(dynamic random access memory, DRAM), 플래시 메모리, 캐시(cache) 메모리, 또는 정보를 저장할 수 있는 다른 어떤 장치를 포함하는, 단일 메모리 장치 또는 복수의 메모리 장치들을 포함할 수 있다. 상기 대용량 저장 메모리 장치(36)는, 하드 드라이브, 광학 드라이브, 테이프 드라이브, 비휘발성 솔리드 스테이트 디바이스, 또는 정보를 저장할 수 있는 다른 어떤 장치와 같은, 데이터 저장 장치들을 포함할 수 있다.
프로세서(32)는 메모리(34)에 상주하는 운영 체제(46)의 제어하에 작동될 수 있다. 상기 운영 체제(46)는, 메모리(34)에 상주하는 애플리케이션(48)과 같은 하나 이상의 컴퓨터 소프트웨어 애플리케이션들로 구현되는 컴퓨터 프로그램 코드가 상기 프로세서(32)에 의해 실행되는 명령어들을 가질 수 있도록, 컴퓨터 자원들을 관리할 수 있다. 대안적인 실시예에서, 상기 프로세서(32)는 상기 애플리케이션(48)을 직접 실행할 수 있으며, 그러한 경우에 상기 운영 체제(46)는 생략될 수 있다. 하나 이상의 데이터 구조들(50)이 또한 메모리(34)에 상주할 수 있고, 데이터를 저장 또는 조작하기 위해 상기 프로세서(32), 운영 체제(46), 또는 애플리케이션(48)에 의해 이용될 수 있다.
상기 I/O 인터페이스(38)는 상기 프로세서(32)를, 상기 네트워크(24) 또는 외부 자원(42)과 같은, 다른 장치들 또는 시스템들과 작동적으로 결합시키는 기계 인터페이스(machine interface)를 제공할 수 있다. 이로써 상기 애플리케이션(48)은, 본 발명의 실시예들을 포함하는 다양한 특징들, 기능들, 및 모듈들을 제공하기 위해, 상기 I/O 인터페이스(38)를 통해 통신함으로써 상기 네트워크(24) 또는 외부 자원(42)과 협동적으로 작업할 수 있다. 상기 애플리케이션(48)은 또한 하나 이상의 외부 자원들(42)에 의해 실행되는 프로그램 코드를 갖거나, 아니면 상기 컴퓨터 시스템(30) 외부의 다른 시스템 또는 네트워크 구성요소들에 의해 제공되는 기능들 또는 신호들에 의존할 수 있다. 실제로, 거의 무한정의 가능한 하드웨어 및 소프트웨어 구성들을 고려해 볼 때, 본 발명이 속하는 기술분야의 통상의 지식을 가진 자라면 본 발명의 실시예들은, 상기 컴퓨터 시스템(30)의 외부에 위치되거나, 다수의 컴퓨터들 또는 다른 외부 자원들(42) 간에 분배되거나, 또는, 클라우드 컴퓨팅 서비스과 같은, 상기 네트워크(24)를 통한 서비스로서 제공되는 컴퓨팅 자원들(하드웨어 및 소프트웨어)에 의해 제공되는, 애플리케이션들을 포함할 수 있다.
상기 HMI(40)는, 사용자가 컴퓨터 시스템(30)과 직접 상호작용할 수 있도록, 공지의 방식으로 상기 컴퓨터 시스템(30)의 상기 프로세서(32)에 작동적으로 결합될 수 있다. 상기 HMI(40)는 비디오 또는 알파벳-숫자 표시 장치들, 터치 스크린, 스피커, 또는 정보를 상기 사용자에게 제공할 수 있는 다른 어떤 적합한 오디오 및 비디오 표시기들을 포함할 수 있다. 상기 HMI(40)는 또한, 상기 사용자로부터의 명령들 또는 입력을 수용하고 상기 들어온 입력을 상기 프로세서(32)에 전송할 수 있는, 알파벳-숫자 키보드, 포인팅 장치, 키패드, 푸시버튼, 제어 손잡이(control knob), 및 마이크 등과 같은 입력 장치들 및 제어장치들(controls)을 포함할 수 있다.
데이터베이스(44)는 상기 대용량 저장 메모리 장치(36)에 상주할 수 있고, 본 명세서에서 설명하는 다양한 시스템들 및 모듈들에 의해 이용되는 데이터를 수집하고 체계화하는데 이용될 수 있다. 상기 데이터베이스(44)는 데이터 및 상기 데이터를 저장하고 체계화하는 지원 데이터 구조들(supporting data structures)을 포함할 수 있다. 특히, 상기 데이터베이스(44)는, 비한정적으로 관계형 데이터베이스(relational database), 계층적 데이터베이스(hierarchical database), 네트워크 데이터베이스, 또는 이들의 조합을 포함하는, 어떤 데이터베이스 체계(organization) 또는 구조로든지 배열될 수 있다. 상기 프로세서(32) 상에서 명령어들로서 실행되는 컴퓨터 소프트웨어 애플리케이션 형태의 데이터베이스 관리 시스템은 쿼리(query)에 응답하여 데이터베이스 기록들에 저장된 정보 또는 데이터에 액세스하는데 이용될 수 있고, 여기서 쿼리는 상기 운영 체제(46), 애플리케이션(48), 또는 하나 이상의 모듈들에 의해 동적으로 결정되고 실행될 수 있다.
이제 도 3을 참조하면, 태스크 처리 모듈(52)은, 통신 네트워크 또는 공유 메모리 공간과 같은, 매체(58)를 통해 태스크 해결 데이터베이스(54) 및 수익 회계 모듈(56)과 통신할 수 있다. 상기 태스크 처리 모듈(52), 태스크 해결 데이터베이스(54), 및 수익 회계 모듈(56)은 상기 GDS(12), 항공사 시스템(14), 다른 어떤 적합한 컴퓨터 시스템에 의해 주관될(hosted) 될 수 있다. 상기 태스크 처리 모듈(52)은 상기 간접 판매자들에 의해 판매된 티켓을 포함하는 거래들에 관한 태스크들을 관리하는 기능들을 제공할 수 있다. 상기 태스크 해결 데이터베이스(54)는 상기 태스크 처리 모듈(52)에 의해 관리되는 상기 태스크들에 관한 데이터를 저장할 수 있고, 태스크 관련 데이터를 검색 및 저장하기 위해 상기 태스크 처리 모듈(52)에 의해 액세스될 수 있다. 상기 수익 회계 모듈(56)은 항공사의 수익 회계 시스템의 일부일 수 있고, 상기 GDS(12), 상기 항공사 시스템(14), 상기 여행사 시스템(16), ETS(20), DCS(22), 및/또는 상기 BSP와 같은 대금청구 플랫폼들과 같은, 하나 이상의 소스들로부터 티켓 또는 다른 거래 관련 데이터를 수신할 수 있다.
상기 수익 회계 모듈(56)은, 예를 들면, 티켓의 문제를 검출하는 감사(audit)에 응답하여, 티켓의 발행, 사용, 및 대금청구에 관련된 태스크(60)를 발생시킬 수 있다. 간접 판매 감사의 경우에, 상기 수익 회계 모듈(56)은 상기 간접 판매자에 의해 부과된 실제 요금과 상기 티켓에 대해 부과되어야 했던 요금을 비교할 수 있다. 당발 인터라인 대금청구(outward interline billing) 감사에 대해, 상기 수익 회계 모듈(56)은 상기 발권 항공사로부터 수취된 금액과 수취되어야 했던 금액을 비교할 수 있다. 타발 인터라인 대금청구(inward interline billing) 감사에 대해, 상기 운항사에 의해 대금청구된 금액은 상기 운항사에게 권리가 있는 비례배분된(prorated) 금액과 비교될 수 있다. 어떤 경우든, 상기 감사 금액(audit amount)과 관련된 불일치는 상기 태스크(60)를 발생시킬 수 있다. 상기 태스크(60)는, 예를 들면, 대행사 차변 메모(Agency Debit Memo, ADM)를 발생시키기 위한 명령어들을 포함할 수 있다. 상기 운항사와 발권 항공사 간의 대금청구 분쟁의 경우에, 상기 태스크(60)는 상기 발권 항공사에게 인터라인 대금청구(interline bill)을 발생시키거나(즉, 인터라인 당발 대금청구) 또는 운항사에게 거부 메모를 발행하기(즉, 인터라인 타발 대금청구) 위한 명령어들을 포함할 수 있다. 불일치의 검출에 응답하여 발생될 수 있는 다른 태스크들은 수신된 ADM을 다투거나(dispute), 또는 수신된 분쟁에 대한 조회(inquiry)를 발행하기 위한 명령어들을 포함할 수 있다.
태스크들은 또한 상기 수익 회계 프로세스 외부에서 발생될 수 있다. 추가적인 자동화된 프로세스들은 반드시 수익 감사와 연관되는 것은 아닌 다른 어떤 검증(validation) 또는 다양한 조치들을 수행하기 위해 태스크들을 발생시킬 수 있다. 이러한 자동적으로 발생된 태스크들 중 일부는 사용자가 상기 시스템에 의해 수행되거나 또는 제안된 자동화된 조치를 체크하고 검증(즉, 감사)할 것을 요구할 수 있다. 상기 자동적으로 발생된 태스크들 중 다른 것들은 사용자가, 일정 수준 미만으로 떨어진 계약 수(contract numbers)의 현재 재고에 응답하여 재고 데이터베이스로부터 추가적인 계약 수의 할당, 연말이 다가옴에 응답하여 신규 BSP 일정의 삽입, 또는 여행 서비스 제공자의 작업과 관련된 다른 어떤 조치와 같은, 특정 조치를 수행하도록 하는 트리거들(triggers)일 수 있다.
ADM의 수신, 대금청구 분쟁, 또는 상기 ETS(20)와 DCS(22) 간의 불일치의 검출과 같은, 회계 이벤트에 응답하여, 상기 수익 회계 모듈(56)은 상기 태스크(60)를 발생시키고 상기 태스크(60)를 처리를 위해 상기 태스크 처리 모듈(52)로 전달할 수 있다. 이 결정은 티켓에 대한 특정 사용의 경우, 또는 "태스크 유형"에 의존할 수 있다. 상기 태스크 유형은 상기 태스크(60)와 연관된 태스크 템플릿(62)에 저장될 수 있다. 상기 태스크 템플릿(62)은, 상기 항공사가 상기 태스크(60)가 할당되어야 할 업무 단위(business unit)와 같은 추가적인 파라미터들을 상기 태스크 템플릿(62)에 추가할 수 있도록, 구성될 수 있다. 상기 업무 단위는 상기 태스크에 대해 액세스를 갖는 사용자들의 가상 팀을 정의하는 팀 프로파일을 포함할 수 있다. 상기 태스크 템플릿(62)은 또한, 상기 태스크(60)를 특정 사용자에게 할당하는 것과 같이, 상기 태스크(60)를 관리하기 위해 상기 태스크 처리 모듈(52)에 의해 이용되는 추가적인 데이터를 저장하는데 이용될 수 있다.
상기 태스크(60)를 발생시키는 것에 응답하여, 상기 수익 회계 모듈(56)은 상기 태스크(60)의 발생을 트리거시킨 회계 문제의 근본 원인(root cause)을 결정할 수 있다. 그 다음에, 상기 수익 회계 모듈(56)은 어떤 추가적인 회계 문제들이 상기 태스크(60)의 상기 근본 원인에 의해 생성되는지 여부를 결정할 수 있다. 이 추가적인 회계 문제들에 응답하여 추가적인 태스크들이 통상적으로 발생될 것이라면, 상기 수익 회계 모듈(56)은 상기 근본 원인과 연관된 상기 추가적인 회계 문제들을 상기 기존 태스크(60)에 추가할 수 있다. 따라서, 추가적인 태스크들을 생성하는 대신에, 상기 수익 회계 모듈(56)은 단일 근본 원인과 관련된 다수의 회계 문제들을 상기 기존 태스크(60)로 통합할 수 있다. 이로써 상기 수익 회계 모듈(56)은 단일 근본 원인과 관련된 다수의 태스크들을 발생시키는 것을 피할 수 있다. 상기 추가적인 태스크들을 발생시킬 수 있었던 상기 수익 회계 애플리케이션에 의해 발생되는 추가적인 업무 데이터는 또한 상기 태스크(60)의 상기 태스크 템플릿(62)에 저장될 수 있다. 상기 업무 데이터는, 일단 상기 근본 원인이 다루어지면 영향받는 티켓들 각각이 수정될(fixed) 수 있도록, 포인터(pointer)와 같이, 상기 영향받는 티켓들 각각을 식별하는 데이터를 포함할 수 있다.
통합되는 태스크들을 초래할 수 있는 근본 원인의 예는 누락된 비례배분 인자(missing prorate factor)이다. 누락된 비례배분 인자의 경우에, 상기 통합된 태스크의 고유성(uniqueness)은 근거가 되는 비행편에 대해 매칭되는 출발지 및 목적지 지점들에 기반할 수 있다. 어떤 경우든, 일단 상기 통합된 태스크가 상기 사용자에 의해 처리되면, 상기 근본 원인과 연관된 모든 세부 문제들이 자동적으로 해결될 수 있다. 이로써 관련 태스크들의 통합은 사용자 생산성의 추가적인 향상, 사용자 인박스들 내의 더 적은 태스크들로 인한 더 적은 혼란, 및 개별 태스크들을 열고 처리할 필요성 또는 상기 사용자들이 선행(previous) 태스크를 처리했던 방법을 기억할 필요성의 제거를 초래할 수 있다.
상기 태스크 처리 모듈(52)은 수신된 각 태스크(60)를 해당 태스크 템플릿(62)에서 식별되는 업무 단위에 해당하는 팀에게 할당할 수 있다. 이로써 각 업무 단위는 상기 해당 팀의 구성원이 작업하도록 인가되는 상기 태스크들의 기능적 도메인(functional domain)을 정의할 수 있다. 사용자별 기준으로 인가(authorization)의 제어를 용이하게 하기 위해, 각 사용자는 상기 사용자의 적어도 하나의 특성을 정의하는 사용자 프로파일과 연관될 수 있다. 예를 들면, 상기 사용자 프로파일은 상기 사용자가 속한 하나 이상의 업무 단위들, 상기 사용자가 열람하거나 작업할 수 있는 태스크의 최대값과 같이 상기 사용자가 만족시키는 보안 요건, 또는 상기 사용자의 다른 어떤 적합한 특성을 정의할 수 있다.
상기 사용자 프로파일에 저장된 상기 사용자의 하나 이상의 특성들에 기반하여, 상기 사용자는 상기 하나 이상의 업무 단위들에 할당된 태스크들 및/또는 상기 사용자 프로파일에 정의된 팀 프로파일들에 액세스하도록 인가될 수 있다. 태스크들에 대한 액세스는 수익 회계 데이터의 보안을 보장하는 보안 모델에 기반할 수 있다. 상기 보안 모델은 특정 사용자가, 적어도 부분적으로 그들의 업무 단위 및 상기 조직 내에서의 역할에 기반하여, 어떤 태스크들에 액세스할 수 있는지를 제어할 수 있다. 이는 가상 팀을 포함하는 각 사용자를 업무 단위에 할당하여 상기 "가상 팀"의 생성을 가능하게 할 수 있다. 사용자를 특정 업무 단위에 할당하는 것은 상기 사용자가 상기 특정 업무 단위를 파라미터로서 포함하는 템플릿을 갖는 어떤 태스크에든지 액세스하도록 할 수 있다. 상기 업무 단위에 할당된 태스크에 액세스하는 상기 사용자의 능력은 상기 업무 단위 내의 상기 사용자의 역할에 추가적으로 기반할 수 있다. 즉, 상기 사용자가 상기 업무 단위에 할당된 태스크들에 행할 수 있는 조치들의 유형은 상기 사용자가 작업자(operator), 검증자(validator), 또는 감독자(supervisor)인지 여부에 추가적으로 의존한다.
각 태스크는 팀 또는 사용자에 대응하는 인박스에 상기 태스크를 저장함으로써 상기 팀 또는 상기 사용자에게 할당될 수 있다. 각 인박스는 전자 파일링 시스템(electronic filing system) 내에 태스크들의 세트를 수용하도록 구성된 가상 용기(virtual container)를 포함할 수 있다. 인박스 유형들은 특정 사용자에게 할당되는 태스크들을 수용하는 사용자 인박스들, 및 팀에게 할당되는 태스크들을 수용하는 팀 인박스들을 포함할 수 있다. 사용자들은 태스크들을 해결하는데 집중하는 작업자들, 해결된 태스크들의 품질을 제어하고 현금 흐름을 포함하는 태스크들을 인가하는데 집중하는 검증자들, 및 작업 부하(workload) 모니터링, 작업자들의 지원, 및 수동 개입이 필요한 경우 태스크들의 발송(dispatching)에 집중하는 감독자들을 포함할 수 있다. 감독자 또는 검증자와 같은, 오직 일정 사용자들만이 사용자 인박스로부터 태스크들을 소환할(recall) 수 있는 반면에, 팀 인박스들은 태스크들이 상기 태스크에 액세스할 권한을 가진 어떤 사용자에 의해서든 검색될 수 있도록 구성될 수 있다.
인박스에 대한 액세스를 갖는 작업자는 그들이 액세스 권한을 갖는 상기 인박스 내의 태스크들에 대해 열람하고 작업할 수 있다. 즉, 상기 인박스에 대한 액세스 권한을 갖는 것에 부가하여, 상기 사용자는 상기 태스크를 열람하고 변경하기 위해 상기 인박스 내의 태스크에 대해 특정 액세스 권한을 가질 필요가 있을 수 있다. 태스크 액세스 권한은 상기 태스크 템플릿(62) 내의 보안 파라미터와 상기 사용자의 상기 사용자 프로파일 내의 해당 파라미터를 매칭시켜 결정될 수 있다.
인박스들은 상기 태스크 처리 모듈(52)에 의해 제공되는 사용자 인터페이스를 통해 액세스될 수 있다. 각 작업자는, 그들의 사용자 및 팀 인박스와 같이, 하나 이상의 특정 인박스들에 대해 액세스하도록 선택적으로 할당될 수 있다. 상기 태스크 처리 모듈(52)은, 각 작업자가 액세스하는 상기 인박스들, 상기 태스크 템플릿(62) 내의 상기 보안 파라미터들, 및 상기 사용자 프로파일 내의 상기 사용자 특성들에 기반하여, 각 태스크에 대해 누가 액세스할 것인지를 관리할 수 있다. 작업자들은 상이한 액세스 레벨들을 할당받을 수 있고, 각 액세스 레벨은 해당 인박스에 대한 상이한 액세스 권한을 제공한다. 예시적인 인박스 및 태스크 액세스 레벨들은, 상기 사용자가 태스크들을 열람할 수 있게 하지만, 상기 사용자가 상기 태스크를 편집하거나 또는 달리 변경하는 것을 방지할 수 있는, "열람 전용(view-only)" 액세스를 포함할 수 있다. 액세스의 다른 레벨은, 상기 사용자가 상기 인박스 내의 상기 태스크들을 편집, 이동, 해결, 또는 달리 변경하도록 할 수 있는, "변경(modify)" 액세스일 수 있다. 이로써 상기 태스크 처리 모듈(52)은, 태스크들을 적절한 사용자들에게 적절한 액세스 레벨들을 제공하는 인박스들에 추가함으로써, 태스크 작업 흐름을 관리할 수 있다.
이제 도 4를 참조하면, 역할 기반 액세스 제어 모델(100)은, 상기 업무 단위 및 사용자에게 할당되는 조직 역할(organizational role)에 기반하여, 복수의 사용자들(102a 내지 102f) 각각에 대한 액세스 레벨들을 정의할 수 있다. 상기 사용자들(102a 내지 102f) 각각은 하나 이상의 인박스들(104a 내지 104f)에 액세스할 수 있다. 도시된 예시적 실시예에서, 상기 역할 기반 액세스 제어 모델(100)은 상기 사용자들(102a 내지 102f)이 할당될 수 있는 복수의 조직 역할들(106a 내지 106c)을 포함할 수 있으며, 각 조직 역할(106a 내지 106c)은 일정 레벨의 액세스를 가지도록 인가되는 사용자 유형을 정의할 수 있다. 상기 태스크 처리 모듈(52)은 오직 인가된 사용자들만 태스크들에 액세스할 수 있도록 함으로써 수익 회계 데이터의 보안을 보장할 수 있다. 상기 사용자의 상기 조직 역할(106a 내지 106c)은 조직 내의 상기 사용자의 계층적 레벨에 대응할 수 있다. 예시적 역할은 작업자(예를 들면, 태스크 해결에 대해 작업하는 사용자), 검증자(예를 들면, 상기 검증자의 업무 단위 내의 사용자에 의해 발생되는 해결책들의 품질을 모니터링하고 제어하며, 현금 흐름을 포함하는 태스크들의 해결책을 인가하는 사용자), 감독자(예를 들면, 작업 부하를 모니터링하고, 작업자들을 지원하며, 필요한 경우, 상기 업무 단위 내의 태스크들을 소환하고(recalling) 발송하는(dispatching) 책임을 맡은 사용자), 관리자(예를 들면, 감독자 레벨에서 할당된 태스크들을 포함하여, 동일한 업무 단위에 속하는 태스크들을 소환하고 발송하도록 인가되는 "슈퍼 유저(super-user)"), 또는 상기 조직 내의 다른 어떤 적합한 역할을 포함할 수 있다.
사용자들(102a 내지 102f)은, 예시적 가상 팀(108)과 같이 상기 사용자들(102a 내지 102f)이 할당되는 상기 업무 단위들에 기반하여, 가상 팀들로 추가적으로 조직될 수 있다. 상기 가상 팀(108)은 비상관(uncorrelated) 계층 구조를 가질 수 있고, 가상 팀(108)의 상기 사용자들(102d, 102e, 102f)을 동일 업무 단위 내의 역할에 할당함으로써 정의 될 수 있다. 예를 들면, 상기 가상 팀(108)을 정의하는 상기 업무 단위를 사용자들(102d, 102e, 및 102f)의 상기 사용자 프로파일에 추가함으로써, 상기 가상 팀(108)이 정의될 수 있다. 상기 사용자(102a 내지 102f)의 상기 업무 단위는 상기 사용자(102a 내지 102f)가 작업할 수 있는 상기 태스크들의 기능적 도메인을 결정할 수 있다. 예시적 업무 단위들은 인터라인(interline), 여행사, BSP, 또는 태스크들을 분리하기에 적합한 다른 어떤 업무 단위 정의를 포함할 수 있다.
예로서, 판매 감사팀을 위한 작업자의 역할을 할당받은 사용자는 인터라인 감사팀을 위한 검증자의 역할을 할당받을 수 있다. 각 팀 인박스에 대한 상기 사용자의 액세스 레벨은 팀 내에서 그들의 역할에 따라 설정될 수 있다. 이로써 상기 태스크 처리 모듈(52)은, 사용자들이 올바른 팀 및 사용자 인박스들에 액세스하도록, 액세스 제어들이 사용자들에게 할당되도록 할 수 있다. 특정 업무 단위 액세스 제어를 가상 팀의 일부가 될 사용자들에 대한 상기 인박스들 각각에 할당하여 상기 가상 팀을 생성하는 것은 항공사들이 조직 변화에 뒤따르는 전자 파일링 시스템 갱신을 피할 수 있도록 할 수 있다. 이로써 상기 가상 팀 특징은 사용자들을 조직하고 사용자 작업 부하를 효율적으로 관리하기 위한 신속한 방법을 제공할 수 있다. 팀 인박스들 및 사용자 인박스들을 통해 태스크들을 처리함으로써, 항공사들은 발생된 태스크들과 상기 태스크들을 처리할 책임이 있는 사용자들 간에 올바른 할당을 보장할 수 있다.
이제 도 5를 참조하면, 상기 태스크 처리 모듈(52)은 상기 태스크(60)를, 팀(116)의 인박스(112), 또는 작업자(118)의 사용자 인박스(113)와 같이, 업무 단위에 속하는 복수의 인박스들(112 내지 115)에 자동으로 발송하도록(dispatch) 구성될 수 있다. 이 할당은 상기 태스크의 유형을 정의하는 상기 태스크 템플릿(62)에 저장된 데이터 및 상기 태스크(60)가 할당되는 상기 업무 단위에 따른 것일 수 있다. 어느 경우든, 상기 인박스(112 내지 115)는, 상기 태스크 템플릿(62) 내의 상기 태스크의 유형 또는 다른 파라미터들에 기반하여, 상기 태스크 처리 모듈(52)에 의해 선택될 수 있다. 작업자(118)의 상기 사용자 인박스(113)는, 상기 작업자(118)가 상기 태스크(60)를 팀(116)의 상기 인박스(112)로 또는 감독자(120)의 상기 사용자 인박스(114)로 다시 발송할(dispatch) 수 있도록, 구성될 수 있다. 이로써 상기 태스크 처리 모듈(52)은, 상기 작업자(118)가 상기 태스크(60)를 해결하는데 도움이 필요한 경우, 상기 작업자(118)가 지원 받을 수 있도록 할 수 있다.
대부분의 경우, 태스크 할당 작업 흐름은 상기 시스템에 의해 자동으로 관리될 수 있다. 즉, 상기 태스크는 상기 작업의 생성에 응답하여 상기 작업자에게 자동으로 할당될 수 있다. 검증이 필요한 경우, 상기 태스크는 상기 작업자의 상기 태스크 해결에 응답하여 상기 검증자에게 할당될 수 있다. 그 다음에, 상기 태스크는, 상기 해결된 태스크가 상기 검증자에 의해 검증되는 것에 응답하여, 또는 상기 해결된 태스크가 검증을 필요로 하지 않는다고 결정시, 자동으로 종결될 수 있다.사용자 개입이 필요한 경우, 상기 시스템은 사용자들에게 상기 시스템 내의 태스크들을 이동시키기 위한 도구(tool)를 제공할 수 있다.
이를 위해, 감독자(120)의 상기 사용자 인박스(114)는, 상기 감독자(120)가, 경우에 따라, 팀(116)의 상기 인박스(112) 또는 작업자(118)의 상기 사용자 인박스(113)로부터 상기 태스크(60)를 소환할(recall) 수 있도록, 구성될 수 있다. 상기 사용자 인박스들로부터 태스크들을 소환하는 상기 감독자의 능력은 감독자 모니터링 인박스(153)(도 8)에 의해 제공될 수 있다. 하기에서 더 상세히 설명하는 바와 같이, 상기 감독자 모니터링 인박스(153)는 상기 감독자가 동일 업무 단위의 작업자 인박스들에 할당된 모든 태스크들을 볼 수 있도록 할 수 있다.
상기 감독자(120)는 상기 태스크(60)를 다른 작업자(122)의 상기 사용자 인박스(115)로 발송할 수 있다. 상기 감독자(120)는 또한 상기 태스크(60)를 팀(116)의 상기 팀 인박스(112) 또는 작업자(118)의 상기 사용자 인박스(113)로부터 작업자(122)의 상기 사용자 인박스(115)로 직접 발송할 수 있다. 이로써 상기 감독자(120)는 작업자들(118, 122) 간의 작업 부하를 조정하거나, 또는 상기 태스크를, 상기 태스크(60)를 처리하기에 더 적합할 수 있는, 상기 작업자(122)에게 재할당할 수 있다. 이로써 상기 발송 특징(dispatch feature)은 감독자들이 특정 작업 흐름을 통해 태스크의 해결까지 상기 태스크를 수동으로 제어하는 방법을 제공할 수 있다. 본 발명의 실시예들에서, 사용자들은 그들의 사용자 인박스, 또는 그들의 업무 단위 내의 더 낮은 레벨 사용자들의 사용자 인박스들을 차단할 수 있으며, 이에 따라 태스크들은, 사무실 외부의 아니면 태스크들을 수신할 수 없는, 사용자에게 할당되지 않게 될 것이다.
각 인박스(112 내지 115)는 상기 항공사의 상기 수익 회계 시스템에 링크되거나, 또는 이와 달리 상기 인박스(112 내지 115) 내의 상기 태스크들이 상기 사용자에 의해 이용되는 어떤 관련 수익 회계 애플리케이션들의 사용자 인터페이스에 의해 표시되도록 구성될 수 있다. 예를 들면, 상기 작업자(118)가 상기 태스크 처리 모듈(52)을 이용하여 상기 태스크(60)를 여는 경우, 상기 태스크(60)를 해결하도록 요구되는 상기 수익 회계 애플리케이션의 상기 사용자 인터페이스는 상기 태스크 처리 모듈(52)에 내장되거나, 또는 상기 태스크 처리 모듈(52)을 통해 표시될 수 있다. 이는, 예를 들면, 상기 태스크 처리 모듈(52)이 상기 수익 회계 애플리케이션의 상기 사용자 인터페이스를 표시하기 위한 창(window)을 여는 사용자 인터페이스를 제공함으로써 달성될 수 있다. 이런 식으로, 상기 수익 회계 애플리케이션은 상기 태스크 처리 모듈(52)를 통해 액세스될 수 있다. 어떤 경우든, 일단 상기 태스크(60)가 종결되었다면(예를 들면, 해결, 검증, 및 시정 조치가 취해졌다면), 상기 태스크(60)는 상기 인박스들(112 내지 115)로부터 자동으로 제거될 수 있다. 태스크들이 추가적인 조치(예를 들면, 검증 또는 시정 조치)를 필요로 하는 경우, 상기 제거된 태스크는 상기 자동 작업 흐름 논리에 의해 결정되는 바와 같이 적절한 사용자 인박스로 전달될 수 있다.
이제 도 6 및 도 7을 참조하면, 상기 태스크 처리 모듈(52)에 의해 제공될 수 있는 예시적 사용자 인터페이스(130)는 팀 인박스 창(132) 및 사용자 인박스 창(134)를 포함한다. 상기 사용자는 상기 해당 창(132, 134)을 활성화시켜 상기 태스크 처리 모듈(52)이 상기 팀 인박스(112) 또는 그들의 사용자 인박스(113 내지 115)를 표시하도록 할 수 있다. 상기 팀 인박스 창(132) 및 사용자 인박스 창(134) 각각은 상기 대응하는 인박스(112 내지 115) 내의 상기 태스크들과 관련된 데이터를 표시하는 복수의 열들(columns)을 포함할 수 있다. 예시적 열들은 선택된 태스크(136), 태스크 식별자(137), 태스크 애플리케이션(138), 태스크 유형(139), 태스크 하위유형(sub-type)(140), 상기 태스크를 처리하도록 할당된 팀(141), 목표 일자(142)(예를 들면, "레드 존 기한(Red Zone Due Date)"), 기한(143), 태스크 중요도(severity)(144), 및 상기 태스크의 검증 상태(145)를 포함할 수 있다. 상기 사용자 인터페이스는 또한 상기 선택된 태스크의 간략한 설명을 표시하는 선택된 태스크 미리보기 창(146)을 포함할 수 있다.
상기 목표 일자(142)는, 상기 사용자가 적어도 상기 태스크를 처리하기 시작했어야만 하는, 상기 기한(143) 이전의 일자로서 정의될 수 있다. 이로써 상기 목표 일자(142)는 상기 사용자에게 그들이 상기 태스크가 상기 기한(143) 이전에 완료되도록 작업하고 있어야 한다는 경고를 제공할 수 있다. 상기 태스크 처리 모듈(52)은 각 항공사가 상기 목표 일자(142), 상기 기한(143), 및 상기 태스크 중요도(144)를 결정하는데 이용되는 파라미터들을 정의할 수 있도록 구성될 수 있다. 일자들은 또한 상기 태스크를 생성하는 애플리케이션에 의해 동적으로 결정될 수 있다. 예를 들면, 더 높은 상대적 긴급성을 갖는 태스크들은 더 낮은 상대적 긴급성을 갖는 태스크들 이전에 사용자들에게 할당될 수 있다.
도 6에 도시한 바와 같이, 상기 팀 인박스 창(132)을 표시할 때, 상기 사용자 인터페이스(130)는 표시되는 인박스를 갱신하는 새로고침 버튼(refresh button, 147), 열람을 위해 상기 선택된 태스크를 여는 선택 태스크 열람 버튼(view selected task button, 148), 상기 팀 인박스(112)로부터 상기 선택된 태스크를 검색하고 상기 태스크를 상기 사용자 인박스(113 내지 115)에 넣는 선택 태스크 가져오기 버튼(get selected task button, 149), 및 상기 태스크의 긴급성에 기반하여 상기 표시된 인박스 내의 다음 태스크를 선택하는 다음 태스크 가져오기 버튼(get next task button, 150)을 더 표시할 수 있다. 하기에서 더 상세히 설명하는 바와 같이, 상기 태스크가 상기 사용자 인박스(113 내지 115)에 놓이는 것에 응답하여, KPI를 결정하는데 이용하기 위해 상기 태스크에 대한 상기 사용자의 소요 시간을 추적하도록 타이머가 시작될 수 있다. 도 7에 도시한 바와 같이, 상기 사용자 인박스 창(134)을 표시할 때, 상기 사용자 인터페이스(130)는 상기 새로고팀 버튼(147), 상기 다음 태스크 가져오기 버튼(150), 및 편집을 위해 상기 선택된 태스크를 여는 선택 태스크 편집 버튼(edit selected task button, 151)을 표시할 수 있다.
이제 도 8을 참조하면, 상기 사용자의 역할에 기반하여, 상기 태스크 처리 모듈(52)은 일정 사용자들이 모니터링 인박스들(152 내지 154)을 통해 다른 사용자들의 인박스들 내의 태스크들을 열람 또는 제어할 수 있도록 할 수 있다. 모니터링 인박스들(152 내지 154)은 상기 모니터링 인박스의 사용자가 액세스 제어하는 상기 업무 단위들 내의 더 낮은 계층적 역할을 갖는 사용자들에게 할당된 인박스들 내의 모든 태스크들을 포함할 수 있다. 이로써 모니터링 인박스들(152 내지 154)은 동일한 업무 단위(155) 내의 사용자들이 상기 모니터링 인박스에 액세스하는 사용자보다 더 낮은 역할을 갖는 상기 업무 단위(155) 내의 다른 사용자들에게 할당된 태스크들을 열람 또는 제어할 수 있도록 할 수 있다. 도시된 예시적 실시예에서, 최하위의 역할은 상기 작업자의 역할이고, 높아지는 순서로, 검증자, 감독자, 및 관리자의 역할이 이어진다. 작업자보다 낮은 역할을 갖는 상기 업무 단위(155) 내의 사용자들은 없으므로, 상기 작업자 레벨의 사용자들은 모니터링 인박스에 액세스하지 못할 수 있다.
한 레벨 올라가면, 각 검증자는 상기 검증자 모니터링 인박스(152)에 대한 액세스를 제공받을 수 있다. 상기 검증자 모니터링 인박스(152)는 상기 업무 단위(155) 내의 작업자들의 각 작업자 사용자 인박스(156) 내의 태스크들에 대한 액세스를 제공할 수 있다. 상기 검증자 모니터링 인박스(152)에 의해 제공되는 상기 액세스는 상기 검증자가 상기 업무 단위(155) 내의 각 작업자의 상기 작업자 사용자 인박스(156) 내의 태스크들을 열람 또는 제어하도록 할 수 있다. 유사한 방식으로, 상기 감독자 모니터링 인박스(153)는 상기 업무 단위(155) 내의 각 작업자 및 검증자의 상기 인박스들 내의 태스크들에 대한 액세스를 제공할 수 있고, 상기 관리자 모니터링 인박스(154)는 업무 단위(155) 내의 상기 검증자 모니터링 인박스(152), 감독자 모니터링 인박스(153), 및 작업자 사용자 인박스(156) 각각에 있는 태스크들에 대한 액세스를 제공할 수 있다.
도 9는 상기 태스크 처리 모듈(52)의 상기 사용자 인터페이스(130)에 의해 표시될 수 있는 상기 감독자 모니터링 인박스(153)의 예시적 프레젠테이션을 도시한다. 상기 선택된 태스크, 태스크 식별자, 태스크 애플리케이션, 태스크 유형, 태스크 하위유형, 할당 팀, 목표 기한, 최종 기한, 및 태스크 중요도 열들(136 내지 144)에 부가하여, 상기 감독자 모니터링 인박스의 상기 표시는 할당 팀 유형 열(157), 및 할당 사용자 열(158)을 더 포함할 수 있다. 상기 감독자 모니터링 인박스(153)를 표시할 때, 상기 사용자 인터페이스(130)는 또한 소환(recall) 버튼(159) 및 발송(dispatch) 버튼(161)을 표시할 수 있다. 상기 소환 버튼(159)은, 상기 사용자가 상기 소환 버튼(159)을 활성화시키는 것에 응답하여, 상기 태스크 처리 모듈(52)이 상기 할당된 사용자의 인박스로부터 상기 선택된 태스크를 소환하도록 구성될 수 있다. 상기 발송 버튼(161)은, 상기 사용자가 상기 발송 버튼(161)을 활성화시키는 것에 응답하여, 상기 태스크 처리 모듈(52)이 상기 선택된 태스크를 선택된 사용자의 인박스, 또는 동일 업무 단위의 팀 인박스에 추가하도록 구성될 수 있다.
상기 태스크 처리 모듈(52)에 의해 제공되는 상기 인박스 구조 및 사용자 인터페이스(130)는 상기 업무 단위(155) 내의 태스크들, 예를 들면, 상기 팀 인박스 내의 보류중인 태스크들 및 사용자 인박스들 내의 진행중인 태스크들의 전체 열람(full view)을 제공하여 태스크 처리 활동들의 제어를 용이하게 할 수 있다. 상기 태스크 처리 모듈(52)에 의해 제공되는 상기 시인성(visibility)은 사용자들에게 태스크 상태에 대해 경계심을 가지게 할 수 있고, 마감일에 가까워진 또는 높은 중요도 순위를 갖는 태스크들과 같이, 긴급하게 처리될 필요가 있는 태스크들의 처리(handling)를 향상시킬 수 있다. 상기 계층 구조, 가상 팀 특징, 및 작업자 레벨보다 상위의 사용자들이 더 낮은 레벨 사용자들의 인박스로부터 또는 인박스로 소환 및 발송하는 능력은 직원 구성(staffing)의 변화에 맞춘 태스크들의 처리를 위한 유연한 도구를 제공할 수 있다.
예를 들면, 상기 다음 태스크 가져오기 버튼(150)을 활성화하여, 사용자가 다음 태스크를 요청하는 것에 응답하여, 상기 태스크 처리 모듈(52)은 상기 요청 사용자에 의해 처리되어야 할 상기 인박스 내의 다음 태스크를 선택할 수 있다. 이를 위해, 상기 태스크 처리 모듈(52)은, 태스크의 상대적 중요도, 상기 태스크의 상대적 기한, 및/또는 상기 요청을 한 상기 사용자에 의해 처리된 하나 이상의 선행 태스크들과 상기 태스크의 상대적 유사성에 기반하여, 다음으로 가장 긴급한 태스크를 결정할 수 있다. 상기 태스크의 긴급성을 결정하는 선택 선호도(selection preferences)는 상기 항공사에 의해 정의될 수 있다. 즉, 상기 태스크 처리 모듈(52)은 상기 여행 상품을 제공했던 상기 항공사에 따라 어떤 태스크가 가장 긴급한지를 결정하기 위한 파라미터들의 상이한 세트들을 가질 수 있다. 상기 항공사가 상기 파라미터들을 선택할 수 있게 함으로써, 상기 태스크 처리 모듈(52)은 상기 항공사가, 적어도 부분적으로, 태스크들이 해결되는 순서를 결정하는 규칙을 설정 가능하게 할 수 있다. 상기 태스크 처리 모듈(52)은 사용자들이 다음에 어떤 태스크를 작업할지 선택할 필요가 없게 함으로써, 주관성(subjectivity) 및 연관된 생산성 손실을 방지할 수 있다. 상기 자동 태스크 선택 특징은 또한 최상의 긴급성을 갖는(예를 들면, 최상의 중요도, 가장 빠른 기한, 또는 상기 항공사에게 최상의 가치를 갖는) 태스크들이 더 낮은 긴급성을 갖는 태스크들 이전에 작업되는 것을 보장할 수 있다. 이로써 상기 태스크 처리 모듈(52)은 태스크들의 우선순위 선정에 관한 항공사 정의 파라미터들의 일관된 적용을 용이하게 할 수 있다.
상기 태스크 처리 모듈(52)은 또한 동일 유형의 태스크들을 선택함으로써 또는 해당 사용자에 의해 처리된 선행 태스크와 유사한 예상 해결책을 가짐으로써 다음 태스크를 식별할 수 있다. 상기 동일 사용자와 함께 동일 유형의 태스크들을 순서화(sequencing)함으로써, 유사한 해결책을 가질 것으로 예상될 수 있는 이 유사한 태스크들은 차례로 처리될 수 있다. 이는 선행 태스크를 해결하는데 필요한 단계들이 사용자에게 여전히 생생하게 기억되는 동안 상기 사용자들이 순차적으로 유사한 태스크들을 작업할 수 있게 함으로써 사용자 생산성을 높일 수 있다.
상기 태스크 처리 모듈(52)은 태스크의 유형 및 팀의 정의(definition)에 기반하여 특정 팀 인박스에 신규 태스크들을 발송할 수 있다. 상기 태스크 처리 모듈(52)은 특정 태스크 유형에 속하는 태스크들을 올바른 팀 또는 사용자 인박스에 어떻게 분배할지 결정하기 위해 상기 태스크 템플릿(62)으로부터 추출된 업무 데이터에 추가적으로 의존할 수 있다. 예를 들면, 상기 업무 데이터는, 상기 태스크를 어디로 발송할지 결정함에 있어 각 태스크에 대해 평가되어야 할, 키 값(key-value), 또는 태스크 파라미터를 포함할 수 있다. 예시적 키 값은 상기 태스크의 근거가 되는 티켓에 대한 탑승 지점(board point)일 수 있다.
예로서, 상기 탑승 지점=NCE인 일정 유형의 모든 태스크들은 특정 팀 또는 사용자 인박스로 발송될 수 있다. 이를 위해, 상기 업무 데이터 유형(예를 들면, 탑승 지점)은, 상기 항공사가 태스크들이 어떻게 할당되고 상기 태스크들에 어떤 사용자들이 액세스할지를 제어할 수 있도록, 상기 항공사에 의해 정의될 수 있다. 상기 업무 데이터 값(예를 들면, NCE)은 상기 태스크를 발생시키는 애플리케이션에 의해 결정될 수 있다. 이로써 상기 태스크 템플릿은 상기 태스크가 상기 업무 데이터 유형 및 값에 기반하여 어떻게 지휘될지를(directed) 정의할 수 있다. 예를 들면, 상기 탑승 지점=NCE인 경우, 상기 태스크 템플릿은 상기 태스크가 팀 A에 할당되도록 할 수 있고, 상기 탑승 지점≠NCE인 경우, 상기 태스크 템플릿은 상기 태스크가 팀 B 또는 사용자 C에게 할당되도록 할 수 있다. 또한, 항공사들은 상기 태스크 처리 모듈(52)을 제공하는 상기 시스템의 소유자의 관여 없이 태스크들을 할당하는데 이용되는 상기 업무 데이터를 변경 가능할 수 있다. 업무 데이터는, 탑승 지점, 하선 지점(disembarkation point), 메모 금액(memo amount), 또는 메모 이유와 같은, 상기 태스크와 연관된 어떤 적합한 데이터든지 포함할 수 있다.
상기 업무 데이터 평가에 기반하여, 상기 태스크 처리 모듈(52)은, 태스크 유형에 기반하여 태스크들을 수용할 수 있는 사용자들을 포함하는 하나 이상의 팀들을 정의함으로써, 상기 태스크들을 동적으로 할당할 수 있다. 예로서, 상기 태스크 처리 모듈(52)은 해당 유형의 태스크들을 처리하도록 두 팀을 정의할 수 있다. 그 다음에, 상기 태스크 처리 모듈(52)은 상기 업무 데이터 값에 기반하여 상기 태스크(60)를 상기 두 팀 중 한 팀 또는 다른 한 팀에 할당할 수 있다. 예를 들면, 문턱값(threshold)보다 더 큰 금액을 갖는 모든 ADM들은 상기 두 개의 팀 인박스들 중 하나에 발송될 수 있고, 문턱치 금액 이하의 금액을 갖는 모든 ADM들은 상기 두 개의 팀 인박스들 중 다른 하나에 발송될 수 있다.
본 발명의 대안적 실시예에서, 상기 태스크들은 상기 태스크 유형에 매칭되는 팀 프로파일을 갖는 단일 팀 인박스에 할당될 수 있다. 그러나, 상기 팀을 포함하는 상기 사용자들 중 오직 일부만이 상기 팀 인박스 내의 상기 태스크를 열람 가능할 수 있다. 이러한 선택적 액세스는, 해당 태스크들에 대한 액세스 권한을 갖는 상기 사용자들 중 상기 일부에 의해서만 열람되어야 할 상기 태스크들의 상기 태스크 템플릿에 보안 요건, 또는 키 값을 포함함으로써, 달성될 수 있다. 상기 보안 요건은 업무 값에 대해 체크될 수 있다. 예를 들면, 상기 사용자는 상기 메모를 할당받기 위해 상기 메모의 값보다 더 큰 허용되는 최대 금액을 가질 필요가 있을 수 있으며, 여기서 상기 메모 값은 상기 태스크의 상기 업무 데이터에 의해 정의된다. 그 다음에, 상기 태스크 액세스 권한을 갖는 상기 사용자들 중 상기 일부는 상기 팀 사용자들 중 상기 일부를 포함하는 각 사용자의 상기 사용자 프로파일에 상기 보안 요건 또는 키 값을 포함함으로써 정의될 수 있다.
상기 태스크 처리 모듈(52)은 조직 역할 기반 액세스 권한에 기반하여 어떤 인박스가 상기 태스크(60)를 수신해야 할지를 추가적으로 결정할 수 있다. 이러한 액세스 권한은 어떤 액세스 레벨이 상기 태스크(60)를 열람해야 할 필요가 있는가에 대한 보안 문제에 기반할 수 있다. 상기 태스크(60)에 대한 보안 요건은, 보안 레벨들이 각 태스크에 대해 별도로 정의되도록 할 수 있는, 상기 태스크 템플릿(62)에 의해 정의될 수 있다. 액세스 권한이 태스크들을 할당하는데 이용될 수 있는 방법의 예로서, 태스크들의 세트가, 상기한 바와 같은 업무 데이터를 만족시키는 상기 태스크들에 기반하여, 동일 팀에 할당될 수 있다. 그러나, 상기 팀을 포함하는 각 사용자는 사용자들에게 부속되는 특정 규칙을 만족시키는 태스크들만을 수신할 수 있다(예를 들면, 상기 사용자 인박스는 탑승 지점들 NCE 및 PAR에 관련된 태스크들만 수신하지만, 반면에 상기 팀 인박스는 모든 탑승 지점들에 대한 태스크들을 수신한다). 이로써 상기 태스크 템플릿은 상기 태스크 처리 모듈(52)이 상기 태스크 유형에 관련된 업무 규칙 및 보안 요건에 기반하여 인박스들을 선택 가능하도록 할 수 있다.
상기 업무 데이터는 또한 상기 태스크(60)의 소재를 찾기(locate) 위한 검색 패널(search panel)에서의 기준(criteria)으로서 이용될 수 있다. 태스크들을 업무 데이터에 기반하여 특화된 팀들 또는 사용자들에게 할당함으로써, 태스크 할당은 상기 사용자의 숙련기술에 기반하여 최적화될 수 있다. 태스크 템플릿은 사용자들이 그들이 작업하도록 자격을 갖는 및 인가되는 상기 태스크들에 대한 액세스만을 제공받도록 보장하는데 이용될 수 있다. 예를 들면, 태스크들은, 상기 태스크가 상기 사용자가 처리하도록 허용된 최대 금액 미만의 금액 및 상기 사용자의 사용자 프로파일에 매칭되는 탑승 지점을 갖는 경우, 상기 사용자의 상기 인박스에만 발송될 수 있다. 따라서, 사용자들은 업무 영역을 통해 정의된 그들의 지식 영역에 관련된 태스크들에 대한 액세스를 제공받을 수 있고, 상기 업무 데이터에 기반한 검색 기준을 이용하여 더 미세하게 태스크들을 검색할 수 있다.
상기 태스크 템플릿 내의 데이터에 기반한 태스크의 동적 할당의 예로서, 상기 항공사가 ADM을 수신한 것에 응답하여 태스크(60)가 발생된 경우를 가정하자. 상기 항공사에 의해 선택되는 상기 업무 데이터에 따라, 상기 ADM 내의 메모 코드의 이유에 기반하여 상기 태스크(60)를 처리하도록 팀이 선택될 수 있다. 즉, 상기 태스크 템플릿(62)은, 상기 태스크(60)가 상기 ADM 내의 메모 코드의 상기 이유에 따라 상이한 팀들에게 발송되도록 하는, 데이터를 포함할 수 있다. 어떤 경우든, 상기 수익 회계 시스템에 의해 제공되는 상기 ADM 애플리케이션은 상기 ADM의 메모 코드의 상기 이유를 상기 태스크에 연관된 ADM을 수신하는 것에 응답하여 발생된 각 태스크(60)에 대한 상기 태스크 템플릿(62)에 저장할 수 있다. 즉, 상기 ADM 애플리케이션은 상기 생성된 태스크 내의 상기 근본적인 ADM 값을 상기 메모 금액 업무 데이터에 대한 값으로서 위치시킬 수 있다.
상기 태스크 템플릿(62)은 또한 어떤 사용자들이 상기 태스크(60)에 액세스할 것인지를 결정하는 액세스 권한 조건을 정의할 수 있다. 이를 위해, 상기 태스크 템플릿(62)은 다음 엔트리들을 포함하도록 설정될 수 있다:
Template Entry 1:
Dynamic assignment: EQUAL(BUSINESS_DATA(reason_for_memo), reason1)
Business area: ADMTEAM1
Template Entry 2:
Dynamic assignment: IN(BUSINESS_DATA(reason_for_memo), [reason2,
reason3])
Business area: ADMTEAM2
Template Entry 3:
Dynamic assignment: NOT(IN(BUSINESS_DATA(reason_for_memo), [reason1,
reason2, reason3])
Business area: ADMTEAM3
상기 예시적 태스크 템플릿(62)을 이용하여, 상기 ADM을 수신한 것에 응답하여 상기 태스크(60)가 발생되는 경우, 상기 태스크(60)는 상기 메모의 이유가 "이유 1(reason 1)"이면 ADM 팀 1의 팀 인박스로 발송될 수 있다. 상기 메모의 이유가 "이유 2(reason 2)" 아니면 "이유 3(reason 3)"이면, 상기 태스크(60)는 ADM 팀 2의 팀 인박스로 전송될 수 있고, 상기 이유가 "이유 1", "이유 2", 또는 "이유 3"이 아니라면, 상기 태스크(60)는 ADM 팀 3의 팀 인박스로 발송될 수 있다. 상기 시나리오 하에서, 이유 코드=이유 1(reason 1)을 갖는 ADM을 수신하는 것에 응답하여 상기 태스크(60)가 발생되었다면, 상기 업무 단위 "ADMTEAM1"에 대한 액세스 제어를 갖는 사용자는 오직 상기 태스크(60)에 대해서만 액세스를 갖게 될 것이다.
상기한 바와 같이, 상기 태스크 템플릿(62)은 또한 보안 요건을 구현하는데 이용될 수 있다. 다른 예로서, 태스크(60)는 상기 티켓이 사용되는 시점에 상기 ETS(20)와 DCS(22) 간의 불일치의 검출에 응답하여 발생될 수 있다. 관여된 항공사에 대한 상기 업무 데이터는 상기 DCS가 상기 불일치를 검출했던 공항과 연관된 팀 또는 사용자, 예를 들면, 팀=샤를 드골(Charles de Gaulle) 공항(CDG)에 의해 처리되도록 요구할 수 있다. 본 예시적 경우에 대해, 상기 템플릿 엔트리들은 이런 식으로 트리거된 모든 태스크들이 동일 팀(예를 들면, 팀 CDG)으로 가도록, 그러나 상기 팀을 포함하는 각 사용자가 그들이 보안 요건을 준수하여 볼 권리를 갖는 태스크들만을 볼 것을 요구할 수 있다. 상기 경우에, 연관된 값을 정의하는 업무 데이터는 상기 수익 회계 시스템 애플리케이션에 의해 상기 태스크 템플릿(62)에 입력될 수 있다. 이 업무 데이터는, 상기 태스크 처리 모듈(52)이 상기 태스크(60)를 상기 태스크(60)에 액세스하도록 인가된 사용자들에게만 표시하는 것을 알도록, 상기 ETS(20)와 DCS(22) 간의 상기 불일치를 유발하는 상기 티켓의 상기 탑승 지점을 정의할 수 있다.
액세스 권한 조건(예를 들면, 요구되는 사용자 액세스 레벨)은 상기 태스크 템플릿(62)에서 다음과 같이 설정될 수 있다:
Template Entry 4:
Access Right: EQUAL(USER_DATA(rev, manage_boardpoint, bpt),
BUSINESS_DATA(boardpoint))
Business Area: AIRPORT
상기 경우에, 작업자, 검증자, 또는 감독자의 역할을 할당받고, 상기 업무 단위 "AIRPORT"에 대해 액세스 제어를 가지며, "Data Boardpoint: NCE for permission manage_boardpoint"를 포함하는 사용자 프로파일을 갖는 사용자는 상기 탑승 지점=NCE를 나타내는 업무 데이터를 포함하는 템플릿을 갖는 AIRPORT에 대한 팀 인박스로 발송되는 태스크들에 액세스할 수 있다. 즉, 다음의 예시적 사용자 프로파일 엔트리들을 갖는 사용자는 상기 태스크에 대한 액세스를 부여받게 될 것이다:
User profile Entry 1:
Data: business area=AIRPORT
boardpoint=NCE for permission manage_boardpoint
Role: OPERATOR
이제 도 10을 참조하면, 상기 태스크 처리 모듈(52)의 상기 사용자 인터페이스(130)에 의해 표시될 수 있는 예시적 검증 창(160)은 태스크 내용 창(task content window, 162), 요약 창(summary window, 164), 설명 창(description window, 166), 코멘트 창(comments window, 168), 및 이력 창(history window, 170)을 포함할 수 있다. 상기 검증 창(160)은 또한 인박스로 돌아가기 버튼(back to inbox button, 172), 코멘트 추가 버튼(add comment buttom, 174), 및 태스크 발송 버튼(dispatch task button, 176)을 포함할 수 있다. 상기 태스크 내용 창(162)은, 상기 검증자가 상기 태스크가 제대로 해결되었는지 여부를 결정할 수 있도록, 선택된 태스크를 상기 검증자에게 표시할 수 있다. 이 결정에 기반하여, 상기 검증자는 태스크 승인 버튼(task approved button, 178)을 활성화하여 상기 태스크를 승인하거나, 아니면 작업자에게 반송 버튼(return to operator button, 180)을 활성화하여 애초에 상기 태스크를 해결한 작업자에게 상기 태스크를 자동적으로 돌려보낼 수 있다. 상기 검증자는 또한 상기 코멘트 추가 버튼(174)을 활성화하여 상기 태스크에 코멘트를 추가하거나, 또는 상기 태스크 발송 버튼(176)을 활성화하여 상기 태스크를 다른 인박스로 발송할 수 있다.
검증자들은 작업자들에 의해 처리되는 태스크들을 검증하는 책임을 맡을 수 있다. 검증자들은 또한, 예를 들면, 작업자가 태스크에 도움을 요청하는 것에 응답하여, 작업자를 대체하여 상기 태스크를 해결할 수 있다. 태스크는 또한 검증 목적으로 발생될 수 있으며, 그러한 경우 상기 태스크는 처음에 작업자에게 가지 않고 상기 검증자의 인박스로 직접 발송될 수 있다. 이는, 예를 들면, 상기 항공사가 상기 항공사가 검증을 원하는 외부 파일을 통한 문서, 또는 수익 회계 사용자 인터페이스를 통해 항공사 사용자에 의해 생성되는 문서를 수신하는 것에 응답하여, 발생할 수 있다. 어떤 경우든, 검증의 유형은 품질 관리(quality control) 및 재정 승인(financial approval)을 포함할 수 있다.
품질 관리 검증은 상기 검증자가 상기 태스크를 해결하기 위해 작업자가 행한 작업을 체크하는 것을 포함할 수 있다. 재정 승인 또는 인가는 상기 항공사의 현금 흐름에 영향을 주거나, 또는 문턱값을 초과하는 금액을 포함하는 태스크들에 대해 요구될 수 있다. 즉, 일부의 경우에, 상기 작업자는 상기 태스크의 검증자 승인 처리를 받도록 요구될 수 있다. 특정 사용자는 태스크에 대한 해결을 제안하고 검증하는 것 둘 다 허용되지 않을 수 있는데, 왜냐하면 그렇게 하는 것은 이러한 의무들이 분리된다는 요건을 위반하는 것이기 때문이다. 처리(processing)와 검증 의무들의 분리는, 상기 처리 및 검증 단계들이 상이한 사용자들에 의해 처리되기 때문에, 상기 태스크 처리 프로세스의 품질을 향상시킬 수 있다.
상기 검증자의 상기 팀 인박스는, 상기 태스크를 발생시킨 이유, 상기 태스크에 대해 제안된 해결책, 및 상기 작업자로부터의 코멘트를 포함하여, 모든 정보를 이용한 검증을 필요로 하는 태스크들을 함유할 수 있다. 상기 검증자는 상기 제안된 해결책에 기반하여 상기 태스크를 검증하거나, 상기 제안된 해결책에 기반하여 상기 태스크를 거부하거나, 또는 상기 작업자를 대신하여 상기 태스크를 해결할 수 있다.
상기 검증 싸이클은, 검증 프로세스들이 상기 항공사에 의해 결정될 수 있도록, 상기 태스크 템플릿에서 정의될 수 있다. 검증은 랜덤 샘플링(random sampling), 업무 데이터, 보안 요건, 사용자 특성, 또는 이들의 조합에 기반하여 수행될 수 있다. 예를 들면, 주어진 태스크 유형에 대해, 검증이 전혀 수행되지 않거나(예를 들면, 해결된 태스크들의 0%가 검증됨), 항상 수행되거나(예를 들면, 해결된 태스크들의 100%가 검증됨), 또는 해결된 태스크들의 샘플링한 것에 대해 수행될 수 있도록(예를 들면, 해결된 태스크들의 20%가 검증됨), 상기 항공사는 상기 태스크 템플릿에서 검증 샘플율(valifation sample rate)을 설정할 수 있다. 업무 데이터는, 일정 값을 초과하는 금액을 포함하는 태스크에 대한 검증 트리거와 같은, 하나 이상의 검증 트리거들을 정의할 수 있다. 예를 들면, 상기 업무 데이터는 태스크 파라미터 및 상기 태스크가 검증되어야 할 상기 태스크 파라미터의 값을 정의할 수 있다. 상기 업무 데이터는 또한 사용자가 검증의 필요 없이 해결할 수 있는 태스크의 최대 금액 값을 추가적으로 정의할 수 있는, 상기 사용자의 역할 또는 상기 사용자의 경험 레벨과 같은, 사용자 특성을 정의할 수 있다. 이로써 업무 데이터는, 파라미터의 유형, 상기 태스크에 대한 상기 파라미터의 값, 또는 상기 태스크를 해결하는 상기 사용자의 특성에 기반하여, 태스크들에 대한 검증 싸이클을 트리거시키는 검증 트리거들을 정의할 수 있다. 보안 설정은, 상기 사용자가 그들의 역할(예를 들면, roll=operator_new)에 얼마나 오래 있었는지와 같은, 상기 태스크를 해결한 상기 사용자의 상기 사용자 프로파일 내의 데이터에 기반하여, 검증을 트리거시킬 수 있다. 검증은 또한, 상기 태스크 템플릿에서 정의되는 논리 연산자들(logical operators)을 이용한 상기 파라미터들의 조합에 기반하여, 트리거될 수 있다.
예로서, 항공사는, 상기 태스크를 해결한 상기 사용자가 해당 역할에서의 경험이 1 년 미만인 작업자일 때 품질 관리를 위해 태스크 유형이 검증되어야만 하고, 해결된 태스크들의 10%를 샘플링하도록 결정할 수 있다. 상기 항공사는 또한, 상기 업무 데이터에 의해 표시되는 바와 같은, 상기 태스크의 금액이 상기 태스크를 해결한 상기 사용자에 대한 최대 인가 금액보다 클 때, 재정 승인이 발생해야 한다고 결정할 수 있다. 이러한 검증 요건들은, 단지 예를 든 것이며, 상기 태스크 템플릿에 다음 엔트리들을 포함함으로써 구현될 수 있다:
Template 5:
Trigger Quality Control: OR(USER_PERMISSION(rev, operator_new),
PERCENTAGE(10))
Trigger Financial Approval: GREATER(BUSINESS_DATA(memo_amount),
USER_DATA(rev, max_amount, amount))
이제 다음 사용자 프로파일을 갖는 사용자를 고려해 보자:
User profile 2:
Role: operator_new
Data: amount: max_amount=1000
사용자 프로파일 2를 갖는 사용자가 템플릿 5와 연관된 태스크를 해결하는 경우, 상기 태스크는 "operator_new"인 상기 사용자의 상기 역할에 기반하여 품질 관리 검증을 받기 위해 검증자의 팀 인박스로 발송될 수 있다. 상기 태스크가 memo_amount>1000을 포함한다면, 상기 태스크는 또한 재정 승인을 받기 위해 다른 검증자의 팀 인박스로 발송될 수도 있다. 이러한 제 2 검증은 상기 품질 관리 검증자가 상기 제안된 해결책을 검증하기 이전 또는 이후에 발생할 수 있다.
상기 검증자는 상기 태스크의 상기 제안된 해결책을 검증하거나 또는 거부할 수 있다. 상기 검증자가 상기 제안된 해결책을 검증한 경우, 상기 제안된 해결책은, 상기 태스크 템플릿에서 어떤 검증 트리거들이 설정되는지에 따라, (예를 들면, 재정 승인을 위해) 다음 검증자의 사용자 인박스로 발송되거나, 또는 종결될 수 있다. 상기 제안된 해결책이 거부되는 경우, 상기 태스크는 추가적인 처리를 위해 애초에 상기 태스크를 해결한 사용자의 사용자 인박스로 반송될 수 있다. 상기 반송된 태스크는 상기 사용자에게 상기 해결된 태스크가 거부된 이유를 통지하는 상기 검증자로부터의 코멘트를 포함할 수 있다. 상기 코멘트는, 예를 들면, 상기 검증 창(160)의 상기 코멘트 창(168)에 입력될 수 있다. 상기 태스크가 오래된 경우에 대해, 상기 검증자는 상기 제안된 해결책을 검증 또는 거부하기 이전에 상기 태스크를 갱신할 수 있다. 상기 태스크가 검증되고 있는 동안, 상기 태스크 처리 모듈(52)은 상기 태스크의 상태를 사용자들에게 통지하기 위해 상기 태스크 템플릿에 검증 상태 표시자(validation status indicator)를 추가할 수 있다. 예시적인 검증 상태 표시자들은 해결됨(resolved), 품질 관리 검증됨(validated quality control), 품질 관리 거부됨(rejected quality control), 재정 승인 검증됨(validated financial approval), 재정 승인 거부됨(rejected financial approval), 양쪽 레벨에서 검증됨(validated at both levels)을 포함할 수 있다.
검증 단계들은 순차적으로 실행될 수 있으며, 모든 검증 단계들이 완료되는 것에 응답하여 상기 태스크는 종결된다. 상기 태스크의 종결시, 상기 해결책의 처리는, 예를 들면, 메모 또는 다른 문서를 발행하여, 시작될 수 있다. 예로서, 상기 수익 회계 시스템은, IATA BSP 대행사 대 항공사 거래를 보고하는 핸드 오프 테이프(Hand-Off Tape, HOT)를 수신하는 것에 응답하여, 과다 환불(over-refund)을 검출할 수 있다. 상기 과다 환불을 검출하는 것에 응답하여, 상기 수익 회계 시스템은, 차례로 상기 태스크 처리 모듈(52)에 의해 작업자의 인박스로 발송될 수 있는, 태스크를 발생시킬 수 있다. 그 다음에, 상기 작업자는 상기 태스크를 열고 상기 환불을 수용할 것인지, ADM을 발행할 것인지, 또는 상기 환불을 거부할 것인지 여부를 결정할 수 있다. 상기 작업자가 상기 ADM을 발행하는 경우에, 상기 해결된 태스크가 검증 싸이클을 트리거시키지 않으면, 상기 ADM이 발행되고 상기 환불은 상기 작업자가 상기 태스크를 해결하자 마자 확정될 수 있다. 반면에, 상기 해결된 태스크가 검증 싸이클을 트리거시키면, 상기 ADM은 발행되지 않고 환불은 최종 검증 싸이클이 성공적으로 완료될 때까지 확정되지 않을 수 있다.
이제 도 11을 참조하면, 검증 창(160)의 상기 이력 창(170)의 화면은 재정 승인이 필요한 태스크에 대한 예시적 작업 흐름을 제공한다. 이력 창(170)은 상기 태스크 중요도(144), 엔벨로프 식별자(envelope identity, 182), 일자 및 시간(184), 사용자 역할(186), 사용자 식별자(188), 취해진 조치(190), 검증(192), 및 코멘트(194)를 위한 열들(columns)을 포함한다. 행(row, 196)에서, 상기 이력 창(170)은 상기 예시적 태스크가 2014년 1월 2일에 상기 팀 인박스에 수신되었다는 것을 보여준다. 이제 행(198)을 참조하면, 작업자(1AREVUSR4)는 2014년 2월 5일에 상기 태스크를 수신하였다. 상기 태스크는, 사용자 인터페이스(130)의 상기 다음 태스크 가져오기 버튼(150)의 활성화에 응답하여, 작업자(1AREVUSR4)의 사용자 인박스로 발송되었을 수 있다. 행(200)에 의해 나타낸 바와 같이, 상기 작업자는 이후에, 재정 승인 검증 요건을 트리거시킨, 상기 태스크를 해결하였다. 행(202)에 의해 나타낸 바와 같이, 상기 태스크는 이후에, (행(204)에 의해 표시되는 바와 같이) 상기 태스크에 코멘트를 추가하였고 (행(206)에 의해 표시되는 바와 같이) 상기 제안된 해결책을 거부한, 재정 승인 검증자(PMANTELET)에게 발송되었다. 행(208)에 의해 표시되는 바와 같이, 상기 태스크는 작업자(1AREVUSR4)에게 반송되었다. 행(210)에 의해 표시되는 바와 같이, 상기 작업자는 상기 태스크를 두 번째 해결하였고, 행(212)에 의해 나타낸 바와 같이, 이는 상기 태스크가 검증자(PMANTELET)에게 다시 발송되는 결과를 가져왔다. 행(214)에 의해 표시되는 바와 같이, 이 때 상기 태스크에 대해 제안된 해결책은 상기 검증자에 의해 검증되었다. 그 다음에, 행(216)의 엔트리에 의해 표시되는 바와 같이, 상기 해결책은 처리되었고 상기 태스크는 종결되었다.
이제 도 12 내지 도 16을 참조하면, 태스크 처리 모듈(52)의 상기 사용자 인터페이스(130)는, 잔무 KPI 창(backlog KPI window, 220), 마감일 KPI 창(221), 소요 시간 KPI 창(222), 일일 활동 창(223), 및 검증 KPI 창(224)을 포함하여, KPI들을 표시하는 복수의 창들을 더 제공할 수 있다. KPI 창들(220 내지 224) 각각은 복수의 행들(230 내지 238)에 배열된 데이터를 표시할 수 있으며, 각 행은 사용자들의 업무 단위 또는 팀을 표시한다. 상기 KPI 창들(220 내지 224)은 또한 상기 KPI 창들(220 내지 224)에 의해 표시되는 결과들을 필터링하거나 또는 달리 범위를 좁히기(narrowing) 위한 기준을 입력하는 보고서 입력 기준 데이터 필드(report input criteria data field, 240)를 포함할 수 있다.
상기 태스크 처리 모듈(52)은 사용자 선택가능 기간에 종결된 태스크들의 분석을 지원하도록 구성될 수 있다. 이용가능한 통계는 애플리케이션별, 태스크 유형별 또는 역할별 취합(aggregation)을 포함할 수 있다. 통계는 효율성 측정을 위해 사용자별 또는 팀별 기준으로 표시될 수 있다. KPI들은, 이력 경향이 결정될 수 있도록, 매시간 또는 매일과 같이, 적합한 단위(granularity)를 이용하여 저장될 수 있다. 본 발명의 일 실시예에서, 상기 태스크 처리기는, 상기 항공사가 KPI 데이터를 이용하여 맞춤형 보고를 생성할 수 있도록, 콤마 분리 값(comma-separated values, .csv) 또는 다른 텍스트 파일과 같이, 표준 파일 포맷으로 상기 KPI 데이터를 내보내도록(export) 구성될 수 있다.
도 12에 나타낸 바와 같이, 상기 예시적 잔무 KPI 윈도우(220)는 작업 부하 결정과 관련된 팀별 기준 태스크 정보를 표시할 수 있다. 이 데이터는 활성중인(230), 할당된 또는 활발히 작업중인(231), 팀에 발송된(232), 또는 오류가 있는(233) 태스크들의 수를 포함할 수 있다. 상기 잔무 KPI 창(220)은 또한, 막대 그래프(도시됨), 선 그래프, 산포도(scatter plot), 또는 다른 어떤 적합한 그래픽 프레젠테이션과 같은, 도표의 형태로 상기 결과들을 표시하는 그래프(250)를 포함할 수 있다.
도 13에 나타낸 바와 같이, 상기 예시적 마감일 KPI 창(221)은 태스크들을 종결하는 적시(timeliness)의 결정에 관련되는 각 팀에 대한 태스크 정보를 표시할 수 있다. 이 데이터는 시간에 맞는 태스크들(252), 레드 존에 있는 할당 또는 인식된 태스크들(254), 레드 존에 있는 팀에 발송된 태스크들(256), 지연되고 있는 할당 또는 인식된 태스크들(258)의 수, 또는 잔무 태스크들(tasks in backlog)과 같이 마감일 기준으로 태스크들의 상태에 관한 다른 어떤 적합한 통계를 포함할 수 있다. 태스크들은 도 13에 나타낸 바와 같이 팀별 기준으로 표시될 수 있거나, 또는 사용자별, 태스크 유형별, 또는 다른 어떤 적합한 기준으로 선택적으로 표시될 수 있다.
도 14에 나타낸 바와 같이, 상기 예시적 소요 시간 KPI 창(222)은 태스크들을 해결하는데 얼마나 많은 시간이 소요되고 있는지에 관한 태스크 정보를 표시할 수 있다. 이 데이터는 실제 소요 시간(262), 사용자 인박스 소요 시간(264), 팀 인박스 소요 시간(266)을 포함할 수 있다. 표시된 시간들은 모니터링 되는 그룹에 대한 태스크당 평균(average) 소요 시간, 태스크당 중간(median) 소요 시간, 또는 태스크당 누적(cumulative) 소요 시간일 수 있다. 본 발명의 대안적 실시예에서, 상기 소요 시간 KPI 창(222)은 또한 수행된 검증 단계들의 수 또는 발생한 거부들(rejections)의 수를 표시하는 데이터를 표시할 수 있다.
도 15에 나타낸 바와 같이, 상기 예시적 일일 활동 KPI 창(223)은, 모니터링되는 기간 동안 생성 및 종결된 태스크들의 수와 같이, 모니터링되는 기간 동안 발생한 활동의 양에 관한 정보를 표시할 수 있다. 이 데이터는 생성된 태스크들(268), 종결된 태스크들(270), 시간에 맞게 종결된 태스크들(272), 늦게 종결된 태스크들(274), 종결된 총 태스크들(276), 검증 싸이클이 수행되지 않은 태스크들(278), 품질 관리 검토(review)가 수행된 태스크들(280), 재정 승인이 수행된 태스크들(282), 품질 관리 검토 및 재정 승인 둘 다 수행된 태스크들(284), 품질 관리 검토에 결격되어 거부된 태스크들(286), 및 재정 승인을 받는데 결격되어 거부된 태스크들(288)의 수를 포함할 수 있다.
도 16에 나타낸 바와 같이, 상기 예시적 검증 KPI 창(224)은 검증되는 태스크들의 수에 관한 정보를 표시할 수 있다. 이 데이터는 품질 관리(290), 및/또는 재정 승인(292)인 수행된 태스크들의 수를 포함할 수 있다.
상기 태스크 처리 모듈(52)의 상기 사용자 인터페이스(130)에 의해 제공되는 상기 KPI들은, 예를 들면, 잔무 태스크들의 수의 증가 또는 감소에 응답하여, 팀들의 구성을 조정하는 것을 용이하게 할 수 있다. 상기 KPI들은 또한 사용자들이 언제 시정 조치를 실행할지 결정하는 것을 도울 수 있다. 예를 들면, 문턱값을 초과하는 거부들의 수에 응답하여, 항공사들은 작업자들에게 증가된 훈련 또는 지도(coaching)를 제공할 수 있다. 상기 제공된 데이터는 또한, 거부들의 수가 예상보다 더 적은 경우, 검증을 수행하는 트리거 레벨들을 조정하는 것을 용이하게 할 수 있다. 태스크들에 대해 소요된 시간의 양에 관한 상기 이력 데이터는 또한 항공사들이 조치들이 효율성에 미친 효과를 결정 가능하게 할 수 있다.
도 17은 상기 태스크 처리 모듈(52)에 의해 구현될 수 있는 검증 최적화 프로세스(300)를 도시한다. 상기 프로세스(300)는 상기 태스크 해결 데이터베이스(54)에 저장된 검증 결과들 및/또는 해결된 태스크들에 기반하여 검증 결정을 동적으로 최적화할 수 있다. 이를 위해, 상기 검증 최적화 프로세스(300)는 검증 서브 프로세스(302), 및 샘플링 서브 프로세스(304)를 포함할 수 있다. 상기 검증 서브 프로세스(302)는 복수의 해결된 태스크들로부터 어떤 해결된 태스크들이 검증되어야 하는지를 결정할 수 있다. 상기 샘플링 서브 프로세스(304)는, 상기 태스크 해결 데이터베이스(54) 내의 이력 데이터에 기반하여, 검증 파라미터들의 세트(306), 확률 파라미터들의 세트(308), 및 샘플링 파라미터들의 세트(310)를 동적으로 결정할 수 있다. 그 다음에, 이러한 파라미터들의 세트들은 검증을 위해 해결된 태스크들을 선택하기 위해 상기 검증 서브 프로세스(302)에 의해 이용될 수 있다.
블록(312)에서, 상기 검증 서브 프로세스(302)는 복수의 해결된 태스크들을 수신할 수 있다. 상기 해결된 태스크들은, 예를 들면, 검토 또는 구현을 위해 가상 팀의 작업자들에 의해 제출된 해결된 태스크들을 포함할 수 있다. 이러한 제출들은, 하루 또는 작업자 교대와 같이, 특정 시간 기간에 걸쳐 발생할 수 있고, 및/또는 상기 해결된 태스크들이 제출되는 큐(queue)에 놓여질 수 있다. 상기 해결된 태스크들의 수신에 응답하여, 상기 검증 서브 프로세스(302)는 블록(314)으로 진행될 수 있다.
블록(314)에서, 상기 검증 서브 프로세스(302)는, 각 해결된 태스크에 대해, 상기 해결된 태스크의 상기 제안된 해결책이 부정확할 확률(PI)을 결정할 수 있다. 이 결정은, 상기 샘플링 서브 프로세스(304)에 의해 결정되는 가중 함수들과 같은, 통계 파라미터들을 포함할 수 있는 상기 검증 파라미터들(306)에 기반할 수 있다. 상기 검증 파라미터들(306)은, 상기 태스크 또는 근거가 되는 거래의 특성과 같은, 입력에 기반하여 상기 확률(PI)을 발생시킬 수 있다. 예시적인 특성들은, 비한정적으로, 태스크의 유형, 상기 태스크를 발생시키는 상기 거래의 하나 이상의 특성들, 또는 상기 태스크의 다른 어떤 적합한 특성을 포함할 수 있다. 상기 검증 파라미터들(306)은 이력 데이터가 상기 태스크 해결 데이터베이스(54)에 추가됨에 따라 동적으로 갱신될 수 있기 때문에, 상기 제안된 해결책이 부정확할 상기 확률(PI)은 이용가능한 가장 최근 데이터에 기반하여 결정될 수 있다. 상기 검증 서브 프로세스(302)는 그 다음에 블록(306)으로 진행될 수 있다.
블록(316)에서, 상기 검증 서브 프로세스(302)는, 상기 제안된 해결책이 부정확하고 문제가 될 수 있다면, 상기 항공사에 대해 예상되는 재정적 영향, 또는 비용을 나타내는 금액(A)을 결정할 수 있다. 이 결정은, 상기 해결책과 연관된 어떤 문서들(예를 들면, ADM)에서든 상기 금액이 부정확할 확률들과 같이, 통계 파라미터들을 포함할 수 있는 상기 확률 파라미터들(308)에 기반할 수 있다. 예로서, ADM을 발생시키는 해결된 태스크에 대해, 상기 금액(A)은 상기 ADM이 분쟁이 될 확률(PD)과 상기 분쟁에 대응하기 위한 추산 비용의 곱(product)에 기반할 수 있다. ADM 또는 조회(inquiry) 발행에 연관된 비용을 결정하는 방법, 시스템, 및 컴퓨터 프로그램 제품들은, 개시가 본 명세서에 모든 목적을 위하여 그 전체가 참조로서 포함된, 대리인 번호 AMS-143US, 2013년 6월 25일에 출원되고 "대행사 차변 메모의 발생의 최적화(OPTIMIZING GENERATION OF AGENCY DEBIT MEMOS)"로 명명된 미국 특허 출원 번호 13/926,136에 보다 상세히 설명되어 있다.
일단 상기 확률(PI) 및 상기 예상 재정 영향 금액(A)이 결정되었으면, 상기 검증 서브 프로세스(302)는 블록(318)으로 진행될 수 있다. 블록(318)에서, 상기 검증 서브 프로세스(302)는, 상기 확률(PI)과 상기 예상 재정 영향 금액(A)의 곱에 기반하여, 각 제안된 해결책을 검증하는 것의 예상 영향(VE)을 결정할 수 있다. 상기 검증 서브 프로세스(302)는 그 다음에 블록(320)으로 진행되고 검증을 위해 상기 해결된 태스크들 중 일부를 선택할 수 있다. 이 부분은 폭넓게 선택되는 해결된 태스크들, 및 해결된 태스크들의 예상 영향(VE)에 기반하여 선택되는 해결된 태스크들을 포함할 수 있다. 이러한 분리는 해결된 태스크들을 검증하기 위한 검증자들의 팀의 수용능력(capacity)을 고려하기 위해 행해질 수 있다. 예로서, 상기 검증자들의 팀은 태스크들을 해결하는 복수의 작업자들을 포함하는 사용자들의 팀에 속하는 하나 이상의 검증자들을 포함할 수 있다. 상기 검증자들의 팀은, 해결된 태스크들에 대한 상기 작업자들의 수용능력보다 더 적은, 해결된 태스크들의 일정 양을 검증할 수용능력을 가질 수 있다. 검증 수용능력에 있어서 이러한 한계로 인해, 상기 해결된 태스크들 중 일부만을 검증하는 것이 바람직할 수 있다.
블록(320)에서, 상기 검증 서브 프로세스(302)는 검증을 위해 상기 태스크들 중 상기 일부를 선택할 수 있다. 검증을 위해 선택된 상기 부분은 폭넓게(예를 들면, 무작위로, 또는 달리 검증되지 않는 해결된 태스크들의 샘플링한 것을 제공하도록) 선택되는 일부분, 및 상기 해결된 태스크들의 상기 예상 영향(VE)에 기반하여 선택되는 다른 부분을 포함할 수 있다. 해결된 태스크들의 예상 영향(VE)에 기반하여 선택된 해결된 태스크들 대비 폭넓게 선택된 해결된 태스크들의 비는 상기 샘플링 파라미터들(310)에 기반하여 결정될 수 있다. 폭넓게 선택된 샘플들 및 상기 예상 영향(VE)에 기반하여 선택된 샘플들을 포함함으로써, 검증을 위해 선택된 상기 해결된 태스크들은 검증의 누적 영향(예를 들면, 검증된 각 해결된 태스크들에 대한 VE의 합)을 최적화할 수 있으며, 반면에 달리 검증되지 않는 해결된 태스크들에서는 이력 데이터를 얻을 수 있다.
블록(322)에서, 상기 검증 서브 프로세스(302)는, 상기 복수의 해결된 태스크들에서의 각 해결된 태스크에 대해, 상기 해결된 태스크가 검증을 위해 선택되었는지 여부를 결정할 수 있다. 상기 해결된 태스크가 검증을 위해 선택되었다면(결정 블록(322)의 "YES" 분기), 상기 검증 서브 프로세스(302)는 블록(324)으로 진행되고 검증이 수행되도록 할 수 있다. 상기 검증 서브 프로세스(302)는, 예를 들면, 상기 해결된 태스크를 상기 검증 팀의 팀 인박스 또는 상기 검증자들 중 하나의 사용자 인박스로 발송함으로써, 상기 검증이 수행되도록 할 수 있다. 상기 검증 서브 프로세스(302)가 상기 해결된 태스크가 검증을 위해 선택되지 않았다고 결정하면(결정 블록(322)의 "NO" 분기), 상기 검증 서브 프로세스(302)는 블록(326)으로 진행되고 상기 해결된 태스크가 검증 없이 처리되도록 할 수 있다. 즉, 상기 검증 서브 프로세스(302)는 상기 해결된 태스크에 의해 정의되는 메모 또는 다른 문서를 발행함으로써 상기 제안된 해결책이 구현되도록 할 수 있다.
블록(324)에서 검증이 수행되는 것에 응답하여, 상기 검증 서브 프로세스(302)는 블록(328)으로 진행되고 상기 해결된 태스크가 검증되었는지 여부를 결정할 수 있다. 상기 해결된 태스크가 검증되는 것에 응답하여(결정 블록(328)의 "YES" 분기), 상기 검증 서브 프로세스(302)는 블록(326)으로 진행되고, 상기한 바와 같이, 상기 제안된 해결책이 구현되도록 할 수 있다. 상기 해결된 태스크가 검증되지 않는 것에 응답하여(결정 블록(328)의 "NO" 분기), 상기 검증 서브 프로세스(302)는 블록(330)으로 진행되고 상기 제안된 해결책을 거부할 수 있다. 상기 제안된 해결책을 거부하는 단계는 상기 태스크를 애초에 상기 태스크를 해결한 상기 작업자의 상기 사용자 인박스로 다시 발송하는 단계를 포함할 수 있다. 상기 해결책을 거부하는 단계는 또한 상기 태스크를, 상기 태스크를 해결할 수 있는 애초의 작업자가 아닌 작업자, 다른 검증자, 감독자, 또는 다른 어떤 사용자의 사용자 인박스와 같은, 다른 사용자 인박스로 발송하는 단계를 포함할 수 있다. 상기 검증 서브 프로세스(302)는 다음에 블록(332)으로 진행되고 상기 검증의 결과들로 상기 태스크 해결 데이터베이스(54)를 갱신할 수 있다.
상기 샘플링 서브 프로세스(304)는, 상기 검증 서브 프로세스(302)에 의해 이용되는 상기 검증 파라미터들(306), 확률 파라미터들(308), 및 샘플링 파라미터들(310)에 대한 값들을 최적화하기 위해, 상기 태스크 해결 데이터베이스(54) 내의 이력 검증 및/또는 태스크 해결 데이터를 검색하고 처리할 수 있다. 이를 위해, 블록(334)에서, 상기 검증 서브 프로세스(302)는, 상기 태스크 해결 데이터베이스(54)로부터 얻은 이력 데이터에 기반하여, 상기 검증 파라미터들(306), 확률 파라미터들(308), 및 샘플링 파라미터들(310)에 대한 현재 또는 개시 값들을 이용하여 검증 및 해결 결과들을 결정할 수 있다.
본 발명의 일 실시예에서, 상기 샘플링 서브 프로세스(304)는, 상기 태스크 해결 데이터베이스(54) 내의 상기 이력 데이터에 기반하여, 상이한 값들을 갖는 복수의 검증 파라미터들에 대한 실제 영향(VA)을 결정할 수 있다. 상기 샘플링 서브 프로세스(304)는 그 다음에, 상기 항공사에게 최대로 긍정적인(또는 최소로 부정적인) 재정적 영향을 주는 상기 태스크 해결 데이터베이스(54)에 저장된 실제 결과를 이용하여 결정되는, 가장 바람직한 또는 최적의 누적 영향, 예를 들면, VA의 값들의 합을 제공하는 상기 검증 파라미터들(306)에 대한 값들을 선택할 수 있다. 이 프로세스는 확률 파라미터들(308)의 세트 및 샘플링 파라미터들(310)의 세트에 대해 반복될 수 있다. 상기 갱신 프로세스는 반복적일 수 있으며, 파라미터들의 각 세트에 대해 최적의 값들이 결정될 때까지 반복될 수 있다. 상기 파라미터들의 갱신된 세트들은, 상기 검증 최적화 프로세스(300)의 총 재정적 영향을 최적화하도록 결정된, 검증 파라미터들(306), 확률 파라미터들(308), 및 샘플링 파라미터들(310)의 조합일 수 있다.
일단 상기 파라미터들이 결정되었으면, 상기 샘플링 서브 프로세스(304)는 블록들(336, 338, 및 340)로 진행되고 각각 상기 검증 파라미터들(306), 확률 파라미터들(308), 및 샘플링 파라미터들(310)을 갱신할 수 있다. 이로써 상기 검증 서브 프로세스(302)는 상기 검증 파라미터들(306), 확률 파라미터들(308), 및 샘플링 파라미터들(310)을 동적으로 갱신할 수 있고, 이에 따라 이 파라미터들은 이용가능한 가장 최근의 데이터를 반영한다.
상기한 바와 같이, 상기 샘플링 파라미터들(310)은 폭넓게 선택된 해결된 태스크들을 검증하는데 이용되어야 할 상기 검증 수용능력(validation capacity)의 일부를 결정하는데 이용될 수 있다. 나머지 수용능력은 다음에 상기 예상 영향에 기반하여 해결된 태스크들을 평가하는데 이용될 수 있고, 제안된 해결책이 검증을 위해 선택될 확률은 상기 검증의 상기 예상 영향(VE)에 비례한다. 즉, 상기 갱신된 샘플링 파라미터들(310)은 상기 검증 최적화 프로세스(300)의 총 재정적 영향을 최적화하도록 결정된 샘플링 파라미터들(310)일 수 있다. 이 최적화는, 상기 폭넓은 샘플링에 의해 제공되는 추가적인 데이터에 기인하는 상기 확률(PI) 및 상기 예상 재정 영향 금액(A)의 증가된 정확도로 인해, 상기 폭넓게 선택된 태스크들을 검증하는 것으로부터 예상되는 이익을 고려할 수 있다.
상기 샘플링 파라미터들(310)을 결정하기 위해, 상기 샘플링 서브 프로세스(304)는 상기 태스크 해결 데이터베이스(54) 내의 이력 태스크 데이터를 이용하여 심층적(in-depth) 샘플링 대비 폭넓은 샘플링의 복수의 비들에 대해 재정적 영향을 결정할 수 있다. 상기 샘플링 서브 프로세스(304)는 그 다음에 최선의 결과를 제공하는 비를 선택할 수 있다. 상기 폭넓은 샘플링은, 태스크 유형 또는 업무 단위와 같은, 제한된 기준 세트(limited set of criteria)에 기반하여 선행 검증들의 결과들을 검토할 수 있다. 상기 폭넓은 샘플링은 상기 태스크 해결 데이터베이스 내의 상기 이력 데이터가 태스크들의 폭넓은 스펙트럼을 포괄하도록 구성될 수 있다. 상기 심층적 샘플링은, 상기 예상 영향(VE)과 같은 더 많은 태스크 특정적 데이터, 상기 태스크를 수행 또는 검증한 사용자, 출발지-목적지 쌍과 같은 티켓 파라미터들, 티켓 요금, 또는 다른 어떤 적합한 데이터에 기반하여, 결과들을 검토할 수 있다. 어떤 경우든, 상기 검증 서브 프로세스(302)에 의해 이용되는 심층적 샘플링 대비 폭넓은 샘플링의 비는 샘플링 파라미터들(310)에 기반하여 결정될 수 있다. 예를 들면, 상기 샘플링 파라미터들(310)은 샘플링 수용능력의 x%가 폭넓은 샘플링에 전용되어야 하고, 상기 샘플링 수용능력의 (100-x)%가 심층적 샘플링에 전용되어야 한다는 것을 표시할 수 있다.
일반적으로, 본 발명의 실시예들을 구현하기 위해 실행되는 루틴들(routines)은, 운영 체제의 일부 또는 특정 애플리케이션, 구성요소, 프로그램, 오브젝트(object), 명령어들의 모듈 또는 시퀀스, 또는 심지어 이들의 서브세트(subset)로서 구현되든지 간에, 본 명세서에서 "컴퓨터 프로그램 코드", 또는 단순히 "프로그램 코드"로 칭해질 수 있다. 프로그램 코드는 통상 다양한 때에 컴퓨터 내의 다양한 메모리 및 저장 장치들에 상주하고, 및, 컴퓨터 내의 하나 이상의 프로세서들에 의해 판독되고 실행될 때, 컴퓨터가 본 발명의 실시예들의 다양한 측면들을 구현하는 작업들 또는 요소들을 실행하는데 필요한 작업들을 수행하도록 하는 컴퓨터 판독가능 명령어들을 포함한다. 본 발명의 실시예들의 작업들을 수행하기 위한 컴퓨터 판독가능 프로그램 명령어들은, 예를 들면, 어셈블리 언어, 소스 코드, 및/또는 하나 이상의 프로그래밍 언어들 중 어떤 조합으로든지 작성된 오브젝트 코드일 수 있다.
본 명세서에서 설명하는 다양한 프로그램 코드는 상기 프로그램 코드가 본 발명의 특정 실시예들에서 구현되는 애플리케이션에 기반하여 식별될 수 있다. 그러나, 다음의 어떤 특정한 프로그램 명칭(nomenclature)이든지 단지 편의를 위해 사용되는 것이고, 따라서 본 발명은 그러한 명칭에 의해 식별 또는 암시되는(implied) 오로지 어떤 특정한 애플리케이션에서의 사용에만 제한되어서는 안 된다는 것을 이해해야 할 것이다. 나아가, 컴퓨터 프로그램들이 루틴들, 절차들, 방법들, 모듈들, 및 오브젝트들 등으로 조직화될 수 있는 방법들의 일반적으로 무한히 많은 수 뿐만 아니라 프로그램 기능이 통상의 컴퓨터 내에 상주하는 다양한 소프트웨어 계층들(예를 들면, 운영 체제들, 라이브러리들, API들, 애플리케이션들, 애플릿들(applets) 등) 중에 할당될 수 있는 다양한 방법들을 고려해 볼 때, 본 발명의 실시예들은 본 명세서에서 설명하는 프로그램 기능의 특정한 조직화(organization) 및 할당(allocation)에 제한되지 않는다는 것을 이해해야 할 것이다.
본 명세서에서 설명하는 애플리케이션들 및/또는 모듈들 중 어떤 것에서든지 구현되는 상기 프로그램 코드는 개별적으로 또는 총괄적으로 다양한 상이한 형태의 프로그램 제품으로서 배포될 수 있다. 특히, 상기 프로그램 코드는 프로세서가 본 발명의 실시예들의 측면들을 수행하도록 하는 컴퓨터 판독가능 프로그램 명령어들을 갖는 컴퓨터 판독가능 저장 매체를 이용하여 배포될 수 있다.
본질적으로 비일시적인, 컴퓨터 판독가능 저장 매체는, 컴퓨터 판독가능 명령어들, 데이터 구조들, 프로그램 모듈들, 또는 기타 데이터와 같은, 정보의 저장을 위해 어떤 방법 또는 기술로든지 구현된, 휘발성 및 비휘발성, 및 탈착식 및 고정식(removable and non-removable)의 유형 매체를 포함할 수 있다. 컴퓨터 판독가능 저장 매체는 RAM, ROM, 소거가능 프로그램가능 읽기 전용 메모리(erasable programmable read-only memory, EPROM), 전기적 소거가능 프로그램가능 읽기 전용 메모리(electrically erasable programmable read-only memory, EEPROM), 플래시 메모리 또는 기타 솔리드 스테이트 메모리 기술, 이동식 컴팩트 디스크 읽기 전용 메모리(portable compact disc read-only memory, CD-ROM) 또는 기타 광학적 저장체, 자기 카세트, 자기 테이프, 자기 디스크 저장체 또는 기타 자기 저장 장치들, 또는 원하는 정보를 저장하는데 이용될 수 있고 컴퓨터에 의해 판독될 수 있는 다른 어떤 매체를 더 포함할 수 있다. 컴퓨터 판독가능 저장 매체는 그 자체로 일시적인 신호들(예를 들면, 라디오파들(radio waves) 또는 다른 전파되는 전자기파들, 도파관과 같은 전송 매체를 통해 전파되는 전자기파들, 또는 전선을 통해 전송되는 전기 신호들)로서 해석되어서는 안 된다. 컴퓨터 판독가능 명령어들은 컴퓨터 판독가능 저장 매체로부터 컴퓨터, 다른 유형의 프로그램가능 데이터 처리 장치, 다른 장치로, 또는 네트워크를 통해 외부 컴퓨터 또는 외부 저장 장치로 다운로드될 수 있다.
컴퓨터 판독가능 매체에 저장된 컴퓨터 판독가능 프로그램 명령어들은, 상기 컴퓨터 판독가능 매체에 저장된 상기 명령어들이 흐름도들, 시퀀스 다이어그램들(sequence diagrams), 또는 블록도들에서 구체화되는 기능들, 행위들(acts), 또는 작업들(operations)을 구현하는 명령어들을 포함하는 제조 물품을 생산하도록, 컴퓨터, 다른 유형의 프로그램가능 데이터 처리 장치, 또는 다른 장치들이 특정한 방식으로 기능하도록 지시하는데 이용될 수 있다. 상기 컴퓨터 프로그램 명령어들은 기계를 생산하기 위해 범용 컴퓨터, 특수 목적 컴퓨터, 또는 다른 프로그램 가능 데이터 처리 장치의 하나 이상의 프로세서들에 제공될 수 있으며, 이에 따라 상기 하나 이상의 프로세서들을 통해 실행되는 상기 명령어들은 일련의 연산들이, 흐름도들, 시퀀스 다이어그램들, 또는 블록도들에 구체화되는 기능들, 행위들, 또는 작업들을 구현하기 위해, 수행되도록 한다.
일정 대안적 실시예들에서, 상기 흐름도들, 시퀀스 다이어그램들, 또는 블록도들에 구체화되는 상기 기능들, 행위들, 또는 작업들은, 본 발명의 실시예들과 일관되게, 순서가 재배열되거나, 순차적으로 처리되거나, 또는 동시에 처리될 수 있다. 또한, 상기 흐름도들, 시퀀스 다이어그램들, 또는 블록도들 중 어떤 것이든, 본 발명의 실시예들과 일관되게, 도시된 것들보다 더 많은 또는 더 적은 블록들을 포함할 수 있다.
본 명세서에 사용된 용어는 단지 특정 실시예들을 설명하기 위한 목적이며 본 발명의 실시예들을 제한하고자 한 것이 아니다. 본 명세서에서, 단수의 표현은 문맥상 명백히 다른 경우를 제외하고는 복수의 표현을 포함하고자 한 것이다. "포함하다(comprise)"라는 용어는, 본 명세서에서 사용되는 경우, 진술된 특징들, 정수들(integers), 단계들, 작업들, 요소들, 또는 구성요소들의 존재를 특정하는 것이지, 하나 이상의 다른 특징들, 정수들, 단계들, 작업들, 요소들, 구성요소들, 또는 이들의 그룹들의 존재 또는 추가를 미리 배제하지 않는 것으로 이해되어야 할 것이다. 또한, "포함하다(include)", "가지다(have)", "구성되다(comprised of)", 또는 이들의 변형과 같은 용어들이 상세한 설명이나 아니면 청구항에 사용되는 한도에서, 그러한 용어들은 "포함하는(comprising)"이란 용어와 유사한 방식으로 포괄적인 것으로 의도된 것이다.
본 발명 전부가 다양한 실시예들의 설명에 의해 예시되었고, 이 실시예들이 상당히 상세히 설명되었지만, 출원인의 의도는 첨부된 청구항의 범위를 어떤 식으로도 그러한 세부 사항에 제한 또는 한정하고자 하는 것이 아니다. 추가적인 장점들 및 변형들은 본 발명이 속하는 기술분야의 숙련된 자들이 쉽게 알 수 있을 것이다. 그러므로, 보다 폭넓은 측면들에 있어서의 본 발명은, 도시되고 설명된, 특정 세부 사항들, 대표적인 장치 및 방법, 및 예시적 예들에 제한되지 않는다. 따라서, 출원인의 일반적인 발명 개념의 사상 또는 범위를 벗어나지 않고 이러한 세부 사항들과 다른 실시예들이 가능할 수 있다.

Claims (23)

  1. 복수의 팀 인박스들(team inboxes)을 이용하여 복수의 태스크들(tasks)을 관리하는 방법에 있어서, 각 팀 인박스는 팀 프로파일(team profile)을 가지며, 상기 방법은,
    상기 복수의 태스크들의 각 태스크에 대해:
    컴퓨터에 의해, 상기 태스크의 유형을 결정하는 단계;
    상기 컴퓨터에 의해, 상기 태스크의 상기 유형에 매칭되는 상기 팀 프로파일을 갖는 하나 이상의 팀 인박스들을 결정하는 단계; 및
    상기 컴퓨터에 의해, 상기 태스크를 상기 매칭되는 팀 프로파일을 갖는 상기 하나 이상의 팀 인박스들 중 하나에 추가하는 단계; 및
    제 1 복수의 사용자들 중 각 사용자에 대해:
    상기 컴퓨터에 의해, 상기 복수의 팀 인박스들 중 하나 이상에 대한 액세스를 인가하는(authorizing) 단계; 및
    상기 컴퓨터에 의해, 상기 사용자가 액세스하도록 인가되지 않은 각 팀 인박스에 대한 액세스를 거부하는 단계
    를 포함하며,
    각 팀 인박스는 상기 팀 인박스 내의 태스크들에 대한 액세스를 갖는 사용자들의 가상 팀(virtual team)을 정의하는 것인, 복수의 팀 인박스들을 이용하여 복수의 태스크들을 관리하는 방법.
  2. 제 1 항에 있어서,
    상기 복수의 팀 인박스들 중 제 1 팀 인박스에 대한 액세스를 갖는 제 2 복수의 사용자들 중 각 사용자에 대해:
    상기 사용자의 적어도 하나의 특성(characteristic)을 포함하는 사용자 프로파일(user profile)을 정의하는 단계;
    사용자 인박스를 상기 사용자 프로파일과 연관시키는 단계; 및
    상기 사용자가 상기 사용자 인박스에 액세스하도록 인가하는 단계; 및
    상기 제 1 팀 인박스 내의 적어도 하나의 태스크에 대해:
    상기 태스크의 상기 유형에 매칭되는 상기 사용자 프로파일을 결정하는 단계; 및
    상기 태스크를 상기 제 1 팀 인박스로부터 상기 매칭되는 사용자 프로파일과 연관된 상기 사용자 인박스로 이동시키는 단계를 더 포함하는, 복수의 팀 인박스들을 이용하여 복수의 태스크들을 관리하는 방법.
  3. 제 2 항에 있어서,
    상기 매칭되는 사용자 프로파일과 연관된 상기 사용자 인박스는 작업자(operator)의 제 1 사용자 프로파일과 연관된 제 1 사용자 인박스이고,
    감독자(supervisor)의 제 2 사용자 프로파일을 정의하는 단계;
    제 2 사용자 인박스를 상기 제 2 사용자 프로파일과 연관시키는 단계; 및
    상기 태스크를 상기 제 1 사용자 인박스로부터 상기 제 2 사용자 인박스로 발송하는(dispatching) 단계를 더 포함하는, 복수의 팀 인박스들을 이용하여 복수의 태스크들을 관리하는 방법.
  4. 제 2 항에 있어서,
    상기 사용자 인박스 내의 각 태스크에 대해:
    상기 태스크에 관한 핵심 성과 지표(key performance indicator)를 데이터베이스에 저장하는 단계; 및
    상기 핵심 성과 지표를 상기 사용자 인박스에 액세스하도록 인가된 상기 사용자, 상기 태스크의 상기 유형, 또는 상기 태스크를 해결하는데 이용되는 애플리케이션(application)과 연관시키는 단계를 더 포함하는, 복수의 팀 인박스들을 이용하여 복수의 태스크들을 관리하는 방법.
  5. 제 2 항에 있어서,
    상기 제 2 복수의 사용자들은 제 1 사용자 유형의 하나 이상의 사용자들 및 제 2 사용자 유형의 하나 이상의 사용자들을 포함하고,
    상기 제 1 사용자 유형의 제 1 계층 레벨(hierarchical level)을 결정하는 단계;
    상기 제 2 사용자 유형의 제 2 계층 레벨을 정의하는 단계; 및
    상기 제 1 계층 레벨이 상기 제 2 계층 레벨보다 더 높은 것에 응답하여:
    상기 제 2 사용자 유형의 각 사용자의 각 사용자 인박스에 대한 액세스를 갖는 모니터링 인박스를 구성하는 단계; 및
    상기 제 1 사용자 유형의 상기 하나 이상의 사용자들이 상기 모니터링 인박스에 액세스하도록 인가하는 단계를 더 포함하는, 복수의 팀 인박스들을 이용하여 복수의 태스크들을 관리하는 방법.
  6. 제 5 항에 있어서,
    상기 모니터링 인박스에 대한 액세스를 갖는 상기 제 1 사용자 유형의 상기 하나 이상의 사용자들은 상기 모니터링 인박스 내의 태스크들을 소환하도록(recall) 추가적으로 인가되는 것인, 복수의 팀 인박스들을 이용하여 복수의 태스크들을 관리하는 방법.
  7. 제 2 항에 있어서,
    상기 제 1 팀 인박스는 제 1 태스크 및 제 2 태스크를 포함하고,
    상기 제 1 태스크 및 상기 제 2 태스크의 상대적인 긴급성을 결정하는 단계; 및
    상기 제 1 태스크 및 상기 제 2 태스크 중 하나를 상기 제 1 팀 인박스로부터 상기 제 2 복수의 사용자들 중 한 명의 상기 사용자 인박스에 할당하라는 요청에 응답하여, 더 높은 상대적인 긴급성을 갖는, 상기 제 1 태스크 및 상기 제 2 태스크 중 상기 하나를 할당하는 단계를 더 포함하는, 복수의 팀 인박스들을 이용하여 복수의 태스크들을 관리하는 방법.
  8. 제 7 항에 있어서,
    상기 제 1 태스크 및 상기 제 2 태스크의 상기 상대적인 긴급성은, 적어도 부분적으로 상기 제 2 태스크에 대한 상기 상기 제 1 태스크의 상대적 중요도(severity), 상기 제 2 태스크에 대한 상기 상기 제 1 태스크의 상대적 기한(due date), 또는 상기 제 2 복수의 사용자들 중 상기 한 명의 상기 사용자 인박스에 할당된 선행(previous) 태스크에 대한 상기 제 1 태스크 및 상기 제 2 태스크의 상대적 유사성에 기반하여, 결정되는 것인, 복수의 팀 인박스들을 이용하여 복수의 태스크들을 관리하는 방법.
  9. 제 1 항에 있어서,
    상기 복수의 태스크들 중 제 1 태스크의 발생을 트리거시킨 제 1 회계 문제(accounting issue)의 근본 원인(root cause)을 결정하는 단계;
    상기 근본 원인이 제 2 태스크의 발생을 트리거시키는 제 2 회계 문제를 생성시키는지 여부를 결정하는 단계; 및
    상기 근본 원인이 상기 제 2 회계 문제를 생성시키는 것에 응답하여, 상기 제 2 회계 문제를 상기 제 1 태스크로 통합하고 상기 제 2 태스크의 발생을 억제하는 단계를 더 포함하는, 복수의 팀 인박스들을 이용하여 복수의 태스크들을 관리하는 방법.
  10. 제 1 항에 있어서,
    복수의 해결된 태스크들 각각에 대해:
    상기 해결된 태스크의 제안된 해결책이 부정확할 확률을 결정하는 단계;
    상기 제안된 해결책이 부정확하다면 상기 해결된 태스크를 구현하는 것의 예상 재정 영향을 결정하는 단계; 및
    상기 확률 및 상기 예상 재정 영향에 기반하여 상기 해결된 태스크를 검증하는(validating) 것의 예상 영향을 결정하는 단계; 및
    적어도 부분적으로 각 해결된 태스크를 검증하는 것의 상기 예상 영향, 및 상기 해결된 태스크들을 검증하기 위한 검증자들의 팀의 수용능력(capacity)에 기반하여, 검증을 위해 상기 복수의 해결된 태스크들 중 일부를 선택하는 단계를 더 포함하는, 복수의 팀 인박스들을 이용하여 복수의 태스크들을 관리하는 방법.
  11. 제 10 항에 있어서,
    검증을 위해 상기 복수의 해결된 태스크들 중 상기 일부를 선택하는 단계는:
    검증되는 각 해결된 태스크에 대해, 상기 검증의 결과를 데이터베이스에 저장하는 단계; 및
    상기 데이터베이스에 저장된 상기 결과에 기반하여, 무작위로 선택된 해결된 태스크들에 적용되는 상기 수용능력의 제 1 부분 및 각 해결된 태스크를 검증하는 것의 상기 예상 영향에 기반하여 상기 해결된 태스크들에 적용되는 상기 수용능력의 제 2 부분을 결정하는 단계를 포함하고,
    상기 제 1 부분 및 상기 제 2 부분은 상기 복수의 해결된 태스크들에 걸쳐 검증의 누적 영향을 최적화하여 결정되는 것인, 복수의 팀 인박스들을 이용하여 복수의 태스크들을 관리하는 방법.
  12. 제 10 항에 있어서,
    검증되는 각 해결된 태스크에 대해, 상기 검증의 결과를 데이터베이스에 저장하는 단계; 및
    상기 데이터베이스에 저장된 상기 결과에 기반하여, 검증 파라미터들의 세트 및 확률 파라미터들의 세트를 결정하는 단계를 포함하고,
    상기 제안된 해결책이 부정확할 상기 확률은 검증 파라미터들의 상기 세트에 기반하여 결정되고, 및
    상기 제안된 해결책이 부정확하다면 상기 해결된 태스크를 구현하는 것의 상기 예상 재정 영향은 확률 파라미터들의 상기 세트에 기반하여 결정되는 것인, 복수의 팀 인박스들을 이용하여 복수의 태스크들을 관리하는 방법.
  13. 제 1 항에 있어서,
    상기 복수의 태스크들 중 각 태스크는 태스크 템플릿(task template)과 연관되고, 및 상기 복수의 태스크들 중 각 태스크에 대해:
    상기 태스크 템플릿에 기반하여 상기 태스크에 대한 검증 트리거(trigger)를 결정하는 단계;
    상기 태스크가 해결되는 것에 응답하여, 상기 검증 트리거가 트리거되는지 여부를 결정하는 단계; 및
    상기 검증 트리거가 트리거되는 것에 응답하여, 상기 태스크를 검증 싸이클과 연관된 상기 하나 이상의 팀 인박스들로 발송하는 단계를 더 포함하는, 복수의 팀 인박스들을 이용하여 복수의 태스크들을 관리하는 방법.
  14. 제 1 항에 있어서,
    상기 복수의 태스크들 중 각 태스크는 태스크 템플릿(task template)과 연관되고, 및 상기 복수의 태스크들 중 각 태스크에 대해:
    상기 태스크 템플릿으로부터 업무 데이터(business data)를 추출하는 단계;
    상기 업무 데이터에 의해 식별되는 태스크 파라미터의 값을 결정하는 단계;
    상기 값을 상기 하나 이상의 팀 인박스들의 상기 팀 프로파일과 비교하는 단계; 및
    상기 비교에 기반하여 상기 하나 이상의 팀 인박스들 중 하나를 상기 태스크와 매칭시키는 단계를 더 포함하고,
    상기 태스크는 상기 하나 이상의 팀 인박스들 중 상기 하나에 추가되는 것인, 복수의 팀 인박스들을 이용하여 복수의 태스크들을 관리하는 방법.
  15. 제 14 항에 있어서,
    상기 제 1 복수의 사용자들 중 각 사용자는 사용자 프로파일과 연관되고, 상기 제 1 복수의 사용자들 중 각 사용자에 대해:
    상기 태스크 템플릿으로부터 보안 요건을 추출하는 단계;
    상기 사용자의 상기 사용자 프로파일이 상기 보안 요건을 만족시키는지 여부를 결정하는 단계; 및
    상기 사용자 프로파일이 상기 보안 요건을 만족시키지 못하면, 상기 사용자가 상기 태스크에 액세스하는 것을 차단하는 단계를 더 포함하는, 복수의 팀 인박스들을 이용하여 복수의 태스크들을 관리하는 방법.
  16. 복수의 팀 인박스들을 이용하여 복수의 태스크들을 관리하는 시스템에 있어서, 각 팀 인박스는 팀 프로파일을 가지며, 상기 시스템은,
    프로세서; 및
    메모리를 포함하며,
    상기 메모리는, 상기 프로세서에 의해 실행될 때, 상기 시스템으로 하여금,
    상기 복수의 태스크들 중 각 태스크에 대해:
    상기 태스크의 유형을 결정하고,
    상기 태스크의 상기 유형에 매칭되는 상기 팀 프로파일을 갖는 하나 이상의 팀 인박스들을 결정하며,
    상기 태스크를 상기 매칭되는 팀 프로파일을 갖는 상기 하나 이상의 팀 인박스들 중 하나에 추가하고,
    제 1 복수의 사용자들 중 각 사용자에 대해:
    상기 복수의 팀 인박스들 중 하나 이상에 대한 액세스를 인가하고,
    상기 사용자가 액세스하도록 인가되지 않은 각 팀 인박스에 대한 액세스를 거부하도록 하는
    명령어들을 포함하며,
    각 팀 인박스는 상기 팀 인박스 내의 태스크들에 대한 액세스를 갖는 사용자들의 가상 팀을 정의하는 것인, 복수의 팀 인박스들을 이용하여 복수의 태스크들을 관리하는 시스템.
  17. 제 16 항에 있어서,
    상기 명령어들은 상기 시스템으로 하여금,
    상기 복수의 팀 인박스들 중 제 1 팀 인박스에 대한 액세스를 갖는 제 1 복수의 사용자들 중 각 사용자에 대해:
    상기 사용자의 적어도 하나의 특성을 포함하는 사용자 프로파일을 정의하고,
    사용자 인박스를 상기 사용자 프로파일과 연관시키며,
    상기 사용자가 상기 사용자 인박스에 액세스하도록 인가하고,
    상기 제 1 팀 인박스 내의 적어도 하나의 태스크에 대해:
    상기 태스크의 상기 유형에 매칭되는 상기 사용자 프로파일을 결정하고,
    상기 태스크를 상기 제 1 팀 인박스로부터 상기 매칭되는 사용자 프로파일과 연관된 상기 사용자 인박스로 이동시키도록 또한 구성되는 것인, 복수의 팀 인박스들을 이용하여 복수의 태스크들을 관리하는 시스템.
  18. 제 17 항에 있어서,
    상기 명령어들은, 상기 시스템으로 하여금, 상기 사용자 인박스 내의 각 태스크에 대해,
    상기 태스크에 관한 핵심 성과 지표를 데이터베이스에 저장하고,
    상기 핵심 성과 지표를 상기 사용자 인박스에 액세스하도록 인가된 상기 사용자, 상기 태스크의 상기 유형, 또는 상기 태스크를 해결하는데 이용되는 애플리케이션과 연관시키도록 또한 구성되는 것인, 복수의 팀 인박스들을 이용하여 복수의 태스크들을 관리하는 시스템.
  19. 제 16 항에 있어서,
    상기 명령어들은 상기 시스템으로 하여금,
    상기 복수의 태스크들 중 제 1 태스크의 발생을 트리거시킨 제 1 회계 문제의 근본 원인을 결정하고,
    상기 근본 원인이 제 2 태스크의 발생을 트리거시키는 제 2 회계 문제를 생성시키는지 여부를 결정하며,
    상기 근본 원인이 상기 제 2 회계 문제를 생성시키는 것에 응답하여, 상기 제 2 회계 문제를 상기 제 1 태스크로 통합하고 상기 제 2 태스크의 발생을 억제하도록 또한 구성되는 것인, 복수의 팀 인박스들을 이용하여 복수의 태스크들을 관리하는 시스템.
  20. 제 16 항에 있어서,
    상기 명령어들은 상기 시스템으로 하여금,
    복수의 해결된 태스크들 각각에 대해:
    상기 해결된 태스크의 제안된 해결책이 부정확할 확률을 결정하고,
    상기 제안된 해결책이 부정확하다면 상기 해결된 태스크를 구현하는 것의 예상 재정 영향을 결정하며,
    상기 확률 및 상기 예상 재정 영향에 기반하여 상기 해결된 태스크를 검증하는 것의 예상 영향을 결정하고,
    적어도 부분적으로 각 해결된 태스크를 검증하는 것의 상기 예상 영향, 및 상기 해결된 태스크들을 검증하기 위한 검증자들의 팀의 수용능력에 기반하여, 검증을 위해 상기 복수의 해결된 태스크들 중 일부를 선택하도록 또한 구성되는 것인, 복수의 팀 인박스들을 이용하여 복수의 태스크들을 관리하는 시스템.
  21. 제 16 항에 있어서,
    상기 복수의 태스크들 중 각 태스크는 태스크 템플릿과 연관되고, 상기 명령어들은 상기 시스템으로 하여금, 상기 복수의 태스크들 중 각 태스크에 대해:
    상기 태스크 템플릿으로부터 업무 데이터를 추출하고,
    상기 업무 데이터에 의해 식별되는 태스크 파라미터의 값을 결정하며,
    상기 값을 상기 하나 이상의 팀 인박스들의 상기 팀 프로파일과 비교하고,
    상기 비교에 기반하여 상기 하나 이상의 팀 인박스들 중 하나를 상기 태스크에 매칭시키도록 또한 구성되며,
    상기 태스크는 상기 하나 이상의 팀 인박스들 중 상기 하나에 추가되는 것인, 복수의 팀 인박스들을 이용하여 복수의 태스크들을 관리하는 시스템.
  22. 제 21 항에 있어서,
    상기 제 1 복수의 사용자들 중 각 사용자는 사용자 프로파일과 연관되고, 상기 명령어들은 상기 시스템으로 하여금, 상기 제 1 복수의 사용자들 중 각 사용자에 대해:
    상기 태스크 템플릿으로부터 보안 요건을 추출하고,
    상기 사용자의 상기 사용자 프로파일이 상기 보안 요건을 만족시키는지 여부를 결정하며,
    상기 사용자 프로파일이 상기 보안 요건을 만족시키지 못하면, 상기 사용자가 상기 태스크에 액세스하는 것을 차단하도록 또한 구성되는 것인, 복수의 팀 인박스들을 이용하여 복수의 태스크들을 관리하는 시스템.
  23. 복수의 팀 인박스들을 이용하여 복수의 태스크들을 관리하는 컴퓨터 프로그램 제품에 있어서, 상기 컴퓨터 프로그램 제품은,
    비일시적 컴퓨터 판독가능 저장 매체; 및
    상기 비일시적 컴퓨터 판독가능 저장 매체에 저장된 명령어들
    을 포함하며,
    상기 명령어들은, 프로세서에 의해 실행될 때, 상기 프로세서로 하여금,
    상기 복수의 태스크들 중 각 태스크에 대해:
    상기 태스크의 유형을 결정하고,
    상기 태스크의 상기 유형에 매칭되는 상기 팀 프로파일을 갖는 하나 이상의 팀 인박스들을 결정하며,
    상기 태스크를 상기 매칭되는 팀 프로파일을 갖는 상기 하나 이상의 팀 인박스들 중 하나에 추가하고,
    제 1 복수의 사용자들 중 각 사용자에 대해:
    상기 복수의 팀 인박스들 중 하나 이상에 대한 액세스를 인가하고,
    상기 사용자가 액세스하도록 인가되지 않은 각 팀 인박스에 대한 액세스를 거부하도록 하며,
    각 팀 인박스는 상기 팀 인박스 내의 태스크들에 대한 액세스를 갖는 사용자들의 가상 팀을 정의하는 것인, 복수의 팀 인박스들을 이용하여 복수의 태스크들을 관리하는 컴퓨터 프로그램 제품.
KR1020150137847A 2014-10-01 2015-09-30 자동 작업 처리 KR20160039552A (ko)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US14/503,720 2014-10-01
US14/503,720 US20160098681A1 (en) 2014-10-01 2014-10-01 Automated task handling
EP15000572.6 2015-02-27
EP15000572.6A EP3002726A1 (en) 2014-10-01 2015-02-27 Automated task handling

Publications (1)

Publication Number Publication Date
KR20160039552A true KR20160039552A (ko) 2016-04-11

Family

ID=52598558

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020150137847A KR20160039552A (ko) 2014-10-01 2015-09-30 자동 작업 처리

Country Status (5)

Country Link
US (1) US20160098681A1 (ko)
EP (1) EP3002726A1 (ko)
KR (1) KR20160039552A (ko)
AU (1) AU2015231165A1 (ko)
CA (1) CA2906865A1 (ko)

Families Citing this family (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105373419A (zh) 2014-08-26 2016-03-02 阿里巴巴集团控股有限公司 一种后台应用的操作方法及装置
US20160098667A1 (en) * 2014-10-07 2016-04-07 Salesforce.Com, Inc. Customizable skills database
US11164120B2 (en) * 2015-03-16 2021-11-02 Swarm Vision, Inc. Behavioral profiling with actionable feedback methodologies and systems
US20220138661A1 (en) * 2015-03-16 2022-05-05 Swarm Vision, Inc. Behavioral Profiling with Actionable Feedback Methodologies and Systems
US9705751B1 (en) * 2016-03-31 2017-07-11 Sas Institute Inc. System for calibrating and validating parameters for optimization
US10298414B2 (en) * 2016-04-20 2019-05-21 Black Knight Ip Holding Company, Llc Intelligent transducers for transforming signals in complex computing networks
CN106372207B (zh) * 2016-09-05 2019-07-16 北京蓝色光标品牌管理顾问股份有限公司 公众号信息的影响力排序方法及排序系统
US20190096001A1 (en) * 2017-09-25 2019-03-28 Eusoh, Inc. Platform implementing retrospective loss pooling
CN110033145B (zh) * 2018-01-10 2024-02-02 顺丰数据服务(武汉)有限公司 财务共享作业分单方法及装置、设备和存储介质
US11210116B2 (en) * 2019-07-24 2021-12-28 Adp, Llc System, method and computer program product of navigating users through a complex computing system to perform a task
CN110908778B (zh) * 2019-10-10 2024-03-19 平安科技（深圳）有限公司 任务部署方法、系统和存储介质
JP2021193511A (ja) * 2020-06-08 2021-12-23 富士フイルムビジネスイノベーション株式会社 情報処理装置及びプログラム
US11720836B1 (en) 2020-07-29 2023-08-08 Wells Fargo Bank, N.A. Systems and methods for facilitating secure dual custody activities
US11822771B2 (en) 2021-06-30 2023-11-21 Microsoft Technology Licensing, Llc Structuring communication and content for detected activity areas
CN113435763B (zh) * 2021-07-05 2022-10-14 苗懿 一种基于大数据的任务自动领取系统及方法
CN114895997A (zh) * 2022-03-22 2022-08-12 北京字跳网络技术有限公司 一种关联任务的方法、装置及电子设备
CN117032722B (zh) * 2023-08-18 2024-04-26 上海澜码科技有限公司 基于api文档的代码生成方法

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7437304B2 (en) * 1999-11-22 2008-10-14 International Business Machines Corporation System and method for project preparing a procurement and accounts payable system
US20070299953A1 (en) * 2006-06-26 2007-12-27 Bellsouth Intellectual Property Corporation Centralized work distribution management
US7869098B2 (en) * 2006-06-30 2011-01-11 Edcor Data Services Corporation Scanning verification and tracking system and method
US10453029B2 (en) * 2006-08-03 2019-10-22 Oracle International Corporation Business process for ultra transactions
WO2008140709A1 (en) * 2007-05-08 2008-11-20 Metropolitan Life Insurance Co. System and method for workflow management
US8738414B1 (en) * 2010-12-31 2014-05-27 Ajay R. Nagar Method and system for handling program, project and asset scheduling management
US9172704B2 (en) * 2014-02-14 2015-10-27 Bank Of America Corporation System for allocating a work request

Also Published As

Publication number Publication date
AU2015231165A1 (en) 2016-04-21
CA2906865A1 (en) 2016-04-01
US20160098681A1 (en) 2016-04-07
EP3002726A1 (en) 2016-04-06

Similar Documents

Publication Publication Date Title
KR20160039552A (ko) 자동 작업 처리
CN112950162B (zh) 信息系统工程监理工作派发管理信息系统
CN111815283B (zh) 信息系统工程监理企业业务管理系统
US20230385843A1 (en) Programmatic approvals of corporate spend and employee expense
CN110770771A (zh) 用于管理临时工的系统和界面
US10803459B2 (en) Online transaction processing system for multi-product transactions
US11080795B1 (en) Identifying and utilizing the availability of enterprise resources
US20160232532A1 (en) Using revenue management to improve payment fraud screening
US20170278019A1 (en) Online transaction processing system for multi-product transactions
US20170177575A1 (en) Processing transactions involving an exchange of an electronic document
EP2985722A1 (en) Auditing system with historic sale deviation database
US20160012502A1 (en) Preventive auditing
US10032230B2 (en) Auditing system with historic sale deviation database
EP2911103A1 (en) Auditing system with increased accuracy
US20150242960A1 (en) Auditing system with increased accuracy
US20170278163A1 (en) Online transaction processing system for multi-product transactions
US20170278158A1 (en) Online transaction processing system for multi-product transactions
US20160260099A1 (en) Prioritizing transactions in a transaction queue
US10402877B2 (en) Online transaction processing system for multi-product transactions
KR102189658B1 (ko) 이력적 판매 편차 데이터베이스를 갖춘 감사 시스템
KR20150030608A (ko) 회계감사 규칙 최적화기
EP3065096A1 (en) Manual review optimization for predictive fraud screening
EP3057054A1 (en) Using revenue management to improve payment fraud screening
CA2919621A1 (en) Using revenue management to improve payment fraud screening
CA2882471A1 (en) Auditing system with increased accuracy