SYSTEM AND METHOD FOR ENSURING TIMING STUDY QUALITY IN A SERVICE DELIVERY ENVIRONMENT

A system for ensuring timing study quality in a service delivery environment, comprises a participation module capable of determining a level of participation by assets in the timing study, a volume module capable of comparing effort data volume with workload data volume, and a records module capable of analyzing effort data for a duration for each record, wherein one or more of the modules are implemented on a computer system comprising a memory and at least one processor coupled to the memory.

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS

Exemplary embodiments of the invention will now be discussed in further detail with regard to interactive and metric-based systems and methods for ensuring timing study quality in a service delivery environment. This invention may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein.

Assets as used herein can refer to any asset or set of assets, and configurations thereof, that are used to contribute to delivering a service and/or responding to one or more service requests. Assets may have one or more attributes that are used to meet the needs of a customer requiring a service and/or response to a service request. For example, assets may include computer applications and application attributes, e.g., a payroll function; equipment and attributes of equipment capability related to the service; a knowledge-base with particular attributes (e.g., search index); and/or a staffing configuration, which is a configuration of service agents for delivering one or more of such services and/or responding to one or more service requests. A configuration of assets can include one or more assets of different types with different attributes used to deliver the requested services and/or responses.

Embodiments of the present invention address the challenges that may be associated with timing study data collection in a service delivery environment. Such challenges may include, for example, diversity of the data being collected and diversity of the assets. For example, assets may be in different groups, have different attributes, such as, for example, skill levels, functionality, performance capabilities, and may be in different geographic locations. In addition, the type of work may vary based on the problems and service requests which require the attention of the assets. For example, assets may need to address downed servers, installation of new equipment and applications, administrative requests, such as forgotten usernames and passwords, alerts, such as maximum or close to maximum utilization of memory or a CPU, and non-ticket work, such as meetings, education, training, asset servicing and repair, etc.

It is noted that the embodiments of the present invention are not necessarily limited to the service delivery environment, and may be applied to any environment where timing study may be needed, such as, for example, any environment where work orders or claims might be processed.

Referring toFIG. 1, which is a high-level diagram of a system for ensuring timing study quality in a service delivery environment, according to an embodiment of the present invention, the system100includes a service delivery group module101, a workload module110, a work schedule module120, a participation module130, a volume module140, an effort data module150, a records module160, a timing study guideline module170and a data combination module180. According to an embodiment, the service delivery group module101interacts with workload and work schedule modules110and120to process workload and work schedule data in connection with each asset103and correspond the appropriate workload and work schedule data to the respective assets103in the service delivery group. According to an embodiment, the work schedule data includes, for example, the shifts and locations of an asset, and the work schedule data for each asset103of a service delivery group is output from the work schedule module120to a participation module130.

According to an embodiment, the workload data can be divided into ticket workload115and non-ticket workload117. The ticket workload115comprises ticket work mentioned above, such as, for example, addressing downed servers, installing new equipment and applications, responding to administrative requests and alerts, etc. The non-ticket workload117comprises non-ticket work mentioned above, such as meetings, education, training, asset servicing and repair, etc. The ticket and non-ticket workloads115,117can be defined in terms of the number of items of ticket work and non-ticket work per time period, such as, for example, the number of ticket or non-ticket items per week. The workload module110together with the service delivery group module101, processes the workload data115,117in connection each asset103to correspond the appropriate workload data to the respective assets103in the service delivery group. The ticket workload data115for each asset103of a service delivery group is output from the workload module110to a volume module140.

Alternatively, according to an embodiment, the service delivery group module101can supply the workload and work schedule modules110and120with data indicating which assets103are in a service delivery group, and the workload and work schedule modules can respectively process the workload data115and117, and work schedule data in connection each asset103to correspond the appropriate workload and work schedule data to the respective assets103in the service delivery group. In another embodiment, workload and work schedule data input to the workload and work schedule modules110and120can be previously corresponded to the respective assets103prior to input to the workload and work schedule modules110and120.

