It is often the case that expected, or unexpected, change requires a change in the way a business must operate. For example, the launch of a new product can require existing systems to be integrated, new regulation can require the recording of process steps or an acquisition can require the merging of two product lines and processes. Traditional enterprise system planning and rollout can absorb these issues; however, these planning cycles are designed for large projects, not supporting everyday operational change. As a result, changes are implemented at great cost and sometimes only over many years, as new systems replacing the functionality of the original systems and providing the required new functionality must be developed and require extensive testing and quality assurance before they can reliably be implemented. These systems must also be designed and configured by people with the required specialist skills in computer programming and application development. This adds more time to the development process since there are often relatively few people with the required skills, if any, within an organization and, once such systems are implemented, the time it takes for users of the original systems to become acquainted with the new systems can be long and the process is often characterized by inefficiency and inaccuracy.
The problem arises because back office business processes can often involve multiple independent and incompatible software applications. Some of these software applications may have APIs which facilitate the transfer of information in or out of an application by providing a predefined interface through which another software application may interact; however this is not always the case. For example, many of the software applications used in these back office business processes are old applications designed without the features required to allow easy access by other software applications. Others are custom in-house software solutions created to serve a very specific purpose where the need to provide an interface through which other applications could interact was not foreseen. Traditionally, this is overcome by using operational staff to bridge the gap between these software applications. The use of operational staff is an expensive solution, since large numbers of operational staff may need to be employed to provide the capacity required. Since the gap between these incompatible software applications or systems is bridged by a human, the process is typically slow since operational staff only work for part of the day, are limited by the speed at which they can input information or commands using a keyboard and mouse or any other interface and are limited by the speed at which they can read information from a screen or other output. Furthermore, humans are susceptible to errors in input of data or commands to a system and in reading information from another, which a computer is not. There also exists the possibility, when operational staff are used in such a manner, that malicious interference with processes, systems and data can occur.
For example, a telecoms provider may launch a new mobile phone handset which requires the use of existing software applications and new systems which may be incompatible. This shortfall is usually filled by operational staff, but often it is not possible to predict the demand for such newly launched products and so too many or too few staff are trained to use the software systems. It is, therefore, desirable to fill this gap between incompatible software systems with a solution which allows for rapid scaling to cope with demand, without requiring detailed knowledge of the demand up-front.
In such systems, large volumes of information, which may be sensitive personal information are often handled. It is also desirable to handle this information in a consistent manner which reduces the number of errors that may be associated with a human simply copying information from one system to another and it is also desirable to handle the information in a private and secure manner which is only accessible when absolutely necessary.
These problems, which require operational staff to fill in where pre-existing software applications fall short of the functionality required for a new process to be implemented, are not unique to the business back office. For example, the reception of a hospital or doctor's surgery is often a busy environment with many patients arriving for appointments. Receptionists spend a lot of time carrying out routine tasks such as taking details from patients arriving for appointments and inputting them into a software application which checks the patient in for their appointments. This process is often slow, can be inaccurate due to patient details being misheard and takes away the receptionists' time from carrying out other duties.
It may be desirable to provide self-service check-in kiosks in the reception of the hospital or doctor's surgery which enable patients arriving to input their own details to the system so that inaccuracies are minimized, receptionists are free to deal with other tasks and waiting times are reduced. However, to provide a patient with the same interface as that provided to the receptionist may not be appropriate, since the software applications used by the receptionist is likely to have more advanced features that are unnecessarily confusing to the patient or the application may have administrative controls or access to information that it would be inappropriate to provide to patients using a self-service check-in kiosk. Unless the existing receptionist application provides the capability for a new application which is run on the self-service kiosks to access certain functions and features, the same long planning cycles, expense, inefficiency and inaccuracy associated with change in back office business processes apply when new software applications and systems which provide the required functionality to implement these systems are developed. This often results in such projects never being undertaken. Many other such examples will be apparent to the reader.
Existing solutions involve the use of virtual machines as virtual workers that are configured to automate these processes by interacting with legacy software. Such a system is described in PCT application publication number WO 2015/001360 A1; however, these systems require a user to determine how work items should be distributed among the virtual workers, and this is often an inefficient way of determining such things. There is therefore a need for an appropriate system and method for optimizing the distribution of work items among the virtual workers.
USPTO Backgrounds
USPTO Backgrounds