Device level performance monitoring and analysis

Methods relating to device level performance monitoring and analysis include accessing device data including a listing of network devices, with each network device having a device profile. The methods further include accessing service reports, with each report related to a service issue. A set of devices profiles from the listing of network devices may be identified based on a particular device being associated with a particular service issue. The method further includes determining a set of problem prone device profiles from the set of devices profiles. A system including at least one database and a report processor may be configured to associate device data with service reports, identify service issue trends from service reports, identify at least one at risk device susceptible to future service issues related to service issue trends, and provide preventative support to the identified at least one at risk device.

BACKGROUND

A service provider may implement a tracking system for tracking reports of service issues and customer service requests. Such a tracking system may provide historical information related to service issues, but may not provide predictive analyses regarding future service issues. Moreover, such issue tracking systems only include limited information on the network devices that were subject to the service issues. Having only limited information on the network devices prevents the extrapolation of past service issues for the prediction of future service issues that may occur in similar devices.

A customer relationship database system may track information related to a set of customers. This customer information may include details regarding the network devices of the customer. However, information that is obtainable only from a combination of issue tracking and customer relationship data sets may go unrealized absent systems and methods for joining and analyzing data from such disparate systems.

DETAILED DESCRIPTION

FIG. 1illustrates an exemplary device level performance monitoring and analysis system100. System100may be implemented by a service provider such as a network service provider. A network105may interconnect a customer system110, a ticket system125, and a trend analysis system140. Customer system110may include a customer server115communicatively coupled to a customer data store120. Ticket system may include a ticket server130communicatively coupled to a ticket data store135. Trend analysis system140may include a trend analysis server145communicatively coupled to a trend analysis data store150. Trend analysis server may include a data import module160, a trend identification module170, and a reporting module180.

Network105may be a local-area network (LAN) or a wide-area network (WAN). Network105may further be a packet switched communication network such as an Internet Protocol (IP) network. Network105generally interconnects various computing devices and the like, such as servers115,130, and145. Interconnections in network105may be made by various media including wires, radio frequency transmissions, and optical cables. Other devices connecting to network105, e.g. switches, routers, etc., are omitted for simplicity of illustration inFIG. 1.

Customer system110may provide a customer server115and customer data store120for tracking information about customers. Customer system110may be a customer relationship management system, or the like. Any one of numerous generally available customer relationship management systems, e.g., SAP CRM, Oracle/Sieble CRM, Salesforce, etc., may be suitable as customer system110. Customer system110may include data storage entities in customer data store120that are particularly adapted or customized to the relationship between the service provider and the customer. For instance, a network service provider may include data storage entities for storing information about network devices, device interfaces, and circuits associated with a customer.

Customer server115may be a server based computer system, such as a web application server, configured to provide a customer relationship management system like that just described. However, any computing device having a computer readable medium including instructions for communicating with customer data store120may act as customer server115. Customer server115may be a networked computer system configured with server software for accepting connections via network105. Customer server115may provide a graphical or command line user interface for use by a human operator. Additionally, customer server115may provide an interface of remote procedure calls that allow remote systems to programmatically interact with customer server115. For instance, remote procedure calls may be used by trend analysis server145to receive data from customer data store120. Accordingly, customer server115may act as an intermediary to customer data store120. WhileFIG. 1merely depicts a single customer server115, it is to be understood that customer server115may include a pool of servers configured to share the responsibility of interacting with customer data store120.

Customer data store120may be a relational database management system (RDBMS). Many such systems, including SQL Server, Oracle, and MySQL, among others, are generally available. Customer data store120generally stores customer data in row and column table format, and may include multiple tables. A row, or record, includes one or more columns, or fields, holding data values for specifically defined fields. Rows may be uniquely identified by the values of one or more columns. Indexes of one or more columns can be included to aide in searching for particular rows of the table.

