HomeHomeAbout UsBrowseBack IssueNews DispatchesSubscribing to Army SustainmentWriting For Army SustainmentContactLinksBottom

Current Issues
Cover of Issue
 

Making BCS3 Work in a Deployed Environment

Units planning to use BCS3 in a deployed environment may find it to be a far greater challenge than expected. Soldiers of the 310th Expeditionary Sustainment Command learned this in 2011
as they supported Operation New Dawn.

The Battle Command Sustainment Support System (BCS3) is the logistics application of the modular Army Battle Command System. It can pull information from a variety of logistics information systems and compile it into one common operational picture for commanders to view. BCS3, however, suffered a number of setbacks in its early fieldings because it was perceived as being difficult to use and often unreliable.

After a major effort to improve BCS3, U.S. Forces–Iraq (USF–I) and the Army’s expeditionary sustainment command (ESC) in Iraq were told in 2010 to field the system or it would be removed from the theater. Both USF–I and the ESC, in their efforts to field the system, issued orders directing units to report through BCS3. This was the first mandate for units to use the system.

However, after a widespread fielding from September to December 2010, BCS3 was largely abandoned in favor of simple spreadsheets and databases. Soldiers went back to using Microsoft Excel and Access to manage fuel, and they stopped doing the maintenance needed to keep BCS3 functional. By March 2011, the 310th ESC arrived in Iraq to find that BCS3 was being used only for partial reporting of ammunition, water, and operational rations.

Some of the problems with BCS3 surfaced when the Army transitioned from a direct-support model to an area-support model that uses hubs, spokes, and forward operating bases. BCS3 also requires a great deal of maintenance and coordination at all levels of the organization to keep the system operating and the information accurate. However, with hard work and Soldiers dedicated specifically to BCS3 maintenance, it can be a great resource for managing most commodities in a deployed environment.

Although an updated version of BCS3 was specifically created to address supply point operations, the system does not adequately accommodate locations that do not have unit identification codes. Nor does it provide the data needed to manage ammunition at an ammunition supply point or fuel contained in bags.

Problems Associated With Unit Task Organization
The first thing that requires a great deal of effort to make BCS3 work is maintaining the unit task organization (UTO). BCS3 rolls up data for a given commodity from each echelon of an organization for the next-higher-level organization, appending the data into one common operational picture for the commander to see.

A unit must include all subordinate units in its organization, or it will not automatically receive data for those units. If a unit rotates out of theater and the UTO is not updated, then all units above the departed unit will continue to see this unit’s unchanging data but will not see the replacement unit’s data.

When the 310th ESC arrived in Iraq in March 2011, the UTO at the ESC level had not been updated for 6 months (while BCS3 was being fielded). Given the 10-month rotations of Reserve component units and the 12-month rotations of active duty units, the UTO may have been as much as 50 percent inaccurate. That is, 50 percent of the logistics data reported came from units no longer in Iraq and the replacement units were not reflected at all. These problems came from units that mandated, fielded, and were true believers in the system.

In another example, the ammunition section of the ESC noticed discrepancies in a class V (ammunition) count with a maneuver division. After studying the problem and discussing the issue with that division, the warrant officers discovered that the issue was an inaccurate UTO.
The overall accuracy of BCS3 for class V is estimated at 60 percent. Only the ammunition on individual unit property books is tracked with BCS3. Stockage at ammunition supply points is maintained directly from the Standard Army Ammunition System–Modernization (SAAS–MOD). SAAS–MOD provides ammunition managers with much more detailed ammunition information than BCS3 does. This minimizes the impact of BCS3 errors because of faulty reporting and out-of-date UTOs.

In his article “A New Dawn for BCS3” in the September–October 2011 issue of Army Sustainment, Major John J. Coiro said that one of his lessons learned while using BCS3 with the 103d ESC was to maintain a UTO manager. Being a UTO manager is an additional duty assignment in every unit with BCS3. Most units assign the knowledge manager or logistics automation officer as the UTO manager. However, this is a duty that requires diligent, constant updates.

All operators, or someone looking out for them, must install the current UTO onto every BCS3 laptop in the organization to maintain the accuracy and reliability of all data rolled up through that system. Typically, this is a point of failure for most organizations because one bad link in the chain affects the entire system.

The Logistics Factor File
The next thing requiring a great deal of effort and coordination is the Logistics Factor File (LFF). When calculating days of supply for a given commodity, LFF provides the multiplication rate for the calculation and sets thresholds of “green,” “yellow,” “red,” and “black” based on predetermined criteria. If the Army provides Soldiers with three meals a day, the LFF of “3” is entered for each day. However, every unit in your supply chain must install the same LFF on every BCS3 laptop dealing with the same commodity in order to reconcile data.

When the 77th Sustainment Brigade deployed to Iraq in the spring of 2011, it noticed inconsistencies with the bottled-water count for a subordinate battalion. The battalion was “red” for water but claimed it was “green.” The brigade requested an Excel spreadsheet from the battalion to assist with troubleshooting the issue. The battalion refused, saying that BCS3 is the system of record, and if the brigade wanted the numbers, it could get them from BCS3.

After a significant amount of time was spent investigating the issue, the 77th Sustainment Brigade’s logistics automation section asked the battalion what LFF it was using. The unit replied, “What is an LFF?” The battalion, which was totally committed to BCS3, was calculating three bottles of water per day for a 5-day week. The mandated LFF from USF–I was four bottles of water per day for all 7 days in the week. Doing the math, this error in LFF was a difference of 13 bottles of water per Soldier each week.

