CREW: General Services Administration: Regarding E-Gov Travel: 1/21/2010 - Ets r2 v1 Final Part 2 Redacted

eTravel Services
Volume 1 – Technical Approach
1.0 TECHNICAL APPROACH - NARRATIVE (RFP REFERENCE E.3.4.2.1; E.6.1)
The Federal Government’s electronic travel (eTravel) initiative marks a dramatic evolution in the way travelers, approving
officials, administrators, and all other Government personnel involved in the day-to-day business of travel and expense man-
agement procure and fulfill their unique requirements and objectives. Carlson applauds that vision and is exceptionally well
positioned to affirmatively and effectively accomplish the vision and goals of the Government’s eTravel Service (eTS) pro-
gram.
To satisfy the Government eTravel service requirements, Carlson has assembled and coordinated the resources and capabili-
ties of a carefully selected core of information technology, travel services, and customer service industry leaders. The Team
brings the technical capability, management resources, and past performance experience which, to share the Government’s
view, is critically important to the success of the eTS contract.
Our proposed Team consists of the prime contractor, CW Government Travel (hereinafter referred to as Carlson). We are the
leader in Government-dedicated travel management services, providing reservations, ticketing, and data management ser-
vices to Federal and Military personnel for over 15 years. Under the leadership and vision of the division’s president Erma
Spell, we developed a product called E2 Solutions. E2 is a suite of products and services designed specifically to allow Gov-
ernment organizations to effectively and efficiently manage travel policy, travel fulfillment and expense management. It is a
web-based application that automates, streamlines and integrates the interdependent components of the travel life cycle and
serves as the backbone of our eTS solution. Our solution consisting of GSA’s required and enhanced eTS products and ser-
vices will be referred to throughout the rest of the proposal and its volumes as the Carlson eTS Solution.
Complementing our capability, we are proposing nine exceptionally well qualified and experienced first tier subcontractors.
Heading the list, leveraging the technical, marketing, and financial resources of our parent company Carlson Companies, Inc.
(CCI), we are proposing two of CCI’s component parts as our first tier subcontractors – Carlson Shared Services (CSS) and
Carlson Marketing Group (CMG). CCI employs a shared services methodology that covers common information technology,
human resource, finance, and procurement processes. Specifically, CSS and CMG will be providing the following services:
CSS will provide application hosting services, data warehouse services, help desk support, technical design, mainte-
nance, and refreshment support; and the capabilities of 1,000 Carlson IT employees, providing world-class processes
and support to the eTS solution ensuring the effective use of critical resources.
CMG will provide marketing services, user acceptance and growth management strategies, change management support,
and training services.
Our other seven proposed first-tier subcontractors are no less impressive in terms of proven Government technology experi-
ence and capability and will be providing the following services:
AT&T will provide the FirstGov.gov eTravel portal interface, standard implementation services, and DSL connectivity
Corio, a well known information technology (IT) integration company, will provide redundant data center hosting facili-
ties
SNVC, a leader in the IT security issues, will provide Public Key Infrastructure (PKI) and data protection services and
support
ClearNova, an industry leader in IT innovation and refreshment solutions, will provide application coding and develop-
ment support
ImageTag, Inc. will provide digital receipt management services
Gradkell will provide digital signature software and capability
TRX, the premier Government online reservations booking tool, will provide our primary online selfbooking engine
(GetThere is our secondary online booking tool).
Throughout the proposal, this outstanding partnership will be (unless otherwise noted) referred to as the Carlson eGov Solu-
tions Team (also may be referred as our Carlson and/or Team). The Carlson eGov Solutions Team welcomes the opportunity
to respond to the GSA’s RFP to provide professional eTravel Services that meet and exceed critical Government require-
ments including but not limited to:
Facilitating the travel process for the Federal traveler
Integrating
Solutions with Use or disclosure of data contained on this sheet is subject to the restriction on the title page of this proposal.
Service Solicitation Number FBGT-CD-030001-N
Round 2, Volume 1, Page 1
eTravel Services
Ensuring prompt reimbursement of travel expenses to the Federal traveler and travel suppliers
Leveraging the Government’s buying power and significantly reducing the cost of travel management
Improving visibility into travel management processes for continued improvement and cost savings.
Carlson has thoroughly reviewed all sections of the RFP and is prepared to fully comply with all requirements. We are ex-
cited about the opportunity to demonstrate our team’s value in exceeding your requirements as we have done for customers
outlined in our past performance. On the following pages, we present our approach and methodologies to meeting and ex-
ceeding the technical requirements and objectives as identified within the solicitation’s Statement of Objectives (SOO).
Within this section, we discuss our technical approach to: (1) Voluntary Product Accessibility Templates, (2) Final
CONOPS/Use Cases, (3) Performance Based Work Statement/Work Breakdown Structure, (4) Security Approach, and (5)
Data Management Approach.
The Carlson eGov Solutions Team consists of partners who have proven experience in supplying integrated eCommerce ser-
vices including the development, management, and life cycle maintenance of commercial and Government travel,
telecommunication, financial, and IT systems. Through unmatched experience, Carlson fully understands that the best way
to serve our customers is to combine expert service with the right solution. This fundamental philosophy applies to every
client and to every project, no matter its size or complexity.
1.1 Voluntary Product Accessibility Templates (RFP Reference C.6.6; E.3.4.2.1.2, Item 1)
The Federal Government considers universal accessibility to information a priority for all its employees and external custom-
ers, including individuals with disabilities. Carlson applauds and shares that view and commitment. Using Section 508 of the
Rehabilitation Act of 1973 (as amended), FAR 39.203(c), and the accessibility standards of 36 CFR 1194 as our primary
guidelines, Carlson ensures the accessibility of the Carlson eTS Solution programs and services, specifically in the use of and
applicability to accessible electronic and information technology for all users regardless of disabilities. Carlson maintains the
Government issued manual, "Requirements for Accessible Software Design," and has used it in the development our eTS
product to comply with the provisions of the above stated clause.
Carlson commits to the following:
Delivering to or developed for the Government all software that meets all applicable requirements of the manual "Re-
quirements for Accessible Software Design."
Any software/product enhancements or modifications made under this contract for use by Government employees or
external customers will be subject to the requirements of the clauses identified above, regardless of where or how the
software was first developed.
Should future technologies provide solutions that are not envisioned in or consistent with the provisions of the manual
"Requirements for Accessible Software Design" and if it furthers a public interest of the Government (while not signifi-
cantly impairing the Government’s ability to ensure accessibility of its programs and activities to all its employees and
external customers, including individuals with disabilities), Carlson will request a waiver by notifying contracting offi-
cer in writing, listing the specific accessibility requirements that would not be met and explaining how the accessibility
of a particular feature can be achieved by alternative means or why it is not feasible to make a feature of the software ac-
cessible.
The Carlson eTS Solution fully complies with the Government’s requirements that the acquisition and management of Fed-
eral Information Processing (FIP) resources be conducted in a manner that ensures access to computer and
telecommunications products and services by all individuals, both federal employees and the public sector, including indi-
viduals with disabilities. Carlson ensures ensure that FIP resources are equally provided to all individuals, including
individuals with disabilities.
As required by the solicitation, Carlson has completed the Voluntary Product Accessibility Templates (VPAT) and included
it in our proposal in Appendix C.
Integrating
eTravel Services
1.2 Final CONOPS/Use Cases (RFP Reference E.3.4.2.1.2, Item 2; E.6.1 Factor 2)
In this section, Carlson includes a detailed discussion of our approach to meeting the basic eTS requirements as well as de-
scribing in detail the user roles, account accesses, and use cases and how the Carlson eTS Solution provides an integrated
end-to-end travel management service to the Federal Government and in the Government travel domain.
Our discussion includes:
Types of Travel eTS Services
Basic Capabilities and Characteristics Technology Capabilities and Characteristics
Policy Knowledge and Compliance User Roles
Use Cases Use Case Documentation
1.2.1 Types of Travel (RFP Reference C.3.2.1)
The Carlson eTS Solutions implements all the types of travel as specified in paragraph 3.1, Chapter 301 of the FTR. Travel-
ers are provided an automated workflow tool (E2 Solutions) to develop and manage travel authorizations and vouchers
supporting the following types of travel:
1.2.1.1 BUSINESS
Domestic and international temporary duty travel Local travel
Long term TDY and local travel Invitational travel
1.2.1.2 NON-FEDERALLY SPONSORED TRAVEL (RFP REFERENCE C.6.3.12)
The Carlson eTS Solution
Provides the ability to reflect funds received from non-Federal sources in relation to specific travel authorizations, indi-
cating amounts and entitlements to be applied to the non-Federal funds. Post-travel, Carlson eTS Solution monitors
expenses claimed applicable to the non-Federal funds versus maximum allowance defined during pre-travel authoriza-
tion process, providing alerts to Federal Travel Approver.
Has the capability to authorize and report payments from multiple sources (to include non-federal sources) of payments
and payments in kind. Payments may be divided up by organization and allocated and accounted for accordingly. This
feature functionality allows the payments to be allocated and accounted for in accordance with FTC Chapter 304.
Provides conditional routing capability allowing customized routing and approvals based upon agency defined criteria,
including non-federally sponsored travel.
Allows for multiple funding sources, including the clear definition of specific travel expenses to be paid by the traveler’s
agency with the remaining be paid by the sponsoring organization. This functionality is provided within both the Au-
thorization and Voucher modules.
If actual amounts are not known, the Carlson eTS Solution provides the ability to display estimated cost used for obliga-
tion purposes. Post-travel, Carlson eTS Solution monitors expenses claimed applicable to the non-federal funds versus
maximum allowances defined during the pre-travel authorization process.
1.2.1.3 OTHER – LEISURE. (RFP REFERENCE C.6.3.13)
Carlson will offer leisure in conjunction of official/business travel to Federal Agency travelers. Travelers will be provided
the ability to communicate information through the eTS to the TMC in regards to leisure travel in conjunction with official
travel. After booking the official travel, the traveler can include notes in the traveler remarks portion of the travel authoriza-
tion regarding their requirements for leisure travel. The resulting record will be passed to the TMC and flagged for review
by an agent. The TMC will then follow the Agency guidelines for issuing leisure in conjunction transactions. The Carlson
eTS Solution contains procedures that prevent a traveler from claiming leisure travel expenses on official business travel. All
leisure travel reservations and booking will require a traveler individual credit card.
1.2.2 eTS Services (RFP Reference C.3.3.1)
Carlson eGov Solutions Team’s technical approach to the eTS solicitation supports the basic eTravel service framework that
provides but not limited to:
Integrating
eTravel Services
Delivery of a workflow and eTravel portal enabled eTS via a web-based, self-service environment
Services and support capabilities required to host and deploy the Carlson eTS Solution to Federal travelers
eTS services supplemented with phone, fax, person-to-person, email, and instant messaging services
Information technology services and support
Federal travel process and travel management expertise
Web-based/online booking engine reservation service
Implementation planning and support for Federal Agencies
Training for all eTS user roles
Customer support.
The Carlson eGov Solutions Team’s technical approach is best summarized as effectively using technology to deliver tools
that enable diverse user roles to productively interact with travel and expense management procedures.
1.2.3 Basic Capabilities & Characteristics (RFP Reference C.6.1.2)
The Carlson eTS Solution embeds all of the Federal travel procedures, requirements and objectives as identified in the solici-
tation. It provides a web-based common travel management service available to all authorized Government travelers and
administrators. The Carlson eTS Solution fully supports all required characteristics/capabilities identified in the solicitation
to include:
Requirement Carlson eTS
Solution
Supports
Web-based, end-to-end travel management environment
Travel planning and cost estimating, travel authorization, booking of travel reservations and travel
arrangements, filing, processing, and approval of official travel claims, travel reporting and business
intelligence; travel-related data exchange
Web-based deliveries of services and data exchange with access and input possible by all users and
approving officials
Central management of Federal travel procedures through a common, configurable, customer-centric,
self-service, web-based environment
Real-time updates and allows travel policy to be administered with or without exceptions
Access to and control of all Government preferred travel suppliers and negotiated rates
Maintains the order of precedence for executing travel steps and adequate separation of duties
Controls to prevent the creation of duplicate travel documents
Audit trail capability on historical data that identifies input, correction, amendment, cancellation and
approval
Standard data input/output supporting the exchange of data with agency business systems
Our Team will work and coordinate with Government subject matter experts and other travel partners
to integrate and deploy the eTS
Government ownership all federal data generated by and/or stored in the eTS
Update capability without the need for programming of Government policies, business rules, vendor
contract parameters, permissions, and profiles
The Carlson eTS Solution fully supports all objectives identified in the solicitation to include:
Carlson eTS
Objective Solution
Capable
Integrating
eTravel Services
Carlson eTS
Objective Solution
Capable
Common, streamlined travel management services available Government-wide that automates and
fully integrates Federal travel management functions
Common, consolidated travel process at a Government-wide level which is configurable at the de-
partment, agency, and subordinate organization levels within the limits allowed by the applicable
travel regulations
Consistent, web-based, self-service environment with an intuitive graphical user interface and suffi-
cient system prompts, clearly understandable dialog boxes, and informative messages to guide users
through logical, sequential processes and collect all necessary information within all functionalities
and modules
Travel policy web-based administration with configurable business rules for all applicable functional-
ities
Automated routing, workflow, messaging, and notifications
Comment fields and local fields within all functionalities to support organization- and agency-specific
business processes and audit requirements
Support the use of personal charge/credit cards
Use appropriate commercial standards wherever possible to streamline the acquisition, enhance inter-
operability, and reduce costs provided that all mandatory requirements stated herein are met or
exceeded
Establishment of Federal eTravel standards, incorporating appropriate commercial and government
best practices into their eTS solutions
Support for wireless and personal digital assistant (PDA) devices.
Policy Knowledge and Compliance (RFP Reference C.6.2)
1.2.4 Technology Capabilities & Characteristics (RFP Reference C.6.4.1; 6.4.2)
1.2.4.1 FEDERAL ENTERPRISE ARCHITECTURE
The Carlson eTS Solution is developed based on standards established by the FEA PMO. Carlson monitors the FEA PMO
web site to stay abreast of technology standards (BRM and DRM) and to leverage the same to manage and enhance the Carl-
son eTS Solution. In addition, Carlson leverages industry best practices and technology expertise to enhance the Carlson eTS
Solution.
1.2.4.2 PORTAL FUNCTIONALITY

The Carlson eTS Solution fully integrates portal functionality into the solution; the portal is accessed via one URL that can
also be referenced via the FirstGov Portal. The J2EE developed portal offers efficient one-stop access to all common travel
and expense management activities utilizing single sign-on security capabilities for functional access. Contracting Agencies
will have the flexibility to customize portal functionality during their implementation of the Carlson eTS Solution.
1.2.4.3 OPERATING PLATFORM

The Carlson eTS Solution is platform independent and is certified to operate on Internet Explorer 5.5 and higher or Netscape
6.0 and higher. Carlson will certify Carlson eTS Solution operations on other browser technologies or previous versions of
Internet Explorer and Netscape as requested by contracting agencies. As part of Carlson’s technology refreshment, future
browser versions will be certified as necessary.
1.2.4.4 BROWSER TECHNOLOGY

The Carlson eTS Solution is designed to only require industry standard browser technology; no other client-side application
software is required. To manage travel sessions and ensure application performance, client-side JavaScript will be used for
Integrating
eTravel Services
web form validation and session cookies will be used to store session data but will not remain resident on a user’s work-
station. Other industry standard signed plug-ins such as Flash may be used in online training programs.
1.2.4.5 ARCHITECTURE
The Carlson eTS Solution is based on a standard J2EE architecture that provides complete horizontal capacity scalability.
This architecture is expected to scale to support more than 10,000 users without requiring any architecture redesign or devel-
opment. The entire system will be continuously monitored for performance and capacity during agency adoption,
implementation, and ongoing operations.
1.2.4.6 DATA EXCHANGE

The Carlson eTS Solution provides a common data exchange and EAI (Enterprise Application Integration) environment de-
signed to integrate all required interfaces necessary to implement an end-to-end solution including support and management
of real-time, near real-time, and batch communications through a variety of Government and industry standard transmission
formats. The EAI environment provides a common point and management mechanism to manage all data exchange and ap-
plication integration points simplifying the management and the time and development effort required to complete an
interface.
The solution will implement data exchange activities using XML messaging standards (XML, XSLT, Schemas) and web
services standards (SOAP, WSDL, UDDI) whenever possible. Messaging capabilities are enhanced by using both incoming
and outgoing JMS (Java Messaging Service) message queuing. EDI support is enabled for integration into existing EDI
partners or suppliers.
The Batch capabilities will implement Secure FTP and Secure Mail interfaces for batch exchanges. It will accept legacy data
formats and perform required transformations to make the data meaningful.
1.2.5 Policy Knowledge and Compliance (RFP Reference C.6.2)
Policy guidance and travel system requirements are key drivers in the design and development of the functional architecture
of the Carlson eTS Solution. Carlson business travel analysts that are “experts” in interpreting Federal travel policy and en-
suring FTR policy requirements are embedded in the Carlson eTS Solution.
1.2.5.1 FEDERAL TRAVEL REGULATIONS AND OTHER APPLICABLE REGULATIONS (RFP REFERENCE C.6.2.1.1)
Regulatory guidance provided by the FTR which governs travel and transportation allowances for Federal civilian employees
and others authorized to travel at Government expense is embedded in the Carlson eTS Solution application governing users
in all phases of the travel process from pre-travel authorizations through post-travel reimbursements. Exceptions to the FTR
are identified and presented to approving officials, as appropriate, to assure regulatory compliance.
1.2.5.2 FOREIGN SERVICE TDY TRAVEL (AND OTHER) -6 FAM VOLUME 100 REGULATIONS (RFP REFERENCE C.6.2.1.2)
The Carlson eTS Solution incorporates 6 FAM Volume 100 regulations for TDY travel of Foreign Service travelers and
other applicable classes of Federal travelers and provides internal links to these regulations. Carlson has configuration and
management processes in place to ensure subsequent amendments, approved by the State Department, are implemented on
the effective date.
1.2.5.3 ACCESSIBILITY STANDARDS OF 36 CFR 1194 (RFP REFERENCE C.6.2.1.3; C.6.6)

