Integrating action requests from a plurality of spoke systems at a hub system

BACKGROUND

0001This 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.

0002Today'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.

0003As 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.

0004Additionally, 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.

BRIEF DESCRIPTION OF THE DRAWINGS

0005<figref idref="DRAWINGS">FIG. 1</figref> illustrates, in block diagram form, an example of a Hub and Spoke architecture configured to provide remote support to local systems or customers according to one disclosed embodiment.

0006<figref idref="DRAWINGS">FIG. 2</figref> illustrates a flow chart depicting problem ticket generation at a Spoke system and transmission of a required subset of information to a Hub system user for action to address the problem ticket.

0007<figref idref="DRAWINGS">FIG. 3</figref> illustrates, in flowchart form, an embodiment of addressing a problem ticket in the context of a Hub user.

0008<figref idref="DRAWINGS">FIG. 4</figref> illustrates, in block diagram form, an example computing device comprising a program control device.

DETAILED DESCRIPTION

0009The 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.

0010To aid in the understanding of this disclosure the following definitions are provided: <ul id="ul0001" list-style="none"><li id="ul0001-0001" num="0000"><ul id="ul0002" list-style="none"><li id="ul0002-0001" num="0011">Hub-user: a user of the logical Central Hub System providing support wherein that support may be initiated based on prioritized tasks in a work queue (e.g., problem tickets entered into a problem tracking system).</li><li id="ul0002-0002" num="0012">Spoke-user: a user on a remote Spoke system environment providing support to the Spoke environment directly (i.e., locally) when remote support may not be desired. For example, physical access to change a disk drive may be required or a very high priority task may require immediate local intervention.</li><li id="ul0002-0003" num="0013">Remote-user: an end user desiring device support; including users of a corporate infrastructure or customers of a service provider. Typically, a Remote-user will be neither a Spoke-user nor a Hub-user and will receive the desired support from either the Spoke-user or the Hub-user. However, a Remote-user may interact with the Spoke in various capacities. For example, the Remote-user may submit tickets (e.g., request support), check status or update information.</li><li id="ul0002-0004" num="0014">Spoke-region (region): a logical collection of programmable control devices conforming to at least a portion of a standard set of support applications and governmental laws/regulations.</li><li id="ul0002-0005" num="0015">Hub (or Central Hub System): a logical collection point for task requests originating from a plurality of connected Spoke-regions.</li></ul></li></ul>

0016A 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.

0017In 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.

0018Security 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.

0019Because 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.

0020Overall, 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.

0021In 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.

0022It 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.

0023Referring now to <figref idref="DRAWINGS">FIG. 1</figref>, a block diagram <b>100</b> illustrates a Hub and Spoke architecture according to one embodiment. Central Hub System <b>110</b> reflects a collection point for support requests. In this example, support request could originate in three different Spoke-regions (<b>1</b>-<b>3</b>). Spoke systems A (<b>120</b>) and B (<b>130</b>) are in Spoke-region <b>1</b>; Spoke systems C (<b>140</b>) and D (<b>150</b>) are in Spoke-region <b>2</b>; and Spoke systems E (<b>160</b>) and F (<b>170</b>) are in Spoke-region <b>3</b>. Note, for simplicity this example shows each of Spoke systems A-F are bi-directionally linked to Central Hub System <b>110</b>. However, many different forms of communication capabilities could be used in different Spoke-regions and a Spoke-region (or system in a Spoke-region) may not be directly connected bi-directionally with Central Hub System <b>110</b>. Additionally, even though two systems are shown in each region, a region could contain any number of Spoke systems or computers associated with Spoke systems.

0024Also, Central Hub System <b>110</b> is shown here as a single system for simplicity. However, Central Hub System <b>110</b> 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 <b>110</b> 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 <b>110</b> 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 <b>110</b> 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.

0025After 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 <b>110</b>, 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 <b>110</b> or other Spoke-regions.

0026Referring now to <figref idref="DRAWINGS">FIG. 2</figref>, flow chart <b>200</b> depicts a possible work flow for problem support request processing according to one embodiment. Beginning at block <b>210</b>, a problem is detected on a computing device of Spoke A in region <b>1</b> (See <figref idref="DRAWINGS">FIG. 1</figref>). To obtain appropriate support, a problem ticket can be generated as shown in block <b>215</b> in the problem tracking system associated with devices of region <b>1</b>. At block <b>220</b>, it can be determined, either manually or automatically, whether the problem ticket should be addressed locally at region <b>1</b> or through support provided by augmented support staff (e.g., outsourced support staff). If it is determined to service the problem ticket locally (the YES prong of block <b>220</b>), flow can continue to block <b>222</b> with no need for Hub-user or Hub System interaction. However, if it is determined to include the Hub support staff (the NO prong of block <b>220</b>), at least a portion of the problem ticket information may be propagated to Central Hub System <b>110</b> as shown in block <b>250</b>. The propagated portion can represent less than all information (e.g., a subset or “sub-ticket”) available at Spoke A region <b>1</b><b>120</b> because propagation of some information may be prohibited from being sent to Central Hub System <b>110</b>. Upon receipt at the Central Hub System <b>110</b>, the new sub-ticket (i.e. subset of problem ticket information) can be integrated and prioritized with respect to other new and already existing support tickets (block <b>260</b>). After receipt, either an automatic assignment or manual assignment (block <b>265</b>) may be performed. A Hub-user can then monitor a work list of assigned, integrated and prioritized problem ticket tasks and address the current highest priority ticket assigned to them (block <b>270</b>). Blocks <b>225</b>, <b>230</b>, <b>240</b> and <b>242</b> reflect problem ticket origination similar to that described for blocks <b>210</b>-<b>222</b> for a different Spoke system (D) and a different user in a different Spoke region (i.e., region <b>2</b>). Note that the problem ticket administration environment, such as a problem tracking software application in use in region <b>1</b>, may or may not be the same type of software application in use for region <b>2</b>. This can be accomplished at least in part because only a subset of problem ticket information need be propagated to Central Hub System <b>110</b>.