Ticket system125may be provided by a customer service or helpdesk entity of the service provider. Such an entity may employ one of many generally available helpdesk management systems, e.g. Remedy, Kaseya, OneOrZero, etc. Such systems typically allow customer service personnel to receive service reports410(FIG. 4) related to service issues from customers. These reports410may be stored to a database, e.g. ticket data store135, for use by other customer service personnel such as repair technicians. Such systems typically refer to stored service reports410as trouble tickets, or just tickets. A ticket may be initiated by customer service personnel or by a customer in response to a service issue faced by the customer. The customer service personnel may provide further information and prepare the ticket for a repair technician. The repair technician may provide follow-up information on the ticket regarding any repairs related to the service issue as well as the amount of time required to resolve the service issue.

Ticket server130may be a server based computer system, such as a web application server, configured to provide a helpdesk management system or ticket system like the one just described. However, any computing device having a computer readable medium including instructions for communicating with ticket data store135may act as ticket server130. Ticket server130may be a networked computer system configured with server software for accepting connections via network105. Ticket server130may provide a graphical or command line user interface for use by a human operator. Additionally, ticket server130may provide an interface of remote procedure calls that allow remote systems to interact with ticket server130. For instance, remote procedure calls may be used by trend analysis server145to receive data from ticket data store135. Accordingly, ticket server130may act as an intermediary to ticket data store135.

Ticket data store135may be a relational database management system (RDBMS). Many such systems, including SQL Server, Oracle, and MySQL, among others, are generally available. Ticket data store135generally stores ticket data in row and column table format, and may include multiple tables. A row, or record, includes one or more columns, or fields, holding data values for specifically defined fields. Rows may be uniquely identified by the values of one or more columns. Indexes of one or more columns can be included to aide in searching for particular rows of the table.

Trend analysis system140may include trend analysis server145and trend analysis data store150in order to receive data from customer data store120and ticket data store135. Customer and ticket data may be copied to trend analysis system in order to allow manipulations and alterations thereof without causing interference to the normal operations of the originating systems. For instance, ticket data may need to be altered by trend analysis server145. However, altering the ticket in ticket data store135may interfere with the normal operations of ticket system125. Trend analysis system140may store the customer and ticket data according to a different table structure, e.g., a structure that is simplified or optimized for the identification of service issue trends. Accordingly, trend analysis data store150may maintain a duplicate set of client and ticket data in order to allow for any necessary manipulations and alterations. WhileFIG. 1merely depicts a single trend analysis server145and a single trend analysis data store150, it is to be understood that trend analysis system140may include a pool of trend analysis servers145and trend analysis data stores150.

Trend analysis server145may be a server based computer system, such as a web application server, configured to provide data import, trend identification, and reporting functionality. However, any computing device having a computer readable medium including instructions for modules160-180may act as trend analysis server145. Trend analysis server145may be a networked computer system configured with server software for accepting connections via network105. Trend analysis server145may provide a graphical or command line user interface for use by a human operator. Additionally, trend analysis server145may provide an interface of remote procedure calls, or the like, that allow remote systems to interact with trend analysis server145. For instance, remote procedure calls may allow for the remote execution of modules160-180.

Trend analysis data store150may be a relational database management system (RDBMS). Many such systems, including SQL Server, Oracle, and MySQL, among others, are generally available. Trend analysis data store150generally stores customer and ticket data in row and column table format, and may include multiple tables. A row, or record, includes one or more columns, or fields, holding data values for specifically defined fields. Rows may be uniquely identified by the values of one or more columns. Indexes of one or more columns can be included to aide in searching for particular rows of the table.

Data import module160may provide computer instructions for interacting with customer system110and ticket system125in order to receive data from customer data store120and ticket data store135. The instructions of data import module160may be executed manually via the interface of trend analysis server145. For instance, trend analysis server145may provide a web page interface, or the like, that includes controls for executing data import module160. Trend analysis server145may further provide an interface for scheduling the execution of data import module160at a future time or on a recurring, periodic basis. In another exemplary approach, data import module160may run continuously and may receive data from customer data store120and ticket data store135via various data acquisition methodologies. Data import module160is described in more detail below with respect toFIGS. 4 and 6.

