Background: While employed at the Communications Maintenance dept. of the Pinellas County Sheriff’s Office, I was tasked with bringing the list of Mobile Data Terminals up to date. In doing so, I discovered a weak and potentially incapacitating approach to data collection. Thus, the following report:
Subject: Communications Maintenance Work Requests; their quality, and improvement thereof
II Project Number Field
III Short Description Field
IV Detail Description Field
VI Instructions Field
In the process of updating the Mobile Data Terminal (MDT) list, three bodies of records were pored over and collated: the Personnel Management System; the Fleet Management Equipment Inquiry, and the Communications Maintenance Work Requests. As the process continued, one particular fact became clear: the body of records with the highest level of inaccuracy was the Communications Maintenance (CMD) Work Requests.
This inaccuracy manifested in several ways: for example, an MDT known to be in a particular vehicle would be shown in its most-recent Work Request (WR) only to have been “removed for repair” from a different vehicle; or be shown to have been installed in a vehicle other than its current location. In several cases, no WRs were found.
Another great problem lies in a simple lack of detail. In many instances neither the ‘Short Description’ field nor the ‘Detail Description’ field, for example, contained sufficient data, and often merely re-stated information entered in dedicated fields within the document.
Of course, a portion of the blame for this must be placed on Comm Maint personnel’s attitude towards the Work Request application which, unfortunately, seems to be one of, “This program is a dinosaur, so I’m not going to put much effort into dealing with it.” Granted, the Work Request application is cumbersome and inflexible, to say the least. In fact, what is needed is a single application that can manage Personnel, CMD and Fleet Management information in interuseable databases, rather than using three incompatible stand-alone apps. But such an application is not soon in coming, so it behooves us to try to make better use of the existing application.
II Project Number Field
The place to start is the document header; this is the information first seen when the user navigates to the “Work Request Maintenance” screen. In its default setting — documents sorted by Work Request number — we notice two things: 1) the “Facility ID” field contains CMD asset numbers; and 2) the “Project Number” field is empty. CMD uses the first field — which normally would contain identifiers for factories, plants or other ‘facilities’ — to hold what is the single most important piece of data, the equipment asset number. The second field is empty because there are no data in the “Project Number” sub-library which relate to CMD activities. However, if CMD were to make use of this field as it does with the “Facility ID”, this would be a first step towards making better use of the WR application.
The sub-library for “Project Number” contains entries in this format: a six-digit number (in some cases, alphanumeric) accompanied by a brief text description (e.g., SO9802 – Courthouse Security). For CMD, the six-character identifier would be a simple description of equipment type — ‘portbl’ (for portable radios), ‘radar’, ‘siren’, etc. (If all six spaces must be used, either pluralizing or filler characters will suffice.) Having such information in a dedicated field would make identifying either a particular work order or an activity trend easier, as that field is both sortable and filterable.
A particular drawback in using this field is that, unlike most of the other sub-libraries, no direct modification option is available for this field’s sub-library at user-level; therefore Computer Services would have to make the modification.
III Short Description Field
The “Short Description” field, the only truly flexible field in the header, probably suffers from the least-effective use in the creation of a Work Request. In fact, since this field often contains nothing more than redundancies of data from dedicated fields, it is therefore the greatest weakness in a typical CMD Work Request, when because of its flexibility it could in fact be the strongest point. The Short Description field can contain a maximum of fifty characters, enough to form a well-detailed sentence fragment. Further, fully thirty of these fifty characters are displayed in the header, meaning that a fairly complex set of data may be entered into the Short Description field with the assurance that this information will be immediately available upon the User’s arrival at the Work Request Maintenance screen. What must be determined is just what information would be entered to best make use of this field. Examine the following:
- During the research for the MDT list update project, it became apparent that aside from the asset number of a given MDT, the data most needed were vehicle number, officer name and payroll number, and cost center.
- At the Jail sub-office, it is common practice for the technicians to note a portable’s model, serial number and from which section it originated
- Radar units are tracked by their serial numbers and unit numbers moreso than by their asset numbers
The following examples are taken from actual CMD Work Requests, and demonstrate typical data entry habits:
Note that none of the arguably more-pertinent data described in the preceding bullet list is included here. Moreover, such information often is not entered into a WR at all, whereas the data in the Short Description field is again either merely redundant or insufficiently informative. In fact, WF…473 offers no immediate clue as to what type of equipment it concerns.
Here’s a model of how these same work orders might look using specialized data formats:
In these examples, the data in the Short Description field more readily identify the different equipment items and make them easier to track. For example, Work Requests could be filtered to show only those concerning portables, or even more specifically, Visar portables; or perhaps only those concerning MDTs under Cost Center 5100. Further, since the Project Number field is both sortable and filterable, it could be used in conjunction with Short Description filtering to create either highly customized or extremely isolated document listings.
As can be seen, the modified entries are not identical in format; however, neither are they terribly dissimilar. Both the radar and portable entries contain an originating location and a serial number. The format used in the MDT entry would be the same for any piece of equipment installed into a vehicle.
A significant benefit of the modified data examples above is that for tracking purposes each such entry need only be done once per item per assignment. For the duration of that assignment, this data need not be entered again until the item is either re-assigned, removed and shelved, or disposed of; then the extended data would be entered reflecting the changes, and not entered again until another such change. For example, if WR~462 actually contained the modified data shown above, that would be the only such entry necessary until, seven months from now let’s say, MDT #12439 is moved to a different car. The WR concerning the move would contain the new vehicle, employee and cost center numbers; this would be the only time the new data need be entered, any reports generated in-between, during which time the MDT did not “change hands”, would simply not need the extended data. For equipment tracking purposes, a single such entry is quite sufficient.
IV Detail Description Field
The Detail Description field also suffers from poor use. More often than not it’s merely left blank; or it contains ‘information’ barely more informative than that entered in the Short Description field. This field is also fifty characters wide, but can be several pages long, offering more than enough room for the User to explain both the fault and various repair steps taken. Unlike some of the dedicated fields, this field remains unlocked for the duration of the WR’s open status, allowing the User to continually add to it as work progresses.
The only significant drawback of the Detail Description field is that it offers no word-processing capability aside from basic insertion, deletion and type-over. Each line is a unique field, separate and distinct from the rest. This can make editing a lengthy report tedious.
Just as useful, but even moreso overlooked is the Result Comments field, which functions in the exact manner of the Detail Description field. It is made available upon the closing of a Job Order or Work Request, but is rarely and poorly used.
V Dedicated Fields
This concerns not so much the habits of Users as it does planning. The strength or weakness of the various Dedicated Fields lies in their related sub-libraries. For each entry field that offers the ‘prompt’ (F4) function, there is a sub-library of pre-defined entries from which one may be selected. As both technology and the operations of CMD have changed, the sub-libraries have grown inadequate due to lack of upkeep.
For example, virtually none of the existing entries accurately covered Jail sub-office operations. With the aid of the Office Manager, the Jail technicians added or re-defined many entries to better suit their WRs. However, this was done several years ago; with the addition of Video Visitation, as well as other changes in operations, the sub-libraries for Jail WRs have again fallen behind.
The Maintenance function for these libraries can be accessed at user-level (providing the User has proper authorization attached to his/her AS400 identity), so upkeep on them can readily be accomplished. On a regular basis, perhaps annually or bi-annually, all the sub-libraries should be reviewed to determine if they need maintenance.
VI Instructions Field
In the Job Order attached to a Work Request, there is a dedicated field named “Standard Task Code”; this field is unique in that along with its own sub-library, it also has a sub-library for the Instructions field. When a Standard Task Code selection is defined in the sub-library, the User may then also define a custom Instructions field layout; this layout then automatically gets loaded into the Instructions field when a Standard Task Code selection is made.
Here, the concern for accuracy is two-fold: the maintenance of the pre-defined layouts, and the efficient use of these layouts by the User. Regarding maintenance, the concern is the same as that of the sub-libraries as mentioned in Sec. V, Dedicated Fields
The concern for efficient use of the Instructions field is at least equal to that already mentioned, and in fact may be greater. For, while much of the data in a Work Request or Job Order are selected from sub-libraries, entry of the Instructions field data is manual entirely. Moreover, since the Technicians use printed WRs and JOs, rather than filling them in online, the generated data often are not then entered into the online forms. Thus, the majority of CMD’s data lies not in a convenient online history but in a massive collection of hard-copy printouts. Should a particular document get lost or damaged, or too worn to remain useable, the recourse of simply re-printing it very well may not exist. The simple fact is that many of the online documents do not contain the very information for which their hard-copy versions were originally printed.
The usefulness of any given tool lies not only in the function or functions designed into the tool but also in how well and how appropriately the User uses the tool. While the Work Request application is far from user-friendly, it can more effectively serve as CMD prefers to use if better use were made of the capabilities it does have. Often, CMD hears from the personnel and sections it supports complaints about the equipment for which it is responsible; yet when CMD tries to introduce new, often computer-based, technologies, it is met with great resistance to change from the current equipment. Ironically, in a sense this also happens within CMD. The general opinion of the Work Request application held by CMD personnel is fairly low; yet when a different and arguably better way of using the application or configuring the data is presented, CMD personnel balk at the notion of changing from the current methodology. Unfortunately, this has led to a general lack of overall accuracy in the Work Requests, inconsistency in the collection of data and a great absence of much of the very information for which a given Work Request is created. The quality of CMD’s own records shall certainly remain sub-standard unless and until a significant change is made in the way these records are generated and maintained.
Original document written in 1999; this online version © 2016 Designs by Gus