Narrative:

After downloading and executing the [weight and balance] data; we received an FMC message 'unable 280 KTS at churo.' we discovered the cause to be the cost index of 20 set by the dispatch release which commands a 261 knot descent after transition from mach. We had to spend time finding out the cause which is not optimal during the very busy time after [weight and balance] takeoff data arrives. As we all know; the moment the [weight and balance] takeoff data arrives is one of the busiest times of a flight so this is not inconsequential. This happened again on our very next flight as well; however this time we quickly discovered it was due to the same thing. The ci (cost index) set to below 40 is obviously to save fuel and accomplish our third operational priority of efficiency. But since this programming generates an airspeed that does not comply with a published STAR; it becomes a clear safety issue; greatly increasing the likelihood of pilot violations/deviations if the programming is not corrected. This policy therefore places our number one policy priority; safety; below our third priority; efficiency.the variable cost index is a great tool for saving fuel; however it cannot be one-size-fits-all. It must be applied at the appropriate time and only where its use does not generate a conflict with the planned STAR at the arrival airport. Crews should not be expected to load an arrival that generates errors and subsequently have to rely on other rrm (risk and resource management) blocks to then correct the planned input that caused the error. We should plan for success and not failure. The use of ci less than 40 should be carefully selected by the dispatcher at airports where the planned STAR has no airspeed restrictions. However; we can take advantage of the variable cost index to save fuel if used properly. In the case where the airspeed restrictions are 280 knots; a cost index of 36 generates a perfect 280 knot transition. We can take advantage of the lower cost index and still comply with the speed requirements. Interestingly; all ZZZ stars have a magenta box dictating a 280 knot transition. Why not use CI36 all the time on ZZZ arrivals? This puts us in compliance with this requirement the instant we load our [weight and balance] data at the gate. It requires no further action by the pilot; as opposed to now where we must modify the VNAV descent page to comply. This is setting up for success not failure. On stars where there is a 270 knot restriction; a ci of 28 generates a 271 knot transition; which is the closest you get to 270 knots without getting slower. Again; we obtain the lower ci fuel savings and avoid having to reprogram our VNAV descent page. It would take a little time to build the database to check on airspeed requirements for the different stars; but this should be simple programming. Simply put; 'if STAR=xxxxx; then ci must be greater than or equal to 36'. Then repeat for the others in our system. Used smartly; this could be a great tool for saving fuel; but as we can see; blindly applying a lower ci is setting our crews up for likely violations and deviations and misplacing our operational priorities.

Related reports:

Google
 

Original NASA ASRS Text

Title: B737 Captain reported the cost index was set too low by Dispatch; so the aircraft could not meet the published speeds on the arrival.

Narrative: After downloading and executing the [weight and balance] data; we received an FMC message 'UNABLE 280 KTS AT CHURO.' We discovered the cause to be the Cost Index of 20 set by the Dispatch release which commands a 261 knot descent after transition from mach. We had to spend time finding out the cause which is not optimal during the very busy time after [weight and balance] takeoff data arrives. As we all know; the moment the [weight and balance] takeoff data arrives is one of the busiest times of a flight so this is not inconsequential. This happened again on our very next flight as well; however this time we quickly discovered it was due to the same thing. The CI (Cost Index) set to below 40 is obviously to save fuel and accomplish our third operational priority of efficiency. But since this programming generates an airspeed that does not comply with a published STAR; it becomes a clear safety issue; greatly increasing the likelihood of pilot violations/deviations if the programming is not corrected. This policy therefore places our number one policy priority; Safety; below our third priority; efficiency.The variable cost index is a great tool for saving fuel; however it cannot be one-size-fits-all. It must be applied at the appropriate time and only where its use does not generate a conflict with the planned STAR at the arrival airport. Crews should not be expected to load an arrival that generates errors and subsequently have to rely on other RRM (Risk and Resource Management) blocks to then correct the planned input that caused the error. We should plan for success and not failure. The use of CI less than 40 should be carefully selected by the Dispatcher at airports where the planned STAR has no airspeed restrictions. However; we can take advantage of the variable cost index to save fuel if used properly. In the case where the airspeed restrictions are 280 knots; a cost index of 36 generates a perfect 280 knot transition. We can take advantage of the lower cost index and still comply with the speed requirements. Interestingly; all ZZZ STARS have a magenta box dictating a 280 knot transition. Why not use CI36 all the time on ZZZ arrivals? This puts us in compliance with this requirement the instant we load our [weight and balance] data at the gate. It requires no further action by the pilot; as opposed to now where we must modify the VNAV descent page to comply. This is setting up for success not failure. On STARS where there is a 270 knot restriction; a CI of 28 generates a 271 knot transition; which is the closest you get to 270 knots without getting slower. Again; we obtain the lower CI fuel savings and avoid having to reprogram our VNAV Descent page. It would take a little time to build the database to check on airspeed requirements for the different STARS; but this should be simple programming. Simply put; 'IF STAR=XXXXX; THEN CI MUST BE GREATER THAN OR EQUAL TO 36'. Then repeat for the others in our system. Used smartly; this could be a great tool for saving fuel; but as we can see; blindly applying a lower CI is setting our crews up for likely violations and deviations and misplacing our operational priorities.

Data retrieved from NASA's ASRS site 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.