Abstract: Systems and computer-implemented methods for ticket analysis in an Information Technology Infrastructure Support (ITIS) environment are described. In one embodiment, a method comprises obtaining ticket data pertaining to a plurality of tickets, where each ticket is associated with a plurality of ticket attributes, and creating homogenous sets for the plurality of tickets based on the plurality of ticket attributes. Each homogenous set includes a plurality of ticket subsets having homogenous ticket attributes. Each of such homogeneous sets is classified into a plurality of categories based on classification parameters including volume of the tickets, and time taken to resolve the tickets. The ticket subsets corresponding to at least one of the categories are analyzed to identify one or more patterns based on predefined characteristics including at least one of high service time characteristics, a low service time characteristics, increasing arrival trend characteristics, decreasing arrival trend characteristics, and correlated characteristics.
FORM 2
THE PATENTS ACT, 1970 (39 of 1970)
&
THE PATENTS RULES, 2003
COMPLETE SPECIFICATION (See section 10, rule 13)
1. Title of the invention: AUTOMATED TICKET ANALYSIS
2. Applicant(s)
NAME NATIONALITY ADDRESS
TATA CONSULTANCY Indian Nirmal Building, 9th Floor, Nariman Point,
SERVICES LIMITED Mumbai, Maharashtra 400021
India
3. Preamble to the description
COMPLETE SPECIFICATION
The following specification particularly describes the invention and the manner in which it
is to be performed.
TECHNICAL FIELD
[0001] The present subject matter, in general, relates to ticket analysis in service
industry, and in particular, to systems and methods of automated ticket analysis in an Information Technology Infrastructure Support (ITIS) environment.
BACKGROUND
[0002] In service industry, a service provider provides wide range of services to its
customers. For example, an ITIS provider may provide service, such as effective deployment, configuration, usage, management, and maintenance of IT infrastructure resources, such as hardware (computer, router, scanner, printers), system software (operating systems, databases, browsers, email programs), and business application programs. The customers at any time may face some problems or issues with the product and/or services provided to them. For providing efficient and continuous service to the customers, the service provider resolves such problems. Therefore, technical support and customer support plays a vital role in the service industry and have a direct impact on the quality of service provided to the customer.
[0003] Typically, whenever customers experience any problem with the products
and/or service provided to them. For example, in the ITIS environment, the customer may face problems like server failure or wants to leverage the infrastructure, such as account creation and installation, the customer may register his request or issues to the respective service provider. Registering of issues can be done through various channels like by calling customer care of the service provider, using online facilities provided by the service provider and via send an email to the service provider. The service provider logs the issue in the form of a ticket. For every issue a ticket is generated by the service provider. The ticket may include multiple attributes that provide information about different aspects of the ticket like date of creation of the ticket, problem associated with the ticket, the customer who raised the ticket. The data corresponding to the tickets, which is hereinafter referred to as ticket data, is typically stored in a centralized repository of a ticketing system, for example, Service Now, and Remedy.
SUMMARY
[0004] This summary is provided to introduce concepts related to automated ticket
analysis and concepts are further described below in the detailed description. This summary is not intended to identify essential features of the claimed subject matter nor is it intended for use in determining or limiting the scope of the claimed subject matter.
[0005] In one embodiment, a method for ticket analysis in an Information Technology
Infrastructure Support (ITIS) environment comprises obtaining ticket data pertaining to a plurality of tickets, where each ticket is associated with a plurality of ticket attributes, and creating homogenous sets for the plurality of tickets based on the plurality of ticket attributes. Each homogenous set includes a plurality of ticket subsets having homogenous ticket attributes. Each of such homogeneous sets is classified into a plurality of categories based on classification parameters including volume of the tickets, and time taken to resolve the tickets. The ticket subsets corresponding to at least one of the categories are analyzed to identify one or more patterns based on predefined characteristics including at least one of high service time characteristics, a low service time characteristics, increasing arrival trend characteristics, decreasing arrival trend characteristics, and correlated characteristics.
BRIEF DESCRIPTION OF THE DRAWINGS
[0006] The detailed description is provided with reference to the accompanying
figures. In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. The same numbers are used throughout the drawings to reference like features and components.
[0007] Fig. 1 illustrates a network environment implementing ticket analysis system,
in accordance with an embodiment of the present subject matter.
[0008] Fig. 2(a) illustrates components of a ticket analysis system, in accordance with
an embodiment of the present subject matter.
[0009] Fig. 2(b) illustrates classification of homogeneous subset into categories, in
accordance with an embodiment of the present subject matter.
[0010] Fig. 2(c)-2(f) illustrates graphical representation of patterns, in accordance
with an embodiment of the present subject matter.
[0011] Fig. 3 illustrates a method for automated ticket analysis in a service industry, in
accordance with an embodiment of the present subject matter.
DETAILED DESCRIPTION
[0012] Ticket analysis for Information Technology Infrastructure Support (ITIS)
service providers may be useful for continual service improvement in an ITIS environment. In a typical ITIS environment, a service provider periodically analyzes historical ticket data corresponding to tickets that are generated to identify opportunities for continual service improvement. The analysis usually involves monitoring past trends of tickets, taking feedbacks from customers, and evaluating the performance based on various predefined key performance indicators (KPI). However, such analysis is performed manually that consumes more time and resources.
[0013] Further, there may be multiple attributes associated with tickets which provide
information about different aspects captured in the ticket, such as problem reported by a customer with respect to products/services. For example, problems may be related to software, desktop, lotus notes, installation, and the like. Also, tickets may have different priorities and severities associated with it depending on the urgency and impact of the reported problem. Other ticket attributes may include information about the date of creation of the tickets, level or tower at which the ticket is resolved. As it is known that there may be multiple resolvers in the ITIS environment resolving the tickets at different levels of hierarchy. In a typical ITIS environment, the resolver teams may be organized as Level 1, Level 2, Level 3, and so on, in an increasing order of expertise, depending on the complexity of the problem, etc. Further, the resolver teams may be further organized as different towers like Service Desk, Mainframe, and Desktop etc., depending on the nature and complexity of the reported problem. Thus, the ticket data reflecting various aspects of the tickets is heterogeneous and multidimensional in nature. The heterogeneity of the data makes the comparison and analysis of the tickets difficult. Further, manual analysis of such heterogeneous and multidimensional ticket data is prone to errors, and is inefficient.
[0014] In accordance with the present subject matter, the systems and computer-
implemented methods of ticket analysis in an ITIS environment are described. The systems and methods involve obtaining ticket data pertaining to a plurality of tickets. The ticket data
may provide information about different attributes of the tickets including creation date of ticket, severity, priority, towers, levels and issues associated with the tickets. As indicated previously, the ticket data is heterogeneous in nature that makes the comparison of the tickets difficult. According to the present subject matter, homogenous sets are created for a plurality of tickets based on the ticket attributes that represent the complexity and service time characteristics of the tickets. Each of the homogenous set includes multiple ticket subsets that represent other ticket attributes, such as attributes representing problems with product and/or services. In one implementation, the homogenous sets may contain description of the ticket subsets in form of attribute-value pairs. The ticket subsets within each homogenous set share similar characteristics, i.e., these subsets have homogenous ticket attributes, and are therefore comparable with one another.
[0015] In one implementation, each of the homogenous sets is classified or divided
into a plurality of categories based on the classification parameters, such as volume of the tickets, and time taken to resolve those tickets. In one implementation, each homogenous set is classified into four categories or quadrants. The first quadrant may include ticket subsets having high service time and high ticket volume, a second quadrant may include the ticket subsets that have low service time and high ticket volume, a third quadrant may include the ticket subsets that have low service time and low ticket volume, and the fourth quadrant may include the ticket subsets that have high service time and low ticket volume. The service time referred herein is the total time taken to resolve the tickets in each ticket subset, and ticket volume refers to the total number of tickets in each ticket subset. In an example, the total ticket volume and total service time may be specified in terms of percentage.
[0016] In one implementation, medians for ticket volume and total service time may
be computed, and such medians may be used for determining whether the total ticket volume is high or low, and total service time is high or low. For example, a median for ticket volume may be computed as 0.18 %, and median for service time may be computed as 1.5 %. In this example, the ticket subsets having total ticket volume lesser than the median 0.18 % may be determined to have low ticket volume, and ticket subsets having total service time higher than 1.5 % may be determined to have high service time. Accordingly, such ticket subsets may be classified into a category of low ticket volume and high service time.
[0017] Subsequent to the classification, categories that are of interest may be selected
for further analysis. In one implementation, categories having high ticket volume are selected for analysis. Referring to the above implementation, the first quadrant and the second quadrant may be selected for further analysis. The analysis may include identify one or more patterns of ticket subsets from the selected categories using various domain driven data mining and statistical techniques. The patterns referred herein may be ticket subsets that are exhibiting various predefined characteristics, for example, high service time characteristics, low service time characteristics, increasing/decreasing arrival trend characteristics, and correlated characteristics. Such patterns, thus, identified provides actionable insights or opportunities for continual service improvement. One example of the patterns include ticket subsets exhibiting significantly high average service time characteristics, i.e., the ticket subsets having higher service time in comparison to the remaining ticket subsets, wherein the significance can be established by a statistical hypothesis test two sample student t-test, known in the art. Such a pattern highlights an area of improvement in terms of efficiency and quality with which the tickets are handled.
[0018] Another example of the patterns includes ticket subsets having significantly
low average service time in comparison to the remaining of the ticket subsets, where the significance is established by the two sample student t-test. Such patterns may be considered for automation, i.e., various automated scripts or programs may be generated for automatically resolving the issues highlighted by such patterns, without the involvement of the service representatives, thereby eliminating the human intervention. This may also help in reducing the volume of tickets. Yet another example of patterns includes ticket subsets having increasing trend in ticket arrival. Such type of patterns may be identified based on performing linear regression on the ticket arrival time series data. Such patterns help in identifying a root cause for increasing trend in ticket arrival. The identified root cause may be resolved immediately in order to minimize the ticket arrival. In a further example, the patterns include a pair of ticket subsets exhibiting correlation with respect to one another in the ticket arrival. Such a correlated pattern may provide an opportunity for either minimizing or eliminating arrival of tickets due to inter-dependency. The above different types of patterns are in general opportunities for continual service improvement.
[0019] In one implementation, the patterns can be ranked based on a ranking
methodology, which is conventionally known as 'borda count' methodology, to determine the patterns that are more relevant and require immediate attention for continual service improvement. In an example, the pattern having the highest rank may be considered for service improvement.
[0020] The manner in which ticket analysis in an ITIS environment is performed shall
be explained in detail with respect to the Figs. 1-3. While aspects of systems and methods can be implemented in any number of different computing systems environments, and/or configurations, the embodiments are described in the context of the following exemplary system architecture(s). Furthermore, the present description has been provided with implementations that are specific to certain business functions or certain businesses. It would be appreciated that other implementations are also covered without deviating from the scope of the present subject matter.
[0021] Fig. 1 illustrates a network environment 100 implementing a ticket analysis
system 102, in accordance with an embodiment of the present subject matter. In one implementation, the network environment 100 can be a public network environment, including thousands of personal computers, laptops, various servers, such as blade servers, and other computing devices. In another implementation, the network environment 100 can be a private network environment with a limited number of personal computers, servers, laptops and other computing devices.
[0022] The ticket analysis system 102 (hereinafter referred to as system 102) is
communicatively connected to a plurality of user devices 104-1, 104-2...104-N, collectively referred to as user devices 104 and individually referred to as a user device 104, through a network 106. In one implementation, a plurality of users may use the user devices 104 to communicate with the system 102.
[0023] The system 102 and the user devices 104 may be implemented as any of a
variety of conventional computing devices including servers, a desktop personal computer, a notebook or portable computer, a workstation, a mainframe computer, and a laptop. Further, in one implementation, the system 102 may itself be a distributed or centralized network system in which different computing devices may host one or more of the hardware or
software components of the system 102. In another implementation, the various components of the system 102 may be implemented as a part of the same computing device.
[0024] The system 102 may be connected to the user devices 104 over the network
106 through one or more communication links. The communication links between the system 102 and the user devices 104 are enabled through a desired form of communication, for example, via dial-up modem connections, cable links, digital subscriber lines (DSL), wireless or satellite links, or any other suitable form of communication.
[0025] The network 106 may be a wireless network, a wired network, or a
combination thereof. The network 106 can also be an individual network or a collection of many such individual networks, interconnected with each other and functioning as a single large network, e.g., the Internet or an intranet. The network 106 can be implemented as one of the different types of networks, such as intranet, local area network (LAN), wide area network (WAN), the internet, and such. The network 106 may either be a dedicated network or a shared network, which represents an association of the different types of networks that use a variety of protocols, for example, Hypertext Transfer Protocol (HTTP), Transmission Control Protocol/Internet Protocol (TCP/IP), etc., to communicate with each other. Further, the network 106 may include network devices, such as network switches, hubs, routers, for providing a link between the system 102 and the user devices 104. The network devices within the network 106 may interact with the system 102, the user devices 104, and a repository 108 through the communication links.
[0026] In one embodiment, the system 102 is further connected to the repository 108
through the network 106. The repository 108 may be a central repository containing a ticket data 110 pertaining to all the tickets generated in the past. Although, the repository 108 depicted in the figure is an external repository implemented outside the system 102, it is to be understood that the repository 108 may also be implemented as an internal repository within the system 102 for storing the ticket data 110.
[0027] As indicated previously, the ticket data 110 in its original form is
heterogeneous data, thus, it is difficult to compare one ticket with another. The system 102, according to an embodiment of the present subject matter, receives ticket data 110 from the repository 108, creates homogenous sets for a plurality of ticket subsets based on various
ticket attributes. Each of the homogenous sets includes multiple ticket subsets having similar characteristics, for example, similar characteristics with respect to complexity of the tickets and service time. The ticket subsets within each homogenous set are therefore comparable with one another, thereby making the analysis simpler. Such ticket subsets within each homogenous set may represent various other ticket attributes, such as attributes representing problem with product and/or service. In one implementation, the process of homogeneous set creation involves storing description of the ticket subsets in form of attribute-value pairs, where ticket attributes and their corresponding values are stored. For example, Severity = ‘High’ and Tower =’Service Desk’ and Resolver-Level = ‘L1’ where Severity, Tower and Resolver Level are attributes and High, Service Desk, L1 are the corresponding values.
[0028] In one implementation, the homogeneous sets are analyzed for continual
service improvement to identify opportunities for reducing the ticket volume, efficiently resolving the tickets or both.. To perform the analysis, the system 102 classifies each of the homogeneous set into a plurality of categories based on various classification parameters, such as volume of the tickets, and time taken to resolve those tickets (interchangeably referred to as service time). Based on the classification, the system 102 selects the categories of interest for analysis. In one implementation, the categories having high ticket volume are selected for further analysis.
[0029] The system 102 according to an embodiment of the present subject includes an
analysis module 112 that is configured to perform the analysis on the selected categories. The analysis module 112, for example, identifies the one or more patterns in the selected categories. The pattern as indicated previously refers to ticket subsets in the homogeneous set that exhibit predefined behavior or characteristics with respect to service time or ticket arrival. The predefined characteristics may include, but not restricted to, low service time characteristics, high service time characteristics, increasing\decreasing arrival characteristics, and correlated characteristics.
[0030] In one implementation, the ticket subsets exhibiting low service time
characteristics, i.e., the ticket subsets taking significantly less average service time in comparison to the rest of ticket subsets, wherein the significance is established by the statistical hypothesis test two sample students t-test may be one pattern. The ticket subsets
having significantly high average service time in comparison to the rest of ticket subsets, wherein the significance is established by the two sample students t-test may be another pattern. Further, the ticket subsets exhibiting either an increasing or decreasing trend in ticket arrival, wherein such trend is established by applying a linear regression may be yet another pattern. Furthermore, the ticket subsets having inter-dependent tickets or correlated tickets may be identified as yet another pattern, wherein the correlation is established by performing cross correlation analysis. In one implementation, the analysis module 112 identifies the patterns as described above after analyzing the selected categories. The identified patterns may represent the ticket subsets at different levels of abstraction, thus, indicating the level at which the improvement in ticket resolving is required. In other words, it helps in continual service improvement.
[0031] According to an implementation, the analysis module 112 generates an
analysis report containing the identified patterns that highlights various opportunities for continual service improvement. For example, the pattern in which ticket subsets exhibits low service time characteristics may be considered as possible candidates for automation. For example, various automation scripts can be generated to automatically resolve the tickets within such ticket subsets. Further, the pattern in which ticket subsets exhibits increase in ticket arrival may help in identifying areas requiring immediate attention to bring in drastic reduction of ticket volume and also facilitate for proactive planning of the team to handle tickets corresponding to these patterns. The patterns corresponding to pattern type “decreasing arrival” also facilitate proactive planning and they also indicate that the stability in ticket arrival trend with respect to these patterns have to be maintained. Furthermore, the patterns corresponding to the pattern type 'high service time’ acts as opportunity for improvement in terms of efficiency and quality with which the tickets of that pattern are handled.
[0032] In one implementation, the analysis module 112 may be configured to rank the
identified patterns based on borda count ranking methodology. Based on ranking, the patterns having high ranking may be identified as a focus points for continual service improvement. For example, when the patterns generated are large in number, and it is difficult to analyze as to which patterns are more useful for service improvement, the analysis module 112 may be configured to rank the patterns and generate an analysis report including each of the patterns
along with their corresponding ranking. Thus, according to the present subject matter, the ticket analysis is made simpler, efficient and reliable.
[0033] Fig. 2(a) illustrates details of the system 102, according to an embodiment of
the present subject matter.
[0034] In said embodiment, the system 102 includes one or more processor(s) 202, a
memory 206 coupled to the processor(s) 202, and interface(s) 204. The processor(s) 202 may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, and/or any devices that manipulate signals based on operational instructions. Among other capabilities, the processor(s) 202 are configured to fetch and execute computer-readable instructions and data stored in the memory 206.
[0035] The interface(s) 204 may include a variety of software and hardware
interfaces, for example, interface for peripheral device(s), such as a keyboard, a mouse, an external memory, a printer, etc. Further, the interface(s) 204 may enable the system 102 to communicate over the network 106, and may include one or more ports for connecting the system 102 with other computing devices, such as web servers and external databases. The interface(s) 204 may facilitate multiple communications within a wide variety of protocols and networks, such as a network, including wired networks, e.g., LAN, cable, etc., and wireless networks, e.g., WLAN, cellular, satellite, etc.
[0036] The memory 206 may include any computer-readable medium known in the art
including, for example, volatile memory, such as static random access memory (SRAM) and dynamic random access memory (DRAM), and/or non-volatile memory, such as read only memory (ROM), erasable programmable ROM, flash memories, hard disks, optical disks, and magnetic tapes. The memory 206 also includes modules 208 and data 210.
[0037] The modules 208 include routines, programs, objects, components, data
structures, etc., which perform particular tasks or implement particular abstract data types. The modules 208 further include a ticket module 212, the analysis module 112, and other module(s) 214. The other module(s) 214 may include programs or coded instructions that supplement applications and functions on the system 102, for example, programs in the operating system.
[0038] The data 210, amongst other things, serves as a repository for storing data
processed, received, and generated by one or more of the modules 208. The data 210 includes the ticket data 110, homogeneous set(s) 216, analysis data 218, and other data 220. The other data 220 may include data generated as a result of the execution of one or more modules in the other module(s) 214.
[0039] In operation, the ticket module 212 of the system 102 obtains the ticket data
110. The ticket data 110 may include historical operational data, plurality of attributes of tickets, and data providing information about tickets. The ticket attributes may include type of ticket, level at which the ticket is resolved, tower, severity and priority associated with the ticket. The tower refers to a logical grouping of tickets based on the domain to which the tickets are addressed. For example, security tower represent tickets concerned with security aspects, such as authentication, sharing, and permission. Severity and priority associated with the tickets may indicate the impact and urgency of the tickets.
[0040] As indicated previously, the ticket data 110 is multidimensional and
heterogeneous in nature, and thus poses a challenge for a fair comparison amongst the tickets. According to an implementation of the present subject matter, upon obtaining the ticket data 110, the ticket module 212 creates homogenous sets for a plurality of ticket subsets based on the ticket attributes, for example, attributes that represent the complexity of the ticket and service time characteristics. Each of the homogenous sets 216 includes multiple ticket subsets having similar characteristics, and is therefore comparable with one another.
[0041] In one implementation, the ticket module 212 stores the homogeneous set(s)
216 within the system 102. The homogenous set(s) 216 stored herein may include description of the ticket subsets contained therein. As indicated previously, the description may be in form of attribute-value pairs. Subsequent to the creation of the homogenous sets 216, the ticket module 212 classifies the homogeneous subsets 216 into a plurality of categories based on classification parameters. The classification parameters referred herein may include ticket volume and service time. The service time as referred herein is the time taken in resolving the tickets at the service provider’s end and the ticket volume gives the measure of tickets corresponding to same problem type. Considering an example, where a plurality of users has
reported issues associated with a router. In said example, the number of tickets reporting the problem related to router will provide the ticket volume.
[0042] In one implementation, the ticket module 212 classifies the ticket subsets in
each of the homogeneous sets 216 into quadrants. A first quadrant may contain the ticket subsets having high volume and high service time, a second quadrant may contain ticket subsets having low volume and high service time, a third quadrant time may contain ticket subsets having low volume and low service time, and a fourth quadrant may contain ticket subsets having high volume and low service time. In one implementation, medians for ticket volume and total service time may be computed, and such medians may be used for determining whether the total ticket volume is high or low, and total service time is high or low. Accordingly, the ticket subsets may be classified into appropriate categories.
[0043] Fig. 2(b) illustrates classification of a homogeneous set into categories, in
accordance with an embodiment of the present subject matter. In said embodiment, the categories are quadrants, median for service time is 0.09% and median for volume of tickets is 0.18%. The homogenous set 216 is classified into four quadrants. The ticket subsets having service time greater than the median of 0.09% are determined as ticket subsets taking high time to resolve and vice versa. Similarly, the ticket subsets having ticket volume greater than the median of 0.18% are determined as ticket subsets having high ticket volume. As shown in the figure, a first quadrant includes ticket subsets 216-1 having high service time and high ticket volume, such as Hotmail-Satchmo, hotmail-FE, and OSSG. The second quadrant includes ticket subsets 216-2 having low service time and high ticket volume, such as GFS Advantage One, Windows-Watson, and BEET US. The third quadrant includes ticket subsets 216-3 having low service time and low ticket volume, such as Japan contextual Search Shared, WMIS-AST, and WPS MyPhone. The fourth quadrant include ticket subsets 216-4 having high service time and low ticket volume, such as GNS Tools, WLX Account, and WLX Shared Resource System.
[0044] Subsequent to the classification, categories of interest are selected for further
analysis. In one implementation, the categories having high ticket volume are selected for further analysis. The analysis module 112 then identifies one or more patterns from the selected categories. The patterns may be understood as ticket subsets that are exhibiting
predefined characteristics. Such predefined characteristics may include high service time characteristics, low service time characteristics, increasing arrival trend characteristics, and correlated characteristics.
[0045] In one implementation, the ticket subsets having significantly high average
service time as compared to rest of the tickets subsets in a homogenous set 216 may be identified as a pattern, wherein the significance is established by using two sample student t-test. Such a pattern of ticket subsets having high service time may also be called as expensive subset of tickets. One immediate improvement that can be indicated by this pattern may be providing training to people who can solve the tickets of this type. For example, trainees and trainers can be identified for each such pattern. A trainee may be a resolver who takes significantly high average service time for the resolving the tickets as compared to others, and a trainer may be a resolver who takes significantly low average service time to resolve the tickets as compared to others, wherein the significance is established using two sample student t-test.. Thus, such a pattern may additionally include the recommendation of training the trainee(s) to improve the efficiency with which the tickets of the pattern are resolved. Table 1 provided below illustrates an example of high service time patterns.
Table 1
Patterns No. of Tickets Avg. ST (min.) Stdev ST (min.) No. of
Tickets
Others Avg .ST
Others
(min.) Stdev. ST
Others
(min.)
Software-LotusNotes 72 78.67 24.49 178 19.36 13.49
Hardware-Mouse 65 63.74 65.03 185 29.43 11.81
Audio video conferencing 50 102.00 3631.42 18.00 17.44 13.89
[0046] As shown in table 1, Software-LotusNotes tickets take high time to resolve, as
the average service time (Avg. ST), which is also referred to as service time in the specification, of Software-LotusNotes tickets is significantly higher than the average service time of other tickets (Avg. ST Others). Similarly, Hardware-Mouse tickets and Audio video conferencing tickets have high significantly average service time.
[0047] In another implementation, the ticket subsets having significantly low average
service time as compared to rest of the tickets subsets in a homogenous set 216 may be identified as a pattern wherein the significance is established by using two sample student t-test.. Such type of a pattern may be indicative of the ticket subsets that are stable in terms of time to resolve and are easier to resolve. The tickets corresponding to these types of patterns may be handled by an automated program or script thus eliminating the human intervention and thereby reducing the tickets volume. Table 2 provided below illustrates an example of low service time patterns.
Table 2
Pattern Number of Avg. ST Stdev Number of Avg .ST Tickets (min.) ST(min.) Tickets Others
Others (min.) Stdev. ST
Others
(min.)
Password reset 40 8.67 24.49 110 99.36 13.49
Software-Installation-LotusNotes 55 13.74 65.03 95 89.43 61.81
[0048] As shown in the table 2, the password reset tickets have an average service
time of 8.67 minutes, which is significantly lower than the 99.36 minutes, which is average service time of other tickets. Similarly, Software-Installation-LotusNotes tickets have average service time significantly less than average service time of other tickets.
[0049] In another implementation, the ticket subsets exhibiting an increasing trend in
ticket arrival may be identified as a pattern. Such a type of pattern helps in identifying the areas that require immediate attention to bring in drastic reduction of ticket volume and also facilitate for proactive planning of the team to handle tickets corresponding to these patterns.
[0050] Fig. 2(c)-2(f) illustrates graphical representation of patterns, in accordance
with an embodiment of the present subject matter, particularly, the fig. 2(c) and 2(d) illustrate graphs depicting an increasing trend in ticket arrival. Fig. 2(c) shows a curve 222 representing an increasing trend in number of ticket arriving pertaining to Hotmail_Satchmo, hsr_SQLcheck_alerts_SMDB_DB_server over a period of days. There is an increase in the number ticket arrival with each passing day. Similarly, figure 2(d) illustrates curves 224, 226 showing an insignificant and a significant or increasing trend in ticket arrival. The curves 224,
226 are for tickets pertaining to Hotmail_Satchmo,
event_1264_1265_DBCC_CHECKBD_Failed. For initial 10 days, the curve 224 exhibits an insignificant change in number of ticket arriving and after 10 days, exhibits a significant trend in the curve 226 representing number of ticket arriving.
[0051] In another implementation, the ticket subsets exhibiting correlation or inter-
dependencies may be identified as a pattern. Such a correlated pattern is indicative of two ticket subsets whose ticket arrival time series have significantly high correlation wherein the significance is established by examining a cross correlation coefficient of the two time series corresponding to the two ticket subsets. Such a pair of ticket subsets may point out the dependencies among different ticket types. The dependencies can be either minimized or eliminated, thereby reducing the tickets arriving due to the dependencies. For example, it might come out as a pattern that lotus notes installation tickets are correlated with account creation which means that higher the lotus notes tickets, higher is the account creation tickets and vice versa. In said example, the fact that the user who raises account creation request also raises a request for lotus notes installation is reflected. Proactively installing the required software’s for the new user can eliminate the tickets for lotus notes installation.
[0052] Fig. 2(e) and 2(f) illustrate graphs depicting a correlated pattern in the ticket
arrival. Figure 2(e) shows two curves displaying time series over a period of days. A curve 228 represents arrival of tickets over a period of days for tickets pertaining to Hotmail-FE, HTTPHMFE-vip net check and curve 230 represents arrival of tickets over a period of days for tickets pertaining to StorageMonitorPhysicalDisk_Failed. The correlation coefficient between the both curves is 0.78 and there is a lag of zero days, i.e., both the curves will show a similar behavior on a given day. Similarly, figure 2(f) shows two curves showing time series over a period of days. A curve 232 represents arrival of tickets over a period of days for tickets pertaining to Hotmail-FE, Event_105-CosmosDataLoader.exe and curve 234 represents arrival of tickets over a period of days for tickets pertaining to Execute_permission_for_SP. The correlation coefficient between the both curves is 0.67 and there is a lag of eight days, i.e., if there is some change in the curve 232, the curve 234 will show a similar trend in ticket arrival after 8 days.
[0053] Once the patterns are identified, in one implementation, the analysis module
112 may associate a rank to the patterns according to a conventionally known 'borda rank' methodology. The analysis module 112 may perform the ranking based on a plurality of parameters for each pattern, such as number of tickets in the pattern average service time of the tickets in the pattern, and standard deviation in service time for the tickets in the pattern. In one implementation, the analysis module 112 module assigns a weightage to each of the above mentioned parameters for each pattern. The cumulative weightage is assigned to each pattern by the analysis module 112. Such cumulative weightage is hereinafter referred to as rank of the pattern. In one implementation, the table 3 provided below illustrates the ranking of the patterns.
Table 3
Pattern Number of Tickets Average Service Time Standard deviation in Service Time Borda Rank
Audio and Video Conferencing 5 1 1 7
Thane Corporate Data Center -Windows 6 7 4 17
Thane Corporate Data Center-Security 10 9 9 28
Hardware 3 6 6 15
Tivoli 8 10 10 28
Global Messaging Support (Lotus Notes) 1 5 8 14
Software 2 3 5 10
Collaboration 4 2 3 9
VoIP 7 4 7 18
Mainframe 9 8 2 19
[0054] As shown in the table 3, for pattern 'Audio and video conferencing', the
weightage 5 is assigned to the parameter 'number of tickets', weightage 1 is assigned to the parameter average service time, and weightage 1 may be assigned to the standard deviation in service time. The cumulative weightage of these parameters, which is 7 is referred as the rank of the pattern 'Audio and video conferencing'. Likewise, ranking is performed for the patterns as depicted in the table 1. Based on the ranking, the top k patterns may be considered for efficiently resolving and reducing the ticket volume, where k is defined by the user. Such
patterns provide opportunities for continual service improvement. The analysis module 112 then generates an analysis report containing top k patterns according to the ranking.
[0055] Fig. 3 illustrates a method 300 of automated ticket analysis in a service
industry, in accordance with an embodiment of the present subject matter. The method may be described in the general context of computer executable instructions. Generally, computer executable instructions can include routines, programs, objects, components, data structures, procedures, modules, functions, etc., that perform particular functions or implement particular abstract data types. The method may also be practiced in a distributed computing environment where functions are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, computer executable instructions may be located in both local and remote computer storage media, including memory storage devices.
[0056] The order in which the method is described is not intended to be construed as a
limitation, and any number of the described method blocks can be combined in any order to implement the method, or an alternative method. Additionally, individual blocks may be deleted from the method without departing from the spirit and scope of the subject matter described herein. Furthermore, the method can be implemented in any suitable hardware, software, firmware, or combination thereof.
[0057] At block 302, ticket data corresponding to a plurality of tickets each having a
plurality of ticket attributes is obtained. The ticket attributes provide information about tickets from different aspects, such as date of creation of the ticket, severity, priority, towers, levels and issues associated with the tickets. In one implementation, the ticket module 212 obtains the ticket data 110 pertaining to the plurality of tickets from the repository 108.
[0058] At block 304, homogenous set are created for the plurality of tickets based on
the plurality of ticket attributes. Each homogenous set includes a plurality of ticket subsets. For example, description of the ticket subsets may be stored in form of attribute-value pairs in the homogenous sets. The ticket subsets within each of the homogenous sets are comparable with one another. Taking an example of an ITIS industry, the homogeneous ticket set(s) 216 may be created based on specific ticket attributes, such as attributes that determine the
complexity of the ticket and service time characteristics. Example of such attributes includes, but not restricted to, severity, tower, type, and resolver level.
[0059] At block 306, each of the homogeneous set is classified into a plurality of
categories based on various classification parameters. The classification parameters may include service time, i.e., time taken to resolve the tickets, and the volume of the tickets. In one implementation, the ticket module 212 classifies a plurality of homogeneous set(s) 216 into four categories based on the classification parameters 'service time' and 'volume of the tickets'. In said implementation, the categories include a high volume and high service time category, a low volume and low service time category, a high volume and low service time category, and a low volume and high service time category.
[0060] At block 308, selected categories are analyzed from the plurality of categories
to identify one or more patterns, where the patterns are the ticket subsets having predefined characteristics. Such patterns may provide opportunities for continual service improvement in an ITIS industry. In one implementation, the analysis module 112 analyses the selected categories. For example, the categories having high volume of tickets may be selected for analysis. The analysis module 112 identifies one or more patterns within the selected categories. As mentioned above, the patterns are the ticket subsets exhibiting predefined characteristics. Such predefined characteristics includes ‘high\low service time’ characteristics, ‘increasing ticket arrival’ characteristics, and ‘correlated' characteristics. In one implementation, the analysis module 112 computes ranking for the identified patterns in order to identify those patterns that are most problematic and require immediate attention.
[0061] The systems and methods of the present subject matter thus provides an
efficient way of ticket analysis by systematically exploring the historical heterogeneous multidimensional ticket data. Such ticket analysis also helps in continual service improvement in the ITIS environment. Although embodiments for systems and methods of ticket analysis have been described in language specific to structural features and/or methods, it is to be understood that the invention is not necessarily limited to the specific features or methods described. Rather, the specific features and methods are disclosed as exemplary implementations of ticket analysis in the ITIS industry.
I/we claim:
1. A computer-implemented method for ticket analysis in an Information Technology
Infrastructure Support (ITIS) environment, the method comprising:
obtaining ticket data pertaining to a plurality of tickets, wherein each ticket is associated with a plurality of ticket attributes;
creating a plurality of homogenous sets for the plurality of tickets based on the plurality of ticket attributes, wherein each of the homogenous sets includes a plurality of ticket subsets having homogenous ticket attributes;
classifying each of the homogeneous sets into a plurality of categories based on classification parameters, wherein the classification parameters comprises at least volume of the plurality of tickets, and time taken to resolve the plurality of the tickets; and
analyzing ticket subsets corresponding to at least one of the plurality of categories to identify one or more patterns based on predefined characteristics, wherein the predefined characteristics comprising at least one of high service time characteristics, a low service time characteristics, increasing arrival trend characteristics, decreasing arrival trend characteristics, and correlated characteristics.
2. The method as claimed in claim 1, wherein the plurality of categories comprise a high ticket volume and low service time category, a high ticket volume and high service time category, a low ticket volume and high service time category, and a low ticket volume and low service time category.
3. The method as claimed in claim 1, wherein the analyzing comprises selecting at least one of the plurality categories having high volume of tickets.
4. The method as claimed in claim 1, wherein the analyzing comprises ranking the one or more patterns based on a borda count ranking methodology.
5. A ticket analysis system (102) comprising:
a processor (202); and
a memory (206) coupled to the processor (202), the memory (206) comprising: a ticket module (212) configured to,
obtain ticket data (110), pertaining to a plurality of tickets, wherein each ticket is associated with a plurality of ticket attributes, from a repository (108);
create one or more homogenous sets (216) for the plurality of tickets based on the plurality of ticket attributes, wherein each of the one or more homogenous sets (216) includes a plurality of ticket subsets having homogenous ticket attributes;
classify each of the one or more homogenous sets (216) into a plurality of categories based on classification parameters; and
an analysis module (112) configured to identify one or more patterns from at least one selected categories amongst the plurality of categories.
6. The ticket analysis system (102) as claimed in claim 6, wherein the plurality of categories are quadrants including a first quadrant containing ticket subsets having high volume and low service time, a second quadrant containing ticket subsets having high volume and high service time, a third quadrant containing ticket subsets having low volume and high service time, and a fourth quadrant containing ticket subsets having low volume and low service time.
7. The ticket analysis system (102) as claimed in claim 6, wherein the classification parameters comprises volume of the plurality of tickets, and time taken to resolve the plurality of the tickets.
8. The ticket analysis system (102) as claimed in claim 6, wherein the one or more patterns are identified based on predefined characteristics comprising high service time characteristics, low service time characteristics, increasing arrival trend characteristics, decreasing arrival trend characteristics and correlated characteristics.
9. The ticket analysis system (102) as claimed in claim 6, wherein the analysis module (112) is further configured to generate an analysis report based at least on the identified one or more patterns.
10. A computer-readable medium having embodied thereon a computer program for executing a method comprising:
obtaining ticket data pertaining to a plurality of tickets, wherein each ticket is associated with a plurality of ticket attributes;
creating a plurality of homogenous sets for the plurality of tickets based on the plurality of ticket attributes, wherein each of the homogenous sets includes a plurality of ticket subsets having homogenous ticket attributes;
classifying each of the homogeneous sets into a plurality of categories based on classification parameters, wherein the classification parameters comprises at least volume of the plurality of tickets, and time taken to resolve the plurality of the tickets; and
analyzing ticket subsets corresponding to at least one of the plurality of categories to identify one or more patterns based on predefined characteristics, wherein the predefined characteristics comprising at least one of high service time characteristics, a low service time characteristics, increasing arrival trend characteristics, decreasing arrival trend characteristics, and correlated characteristics.
| Section | Controller | Decision Date |
|---|---|---|
| # | Name | Date |
|---|---|---|
| 1 | 789-MUM-2012-IntimationOfGrant23-09-2022.pdf | 2022-09-23 |
| 1 | ABSTRACT1.jpg | 2018-08-11 |
| 2 | 789-MUM-2012-PatentCertificate23-09-2022.pdf | 2022-09-23 |
| 2 | 789-MUM-2012-POWER OF ATTORNEY(14-6-2012).pdf | 2018-08-11 |
| 3 | 789-MUM-2012-US(14)-HearingNotice-(HearingDate-23-07-2021).pdf | 2021-10-03 |
| 3 | 789-MUM-2012-FORM 3.pdf | 2018-08-11 |
| 4 | 789-MUM-2012-Written submissions and relevant documents [06-08-2021(online)].pdf | 2021-08-06 |
| 4 | 789-MUM-2012-FORM 2.pdf | 2018-08-11 |
| 5 | 789-MUM-2012-FORM-26 [19-07-2021(online)].pdf | 2021-07-19 |
| 5 | 789-MUM-2012-FORM 18(27-3-2012).pdf | 2018-08-11 |
| 6 | 789-MUM-2012-CORRESPONDENCE(27-3-2012).pdf | 2018-08-11 |
| 6 | 789-MUM-2012-Correspondence to notify the Controller [16-07-2021(online)].pdf | 2021-07-16 |
| 7 | 789-MUM-2012-CORRESPONDENCE(14-6-2012).pdf | 2018-08-11 |
| 7 | 789-MUM-2012-CLAIMS [07-03-2019(online)].pdf | 2019-03-07 |
| 8 | 789-MUM-2012-FER.pdf | 2018-09-11 |
| 8 | 789-MUM-2012-COMPLETE SPECIFICATION [07-03-2019(online)].pdf | 2019-03-07 |
| 9 | 789-MUM-2012-DRAWING [07-03-2019(online)].pdf | 2019-03-07 |
| 9 | 789-MUM-2012-OTHERS [07-03-2019(online)].pdf | 2019-03-07 |
| 10 | 789-MUM-2012-FER_SER_REPLY [07-03-2019(online)].pdf | 2019-03-07 |
| 11 | 789-MUM-2012-DRAWING [07-03-2019(online)].pdf | 2019-03-07 |
| 11 | 789-MUM-2012-OTHERS [07-03-2019(online)].pdf | 2019-03-07 |
| 12 | 789-MUM-2012-COMPLETE SPECIFICATION [07-03-2019(online)].pdf | 2019-03-07 |
| 12 | 789-MUM-2012-FER.pdf | 2018-09-11 |
| 13 | 789-MUM-2012-CLAIMS [07-03-2019(online)].pdf | 2019-03-07 |
| 13 | 789-MUM-2012-CORRESPONDENCE(14-6-2012).pdf | 2018-08-11 |
| 14 | 789-MUM-2012-Correspondence to notify the Controller [16-07-2021(online)].pdf | 2021-07-16 |
| 14 | 789-MUM-2012-CORRESPONDENCE(27-3-2012).pdf | 2018-08-11 |
| 15 | 789-MUM-2012-FORM 18(27-3-2012).pdf | 2018-08-11 |
| 15 | 789-MUM-2012-FORM-26 [19-07-2021(online)].pdf | 2021-07-19 |
| 16 | 789-MUM-2012-FORM 2.pdf | 2018-08-11 |
| 16 | 789-MUM-2012-Written submissions and relevant documents [06-08-2021(online)].pdf | 2021-08-06 |
| 17 | 789-MUM-2012-FORM 3.pdf | 2018-08-11 |
| 17 | 789-MUM-2012-US(14)-HearingNotice-(HearingDate-23-07-2021).pdf | 2021-10-03 |
| 18 | 789-MUM-2012-PatentCertificate23-09-2022.pdf | 2022-09-23 |
| 18 | 789-MUM-2012-POWER OF ATTORNEY(14-6-2012).pdf | 2018-08-11 |
| 19 | ABSTRACT1.jpg | 2018-08-11 |
| 19 | 789-MUM-2012-IntimationOfGrant23-09-2022.pdf | 2022-09-23 |
| 1 | 789_07-09-2018.pdf |