0027Referring now to <figref idref="DRAWINGS">FIG. 3</figref>, flow chart <b>300</b> illustrates a possible work flow for a Hub-user working on Central Hub System <b>110</b>. Beginning at block <b>310</b> a Hub-user will typically select the next highest priority ticket from the integrated list of work tasks in his/her queue. Note that not all Hub-users will necessarily see the same integrated list of work tasks. Each Hub-user may have different security permissions and may also support different types of technology used by end-users. For example, Hub-users may be trained to work on different types of computer systems (e.g., mainframe, desktop computers, workstation computer systems, server type computers, computers running different types of operating systems, computers running different types of applications, etc.). If a Hub-user is not trained or does not have security to work on a particular trouble ticket, that work task will preferably not be displayed to that particular Hub-user. After a Hub-user selects a task to work on, the information which had previously been propagated to Central Hub System <b>110</b> and possibly other information can be collected to activate a session (block <b>320</b>) with the Spoke system (or a computing device associated with the region of the Spoke system). The session may be activated in the context of the Spoke system's region so that the Hub-user is now “working” the ticket in the environment associated with the origination of the problem ticket (block <b>330</b>). As noted above, different regions may run different types of computer applications and different types of environments. By using a session in the context of the Spoke system's region the Hub-user can more effectively address issues particular to the trouble ticket. In this manner, the environment of the Hub-user on Central Hub System <b>110</b> is not as apt to interfere with the Hub-user's ability to work the ticket. For example, the Central Hub System <b>110</b> does not have to have any particular versions of software which may vary (and possibly conflict) from region to region. Flow may then continue to block <b>340</b> where a status of the ticket associated with a work task may be updated. The status may be updated directly in the problem tracking software of the Spoke system region and propagated back to the Hub-system (if appropriate) or can be updated at the Hub-system and propagated back to the Spoke system region (block <b>350</b>). In either case, a status update may be done in a single location by the Hub-user and if the problem was addressed the trouble ticket can be closed at a single location without forcing a Hub-user to update a status in two systems. Similarly, if notes are to be added to a non-solved ticket the ticket can be updated in a single location and likely re-assigned to either a Spoke-user or another Hub-user for additional support.

0028Referring now to <figref idref="DRAWINGS">FIG. 4</figref>, example computing device <b>400</b> is shown. One or more example computing devices <b>400</b> may be included in a mainframe or distributed computer (neither shown). Example computing device <b>400</b> comprises a programmable control device <b>410</b> which may be optionally connected to input devices <b>460</b> (e.g., keyboard, mouse, touch screen, etc.), display <b>470</b> and/or program storage device (PSD) <b>480</b> (sometimes referred to as a direct access storage device DASD). Also, included with program control device <b>410</b> is network interface <b>440</b> for communication via a network with other computing and corporate infrastructure devices (not shown). Note network interface <b>440</b> may be included within programmable control device <b>410</b> or be external to programmable control device <b>410</b>. In either case, programmable control device <b>410</b> will be communicatively coupled to network interface <b>440</b>. Also note, program storage unit <b>480</b> represents any form of non-volatile storage including, but not limited to, all forms of optical and magnetic storage elements including solid-state storage.

0029Program control device <b>410</b> may be included in a computing device and be programmed to perform methods in accordance with this disclosure. Program control device <b>410</b> may itself comprise processor unit (PU) <b>420</b>, input-output (I/O) interface <b>450</b> and memory <b>430</b>. Processing unit <b>420</b> 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 <b>420</b> 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 <b>430</b> 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 <b>420</b> may also include some internal memory including, for example, cache memory.

0030Aspects 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.

0031In 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.

0032Various 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 <figref idref="DRAWINGS">FIGS. 2 and 3</figref> may be performed in an order different from that disclosed here. Alternatively, some embodiments may combine the activities described herein as being separate steps. Similarly, one or more of the described steps may be omitted, depending upon the specific operational environment the method is being implemented in. In addition, acts in accordance with <figref idref="DRAWINGS">FIGS. 2 and 3</figref> may be performed by a programmable control device executing instructions organized into one or more program modules. A programmable control device may be a single computer processor, a special purpose processor (e.g., a digital signal processor, “DSP”), a plurality of processors coupled by a communications link or a custom designed state machine. Custom designed state machines may be embodied in a hardware device such as an integrated circuit including, but not limited to, application specific integrated circuits (“ASICs”) or field programmable gate array (“FPGAs”).

0033It 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.”