Carlson recognizes that in order for Federal Agencies to achieve adoption rates envisioned by the eTS, the TAVS must not
only be functionally useable by all user roles as identified in the GSA solicitation, but also must comply with Section 508 of
the Rehabilitation Action of 1973.
Carlson makes an unqualified commitment to the improvement of accessibility by using state of the art commercially avail-
able products, services and technologies. The continual refinement and enhancement of accessibility features is a component
part of out technology refreshment policy that that will be documented within the Program Management Plan deliverable
(RFP Reference C.10).
Please refer to Section 1.1 Voluntary Product Accessibility Templates earlier in this proposal for more details.
Integrating
eTravel Services
1.2.5.4 JFMIP TRAVEL SYSTEM MANDATORY REQUIREMENTS (RFP REFERENCE C.6.2.1.4)

The Carlson eTS Solution meets all mandatory requirements and incorporates many of the value added characteristics identi-
fied by the JFMIP. The Carlson eTS Solution is a system based upon Federal laws and regulations incorporating controls,
parameters and regulatory requirements configurable at multiple client levels. To verify compliance, Carlson Team used
GAO Report GAO/AIMD -21.2.8 “Travel System Requirement Checklist for reviewing Systems under the Federal Financial
Management Improvement Act”. The high level functional architecture, Appendix B, implements the JFMIP travel process.
1.2.6 User Roles (RFP Reference C.6.3.1; C.6.3.1.2)
1.2.6.1 MANDATORY REQUIREMENTS (RFP REFERENCE C.6.3.1.1)
The Carlson eTS Solution fully implements all user roles, use cases, and account access requirements identified in the solici-
tation’s Notional eTravel Service Use Cases. The Carlson eGov Solutions Team performed an analysis of the eTS system
documentation in order to identify how the government identified user roles and use cases correlated to the existing actors
and use cases defined within the Carlson eTS Solution. This correlation is demonstrated in the following three tables.
TABLE 1: ACTORS
This first table defines the three actors whose activities are equivalent to the six government identified user roles. All gov-
ernment identified user roles are identified by an asterisk (*).
Actors Description
Traveler The Traveler is any person who travels or books travel on Federal Agency re-
Federal Traveler (FT) * lated business. A child to the Traveler actor, the Federal Travel Arranger, is
Federal Travel Arranger (FTA) * usually a secretarial or administrative support function that prepares travel
documents for single or multiple travelers, including themselves. A second child
to the Traveler actor, the Federal Traveler, books and prepares travel but can
only do so for him or herself.
Federal Agency Approver The Federal Agency Approver is any person who has been identified as having
Federal Supervisory Travel Approver (FSTA) * the responsibility of approving travel authorizations, vouchers, pre-payments,
Federal Financial Travel Approver (FFTA) * and miscellaneous expense claims submitted by travelers. A child to the Federal
Agency Approver actor, the Federal Supervisory Travel Approver, is usually a
manager, and concentrates on the area of approving travel documents for travel-
ers. A second child to the Federal Agency Approve actor, the Federal Financial
Traveler Approver, concentrates on reviewing and processing travelers’ travel
documents for the purpose of commitment, obligation, and the disbursement of
funds.
Federal Agency Administrator The Federal Agency Administrator is any person who has been identified as hav-
Travel Administrator (FATA) * ing the authority and responsibility to administer a travel management program
Travel Coordinator (FATC) * for a given minor office, major office, organization, or agency. The responsibili-
Major Customer Administrator ties of this actor include the maintenance of customer settings within the eTS
Minor Customer Administrator application, as well as the maintenance of user accounts. A child to this actor,
the FATA, is any person who has been identified as having the authority and
responsibility to administer a travel management program at the Organization
Level. A second child to this actor, the FATC, is any person who has been iden-
tified as having the authority and responsibility to administer a travel
management program at the Agency Level.
TABLE 2: USE CASES
The second table defines the nine Carlson eTS Solution use cases that represent the equivalent functionality described in the
twelve use cases identified in the solicitation. The use cases defined in the solicitation are referenced in bold red.
Gov. Use
Case
Use Case Name Use Case Description
Refer-
ence
Integrating
eTravel Services
1 Manage Traveler The Manage Traveler Profile use case describes how a Federal Traveler (FT) or Federal Travel Arranger
Profile (FTA) manages a travel profile, including traveler information, default preferences, and secure financial
information.
2, 4, 5 Request Travel The Request Travel Authorization use case describes how a Federal Traveler (FT) or Federal Travel Ar-
Authorization ranger (FTA) creates and submits a travel authorization request for approval.
2, 4, 5 Book Reservations The Book Reservations use case describes how a Federal Traveler (FT) or Federal Travel Arranger (FTA)
books travel, hotel, and car reservations that have been specified in a specific travel authorization request.
3 Process Travel The Process Travel Authorization use case describes how an approver, which includes a Federal Supervi-
Authorization sory Travel Approver (FSTA), Federal Financial Travel Approver (FFTA), and any other approval level
required by the customer, reviews and approves a request for travel authorization.
6 View Itinerary The View Itinerary use case describes how various actors are able to access and review a traveler's itinerary,
which includes his/her original trip details as they existed at the time of booking.
7, 9 Request Reim- The Request Reimbursement use case describes how a Federal Traveler (FT) or Federal Travel Arranger
bursement (FTA) creates, modifies, and submits a settlement voucher and amendments to a settlement voucher in or-
der to request reimbursement of expenses incurred while traveling on business.
8, 10 Process Reim- The Process Reimbursement Authorization use case describes how an approver reviews and approves a
bursement traveler’s request for travel reimbursement, referred to as a voucher or voucher amendment.
Authorization
11, 12 Maintain Customer The Maintain Customer Settings use case describes how a Federal Agency Administrator, which includes
Settings the Federal Agency Travel Administrator (FATA), Federal Agency Travel Coordinator (FATC), Major
Customer Administrator, and/or Minor Customer Administrator, customizes the eTS application to match
the individual processes and procedures of a major or minor customer.
11, 12 Maintain User The Maintain User Accounts use case describes how a Federal Agency Administrator, which includes the
Accounts Federal Agency Travel Administrator (FATA), Federal Agency Travel Coordinator (FATC), Major Cus-
tomer Administrator, and/or Minor Customer Administrator, manages the settings within individual user
accounts, including user permissions and password.
TABLE 3: USE CASE / ACTOR MATRIX
The following matrix identifies the interactions between uses cases and actors/user roles. The matrix also includes a corre-
sponding permission level that would be assigned to a user. We recognize that a user may assume multiple roles; for
example, an individual may be a traveler (FT) and an approver (FSTA). Only the use cases and user roles that represent
those identified in the solicitation are included in this matrix.
Administration Application
FT FTA FSTA FFTA FATA FATC
1 Manage Traveler Profile *

2, 4, 5 Request Travel Authorization *
2, 4, 5 Book Reservations *
3 Process Travel Authorization *
6 View Itinerary *
7, 9 Request Reimbursement *
8, 10 Process Reimbursement Authorization *
Maintain User Accounts *
11,12
Integrating
eTravel Services
FT FTA FSTA FFTA FATA FATC
11,12 Maintain Customer Settings *
1.2.6.2 OBJECTIVES (RFP REFERENCE C.6.3.1.2)

In addition to the user roles/actors, use cases, and account access permissions described above, a number of additional actors
and use cases exist to comprise the full functionality of Carlson’s eTS Solution. These actors and use cases are described
below.
(Note: UML does not distinguish between non-system (human) and system actors, however, for the purposes of this solicita-
tion, these actors have been separately identified.)
ADDITIONAL NON-SYSTEM ACTORS

The following two actors are non-system actors. These non-system actors are typically human beings interacting with the
system. As a human being, non-system actors may have multiple roles.
Actors Description
Federal Agency Auditor (FAA) The Federal Agency Auditor is any person responsible for performing organizational travel audits,
both pre-payment and post-payment. The FAA processes all vouchers that have been flagged by the
application for audit prior to payment approval, as well as all post-payment audit requests. Justifica-
tion: Page C-23, Para C.6.3.9.1 Requirement # 16 and Page C-13, Para C.6.1.2 Requirement #6
Federal Agency Program A Federal Agency Program Coordinator is any person who is responsible for managing the opera-
Coordinator (FAPC) tions of a government credit card program through the maintenance of credit card holders and their
accounts. Justification: Page C-17, Para C.3.4.2 Requirement # 5; Page C-39, Para C.6.7.2.2 Re-
quirement #4; Page C-48, Para C.6.11.2 Requirement #8c.
ADDITIONAL SYSTEM ACTORS

The actors defined below are system actors. These system actors are typically computer hardware or software. As system
actors they usually do not have multiple roles.
Actors Description
Agency Business Systems The Agency Business Systems actor represents an external system interface with the customer’s busi-
ness systems including human resource, financial, and payment subsystems. The customer’s business
systems provide data on traveler profiles, fund cites, and travel credit card numbers. In addition, data
related to approved travel authorizations, vouchers, and processed payments is transmitted between the
eTS application and this actor.
Currency Conversion The Currency Conversion actor represents an external system interface with a 3rd party data source.
This data source provides information to eTS related to current currency conversion rates, used when
calculating estimated and actual travel expenses within the application.
Data Warehouse The Data Warehouse actor represents an interface between the eTS application and an internal (or ex-
ternal) data warehouse, where extracts of data from the eTS application will be stored for the purposes
of reporting and business intelligence.
eTS System Administrator The eTS System Administrator is any person who has the authority to configure, monitor, and maintain
the eTS application for individual clients. The responsibilities of this actor include the maintenance of
system settings, customer matrix, user accounts, and Federal Travel Regulation data being imported
from a customer source.
Federal Travel Regulations The Federal Travel Regulations actor represents an external system interface with the customer’s Fed-
System eral Travel Regulations data source. This data source provides data related to mileage reimbursement
and city per diem rates to the eTS application.
Integrating
eTravel Services
Actors Description
GDS The GDS actor represents an external system interface between the GDS and Online Booking Engine
and the GDS and the eTS application. The online booking engine interfaces with the GDS to book
travel reservations prior to the approval of a travel authorization. The eTS application interfaces with
the GDS to begin the process of issuing tickets once a travel authorization has been approved, as well
as to import the data related to ticketing from the GDS into the eTS application once a ticket has been
issued.
GSA eTravel Administrator The GSA eTravel Administrator is any person within government who oversees information from
across all individual agencies. This actor has access to system-wide reports involving all customers
who are utilizing the eTS application.
Online Booking Engine The Online Booking Engine actor represents an external system interface with an online booking en-
gine. The booking engine is used by the traveler when searching for and creating his/her travel
itinerary. It interfaces with the GDS to book travel reservations.
Travel Card Vendor The Travel Card Vendor actor represents an external system interface with a financial credit card ven-
dor business system. The Travel Card Vendor is used by the FAPC to manage the federal charge card
accounts and update eTS traveler profiles with card delinquency information.
Travel Management Center The Travel Management Center is a company under contract with a federal agency to arrange travel
(TMC) services for federal employees on official travel including tickets, transportation, and reservations of
accommodations. The TMC interfaces with the GDS to issue and print tickets for Federal Travelers
once the travel authorization request has been approved by the appropriate Federal Approving Officials
and processed by the GDS.
Travel Receipt System The Travel Receipt System actor represents an external system interface with a 3rd party vendor. This
system provides travelers the ability to scan travel receipts for attachment to a voucher submission and
allows approvers to review stored images of those scanned receipts during the approval process.
ADDITIONAL USE CASES

The use cases defined below, in addition to those described under the mandatory requirements section, comprise the entire
functionality of Carlson’s eTS Solution.

Request Local Travel and The Request Local Travel and Miscellaneous Expenses use case describes how a Federal Traveler (FT) or Fed-
Miscellaneous Expenses eral Travel Arranger (FTA) can create, modify, and submit a reimbursement request for local transportation
and minor purchase expenses.
Process Local Travel and The Process Local Travel and Miscellaneous Expenses use case describes how an approver, which includes a
Miscellaneous Expenses Federal Supervisory Travel Approver (FSTA), Federal Financial Travel Approver (FFTA), and any other addi-
tional approval level required by the customer, reviews and approves a reimbursement request for local travel
and minor purchase expenses.
Administer Application The Administer Application use case describes how the eTS System Administrator maintains all aspects of the
application, including system settings, customer information and settings, imported data, and user accounts.
Execute Reports The Execute Reports use case describes how multiple actors are able to view standard packaged reports and
create customizable reports through various queries.
Maintain Credit Cards The Maintain Credit Cards use case describes how a Federal Agency Program Coordinator (FAPC) manages
the operations of a government credit card program through the maintenance of credit card holders and their
accounts.
Perform Post-Pay Audit The Perform Post-Pay Audit use case describes how a Federal Agency Auditor (FAA) queries, accesses, and
reviews a reimbursement authorization record when an audit has been requested post-payment.
Perform Pre-Pay Audit The Perform Pre-Pay Audit use case describes how a reimbursement authorization, when flagged for audit, is
accessed, reviewed, and approved by the Federal Agency Auditor (FAA) prior to payment processing.
Integrating
eTravel Services

Perform Reimbursement The Perform Reimbursement Reconciliation use case describes what happens once a traveler's request for re-
Reconciliation imbursement has been approved by the final approver and updated to a status of "awaiting payment". This use
case includes how the reimbursement gets sent for payment processing, is exported for updating of the client's
agency business systems, and is reconciled in the case of overpayment.
Process Partial Payments The Process Partial Payments Authorization use case describes how an approver, which includes a Federal
Authorization Supervisory Travel Approver (FSTA), Federal Financial Travel Approver (FFTA), and any other additional
approval level required by the customer, can review and approve a request for partial payment of expenses,
prior to the completion of travel and a settlement voucher being submitted for approval.
Pull Ticket Information The Pull Ticket Information use case describes how the eTS application accesses ticket information located in
the GDS in order to update the eTS application with that information.
Transfer Data The Transfer Data use case describes how data is transported between eTS and the client business and travel
regulation systems. In addition, this use case covers the parameters, rules, and triggers for archiving data into
the data warehouse for reporting and business intelligence.
View Airfare Data The View Airfare Data use case describes how various actors are able to access and review detailed informa-
tion regarding estimated contract carrier rates and those airfare rates that were booked by a traveler.
View Cost Variance The View Cost Variance use case describes how various actors are able to access and review a comparison
between the estimated trip cost calculated at the time of booking and the actual expenses incurred by the trav-
eler.
View History The View History use case describes how various actors are able to access and review the entire history of a
specific authorization or voucher, from the time it was created to the current state.
View Payment Informa- The View Payment Information use case describes how various actors are able to access and review any pay-
tion ment information (i.e. cash advances, etc.) regarding a traveler and a specific travel voucher.
View Ticket Data The View Ticket Data use case describes how various actors are able to access and review data associated with
a CTO issued airline ticket.
USE CASE / ACTOR MATRIX

The following matrix identifies the interactions between uses cases and actors. This matrix only includes those use cases that
are not part of the mandatory requirements described above.
Integrating
eTravel Services
Figure 1.2 – 1
Integrating
eTravel Services
We have organized the capabilities into an Agency implementation category followed by the three phases of travel depicted
on Figure 1.2 – 1, Functional Architecture. The chart addresses all business processes outlined in the solicitation’s eTravel
Business Process Flow Diagram and the Notional eTS Operational Architecture.
1.2.7 Use Cases (RFP Reference E.6.1; Factor 2)

Carlson presents its final Concept of Operations (CONOPS) using the language and artifacts of the Unified Modeling Lan-
guage (UML). The Rational Unified Process (RUP) is the specific software engineering methodology used in the
development of Carlson’s eTS Solution.
In accordance with UML specifications, the functional requirements of the eTS are defined in the form of use cases and ac-
tors (for a complete definition of all actors and use cases, please reference section 1.2.5 User Roles). This section presents a
sampling of these use cases. The format has been modified for presentation within this document in order to provide high-
level coverage of the use cases used to implement a fully functional eTS Solution.
HIGH-LEVEL USE CASE DIAGRAM (FIGURE 1.2 – 2)
The Use Case diagram is used to 1) capture the interaction between users (actors) and travel business processes, and 2) de-
fine the scope of the system’s functionality. Actors and use cases in blue denote user roles and use cases that were identified
by the government RFP.
Figure 1.2 – 2
Integrating
eTravel Services
The Process Reimbursement Authorization use case is extended by numerous other use cases. In the example below (Figure
1.2 –3), several use cases, such as View Itinerary, extend the functionality described within the Process Reimbursement Au-
thorization use case.
Figure 1.2 – 3
1.2.8 Use Case Documentation