What makes this issue more complicated is the manner in which each unit chooses to provide reports. A unit that uses the Logistics Reporting Tool to roll up the status of its commodities can have 1-liter bottles of water with the same national stock number rolled up into 12-bottle cases and displayed as total bottles or total cases. However, units using the combat reporting tool application in BCS3 cannot do this; the Soldiers must know which unit is reporting cases and which unit is reporting bottles and then convert the totals to the unit (bottles or cases) needed.

(The Logistics Reporting Tool is an application that interfaces with BCS3 on a regular laptop. It was designed to make the complicated and unfamiliar interface of BCS3 resemble spreadsheets and make BCS3 more intuitive. The Logistics Reporting Tool, however, seems not to resolve the many issues with the overall system.)

The LFF can also cause errors when creating a tracked items list (TIL). A TIL allows a unit to select and track specific items from the broad inventory of supplies and commodities. However, when a new TIL is created, the LFF for each item is set by default. When this happens, the operator must adjust the LFF for each item, or all days of supply for that item will be reported incorrectly. This was the situation with the battalion that created the water issue for the 77th Sustainment Brigade.

Commodity History
BCS3 does not provide any history of commodity use, which is necessary if a logistician is to forecast how much food, ammunition, or fuel a unit will need for upcoming operations.

A number of questions could come up that require information that BCS3 does not provide: What is the 14-day rolling average for JP8 fuel use at a given base? What is the 25-day rolling average for class I (subsistence) and water use for a given base or dining facility? What effect did the Islamic holy month of Ramadan have on the consumption of both food and water last year? What about last summer, winter, or any other annual or historic event?

BCS3 provides the consumption rate only from the previous day. If a fuel point has a busy day, the class III (petroleum, oils, and lubricants) commodity manager will order too much fuel for the next day if that person bases the order solely on BCS3 usage data. Conversely, a slump in daily business can cause shortages. The previous year’s data are simply not available from the system. BCS3 creates a daily distribution rate (DDR) for these calculations. A commodity manager must set the DDR manually. Daily reports in BCS3 are exported into a spreadsheet or database where the DDR is calculated and then manually input back into BCS3.

Unfortunately, that is not the end of trouble for class III managers using BCS3. All modern operations are joint operations involving all branches of the military, not just the Army. Fuel is not owned by the Army; it is owned jointly. Class III managers must report fuel in the Fuels Enterprise System (FES) to the Defense Logistics Agency Energy. BCS3 is not compatible with FES, so operators must export data into a spreadsheet and then import the spreadsheet into FES.

No logistics information system for fuel will feed BCS3. Operators at distribution points must input data directly into BCS3 or Microsoft Excel. If Excel is used, the spreadsheets are then imported to BCS3. With no logistics information system for class III, BCS3 cannot calculate pending fuel orders and their effect on sustainment. Simply put, BCS3 does not meet the minimum requirements needed to report class III.

Microsoft Excel and Access
Since operators are importing data from Excel and Access and exporting data back to Excel and Access to do so much of their work, they must be aware of some of the pitfalls. If the data are not exactly in the correct format, such as when operators have added columns to account for factors missing in BCS3, then BCS3 will not take back any of the data. Operators must save a copy of the data they wish to import, remove all extra columns, and then import the data.

Operators at the ESC who manage class I must import data from contractors produced in the logistics status report known as LOGSTAR (created using Excel) and other Excel spreadsheets and Access databases every day. Class III managers at the ESC finally overcame these issues by simply abandoning BCS3 within 1 month of the much-heralded fielding of BCS3 in 2010.

Operator Maintenance
The final thing to remember when using BCS3 is to perform operator maintenance. Plugging data into BCS3 is like overfeeding guppy fish. BCS3 will continue to accumulate files automatically fed into the system until it induces system failure and crashes. At least twice a month, operators must clean out the kernel log file, close the project currently running in BCS3, and start a new one. Failure to conduct this maintenance is the most common source of problems within the BCS3 network.

Headcount
BCS3 can provide a commander with a headcount of supported personnel. This is especially important because logisticians calculate days of supply based on the number of supported personnel. However, when the 310th ESC arrived in Iraq in March 2011, the figures for headcount in BCS3 were off by more than 50,000 personnel. This was mostly because the UTO had not been updated in 6 months.

Commanders must direct specifically how personnel are to be tracked in BCS3; the recommended way is for each unit to report its own personnel data. Since this does not address the number of contractors in theater, the commander has to address how to account for contractors in his guidance.

Without such specific guidance, some units reported the headcounts from the base dining facilities into BCS3. This created a myriad of issues, and the total error in count was tremendous. USF–I resolved the issue by purchasing another personnel system called TREND. BCS3 operators now manually input figures from that system into BCS3.

BCS3 is a very powerful tool, but it requires a lot of intense effort. Commanders around the world are mandating the use of BCS3 based on its implementation success in Iraq. However, the exclusive use of BCS3 in Iraq lasted only 30 days before units began to return to simple Excel spreadsheets and Access databases.

Within 6 months of fielding BCS3, it was relegated to tracking only class I, water, and ammunition on unit property books. While the current version of BCS3 will likely never work for managing class III, it can be made to work for other classes of supply with a great deal of intense effort by all involved. However, a failure anywhere in the supply chain will adversely affect the accuracy of data BCS3 produces at all levels.

Lieutenant Colonel David A. Poland is the assistant chief of staff, G–6, for the 310th Expeditionary Sustainment Command in Indianapolis, Indiana. He was deployed to Joint Base Balad, Iraq, as the chief of the logistics automation section of the 310th Expeditionary Sustainment Command when he wrote this article. He holds a B.S. degree in business administration from West Virginia University and an M.S. degree in systems management from the University of Southern California. He is a graduate of the Army Information Systems Management Course, the Army Engineer Officer Advanced Course, and Intermediate Level Education.

 

Google
WWW Army Sustainment