Trend identification module170may provide computer instructions for analyzing the data imported by data import module160in order to identify service issue trends from the ticket data. The instructions of trend identification module170may be executed manually via the interface of trend analysis server145. In another exemplary approach, trend identification module170may be called or triggered by the execution of data import module160. Trend identification module170is described in more detail below with respect toFIGS. 5 and 7.

Reporting module180may provide computer instructions for analyzing the service issue trends identified by trend identification module170. The instructions of reporting module180may be executed manually via the interface of trend analysis server145. In another exemplary approach, reporting module180may be called or triggered by the execution of trend identification module170. Reports may be provided in electronic form such as a web page, email, PDF document, etc. Reporting module180is described in more detail below with respect toFIGS. 5 and 6b.

FIG. 2illustrates a portion of exemplary telecommunications network200. A network segment205may interconnect various network access points210a-c. Each network access point210a-cmay be monitored by a network operations center (NOC)215a-b. Network access points210a-cmay host network devices such as routers220a-cand switches225a-c. Network devices generally have a device profile230a-das well as a set of device attributes235a-f.

Network segment205may be a high capacity network connection, such as a network backbone, which carries data gathered from smaller connections that interconnect with it. However, it is to be understood that network segment205might not be a single element as depicted. For instance, network segment205may include one or more discrete networks that are not necessarily directly attached to each other.

Network access points210a-cprovide access to network segment205and may provide a physical co-location point for hosting various network devices such as routers220a-cand switches225a-c. NOC215a-bmay include a facility, equipment, and personnel for monitoring and maintaining the network connections and network devices of network access points210a-c. A single NOC, e.g., NOC215a, may be responsible for monitoring multiple network access points210a,210c. NOCs215a-bmay be physically co-located with network access points210a-c, or may be in geographically remote locations. Additionally, NOC215amay not be responsible for monitoring all network devices at network access point210a, but may be responsible for a subset of network devices at a multiple network access points210a,201c.

Routers220a-cact as connection points or nodes to network segment205. Routers220a-cgenerally provide connections to one or more networks205in order to direct network communications between network devices. However, connections from routers220a-cto other routers or networks are omitted fromFIG. 2for simplicity. Routers220a-cmay provide connections to other network devices at network access point210a-csuch as switches225a-c. Switches225a-cgenerally distribute a network connection to multiple network devices (not show). It is to be understood that network devices are not limited to the illustrated routers220a-cand switches225a-cand may also include both low level equipment such as digital subscriber line access multipliers (DSLAMs), digital subscriber line (DSL) modems, channel service units/data service units, and high level equipment such as firewalls, instruction detection systems, traffic monitoring systems, etc. Other configurations of exemplary telecommunications network200are also possible including providing the functions of routers220a-cand switches225a-cby the same physical device. Additionally, other network devices such as firewalls and intrusion detection systems may be included as part of switches225a-c.

Each network device, i.e. routers220a-cand switches225a-c, may include a device profile230a-eand device attributes235a-f. A device profile230a-dmay be defined by at least one device attribute235a-f. Moreover, two devices may share the same device profile230a-ddespite having a different set of device attributes235a-f. For instance, a device profile230a-dmay be defined by the manufacture and model number of a network device. While the manufacture and model number may also be device attributes235a-f, the device attributes235a-fmay further include additional information such as the operating system name and version, the firmware version, etc. Furthermore, aspects external to a network device may also be included as device attributes235a-f. For instance, the circuit transport type of a device, the customer, and even the NOC210a-cresponsible for monitoring the network device may all be considered as being part of the set of device attributes235a-f.

Computing devices such as customer server115, ticket server130, and trend analysis server145may employ any of a number of computer operating systems known to those skilled in the art, including, but by no means limited to, known versions and/or varieties of the Microsoft Windows® operating system, the Unix operating system (e.g., the Solaris® operating system distributed by Sun Microsystems of Menlo Park, Calif.), the AIX UNIX operating system distributed by International Business Machines of Armonk, N.Y., and the Linux operating system. Computing devices may include any one of a number of computing devices known to those skilled in the art, including, without limitation, a computer workstation, a desktop, notebook, laptop, or handheld computer, or some other computing device known to those skilled in the art.