On the following pages, Carlson provides high level use case documentation that includes all elements of information re-
quired by the solicitation. Use cases have been modified to show only the high level flow of events. One example of a
detailed use case is provided under 1.2.7.7 Use Case – Process Reimbursement Authorization. Note: the Issues caption for
the use cases has been removed for simplification and readability.
1.2.8.1 USE CASE – MANAGE TRAVELER PROFILE (GOV’T USE CASE ID: #1)
1. Brief Description
The Manage Traveler Profile use case describes how a Federal Traveler (FT) or Federal Travel Arranger (FTA) manages
a travel profile, including traveler information, default preferences, and secure financial information.
2. Basic Flow (Steps)
This use case begins when the actor chooses to manage a user travel profile.
2.1. System Displays General Travel Profile Information
2.2. Actor Specifies Personal Information
2.3. Actor Selects Default Approvers
2.4. Actor Specifies Contact Information
2.5. Actor Specifies Travel Arrangers
2.6. Actor Specifies Default Travel Preferences
2.7. Actor Specifies Default Fund Cites
2.8. Actor Specifies Personal Banking and Credit Card Data
2.9. System Saves Information
3. Variations and Alternative Flows
3.1. [A-1] Actor Updates His/Her Default Homesite
3.2. [A-2] Actor Changes His/Her Password
Integrating
eTravel Services
4. Non-Functional Requirements
N/A
5. Assumptions
Pre-Condition: Actor must have successfully logged into the Portal.
Post-Condition: Traveler profile is updated.
6. Relationships
The actor(s) starting this use case:
Federal Traveler
Federal Traveler Arranger
The actor(s) also involved in this use case:
None
1.2.8.2 USE CASE – REQUEST TRAVEL AUTHORIZATION (GOV’T USE CASE ID: #2, #4, #5)
The Request Travel Authorization use case describes how a Federal Traveler (FT) or Federal Travel Arranger (FTA)
creates and submits a travel authorization request for approval.
This use case begins when the actor chooses to view his/her travel information.
2.1. System Displays List of Authorizations Associated to the Traveler
2.2. Actor Chooses to Add a New Authorization
2.3. Actor Selects a Trip Sponsor
2.4. Actor Specifies Travel Type and Purpose
2.5. Actor Specifies Departure and Arrival Information
2.6. Actor Specifies Other Expenses Estimated for the Trip
2.7. Actor Specifies the Fund Cite(s) to be Used
2.8. System Displays Actor’s Complete Authorization Based on Data Specified
2.9. Actor Chooses to Book Reservations
2.10. System Verifies that All Required Information Has Been Provided
2.11. Include “Book Reservations” Use Case to Book Travel Reservations
2.12. System Retrieves Actor’s Travel Itinerary
2.13. Actor Notified on Authorization that Booking is Complete
2.14. Actor Submits Authorization Request
2.15. System Prompts Actor to Verify Accuracy of the Authorization Against the Reservations
2.16. System Updates Authorization Status to “Pending Authorization”
2.17. System Notifies First Level Approver of Authorization Request
2.18. Actor Notified on Submitted Authorization that Approver Has Been Notified
3.1. [A-1] Actor Selects an Existing Travel Authorization to View
3.2. [A-2] Actor Copies an Existing Authorization
3.3. [A-3] Actor Chooses to Amend a Submitted Authorization
3.4. [A-4] Actor Views History
3.5. [A-5] Actor Changes Approver Name
3.6. [A-6] Actor Cancels Travel Authorization
3.7. [A-8] Actor Edits Fund Cite Data
3.8. [A-9] Actor Edits Travel Site Information
3.9. [A-10] Actor Edits Other Expenses
3.10. [A-11] Actor Edits Travel Type and Purpose
3.11. [A-12] Actor Views His/Her Travel Itinerary
3.12. [A-13] Actor Exits System and Saves Authorization Request Form
3.13. [A-14] Actor Views Estimated Total Cost of the Authorization Request
3.14. [A-15] Actor Does Not Confirm Accuracy Between Authorization and Reservations
3.15. [A-16] System Alerts Actor That Not All Required Information Has Been Entered
3.16. [A-17] Actor Views Per Diem Information
3.17. [A-18] Actor Chooses to Review Information
Integrating
eTravel Services
3.18. [A-19] Actor Chooses to Change Booking Information

N/A
5. Assumptions
Pre-Condition: Actor must have successfully logged into the Portal. Traveler profile must be complete.
Post-Condition: Authorization request sent to approver.
6. Relationships
Federal Traveler (FT)
Federal Travel Arranger (FTA)
Online Booking Engine
Use cases included by this use case (outgoing Include association):
Book Reservations
Use cases extending this use case (incoming Extend association):
View History use case at [A-4] Actor Views History
View Itinerary use case at [A-12] Actor Views His/Her Travel Itinerary
1.2.8.3 USE CASE – BOOK RESERVATIONS (GOV’T USE CASE ID: #4, #5)
The Book Reservations use case describes how a Federal Traveler (FT) or Federal Travel Arranger (FTA) books travel,
hotel, and car reservations that have been specified in a specific travel authorization request.
This use case begins at Step 2.10 of the Request Travel Authorization use case once the actor has chosen to book reser-
vations.
2.1. System Connects to Online Booking Engine
2.2. System Prompts User to Validate Airline Reservation Search Data
2.3. System Searches for and Displays Airline Availability
2.4. Actor Determines Which Flight(s) to Select
2.5. System Searches for Alternate Low Fare Flight Options
2.6. Actor Makes Final Flight Selection
2.7. System Generates and Displays Travel Itinerary
2.8. Actor Approves Itinerary
3.1. [A-1] Actor Adds an Airline Reservation to an Additional Travel Location
3.2. [A-2] Actor Adds a Car Reservation to a Travel Location
3.2.1. System Displays Car Reservation Search Screen
3.2.2. Actor Determines Correct Search Information and Submits
3.2.3. System Displays Car Availability Screen
3.2.4. Actor Selects a Rental Car
3.3. [A-3] Actor Adds a Hotel Reservation to a Travel Location
3.3.1. System Displays Hotel Reservation Search Screen
3.3.2. Actor Determines Correct Search Information and Submits
3.3.3. System Displays Hotel Availability Screen
3.3.4. Actor Determines Which Hotel Reservation to Select
3.3.5. System Displays Selected Hotel’s Room Availability and Rates
3.3.6. Actor Selects a Rate Plan for the Selected Hotel
3.4. [A-4] Actor Selects Seating Preferences
3.5. [A-5] Actor Cancels His/Her Itinerary
3.6. [A-6] Actor Cancels Air Booking
3.7. [A-7] Actor Cancels Car Request
3.8. [A-8] Actor Cancels Hotel Request
3.9. [A-9] System Prompts User to Change or Cancel Booking
Integrating
eTravel Services
N/A
5. Assumptions
Pre-Condition: Actor has successfully logged into the portal. Travel authorization is completed and confirmation given
to book reservations.
Post-Condition: Reservations are booked.
6. Relationships
Online Booking Engine
GDS
Use cases including this use case: (incoming Include association)
Request Travel Authorization
1.2.8.4 USE CASE – VIEW ITINERARY (GOV’T USE CASE ID: #6)
The View Itinerary use case describes how a Federal Traveler (FT) or Federal Travel Arranger (FTA) can view and print
travel itinerary.
This use case begins when the actor chooses to view the travel itinerary for one of his/her travel authorizations or
vouchers.
2.1. System Displays Traveler’s Itinerary
3.1. [A-1] Print Itinerary
3.2. [A-2] Actor Chooses to View Additional Reservation Information
N/A
5. Assumptions
Pre-Condition: Actor has successfully logged into the portal. Itinerary has been created for the authorization.
Post-Condition: N/A
6. Relationships
Federal Supervisory Travel Approver (FSTA)
Federal Financial Travel Approver (FFTA)
Federal Agency Auditor (FAA)
None
Use cases extended by this use case (outgoing Extend association):
Request Travel Authorization
Process Travel Authorization
Request Reimbursement
Process Reimbursement Request
Perform Pre-Pay Audit
Perform Post-Pay Audit
1.2.8.5 USE CASE – PROCESS TRAVEL AUTHORIZATION (GOV’T USE CASE ID: #3)
The Process Travel Authorization use case describes how an approver, which includes a Federal Supervisory Travel Ap-
prover (FSTA), Federal Financial Travel Approver (FFTA), and any other approval level required by the customer,
reviews and approves a request for travel authorization.
Integrating
eTravel Services

This use case begins once the actor receives an e-mail notification of a travel authorization request and accesses his/her
pending travel authorization approvals.
2.1. System Displays List of Pending Approvals
2.2. Actor Selects a Pending Approval with Status of “Pending Order Approval”
2.3. System Displays Authorization Screen
2.4. Actor Approves Authorization
2.5. System Prompts Actor to Confirm Approval
2.6. System Routes to Next Level of Approval
3.1. [A-1] Actor Edits Fund Cite Data
3.2. [A-2] Actor Views Estimated Total Cost of the Authorization Request
3.4. [A-4] Actor Views Traveler’s Itinerary
3.5. [A-5] Actor Requests Revision of Authorization
3.6. [A-6] Actor Chooses to Cancel Authorization
3.7. [A-7] Authorization Reaches Final Level of Approval
3.7.1. System Prompts Actor to Select Reimbursement Methods
3.7.2. Actor Prompted to Acknowledge Deviations From Standard Travel Policy
3.7.3. Actor Prompted to Approve Advance Requests
3.7.4. System Prompts Actor to Confirm Approval
3.7.5. System Removes Travel Authorization From Actor’s Pending Approvals List
3.7.6. System Updates Travel Authorization Status to “Open”
3.7.7. System Generates Email Notification to the Traveler
3.7.8. Include “Transfer Data” Use Case to Generate Data Output File
3.7.9. System Routes Authorization Approval to GDS for Ticket Issuing
3.8. [A-8] Actor Forwards Authorization for Review
3.9. [A-10] Actor Does Not Confirm Approval of the Authorization
3.10. [A-11] Actor Views Per Diem Rate Details
N/A
5. Assumptions
Pre-Condition: User must have successfully logged into the Portal. Authorization has been submitted for approval.
Post-Condition: The status of the authorization is “Open”. The approval is routed to the GDS for the issuing of the
ticket.
6. Relationships
GDS
Use cases extending this use case (incoming Extend association):
View Itinerary use case at [A-4] Actor Views Traveler’s Itinerary
Use cases included by this use case (outgoing Include association):
Transfer Data use case at 7.8 System Generates Financial Standard Data Output File
1.2.8.6 USE CASE – REQUEST REIMBURSEMENT (GOV’T USE CASE ID: #7, #9)
The Request Reimbursement use case describes how a Federal Traveler (FT) or Federal Travel Arranger (FTA) creates,
modifies, and submits a settlement voucher and amendments to a settlement voucher in order to request reimbursement
of expenses incurred while traveling on business.
This use case begins when the actor chooses to view his/her travel authorization requests.
Integrating
eTravel Services
2.1. System Displays Travel Authorizations

2.2. Actor Selects Travel Authorization With a Status of “Open” to View
2.3. System Displays Travel Settlement Screen
2.4. Actor Enters Transportation Costs
2.5. Actor Enters Other Costs
2.6. Actor Enters Lodging Expenses
2.7. System Generates Total Trip Cost
2.8. Actor Finalizes the Settlement Voucher
2.9. Actor Submits the Settlement Voucher
2.10. System Updates the Status of the Voucher to “Pending Voucher Approval”
2.11. System Sends Notification to First Level Voucher Approver
3.1. [A-1] Actor Updates Approver
3.2. [A-2] Actor Updates Travel Details With Changes Made En-route
3.3. [A-3] Actor Updates Original Itinerary
3.4. [A-4] Actor Views Per Diem Information
3.5. [A-5] Actor Enters Prepaid Meals
3.6. [A-6] Actor Adds Traveler Voucher Remarks
3.7. [A-7] Actor Cancels Trip
3.8. [A-8] Actor Cancels Reservations Only
3.9. [A-9] Actor Views Cost Variance
3.10. [A-10] Actor Views Itinerary
3.11. [A-11] Actor Views Airfare Data
3.13. [A-13] Actor Views Original Travel Authorization Request
3.14. [A-14] Actor Updates Fund Cite Data
3.15. [A-15] Actor Selects Quit
3.16. [A-16] Actor Chooses to Amend a Submitted Voucher
N/A
5. Assumptions
Pre-Condition: User must have successfully logged into the Portal. Authorizations with a status of “Open” exist in the
system.
Post-Condition: First Level Voucher Approver is notified.
6. Relationships
Federal Travel (FT)
Travel Receipt System
Currency Conversion
Use cases extending this use case: (incoming Extend association):
View Cost Variance use case at [A-8] Actor Views Cost Variance
View Airfare Data use case at [A-10] Actor Views Airfare Data
View Travel Itinerary use case at [A-9] Actor Views Itinerary
1.2.8.7 USE CASE – PROCESS REIMBURSEMENT AUTHORIZATION (GOV’T USE CASE ID: #8,#10)
(Note: This use case is provided as an example of one of the detailed use cases used in the creation of the Carlson eTS Solu-
tion. Creation and modification of this type of detailed use case remains a core component of Carlson’s eTS development
lifecycle. As new functionality and agency specific changes are implemented appropriate use cases will be updated to reflect
the current state of the system.)
Integrating
eTravel Services
The Process Reimbursement Authorization use case describes how approvers review and approve a traveler’s request for
travel reimbursement, referred to as a voucher or amendment to a voucher.
2. Basic Flow
This use case begins when the actor chooses to view pending approvals related to travel.
2.1. System Displays List of Approvals
The system displays a list of the actor’s pending approvals, ordered from lowest to highest trip ID number. Ap-
provals for submitted voucher requests will have a status of “Pending Voucher Approval 1” or “Pending Voucher
Approval 2”, depending on the level of approval the voucher currently requires. Each line item in the list of pend-
ing approvals will contain the information described in 1.2.1.1 Travel Departure Dates – 1.2.1.5 Authorization
Status.
[A-8] Actor Reorders the Approval List
2.1.1. Travel Departure Date
The system displays the date in which the traveler who submitted the voucher departed.
2.1.2. Authorization ID
The system displays the authorization id that was assigned automatically to the travel request at the time it
was created.
2.1.3. Traveler’s Full Name
The system displays the traveler’s full name as last name, first name. (E.G. Doe, Jane)
2.1.4. Destination
The system displays the destination to which the traveler was traveling (based on the traveler’s authoriza-
tion request) by city location and 2-letter state acronym. (E.G. Newport New, VA)
2.1.5. Authorization Status
The system displays the status of the authorization. This use case is concerned with all authorizations hav-
ing a status of “Pending Voucher Approval 1” and “Pending Voucher Approval 2”.
2.2. Actor Selects a Pending Voucher Approval
To proceed to approval, the actor selects the specific voucher having a pending voucher approval status.
2.3. System Displays Voucher Screen
The system displays the voucher screen containing the information submitted by the traveler in the Settlement
Voucher form (see Request Reimbursement use case). The information included is detailed in 1.2.3.1Voucher Au-
thorization Number – 1.2.3.13 Remarks.
2.4. [BR-2] Actual Expenses Exceed Estimated Cost
2.5. [BR-3] Actor Not Able to Update Voucher
2.5.1. Trip ID Number
The system displays the Trip ID Number, which was automatically assigned to the authorization when it
was originally created.
2.5.2. Traveler Name
The system displays the full name of the traveler who submitted the voucher: First name Last name (E.G.
Jane Doe)
2.5.3. Voucher Status
The system displays the status of the voucher being viewed by the approver. All vouchers will have a
status of “Pending Voucher Approval 1” or “Pending Voucher Approval 2”.
2.5.4. Approver Name
The system displays the name of the approver currently viewing the request: First name Last name (E.G.
Jane Doe).
2.5.5. Arranger Name
If a Travel Arranger is submitting the voucher on behalf of a traveler, the system displays his/her name:
Travel Arranger: First name Last name (E.G. John Smith).
2.5.6. Type of Travel
The system displays the type of travel specified by the traveler in the travel authorization request.
2.5.7. Purpose of Travel
The system displays the purpose of the travel specified by the traveler in the travel authorization request.
Integrating
eTravel Services
2.5.8. Travel Dates

The system displays the travel dates in which the traveler was traveling.
2.5.9. Duration of Travel
The system displays the duration of travel calculated by the system and based on the travel dates in the
original travel authorization request.
2.5.10. Transportation Costs
The system displays all transportation costs. These costs are grouped together and displayed for the ap-
prover to review. All costs are displayed as they were entered by the traveler in the Request
Reimbursement use case. The costs displayed under Transportation Costs include those specified in
2.3.10.1 Total Airfare – 2.3.10.11 Total Transportation Costs.
2.5.10.1. Total Airfare
2.5.10.2. Rental Car
2.5.10.3. Rental Car Tax
2.5.10.4. Fuel
2.5.10.5. Rail
2.5.10.6. Bus
2.5.10.7. Taxi
2.5.10.8. Personal Vehicle Mileage
2.5.10.9. Incurred In and Around Mileage
2.5.10.10. Personal Plane Mileage
2.5.10.11. Total Transportation Costs
The system displays the total of all costs entered for transportation and calculated by the system.
2.5.11. Other Costs
The system displays all miscellaneous costs that are not directly associated to transportation or lodging.
These costs are grouped together as “Other Costs” and displayed for the approver to review. All costs are
displayed as the traveler in the Request Reimbursement use case entered them. The costs displayed under
Other Costs include those specified in 1.2.3.11.1 Parking – 1.2.3.11.7 Total Other Costs.
2.5.11.1. Parking
2.5.11.2. Laundry
2.5.11.3. Phone
2.5.11.4. Miscellaneous Expenses
2.5.11.5. Teller / Traveler Check Fees
2.5.11.6. ATM Usage Fees
2.5.11.7. Total Other Costs
The system displays the total of all costs entered for miscellaneous costs and calculated by the
system.
2.5.12. Total Costs
The system displays a summary of the totals of all costs specified by the traveler in the Request Reim-
bursement use case. The costs displayed under Total Costs include those specified in 1.2.3.12.1 Lodging
Expense – 1.2.3.12.11 Pay the Traveler.
2.5.12.1. Lodging Expense
The system displays the total lodging expense provided by the traveler. [A-9] Actor Views Lodging De-
tail
2.5.12.2. Lodging Tax
The system displays the total lodging tax provided by the traveler.
2.5.12.3. Meals and Incidental Expenses (Per Diem)
The system displays the total per diem determined by the system and based on the traveler’s desti-
nation locations and to and from airports.
2.5.12.4. Transportation Cost
The system displays the total listed in 1.2.3.10.11 Total Transportation Costs.
2.5.12.5. Other Costs
The system displays the total listed under 1.2.3.11.7 Total Other Costs.
2.5.12.6. Less Unused Airline Tickets
If a portion of a ticket was unused or a credit from an airline was received and charged to a Trav-
Integrating
eTravel Services
eler’s EIC card, the traveler would have specified this in the Request Reimbursement use case.
The system displays this amount.
2.5.12.7. Total Trip Cost
The system calculates the total trip cost and displays this amount (Lodging Expense + Lodging
Tax + M&IE + Transportation Cost + Other Costs – Less Unused Airline Tickets = Total Trip
Cost).
2.5.12.8. Less Payments Made
If any cash advances or partial payments were made to the traveler, the system displays the total
of these advances.
2.5.12.9. Net Due
The system displays the total net due to the traveler (Total Trip Cost – Partial Payments – Cash
Advances = Net Due)
2.5.12.10. Pay EIC Card
If the traveler specified any amount of the total trip cost that s/he wished to have paid directly to
his/her EIC card, the system displays the amount entered.
2.5.12.11. Pay the Traveler
The system displays the total amount to be paid to the traveler. (Net Due – Pay EIC = Pay to
Traveler).
2.5.13. Remarks
If the traveler or approver submitted any remarks, the system displays these.
2.6. Actor Approves Voucher
If the actor agrees with the information submitted in the voucher, s/he approves it by selecting the Approve option.
[A-2] Actor Requests Revision of Voucher [A-7] Actor Forwards Voucher for Review [A-11] Actor Selects Print [A-13] Actor Views History
[A-14] Actor Views Cost Variance [A-15] Actor Views Airfare Data [A-16] Actor Views Travel Itinerary [A-17] Actor Views Ticket Data
[A-18] Actor Updates Fund Cite Data
2.7. [A-19] Actor Views Payment Information [BR-1] View Receipts
2.8. System Validates Voucher
The system verifies that there are no flagged exceptions contained within the voucher or overages in per diem al-
lowance. [A-3] Actor is Notified of Any Flagged Exceptions [A-4] Actor is Notified of Overages in Per Diem [A-5] System Routes to Next
Level of Approval
2.9. [BR-4] Voucher Approval Levels
2.10. System Updates Voucher Status to “Awaiting Payment”
The system updates the status of the voucher to “Awaiting Payment”. [A-6] System Flags Voucher for Audit
2.11. System Notifies Traveler of Updated Status
The system sends an email notification to the traveler (based on the email address specified in the traveler’s pro-
file). This email notification lets the traveler know that his/her settlement voucher has been approved and is now
awaiting payment. The use case ends.

3.1. [A-2] Actor Requests Revision of Voucher
In step 2.4 Actor Approves Voucher the actor may instead request that the traveler revise the voucher. S/he does
this by selecting the Revise option. The system prompts the actor to enter reasons for the revision request. Once the
actor submits these remarks, the system prompts him/her to confirm the request for revision. If s/he confirms the
request, the system sends a notification to the traveler, notifying him/her that the voucher requires revision. The
status of the voucher is changed back to “Open”. The use case ends. If the actor does not confirm the request for
revision, the use case resumes at step 2.3 System Displays Voucher Screen.
3.2. [A-3] Actor is Notified of Any Flagged Exceptions
If in step 2.5 System Validates Voucher the system identifies any exceptions that were originally approved pre-
travel, the actor is prompted with a notification advising him/her of the exception. The actor must review all excep-
tions that were identified and okay out of the prompt. The use case resumes at step 2.3 System Displays Voucher
Screen. If the actor does not confirm the exceptions, s/he is returned to the basic flow and will need to request a
revision. The use case resumes at 2.3 System Displays Voucher Screen.
3.3. [A-4] Actor is Notified of Overages in Per Diem
If in step 2.5 System Validates Voucher the system identifies any claims where lodging plus meals and incidental
Integrating
eTravel Services
expenses exceed the maximum per diem allowed, the actor is prompted by the system with a notification advising
him/her of the exceeded amount. The actor must review this and okay out of the prompt. The use case resumes at
step 2.5 System Updates Voucher Status to “Awaiting Payment”. If the overage is not confirmed, the actor is re-
turned to the basic flow and will need to request a revision. The use case resumes at 2.5 System Updates Voucher
Status to “Awaiting Payment”.
3.4. [A-5] System Routes to Next Level of Approval
In step 2.5 System Validates Voucher, if the system identifies that an additional level of approval is required, it
routes the settlement voucher to the next level approver. The status of the authorization is updated to “Pending
Voucher Approval 2”. The use case ends.
3.5. [A-6] System Flags Voucher for Audit
In step 2.6 System Updates Voucher Status to “Awaiting Payment” the voucher may be flagged for audit. Whether
or not it is flagged depends on the audit parameters established in the Customer Settings use case. If the voucher is
flagged for audit, the system changes the status of the voucher to “Pending Audit”. The voucher is forwarded to the
appropriate Federal Agency Auditor (FAA) for audit. The FAA is notified via email that a voucher has been
flagged for audit. The use case ends.
3.6. [A-7] Actor Forwards Voucher for Review
In step 2.4 Actor Approves Voucher the actor may instead choose to forward the voucher for approval to a differ-
ent individual identified as an approver in the Maintain Customer Settings use case. To forward a voucher to a
different approver, the actor must select the approver’s name that is listed on the Settlement Voucher in 2.3.4 Ap-
prover Name. The system prompts the actor with a list of the available approvers. All approvers are listed
alphabetically by last name (A-Z) and are formatted as Last Name, First Name (E.G. Smith, Jane). The actor can
select one approver from the list. Once selected, the system updates the name of the approver on the Settlement
Voucher, adds the voucher to the new approver’s pending approvals list, and notifies him/her via email of the for-
warded voucher. The voucher is removed from the actor’s list of pending approvals. The status of the voucher does
not change. The use case ends.
3.7. [A-8] Actor Reorders the Approval List
In step 2.1 System Displays List of Approvals the actor can choose to alter the order of the approvals in the ap-
proval list by clicking on the column heading. The system will order the list by the heading selected. The use case
resumes at step 2.1 System Displays List of Approvals.
3.7.1. Departing Date
The system orders by oldest date to most recent date.
3.7.2. Authorization Number
The system orders by lowest number to highest number.
The system orders alphabetically (A-Z) by last name.
3.7.4. Destination
The system orders alphabetically (A-Z) by city location.
3.7.5. Status
The system orders alphabetically (A-Z).
3.8. [A-9] Actor Views Lodging Detail
In step 2.3.12.1 Lodging Expense the system displays the lodging expense total amount. If the actor wishes to view
details of these expenses, as provided by the traveler in the Request Reimbursement use case, s/he can choose to do
so. The system displays the Lodging Details screen that contains the information detailed in 3.8.1 Trip ID – 3.8.15
Meals. The use case resumes at step 2.3 System Displays Voucher Screen. [A-10] Actor Views Per Diem Display for Travel
Destination
3.8.1. Authorization ID
The system displays the authorization id that was assigned automatically to the travel request at the time it
was created.
The system displays the full name of the traveler – First Name Last Name.
3.8.3. Dates of Travel
The system displays the dates in which the traveler conducted his/her travel.
3.8.4. Duration of Travel
The system displays the duration of the travel in days as calculated by the system.
Integrating
eTravel Services
3.8.5. Itinerary
The system displays each of the traveler’s originating locations and destination locations: City, State Code
(E.G. Denver, CO).
3.8.6. Arrival Date
The system displays an arrival date for each of the locations listed under 1.3.8.5 Itinerary, as appropriate.
3.8.7. Departure Date
The system displays a departure date for each of the locations listed under 1.3.8.5 Itinerary, as appropriate.
3.8.8. Arrival Mode
The system displays the mode of travel that the traveler utilized to arrive at his/her destination by its two-
letter acronym.
3.8.9. Arrival Airport
The system displays the airport to which the traveler arrived at his/her destination location by its 3-letter
acronym.
3.8.10. Departure Airport
The system displays the airport from which the traveler departed each originating location by its 3-letter
acronym.
3.8.11. Nightly Rate
The system displays the nightly hotel rate for each location listed.
3.8.12. Room Tax
The system displays the nightly hotel room tax for each location listed.
3.8.13. Lodging Amount and Tax
The system displays the total cost of lodging (Nightly Rate * # of Nights = Total Lodging Amount) and to-
tal cost of lodging tax (Room Tax * # of Nights = Total Lodging Tax) for each location.
3.8.14. Meals Amount
The system displays, for each location where per diem was allowed, the total per diem allotted for meals.
3.8.15. Meals
If the traveler specified any meals as being pre-paid, i.e. covered by the government or via conference fees,
the system notes this. The actor can choose to view each trip date and what meal(s) the traveler marked as
furnished (Breakfast, Lunch, or Dinner).
3.9. [A-10] Actor Views Per Diem Display for Travel Destination
In alternate flow [A-9] Actor Views Lodging Detail, the actor can choose to view more information about how the
per diem for a given location was calculated. By selecting this option, which is available for each location where
per diem was allowed, the system displays the information detailed in 1.3.9.1 Per Diem Location – 1.3.9.9 Per
Diem Statement. The use case resumes at step 3.8 [A-9] View Lodging Detail.
3.9.1. Per Diem Location
The system displays the location for which the actor is viewing the per diem estimates, formatted as city,
state. (E.G. Denver, Colorado)
3.9.2. Traveler Arrival Date
The system displays the date in which the traveler arrived at the per diem location.
3.9.3. Traveler Departure Date
The system displays the date in which the traveler departed from the per diem location.
3.9.4. Lodging Amount
The system displays the amount of the per diem calculated for lodging.
3.9.5. Meals and Incidental Expenses Amount
The system displays the amount of the per diem calculated for meals and incidental expenses.
3.9.6. Total Per Diem
The system displays the total per diem estimated for the location.
3.9.7. Number of Days and Nights for Travel
The system displays the total number of days and nights in which the traveler was at the location as # Days,
# Nights.
3.9.8. Actual Costs
The system displays the actual costs incurred by the traveler for lodging, meals and incidental expenses,
and the total cost of the two combined.
Integrating
eTravel Services
3.9.9. Per Diem Statement

The system displays a general statement regarding what the per diem estimates are based on.
3.10. [A-11] Actor Selects Print
In step 2.4 Actor Approves Voucher the actor can instead choose the print option. The use case resumes at step 2.3
System Displays Voucher Screen.
3.11. [A-12] Actor Chooses to Quit
In step 2.4 Actor Approves Voucher the actor can instead choose to quit. All remarks and other content provided
by him/her are saved. The voucher status remains as “Pending Voucher Approval”. The use case ends.
In step 2.4 Actor Approves Voucher the actor can instead choose the view history option. The system executes the
View History use case. The use case resumes at 2.3 System Displays Voucher Screen.
3.13. [A-14] Actor Views Cost Variance
In step 2.4 Actor Approves Voucher the actor can instead choose the view cost variance option. The system exe-
cutes the View Cost Variance use case.
3.14. [A-15] Actor Views Airfare Data
In step 2.4 Actor Approves Voucher the actor can instead choose the view airfare data option. The system executes
the View Airfare Data use case. The use case resumes at 2.3 System Displays Voucher Screen.
3.15. [A-16] Actor Views Travel Itinerary
In step 2.4 Actor Approves Voucher the actor can instead choose the view travel itinerary option. The system exe-
cutes the View Travel Itinerary use case. The use case resumes at 2.3 System Displays Voucher Screen.
3.16. [A-17] Actor Views Ticket Data
In step 2.4 Actor Approves Voucher the actor can instead choose the view ticket data option. The system executes
the View Ticket Data use case. The use case resumes at 2.3 System Displays Voucher Screen.
3.17. [A-18] Actor Updates Fund Cite Data
In step 2.4 Actor Approves Voucher the actor can instead choose to update fund cites data. The system displays the
existing fund cites selected for the voucher. The actor adds additional fund cites. The use case resumes at 2.3 Sys-
tem Displays Voucher Screen.
3.18. [A-19] Actor Views Payment Information
In step 2.4 Actor Approves Voucher the actor can instead choose the view payment information option. The system
executes the View Payment Information use case. The use case resumes at 2.3 System Displays Voucher Screen.
Compliance with government regulatory requirements.
5. Assumptions
Pre-Condition: User must have successfully logged into the Portal. Vouchers with a status of pending approvals exist in the system.
Post-Condition: Voucher is routed to disbursement where processing of payment will occur and an output file will be generated to
update the customer business systems (see Perform Reimbursement Reconciliation use case)
6. Relationships

Travel Receipt System
Use cases extending this use case: (incoming Extend association):

View Cost Variance use case at [A-14] Actor Views Cost Variance
View Airfare Data use case at [A-15] Actor Views Airfare Data
View Travel Itinerary use case at [A-16] Actor Views Travel Itinerary
View Ticket Data use case at [A-17] Actor Views Ticket Data
View Payment Information use case at [A-19] Actor Views Payment Information
Integrating
eTravel Services
7. Business Rules
7.1. [BR-1] View Receipts
While reviewing a traveler’s Settlement Voucher, if the traveler scanned images of his/her receipts, the actor
should be able to view an image of these receipts for verification purposes.
7.2. [BR-2] Actual Expenses Exceed Estimated Cost
If any of the actual expenses exceeded the estimated cost (determined during the travel authorization request) in
any category, the system flags the appropriate item.
7.3. [BR-3] Actor Not Able to Update Voucher
The actor cannot alter any of the content displayed in the Settlement Voucher that was submitted by the traveler.
The one exception to this involves fund data. The actor can add fund cites and change the fund cite added by the
traveler to zero.
7.4. [BR-4] Voucher Approval Levels
The system accommodates 3 levels of official approval – Level 1 Approval, Level 2 Approval, and Audit. A
voucher can pass through several non-official approval levels by the actor forwarding the voucher on to different
approvers. However, the approval status of the voucher only changes when the approver selects the approve op-
tion, therefore, the status changes of the voucher will still only accommodate the 3 levels.
8. Glossary
Settlement Voucher
The traveler submits a settlement voucher in order to claim any expenses s/he incurred while traveling on business.
EIC Card
The EIC card is a government issued credit card that travelers use when traveling on business.
Meals and Incidental Expenses (M&IE)
Meals and incidental expenses help make up the per diem rate. They include any costs for food and general costs as-
sociated with business traveling.
Incurred In and Around Mileage (I&A)
Incurred in and around mileage includes mileage that was used while traveling within the traveler’s destination loca-
tion.
Pending Voucher Approval 1
Pending Voucher Approval 1 is the status a voucher assumes when initially submitted by the traveler. The first level
approver sees only vouchers with this status. Once s/he approves the voucher, the status changes.
Pending Voucher Approval 2
Pending Voucher Approval 2 is the status a voucher assumes once approved by the first level approver and for-
warded on to the second level approver. The second level approver sees only vouchers with this status. Once s/he
approves the voucher, the status changes.
9. Activity Diagram
Integrating
eTravel Services
1.2.8.8 USE CASE – MAINTAIN CUSTOMER SETTINGS (GOV’T USE CASE ID: #11, #12)
The Maintain Customer Settings use case describes how a Federal Agency Administrator, which includes the Federal
Agency Travel Administrator (FATA), Federal Agency Travel Coordinator (FATC), Major Customer Administrator,
and/or Minor Customer Administrator, customizes the business policies and parameters within the eTS application to
match those of a major or minor customer.
This use case begins when the actor enters the administrative options section and chooses to manage customer settings.
2.1. System Displays Customer Settings Form for User’s Minor Customer Account
2.2. Actor Modifies Audit Settings
2.3. Actor Modifies Customer Settings (Travel Authorization / Voucher Related)
2.4. Actor Modifies Reimbursement Settings
2.5. Actor Modifies Minor Customer Approver Settings
Integrating
eTravel Services
2.6. Actor Submits Modifications to Settings

3.1. [A-1] Actor Selects Different Customer Account to View
3.2. [A-2] Actor Updates the Default Home Station
3.3. [A-3] Actor Adds a New Approver
3.4. [A-4] Actor Deletes an Existing Approver
3.5. [A-5] Actor Chooses to Modify Major Customer Settings
3.6. [A-6] Actor Disables the Customer Account
3.7. [A-4] Actor Chooses to Delete Minor Customer
N/A
5. Assumptions
Pre-condition: Actor must have successfully logged into the Portal.
Post-condition: System is updated with the new settings.
6. Relationships
Federal Agency Administrator
None
1.2.8.9 USE CASE – MAINTAIN USER ACCOUNTS (GOV’T USE CASE ID: #11, #12)
The Maintain User Accounts use case describes how a Federal Agency Administrator, which includes the Federal
Agency Travel Administrator (FATA), Federal Agency Travel Coordinator (FATC), Major Customer Administrator,
and/or Minor Customer Administration, manages the settings within individual user accounts, including user permis-
sions and password.
This use case begins when the actor enters the administrative options section and chooses to manage user accounts.
2.1. System Displays List of Users
2.2. Actor Chooses to Add a New User Account
2.3. System Prompts Actor for New User Account Information
2.4. Actor Provides New User Information
2.5. Actor Specifies New User Settings
2.6. Actor Submits New User Account Form
2.7. System Adds New User
2.8. System Displays User Account Form
3.1. [A-1] Actor Modifies an Existing User Account
3.2. [A-2] Actor Deletes an Existing User Account
3.3. [A-3] Actor Accesses the User’s Traveler Profile
3.4. [A-4] Actor Disables the User’s Account
3.5. [A-5] Actor Accesses Office Settings
N/A
5. Assumptions
Pre-Condition: Actor must have successfully logged into the Portal. Actor must have administrative access.
Post-Condition: New user account added to the system.
6. Relationships
Federal Agency Administrator
7. None
Integrating
eTravel Services
1.3 Performance Based Work Statement (PBWS)/Work Breakdown Structure

(RFP Reference E.3.4.2.1.2, Item 3; E.6.1 Factor 3)
The Work Breakdown described on the following pages is used to deliver Carlson’s Performance Based Work Statement.
The entire PWBS is contained in Appendix A.
1.3.1 Work Breakdown Structure
The Carlson eGov Solutions Team used the Project Management Institute Practice Standard for Work Breakdown Structure
as a methodology and process to design the functional eTS Work Breakdown Structure (WBS). The following WBS diagram
(Figure 1.3 – 1), defines a hierarchy of deliverables, a definition of the functional work required to achieve the eTS vision
and supports documenting organizational accountability and responsibilities defined in Volume 2- Management Approach.
This WBS describes Carlson’s technical and management approach in meeting the Statement of Objectives (SOO). The Pro-
gram Management WBS and Deployment (Implementation Approach) WBS are contained within Volume 2 – Management
Approach. The remainder of the Work Breakdown Schedule is contained within this volume.
In addition to the Functional Work Breakdown Structure, Appendix A contains a detailed WBS for post contract award ac-
tivities. This WBS addresses all those activities and deliverables required to achieve FOC.
Figure 1.3 – 1
1.3.2 Performance Measures (RFP Reference C.7; D.28)

PERFORMANCE MEASUREMENT & MANAGEMENT
The Carlson eTS team views the implementation of a robust Performance Measurement & Management system to be critical
to the success of the eTS Program. Through our experience in the travel services industry, technology integration, application
hosting services, and relationship marketing, Carlson is uniquely positioned to collaborate with the GSA and federal agencies
procuring travel services from Carlson to systematically benchmark services delivered with best-in-class travel services and
identify best practices vital to the success of Carlson providing high-quality travel services. In the following narrative, we
will detail our process and approach, which is based on our experience working with other best-in-class organizations that
excel at incorporating their customers’ needs and expectations into their strategic performance management processes.
Integrating
eTravel Services
Goals & Objectives

Carlson uses performance measurement to gain insight into, and make judgments about, the effectiveness and efficiency of
its programs, processes, and people. As a company that is committed to consistently deliver best-in-class services, Carlson
continuously monitors indicators to measure progress in meeting strategic goals and objectives, gather and analyze perform-
ance data, and then use these data to drive improvements in the organization and successfully translate strategy into action.
This approach helps strategically plan how Carlson will deliver best-in-class services to customers, and specifically measure
program performance in meeting these commitments.
The goal of Carlson’s performance measurement strategy is to:
Realize the vision for eTravel identified by the GSA
Meet eTS Program goals; (2) define how the goals will be achieved
Demonstrate how we will measure program performance in achieving those goals.
Carlson will use the Balanced Scorecard methodology (a tool used in the Six Sigma quality management approach, described
in Volume 2, Section 2.1.1.7 Quality Management) as a conceptual framework for the performance measurement and man-
agement system. This will provide clear and cohesive performance measurement framework that is understood by all levels
of the organization and that supports objectives and the collection of results. Measures will be organized and aligned with the
overall eTS goals and objectives.
What to Measure?
Carlson’s approach to performance measures is divided into two distinct phases. The first covers milestones and performance
measures for the IOC and FOC period and the second covers all services delivered during the base contract period using a
set of balanced measures that enable Carlson and the Government to achieve the eTS vision.
Carlson Service Level Agreement - IOC, FOC
The first element pertains to the achievement of specific milestones and performance expectations for the IOC & FOC pe-
riod. This is tied to the incentives identified in the RFP for the IOC period. The following table identifies specific
performance measures and targets that Carlson is committed to achieving during the IOC & FOC periods.
No. Performance Measure Performance Objective Desired Outcomes

2.1.2.1 Service Delivery
a.) Initial Operational Capability (IOC) implemen- < 105 days Customer Acceptance & Sign Off
tation.
b.) Full Operational Capability (FOC) achievement Before December 1, 2003 Customer Acceptance & Sign Off
with 2500 vouchers & 1000 ticketed transactions.
c.) Rate of eTS adoption. Exceed transaction & voucher % of Vouchers & Reservations
targets in Section C.6.8 for IOC
2.1.2.2 Technical
a.) eTS availability or up time (including scheduled > 98.00% System Availability
eTS down time but not including Federal agency
network outages).
b.) Technology refreshment. Maintained to industry best prac- Customer Acceptance & Sign Off
tices
c.) Support of Federal travel management business Establish business data ware- Customer Acceptance & Sign Off
intelligence and integration of eTS with agency house, Data Exchange
business systems. Specification, and EAI capability
ahead of schedule.
d.) Use of XML Schema and related XML technol- Adopt or extend travel industry Customer Acceptance & Sign Off
ogy for eTS data exchange and integration with standard XML Schema and tech-
agency business systems. nology
e.) Online response time. Meet or beat industry standards Reduced Transaction Response
for point of presence response Time
time for comparable online ser-
Integrating
eTravel Services
No. Performance Measure Performance Objective Desired Outcomes

vices.
f.) Robust protection of eTS data. Rapid attainment of GSA Author- Customer Acceptance & Sign Off
ity to Operate in order to support
FOC.
g.) Leveraging of assistive technology to maximize Meet applicable accessibility Customer Acceptance & Sign Off
eTS accessibility. requirements of 36 CFR Part
1194 with commercially available
tools.
2.1.2.3 Customer Satisfaction
a.) Intuitive eTS user interface and process flows. Qualitative measure.* Increased Customer Acceptance
b.) Quality of eTS user experience. Qualitative measure.* Increased Customer Acceptance
c.) Time needed to complete online travel transac- Qualitative measure.* Increased Customer Acceptance
tion.
2.1.2.4 Self Service Transactions
Maximize end-to-end, self-service transactions 70:30 ratio of self service to non- 70% or greater online booking
including international self-service reservations. self service reservations. reservations
2.1.2.5 Customer Support and Training
a.) Percent of user problems resolved during first > 95% Customer Acceptance & Sign off
customer support call (on a semi-annual basis).
b.) Customer support call wait time (semi-annual < 5 minutes Customer Acceptance & Sign off
average).
c.) Average time between user contact with cus- < 1 hour Customer Acceptance & Sign off
tomer support agent and resolution of problem (not
including agency network outages or problems
requiring software changes.)
d.) Effectiveness of computer- or web-based train- Qualitative measure.* Customer Acceptance & Sign off
ing.
e.) Effectiveness of instructor-led training Qualitative measure.* Customer Acceptance & Sign off
2.1.2.6 Implementation
a.) Ease of eTS configuration for approval, routing, Qualitative measure.* Customer Satisfaction Survey
business rules, user accounts, etc.
b.) Accommodation and integration of TMC and Qualitative measure.* Customer Acceptance & Sign Off
FedTrip™ services.
* Qualitative measures for desired outcomes should be based on independent customer surveys administered by the eTravel PMO. Desired outcomes
represent ratings of 4 or better on a scale of 1 to 5 where 1 is the lowest rating and 5 is the highest rating.
We recommend that the incentive payment for the IOC/FOC period ($250,000) identified in the RFP paragraph B.28 be dis-
bursed upon successful completion of the outcomes, in the following manner.
No. Performance Incentive Desired Outcome Percent Distribution
1 Granted Authority to Operate from GSA DAA Prior to December 1, 2003 33%
2 Government acceptance of IV & V testing Prior to December 1, 2003 33%
3 Successfully processed 2,500 vouchers via CLIN Prior to December 1, 2003 33%
0003AA or 0003AB (exclusive of any vouch-
ers processed as part of CLIN 0001, IOC), of
which 1,000 must be ticketed transactions via
either CLINs 0002AA, 0002AC or 0002AD
or a combination thereof before December 01,
2003.
Carlson Service Level Agreement -Base Contract Period
Integrating
eTravel Services
During the base contract period (and for future extensions), Carlson proposes a Service Level Agreement that uses the Bal-
ance Scorecard methodology that is aimed at achieving the vision and benefits of the overall eTS Program. This is tied to the
incentives identified for the base period of the contract. Using the Balanced Scorecard, we must measure the right things.
However, before deciding on specific measures, we should identify and thoroughly understand the processes to be measured.
Then, each key process should be mapped taken apart and analyzed to ensure (1) a thorough, rather than assumed, under-
standing of the process; and (2) that a measure central to the success of the process is chosen. In many cases, targets,
minimums, or maximums will have to be defined for each measure. The general aspects of performance covered in the Bal-
ance Scorecard include: financial considerations, customer satisfaction, internal business operations, employee satisfaction,
and stakeholder satisfaction.
Once the performance measures have been identified, the next step in the process is to determine a baseline for each of the
measures selected. Once data is collected for the first time on a particular measurement, then that serves as the baseline for
future reference. Determining appropriate goals for each measure after these baseline data are collected can be accomplished
in several ways. We will use various statistical analysis techniques as well as benchmarking to set goals for future perform-
ance.
The following table is a proposed set of measures for consideration that can be used to construct the eTS Balanced Score-
card.
The information compiled in the scorecard is the basis for organizational performance evaluations which will be conducted
periodically to meet management information needs. These will be done on a monthly and quarterly basis. The information
will be used for the following purposes:
Input into resource allocation decisions Use in employee/management evaluations
Determine gaps between goals and reality Drive reengineering
Benchmarking with other best-in-class organiza- Improve organizational processes
tions
Review and adjust goals and targets Review and improve performance measures
As an example, to compile the metrics in the Customer quadrant of the Balanced Scorecard, the following questions may be
included in a customer satisfaction survey.
Integrating
eTravel Services
1. Accuracy of travel tickets