Effort data for each asset103in a service delivery group is collected and input to an effort data module150. Referring toFIG. 2, which is a screen shot200showing effort data collected in accordance with an embodiment of the present invention, effort data is data recorded by or for each asset for analysis in a timing study, and reflects services performed by a particular asset. The effort data includes, but is not necessarily limited to, an identification of the asset (e.g., username, equipment name), the activity type (e g., implementing a change, solving a problem, etc.), the activity performed (e.g., analysis, conference, break), complexity, severity, start and completion times, duration of performance, number of sessions, asset pool to which asset is assigned, account worked on, and comments. According to an embodiment, the effort data can be supplied to the effort data module150from the service delivery group module101or independent of the service delivery group module101. According to an embodiment, the effort data supplied to effort data module150can be categorized to reflect the data layout inFIG. 2, or some other data layout. Alternatively, the effort data module150, alone, or in combination with the service delivery group module101can process effort data into predetermined categories. The processed effort data is then supplied from the effort data module150to the participation module130, the volume module140and the records module160.

According to embodiments of the present invention, the participation, volume and records modules130,140and160analyze relevant portions of the effort data, e.g., performance indicators of participation, volume and records, to determine whether the effort data is being properly collected and will result in accurate timing study results. These performance indicators quantify effort data quality, and data quality problems can be identified by analyzing these performance indicators. The results of the identification can guide service delivery entities when fixing the data quality problems, and allow for certification that sufficient quality data has been collected.

The participation module130processes the effort data from the effort data module150to determine a participation rate, which is the number of assets participating (i.e., providing effort data) divided by the total number of assets in the service delivery group. The participation module also takes into consideration the work schedule data from the work schedule module120to discount those assets who did not provide effort data due to, for example, sickness, malfunction, vacation, scheduled maintenance, training, etc. According to an embodiment, if participation is less than 100% of the assets, then the participation module130queries whether any assets can be discounted. According to an embodiment, assets that are remote from the data collection site are not discounted.

According to an embodiment, if the participation rate is less than 100%, the participation module130identifies those assets which do not provide effort data. Then, an investigation(s) is performed to determine if there is a data quality issue. If there is a data quality issue, action is taken to bring the participation rate to 100 percent. In other words, the effort data is gathered from the assets which did not provide effort data, but were required to provide effort data under the circumstances.

The participation module130also processes the effort data to determine a number of task records for each asset over a period of time, for example, the number of records per day, and the number of hours worked by each asset over a period of time, for example, the number of hours worked per day. According to an embodiment, more than one record can be created for a particular ticket item, each record comprising a task that is performed to complete the ticket item. In this case, a ticket item can refer to, for example, a work order and/or a service request. As an example, two records of 1 hour each may be created where a 15 minute break was taken in between each hour. Further, a record can be created for each task that is performed to complete the ticket item.

According to embodiment, if the number of records and/or hours is less than a predetermined value or greater than another predetermined value, a potential problem with the effort data is identified. For example, according to an embodiment, in the case of a service agent, the participation module130may identify a potential problem if the number of records per day is less than 2, or greater than 20. In the case of the records per day being less than 2, there can be a question of adequate participation in the data collection, and in the case of the records per day being greater than 20, there can be a question of whether the data collection is being effectively performed. In addition, according to an embodiment, in the case of a service agent, the participation module130may identify a potential problem if the number of hours worked per day is less than 2, or greater than 12. In the case of the hours per day being less than 2, there can be a question of adequate participation in the data collection, and in the case of the hours per day being greater than 12, there can be a question of whether the data collection is accurate.

Referring toFIG. 3, according to an embodiment, the results of these participation queries are then tabulated by the participation module into a participation quality check template. In the case of template300, effort hours per day are tabulated for each asset. Other templates may be generated, for example, templates showing records per day for each asset, or a group of assets, and/or specifying different time periods or ranges.

