Issue tracking system

From Wikipedia, the free encyclopedia

Jump to: navigation, search
Merge arrows
 It has been suggested that this article or section be merged with Issue management. (Discuss)

An issue tracking system (also called trouble ticket system or incident ticket system) is a computer software package that manages and maintains lists of issues, as needed by an organization. Issue tracking systems are commonly used in an organization's customer support call center to create, update, and resolve reported customer issues, or even issues reported by that organization's other employees. An issue tracking system often also contains a knowledge base containing information on each customer, resolutions to common problems, and other such data. An issue tracking system is similar to a "bugtracker", and often, a software company will sell both, and some bugtrackers are capable of being used as an issue tracking system, and vice versa.

A ticket is a file contained within a issue tracking system which contains information about support interventions made by technical support staff or third parties on behalf of an end user who has reported an incident that is preventing them from working with their computer as they would expect to be able to. Tickets are commonly created in a help desk or call center environment. Typically the ticket will have a unique reference number, also known as a case, issue or call log number which is used to allow the user or support staff to quickly locate, add to or communicate the status of the users issue or request.

These tickets are so called because of their origin as small cards within a typical wall mounted work planning system when this kind of support started, operators or staff receiving a call or query from a user would fill out a small card with the users details and a brief summary of their request and place it into a position (usually the last) in a column of pending slots for an appropriate engineer, so determining the staff member who would deal with the query and the priority of the request.

Contents

[edit] Architecture

The most common issue tracking system's design is relatively simple. A database is the main storage repository for all data. These data are managed by the business logic layer of the application. This layer gives the underlying raw data more structure and meaning, preparing it for human consumption. The now human readable data are then presented to the support technician by another software application or web page. The end-user of the issue tracking system can create entirely new issues, read existing issues, add details to existing issues, or resolve an issue. Anytime a user of the system makes a change, the issue tracking system will record the action and who made it, so as to maintain a history of the actions taken. Each user of the system may have issues assigned to them, that is, that user is responsible for the proper resolution of that issue. This is generally presented to the user in a list format. The user may have the option of re-assigning an issue to another user, if needed. For security, an issue tracking system will authenticate its users before allowing access to the systems.

[edit] Issues

Issues can have several aspects to them. Each issue in the system may have an urgency value assigned to it, based on the overall importance of that issue. Critical issues are the most severe that should be resolved in the most expedient way possible, taking precedence over all other issues. Low or zero urgency issues are minor, and should be resolved as time permits. Other details of issues include the customer experiencing the issue (whether external or internal), date of submission, detailed descriptions of the problem being experienced, attempted solutions or work-arounds, and other relevant information. As previously noted, each issue maintains a history of each change.

[edit] Workflow

An example scenario is presented to demonstrate how a common issue tracking system would work:

  1. A customer service technician receives a telephone call, email, or other communication from a customer about a problem. Some applications provide automatic error reporting from exception handling blocks.
  2. The technician verifies that the problem is real, and not just perceived. The technician will also ensure that enough information about the problem is obtained from the customer. This information generally includes the environment of the customer, when and how the issue occurs, and all other relevant circumstances.
  3. The technician creates the issue in the system, entering all relevant data, as provided by the customer.
  4. As work is done on that issue, the system is updated with new data by the technician. Any attempt at fixing the problem should be noted in the issue system.
  5. After the issue has been fully addressed, it is marked as resolved in the issue tracking system.

The problem may not have been fully corrected, yet it will still be marked as resolved. The problem may be by-design, a known issue, or have a suitable work-around. A Run Book Automation process that implement best practices of these workflow and increase IT personnel effectiveness is becoming very common.

[edit] See also

[edit] External links

Retrieved from "http://en.wikipedia.org/wiki/Issue_tracking_system"
Personal tools