2. Accuracy of billing information
3. Accuracy of car rental arrangements
4. Accuracy of hotel arrangements
5. Accuracy of resulting itinerary
6. Itinerary was useful (easy to read, easy to interpret)
7. Length of time it took to complete a reservation
8. Web-based page layout was intuitive
9. Order of web-based screens and flow was logical
10. The tool provided enough information for me to select lowest air fares and hotel/car rates according to my travel
schedule
11. The timely manner in obtaining and/or receiving e-ticket receipts, itineraries, and invoices.
12. When needed, the HELP functionality was available
13. When used, the HELP functionality was helpful
14. Calls answered promptly
15. Courtesy of TMC personnel
16. Overall quality of TMC Service
17. Agents' travel knowledge
18. Range of information offered by agents
19. Agents' willingness to offer alternatives
20. On-time ticket deliveries
21. Advance seat requests were correct
22. Received proper "frequent flyer" credit
23. Informed if preferred seat unavailable
24. After Hours Customer Service
PERFORMANCE INCENTIVE PAYMENTS

We recommend that the incentive payment during the base contract period identified in the RFP paragraph B.28 be disbursed
upon successful completion of the outcomes in the balanced scorecard.
SUMMARY
Effective performance measurement systems take time: time to design, time to implement, time to perfect. Performance
measurement must be approached as an iterative process in which continuous improvement is a critical and constant objec-
tive. The hallmark of successful organizations is the use of benchmarking to establish performance targets as part of a
continuous improvement process. This starts with the practice of process mapping and then comparing with those organiza-
tions that are considered to be the best. Through this self-analysis and comparison against the best, we will learn what needs
to be changed as well as the processes, methodologies, approaches, and practices that can help us continuously improve.
Integrating
eTravel Services
1.4 Security Approach (RFP Reference E.3.4.2.1.2, Item 4; E.6.1 Factor 4)
On the following pages, Carlson describes how we propose to protect and maintain the integrity of Government data in the
eTS in accordance with all applicable mandatory security requirements and, to the maximum extent possible, the objectives
of the solicitation’s SOO.
1.4.1 General – Security Architecture (RFP Reference C.6.5.1; E.6.1 Factor 4)
Through the use of Government certified and security industry standard products Carlson delivers a best-in-class security
solution to meet Government hosting needs. The Carlson eGov Solutions Team has demonstrated past performance in host-
ing and securing human resource applications for the Navy, Coast Guard, and Department of Treasury, and currently hosts
and manages systems for numerous financial institutions that demand the highest security standards.
The Carlson eTS security model is architected to meet Government medium data sensitivity levels, to comply with the provi-
sions of the Privacy Act, and to meet requirements for Government accessed major applications and general support systems.
As part of the implementation process, the Carlson eGov Solutions Team will complete any required security certification
and accreditation activities including the Authority to Operate as identified by the GSA Security Order.
The following security sections detail the Carlson defense-in-depth security approach. Figure 1.4 – 1 provides a high-level
summary of the defense-in-depth security capabilities of the Carlson eTS Solution present throughout all elements of the
eTS. The diagram is divided into three sections to represent these capabilities: 1) Personnel Security Measures, 2) Opera-
tional Security Measures, and 3) Technical Security Measures. Within each of these sections, the eTS has been designed to
provide multiple layers of protection thus implementing a web of synergistic security mechanisms. For example, by using
firewalls, network and host based intrusion detection, virus protection, and file integrity solutions, the technical security of
the system is ensured through multiple means. Coverage of the defense-in-depth categories is provided in subsequent secu-
rity sections. By validating the capability to protect, detect, and recover from a multitude of attacks or events, the eTS
delivers assurance that all eTS information is soundly protected.
Integrating
eTravel Services
Figure 4.1 – 1
The Carlson eTS Solution is designed to incorporate Government and industry security standards that meet and exceed
GSA’s requirements within every system component and throughout every interface (both internal and external) used in the
application. Specifically, the security mechanisms within the Carlson eTS Solution implement the following features used to
ensure a defense-in-depth implementation to security throughout the system:
Advanced Filtering provides for the extended capability to scan, block, or intercept malicious or undesirable programs
(e.g., viruses and worms) or content that poses a threat to system resources or Agency image. The Carlson eTS Solution
provides filtering at numerous points in the architecture includes filtering by, among other items, port, protocol, IP ad-
dress, MAC address, session, content, and combinations of these items to create advanced security rule sets.
Audit provides for the logging, monitoring, alerting, and reporting of systems and application access, activities, and
changes through passive (after the fact) and dynamic (near real-time) controls. Auditing provides the ability to proac-
tively identify vulnerabilities and measure compliance to policies.
Authentication provides for identifying and verifying who has access to a defined system resource via an identification
process using one or more of the following approaches:
♦ Something you Know - (e.g., Name and Password Logon Session)
♦ Something you Have - (e.g., Smartcard, Token, or Certificate/Key)
♦ Something you Are - (e.g., Biometric Voice or Fingerprint Scan)
All user authentication information (i.e. passwords) is protected through the use of strong FIPS 140-1 & 2 compliant
one-way hash algorithms and is stored at either the database or operating system level. Authentication services can be
Integrating
eTravel Services
managed by either the Carlson eTS Solution or the Government’s eAuthentication Gateway. A solution-wide secure
single sign-on capability that is fully SAML compliant is provided by either Netegrity SiteMinder or Oblix Enterprise
Identity Management software and can natively accept either PKI digital certificate or password based authentication
credentials.
Authorization provides granular access to system, information, and application resources. Embedded authorization
mechanisms along with role-based permissions will be used at the operating system, database, web/application server,
and application levels to protect the confidentiality of data either in storage or in system process. The Carlson eTS Solu-
tion will manage authorization across the system even with integration into the eAuthentication Gateway.
Availability provides protection against the loss of data or system resources, ensuring all aspects of the Carlson eTS
Solution remain available to those users who are authorized its use. A robust defense-in-depth architecture employing
both host and network based intrusion detection; firewall technology; anti-virus products; fully redundant systems with
automated fail-over capabilities; geographically disparate data centers; fully redundant telecommunications paths and
power supplies; mature disaster recovery and continuity of operations plans and procedures; and stringent configuration
and change management processes ensure the availability of the environment.
Data Confidentiality provides protection against unauthorized disclosure of sensitive information during transmission
over the network or during storage within the Carlson eTS Solution system. FIPS 140-1 & 2 certified SSL or TLS will
be used to ensure confidentiality of data in transit. Authorization mechanisms discussed above protect the confidential-
ity of data either in storage or in process. Native, FIPS 140-1 & 2 certified encryption features embedded in the Oracle
database will also be used to supply in-storage encryption where desirable. Confidentiality of authentication data in
storage is achieved through the use of FIPS 140-1 & 140-2 implementations of the Secure Hash Algorithm (SHA) at the
operating system and database levels.
Data Integrity provides for the protection of information from unauthorized modification or deletion during transmis-
sion over the network or during storage within the Carlson eTS Solution system. SSL will be used to ensure integrity.
Where strong data integrity is required, FIPS 186 certified digital signature technology will be furnished by Gradkell’s
DBsign product. DBsign has also been validated by DoD’s Joint Interoperability Test Command. FIPS 140-1/2 certi-
fied SSL or TLS will be used to ensure the integrity of data in transmission. Proven, industry standard applications and
database product lines will also provide integrity of data in process and in storage.
Identification provides standardized and secure mechanisms for defining, storing, and managing the Carlson eTS Solu-
tion system and user information. Systems (i.e., server and individual component) identification relies on PKI digital
certificates. Individual user identification relies on either PKI digital certificates or centrally managed, unique User IDs
issued through a point-to-point trusted distribution system. Should PKI certificates be used, these can either be Gov-
ernment issued PKI certificates or commercially issued certificates that are issued in accordance with Federal Bridge
guidelines. Identity Management services can be managed by either the Carlson eTS Solution or the Government’s eAu-
thentication Gateway.
Non-Repudiation provides for guaranteeing and verifying the origin, delivery and timing for trusted data, message, or
transaction exchanges. Cryptographic message digests are created so that the originator of a message or transaction can-
not falsely deny originating that message or transaction at a specific point in time. Gradkell’s DBsign product furnishes
the ability to time-stamp, sign and store digitally wrapped versions of forms for archival and later retrieval. The NTP
protocol ensures a reliable, synchronized system time is maintained throughout the enterprise so it can be applied as part
of the digital signature process.
A combination of methodologies can also be used within the Carlson eTS Solution workflow. For example, an Agency may
specify that user ID and password is sufficient for all system activities except for voucher submission for reimbursement
where a client certificate and full digital signature capability is required. Furthermore, security standards and Agency adop-
tion of existing and future security standards may not coincide with the adoption of the Carlson eTS Solution and can be
altered as necessary by the contracting Agency.
SECURITY CUSTOMIZATION
To provide broad and complete security requirements, the Carlson eTS Solution will enable different levels of security to be
specified by each contracting Agency. The Carlson eTS Solution provides the mechanisms to meet the Government’s tough-
est security requirements; however, these security requirements may be deemed restrictive to customer usability or may not
be supported by a contracting Agency. Every aspect of the Carlson eTS Security Solution is designed to permit individual
Integrating
eTravel Services
agencies/organizations to impose the proper types and degrees of security controls on their users. The following table out-
lines the eTS philosophy of delivering full functionality to customers at different security levels.
TECHNICAL SECURITY MEASURES
The diagram (Figure 1.4 – 2) on the next page presents the technical security measures active within the eTS hosting envi-
ronment. The defense-in-depth philosophy places multiple security mechanisms in-line to any request performed against the
system.
1.4.2 EAuthentication (RFP Reference C.6.5.2)
The Carlson eGov Solution’s LDAP and application security implementation, in conjunction with the eAuthentication Gate-
way (Interim & Final), will provide end-to-end security management services including management of privileges and access
control lists. The Carlson eTS Solution application ensures availability, confidentiality, and integrity by providing internal
user identity management, authentication, and authorization services.
The following products may be used to implement the Carlson eTS Solution security model:
Sun Microsystems Sun ONE Directory Server provides dedicated, secure LDAP directory services in a distributed
architecture with robust fail-over capabilities
Netegrity SiteMinder provides Policy Enforcement Point (PEP) functionality for integration into the Interim eAuthenti-
cation Gateway
Oblix NetPoint Access Management furnishes a secure, enterprise-wide single sign-on capability that can accept a
combination of User ID/Password and PKI digital certificate credentials
Gradkell DBsign Digital Signature offers robust, FIPS 186-certified digital signature capabilities that provide true data
integrity and nonrepudiation services capable of meeting all State and Federal legal requirements. DBsign uses “FIPS
140-1 & 2 certified cryptographic modules.
JAAS – Java Authentication & Authorization Service API (a J2EE API) – will be used for native Carlson eTS Solution
application security handling.
Tumbleweed Secure Email (Integrated Messaging Exchange) provides the capability to delivery, track, and guaran-
tee the privacy of all email.
Authentication and Identity Management can be provided either by the Carlson eTS Solution or the eAuthentication Gate-
way. When provided by the eAuthentication Gateway, user credentials, identity, and system roles must be maintained by the
eAuthentication Gateway with appropriate security interfaces to the Carlson eTS Solution. The Carlson eTS Solution LDAP
and application security implementation is used to manage internal access privileges of the Carlson eTS Solution environ-
ment and all user roles.
Integrating
eTravel Services
Figure 1.4 – 2
Figure 1.4 – 3 to the right provides a high level view of the Carlson eTS Solution authentication and authorization mecha-
nism. Included in the authorization process is integration into the eAuthentication Gateway and discrete role-based security
throughout the application. Security is provided at both the functional level (does the user have access to this piece of func-
tionality – Functional Security Framework) and at the data level (does the user have access to this piece of data – Data Level
Security Framework). The Carlson eTS Solution supports single sign-on through out all application functions including ac-
cessing reports and business intelligence services. Authorization is granted via the LDAP and application security
mechanism; within this directory structure, granular permissions allow existing user profiles and future user profiles to ac-
complish specific directives within the system.
Integrating
eTravel Services
Figure 1.4 – 3
Access control will provide system and information protection by limiting access to whom, how, and when it can be ac-
cessed. Granularity is even provided to the type of credential presented, permitting individual Agencies to adopt policies
which only permit the performance of certain operations if an individual has authenticated to the system with, for example, a
PKI digital certificate. The LDAP schema will be designed such that additional roles can be created to satisfy future Gov-
ernment and individual Agency requirements.
Security within the Carlson eTS Solution application is managed on a role basis according to the user types identified in the
RFP and modified within this proposal. These roles are authorized upon entry into the Carlson eTS Solution; portal and ap-
plication user interface components are only visible and accessible if the user has the associated privileges. Security
management procedures ensure the proper addition, maintenance, and deletion of personnel within security roles. The Carl-
son eTS Solution application will display all required security banners to all users as outlined within the RFP. As part of the
portal integration within the Carlson eTS Solution application, custom security messages can be delivered to users as neces-
sary.
Figure 1.4 – 4 provides an example of a Carlson eTS Solution security workflow using the eAuthentication Gateway:
Integrating
eTravel Services
Figure 1.4 – 4
1. The user starts at the firstgov.gov portal.

