Conceptualizing, developing, and building are in some ways the easiest part of introducing a new system. Fielding and implementing it can be much more challenging. Designed to complement a robust suite of systems known as the Army Battle Command System, the Battle Command Sustainment Support System (BCS3) draws information from various diverse systems, tools, and applications to provide a common operating picture (COP) to leaders. In theory, it works flawlessly. However, in practice, it fell short of the mark when it was first fielded. After nearly 4 years in development and 7 years of multiple fielding attempts, BCS3 in Iraq has become a story of deploying a long-resisted information system to modernize the Army and venture into the 21st century.
Conceptualized early in 2003 and first fielded in 2004, BCS3 provides the commander on the ground with an immediate snapshot of the logistics picture, which was known then as the logistics COP but is now simply called the COP. The COP provides actionable logistics information on in-transit and commodity visibility and equipment readiness status. It also allows unit-level logistics reporting and monitoring of relsated commander's critical information requirements.
To achieve the COP, BCS3 draws data from a host of systems, applications, and tools, such as Standard Army Management Information Systems, the Integrated Logistics Analysis Program, the Logistics Information Warehouse, the Global Transportation Network, and the Standard Installation/Division Personnel System. These systems all feed directly into the national server and are distributed out to various data-forwarding gateways worldwide.
When the network is without issue, the transmission of this information from source to server to data-forwarding gateway to workstation takes no more time than sending an email to somebody halfway around the globe. BCS3's operational flexibility comes from its ability to work on both the classified and unclassified networks since certain Army systems, like Blue Force Tracker, have only classified data feeds.
Despite the awesome potential of having a multisourced system display a single COP, its reception by Soldiers was, at best, lukewarm. BCS3, in its earliest configuration, frustrated many Soldiers with its complex and unfamiliar interface. It developed a reputation of unreliability because of constant system crashes and, worst of all, inaccurate data. To their credit, the Product Manager BCS3 (PM–BCS3) and the Army Training and Doctrine Command Capability Manager (TCM) quickly rectified many of the early issues by releasing several enhancements and upgrades to the application.
The latest product, rolled out in 2008, was called the "Ease of Use" upgrade, which improved the user's experience by introducing several enhancements, including a more intuitive graphical interface and redesigned database. However, with the damage done, the first generation of users—Soldiers and commanders who experienced the earliest versions of BCS3—actively resisted the introduction of this automation system into their tactical operations centers. The consequence was a seemingly never-ending fielding attempt and, most discouragingly, the delay of modernizing the sustainment community with a system capable of presenting a single COP for commanders to use.
Resourceful Soldiers requiring a method to easily capture and manage logistics data turned to the path of least resistance and commandeered applications already found on their workstations. In that way, the logistics status report (LOGSTAR), otherwise known as the logistics status (LOGSTAT), came into existence. A LOGSTAR is nothing more than a common Microsoft Excel spreadsheet with a series of rigid and complex formulas that allow sustainers to track, store, and, most importantly, use the data to forecast requirements, shortfalls, and overages.
Soldiers readily use LOGSTARs instead of BCS3 because they already understand how to use Excel. A LOGSTAR does not require an understanding of unit connections or the administration of a client-server relationship. Transmitting a LOGSTAR is straightforward: merely open up an email, attach the LOGSTAR, and send it to the next higher echelon.
Regrettably, a LOGSTAR allows the manipulation of data by granting Soldiers access to change the data found in each cell. In this way, resourceful staffs can "shape" the picture of the battlefield to suit their expectations. These habits have developed a staff culture that permits the common practice of adjusting a LOGSTAR to a desired rather than an actual status.
LOGSTARs have other drawbacks. First, a LOGSTAR is a single-dimensional, glorified Excel spreadsheet. Second, fragile and complex formulas reside within this spreadsheet. Easily manipulated as they are, people often break formulas, which requires countless hours to repair. Units often inherit a LOGSTAR from the preceding unit and have no understanding of the data entered into the cells. Updating LOGSTARs became a rote task that devolved from the staff actively managing their commodities to merely filling in the blanks. For example, units would often fail to adjust their LOGSTAR to fit their modified tables of organization and equipment and their Property Book Unit Supply Enhanced (PBUSE) systems information.
From data entry to the very last level of review, the data in a LOGSTAR, which were held sacrosanct by the Army Sustainment Command, were completely unreliable. And since LOGSTARs deliver their information from a logistics viewpoint rather than from a tactical perspective, staffs must work for hours to reconfigure the information into reports that will be accepted by higher echelons. Nevertheless, LOGSTARs have become the favored method because they are easy to use and flexible enough to fit the needs of nearly every kind of unit in theater. However, one cannot effectively manage logistics by using a spreadsheet, glorified or otherwise.
|"Of course, when all parties are using BCS3, reports are not necessary since relevant information is populated in BCS3. Everyone on the network can see and utilize the reported information. One of the fundamental principles of the modular force logistics concept is 'centralized EAB [echelons above brigade] logistics C2,' which will enable the most efficient and effective end-to-end distribution process."
—Field Manual Interim 4–93.2,
The Sustainment Brigade
Seeking User Input
In 2006, PM–BCS3 sent a data collection team to interview the troops on the ground and discover why they preferred LOGSTARs to BCS3. In late 2006, the 13th Sustainment Command (Expeditionary) (ESC), in conjunction with TCM and PM–BCS3, identified the need for a better logistics reporting capability in the Iraq joint operations area (IJOA). This capability needed to focus on the big money-making commodities: class I (subsistence), IIIB (bulk petroleum, oils, and lubricants), and V (ammunition).
PM–BCS3 developed a hybrid Web-service client LOGSTAR prototype in early 2007, mimicking PBUSE's move to a web-based application. In mid-2007, PM–BCS3, in conjunction with the 13th ESC, conducted a limited-user evaluation to test the LOGSTAR Web-service client.
After more testing and development, PM–BCS3 and TCM conducted another limited-user evaluation with the 316th ESC, a Pennsylvania Army Reserve unit, using a more developed Logistics Reporting Tool (LRT) prototype. The purpose of the second limited-user evaluation was to determine if the capabilities of the LRT prototype met the IJOA's minimum requirements for use in supply-point reporting of classes I, IIIB, and V and to identify the final modification needed for unit-level reporting.
The following is a basic explanation of how requested changes travel through the acquisition process. First, the war- fighter identifies a change and submits a mission needs statement, or operational needs statement, to the combat developer or TCM.
Next, TCM vets the request against both Army doctrine and joint requirements. Once TCM approves the change, it transfers the action to the materiel developer or project manager (PM). Generally, but not always, a modification to the contract accompanies the change request. After that, the PM delivers the project to a team of developers.
The developers then take the change request and modify the content, conduct preliminary testing, and refine the product as necessary. In theory, the users who requested the change would conduct the final test. Unfortunately, because of the unit rotation cycle in the IJOA, the unit requesting the changes has usually been replaced by a new unit before PM–BCS3 completes any modifications.
In 2009, PM–BCS3 fielded LRT, best described as an automated spreadsheet. PM–BCS3's goal was to provide Soldiers with a familiar interface, namely LOGSTAR.
LRT is an extension of the "ease of use" enhancements released in 2008. It is the tool of choice for the Soldier because of its many advantages over both the BCS3 workstation and LOGSTARs. Primarily, it is an installed application on the Soldier's workstation, which is not only convenient but eliminates the need for having an additional laptop cluttering the workspace (which BCS3 requires). The interface is intuitive and straightforward; any Soldier who can enter data into a spreadsheet can operate LRT.
LRT also is a no-cost application. This allows units to field BCS3 capabilities down to the lowest echelons in their organizations, which coincidently are first-line data-entry personnel. Moreover, the LRT contains predefined reports known as "roll-ups" that generate information at the click of a mouse. These reports provide leaders at all echelons with an immediate snapshot of their logistics footprint without having to transfer the data into secondary documents or presentations. Finally, the LRT can capture nondoctrinal data from supply points.
|Leaders with keen foresight who saw LRT presentations delivered by the BCS3 demonstration lab immediately saw the value of this logistics tool.
Introducing the New and Improved BCS3
Leaders with keen foresight who saw LRT presentations delivered by the BCS3 demonstration lab immediately saw the value of this logistics tool. However, earlier iterations of BCS3 had caused Soldiers to be hesitant to use the system, and major operations in Iraq had created an environment that made introducing a new management system difficult. Nevertheless, a grassroots movement of sorts developed among a few forward-thinking units and dedicated field service representatives despite these obstacles and challenges.
The journey began in late 2009 with the first fragmentary order (FRAGO) issued by the commander of the 287th Sustainment Brigade, a Kansas National Guard unit. Although the effort failed to get traction from the unit's headquarters and support staff, the 732d Combat Sustainment Support Battalion (CSSB), a Wisconsin National Guard unit, supported the FRAGO directives. Guided by its support operations officer (SPO), the 732d CSSB, located at Contingency Operating Base (COB) Adder, performed the first proof of principal in the IJOA and set the stage for everything that followed.
In December 2009, the 732d CSSB SPO invited the 36th Sustainment Brigade Sustainment Automation Support Management Office to attend a BCS3/LRT commanders' demonstration.
Soon after replacing the 287th Sustainment Brigade at COB Adder, the 36th Sustainment Brigade, a Texas National Guard unit, discovered that LOGSTARs were susceptible to error because authorized fields were not locked and, therefore, permitted flagrant data corruption. The 732d CSSB introduced the idea of using LRT and found the 36th Sustainment Brigade willing to transition from using LOGSTARs to LRT. With both units on board, their efforts to promote BCS3/LRT turned to U.S. Division–South (USD–S), the 1st Infantry Division, out of Fort Riley, Kansas.
In January 2010, the 36th Sustainment Brigade hosted the USD–S Logistics Conference, which was attended by logisticians from its subordinate units and the 1st Infantry Division. The centerpiece of the conference was the process for implementing LRT. The subordinate units were in agreement, which influenced the 1st Infantry Division's decision to publish a FRAGO in February 2010 that implemented LRT throughout all of USD–S.
This was the first time that both a maneuver unit and a sustainment unit used LRT to report commodities. Their united effort should have led the way for the remainder of the IJOA to adopt LRT as the system of choice. However, without the sustainment command adopting LRT, the IJOA continued to use LOGSTARs to report commodities.
We Did Not Know Any Better
PM–BCS3 started fielding the Dell M6300 for the upgraded BCS3 to Reserve units in 2008. All Reserve units in rotation for deployment had priority to receive the BCS3 workstations. The 103d ESC, a Reserve unit out of Iowa, received its BCS3 workstations late in 2008, complete with support by field service representatives and the extra bonus of sending two Soldiers to Tapestry Solutions' 6-week administrator course.
After visiting several Army Reserve units in Iraq, the commander of the 103d ESC sought to emulate a fusion cell, found in Iraq, back at home station in Des Moines, Iowa. The 103d ESC SPO converted its area in the Reserve center into a mini-fusion cell by removing all cubicles and replacing them with tables, and the G–6 built an "exercise net" to allow the BCS3 operators to train on their machines.
The 103d ESC continued to train Soldiers to use BCS3, constantly seeking training opportunities (such as the courses offered at Camp Dodge, Iowa) and holding a comprehensive training event that was centered on BCS3 use. In fact, an internal competition emerged among several sections within the ESC to test the system under a variety of different circumstances.
During the 103d's predeployment training events, planners incorporated BCS3 use by injecting simulated events into training during the command post exercise–sustainment (CPX–S) at Fort Lee, Virginia, and the mission rehearsal exercise (MRX) at Fort Hood, Texas. Both exercises challenged and prepared the ESC for its mission in Iraq. For the MRX, the 103d ESC and the 224th Sustainment Brigade, a California National Guard unit, participated in Unified Endeavor 11–1. Unified Endeavor 11–1 was part of a larger exercise networked with the 4th Infantry Division at Fort Carson, Colorado (also conducting its MRX), and the XVIII Airborne Corps at Fort Bragg, North Carolina (acting as the U.S. Forces-Iraq higher command).
The Army Combined Arms Support Command (CASCOM) commander challenged the 103d ESC commander to finally implement BCS3 in the IJOA. To facilitate implementation, CASCOM sent a TCM representative to Fort Hood. While the 103d was going through the MRX, the TCM representative worked with the SPO redistribution officer-in-charge on preliminary planning to implement BCS3 in the IJOA. In fact, the TCM representative traveled to Iraq and introduced BCS3 to the outgoing unit, the 13th ESC, and acted as the BCS3 knowledge continuity subject-matter expert while the 103d ESC completed its deployment preparations.
Proof of Principle
The 13th ESC transferred its authority to the 103d ESC on 1 July 2010. With the 103d at the sustainment helm for the IJOA, and following the guidance of the ESC commander, the SPO sought to implement BCS3 to manage commodities. The plan was to field the LRT as a replacement to LOGSTAR and provide units with a familiar interface while tapping into the dynamic and near-real-time reporting capability of the BCS3 architecture.
As the ESC BCS3 program manager, I met with the BCS3 team in late July 2010 to discuss the im-plementation plan and proposed glide path. Emphasis and theater support to field BCS3 came from the U.S. Forces–Iraq (USF–I) J–4 logistics automation officer, who had received a directive from the USF–I J–4 to either implement BCS3 and its application variant, the LRT, or descope the theater contract by returning the field service representatives to the continental United States. The timeline to conduct a proof of principle and present a decision point rested on two major factors: the USF–I J–4's redeployment and the J–8's fiscal deadline. Therefore, the final decision point was due on 15 October.
I chaired a meeting on 1 August 2010 to set in motion the efforts to implement BCS3. In order to convert a "critical" population, we placed the emphasis on promoting LRT because it was an easier application to learn and adapt for use in managing commodities. The commodities we chose to manage with LRT were classes I, IIIB, and V because all three used LOGSTAR as a management tool. The plan involved a grassroots movement that would compel all the commands in the IJOA to adopt LRT or risk losing sustainment visibility and support.
A critical component for success was the involvement and support of senior leaders. Momentum gained by the team translated into support, first by the ESC SPO and then by the ESC commanding general. The final proof-of-principle test began on 15 September and culminated on 12 October. The primary players in the test were the 103d ESC, the 3d Sustainment Brigade, and the 224th Sustainment Brigade.
To facilitate LRT implementation, the sustainment brigades, emulating the ESC, designated their own PM's. The 224th Sustainment Brigade had the benefit of operating in a BCS3-friendly environment because of USD–S's LRT implementation 9 months earlier. Although wary of adopting a new reporting tool, the 3d Sustainment Brigade immediately saw the benefit of using LRT. Ultimately, the findings indicated that the system was reliable, effective, and efficient. In fact, units originally opposed to BCS3 came to appreciate, and even like, LRT.
The ESC's successful proof-of-principle testing provided the required fidelity for USF–I to retain funding for the BCS3 program and to direct a further test encompassing all of the IJOA. The remaining zones (Center and North), in anticipation of USF–I's FRAGO directing LRT testing, published their implementation FRAGOs. On 15 December, management for IJOA class I, IIIB, and V commodities transitioned from LOGSTAR to LRT.
Resolving set-up problems. Fielding the LRT was more than merely installing the client on Soldiers' workstations or setting up a local BCS3 system at each battalion or above. Before publishing the ESC proof-of-principle FRAGO, the ESC BCS3 project team spent weeks ensuring that all ESC subordinates had either BCS3 or LRT and that all network connectivity issues, including appropriate firewall exemptions, were resolved. LRT lent itself to simple over-the-shoulder instructions and quick refresher training because of its similarity to common spreadsheets, making it easy to transition from LOGSTAR to LRT.
Roll-up reports. Out of necessity, Soldiers had created third-party applications to extract data from LOGSTAR in order to forecast and retain historical data. Contained within LRT are premade reports known as roll-ups. Since these roll-ups displayed data differently than the third-party applications, it took a great deal of effort to shift users' and managers' fundamental thought processes and get them to accept the new layout. Even so, LRT could not produce certain critical roll-ups, such as class IIIB bag data. PM–BCS3 must incorporate these fields and reports into LRT; otherwise, units will have to develop additional customized reports.
In the short term, because of the lengthy process needed to effect change in BCS3/LRT, users are compelled to use third-party applications. Fortunately, several of these applications (such as Microsoft Access) feed off spreadsheets and LRT can export to Microsoft Excel, so the fix was a simple procedure of reformatting the import process.
Reporting delay. Inherent to LOGSTAR was a reporting delay. LOGSTAR created a natural delay when units added data and emailed them to their next higher echelons. This allowed each echelon to verify the data, and if it discovered any inaccuracies, it could request clarification or correction from the reporting echelon. LRT operates in near-real time. Data entered at the data input echelon immediately populate everywhere. Each echelon had little or no time to verify its data before several higher echelons viewed them. Therefore, commodity managers established artificial time hacks that mimicked the time delay inherent in LOGSTAR. This provided a level of comfort for each echelon to verify its information long before the higher command received it.
Unit task organization. A critical lesson learned was the management of the unit task organization (UTO). BCS3/LRT operates a customized database, and for every unit identification code reported within the system, one can view that unit's data. The UTO acts like a filter (and to some degree the location within the hierarchy) that permits the customization of different views based on requirements. However, although the data are in the system, if the UTO does not have the correct unit identification codes, that echelon cannot see the data. The UTO requires some maintenance, but no more maintenance than the time it takes to check a vehicle's oil.
The proof of principle determined that the process works best if the following are instituted: assign an operator to each BCS3 workstation, establish a UTO manager for every unit with a BCS3 workstation, and initiate all changes to the UTO from the lowest echelon possible. The bottom-up method of UTO management was the most accurate and easiest to manage. The additional roles created by necessity simplified the process and provided a single point of contact for any UTO issue. The UTO manager is an additional duty, much like the safety officer or food-service inspection noncommissioned officer. The UTO manager can be a BCS3 operator or in another staff section, like G/S–3 or G/S–6.
BCS3/LRT shortcoming. Even with all the system enhancements and the development of LRT, BCS3 remains a tactical system rooted in the present. A sustainment command needs a system that operates on an operational level and can perform trend analysis and forecasting. The sustainment brigade's system needs to live in both the past and the future. PM–BCS3 is looking at future enhancements to provide this capability, but to bridge the deficit, the ESC is compelled to use third-party software, such as Microsoft Access. This has the making of another potential LOGSTAR-type application, which reintroduces data corruption because of human intervention and defeats the purpose of an automated information management system.
The story of deploying BCS3 is a testament to leader involvement and staff collaboration and acceptance. It is also a caution against the legacy attitudes prevalent in the Army sustainment community. All the events described above occurred in parallel and culminated in the efforts of a few units and individuals who were determined to truly manage their logistics.
BCS3 provides operational flexibility and creates a commonality of information that becomes a combat multiplier. Units no longer have to manage or customize commercial off-the-shelf systems and relearn the unique attributes of all iterations of a custom application found in a theater. With BCS3, units can train during their reset phase and incorporate the system during their predeployment activities. Then, when units hit the ground, they will fall in on a common system with which they are familiar, which increases the effectiveness of the transfer of authority and over-all logistics management.