Customer data store120, ticket data store135, and trend analysis data store145may include a query processor that employs Structured Query Language (SQL) in addition to a language for creating, storing, editing, and executing stored procedures, such as the Procedural Language/Structured Query Language (PL/SQL) utilized by Oracle, as mentioned above. Customer data store120, ticket data store135, and trend analysis data store145may each be some other kind of database, other than an RDBMS, such as a hierarchical database, a set of files, an embedded application database in a proprietary format, etc. Customer data store120, ticket data store135, and trend analysis data store145generally include a computing device employing a computer operating system such as one of those mentioned above, and are accessed via a network in any one or more of a variety of manners, as is well known. Exemplary systems are possible in which customer data store120, ticket data store135, and trend analysis data store145, or a combination thereof, are combined as a single data store.

FIG. 3illustrates an exemplary set of database entities, or tables,300that may be used with trend analysis data store150. In one exemplary approach, data in a circuits table315, a customers table310, a devices table305, and an interfaces table320may originate from customer data store120. Similarly, data in a service reports table325may originate from ticket data store135. Devices table305may include information about network devices, i.e., routers220a-cand switches225a-c, including device profiles230a-dand device attributes235a-f. Device profiles230a-dand device attributes235a-fmay include the fields, or columns, of devices table305. However, fields from other tables such as circuits table315, customers table210, and interfaces table320may also be included as part of device profiles230a-dand device attributes235a-f. Service reports table325may include time values in the ticket time, service issue length, and estimated time to repair fields.

As discussed above, relational databases typically store data in tabular row and column format. A relationship may be provided, for example, from a row of a first table to a row of a second table by including a value that identifies the row of the second table in the row of the first table. The dashed linesFIG. 3illustrate the corresponding fields that may be used to develop relationships between devices table305and service reports table325. The solid lines ofFIG. 3represent existing relationships including those developed between devices table305and service reports table325by data import module160.

FIG. 4provides a dataflow diagram illustrating an exemplary flow400of data into and out of data import module160. Device data405may include a listing of network devices including a device profile for each device, and may include data that will be imported in to devices table305. Service reports410may include reports of service issues such as the service issues that are stored as tickets in ticket system125and imported into service reports table325. A service issue may be the result of numerous possible causes, including an issue with a network device. However, service reports410may not be configured to relate a service issue to a network device. For example, a network service provider may experience service issues as the result of a problematic network device, but may only be able to record service reports410according to a particular network circuit, customer, or domain name. Accordingly, service reports410may be analyzed with respect to linking data415in order to relate a service report410to a particular network device of device data405.

As discussed above, data import module160may be provided when the data required by trend analysis module170is not available in trend analysis data store150. Accordingly, data import module160may receive data from customer data store120and ticket data store135. However, service reports410from ticket data store135may lack attributes allowing for the joining of the data with the data from customer data store120. For instance, a telecommunications service provider may implement ticket system125such that each service report410is related to a network circuit rather than to a customer or network device. Moreover, service reports410may not include any device information or may only include a secondary device identifier, such as a domain name. Therefore, customer data and circuit data from customer data store120may be provided to data import module160and used as linking data415to form relationships between device data405and service reports410, such as ticket data. As discussed above, importing data into trend analysis data store150may allow for data alterations and manipulations that wouldn't be possible in the source data stores.

As will be discussed in more detail below with respect toFIG. 6a, data import module160may receive data from customer data store120and ticket data store135. The data may then be formatted or altered in order to facilitate comparisons between the previously disparate data sets. Finally, service reports410may be iteratively reviewed to identify relationships to device data405. Data import module160may produce a combined data set420of device data405and service reports410.

FIG. 5provides a dataflow diagram illustrating an exemplary flow500of data into and out of trend identification module170and reporting module180. Combined data set420, such as that produced by data import module160, may be accessed and reviewed to identify a set of device profiles230a-drelated to service issues. This set of device profiles230a-dmay then be used to determine a set of problem prone device profiles505and problem prone device attributes510. Combined data set420may then be reviewed again in light of problem prone device profiles505and problem prone device attributes510in order to identify at risk devices515. Additional details of trend identification module170and reporting module180are presented below with respect toFIG. 6b.