2. The user requests access to the eTravel portal. The eTS security mechanism checks for any existing, valid security cre-
dentials from the user.
3. In absence of existing, valid credentials, the portal asks the user to authenticate. The user provides credentials (either
user ID & password or certificate) to the eAuthentication Gateway for user identification and authentication.
4. The eAuthentication Gateway interim eAuthentication Gateway requests credential request information & validation
from the ECP (electronic credentials provider). The ECP returns the appropriate information and response based on the
user information.
5. Upon approval of a user’s credentials, a session cookie and a SAML artifact is returned to the user. The session cookie
in turn is sent to the Carlson eTS Solution system.
6. The Carlson eTS Solution receives the SAML artifact from the user and checks the SAML assertion with the eAuthenti-
cation Gateway. The eAuthentication Gateway confirms the artifact and provides the eTS with SAML assertion
containing the user’s ID, authentication and other data.
7. The Carlson eTS Solution verifies the user role’s level authorizations against the internal Carlson eTS Solution security
system. Upon verification of the permissions, the Carlson eTS Solution issues a non-persistent session cookie for the
user and returns the appropriate travel data to the user. Once authentication is complete, all eTS users have single sign-
on access throughout all eTS managed functions.
Note, SAML is not specified for use in the Interim eAuthentication Gateway. As such, Carlson will implement Netegrity as
a Policy Enforcement Point in the Carlson eTS accessing the Interim eAuthentication Gateway as Policy Decision Point
(PDP). Session Cookies will be created to provide authentication and authorization credentials.
Carlson has implemented an enterprise security solution based on the fully SAML compliant Oblix NetPoint Access Man-
agement solution. The security infrastructure provides single sign-on capability across the Carlson enterprise for both
internal and external personnel to access network resources such as VPN or application resources such as PeopleSoft and
Oracle Financials. While Oblix is not included as one of three selected products for use with Interim eAuthentication Gate-
way, Carlson will leverage its security and Oblix experience to integrate the Netegrity SiteMinder product into the eTS
solution.
Integrating
eTravel Services
1.4.3 PKI and Digital Signature (RFP Reference 6.5.2)