In connection with the ticket workload, the volume module140compares the effort data volume from the effort data module160with the ticket workload data115from the workload module110to determine if the actual workload volume (e.g., 100 tickets) is equal to the effort data volume (e.g., effort data recorded on 100 tickets). If the workload volume is not equal to the effort data volume, and the effort data volume<workload volume, a query is performed to check if all of the tickets are being captured by the data collection and/or if one record is being generated for multiple tickets (e.g., batching similar tickets). Conversely, if the effort data volume>workload volume, a query is performed to check if one ticket is being captured as one timing entry, (e.g., are multiple entries mistakenly being generated for the same ticket?).

Referring toFIG. 4, according to an embodiment, the results of these volume queries are then tabulated by the volume module into a volume quality check template400, which reports for a pool of assets whether effort data volume is not consistent with workload volume. For example, referring to the bottom row and the 7thand 12thcolumns, the effort data volume is 7.4 and the workload volume is 9.0, showing an inconsistency. Other templates may be generated, for example, templates showing data for each individual asset, and/or specifying different time periods or ranges.

The records module160analyzes the effort data for the indicated duration for each record in connection with timing study guidelines170received from a timing study guideline module170. The timing study guideline module170includes data on a service delivery entity's guidelines for record keeping. If the record data is not in line with the timing study guidelines, the records module160indicates a potential problem with record keeping. For example, according to an embodiment, if a record duration is less than a particular time (e.g., less than one minute), or greater than a particular time (e.g., greater than 8 hours) a potential problem may be raised that record keeping is not being properly performed. For example, if tasks are broken up into overly minute or overly large elements, collection of data, and resulting analysis may not be accurate. For example, in the case of an overly large duration block, it may not be a realistic scenario where an asset works without breaks over a time period of a particular length. According to an embodiment, the records module160can compare the duration indicated in the records with average duration standards in a timing study guideline.

Referring toFIG. 5, according to an embodiment, the results of these volume queries are then tabulated by the records module160into a records quality check template. In the case of template500, instances where indicated durations of a record are greater than 8 hours are tabulated for each asset. Other templates may be generated, for example, templates showing instance where duration is less than a given value for each asset, or a group of assets and/or specifying different time periods or ranges.

Referring toFIG. 6, an overall quality check template600can be generated by combining data from each of the participation, volume and records modules130,140and160, wherein, as can be seen by the differently shaded areas, the template indicates which areas are not problematic, potentially problematic and problematic. The overall quality check template can be generated by a data combination module180. The overall quality template600is broken up according to groups (pools) of assets, and includes data on the total number of service agents, available service agents, participating service agents, participation rate, total records, total hours, hours per day per agent, and hours per day per total agents in a pool.

Each of the quality templates300,400,500and600can be provided to a local team member who can review and analyze the results to determine any issues with the data. Referring toFIG. 7, a quality check workflow diagram illustrates assets, such as service agents, entering timing records (block701), which are input to an effort database702, which can be located in the effort data module150. A local team member creates one or more quality check templates (block703) to reflect data input into the effort database702, for example, the quality check templates300,400,500and600in unfilled format, and the system100processes the data as described above to generate one or more of the templates300,400,500and600in a filled-in format based on the inputted data (block704). The local team member reviews and analyzes the generated quality templates to determine quality of the data (block705), and diagnoses and fixes any quality issues (block706). Fixing quality issues may require reentering timing records as shown by the arrow from block706to block701. The local team member reports quality status (block707), and a model analyst reviews the local team member's findings to confirm the quality status reported by the local team member (block708). According to an embodiment, a model analyst can run a service delivery environment simulation model based on the effort data to analyze the service delivery environment and the assets thereof.

Referring toFIG. 8, which is a flow diagram illustrating a method for ensuring timing study quality in a service delivery environment, according to an embodiment of the present invention, the effort data of the assets is collected at block801. At block803, the effort data volume is compared with the workload data volume as described above. At block805, if the effort data volume is less than the workload volume, it is checked if all of the tickets are being captured by the data collection at block807, and if the effort data volume is not less than the workload volume, and is greater than the workload volume at block809, it is checked if one ticket is being captured as one timing entry at block811. Then, any resulting data quality issues are reported at block860.