A service issue trend may include any history of service issues that may be associated by some common aspect. For instance, a service issue trend may include a history of service issues that are all associated by a common a device profile230a-dor device attribute235a-f. A service issue trend may be predictive of future service issues even for devices that have never experienced a service issue.

In one exemplary approach, a device profile230a-dmay encompass a vender and model number of a device. It may be determined that a certain combination of the vender and model number is problem prone, and therefore the device profile230a-dencompassing the vender and model number would be considered a problem prone device profile505. This identification of a problem prone device profile505may provide a predictive indication that other devices, even those that have never experienced a service issue, may be at risk for a future service issue. However, just because a device profile230a-dmay be predictive of a future service issue does not necessarily indicate that the device profile230a-ditself is the cause of the service issue. There may be other device attributes235a-fthat can be more closely correlated to service issues. For instance, it may be the case that many devices that share a problem prone device profile505also share a common device attribute235a-f. This common device attribute235a-fmight be more predictive of a future service issue than the device profile230a-dand therefore, may be identified as a problem prone device attribute510. A search for at risk devices515that is limited to only those devices having a problem prone device profile would likely overlook a device having the identified problem prone device attribute510but that does not have the problem prone device profile505.

FIG. 6aillustrates a flowchart depicting exemplary steps and decisions relating to a process600for importing device data405and linking data415. Trend analysis server145may include a computer-readable medium having stored instructions for carrying out certain operations described herein, including some or all of the operations described with respect to process600. For example, some or all of such instructions may be included in data import module160.

The process600begins in step605in which device data405and linking data415may be imported. Trend analysis server145may connect to customer server115of customer system110in order to receive customer data, i.e. device data405and linking data415, from customer data store120. Trend analysis server145may utilize a remote procedure call available on customer server115in order to initiate the data import. In another exemplary approach, the data import may be initiated by customer server115. For instance, trend analysis server145may be available to receive a transfer of customer data initiated by customer server115. Regardless of the initiation of the data import, the customer data may be received by trend analysis server145in order to be saved to trend analysis data store150. Because the customer data import may occur repeatedly, e.g., on a periodic basis, trend analysis data store150may already contain some or all of the data that is received from customer system110. Accordingly, trend analysis server145may cause trend analysis data store150to overwrite all existing customer data or may compare the newly imported data to the existing data in order to save only the new or modified data. In another exemplary approach, customer server115may be configured to only provide data that is new or modified since last import of customer data.

Next, in step610, service reports410may be imported. Service reports410may be related to service issues and may be derived from service repair requests such as the requests recorded by ticket system125and stored in ticket data store135. The import of service reports410may be triggered by the conclusion of the import of customer data, i.e. device data405and linking data415. Trend analysis server145may connect to ticket server130of ticket system125in order to receive service reports410from ticket data store130. Trend analysis server145may utilize a remote procedure call available on ticket server130in order to initiate the data import. In another exemplary approach, trend analysis server145may be continuously available to receive data410from ticket system125, Regardless of the initiation of the data import, the service reports410may be received by trend analysis server145in order to be saved to trend analysis data store150. Because the import of service reports410may occur repeatedly, e.g., on a periodic basis, trend analysis data store150may already contain some or all of the data that is received from ticket system125. Accordingly, trend analysis server145may compare the newly imported data to the existing data in order to save only the new data. In another exemplary approach, ticket server130may be configured to only provide data that is new or modified since last import of service reports410.

Next, in step615, the imported data, i.e. device data405, service reports410, and linking data415, may be formatted. Because data may be imported from disparate systems, e.g. customer system110and ticket system125, the imported data may not be formatted consistently across the data sets. Such inconsistencies may interfere and even prevent the development of relationships between the service reports410and device data405. For instance, data may need to be capitalized, trimmed, or otherwise altered in a manner consistent with the formalities of trend analysis data store150.

Steps620-635create a combined data set420by developing relationships between the imported device data405and service reports410. It is to be understood that the relationship development is not limited to only the data that was just imported in steps605and610. For instance, data that was previously imported may have failed to relate to any other data. However, new linking data415may have been imported in step605that would allow a relationship to be developed between the device data405and service reports410.

