Narrative:

Ground personnel became frustrated with the software application used to manage aircraft loads. The passenger count for this trip had changed by 1 -- increasing from 5 passenger to 6 passenger; but they were unable to get the computer to take the update. Rather than delay the flight; they elected to keep this information from the flight crew. I learned about this situation when the load controller who had signed into the flight informed me of the situation -- I then attempted to contact the flight crew with the revised 'final numbers;' which included the new takeoff gross and percent mac calculations. At this point; the flight was in the air. Using the company frequency; I tried to radio the crew. They did not acknowledge my xmissions. I encouraged the load controller to report this incident via the company procedure for misloading aircraft. While this specific loading did not pose any practical threat to safety of flight; the aircraft type in question here often becomes 'balance critical' with very light loads and our load controllers generally give these situations additional scrutiny for that very reason. Probably the key factor involved in this very representative type incident is insufficient training and indoctrination of station personnel in both loading procedures and the potential consequences of misloading an aircraft. In addition; widespread problems with company radio facilities may be breeding a sense of futility regarding attempts to communicate with crews once they are aboard their respective aircraft. The company has made considerable progress in this area since instituting a rigorously improved load management system. The backbone of this approach is load control; which is co-located with dispatch in our system operations center and manned by assistant dispatchers specifically trained in the use of our load management software and dedicated exclusively to load planning. However; as a cost-cutting measure; our airline has announced its intention to dismantle load control; lay off the assistant dispatchers; and make load management part of the dispatcher's function - in essence; returning to an approach demonstrably fraught with increased risks. A communications audit -- designed to identify; isolate; and hopefully correct critical radio problems -- is underway at this time.

Google
 

Original NASA ASRS Text

Title: RPT DETAILS AN ALLEGEDLY COMMON SITUATION WHEREIN DISPATCHERS; LOAD PLANNERS ARE FRUSTRATED WITH COMPUTER SOFTWARE; COMPANY RADIO COMS; AND INSUFFICIENTLY TRAINED PERSONNEL. IN THIS CASE RESULTING IN THE DISPATCH OF AN SF340 WITH KNOWN LOAD PLANNING DISCREPANCIES.

Narrative: GND PERSONNEL BECAME FRUSTRATED WITH THE SOFTWARE APPLICATION USED TO MANAGE ACFT LOADS. THE PAX COUNT FOR THIS TRIP HAD CHANGED BY 1 -- INCREASING FROM 5 PAX TO 6 PAX; BUT THEY WERE UNABLE TO GET THE COMPUTER TO TAKE THE UPDATE. RATHER THAN DELAY THE FLT; THEY ELECTED TO KEEP THIS INFO FROM THE FLT CREW. I LEARNED ABOUT THIS SITUATION WHEN THE LOAD CTLR WHO HAD SIGNED INTO THE FLT INFORMED ME OF THE SITUATION -- I THEN ATTEMPTED TO CONTACT THE FLT CREW WITH THE REVISED 'FINAL NUMBERS;' WHICH INCLUDED THE NEW TKOF GROSS AND PERCENT MAC CALCULATIONS. AT THIS POINT; THE FLT WAS IN THE AIR. USING THE COMPANY FREQ; I TRIED TO RADIO THE CREW. THEY DID NOT ACKNOWLEDGE MY XMISSIONS. I ENCOURAGED THE LOAD CTLR TO RPT THIS INCIDENT VIA THE COMPANY PROC FOR MISLOADING ACFT. WHILE THIS SPECIFIC LOADING DID NOT POSE ANY PRACTICAL THREAT TO SAFETY OF FLT; THE ACFT TYPE IN QUESTION HERE OFTEN BECOMES 'BAL CRITICAL' WITH VERY LIGHT LOADS AND OUR LOAD CTLRS GENERALLY GIVE THESE SITUATIONS ADDITIONAL SCRUTINY FOR THAT VERY REASON. PROBABLY THE KEY FACTOR INVOLVED IN THIS VERY REPRESENTATIVE TYPE INCIDENT IS INSUFFICIENT TRAINING AND INDOCTRINATION OF STATION PERSONNEL IN BOTH LOADING PROCS AND THE POTENTIAL CONSEQUENCES OF MISLOADING AN ACFT. IN ADDITION; WIDESPREAD PROBS WITH COMPANY RADIO FACILITIES MAY BE BREEDING A SENSE OF FUTILITY REGARDING ATTEMPTS TO COMMUNICATE WITH CREWS ONCE THEY ARE ABOARD THEIR RESPECTIVE ACFT. THE COMPANY HAS MADE CONSIDERABLE PROGRESS IN THIS AREA SINCE INSTITUTING A RIGOROUSLY IMPROVED LOAD MGMNT SYS. THE BACKBONE OF THIS APCH IS LOAD CTL; WHICH IS CO-LOCATED WITH DISPATCH IN OUR SYS OPS CTR AND MANNED BY ASSISTANT DISPATCHERS SPECIFICALLY TRAINED IN THE USE OF OUR LOAD MGMNT SOFTWARE AND DEDICATED EXCLUSIVELY TO LOAD PLANNING. HOWEVER; AS A COST-CUTTING MEASURE; OUR AIRLINE HAS ANNOUNCED ITS INTENTION TO DISMANTLE LOAD CTL; LAY OFF THE ASSISTANT DISPATCHERS; AND MAKE LOAD MGMNT PART OF THE DISPATCHER'S FUNCTION - IN ESSENCE; RETURNING TO AN APCH DEMONSTRABLY FRAUGHT WITH INCREASED RISKS. A COMS AUDIT -- DESIGNED TO IDENT; ISOLATE; AND HOPEFULLY CORRECT CRITICAL RADIO PROBS -- IS UNDERWAY AT THIS TIME.

Data retrieved from NASA's ASRS site as of January 2009 and automatically converted to unabbreviated mixed upper/lowercase text. This report is for informational purposes with no guarantee of accuracy. See NASA's ASRS site for official report.