The Next Generation: Cataloging Nonstandard Items

By LeQuan M. HyltonMarch 13, 2013

Army Sustainment Magazine
(Photo Credit: U.S. Army) VIEW ORIGINAL

The next generation of cataloging nonstandard items is here. Since late 2002, the central catalog management of nonstandard, noncataloged items has been achieved through the Standard Study Number-Line Item Number Automated Management and Integrating System (SLAMIS). Transforming to enterprise resource planning (ERP) using SAP [Systems, Applications, and Products in Data Processing] software requires the existing SLAMIS process to undergo adjustments to facilitate the cataloging of nonstandard items in the ERP environment. This process offers enhanced visibility with reporting and property accountability to support the Army's logistics systems and policies.

This article chronicles the next-generation systems processes for cataloging nonstandard items, imminent data cleansing, migration, and conversion as it relates to nonstandard, noncataloged items during the fielding of Global Combat Support System-Army (GCSS-Army).

It is important to note that GCSS-Army fielding and related actions are delivered in waves. Wave I will replace the Standard Army Retail Supply System-1 (SARSS-1) and associated tactical logistics finance systems. Wave II will replace the Standard Army Maintenance System-Enhanced and Property Book Unit Supply Enhanced.

THE GCSS-ARMY NONSTANDARD PROCESS

In the Army's ERP environment, a nonstandard, noncataloged item is defined as an item not found in the Army Enterprise System Integration Program (AESIP) material master catalog or in the GCSS-Army catalog. For GCSS-Army, the authoritative data source for cataloging materiel is AESIP. Presently, the Logistics Support Activity (LOGSA) Material Master Research Cell (MMRC) is the authoritative data source for cataloging materiel in AESIP.

At the unit level, handling nonstandard, noncataloged materiel in GCSS-Army requires using the GCSS-Army transaction code "ZNONSTD." Through this process, GCSS-Army allows users (based on roles and permissions) to manage nonstandard, noncataloged materiel at the tactical level and communicate the catalog request to the national level and other appropriate trading partners as part of the ZNONSTD process.

Specifically, the nonstandard materiel process allows users to create nonstandard materiel records and complete system processes such as ordering, receiving, and issuing items. The ZNONSTD process also allows users to capture items purchased with credit cards or ordered through the local contracting office and facilitate turn-ins.

The ZNONSTD process has eight mandatory fields: part number, cage code, force element (previously known as the unit identification code), description of item requested, federal supply classification (FSC), supply categories of materiel code (SCMC), measurement quantity, and measurement unit and price. These fields should be completed to the user's best knowledge to ensure the MMRC can locate the remaining data elements.

DATA CLEANSING FOR GCSS-ARMY FIELDING

The data cleansing process extends beyond uncovering nonstandard, noncataloged items to other areas of data cleansing. For the purposes of this article, the process will be limited to unit conversion and fielding of GCSS-Army as it relates to cataloging nonstandard items.

An initial formal analysis is conducted 120 days (or later) from the unit's go-live date to discover problems with the Standard Army Management Information System (STAMIS) data used to create GCSS-Army load files. To further cleanse the unit data, subsequent analyses are performed 90 days, 60 days, 30 days, and 15 days before the go-live date.

InfoSphere and the GCSS-Army Data Staging Utility (DSU) are the two tools used to evaluate the content and quality of unit data and to prepare content for GCSS-Army conversion and fielding. InfoSphere is the LOGSA tool used by the Enterprise Data Management Office (EDMO) to compare unit data to business rules established by LOGSA, the Combined Arms Support Command, Program Management Office AESIP, and others. The results of these inputs produce error reports and suggest remedies for the errors.

DSU is an automated tool designed to validate and stage STAMIS data based on business rules and create load files for GCSS-Army conversion and migration. It can also be used to help data owners to identify and clean up data errors in their source systems before loading data into GCSS-Army. The systems work together to thoroughly prepare bridging system data for migration and conversion to GCSS-Army.

One hundred and twenty days before bridging system use is terminated, the GCSS-Army team will provide the unit with procedures to discover, validate, and correct data in bridging systems. Units can use the SLAMIS procedure for any items not in the enterprise catalog before the EDMO or GCSS-Army teams arrive for fielding. The Army Enterprise Materiel Master Portal is another process that will be available in the near future. This process, currently under development by AESIP, will allow users to communicate directly with AESIP for nonstandard, noncataloged items and is most advantageous for logistics system users that are not GCSS-Army users. Eventually, the SLAMIS process will be subsumed by the AESIP portal.

Although units are responsible for correcting erroneous data, both the EDMO and the GCSS-Army fielding team will assist them in the correction process. Completing these actions before the GCSS-Army team arrives and begins producing unit STAMIS exception reports will greatly reduce the data cleansing work a unit has to do before being migrated into GCSS-Army.

