Patent Application
20060126801
1. Field of the Invention
The present invention generally relates to management systems for monitoring trouble tickets in a telecommunications services environment. More particularly, the present invention relates to a trouble ticket monitoring system having an Internet enabled and Web-based remote graphical user interface (GUI) to trouble ticket workload management systems.
2. Background Art
In order to ensure a high availability rate in communications network services provided to customers, service providers require accurate and responsive maintenance efforts. Workload management systems that support these maintenance efforts are a vital part of a service provider's marketability.
Workload management systems such as Work and Force Administration—Control (WFAC), Work and Force Administration—Dispatch Out (WFADO), and Work and Force Administration—Dispatch In (WFADI) are trouble ticket reporting and tracking software systems used by service providers to monitor workload and individual trouble ticket history. Such workload management systems (collectively referred to as “WFA systems”) are fault management tools which allow a trouble ticket to be opened in response to a telecommunications network fault or a service problem.
Service providers use trouble ticketing as a means for identifying reported network faults or service problems. When a network fault or service problem is reported, a trouble ticket describing the network fault or service problem is opened in one or more of the WFA systems. Generically, WFA systems are databases and trouble tickets are electronic tracking mechanisms that exist as data records in at least one of these databases.
In operation, the status of a trouble ticket is considered open as long as the network condition remains unresolved. At any given time, the collection of open trouble tickets represents the set of ongoing and future repair efforts of the service provider. This mechanism provides the service provider with a method for identifying the status of current and future repair efforts.
The problem with WFA systems is that they lack an Internet enabled and Web-based remote interface that enables different users to open and monitor trouble tickets relating to network faults and service problems on the enterprise network. Further, WFA systems are not universally provided with an interface to communicate and transfer information to other systems.
As such, the trouble ticket reports generated by WFA systems are not interactive. That is, the generated trouble ticket reports are listings of trouble tickets which are not easily organized or displayed in a convenient way for personnel of the service provider. Further, WFA systems require users to enter typed commands to open trouble tickets and to generate more specific trouble ticket reports.
In a system employing more than one WFA system, service provider personnel are required to enter typed search criteria in each WFA system in order to obtain a listing of trouble tickets satisfying a certain criteria. The service provider personnel then have to manually correlate the generated trouble ticket listings using a spreadsheet in order to identify the trouble tickets satisfying all of the search criteria.
The advantages of a trouble ticket monitoring system in accordance with the present invention are numerous. In general, the trouble ticket monitoring system has an Internet enabled and Web-based graphical user interface (GUI) to trouble ticket workload management systems. Such workload management systems include legacy WFAC, WFADO, and WFADI systems (collectively referred to as “WFA systems”).
The trouble ticket monitoring system includes a dashboard application. In general, the dashboard application enables everything that can be done on WFA systems to be able to be done using an Internet enabled Web-based GUI. As such, the dashboard application represents a server based rather than client based approach to trouble ticketing generation and monitoring. The dashboard application provides a GUI for point and click navigation, functions, and commands to the WFA systems. The dashboard application provides ease of customization, updates, and upgrades to meet service provider and customer needs to WFA systems. The dashboard application is able to combine reports and queries from several different WFA systems into one meaningful display.
In operation, the dashboard application combines both real-time and historical data from several sources (including different WFA systems) to present an overview of all maintenance operations in one location. The dashboard application provides drill-down capabilities for trouble ticket reports in order to display the trouble ticket information required by a user at a specific time without requiring manual processing or knowledge of the legacy WFA systems on the user's part. The dashboard application also provides interaction with legacy WFA systems and embedded testing applications to allow many necessary maintenance functions to be performed from one application or one interface.
In general, the dashboard application interacts with legacy WFA systems for both trouble ticket reporting and interactive trouble ticket functions while presenting a simple user interface. Point and click functionality provided by the dashboard application for users allows for reporting or maintenance functions to be performed with a minium of typing or knowledge of the legacy WFA systems.
The dashboard application also interacts with a Symposium Call Center system to provide reports of the center's call center functions. The dashboard application facilitates access to embedded testing systems such as the ASI Circuit Manager, Broadband Tools, and the SBCIS ATM Ping Tool. This allows for a more efficient method of pulling information concerning circuit performance without having to switch between applications and request such information manually.
The dashboard application has built-in escalation ability to allow service provider management to set criteria for trouble ticket report handling and be notified when these criteria are not met. Notifications of missed criteria retain the ability of testing and performing maintenance functions to allow efficient addressing of these reports.
The dashboard application uses historical data to aid in spotting trends and to predict future workload. The dashboard application presents such trends as both raw data and in graphical format. The dashboard application is implemented with the ability to use historical data to predict workload for the day from current data and to forecast the necessary amount of work to address incoming workload.
The dashboard application is preferably written in PERL and runs on any Web server installed with PERL and capable of running CGI scripts. As such, no specific client-side applications are required other than standard Web browser software. The dashboard application therefore can be used on almost any personal computer (PC) out-of-the box.
With the dashboard application running all of the functions on the server side, updates and maintenance are simplified. Once updates or changes have been made on the server side using the dashboard application all clients (i.e., the legacy WFA systems, the embedded test systems, etc.) receive the new information the next time any action is performed. No beta-testing is required for updates and enhancements to ensure compatibility with the multiple clients now in use as long as HTTP compliant code is presented to the end user. Necessary PERL modules are either available with any PERL distribution or can be created specifically for the dashboard application.
The dashboard application can also be modified for new trouble ticket reporting formats as long as the trouble ticket reports are available via a TCP/IP network. Similarly, any new applications will also be supported if they are capable of TCP/IP communication. Security is provided via encryption where necessary, for instance when user information such as passwords are communicated.
Referring now to
Connections between dashboard application 12 and the multiple WFA hosts 14, 16 and embedded testing systems 18 are provided by TCP/IP sockets. Dashboard application 12 provides an interface wherein a user 28 may login and use a single password to access the multiple WFA hosts 14, 16 and embedded testing systems 18 with no need to login and enter a password for each of these systems. As denoted by the double arrows, dashboard application 12 supports simultaneous sessions with the multiple WFA hosts 14, 16, multiple users 28, and embedded testing systems 18.
Dashboard application 12 also interfaces with a WFAC Online Query System (OQS) server 20, a WFADO OQS server 22, a symposium call center report server 24, and an ASI maintenance report server 26. (Dashboard application 12 also interfaces with a WFADI OQS server (not shown).)
As noted above, dashboard application 12 provides an Internet enabled Web-based GUI which provides a mechanism to transfer data among the various systems and servers connected to the dashboard application. As a result, data may be quickly and easily accessed by user 28 to speed the process by which trouble ticket reports are resolved.
The popularity and wide spread adoption of the Internet provides a measure of platform independence for users 28 who wish to connect to enterprise systems such as WFA systems and embedded testing systems, as the users can run their own Internet Web browser and use their own platform connection to the Internet to enable service. This resolves many of platform hardware and connectivity issues in favor of users 28, and lets the users choose their own workstation platform and operating system. Web-based programs minimize the need for training and support as they use existing user browser software which users 28 have already installed and know how to use. Any issues relating to connectivity and communications have already been resolved in favor of standard and readily available hardware and the browser and dial-up software used by the Internet connection.
An Internet delivered paradigm for WFA services obviates many of the installation and configuration problems involved with initial setup and configuration of a dial-up user workstation, as dashboard application 12 required to interface with the legacy WFA systems can be delivered to users 28 via the Internet and run within a standard Web browser, reducing compatibility issues of the dashboard application to browser compatibility issues.
In general, in order to generate trouble tickets for storage in at least one of WFA systems 14, 16, dashboard application 12 provides a GUI for users 28 to use in order to generate trouble tickets. This GUI provided by dashboard application 12 has a structured format for receiving trouble ticket information from users 28. As such, dashboard application 12 acts as a filter to ensure that proper information for generating trouble tickets is inputted by users 28. In turn, dashboard application 12 provides the trouble tickets to at least one of WFA systems 14, 16.
As indicated above, WFA systems 14, 16 are trouble ticket and reporting systems which store trouble tickets. As the trouble tickets are worked on and resolved, users 28 use another GUI provided by dashboard application 12 to update in WFA systems 14, 16 the status of the trouble tickets and remove trouble tickets from the WFA systems which have been resolved.
In general, in order to provide trouble ticket reports, dashboard application 12 receives data indicative of the trouble tickets stored in WFA systems 14, 16 from WFA OQS servers 20, 22. Dashboard application 12 provides GUIs of the trouble ticket reports for display to users 28. Users 28 use the GUIs to have dashboard application 12 manipulate the data received from WFA OQS servers 20, 22 in order to generate tailored GUI trouble tickets report for display to the users.
Referring now to
In operation, dashboard application 12 receives a request from a user 28 for updating a trouble ticket or adding a trouble ticket in WFA systems 14, 16 as shown in block 32. To this end, dashboard application 12 displays for user 28 a GUI which has a standard format for updating or adding a trouble ticket. User 28 uses this GUI to transmit to dashboard application 12 the updated or added trouble ticket information. In turn, dashboard application 12 pulls current information regarding the updated or added trouble ticket from WFA systems 14, 16 and displays same in a GUI to user 28 as shown in block 34.
User 28 then uses this GUI to input updated or new trouble ticket information as shown in block 36. Dashboard application 12 then parses the inputted updated or new trouble ticket information and sends an appropriate request to WFA systems 14, 16 as shown in block 38. Dashboard application 12 receives a message from WFA systems 14, 16 regarding whether the request is successful as shown in block 40. If the request is successful, meaning that WFA systems 14, 16 have received from dashboard application 12 the updated or new trouble ticket information, then the dashboard application retrieves the updated trouble ticket information from the WFA systems as shown in block 42. In turn, dashboard application 12 displays in a GUI the retrieved updated trouble ticket information for user 28 as shown in block 42.
If the request is unsuccessful, meaning that WFA systems 14, 16 have not received from dashboard application 12 the updated or new trouble ticket information for some reason (such as the request being improper, not consistent with trouble tickets stored in the WFA systems, in an incorrect format, etc.), then the dashboard application prompts user 28 with another GUI to retry the request as shown in block 44. If user 28 uses this GUI to successfully input updated or new trouble ticket information as shown in block 46, dashboard application 12 then repeats operation steps 38, 40, and 42.
Referring now to
In operation, dashboard application 12 periodically receives trouble ticket data from WFA OQS servers 20, 22 as shown in block 52. The trouble ticket data is indicative of the trouble tickets stored in WFA systems 14, 16 at a current time. Dashboard application 12 automatically receives the data without human intervention from WFA OQS servers 20, 22 every half hour or so. As such, in this example, dashboard application actually receives two sets of trouble ticket data. One set of trouble ticket data is the trouble ticket information from WFA system 14 and the other set of trouble ticket data is the trouble ticket information from WFA system 16. As indicated above, there may be other WFA systems such as a WFADI system which would also have its own set of trouble ticket information.
Upon receiving all of the sets of trouble ticket information, dashboard application 12 combines, processes, and locally stores the trouble ticket information as shown in block 54. Dashboard application 12 displays a GUI for user 28 to use in order for the user to request a trouble ticket report as shown in block 56. This GUI enables user 28 to enter trouble ticket search criteria for generating a tailored trouble ticket report. Such a tailored trouble ticket report includes the trouble tickets which meet the trouble ticket search criteria of user 28.
Upon receiving a request for a trouble ticket report from user 28, dashboard application 12 determines if the trouble ticket data for the requested trouble ticket report is stored locally by the dashboard application as shown in block 58. If so, dashboard application 12 processes and manipulates the locally stored trouble ticket data per the requested criteria of user 28 to generate the appropriate trouble ticket report as shown in block 60. Again, the appropriate trouble ticket report includes the trouble tickets which meet the requested criteria of user 28.
If dashboard application 12 determines that the trouble ticket data for the requested trouble ticket report is not stored locally, then the dashboard application requests from WFA systems 14, 16 and WFA OQS servers 20, 22 the requested trouble ticket data as shown in block 62. Upon receiving the requested trouble ticket data, dashboard application 12 parses and locally stores the requested trouble ticket data if appropriate as shown in block 64. Dashboard application 12 then processes and manipulates the locally stored trouble ticket data per the requested criteria of user 28 to generate the appropriate trouble ticket report as shown in block 60.
Once dashboard application 12 has generated the appropriate trouble ticket report, the dashboard application adds hyperlinks or options for further drill-down capability of the appropriate trouble ticket report as shown in block 66. The hyperlinks or options added may also be for additional information as shown in block 66. Dashboard application 12 then displays a GUI of the appropriate trouble ticket report along with any added hyperlinks or options for user 28 as shown in block 68.
Referring now to
In operation, dashboard application 12 runs at specified intervals for generating escalation trouble ticket reports as shown in block 72. Dashboard application 12 provides a GUI for display to user 28 for the user to enter trouble ticket escalation criteria. During each interval, dashboard application 12 pulls trouble ticket data from WFA OQS servers 20, 22 as shown in block 74. Dashboard application 12 parses and locally stores the pulled trouble ticket data as shown in block 74.
Dashboard application 12 compares the parsed and locally stored trouble ticket data with the user's preset trouble ticket escalation criteria as shown in block 76 to determine whether there is a match as shown in block 78. If there is a match, meaning there is an trouble ticket escalation event, then dashboard application 12 alerts an appropriate user of the escalation event as shown in block 80. The alert could be in the form of a GUI for display to the appropriate user. Dashboard application 12 then locally stores information regarding the escalation event as shown in block 82. If there is not a match at block 78, then dashboard application 12 stores the information for proactive use by users 28 to prevent escalations as shown in block 84.
Referring now to
In GUI 90, the hyperlinked (i.e., underlined) numbers within table 92 represent amounts of trouble tickets which have a particular duration and a particular status. As described above, in GUI 90, the trouble tickets are arranged horizontally by duration (such as in minutes since the time the trouble ticket has been opened and unresolved) and arranged vertically by status. The hyperlinked numbers in parentheses represent trouble tickets having expired timers. As will be described in further detail, dashboard application 12 generates other trouble ticket report GUIs in response user 28 clicking on any of the hyperlinked trouble ticket numbers contained in table 92 of GUI 90.
GUI 90 further includes a menu list 94 which allows drill-down capabilities of the trouble ticket reports by trouble ticket segmentation (business, residential) any by management level all the way to retrieving trouble ticket load for individual technicians. GUI 90 further includes a search criteria box 96 which allows a user 28 to enter an instant trouble ticket query by trouble ticket number.
Referring now to
Referring now to
Referring now to
Referring now to
Referring now to
Referring now to
Referring now to
Referring now to
Referring now to
Referring now to
Referring now to
Referring now to
Referring now to
Referring now to
Referring now to
Referring now to
As described, WFA systems are not GUI systems. In order to navigate between screens of WFA systems, typed in commands are required and there is no point-and-click ability. WFA systems further require client-based software installation and are high maintenance, not efficient, and hard to modify and customize.
In contrast, dashboard application 12 of trouble ticket monitoring system 10 provides an Internet-enabled Web-based GUI interface to the WFA systems. As such, dashboard application 12 provides Web-based navigation between screens with point and click ability. The logic is on the server side and all options are accessible through a Web-browser such as Internet Explorer. As a result, trouble ticket monitoring system 10 is very customizable—only the server needs to be updated as new additions and modifications are required. Current solutions (such as WFA systems described in the preceding paragraph) require users to have client based software installed on their personal computers which requires a high level of maintenance to operate.
While embodiments of the present invention have been illustrated and described, it is not intended that these embodiments illustrate and describe all possible forms of the present invention. Rather, the words used in the specification are words of description rather than limitation, and it is understood that various changes may be made without departing from the spirit and scope of the present invention.