Next, in step620, a list of service reports410is retrieved from trend analysis data store150. Step620begins the iteration of steps620-635over the list of service reports410by selecting a service report410for review. The selection typically involves a sequential selection of service reports410. However, in another exemplary approach, the query processor of trend analysis data store150may provide only those service reports that lack a joinable data element.

Next, in step625, it is determined whether the service report410that is currently being reviewed lacks a joinable data element. Each service report410may be represented by a row in service reports table325. Rows in service reports table325may include a relationship to devices table305by including a value in the device ID column. Accordingly, any row of the service reports table325that lacks a relationship, i.e. an entry in the device ID column of the row, to devices table305is deemed to lack a joinable data element. If the service report410already includes a joinable data element, the process may skip to step635.

Next, in step630, linking data415may be used to build a relationship between device data405and service reports410. The service report410currently being reviewed may be analyzed to determine if any other column provides information that may be used to develop a relationship to a specific device. Other possible columns that may be used to identify a specific device include the circuit name and domain name columns. For instance, the circuit name column may provide a value that can be used to determine a device ID from the circuits table315. Similarly, the domain name column may provide a value that can be used to determine a device ID from the devices table305. A direct relationship between the rows of service reports table325and the rows of customers table310may also be desired. Accordingly, the customer name field of service reports table325may be compared to the customer name field of customers table310to determine a customer ID to store in service reports table325.

Next, in step635, it is determined whether there are more service reports410to review. If there are remaining service reports410to review, the process may return to step620.

Following a determination in step635that there are no more service reports410to review, the process ends.

FIG. 7illustrates a flowchart depicting exemplary steps and decisions relating to a process700for identifying service issue trends and at risk devices515. Trend analysis server145may include a computer-readable medium having stored instructions for carrying out certain operations described herein, including some or all of the operations described with respect to process700. For example, some or all of such instructions may be included in trend identification module170and reporting module180. Process700involves two passes over a list of device records retrieved from devices table305. The first pass identifies problem prone device profiles505and problem prone device attributes510. The second pass reviews the list of devices in light of the identified problem prone device profiles505and problem prone device attributes510in order to identify a set of at risk devices515.

The process700begins in step705in which a list of devices may be retrieved from trend analysis data store150. As discussed above, service reports table325may provide service reports410associated with service issues. As a result of process600, rows of service reports table325may include a device ID, thereby associating a particular device with a service report410. Accordingly, service reports table325may be queried for all of the device IDs contained therein in order to identify a set of device IDs which represents devices that have experienced reported service issues in the past. A service provider may wish to identify the devices that have experienced service issues in order to identify trends in the service issues. However, merely identifying the devices may be insufficient. In fact, identifying the device profiles230a-dassociated with service issues may be more relevant to the prediction of future service issues. Accordingly, the set of device IDs may then be used to query the devices table305to retrieve a list of device records to examine.

Next, in step710, it may be determined whether the service reports410for a device exceed a threshold. In order to improve the predictive results of the data, the entire list of devices associated with service issues may be narrowed. For instance, a device may be identified as a problem prone device based on the number of service reports410associated with the device exceeding a threshold level. The service reports table325may be queried for the number of service reports410associated with the device. If the count fails to exceed a threshold level, the process may proceed to step725.

In another exemplary approach the threshold may be related to the length of single service issue or the sum of the lengths of the service issues associated with a device rather than simply the number of service reports410related to the device. The length of a service issue may be stored in the service issue length column of service reports table325. Accordingly, for a threshold related to the sum of the lengths of the service issues, service reports410associated with a device may be retrieved in order to access the service issue lengths. The service issue lengths may then be summed and compared to the threshold.

Next, in step715, the device profile230a-dof the device may be added to the set of problem prone device profiles505. As discussed in step710, only those devices having service reports410that exceed a threshold will have their device profiles230a-dadded to the set of problem prone device profiles505. Accordingly, the set of problem prone device profiles505may provide service issue trends by identifying those device profiles230a-dhave a history of service issues.

