DoDAAD Reengineering 2.0 Workflow

1. DoDAAD Reengineering 2.0 Workflow August 23, 2011

2. Overview • Background • Workflow Concept/Benefits • Notional POA&M • Draft Functional Requirements

3. Background • DUSD/L&MR Task to DLA: Single Enterprise DODAAD System • DAAS Application developed to meet enterprise needs • USAF & USA independently developed web systems with workflow to: • Distribute address data maintenance workload to ultimate customer • Manage and control the review and approval process • Issues with USA and USAF applications include data accuracy/timeliness, lack of important data fields, lack of standard edits, ongoing maintenance costs, rejected transactions, database synchronization (USA) • DoDAAD PRC 2010 supported exploring workflow for DAAS web application • USMC subsequently identified USMC requirement for workflow

4. Workflow: What is it? • Workflow is a known enterprise requirement • Army, Air Force, Marine Corps • Defense Logistics Agency • General Services Administration • Workflow review and approval steps controlled by Component • CSPs set up and control the review and approval schema • New Component unique data may be accommodated • Initial data maintenance entries by DODAAC owner • Reviewers determine legitimacy of need & DODAAC usage • Feedback and suspense tracking throughout process • All existing validation edits/rules applied • CSPs have final approval prior to database update • Use of multi-step review & approval process is optional

5. Workflow Rationale/Benefits • Fully meets DUSD/L&MR goals & lowers cost for DoD • Universal requirement across the enterprise • Improved data quality – One system, same edits for everyone • Workload is distributed to the address owner • Authoritative data source (customer) enters initial data • Eliminates errors from reentering initiator data • Reduces CSP work while maintaining the CSP approval control • Automated suspense and tracking ensures timely action • Information requirements easier to collect and maintain • Records initial requestor for authentication/history • Eliminates problems associated with multiple applications

6. As-is Army and Air Force DODAAD Workflow Management and Control Process Step 1 Step 2 Step3 Step 4 Reviews Rejects Modifies Approves Provides Feedback Forwards Reviews Rejects Modifies Approves Provides Feedback Forwards Reviews Rejects Modifies Feedback Final Approval Component Web Application and DODAAD Database Copy Originates Request DODAAD Change Army Network Station Army CSP LOGSA/AESIP Army/AESIP Unit/Activity Air Force/ AFMC MAJCOM Monitor Control Office AF CSP AFMC Customer DAAS Master DODAAD Database Data Base Replication of Updates to DAAS Data Replication To Component Data Base Copies (AESIP only accepts Non Army Changes)

7. To-Be Workflow Process This review and modification process within the oval may be cycled through more than once depending on the number of review levels That the Component CSP determines are in Their respective governance process. Rejected (with reason for rejection) Originates Request DODAAD Change Staging Area pending pickup by Components Component Review and Modification Reviews Modifies Final Approval Accepted Accept or Reject Accept or Reject Rejected (with reason for rejection) DAAS Master DODAAD Database Accepted

8. Notional Plan of Action & Milestones • Develop concept and high level requirements document Complete • Gather enterprise reqmtsfrom Component Central Service Points (CSP)s 8/15/2011 • Socialize composite requirements with DODAAD PRC 8/23/2011 • Obtain funding & place on existing contract vehicle 9/30/2011 • Preliminary Design Review (PDR) with Component CSPs 10/15/2011 • Detailed Functional Requirements Document (FRD) 12/15/2011 • Critical Design Review (CDR) with DLA Transaction Services 1/15/2012 • DLA Transaction Services develop System Change Request (SCR) 1/31/2012 • DLA Transaction Services change application code IAW FRD/SCR 6/15/2012 • Test application/correct as needed/retest 8/15/2012 • Update DLMS Manual Chapter 2, user guide (SOP), and Training 8/15/2012 • Conduct/complete user training 9/15/2012 • Deploy into production 10/15/2012

9. Draft Functional Description • Apply access controls to allow customers, designated by the Component CSP, to initiate actions through the DODAAD Enterprise Web maintenance application to maintain their DODAACs. • Present a Web input page to the designated customers that allows them to enter proposed additions, changes, or deletions along with their email address so they may be notified when the DoDAAC is approved or rejected. Changes would be treated as draft proposals and would not cause actual changes to the authoritative database at this point. • Maintain a review and approval profile for each customer. Profile shall allow for establishment of as many as three levels of review starting with the initiation by the source customer, a Level 1 review and approval, a Level 2 review and approval and lastly the final CSP review and approval. • The Component review and approval profile will identify the number of review levels, review organizations, review and approval sequence. • Each level of review will contain: User id, email address and telephone number of the person authorized to approve the level and advance it to the next phase.

10. Draft Functional Description Cont. • Each DODAAC will be tied to the Service review profile table. • Each review level in the profile will identify the time in hours allowed for review at that level. Emails will be sent to alert the reviewers that there is a DODAAC requiring review and completing a level will send a email to alert the next level a review and approval is required. • The application will maintain in-process actions in suspense and send automatic follow-ups when the suspense time has been exceeded and no action has taken place. • The application will maintain metrics on reviewer responsiveness. • The application will allow each review level to approve, disapprove via a list of drop-down disapproval reasons or to modify a lower level’s input and the submitter will be advised via email that an action has occurred to their requested change which can be viewed by logging into the Web application containing the database of in-process changes.

11. Draft Functional Description Cont. • When the CSP approves the change it will immediately move from an in-process change condition to the authoritative DODAAD database. This event will trigger an email to notify the original requestor that the DODAAC is approved and ready to use. • If the CSP rejects the DODAAC, an email notification will be sent to the original requestor that the DODAAC has not been rejected and the reason for the rejection. • The profile list will be accessible and the maintainable via the Web application by only the CSP. • CSP Responsibilities Include: • Providing the initial review and approval profile list and maintaining it as it changes. • Providing the data requirements of the data that the customer is required to provide, unique business rules to be applied and any data element Meta data requirements unique to that Component.