At block821, a participation status is checked, and if participation status is less than 100% at block823, a check is performed at block825to determine whether any assets can be discounted. After performing the check at block825, or if participation is not less than 100% at block823, the method proceeds to block827, where a query is performed to determine whether the number of records per day is less than 2, or greater than 20. Depending on the asset or system constraints, the numbers in block827are not limited to 2 and 20, and may be varied to fit the particular situation. If the answer is yes at block827, it is checked at block829whether there is adequate participation in the data collection or whether the data collection is being effectively performed. After performing the check at block829, or if the answer is no at block827, the method proceeds to block831, where it is queried whether the number of hours per day is less than 2, or greater than 12. Depending on the asset or system constraints, the numbers in block831are not limited to 2 and 12, and may be varied to fit the particular situation. If the answer is yes at block831, then the method proceeds to block833where it is checked whether there is adequate participation in the data collection or whether the data collection is accurate. After performing this check at block833, or if the answer is no at block831, any resulting data quality issues are reported at block860.

At block841, the durations indicated in the records are checked. At block843, if there are records indicating less than one minute, then it is checked at block845whether the records are not actual records, but sample or test records. Depending on the asset or system constraints, the number in block843is not limited to one minute, and may be varied to fit the particular situation. After performing the check at block845, or the answer is no at block843, a query is performed at block847to check whether there are records indicating greater than 8 hours. If the answer is yes at block847, it is checked at block849whether duration without breaks is being recorded instead of actual time spent doing work. Depending on the asset or system constraints, the number in block847is not limited to 8 hours, and may be varied to fit the particular situation. After performing the check at block849, or if the answer is no at block847, any resulting data quality issues are reported at block860.

As shown inFIG. 9, computer system/server912in computing node910is shown in the form of a general-purpose computing device. The components of computer system/server912may include, but are not limited to, one or more processors or processing units916, a system memory928, and a bus918that couples various system components including system memory928to processor916.

The computer system/server912typically includes a variety of computer system readable media. Such media may be any available media that is accessible by computer system/server912, and it includes both volatile and non-volatile media, removable and non-removable media.

The system memory928can include computer system readable media in the form of volatile memory, such as random access memory (RAM)930and/or cache memory932. The computer system/server912may further include other removable/non-removable, volatile/nonvolatile computer system storage media. By way of example only, storage system934can be provided for reading from and writing to a non-removable, non-volatile magnetic media (not shown and typically called a “hard drive”). Although not shown, a magnetic disk drive for reading from and writing to a removable, non-volatile magnetic disk (e.g., a “floppy disk”), and an optical disk drive for reading from or writing to a removable, non-volatile optical disk such as a CD-ROM, DVD-ROM or other optical media can be provided. In such instances, each can be connected to the bus918by one or more data media interfaces. As depicted and described herein, the memory928may include at least one program product having a set (e.g., at least one) of program modules that are configured to carry out the functions of embodiments of the invention. A program/utility940, having a set (at least one) of program modules942, may be stored in memory928by way of example, and not limitation, as well as an operating system, one or more application programs, other program modules, and program data. Each of the operating system, one or more application programs, other program modules, and program data or some combination thereof, may include an implementation of a networking environment. Program modules942generally carry out the functions and/or methodologies of embodiments of the invention as described herein.

Computer system/server912may also communicate with one or more external devices914such as a keyboard, a pointing device, a display924, etc., one or more devices that enable a user to interact with computer system/server912, and/or any devices (e.g., network card, modem, etc.) that enable computer system/server912to communicate with one or more other computing devices. Such communication can occur via Input/Output (I/O) interfaces922. Still yet, computer system/server912can communicate with one or more networks such as a local area network (LAN), a general wide area network (WAN), and/or a public network (e.g., the Internet) via network adapter920. As depicted, network adapter920communicates with the other components of computer system/server912via bus918. It should be understood that although not shown, other hardware and/or software components could be used in conjunction with computer system/server912. Examples, include, but are not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data archival storage systems, etc.