The Carlson eGov Solutions Team relies on a PKI managed by Verisign for server certificates to authenticate the identity of
eTS components (e.g., Web servers) to all system users. The system can support certificates generated by an alternative cer-
tificate authority including certificates generated by a Federal certificate authority as specified by a contracting Agency.
Future utilization of the Federal Bridge to enable trust across multiple certificate authorities is planned upon implementation
of the Bridge. Client certificates are expected to be managed by the contracting Agency Certificate Authority. When avail-
able, the eAuthentication Gateway will be used for user authentication and identity management.
The Carlson eTS Solution provides several mechanisms designed to ensure the data integrity and nonrepudiation throughout
the application and, more specifically, the workflow. For example, an agency may determine that the submission of a
voucher for reimbursement requires a digital signature whereas an authorization to travel only requires a Notary or Electronic
signature. The following table outlines the options available across the Carlson eTS Solution.
Client Security Ser- Level of

Signature Type Credential vice(s) Assurance Comments / Suggested Uses
Use with financial or other transactions where
Digital Signature – Client certifi- Extremely
Data Integrity true data integrity and/or nonrepudiation that
cate is used to cryptographically High can be used as the basis for criminal prosecution
“sign” time-stamped data along PKI Cert
in a court of law are required. This meets all
with information on the presenta- Extremely
Nonrepudiation requirements of current Federal Digital Signa-
tion of that data High ture legislation.
Assurance provided by security services limited
Data Integrity due to digital signature application at the server
High
(Limited) rather than client level – may not stand up to
PKI Cert scrutiny in legal proceedings. Use where rea-
Notary Signature – Server certifi- Nonrepudiation sonably strong assurances are required but true
cate is used to cryptographically High digital signature is not feasible due to client or
(Limited)
“sign” time-stamped data along other limitations.
with information on the user sub- Assurance provided by security services (espe-
mitting the data for signature and Data Integrity cially non-repudiation) limited due to digital
Moderate
the presentation of that data (Limited) signature application at the server rather than
User ID/PW client level – may not stand up to scrutiny in
Nonrepudiation legal proceedings. Use where reasonably strong
Moderate assurances are required but true digital signature
(Limited)
is not feasible due to client or other limitations.
Assurance provided very limited due to inability
‘Wet’ Signature / Scan – Process in
to prove imaged data was not modified or signa-
which the user enters all required Data Integrity
Low ture forged prior to electronic submission. Will
data into a form, prints a paper (Very Limited)
likely not stand up to scrutiny in legal proceed-
copy of that form, affixes their
User ID/PW ings – carries essentially the same weight as an
actual signature to the form, and
unauthenticated copy unless the original is kept
then electronically captures an
Nonrepudiation on file somewhere. Use only for routine trans-
image of that form for electronic Low
(Very Limited) actions where stronger assurances are not
submission
required/available.
May offer a modicum of nonrepudiation in the
Electronic Signature – “Pseudo-
sense that the individual had to enter their au-
signature” process in which the
Nonrepudiation Extremely thentication credential at the time of submission,
user re-enters their authentication User ID/PW
(Minimal) Low but realistically offers extremely little assurance
data to simulate signing as the last
of any kind. Only use if all other methods are
step in submitting data
not feasible.
Figure 1.4 – 5 details the implementation of the digital signature mechanism as implemented by the Gradkell DBsign solu-
tion. Note, in order to implement digital signature capabilities the client must sign the data and presentation as presented to
the user. As such, digital signature capability requires the usage of a signed plug-in within the user’s browser.
Integrating
eTravel Services
Figure 1.4 – 5
1.4.4 Web Browser Security (RFP Reference C.6.5.3)

The Carlson eTS Solution is based upon a standard thin client architecture that does not require potentially harmful mobile
code. The Carlson eTS Solution application will use client-side JavaScript to provide field validation within web forms; the
JavaScript will perform no business logic or client interaction. Using JavaScript is an important element of creating an effi-
cient web application that minimizes round-trip requirements to the Carlson eTS Solution servers. No technologies explicitly
prohibited in the RFP are used on the browser of Carlson eTS Solution users. Note, in order to implement digital signature
capabilities, plug-in software operating on the client machine must perform the signature logic.
1.4.5 Data Security (RFP Reference C.6.5.4)
The Carlson eTS Solution provides complete data security through insurance of integrity and confidentiality, data encryption
(128-bit encryption), strong user authentication and authorization practices, and nonrepudiation. Figure 1.4 – 6 outlines the
Carlson eTS Solution, the secure methods by which system actors interact with the system, and the utilities in place to ensure
data security.
The Carlson eTS Solution provides digital signature support by implementing the Gradkell DBsign product. The Carlson
eGov Solutions Team will work closely with the GSA and all implementing Government Agencies to determine which data
must be signed. The Carlson eTS Solution digital signature infrastructure will verify all acceptance criteria before generating
the digital signature including data validation, data integrity verification, user authentication, and user authorization. Digital
signatures will rely on client certificates and Carlson eTS Solution security mechanisms to verify the digital signature. To
provide the necessary information for review after a user’s certificate may no longer exist, all relevant digital signature in-
formation will be stored by Carlson eGov Solutions Team in a centralized digital signature repository.
Integrating
eTravel Services
Figure 1.4 – 6
1.4.6 Personnel and Physical Security (RFP Reference C.6.5.5)

Personnel and physical security covers all implemented controls and security mechanisms to prevent internal and external
unauthorized access to any eTS system components or data. Administrative access to all hardware and software components
is accomplished via a Secure ID 2 Factor Authentication method that requires certificate and PIN authentication and authori-
zation for access to any system component. The solution offers complete nonrepudiation services against any changes that
are made to the environment. A detailed security plan surrounding physical access to all relevant Carlson eTS Solution sys-
tem components will be provided to the Government. These plans will address all Government referenced security
regulations and will be refreshed regularly to maintain compliance with Government and industry standards and best prac-
tices.
Device level security is augmented by strong change management procedures to approve and authorize changes. All authen-
tication and authorization to administer infrastructure components is managed by the centralized authentication and account
management procedures. Access Control to all network, server, and software resources is tightly managed and periodically
reviewed to ensure ongoing compliance. System change management mandates that all access to administrative resources be
approved and that resources accessing administrative capabilities are only given as necessary. Administrative security man-
agement provides the necessary tools and controls to securely and effectively manage relevant security information used to
control access to and monitor system and application resources including but not limited to:
User Access Accounts, Operating System Privileges Network Devices - Firewall Policies, Routing Tables
Access Control Lists Identity Information
Certificates & Keys System Logs
Application Server Software, Administration Consoles, Database
Administration Scripts
DATA CENTER
The Carlson eGov Solutions Team is responsible for ensuring compliance with security standards across both data center
providers. Both data centers feature multiple security checkpoints and dedicated physical hosting space that is physically
separated and secure from all other customers. All physical access to eTS data centers or other physical facilities that sup-
port the eTS will be restricted to those with a clear and demonstrated business need. Access lists will be reviewed on a
regular basis to ensure ongoing compliance with this requirement. Carlson currently performs background checks for per-
sonnel with access to secure facilities and sensitive data and will modify or amend these procedures as needed to meet the
standards specified by contracting Agencies.
Integrating
eTravel Services
NETWORK, HARDWARE, & SOFTWARE