Next, in step720, the device attributes235a-fof the device may be added to the set of problem prone device attributes510. A device profile230a-dmay be indicative of a future service issue, but might not be the actual cause. In fact, the cause of a service issue may be related to a device attribute235a-f. As discussed above, a device attribute235a-fthat has a history of service issues may provide a service issue trend that can be used to predict future service issues. Therefore, the device attributes235a-fof the device may be added to the set of problem prone device attributes510.

Next, in step725, the process may return to step705if there are remaining devices to review.

In another exemplary approach that takes advantage of a query processor of trend analysis data store150, steps705-725may be condensed. For instance, service report data410, i.e. the rows of service reports table325, may be joined with the devices table305according the device ID column. The joined data may be grouped by device profile230a-dand then counted. The selected device profiles230a-dmay be further limited to a set of problem prone device profiles505, e.g., to only those having a count of related service issues exceeding a threshold or to only those related to service issues having a sum of the service issue lengths exceeding a threshold. A similar approach of using a query processor may be implemented to add device attributes235a-fto the set of problem prone device attributes510.

Next, in step730, the second pass over the list of devices begins by selecting a device to review. Unlike above, the entire list of devices from devices table305may be reviewed in order to identify at risk devices515, including those devices that have never experienced a service issue. At risk devices515include any device that has a device profile230a-dincluded in the set of problem prone device profiles510or a device attribute235a-fincluded in the set of problem prone device attributes510. The problem history of a device, or lack thereof, may not be relevant to the determination that a device is an at risk device515. Accordingly, a device that has never experienced a service issue may still be determined to be an at risk device515due to the device having a device profile230a-dincluded in the set of problem prone device profiles510or a device attribute235a-fincluded in the set of problem prone device attributes510.

Next, in step735, it is determined whether the device being reviewed has a device profile230a-dthat is included in the set of problem prone device profiles505. The comparison of the device profile to the set of problem prone device profiles505may be conducted iteratively over the set of problem prone device profiles505or through the use of a query processor. If the device profile230a-dis not included in the set of problem prone device profiles505, the process may skip to step745.

Next, in step740, the device may be added to the set of at risk devices515.

Next, in step745, it is determined whether the device being reviewed has a device attribute235a-fthat is included in the set of problem prone device attributes510. As with step735, the comparison of the device attributes to the set of problem prone device attributes510may be conducted iteratively over the set of problem prone device attributes510or through the use of a query processor. If none of the device attributes235a-fare included in the set of problem prone device attributes510, the process may skip to step755.

Next, in step750, the device may be added to the set of at risk devices515.

Next, in step755, the process may return to step730if there are remaining devices to review.

Finally, in step760, preventative support may be provided to the identified at risk devices515. Multiple types of preventative support may be available based on the way a device was identified as being an at risk device515. For a device identified based on the device profile230a-dbeing in the set of problem prone device profile505, a service technician could be assigned to provide general diagnostics, the device could be considered for replacement, or the vendor could be called upon to determine the cause of past service issues. For a device identified based on the device having a device attribute235a-ffrom the set of problem prone device attributes510, the preventative support may be targeted at the problem prone device attribute510. For instance, if the problem prone device attribute510relates to the firmware or operating system of the device, appropriate upgrades or patches thereto could be applied. If the problem prone attribute510is related to the NOC215a-b, the device could be assigned to a different NOC215a-b, or the NOC personnel could receive training related to the device.

Following a determination in step755that there are no more devices to review, the process ends.

Accordingly, system100may allow a service provider to combine device data405from a customer system110with service reports410from a ticket system125in order to create a combined data set420. The data may be imported by a data import module160into a separate trend analysis data store150in order to allow the data to be reformatted as necessary to identify relationships between the device data405and service reports410. The combined data set420may relate information about service issues to particular devices such that a set of problem prone device profiles505and a set of problem prone device attributes510may be identified by a trend identification module170. The combined data set420may be reanalyzed by a reporting module180to identify at risk devices515in order to provide preventative support thereto. Thus, customer service may be improved by providing support to at risk devices515prior to the development of a service issue.