Conversions of these bridging systems are divided between the fielding waves of GCSS-Army. For Wave I fielding, the EDMO and the GCSS-Army fielding team will obtain SARSS-1 data for all open orders and corresponding financial data from accounting systems, including the Standard Operations Maintenance and Research Development System (SOMARDS), the Standard Finance System (STANFINS), and the General Fund Enterprise Business System (GFEBS).

Specifically, a validation of "due-in from referral transaction" and "due-in from referral reconciliation of orders" in SARSS will be used to determine if an item is valid and open. Using InfoSphere, the process will begin with the EDMO obtaining the fielding unit's SARSS-1 backup files and identifying nonstandard, noncataloged items on SARSS-1 open orders or in inventory.

InfoSphere will compile a list of materiel records that violate business rules and corresponding ways to potentially correct the violations. Business rules are definitions that regulate the contents of a data field and help detect potential errors. Materiel currently not found in GCSS-Army will be reported through the GCSS-Army DSU exception reports documents as "NIIN not found in GCSS-Army Materials Check Table." These reports will be supplied to the unit by the deployment team for action by the team or unit.

The information for items to be cataloged will be sent to the GCSS-Army data team for cataloging. AESIP will receive the information from a GCSS-Army interface and will pass it to the MMRC for analysis, adjudication, and disposition. To ensure data integrity, once the MMRC decides which items need to be cataloged, those items will be sent to AESIP, which will syndicate changes to GCSS-Army, the corps theater automatic data processing center service center, and other trading partners. GCSS-Army will receive catalog updates and amend the original material master template with the new information. In addition, submissions not cataloged will be rejected and notifications will be sent to users.

GCSS-ARMY MIGRATION AND CONVERSION

The final preparation for bridging systems data will take place during a six-day period called brownout. During this timeframe, use of bridging systems will be suspended. High-priority requests will be completed using an offline manual process. Units will also be required to clear the management review file. The unit's SARSS backup files and associated SOMARDS, STANFINS, and GFEBS data will be collected by the GCSS-Army fielding team and processed through the DSU to produce load files for GCSS-Army conversion. "Drop out" reports are also produced to account for data items that could not be migrated because of business rules in SAP.

After the six-day brownout, blackout will begin. During the six-day blackout period, the load files for GCSS-Army will be reviewed and validated by the GCSS-Army fielding team and all open orders with a valid catalog record will be loaded into GCSS-Army for customer validation.

During blackout, no new orders can be entered in the system and open orders will be loaded into the GCSS-Army ZPARK process. The financials will be validated by the GCSS-Army fielding team by comparing the legacy system open orders and the orders loaded into ZPARK, which is a process similar to a shopping cart on a merchant's website; it allows a user to review and manage requests by validating the financial status and supply requests.

Final customer data validation will take place before the unit signs the letter of acceptance. After the customer data validation and the signing of the letter of acceptance, the unit will begin using GCSS-Army to process transactions.

AFTER THE GCSS-ARMY MIGRATION

Despite the intense data cleansing procedures in place, the possibility exists that some records will fail to migrate because of a nonstandard, noncataloged record from the SARSS-1 backup file and its associated accounting records having no GCSS-Army master file match. Two options have been built to overcome this situation.

The first option is that a record can be built using the GCSS-Army nonstandard process through the ZNONSTD transaction code. The second option is that the onsite GCSS-Army deployment team can generate a help desk ticket requesting that GCSS-Army build the material master template based on the recorded data. Either option requires part number, cage code, force element, description of item requested, FSC, SCMC, measuring quantity, and measurement unit and price.

As the Army converts logistics functions to GCSS-Army, the existing SLAMIS process must also transform to accommodate the ERP environment of GCSS-Army. As GCSS-Army is fielded to units, it is imperative that Soldiers understand the strategies for data cleansing, migration, conversion, and fielding. This is especially the case in the non-standard, noncataloged items.

To better assist the fielding of GCSS-Army, it is important for units, and especially unit supply and property book officers, to properly catalog any nonstandard items using the existing SLAMIS process now, before the EDMO and the GCSS-Army deployment team arrive. This will be a major enabler for the success of data cleansing, migration, and conversion for GCSS-Army fielding.

___________________________________________________________________________________________

LeQuan M. Hylton is a logistics management specialist and the assistant data team leader for the Global Combat Support System-Army functional integrated concept team at the Combined Arms Support Command. He holds a B.S. degree in business management with a concentration in human resources from Virginia State University and an M.B.A. degree from Averett University, and he is a Ph.D. student in public policy and administration at Virginia Commonwealth University. He is also a captain in the Medical Service Corps in the Army Reserve.

___________________________________________________________________________________________

This article was published in the March-April 2013 issue of Army Sustainment Magazine.

Related Links:

Browse Army Sustainment Magazine

Download This Issue

Print This Article

Army Sustainment Magazine Archives

Army Sustainment Magazine News