The network is secured using industry standard network security solutions including firewalls (Checkpoint & Cisco PIX),
intrusion detection devices, and host based intrusion detection. VPN (Cisco VPN) for administrative access to Carlson eTS
Solution devices uses IPSEC and a multi-layer anti-virus solution is implemented throughout the system. File integrity
(Tripwire & ISS) is continuously monitored and verified across all system servers preventing any unauthorized changes to
system content and functionality. Carlson and its hosting partners use a rigorous certification process prior to releasing any
new hardware devices or software releases into the environment. Operating system and software hardening standards are
developed using vulnerability scans to eliminate unnecessary operating system access for Windows and UNIX based sys-
tems; this locks down all software to a least privilege model of access.
The Carlson eTS Solution hosting operations and business operations manage, monitor, engineer, and upgrade software re-
leases, patches, and security releases as necessary. The operating system and software environment is engineered such that
common builds are used throughout a system implementation by using automated build scripts. The following processes and
procedures further guarantee security:
Vulnerability scans are automatically performed at regular intervals.
Infrastructure Account Reviews are automatically performed at regular intervals; Carlson eGov Solutions Team will
work with any Agency to customize the review criteria used during account reviews.
Firewall and Router Rules are automatically reviewed on a regular basis to eliminate unnecessary port openings and old
routes from remaining within the routing rules.
Reports and recommendations from automated scans are delivered to the operations management tools used by Carlson
eGov Solutions Team Operations for the management of the Carlson eTS Solution hosting environment.
1.4.7 Supplemental Security Services (RFP Reference C.6.5.6)
Carlson eGov Solutions Team will provide a process to work with Agencies that require a higher level of security than the
base eTS provides. This process will ensure that costs associated with design and implementation of these additional meas-
ures will not impact the base cost of the eTS. The security mechanisms and infrastructure as described previously are
designed to meet the unique security requirements that individual Agencies may require. Security mechanisms will be re-
viewed with contracting Agencies and modifications made as part of the Agency integration process.
1.4.8 Government Access (RFP Reference C.6.5.7)
The Carlson eTS Solution will provide Government and private entities audit access to all system components as required by
SOO; schedules to do so will be arranged with contracting Agencies during integration activities. Furthermore, the Carlson
eTS Solution system is designed to retain, log, and report against the application and its security components to provide eas-
ier access to auditable material.
1.4.9 Subcontractor Security (RFP Reference C.6.5.8)
Carlson Companies is responsible for and will ensure that any and all subcontractors that support the Carlson eTS Solution
comply with the security standards specified and referenced by the GSA, by the RFP, and by contracting Agencies during
implementation.
1.4.10 Security Management, Plan, Process, Certification Process (RFP Reference E.6.1 Factor 4)
Carlson understands that the eTS will need to undergo formal security certification and accreditation (C&A) to meet the re-
quirements of Office of Management and Budget (OMB) Circular A-130 and GSA’s implementation of the OMB Circular
embodied in their IT Security Procedural Guide 01-09, as well as the objectives of the General Accounting Office’s (GAO’s)
Federal Information System Control Audit Manual (FISCAM). This will entail obtaining an initial full approval to operate
(ATO) on the objective eTS system and also intermediate ATOs for various phases of the development and implementation
effort. Carlson intends to establish early and continuous coordination with the Designated Approving Authority (DAA) and
Certification Authority (CA) to determine expectation and develop an appropriate level of evidence to support a decision by
the DAA to issue an ATO or Interim Approval to Operate (IATO), as appropriate.
Coordination with the DAA and CA is also essential to ensure well-established procedures are defined as appropriate and
agreed upon which permit Carlson to quickly and easily add functional capabilities to support various customer needs as part
Integrating
eTravel Services
of an overall modular systems design (these procedures will be woven into the change, configuration, and release manage-
ment processes utilized by Carlson). This will permit Carlson to establish approved processes that reduce the impact of
system changes on the existing ATO and define thresholds for re-accreditation. To ensure the ATO will be universally ac-
ceptable among the wide range of potential Federal Government customers, Carlson recommends the use of the National
Institute of Standards and Technology (NIST) National Information Assurance Certification and Accreditation Process
(NIACAP). Patterned very closely after the DoD Information Technology Security Certification and Accreditation Process
(DITSCAP); the NIACAP supports all required C&A activities embodied in GSA IT Security Procedural Guide 01-09 and
permits the use of multiple requirements sources such as the FISCAM. The close relationship between the NIACAP and the
DITSCAP also means that an ATO will be easily accepted by the Armed Services as Carlson looks to market eTS to the DoD
community.
Carlson teammate SNVC (and partners) has extensive C&A experience developing and implementing a variety of tailored
C&A efforts, combining the latest industry best practices with their intimate knowledge of ongoing and emerging Govern-
ment standards and initiatives to obtain ATOs in accordance with a wide range of Government standards such as Common
Criteria, NIACAP, FISCAM, DITSCAP, and Director of Central Intelligence (DCI) Directive 6/3. Carlson recognizes the
importance of an integrated approach to organizational security that incorporates both the latest technical measures, such as
smart cards, public key technology, and biometrics, with proven procedural measures in disciplines such as information, per-
sonnel, and physical security. The Carlson eGov Solutions Team brings experienced personnel who are well-versed in these
disciplines to the eTS C&A effort, including former military specialists who have conducted personnel security clearance
investigations, counterespionage operations, and counter terrorist operations; performed physical security compliance and
penetration inspections in support of DoD installations, sensitive DoD operations, and special munitions programs; supported
information security activities involving the highest levels of classified information; and designed, developed, implemented,
assessed, and accredited secure IT solutions ranging from multi-level secure workstations to fully integrated enterprise IT
solutions.
SNVC’s partner Veridian is an ISO 9001:2000 certified organization that brings to the Carlson team a proven requirements-
based risk assessment process applied by highly skilled and knowledgeable security professionals incorporating a wide range
of disciplines. VITS personnel and processes ensure that the security solutions applied provide cost-effective solutions that
appropriately mitigate the risks identified and fulfill the security requirements applicable to the specific system or activity
being supported. Security analysts review organizational structure and business practices, interview key personnel, observe
site activities, and gain a thorough appreciation of the functions and operational objectives of the organization. The impor-
tance of information, systems, and operations to the overall success of the organization is identified. Next, security analysts
examine the specific systems and operations of the activity to identify security weaknesses. A weakness is defined as any
inherent characteristic of a system, organization or activity that could potentially leave organizational information or re-
sources susceptible to harm. Data on known or reasonably postulated threats to the system, organization or activity is also
collected. Threat agents (entities with a known or postulated capability and intent to bring the threat to bear against the sys-
tem) are identified. These threat agents may be natural (e.g., flood, fire, earthquake, lightning, power interruptions) or man-
made (e.g., criminals, hackers, viruses, civil disturbance). If a weakness may be exploited by a threat agent (adversary or
natural event) to the detriment of system users, this weakness constitutes a vulnerability; vulnerability = risk. The likelihood
of successful exploitation of the vulnerability is then compared against the degree of harm if the exploitation is successful to
determine the resulting risk. A risk level is assigned to indicate the seriousness of the risk. Security analysts then provide
detailed recommendations for mitigating risks through the application of tailored countermeasures, along with an assessment
of the return on investment (ROI) that an organization can expect from the application of each countermeasure. No organi-
zation or IT system can operate free of risk and the ROI is an important element in making sound risk management decisions.
Where appropriate, countermeasures are then integrated into the overall systems design effort and serve as the basis for secu-
rity enhancements to the objective system.
Figure 1.4 – 7 depicts VITS’ Risk Assessment Methodology, which serves as the cornerstone of their C&A activities and
provides a risk-based approach to information assurance. This risk-based approach is inherently designed to produce a sys-
tem which can achieve an ATO with little additional time or effort through the application of proven risk management
strategies.
Integrating
eTravel Services
Figure 1.4 – 7
Sound engineering practices applied by experienced systems and security engineers have already resulted in the generation
of much of the systems documentation and test evidence that will be required to support an ATO for the current system. As
a world-renowned travel provider whose daily operations depend on IT support, Carlson routinely maintains extremely de-
tailed and mature organizational plans and processes, such as a Contingency Plan that addresses disaster recovery and
continuity of operations, a Configuration Management Plan that includes a robust change management process, and formal
developmental test procedures that are conducted in an independent development environment isolated from the operational
system environment, already exist and were in force well before the advent of this opportunity. In addition, detailed system-
specific design documentation and operations and maintenance procedures for the existing eTS system have already been
produced as an integral part of Carlson’s IT standard development methodology. This existing documentation will be sup-
plemented by the security-specific documentation, such as the Systems Security Authorization Agreement (the NIACAP
equivalent of the Systems Security Plan), Security Requirements Traceability Matrix, and Residual Risk Assessment, re-
quired to achieve an ATO. The Carlson eGov Solutions Team is prepared to either support an independent certification team
chosen by GSA, provide highly skilled technical security personnel to serve as the certification team in support of the Gov-
ernment-appointed CA, or even provide an independent CA with a separate reporting chain in support of the DAA. At the
Government’s discretion, this may include the development of the Security Test and Evaluation (ST&E) Plan, to include all
associated ST&E procedures. The ST&E Plan and Procedures will include a traceability matrix indicating which tests serve
to assess the implementation of which security requirements and controls, such as those critical elements within the Security
Program Planning and Management (SP), Access Control (AC), Software Development and Change Control (CC), System
Software (SS), Segregation of Duties (SD), and Service Continuity (SC) areas of the FISCAM.
Experienced security analysts are already working hand-in-hand with systems engineers as the next version of the existing
Carlson system is being designed and implemented to add functionality and prepare to support interfaces to other Govern-
ment IT enterprise operations begin by examining the organization to identify protection needs. As part of this effort, a
formal connection approval process is being developed. This connection approval process will include uniform Systems
Interconnect Agreement (SIA) templates to serve as formal Memoranda of Agreement (MOAs) between systems owners and
incorporate any appropriate Service Level Agreements (SLAs). Through the application of a robust connection approval
process and standardized SIA templates that are pre-coordinated with the DAA, Carlson will reduce the time and effort re-
quired to initiate service for new Government agencies and establish approved interfaces with their systems. Where
additional ATOs are required due to the introduction of additional functionality, further requirements, or changes in the op-
erational environment resulting from the organizational systems being added, the Carlson eGov Solutions Team will either
pursue an Interim Approval to Operate (IATO) for the revised system or a full ATO, whichever is appropriate.
The use of automated tools (e.g., ISS Scanner suite, Harris STAT, Nessus, nmap, War Dialer, ToneLoc, Phone Sweep, Ne-
tRecon) plays an important role in periodically assessing the security posture of the eTS system. These will be augmented by
Integrating
eTravel Services
the use of customized scripts such as the Security Readiness Review (SRR) scripts put out by the Defense Information Sys-
tems Agency (DISA), which check systems compliance with published National Security Agency (NSA) configuration
guides. Through a combination of constant re-evaluation of systems security and a proven change management process that
routinely monitors vendors for patches, subscribes and reacts to vulnerability notices, and thoroughly test all changes prior to
implementation, eTS will remain secure and available to meet the needs of GSA customers and travel services consumers at
all levels of Government.
1.5 Data Management Approach (RFP Reference E.3.4.2.1.2, Item 5; E.6.1 Factor 5)
On the following pages, Carlson describes our approach to data, integration, and information management including records
retention, archiving, and reporting that meets the SOO mandatory requirements and objectives. The description also includes
detailed specification of Carlson’s proposed Standard Data Output.
1.5.1 Data Exchange (RFP Reference C.6.7.2)
The Carlson eTS Solution provides a common data exchange and Enterprise Application Integration (EAI) environment de-
signed to integrate all required interfaces necessary to implement an end-to-end solution. The data exchange infrastructure
supports real-time, near real-time, and batch communications through a variety of Government standard transmission formats
including XML, EDI, and User Defined Formats (UDF). Figure 1.5 – 1 presents the high-level eTS EAI solution.
The EAI capability provides a common framework for integrating various systems making it faster and easier to tie together
applications so they can be integrated into business processes across the system, customers, and suppliers. As required in the
solicitation, the data exchange and EAI capability reduces the complexity of the IT infrastructure and dramatically improves
its integration, reliability, flexibility and scalability. The EAI solution will handle both intracompany information sharing
between multiple systems and business-to-business (B2B) information sharing between multiple customer and supplier sys-
tems. By implementing a complete EAI/B2B solution, Carlson is positioned to meet the following integration touch points:
1) Data, 2) Processes, and 3) Collaboration. By example, companies might want to share a catalog (data), agree to modify a
product for a buyer’s specific needs (collaboration) and then turn a PO into an invoice (process). In its initial release, the
Carlson eTS Solution requires the sophisticated data integration capabilities. However, by leveraging the EAI capabilities,
the eTS can be extended to include additional collaborative capability (e.g. event planning) and business process manage-
ment capability (e.g. eTS workflow is integrated into agency business systems such financial approvals).
The data exchange and EAI environment relies on the eTS security model to ensure that transactions are completely secure.
The following features are integrated into the EAI solution:
JMS (Java Messaging Service) is used for message queuing of incoming and outgoing messages.
Integrating
eTravel Services
Usage of XML (XSLT, Schemas, etc.) and Web Services (SOAP, WSDL, etc.) provides integration with legacy systems
and emerging systems.
The data exchange architecture will be open and extensible to enable ease of integration as well as leverage standards to
improve usability over time.
The Data Exchange mechanism meets the following requirements:
Two-way exchange of Federal travel data with Agency business systems in real-time, near real-time, and batch modes.
Two-way exchange using synchronous and asynchronous protocols.
Two-way transactional data exchange with external systems to support business requirements such as funds availability
checks, payment actions, etc.
Support of EDI, UDF, and XML formats.
The eTS Solution uses JMS (Java Messaging Service) to implement message queuing for incoming and outgoing messages
to the EAI Messaging Bus. The usage of the EAI environment and JMS enables near real-time and batch integration with the
business systems of Federal Agencies as well as with commercial systems as required. The EAI platform supports data and
format translations for inbound and outbound data exchange. Standard data input and output formats, schema, and method-
ologies will be defined and implemented to meet requirements in C.6.7.2.1 of the RFP.
Figure 1.5 – 1
For integration into agency systems and other external systems, the eTS relies on message based, asynchronous communica-
tions enabled by the EAI environment. In doing so, the eTS is designed not to rely on synchronous communication
technologies such as Object Request Brokers and Remote Procedure Calls.
1.5.2 Integration Support (RFP Reference C.6.7.2.1; C.6.7.3)
The Enterprise Application Integration (EAI) capability provides a common framework for integrating various systems, mak-
ing it faster and easier to integrate applications required of the end-to-end solution.
Integrating
eTravel Services
Standard data input and output formats will be defined and implemented to meet requirements. This enables Federal Agen-
cies to integrate their systems with the Carlson eTS Solution using the EAI capability. The EAI platform infrastructure
includes flexible scheduling, transport, routing, and format translation services (both inbound and outbound). Agencies that
need to integrate or exchange data with Carlson eTS Solution will be provided appropriate access, security credentials, and
licenses to use the platform.
Carlson eGov Solutions Team will coordinate with Federal and GSA-authorized commercial external system owners to fa-
cilitate the establishment of Integration Agreements and interfaces that facilitate data exchange, mapping, translation,
transport, and scheduling requirements to support Federal travel management functions within the scope of the eTS.
The following products are used to provide EAI services:
TIBCO Rendezvous is used for application messaging services (MOM – message oriented middleware) and enterprise
data transformation.
TIBCO BusinessWorks
TIBCO BusinessConnect
TIBCO Hawk
TIBCO Enterprise JMS Server
TIBCO Adapters (SDK, JDE One World, PeopleSoft, Teradata, LDAP, Active Database, Oracle Applications, Files,
EJB, COM, & others as required)
TIBCO Portal Builder is one of two portal tools used for delivering portal functionality to customers, suppliers, and
partners. ClearNova ThinkCAP also offers portal functionality within a development that operates within an applica-
tion.
The TIBCO solution supports a broad range of industry standards necessary to provide a complete EAI solution including:
XML (cXML, ebXML, XSLT, XPATH, etc.)
Web Services (SOAP, WSDL, UDDI, ebXML, etc.)
J2EE (JMS, EJB, JCA, etc.)
RosettaNet
EDI (VANs, ANSI, X.12, EDIFACT, etc.)
Mainframe Technologies (CICS, OS390, DB2, etc.)
Legacy Transport Technologies (COM, CORBA, MQSeries)
Process Management Standards (UML, WSFL, BPML, etc.)
While the overall eTS Solution requires a unique solution, it contains many industry standard interfaces for which XML,
EDI, and other data exchange standards exist. By using the Carlson global EAI solution, Carlson can deliver the capabilities
to use all of these different means, protocols, and solutions to integrate without incurring the EAI expense to one system.
Carlson will always leverage existing industry and government standards instead of creation proprietary, custom standards.
The travel industry, for example, via the Open Travel Alliance (OTA) is defining common XML (& ebXML) schema’s for
usage in travel data exchange. Carlson, a member of the OTA, leverages these standards for the ease of integration, reduc-
tion in cost and support to integrate, and the benefit that it provides to our customers as well. By using these standards
customers can expect
Improved communications between customers, suppliers, and partners by using a common shared understanding of data
definitions and transactions
Shortened development cycles to the extent that standards map to application requirements
Reduced development risk in that industry standards represent the collective learning and effort of the industry
A neutral starting point to drive consensus across all parties
Proprietary standards will be created when standards are incomplete or unavailable for integration requirements.
Figure 1.5 – 2 presents the technical capabilities of the Carlson EAI system as enabled by the TIBCO products. Descriptions
of each layer are provided within the diagram.
Integrating
eTravel Services
Figure 1.5 – 2
Feature functionality will continue to be added and updated; as the business and technical capabilities of the eTS are ex-
tended additional interfaces will be required such that usage of a sophisticated EAI tool is critical for the efficient and
effective cost, functional, and operational management of the product.
1.5.2.1 DATA INTEGRATION – STANDARD INPUTS AND OUTPUTS (RFP REFERENCE C.9.2)
Carlson has reviewed the standard data elements published by the government and the eTS solution will support EDI, XML,
and UDF formats to support standard data input and output.
Carlson will always use industry standards when available. While the overall eTS Solution requires a unique solution, it con-
tains many industry standard interfaces for which XML, EDI, and other data exchange standards exist. By using the Carlson
global EAI solution, Carlson can deliver the capabilities to use all of these different means, protocols, and solutions to inte-
grate without incurring the EAI expense to one system. The eTS supports data integration across both legacy exchange
methodologies and emerging standards such as Web Services; as the system matures and interfacing systems different inter-
faces (integration points) will leverage newer standards.
Standard data outputs will be created for all required Agency Business System interaction including funds availability, sys-
tem credits, payments, tax reporting, travel advance liquidation, amount due, operational reports, and other standards
Integrating
eTravel Services
required for interface to financial, human resource, and payment business systems. Carlson prefers to create manageable
standard data outputs relevant to the service or system that will use the data. Understanding that Agency Business Systems
may want a comprehensive set of eTS data, Carlson will support a complete data output that supports all Standard Data Ele-
ments for Exchange. Appropriate Integration Agreements will be created for all interfaces and integration points.
EDI (ELECTRONIC DATA INTERCHANGE)
Carlson has currently implemented the following EDI transactions for financial Business to Business Interchanges and can
support other standards as necessary:
EDI Standard Version

867 inbound 3020, 3030, 4010
820 ACH outbound 4010
820 FX Drafts outbound 4010
820 FX Wires outbound 4010
820 USD Wires outbound 4010
824 Issuance inbound 4010
821 Paid Items inbound 4010
828 Check Issuance out 4010
820 Purchase order 4010
810 Invoice 4010
850 Purchase order 4010
997 Functional Acknowledgements 4010
XML (EXTENSIBLE MARKUP LANGUAGE)

XML is widely used throughout the system and is the preferred format for all data exchange activities. Using international
standards bodies, the Federal Draft XML Developer’s Guide, and the standard data elements outlined in Attachment 14B,
Carlson will create both input and output specific XML schemas (HR, Financial, Payroll, etc) and complete standard data
outputs according to the Government Standard Data Elements. Note: the data elements required by the system will be modi-
fied and/or expanded according to implementation requirements and future functionality development.
The following examples represent the creation of a standard XML schema for the processing of travel advances as identified
in the Standard Data Elements. Hypothetically, data extracts for Travel Advances would be consumed by the Agency Busi-
ness Systems. Figure 1.5 – 3 represents the structure of the XML Schema for the Travel Advance extract:
Integrating
eTravel Services
Figure 1.5 – 3
The XML Schema is represented as follows (XSD Examples):
<?xml version="1.0" encoding="UTF-8"?>


<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified" version="1.0">
<xs:element name="eTS_TravelAdvance">
<xs:annotation>
<xs:documentation>A collection of Unique IDs of Advances</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element name="AdvanceInfo" maxOccurs="unbounded">
<xs:complexType>
<xs:sequence>
<xs:element name="ProfileID" type="xs:integer"/>
<xs:element name="TripID" type="xs:integer"/>
<xs:element name="AdvanceID" type="xs:integer"/>
<xs:element name="LinkedAuthorizationID" type="xs:integer" minOccurs="0"/>
<xs:element name="BalanceRemainingOnAdvance" type="xs:decimal" minOccurs="0"/>
<xs:element name="ProcessingStatus" type="xs:string" minOccurs="0"/>
<xs:element name="ProcessingStatusReason" type="xs:string" minOccurs="0"/>
<xs:element name="ProcessingUpdateOfficialETSUserID" type="xs:string" minOccurs="0"/>
<xs:element name="ProcessingUpdateTimestamp" type="xs:date" minOccurs="0"/>
<xs:element name="AdvanceType">
<xs:complexType>
<xs:sequence maxOccurs="unbounded">
<xs:element name="AmountPaid" type="xs:decimal"/>
<xs:element name="PaymentMethod" type="xs:string"/>
<xs:element name="PaymentIdentification" type="xs:string"/>
<xs:element name="PaidDate" type="xs:date"/>
<xs:element name="RetainedTravelFlag" type="xs:boolean" default="0"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
Integrating
eTravel Services
</xs:element>
</xs:schema>
UDF (USER DEFINED FORMAT)

The system supports complete creation and consumption of UDF files such as flat files, comma delimited files, and tab de-
limited files.
The usage of the Carlson EAI enables UDFs to be translated into data formats that are meaningful to Carlson eTS applica-
tions. The following example is a tab-delimited text file format.
The UDF text file consists of records according to the following definitions.
• Each line in the text file is a record.

• Each record may consist of several fields, separated by a field separator (column delimiter). The tab and comma
characters are field separators.
• Space characters around a tab or comma are ignored and considered part of the field separator. Text strings are en-
closed in quotation marks to ensure that any embedded spaces, commas and tabs are not mistaken for field
separators.
• The group of records at the beginning of the file is called the file header.
• The file header describes the file structure and includes column titles, units, and comments.
The follow example presents a UDF example:
First header record Format: XYZ (all caps), Version number
Second header record Number of optional header records n,
Number of data columns (fields) m
1st optional record ...
2nd optional record ...
nth optional record ...
n+3)th record Required record containing m fields.
Each field contains a column title.
DATA RECORDS Arranged in m columns (fields) of data.
1.5.3 Information Management - Reporting (RFP Reference C.6.7.4)

