Patent Application
20120185290
This disclosure pertains to a method and system for providing a centralized interface to an integrated work queue of tasks (e.g., action items) where each task could have originated on a different and potentially remote system. More particularly, but not by way of limitation, this disclosure relates to a Hub (centralized system) and Spoke (remote system) integration of service tasks wherein each service task may further be automatically enabled for processing (i.e., performance of the task) in the context and environment of the originating Spoke system.
Today's enterprise computing environments comprise a plurality of techniques to support end users. Additionally, programmable control devices located at a personal residence often require technical support. Implementations of “trouble ticket” or customer support capabilities can be tailored for a particular vendor or environment. Typical trouble shooting support employees are confined to a particular set of support capabilities or environments they can support.
As the need for customer support has increasingly been “outsourced” to service providers, prior art techniques of providing support to disparate technologies and environments have caused an unneeded segmentation of support staff. Additionally, outsourcing implementations commonly cross countries and different countries have substantially different rules about transmission and storage of data. In particular, different countries have substantially different data privacy laws, so copying complete data records (or even persistent storage of data) to provide an efficient support mechanism may not conform to the different governmental laws and regulations. Additionally, corporate policy may dictate that certain information may not be copied and stored at an “outsourcing” location. Because of these concerns, complete replication of data or federation of trouble support databases may not be a viable solution.
Additionally, prior art techniques are typically limited to a single environment or potentially a small number of support environments because support engineers are confined by the capabilities of their support infrastructure. Solutions to these and other problems are described below to allow a support engineer's support infrastructure to dynamically adapt, based on the infrastructure and technology in use at the supported environment, as opposed to being limited by the supporting environment.
The present disclosure is described in the context of a service desk to provide centralized support for a variety of end users and systems. A service desk can provide many different types of capabilities including Change Management, Release Management, Service Request Management, Customer Service call center capabilities and Task Management to name a few. Each of these can be thought of in the general sense of a service desk because they are all processes that can involve the submission of a set of information that needs to be assigned to groups/individuals where the assigning and assigned people may have to work across entries arriving from multiple distinct sources. Any technical support work model that requires cross location and cross group management may benefit from the concepts of this disclosure.
To aid in the understanding of this disclosure the following definitions are provided:
A general overview is now provided using the above terminology and then more detailed embodiments are described. In general, a Hub-user connects to the Hub allowing the Hub-user a single system to provide a complete list of the work the Hub-user is responsible for. The Hub-user is provided correctly ranked and prioritized information regardless of the origin of the service request. The Hub could have logic that adjusts and rebalances priorities of assignments as appropriate. Priorities may be determined based on severity of problem, service level agreements, contracted support obligations (e.g., gold level, silver level, bronze level), and other methods known to those of ordinary skill in the art.
In one embodiment, the Hub-user and the support staff do not perform actual work from the Hub. They connect to the Hub to access their work queue and when they access a particular task to perform work on the task the Hub-user can be automatically redirected to a “work session” (e.g., a work connection such as a hosted window or a telnet connection) with the appropriate Spoke or system associated with the Spoke-region. In this manner, the Hub-user can connect to the Hub and when they begin work on a task they can be: automatically connected to, open the details, and perform the work on the appropriate Spoke that owns the requested task. When the task is complete, the Hub-user can close that session and retrieve the next highest priority assigned task (as assigned at the Hub) to begin work on the appropriate item. Also, a Hub-user may not be limited to working one particular task at a time and may be working several concurrent tasks and thus have several “work sessions” to one or more Spokes at any given time.
Security may be accounted for in a number of ways. Upon initiation of the session with the Spoke a password prompt could be provided. Alternatively, single sign-on credentials could be incorporated into the Hub and Spoke architecture to only allow certain Hub-users direct connection capabilities to the Spoke-regions they support.
Because of the logical architecture of the Hub and Spoke system, there is no requirement that all spokes host the same version of an application or even the same applications. Spoke-regions could have different logic and work differently from each other. In this case the Hub-user performing the task may get a different “look and feel” of the application they are supporting but can be spared the need to know (or remember) how to initiate different support applications in different Spoke-regions. Because each task is worked in the context of the Spoke-region, data and conformance policies of systems in the particular Spoke-region are still in effect.
Overall, the approach described herein allows the retention of local instances of an application with local differences while also providing consolidated global access to the work in progress within the system for the workers and the management personnel responsible for the disparate systems. The local systems at a Spoke-region are not required to change in order to participate in the disclosed environment so virtually any application can be accommodated in this shared environment. For example, this may allow for more seamless transition of support tasks when a corporate acquisition takes place.
In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the inventive concept. As part of this description, some structures and devices may be shown in block diagram form in order to avoid obscuring the invention. Moreover, the language used in this disclosure has been principally selected for readability and instructional purposes, and may not have been selected to delineate or circumscribe the inventive subject matter, resort to the claims being necessary to determine such inventive subject matter. Reference in the specification to “one embodiment” or to “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the invention, and multiple references to “one embodiment” or “an embodiment” should not be understood as necessarily all referring to the same embodiment.
It will be appreciated that in the development of any actual implementation (as in any development project), numerous decisions must be made to achieve the developers' specific goals (e.g., compliance with system- and business-related constraints), and that these goals will vary from one implementation to another. It will also be appreciated that such development efforts might be complex and time-consuming, but would nevertheless be a routine undertaking for those of ordinary skill in the information technology support system field having the benefit of this disclosure.
Referring now to
Also, Central Hub System 110 is shown here as a single system for simplicity. However, Central Hub System 110 can be a logical collection of one or more support systems located in one or more data centers communicatively coupled to each other. Furthermore, in the case where Central Hub System 110 includes a collection of one or more support systems, the Spoke systems may be exclusively related to a single support system of the Hub or, alternatively, related to more than one of the support systems of the Hub at a time. As shown, support requests collected at Central Hub System 110 can originate from a plurality of remote regions. Remote regions reflect one or more sets of Remote-users that may typically be in a different physical location from a support staff member (i.e., a Hub-user). To properly administer support to a remote region there should be at least one communication coupling between the remote region and the Hub-user. This connection may be direct or indirect. The communication coupling could be network communication capability to propagate data (e.g., trouble ticket information) between the remote region and Central Hub System 110 or it could comprise a Remote-user communicating (e.g., via phone or email) to a “help desk” or “call center” for entry of a trouble ticket. In either case, a problem ticket may be opened for a problem in the environment of the end-user.
After entry, the trouble ticket information, or a portion thereof, may be propagated to a Hub-user for support action. Upon receipt at Central Hub System 110, the new trouble ticket information can be integrated or prioritized relative to a plurality of other requests for service or support. Additionally, upon receipt or thereafter the new trouble ticket may be assigned, either automatically or manually, to an appropriate Hub-user or Spoke-user for attention. Again, note that a software application managing trouble ticket information for a Spoke-region may be different from the software application providing the same function at Central Hub System 110 or other Spoke-regions.
Referring now to
Referring now to
Referring now to
Program control device 410 may be included in a computing device and be programmed to perform methods in accordance with this disclosure. Program control device 410 may itself comprise processor unit (PU) 420, input-output (I/O) interface 450 and memory 430. Processing unit 420 may include any programmable control device including, for example, processors of an IBM mainframe (such as a quad-core z10 mainframe microprocessor). Alternatively, in non-mainframe systems examples of processing unit 420 include the Intel Core®, Pentium® and Celeron® processor families from Intel and the Cortex and ARM processor families from ARM. (INTEL CORE, PENTIUM and CELERON are registered trademarks of the Intel Corporation. CORTEX is a registered trademark of the ARM Limited Corporation. ARM is a registered trademark of the ARM Limited Company.) Memory 430 may include one or more memory modules and comprise random access memory (RAM), read only memory (ROM), programmable read only memory (PROM), programmable read-write memory, and solid state memory. One of ordinary skill in the art will also recognize that PU 420 may also include some internal memory including, for example, cache memory.
Aspects of the embodiments are described as a method of control or manipulation of data, and may be implemented in one or a combination of hardware, firmware, and software. Embodiments may also be implemented as instructions stored on a machine-readable medium, which may be read and executed by at least one processor to perform the operations described herein. A machine-readable medium may include any mechanism for tangibly embodying information in a form readable by a machine (e.g., a computer). For example, a machine-readable medium (sometimes referred to as a program storage device or a computer readable medium) may include read-only memory (ROM), random-access memory (RAM), magnetic disc storage media, optical storage media, flash-memory devices, electrical, optical, and others.
In the above detailed description, various features are occasionally grouped together in a single embodiment for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed embodiments of the subject matter require more features than are expressly recited in each claim.
Various changes in the details of the illustrated operational methods are possible without departing from the scope of the following claims. For instance, illustrative flow chart steps or process steps of
It is to be understood that the above description is intended to be illustrative, and not restrictive. For example, the above-described embodiments may be used in combination with each other. Many other embodiments will be apparent to those of skill in the art upon reviewing the above description. The scope of the invention should, therefore, be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled. In the appended claims, the terms “including” and “in which” are used as the plain-English equivalents of the respective terms “comprising” and “wherein.”