The Carlson eTS Solution provides direct query and reporting capabilities from the eTravel portal. All eTS Standard Reports
are generated against both the Carlson eTS Solution reporting database while all Business Intelligence Reports are generated
against the data warehouse. Reports against in the data warehouse are covered in the business intelligence section below;
queries and reports against the operational database are covered in this section. Figure 1.5 – 4 represents the eTS reporting,
querying, data warehouse, and business intelligence solution and applies to all data warehouse, reporting and querying, and
business intelligence capabilities.
The reporting tool allows users to generate reports and execute queries in accordance with the FTR Section 300-70 and
Chapter 304 for travel management and Agency reporting. All relevant travel data as specified in FTR Chapter 301, Appen-
dix C is maintained in the Carlson eTS Solution reporting database. Reporting and querying capabilities extend to all
operational data including against future travel arrangements and vouchers in process.
Reports are generated and accessed through the eTravel portal using a web browser; the user’s security permissions will de-
termine what reports are visible and what data can be queried against. Reporting options allow users to generate reports at
various levels of an organization’s hierarchy and include reports providing detailed information or summary type informa-
tion. Reports as specified in Attachment 7 of the solicitation are standard reports provided by eTS reporting engine including
Total Travel Report, Agency Travel Report, CPP Travel Report and CPP Audit Report.
Integrating
eTravel Services
Figure 1.5 – 4
Users will have the capability to perform pseudo ad-hoc queries and generate custom reports based on their security authori-
zations and the set of data elements defined for the report (e.g. dates, city pairs, user, etc.) Users with appropriate
permissions will be provided access to download report data into other tools for further analysis. For example, users will be
able to download the report data as an Excel spreadsheet and use the Pivot tables feature within Microsoft Excel to do further
analysis of the data.
The eTravel portal and all features and services included within it are part of an open standard based technology that can be
easily extended and integrated with other tools to provide additional functionality. The Carlson eTS Solution reporting tool
contains a very robust and intuitive querying tool that enables users to write powerful and efficient queries to fetch relevant
information contained with the eTS. Standard reports provided by the eTravel portal include but are not limited to:
Total spend for travel and transportation
Average costs of trips
Average duration of trip
Report listing of special travel arrangements (e.g., first-class travel with justification)
1.5.3.1 CUSTOM REPORTS (RFP REFERENCE C.7.4.3)
If the standard reporting capabilities of the eTS do not meet an agency’s reporting needs, the eTS reporting engine can be
extended as necessary. The standard reporting engine provides very flexible query options for reporting needs; this flexible
reporting model allows custom reports to be easily integrated into the system capabilities.
1.5.4 Information Management – Data Warehouse (RFP Reference C.6.7.1)
The usage of the data warehousing and business intelligence capabilities of Carlson will help Government Agencies and the
GSA to realize many of the full objectives of the eTravel System. By providing a solution that aggregates data from numer-
ous sources, transforms that data into a meaningful format and applying best of class analytic and reporting tools,
Government users will have access to complete Government travel data and information unlike ever before. Specifically,
decision makers will have the holistic view necessary to chart future government travel strategy, contracts, and policies by
creating city pair utilization, preferred supplier and carrier utilization, travel trend analysis, budget management capabilities,
real-time spend analysis, and regulatory compliance reports. All Carlson business intelligence capabilities allow for the
download of data for additional analysis and the capability to drill-down to data specifics or view reports at a summary level.
Integrating
eTravel Services
In short, the use of these tools will provide the unprecedented integrated business reporting capability for all Government
Agencies across all Branches.
To deliver data warehousing and business intelligence capabilities, the Carlson eGov Solutions Team uses a custom devel-
oped tool called Discovery®. Discovery® currently delivers full functionality to over 600 clients in the commercial travel
business around the world. The following industry standard tools are used to implement the data warehouse:
Database Oracle w/ Partitioning

Data Extraction Transformation Load Informatica
Enterprise Application Integration TIBCO
Creation of an effective data warehouse is concerned with the extraction, scrubbing, aggregation, and transformation of data.
The business intelligence section will present the Carlson eTS Solution’s mechanisms of presenting the data to Government
users. The primary purpose of the business data warehouse is to create a data repository that provides business intelligence
capabilities to Government users. All warehouse data is transformed into an easily accessed and powerful information
source for decision support. Figure 1.5 – 5 provides a view of the activities that occur to create an effective data warehouse.
Carlson has leveraged its travel industry expertise and breadth to deliver a data warehouse which contains relevant data to
government and corporate travel decision makers. The data warehouse supports tactical and strategic decision-making by
delivering the following functions:
Transparent and efficient information access to all relevant travel itinerary, expense management, and voucher informa-
tion including purpose of travel, exception codes and justifications for not using mandatory and/or preferred travel
suppliers, flight information, and travel cost information.
Consolidated into a common data warehousing infrastructure maintained separately (logically and physically) from op-
erational systems.
Provide detailed and summarized historical data drawn from multiple operational systems (and external sources) for
analysis and decision support.
Key characteristics of the eTS data warehouse include:
Subject Oriented - Organized by subject, not application
Integrated - Compiled from multiple operational systems and external sources
Time Variant - Accurate as of a moment in time; a dated snapshot
Non Volatile - Existing data is not changed, additional data is added
Derived - Refined from primitive operational data that has been organized in a meaningful context
A successful data warehouse will deliver to the following attributes:
Data that is available and being utilized across a wide spectrum of business users
Dramatically increased productivity among knowledge workers
Speed--not on-line response, but task performance (retrieve, compile, analyze, report)
Quality--better, quicker decisions
In order to deliver a data warehouse that meets these requirements, Figure 1.5 – 5 depicts the life cycle that is used:
Each iteration of the data warehouse makes use of the following best practices:
Integrating
eTravel Services
Understand the different life cycle development methodology

Migration to data warehouse is evolutionary
Develop iteratively--avoid the big bang approach, build on previous sections
Develop a strategy for building the warehouse
Keep the business needs in clear focus
Design for Subject Area that provides the highest return
Choose a small pilot to begin but keep the long term focus
The data warehouse is populated and enabled by the data layer whereby data from multiple sources is collected, cleansed,
and standardized. The data layer is responsible for providing the means to receive transactions from external systems (based
on EAI capabilities) and perform any necessary data transformations, filtering, and extraction. The second layer is the pres-
entation layer. The business intelligence layer is where the data is processed into information and delivered as reports,
cubes, or extracts through the web, paper, or other media.
Data warehouse data is sourced primarily from the eTS reporting database, but will also handle inputs via other internal back
office systems (accounting system), external partner systems (booking engines, GDS’), and external customer systems.
The frequency of refresh of data may vary from source. Furthermore, data from the operational system may represent an
incomplete eTS workflow. As data meets the characteristics as described above, it will be added into the data warehouse.
The data extraction process is currently run weekly.
The Carlson eGov Solutions Team data warehousing, business intelligence and reporting solution is built on the following
technology set:
Database Management System: Oracle (with partitioning ) (Data Warehouse)
Data Extraction Transform Load (ETL): Informatica (Data Warehouse)
Information Delivery Tools: Actuate, Cognos (Business Intelligence)
Web Presentation: Java Portlet (Business Intelligence)
As part of the integration effort, the Carlson eGov Solutions Team will work with contracting Agencies to extend and cus-
tomize the standard data warehouse information model. The Discovery® tool offers client defined data mappings and data
translations as part of the service offering. This information will be documented in the Data Management Plan. Figure 1.5 –
6 depicts our concept of the business intelligence and data warehouse environment. All eTS data and eTS specific data mod-
els will be deemed as property of the Government and protected according to the provisions of the Privacy Act. Upon
expiration or termination of any data warehouse contracts, Carlson will gracefully discontinue data warehouse updates and
provide all data warehouse contents to the government either through data exchange means or durable electronic media. Any
incomplete or in-process travel authorizations will be identified accordingly.
1.5.5 Information Management – Business Intelligence (RFP Reference C.6.7.5)
The business intelligence layer of the Carlson eGov Solutions Team Discovery® solution provides business users with ac-
cess to information in a form they need and understand. It comprises data preparation routines and information abstraction
objects. The tools query information and contain functionality to manipulate the response in the format needed by the user.
Furthermore, they provide reporting and graphing capabilities to extrapolate and present information in user presentable for-
mat via a web browser.
Integrating
eTravel Services
Figure 1.5 – 6
Business intelligence capabilities are also valuable to numerous eTS actors including the FTSA, FFTA, FAA, FAPC, FATA,
and FATC. Depending on the level of the user and the associated security permissions, Business Intelligence can provide a
wealth of valuable decision-making information.
The Business Intelligence layer of the Discovery® solution provides business users with access to information in a form they
need and understand. It comprises data preparation routines or information abstraction objects. The tools request informa-
tion (query), and contain functionality to manipulate the response in the format needed by the business user. They provide
query, reporting and graphing capabilities to extrapolate and present information in user presentable format via a web
browser. The business intelligence solution will mask the business users from technical specifics of transparency (where the
data resides), consistency (how to access and use the data), and commonality (provide a multi-purpose toolset).
The Business Intelligence solution offers three different integrated reporting tools, ReportView, RequestView, and Ex-
plorerView, which offer complete coverage of all business intelligence reporting capabilities. All business intelligence tools
implement a role based security model that is integrated into the overall eTS security mechanism. The following products
are used to provide the Business Intelligence capability:
ReportView, RequestView Actuate

ExplorerView Cognos Powerplay
Presentation Java (JSP)
Integrating
eTravel Services
REPORTVIEW
ReportView publishes monthly (batch) standard reports published to the portal and Discovery Business Intelligence applica-
tion. Features of ReportView include the capabilities to perform:
Drill down navigation
Smart search for ad-hoc analysis and reporting against the monthly reports – searches can occur on user defined parame-
ters (fields) including name, airline, e-ticket, paid fares, and others.
Ability to download report data and reports in PDF or Excel formats
Multi-dimensional analysis for decision support
Full usage of ReportView’s capabilities requires usage of a signed Java Applet from the Actuate toolset called e-Analysis.
The following report configuration parameter are used to fulfill batch and on demand (standardization) where the reports
pick up the various parameters from the database. Following are some key elements of report configuration:
Groups – Provide ability to configure the groups, page security elements
Filters – Provide ability to configure the filters
Sorts – Provide ability to configure the sorts
Dynamic columns – Provide ability to configure dynamic columns
REQUESTVIEW
RequestView provides the capability to perform on-demand reporting including:
Direct access to the data warehouse
Ability for a user to run standard reports based on select parameters
The same data analysis capabilities as ReportView
ReportView is ideal for exception reporting and analysis, group reporting, and emergency reporting such as identifying
where travelers are at any given time.
EXPLORERVIEW
ExplorerView provide complete multi-dimensional (cubes) reporting capabilities against the entire eTS data warehouse. The
implementation of ExplorerView includes cube (Cognos Powerplay) definition and publishing enabling true ad-hoc reporting
against all OLAP data. ExplorerView enables:
Easy slice, dice, and drilldown
One click sorting and graphing
Multi-year analysis for trending and decision support
Custom cubes can be defined and published as requested by contracting agency business departments.
Discovery is integrated into the eTS security mechanism enabling single sign-on and full role-based security. Discovery has
also been developed to meet local, regional, national, and international queries and reporting.
The use of the Discovery set of tools enables Agency decision makers to perform the following functions:
Discovery® will be accessible from the eTravel portal and provide the following business analysis and management
functions (C6.7.5.1 and C6.7.5.2):
♦ Budget management
♦ Real-time spend analysis
♦ Preferred supplier utilization and spend
♦ Federal travel trend analysis
♦ Regulatory compliance and regulatory exception analysis and reporting
♦ The eTS Contractor performance
Integrating
eTravel Services
Business Intelligence roles will be assigned to all eTravel actors according to need to know requirements. Roles are
defined on a basis of whether an actor can use the functionality and whether the actor can access the data. Capabilities
that require role-based access include:
♦ Access to standard applications and reports for information retrieval
♦ Access to time spans for which information can be retrieved
♦ Access to custom reporting and/or data download functionality
♦ Access to ad-hoc drill-down and interactive investigation functionality
♦ Access to summary or detailed information and reports
♦ Access to strategic or tactical information and reports
Roles will be extended and refined as required by contracting Agencies. Following is a brief overview of the features of the
Discovery® presentation layer:
Feature Description
Security Discovery® security is defined using the same role-based mechanisms presented in the security section. All authoriza-
tion, authentication, encryption, and other security features used in the application are used for the Business Intelligence
system. Logging of all activities within the Discovery system is available for system usage and auditing purposes.
Client Discovery® provides for the application of Agency defined preferences regarding data translations, mappings, and pref-
Prefer- erences for the storage of data within warehouse. Agencies can define custom reports, extracts, OLAP cubes, and user
ences interfaces to meet needs. Discovery offers a set of standard reports and to meet Government requirements including 32
standard reports and 14 graphs providing summary, transaction, exception, and data analysis.
Reporting Discovery® uses Agency customizable scheduling mechanisms to ensure the timely delivery of reports to Agency de-
Package fined distribution lists; distribution lists may be based on system user roles or a new set of roles created for Business
Intelligence purposes. Configurable report elements include groups, filters, sorts, and dynamic columns. Reports can be
generated with specific detailed information or with summary data.
On De- Discovery® provides real-time report generation and data warehouse querying mechanisms through RequestView.
mand
OLAP Discovery® provides the ability to complete multi-dimensional analysis using OLAP Cubes through DiscoveryView.
Reporting
Scheduled report delivery is accomplished through notifications through the Business Intelligence Portlet and via email.
1.5.6 Record Retention & Archiving (RFP Reference C.6.7.6)
The Carlson eTS Solution provides a mechanism for record retention and archiving and meets all requirements as specified
in the SOO. The Carlson eTS Solution will maintain all system transaction information on-line for a minimum period of 39
months and off-line for an additional 36 months and in compliance with the Government fiscal year (October 1 through the
following September 30).
Figure 1.5 – 7 provides an overview of the overall data retention and archiving process. Features of the process are as fol-
lows:
Integrating
eTravel Services
Figure 1.5 – 7
The eTS implements three different on-line data stores in order to deliver its complete functionality including an operational
database which handles all day to day on-line transactions, a reporting and archive database which contains copies of opera-
tional data for reporting access, and the data warehouse which contains data in support of business intelligence. Data over
39 months old is archived off to a durable media format from the reporting and archive database. If access to that data is
required the data is returned to on-line status on the reporting and archive database.
All operational data is replicated to the reporting database on a nightly database; records older than 18 months are purged
from the operational database. Records older than 39 months will be archived and purged from the reporting database.
Definition of data elements and system state will be maintained in the archive. These archived transactions will be main-
tained on durable media such as optical disk and/or magnetic tape for the period specified. Upon request, archived
transactions will be supplied to the requesting Agency or department on durable media. Archived records will be indexed by
travel authorization number, traveler name, traveler SSN or other employee identification number, travel destination, and
dates of travel. Archived records can also be delivered to agencies in a standard data format via a data exchange process.
All eTS reports are run against the reporting database that is updated daily from the operational database; the business logic
of the eTS Reporting system determines the availability of data on-line.
As part of the data warehouse, specified transactional information will also be maintained to provide business intelligence
capabilities. Data retention, archiving, and summarization practices for the data warehouse will determined according to
Agency policy, although Carlson commits that all unique data not already retained by the eTS Archiving process will at a
minimum meet the 75 month and fiscal year requirement.
Integrating

CREW: General Services Administration: Regarding E-Gov Travel: 1/21/2010 - Ets r2 v1 Final Part 2 Redacted

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

CREW: General Services Administration: Regarding E-Gov Travel: 1/21/2010 - Ets r2 v1 Final Part 2 Redacted

Hochgeladen von

Copyright:

Verfügbare Formate

eTravel Services

Volume 1 – Technical Approach

1.0 TECHNICAL APPROACH - NARRATIVE (RFP REFERENCE E.3.4.2.1; E.6.1)

1.2.4.2 PORTAL FUNCTIONALITY

1.2.4.3 OPERATING PLATFORM

1.2.4.4 BROWSER TECHNOLOGY

1.2.4.6 DATA EXCHANGE

1.2.5.3 ACCESSIBILITY STANDARDS OF 36 CFR 1194 (RFP REFERENCE C.6.2.1.3; C.6.6)

1.2.5.4 JFMIP TRAVEL SYSTEM MANDATORY REQUIREMENTS (RFP REFERENCE C.6.2.1.4)

TABLE 2: USE CASES

TABLE 3: USE CASE / ACTOR MATRIX

FT FTA FSTA FFTA FATA FATC

1 Manage Traveler Profile *

FT FTA FSTA FFTA FATA FATC

11,12 Maintain Customer Settings *

1.2.6.2 OBJECTIVES (RFP REFERENCE C.6.3.1.2)

ADDITIONAL NON-SYSTEM ACTORS

ADDITIONAL SYSTEM ACTORS

ADDITIONAL USE CASES

Use Case Name Use Case Description

Use Case Name Use Case Description

USE CASE / ACTOR MATRIX

1.2.7 Use Cases (RFP Reference E.6.1; Factor 2)

HIGH-LEVEL USE CASE DIAGRAM (FIGURE 1.2 – 2)

1.2.8 Use Case Documentation

3.18. [A-19] Actor Chooses to Change Booking Information

2. Basic Flow (Steps)

2.1. System Displays Travel Authorizations

2.5.8. Travel Dates

3. Variations and Alternative Flows

3.9.9. Per Diem Statement

The actor(s) also involved in this use case:

Use cases extending this use case: (incoming Extend association):

2.6. Actor Submits Modifications to Settings

1.3 Performance Based Work Statement (PBWS)/Work Breakdown Structure

1.3.2 Performance Measures (RFP Reference C.7; D.28)

Goals & Objectives

No. Performance Measure Performance Objective Desired Outcomes

No. Performance Measure Performance Objective Desired Outcomes

1. Accuracy of travel tickets

PERFORMANCE INCENTIVE PAYMENTS

1.4 Security Approach (RFP Reference E.3.4.2.1.2, Item 4; E.6.1 Factor 4)

1. The user starts at the firstgov.gov portal.

1.4.3 PKI and Digital Signature (RFP Reference 6.5.2)

Client Security Ser- Level of

1.4.4 Web Browser Security (RFP Reference C.6.5.3)

1.4.6 Personnel and Physical Security (RFP Reference C.6.5.5)

NETWORK, HARDWARE, & SOFTWARE

EDI Standard Version

XML (EXTENSIBLE MARKUP LANGUAGE)

The XML Schema is represented as follows (XSD Examples):

<?xml version="1.0" encoding="UTF-8"?>

UDF (USER DEFINED FORMAT)

• Each line in the text file is a record.

1.5.3 Information Management - Reporting (RFP Reference C.6.7.4)

Database Oracle w/ Partitioning

Understand the different life cycle development methodology

ReportView, RequestView Actuate

Das könnte Ihnen auch gefallen