Embed Size (px)
Citation preview
Software Developers ConferenceNew York City, New York
March 31, 2004
Welcome and Today’s Agenda
•Welcome and Opening Remarks
•Data Strategy Update
•Common Origination Disbursement (COD) Update
•Break
•Front End Business Integration (FEBI) Update
•Common Services for Borrowers (CSB) Update
•Panel of Experts/ Q and A
•Schedule Update and Wrap-up
Next Conference: August 19-20, 2004Marriott Crystal GatewayArlington, VA
Data Strategy Update
Data Strategy Purpose
7 56
121110
8 4
21
9 3
§Consolidation of Data into Shared Source
§Focus on Data Quality
§Enterprise Standard for Student Identification
§ Integrated Partner Management
§EnterpriseRouting ID
§Enterprise Access Management
§ Integrated Student View
§ Integrated School View
§Foundation for more Timely and Efficient Processing
Develop an overall approach towards data to ensure that accurate and consistent data is available to and exchanged between FSA and our
customers, partners, and compliance and oversight organizations.
“The Right Data to the Right People at the Right Time”
Data Strategy in the Press
“The Right Data to the Right People at the Right Time”
From the January 2004 issue of “The Greentree Gazette”
“FSA’s Data Strategy Initiative is likely to have a significant impact on FSA’s ability to serve its customers. Its objectives include an enterprise-wide policy for managing and storing data and an industry-wide standard for publication and dissemination. FSA staff commonly refers to the critical nature of ‘getting the right data to the right people at the right time.’”
Data Strategy Key Findings To Date
The Data Strategy teams have confirmed several key findings:§ Data should be organized by business process, not by system.
§ Providing data access to business experts is the key component of improving the enterprises’ ability to make informed business decisions.
§ Verified that using a Matching Algorithm with SSN, First Name, Last Name, and DOB is the most flexible and tolerant way to identify customers.
§ Need to develop a single Enterprise solution for all Trading Partner Identification and Access.
§ “As-Is” Data Flow Discussions have facilitated a broader understanding of End-to-End Business Processes across all FSA program areas.
Data Strategy References
The following Data Strategy Deliverables may be found on the Library tab of the FEBI website under the Integration
Partner heading (http://www.febi.ed.gov/library.htm):§ FSA As-Is Data Flows§ To-Be Financial Aid Life Cycle Diagram
Lif
e-
cyc
leP
ha
se
App
lic
ant
/Bo
rro
wer
Pr
oce
ss
Department of Education
Help Desk
Financial Partners Portal
Schools Portal
FSA
Tra
din
gP
art
ne
rP
roce
ss Partner Application
Oversight
Aid Education Submission Eligibility Repayment Consolidation
Aid Awareness & Application InstitutionParticipation
Servicing
Tra
din
gP
artn
ers
&S
erv
icer
s
Guaranty Agencies
Student Aid on the Web
Call Centers
Collections
Origination &Disbursement
ED
Financial Management
Lenders (Lender Servicers)
Other External Partners
To-Be FinancialAid Life Cycle
DRAFTHigh-Level Business View
State Agencies Schools ( School Servicer)
Common Services for BorrowersOrigination & Disbursement
Trading Partner Management
Delivery
FSA Gateway
Award & DisbursementProcessing
School Aid Payments &Funding Level Mgmt
PartnerEnrollment
Partner Eligibility& Oversight
Funds & InternalControls
Service Loans Recovery &Resolution
ITAIntegratedTechnical
Architecture
VDCVirtual
Data Center
EAIEnterprise
ApplicationIntegration
Internal Transfer
External Transfer
Business Function
ApplicationAid Eligibility
Determination
EstablishPersonRecord
GLAccounting
BudgetingExternal FinancialReporting
Authentication & Access Management
Credit Check SSCRServicing Reporting (FFEL & Campus Based)
Edit ChecksEnt
erp
ris
e S
ha
red
Fu
nc
tion
s Common Data ArchitectureGenerate/Distribute ISIR/SAR
CSB
FMS
En
terp
rise S
ha
red
Fu
nctio
ns
Warehouse/Data Marts
Match Against CDA (FAH)
Send/Receive from Matching Agencies
SSIM Logic
ConsolidateLoans
Payment Processing
Authentication &Access Tools
Enablers
Business
IntelligenceTools
Enterprise Analytics and ResearchAcquisition &Planning Strategy
Enterprise PerformanceManagement
Case Tracking(Ombudsman)
Partner Payment Calculation/PrePopulation
CDR
RecommendPolicy Changes
AncillaryServices
AidAwareness
NSLDS
Partner Payment ManagementPartner Payment
Admin
Transactions
Students TradingPartners
ProcessPayments
State AgencyFunding
Analytics
Computation Edits - EFC
AR Managment
Distribute Eligibility
Transfer Monitoring Process Promissory Notes
FMSS GAPS
RID Legacy Identifier Crosswalk
ApplicationProcess
RelationshipMgmt
Audit History
EnterpriseContent
Management
MetadataRepository
Life
-c
ycle
Ph
ase
App
lic
ant
/Bo
rro
wer
Pro
ce
ss
Department of Education
Help Desk (Example - NSLDS)
Financial Partners Portal
Schools Portal
PIN
CPS
COD PEPS
FSA
EAIEnterpriseApplicationIntegration
ITAIntegrated
TechnicalArchitecture
VDCVirtual
Data Center
SSOSingle Sign On
SAIGStudent Aid
InternetGateway
NSLDS
Tra
din
gP
art
ner
Pro
ce
ss
TechnologyEnablers
Non-EAI Transfer
EAI Transfer
FAFSA
Partner Application
Oversight
Aid Education Submission Eligibility Repayment Consolidation
AidAwareness
Application InstitutionParticipation
Servicing
Tra
din
g P
art
ner
s &
Se
rvic
ers
Guaranty Agencies
CDDTSDLSS
DLCS
DMCS
Students Portal
Call Centers (Example - PIC)
Delivery
Collections
External Transfer Origination &Disbursement
ParticipationManagement
ED
FMS
eCB
Lenders (Lender Servicers)
Ombudsman
Other External Partners
The Financial AidLife Cycle
High-Level Business View
FinancialPartners
Data Mart
DelinquentLoan
Data Mart
CreditManagementData Mart
eZ-Audit
State Agencies
Schools ( School Servicer)
Data Strategy 2.0
§ Gathered Business Objectives
§ Drafted Target Data Flows§ Created a Vision of “What it
should look like”
Life
-cy
cle
Pha
se
Appl
ican
t/B
orro
wer
Proc
ess
Department of Education
Help Desk
Financial Partners Portal
Schools Portal
FSA
Trad
ing
Par
tner
Proc
ess Partner Application
Oversight
Aid Education Submission Eligibility Repayment Consolidation
Aid Awareness & ApplicationInstitution
ParticipationServicing
Tra
ding
Part
ners
&S
ervi
cers
Guaranty Agencies
Student Aid on the Web
Call Centers
Collections
Origination &Disbursement
ED
Financial Management
Lenders (Lender Servicers)
Other External Partners
To-Be FinancialAid Life Cycle
DRAFTHigh-Level Business View
State Agencies Schools ( School Servicer)
Common Services for BorrowersOrigination & Disbursement
Trading Partner Management
Delivery
FSA Gateway
Award & DisbursementProcessing
School Aid Payments &
Funding Level Mgmt
PartnerEnrollment
Partner Eligibility& Oversight
Funds & InternalControls
Service Loans Recovery &Resolution
ITAIntegrated
TechnicalArchitecture
VDCVirtual
Data Center
E A IEnterprise
Application
Integration
Internal Transfer
External Transfer
Business Function
ApplicationAid Eligibility
Determination
EstablishPersonRecord
GLAccountingBudgetingExternal Financial
Reporting
Authentication & Access Management
Credit Check SSCRServicing Reporting (FFEL & Campus Based)
Edit ChecksEnt
erpr
ise S
hare
dF
unct
ions Common Data Architecture
Generate/Distribute ISIR/SAR
CSB
FMS
Enterprise Sha
red
Func
tions
Warehouse/Data Marts
Match Against CDA (FAH)
Send/Receive from Matching Agencies
SSIM Logic
ConsolidateLoans
Payment Processing
Authentication &
Access Tools
Enablers
Business
IntelligenceTools
Enterprise Analytics and ResearchAcquisition &Planning Strategy
Enterprise PerformanceManagement
Case Tracking(Ombudsman)
Partner Payment Calculation/PrePopulation
C D R
RecommendPolicy Changes
AncillaryServices
AidAwareness
NSLDS
Partner Payment ManagementPartner Payment
A d m i n
Transactions
Students Trading
Partners
ProcessPayments
State AgencyFunding
Analytics
Computation Edits - EFC
AR Managment
Distribute Eligibility
Transfer Monitoring Process Promissory Notes
FMSS GAPS
RID Legacy Identifier Crosswalk
ApplicationProcess
RelationshipMgmt
Audit History
EnterpriseContent
Management
MetadataRepository
Where We Are
Integration Services
Security
ED/FSAInternal Users
Student, FAA,& Financial
Partner Users
Enterprise Shared Functions
System Access(G2G & G2B)
GovernmentAgency
Systems
School/Servicer
Systems
Lender/ServicerSystems
GuarantyAgency/Servicer
Systems
TransactionsStudents Trading
PartnersFMS
Web Access (G2C & G2B)
Student Aidon the Web
Portal
FSA Web Site
Web Applications
Extract - Transform - Load
Internet
IntegratedViews
Analytics andResearch Tools
CentralizedGovernance and
Management
FSA
Gat
eway
Metadata Repository
PartnerEnrollment
Common Data Architecture
SchoolServices
Portal
FP Services
Portal
Trading PartnerManagement
(Interacts withall BusinessCapability
Areas)
Enterprise ContentManagement
Technical Functions Business FunctionsCapability Discovery
Data Tracing and Visibility
Data Transformation
Data Validation
Error Handling
Audit HistoryAuthentication & Access Mgmt.CDRComputation Edits - EFCCredit CheckDistribute EligibilityEdit ChecksGenerate/Distribute ISIR/SARMatch Against CDA (FAH)
Partner Payment Calculation/ Pre-PopulationProcess Promissory NotesRID Legacy Identifier CrosswalkSend/Receive from Matching AgenciesService Reporting (FFEL & Campus- based)SSCRSSIM LogicTransfer Monitoring
Web Services
Real-Time Transfer
Batch Transfer
Business ProcessManagement
Application Origination andDisbursement
Payment PartnerManagement
Financial Management
Common Services forBorrowers
C S B
SystemAccess
Management
Borrower Access Management
Trading Partner and Internal UserAccess Management
Enterprise Analytics andResearch
Knowledge/
Discovery
OLAP /Analytics
Query /Reporting
Internet(Some Systems)
FSA Target Conceptual Architecture Guiding Principles
1. Shift to business process focus from system-based operation.2. Consolidate data to a centralized storage environment.3. Standardize interaction with external customers.4. Improve FSA architecture response to business change.5. Eliminate redundancy to promote the reuse of business functions.
Warehouse/Data Marts
NSLDS
What We Need To Do§ Explore options for new questions raised during Target Vision
Discussions and Retreats § Implement XML Registry / Repository of Core Components to the
Internet§ Enact the Data Quality Assurance Methodology for the Enterprise
Data Strategy 2.0 Schedule
1/5 1/12 1/19 1/26 2/2 2/9 2/16 2/23 3/1 3/8 3/15 3/22 3/29 4/5 4/12 4/19 4/26 5/3 5/10 5/17 5/24 5/31 6/7 6/14 6/21 6/28 7/5 7/12 7/19 7/26 8/2 8/9 8/16 8/23 8/30 9/6 9/13 9/20 9/27 10/4 10/11 10/18 10/25 11/1 11/8 11/15 11/22 11/29
Delivered on Schedule
Scheduled Delivery Date
June
Data Quality Management
XML Registry/Repository Production Support
Data Strategy Target Vision Functional Gap Analysis
Data Strategy Target Vision Enterprise Analytics Architecture Option Analysis
XML Management
Core Component Dictionary Release 2.0
Production Registry / Repository
XML Production Support
Technical Strategies
Enterprise Analytics Architecture Option Analysis
Common Data Architecture Operating Guidelines
Website/Portals Consolidation and Shared Services Implementation
Option Analysis
Data Framework
FFEL and Student Enrollment Data Flow Option Analysis
CSB Impact Analysis
Data Strategy Target Vision Functional Gap Analysis
Data Strategy Target Vision Common Data Architecture Operating Guidelines Options
Data Strategy Target Vision FFEL and Student Enrollment Data Flow Option Analysis
Jan MayFeb Mar Apr Jul NovOctSepAug
Data Quality Management
Overall Data Strategy TO 152 - Data Strategy 2.0
Data Strategy Target Vision CSB Impact Analysis
Data Strategy Target Vision Website/Portals Consolidation and Shared Services Implementation Option Analysis
XML Core Component Dictionary Release 2.0
XML Registry/Repository Production Readiness Review (PRR) Report
CurrentDate
Legend
152.1.2 - Data Strategy Target Vision CSB Impact Analysis
152.1.3b - Data Strategy Target Vision Functional Gap Analysis (Final)
152.1.10a - Data Quality Management Support Report I
152.1.10b - Data Quality Management Support Report II
152.1.9a -XML Registry/Repository Production Quarterly Report I
152.1.8-XML Registry/Repository Production Readiness Review
(PRR) Report
152.1.7-XML Core Component Dictionary Release 2.0
152.1.9b - XML Registry/Repository Production Quarterly Report II
152.1.1 - Data Strategy Target Vision FFEL and Student Enrollment Data Flow Option Analysis
152.1.4b - Data Strategy Target Vision Enterprise Analytics Architecture Option Analysis (Final)
152.1.5-Data Strategy Target Vision Common Data Architecture Operating Guidelines Options
152.1.6 -Data Strategy Target Vision Website/Portals Consolidation and Shared Services Implementation Option Analysis
152.1.3a - Data Strategy Target Vision Functional Gap Analysis (Draft)
152.1.4a -Data Strategy Target Vision Enterprise Analytics Architecture Option Analysis (Draft)
Data Strategy 2.0 Functional Gap Activities
Integration Services
Security
ED/FSAInternal Users
Student, FAA,& Financial
Partner Users
Enterprise Shared Functions
System Access(G2G & G2B)
GovernmentAgency
Systems
School/ServicerSystems
Lender/ServicerSystems
GuarantyAgency/Servicer
Systems
TransactionsStudents Trading
PartnersFMS
Web Access (G2C & G2B)
Student Aidon the Web
Portal
FSA Web Site
Web Applications
Extract - Transform - Load
Internet
IntegratedViews
Analytics andResearch Tools
CentralizedGovernance and
Management
FSA
Gat
eway
Metadata Repository
PartnerEnrollment
Common Data Architecture
SchoolServices
Portal
FP ServicesPortal
Integrated PartnerManagement
(Interacts withall Business
CapabilityAreas)
Enterprise ContentManagement
Technical Functions Business FunctionsCapability Discovery
Data Tracing and Visibility
Data Transformation
Data Validation
Error Handling
Audit HistoryAuthentication & Access Mgmt.CDRComputation Edits - EFCCredit CheckDistribute EligibilityEdit ChecksGenerate/Distribute ISIR/SARMatch Against CDA (FAH)
Partner Payment Calculation/ Pre-PopulationProcess Promissory NotesRID Legacy Identifier CrosswalkSend/Receive from Matching AgenciesService Reporting (FFEL & Campus- based)SSCRSSIM LogicTransfer Monitoring
Web Services
Real-Time Transfer
Batch Transfer
Business ProcessManagement
ApplicationOrigination andDisbursement
Payment PartnerManagement
Financial Management
Common Services forBorrowers
CSB
SystemAccess
Management
Borrower Access Management
Trading Partner and Internal UserAccess Management
Enterprise Analytics andResearch
Knowledge/Discovery
OLAP /Analytics
Query /Reporting
Internet(Some Systems)
Data Strategy 2.0 Functional Gap Analysis Activities
1. Option analysis for FFEL Loan and Student Enrollment Reporting2. CSB award outcome impact analysis3. Option analysis for Financial Transaction Processing4. Enterprise Analytics Architecture Analysis and CDA Operating Guidelines.5. Web Consolidation and Shared Services Options
Warehouse/Data Marts
NSLDS
1
2
3
4
4
4
5
5
5
Data Strategy 2.0 XML Deployment
RDBMS
A Registry contains meta-data about documentsstored in the Repository. Meta-data includes:
* Ownership Data* Version Data* Access Constraints Data* Classification Schemes* Associations
File System
A Repository stores documents referenced bya Registry. Documents Include:* XML Schemas* Core Components* Other Documents
RepositoryRegistry
Registry Client
A User Interface allows users access to Repository documentsand enables them to:
* Search for Documents* View Documents* Upload Documents* Delete Documents* Edit Document Properties* Classify Documents* Associate Documents with eachother
User Interface
§ Deploy XML Registry / Repository to the Internet– Makes FSA standardized Title IV Aid definitions and
Core Components available for both FSA and Community usage
– Provides a vehicle to drive consensus on data standards
Data Strategy 2.0 Data Quality Deployment
PrioritizationPhase
AssessmentPhase
ImprovementPhase
OversightPhase
PR
OC
ES
S &
ST
AG
E S
UM
MA
RY
TOO
LS1.Verification of As-Is
State and QualityIssues Stage
2.Determine Criteriafor Ranking Stage
3.Rank Quality IssuesStage
• Assign ProjectManagers, requestfurther research, ortransfer to EnterpriseQuality Assuranceprogram
• Quality Report• Failure Modes and
Effect Analysis (FMEA)• Voice of the
Customer (VOC)• Quick Win
Determination• Cost of Poor Quality
Analysis
• Develop BusinessCase, project plan,and objectives.
• Create acommunication plan.
• Document Inputs andOutputs.
• Voice of Customer /Critical to Quality
• Histograms, ParetoCharts
• Fishbone Diagram,Failure Modes andEffect Analysis
• “To-Be” Vision
• Brainstorming• Decision Matrix• Cost/Benefit• Risk Assessment• Change Leadership• Implementation Plan• Pilot testing• Control and Response
Plan
• Quality Report(High levelprovidingenterprise-widequality health-withdrill down forquality issue/orsystem level)
• Best Practiceanalysis andtransfer
1. Enterprise AnalyticsStage
2. Enterprise Audits(Financial) Stage
3. Enterprise QualityReport Stage
• Transfer Reportresults back toPrioritization Phase
1. Pre-AssessmentPlanning (As-Is)Stage
2. Initial DataAssessment Stage
3. Pilot Testing DataAssessment Stage
• Transfer toImprovement Phase
1. Solution Definition andAssessment Stage
2. Data QualityImplementation PilotTesting Stage
3. Data QualityImplementationProduction Stage
• For pilot testing,transfer back toAssessment Phase,otherwise go toOversight Phase
§ Enact Data Quality Assurance Strategy– Establishes Repeatable processes for identifying, correcting, and maintaining
data within the Enterprise
Data Strategy Update - IPM
What is the Integrated Partner Management Solution (IPMS)?
IPMS is envisioned as the solution that enables FSA to successfully and easily perform oversight, management and maintenance of its Trading Partners. The solution will provide a holistic view of the information related to FSA Trading Partners and will enable FSA to overcome the current challenges of managing information related to Trading Partner identification and their interactions via a combination of PEPS and the Title IV delivery systems.
The solution should cover the following business areas:•Enrollment Management •Eligibility Management •School On-Going Oversight•Financial Partner On-Going Oversight •Enterprise Routing Identifier (RID) Services •Reporting and Auditing Services•Profile and Demographic Management •Access Management •Customer Support •Workflow Management
Data Strategy Update - IPM
Inte
grat
ed V
iew
Ser
vice
s
§D
ata
Acc
ess
Ser
vice
F S AG a t e w a y
S c h o o l O n - G o i n gO v e r s i g h t
§ P r o g r a m E l i g i b i l i t yO v e r s i g h t : A u d i t s ,f i n a n c i a l s t a t e m e n t s ,d e f a u l t r a t e c a l c u l a t i o n s
§ C o m p l i a n c e R e v i e w s :R i s k a s s e s s m e n t ,a c c r e d i t a t i o n , s t u d e n tc o m p l a i n t s , f u n d i n gp a r a m e t e r s , r e f e r r a l s
§ A p p e a l s§ P r o a c t i v e O v e r s i g h t ,
M o n i t o r i n g , a n d S u p p o r t
F i n a n c i a l P a r t n e r O n -G o i n g O v e r s i g h t
§ P r o g r a m E l i g i b i l i t yO v e r s i g h t : A u d i t s ,f i n a n c i a ls t a t e m e n t s ,
§ C o m p l i a n c eR e v i e w s : R i s ka s s e s s m e n t ,r e f e r r a l s
§ A p p e a l s§ P r o a c t i v e O v e r s i g h t ,
M o n i t o r i n g , a n dS u p p o r t
E n r o l l m e n tM a n a g e m e n t
§ I n t e g r a t e dA p p l i c a t i o na n dE n r o l l m e n tP r o c e s s i n g -P r o c e s sR e q u e s t s ,D e t e r m i n eA c c e s s
§ I n s t i t u t i o n -l e v e l S y s t e mE n r o l l m e n ta n d S i n g l eS i g n U p( S S U )
E l i g i b i l i t yM a n a g e m e n t
§ N e w T r a d i n gP a r t n e rA p p l i c a t i o n s
§ I n i t i a l R I DA s s i g n m e n t
§ R e -c e r t i f i c a t i o n s
§ P r o g r a mP a r t i c i p a t i o nM a n a g e m e n t
§ A p p e a l s§ P r o a c t i v e
E l i g i b i l t yM a n a g e m e n t
§ E l i g i b i l i t yA c t i o n s ( F P R D ,F i n e s , L O C ,L S & T ,R e f e r r a l s )
I n t e g r a t e d P a r t n e r M a n a g e m e n t F r a m e w o r k( S c h o o l s , G u a r a n t y A g e n c i e s , L e n d e r s , T h i r d P a r t y S e r v i c e r s , S t a t e A g e n c i e s , S o f t w a r e D e v e l o p e r s a n d A u d i t o r s )
W e bA p p l i c a t i o nI n t e r f a c e s
P o r t a l s
A c c e s s M a n a g e m e n t
§ I n d i v i d u a l U s e r A c c e s s M a n a g e m e n t§ R o l e s b a s e d S i n g l e S i g n O n ( S S O )§ T r a d i n g P a r t n e r S e l f - A d m i n i s t e r e d A c c e s s
E n t e r p r i s eR o u t i n g
I d e n t i f i e r( R I D )
S e r v i c e s
C u s t o m e r S u p p o r t
W o r k f l o w & D o c u m e n t M a n a g e m e n t
= U s e r A c c e s s P o i n t s
P r o f i l e & D e m o g r a p h i c s M a n a g e m e n t
§ D e m o g r a p h i c s M a n a g e m e n t§ R e l a t i o n s h i p a n d A f f i l i a t i o n M a n a g e m e n t
- E n t e r p r i s e R I D M a n a g e m e n t
R e p o r t i n g & A u d i t S e r v i c e s
E n t e r p r i s e A n a l y t i c s
F S A ; O t h e r G o v e r n m e n t A g e n c i e s
Data Strategy Update - IPM
10/1 10/6 10/13 10/20 10/27 11/3 11/10 11/17 11/24 12/1 12/8 12/15 12/22 12/29 1/5 1/12 1/19 1/26 2/2 2/9 2/16 2/23 3/1 3/8 3/15 3/22 3/29
Key:
Del 1 =
Del 2 =
Del 3 =
Jan Feb MarOct Nov Dec
10/1 - Begin Date 3/12 - All Work Completed
Perform Case Management Gaps Analysis (e.g., Schools Eligibility Channel Cohort
Default Rate Calculations)
Document Non-Case Management Requirements for Schools, Borrower Services, CFO and OPE
Document Financial Partner Eligibility & OversightRequirements
Develop Financial Partner Eligibility & Oversight As-Is Flows
IPMS Gap Analysis Timeline
NSLDS & Data Strategy§ More detail on NSLDS will be available when
the NSLDS business functions have been clearly mapped to the FSA target vision.§ The following NSLDS upgrades have taken
place in an effort to position the system for future re-engineering efforts:– Upgraded the NSLDS mainframe system to Z900
in September 2003.– Upgraded the operating system to Z/OS version
1.4 in January 2004.– Upgraded to 64 bit Discovery Process.
NSLDS Update
§ NSLDS announced a new operations and maintenance contractor effective as of March 8, 2004.§ The contractor is Applied Engineering
Management (AEM), a small business located in Virginia.
NSLDS Update
Consolidation Loans & the Aggregate Calculation
§ Working with the community through NCHELP.– FFEL community to provide further
breakdown of Consolidation Loans– NSLDS to capture Outstanding Principal
Balance at time of loan closure or payoff.
NSLDS Updates
Other NSLDS initiatives§ To collect data on Total & Permanent
Disability Loans§ To continue efforts to monitor
reasonableness of data reported in summary on ED Forms to the loan level detail reported on NSLDS
COD Update
In this session…
§ 2004-2005 Processing Changes
§ School Testing
§ Software Developer Feedback
2004-2005 Processing Changes
Summary of 2004-2005 Processing Changes
Pell Grant and Direct Loan Changes
§ Extended Full Participant deadline to 2005-2006.
§ Enhanced Message Class Options for Full Participants.
§ Increased variable field length on the SAIG Transmission Header.
Summary of 2004-2005 Processing Changes
Pell Grant Changes
§ Verification Initiatives– CPS Verification Indicator tag added to Common Record
Response– Highest CPS Transaction Number tag added to Common
Record Response– Pell Verification Status Report
§ Pell POP Report (Future Release)
Summary of 2004-2005 Processing Changes
Pell Grant Changes cont.
§ Data elements no longer required for Pell Grant processing:– Academic Calendar Code – Payment Methodology Code – Weeks of instructional time used to calculate payment– Weeks of instructional time in program’s definition of award
year– Credit/Clock hours used to calculate payment– Credit/Clock hours in this student’s program of study’s
academic year
Summary of 2004-2005 Processing Changes
Direct Loan Changes
§ Anticipated disbursement information required when establishing Direct Loan awards.
§ Automatic recalculation of anticipated disbursements when Award Amount is decreased.
§ Automatic reduction of anticipated disbursements to allow loan inactivation.
§ Pennies will not be processed in the Direct Loan Program.
Summary of 2004-2005 Processing Changes
COD Web Site Changes
§ Enhanced CPS applicant data search functionality.
§ Person Information pages allow filtering by award year.
§ Award Amount Disbursed and Award Amount Approved added to Person Information pages.
§ Batch Search screens allow filtering by Award Type and Doc Type.
§ Batch Detail Information page split to display information submitted to COD and information returned by COD.
Summary of 2004-2005 Processing Changes
COD Web Site Changes§ Promissory note search by SSN, MPN ID, or First
Name and Date of Birth.
§ School Summary Financial Information screen reflects information contained in the Direct Loan School Account Statement.
§ Enhanced disbursement functionality to allow creation of multiple anticipated disbursements when originating an award.
§ Ability to select Award Year and Program for web navigation.
§ GAPS Debit Date added to Cash Activity Screen.
2004-2005 Processing Changes Update
§ COD will no longer be instituting the following functionality for the 2004-2005 award year:– Campus-Based processing– School Report Options via the COD web site
§ Campus-Based– Due to feedback on the proposed Campus-Based functionality for the
2004-2005 award year, enhancements to Campus-Based functionality are now being explored. The implementation of Campus-Based processing has been postponed pending further discussion of Campus-Based design requirements.
§ School Report Options– COD will not be providing enhanced School Report Options. Current
COD processing will continue to allow for the selection of limited report delivery, sort, and format options via the web and by contacting Customer Service.
2004-2005 UpdateCurrent School Report Options
Pell Reports
§ The following reports can be requested via the Pell Data Request link on the COD web site and will be delivered in fixed-length file format via the school’s SAIG mailbox:– ESOA– MRR– Pell Reconciliation– YTD
§ The following reports can be viewed on the COD web site in PDF or comma-delimited format by clicking on the Services tab:– Pending Disbursement List Report– Funded Disbursement List Report
2004-2005 UpdateCurrent School Report Options
Direct Loan Reports
§ The following reports can be displayed on the COD web site by clicking on the Services tab. These reports are automatically sent to the schools SAIG mailbox: – 30 Day Warning Report– Pending Disbursement List Report– Funded Disbursement List Report– Duplicate Student Borrower– SSN/DOB/Name Change Report
§ Format and delivery options for the above reports can be modified by accessing the Report Selection link on the School Summary Information Screen.
§ Format and delivery modifications for the SSN/DOB/Name Change Report must be made by contacting Customer Service.
XML Schema ProcessingOriginal Namespace Convention
§ For the launch of the 2004-2005 award year, COD had planned to continue to return the latest XML Schema version, 2.0d, in Common Record response documents for all award years.
§ The XML Schema contains the validation rules of the Common Record document, and also contains specific version information in the “Namespace” attribute.
§ XML Schema validation is normally performed throughout development and testing of a system to verify system XML output. Typically, XML Schema validation is notperformed during production processing.
§ Since Schema validation is not performed during production, the Namespace attribute should not be edited during production processing. Therefore, updates to the XML Schema Namespace should not influence production processing.
XML Schema ProcessingOriginal Namespace Convention
§ Prior to the release of the 2004-2005 award year, COD learned that some vendors were editing the value in the Namespace attribute during production processing.
§ As a result, some vendors would have had to update their 2003-2004 award year software in order to continue processing 2003-2004 responses returned in 2.0d.
§ Therefore, COD has implemented a temporary workaround to enable those vendors to continue processing for the 2003-2004 award year.
XML Schema Processing Current Namespace Convention
§ COD is currently returning the highest Schema version released during the award year of the data contained in the Common Record document.
§ If the Common Record contains multiple award years, COD is returning the XML Schema version that corresponds to the highest award year.
§ However, this temporary solution may cause problems for those vendors that were expecting to receive the latest XML Schema version for all award years.
http://www.ed.gov/FSA/COD/2003/v2.0c 2003-2004
http://www.ed.gov/FSA/COD/2004/v2.0d 2004-2005
http://www.ed.gov/FSA/COD/2002-2003
Common Record Schema Namespace ValueBatch Award Year
XML Schema ProcessingProposed Namespace Solution
§ For the 2005-2006 release, COD is considering returning response documents in the XML Schema version submitted to COD. i.e. “Echo-ing” back what was submitted to COD.
§ For system-generated responses, COD will return Common Record documents in the latest version of the XML Schema.
§ This solution will accommodate vendors that are editing on the Namespace value regardless of the value they were expecting to receive.
§ However, the best method is to not edit the Namespace value.
School Testing
COD School Testing§ Purpose:
– Provide schools, Third-party Servicers, and software vendors an opportunity to test business processes and system software in a low-volume, controlled test environment thereby enabling simpler, faster, and less costly issue identification and resolution
– Ease the transmission of production data– Reduce the risk of production problems
§ School Testing Documentation:– School Testing Guide – Test Cases for both Full and Phase-In Participants– COD 2004-2005 Technical Reference available on IFAP and
FSA Download
Communicating about School Testing…
§ COD has increased communication about School Testing to the community using the following forums: – IFAP– COD Processing Updates– Web Messages– Conference Presentations
§ The School Testing Bulletin Board has been discontinued due to lack of community interest.
2003-2004 Lessons Learned§ Based on school and vendor feedback, the following
enhancements were made to the 2004-2005 School Testing Guide in the COD Technical Reference:– Detailed Routing ID explanation– Detailed explanation of ISIR files– Further clarification of the fields contained in the Sign-up
Document
2003-2004 Lessons Learned§ COD is currently investigating whether or not it is
possible to provide sample Pell origination files and acknowledgement files, and Direct Loan origination and acknowledgement files.
§ COD is unable to provide a year round testing environment with testing scenarios.
§ COD will allow for additional unstructured testing after the COD testing window has closed.
COD Unstructured Testing
§ COD is offering unstructured testing to a limitednumber of 2004-2005 COD School Testing participants.
§ Participants interested in unstructured testing must participate in, and complete Phase II test cases prior to participating in unstructured testing.
COD Unstructured Testing
§ What can be done in Unstructured Testing?– Update person data, – Updates to awards and award amounts, – Send batches and receive acknowledgements and
responses in proper format (Common Record or Fixed-length flat files).
§ What are the limitations of Unstructured Testing?– Unknown result expected by school,– Unable to provide system-generated responses, – Cannot provide COD “testing” web site access, – Cannot provide COD reports.
2004-2005 COD School Testing Timeline
Mid-March 2004 - June 30, 2004
Phase II-Structured Application Testing
Mid-March 2004 - June 30, 2004
Unstructured Testing
Jan. 1, 2004 – May 31,2004 Phase I-Manual Verification Testing
Dec. 1, 2003 – May 1, 2004Sign-up
DatesPhase
COD Full ParticipantsAs of March 1, 2004
1895
3537
22
5512
3840
1490
Phase-In ParticipantsFull Participants
2002-2003 2003-2004
2004-2005 (Projected)
All schools must be Full Participant for the 2005-2006 Award Year.
Software Developer Feedback
Contact Us!!§ Email: [email protected]
§ Call the COD School Relations Center– 1-800-4-PGRANT for Pell Grants– 1-800-848-0978 for Direct Loans
§ COD Web Site (www.cod.ed.gov)
Overview of FEBI-Front End Business Integration
March 31, 2004
Agenda
§ FEBI Objectives§ Approach to FEBI§ FEBI Accomplishments§ Market Research§ FEBI Procurement Timeline§ Next Steps
FEBI Objectives§ Create a student-centric business model that supports the needs of the end-to-
end business process
§ Align products and services across the Front End and assure that they effectively and efficiently serve customer needs
§ Integrate student/applicant customer service capability, including the capturing of customer service data such that we can improve our products and services
§ Share services across the enterprise such as imaging and fulfillment
§ Operationalize ways to use technology to simplify the application process and customer experience (e.g., warm transfer capability between customer interaction centers, web services, and identity management)
§ Streamline and simplify of the application and origination and disbursement delivery systems including reusable components that support FSA data strategy
§ Effectively provide technical help desk services
§ Simplify processes for business partners (improve interfaces with institutions and other FSA systems such that schools can provide aid on our behalf)
§ Establish performance measures that ensure demonstrable outcomes
Approach to FEBI§ Identify front end business processes§ Understand interdependencies between this
initiative and other integration activities in FSA§ Conduct market research § Develop Vision and Target State§ Develop acquisition strategy§ Release Statement of Objectives
FEBI sits within the broader FSA and ASEDS goals
Awareness/Outreach, Application,Origination & Disbursement,
and Customer Service
Shared Services
Data Strategy
FSA Enterprise Goals
FEBI
FEBI Accomplishments§ Defined FE business processes
§ Identified activities associated with the FE– Focused on shared services and shared data
§ Synced up with Data Strategy efforts– Validated common data between Awareness/Application and
Origination/Disbursement
§ Refined FEBI objectives
§ Developed FEBI market research strategy
§ Conducted market research sessions and developed learnings/best practices matrix
§ Released draft Statement of Objectives to vendor community as ongoing market research
Market Research§ Defined MR Objectives in the areas of Business Process,
Performance, and Technology for:
– Application, Origination, and Disbursement
– Customer Service
– Shared Services
§ Developed profiles for 51 organizations: 33 providers, 18 users,41 commercial sector companies and 27 organizations that operatein commercial and/or government
§ Developed a prioritization formula and refined weights until a usable dispersion of company scores was achieved
§ Of the 21 organizations we contacted, we are able to conduct interviews with 13
§ Conducted MR Sessions
§ Documented MR Learnings
2004
F M A
Front End Strategy and Procurement Approach
SOO Developed
Draft SOO Comments Received 3/8
Solicitation 1
M
Draft SOO Posted 2/27
Sol 1 SOO Approach Defined 3/19
Analyze Draft SOO Input 3/10-3/12
Determine # of Solicitations 3/19
Refine SOO based on Vendor Input 3/12-3/19
Sol 1 Released 3/31
Responses Due 4/15
Down Select Review 4/15-4/29
Solicitation 2Sol 2 Draft Released 4/30
Due Diligence 5/1-5/31
Final Sol 2 Released 6/1
J
Checkpoint- Determine # of parts 3/19
Checkpoint
Checkpoint- Define # Sol
Checkpoint
FEBI Procurement Timeline
Next Steps
§ Solicitation 1 – Release 3/31/04§ Solicitation 2 – Release on or about
6/1/04§ Award – 9/30/04
- CSB -Common Services for Borrowers
Dwight VignaActing Director, Direct Loan Servicing System
Common Services for Borrowers (CSB)
Agenda
§ CSB Overview § CSB – An innovative
contract method§ Implementation
Approach § Benefits to Schools§ Summary
CSB Overview - GoalsCSB will modernize/integrate four legacy systems into 1
§ Direct Loan Servicing (DLSS)§ Loan Consolidation (LC)§ Debt Collection (DMCS)§ Conditional Disability
Discharge Tracking (CDDTS)
Additionally, CSB will include the Delinquent Loan Data Mart (DLDM) and other FSA data mart functions
CSB Overview - Goals
§ Integration will achieve the following:– Reduce Delinquency and Default
• Performance based pricing• Incentive based and
– Improve Customer Service and Increase Self-Servicing• Additional Web access• Improved IVR functionality• Reengineered communications
– Integrate Systems and Data• Less data redundancy and associated errors• Improved auditability
– Create Adaptability and Flexibility in the CSB System– Reduce Cost– Achieve Contracting Goals
CSB Contract Approach§ A “performance-based” contract
– Focus on expected results/outcomes
– Comply with statute and regulations
– More flexibility for contractor
– Reduction in Reconciliation and System Balancing Point
– Reduce Staffing at Call Centers, Other Locations
– Reduce Infrastructure
• Consolidates 6 call centers into 1 Virtual Service Center
• Consolidates 6 inbound mailrooms into 1
• Consolidates 7 fulfillment (print and mail) centers into 4
• Consolidates 3 lockboxes into 1
§ Independent Government Cost Estimate: - $1 Billion in savings to taxpayers -
Approach to Integrate Systems and Data
§ Leverage legacy assets and FSA investments§ Migrate some§ Reengineer some§ Rewrite some
§ Minimize (prevent) impact on Trading Partners
§ Support FSA IT Standards§ Hosted at the VDC
§ Compliant with FSA technology standards
§ Complements FSA data strategy initiatives
§ Eliminate data redundancy and reconciliation issues
§ Provide a single system of record
§ Use a phased integration approach
Phases Nov Dec Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov
CSB Management Planning/Project Startup
Phase 1Loan Consolidation/ Common Database Implementation
Phase 2Servicing/Debt Collection/Discharge Tracking Implementation
Phase 3Additional Integration and Migration to the VDC
2003 2005
Transition Complete
2004Months
1.5 months
7 months
9 months
15 months
Phase 1
Phase 2
Phase 3
CSB Transition Plan
Legacy systems will continue to operate until implementation of the CSB Solution
DLSS
Data
ApplicationCRM
Interfaces
Common Services for BorrowersPhase 1
EAI/Interfaces
CRM
Common Services
Demographic |
Application Layer
Common Database
Create CSB Framework
Loan Consolidation Ø Develop functionality in CSBØ Incorporate into upgraded
Siebel CRM
Common DatabaseØ Move LC data and DLSS
demographic data to CSB
Data Mart Ø Establish CSB Data Mart
and move existing Servicingdata from CMDM and DLDM
Ø Add data from DMCS andCDDTS
LC
Data
ApplicationCRM
Interfaces
LoanConsolida-
tion
Data
Demographic
DMCS
Data
ApplicationCRM
Interfaces
DataMart
CDDTS
ApplicationCRM
Interfaces Data
DLSS DMCS
Common Services for BorrowersPhase 2
EAI/Interfaces
CRM
Common Services
Demographic |
Application Layer
Common Database
ServicingØ Convert DLSS software to
new hardware andoperating system
Debt CollectionØ Develop functionality in
CSB using Quester as thebase product
Discharge TrackingØ Develop functionality in
CSB
Common DatabaseØ Move remaining legacy
data to CSB
LoanConsolida-
tion
Demographic
LoanServicing
Contact Financial
Debt Collection
DisabilityDischargeTracking
ApplicationCRM
Interfaces
ApplicationCRM
Interfaces DataData
DataMart
CDDTS
ApplicationCRM
Interfaces Data
Additional eCRM (Siebel) Integration– Web-based imaging– Web Chat– Email
Phase 3 ends with CSB hosted at the VDC
Common Services for BorrowersPhase 3
EAI/Interfaces
CRM
Common Services
Demographic |
Application Layer
Common Database
LoanConsolida-
tion
Demographic
LoanServicing
Contact Financial
Debt Collection
DisabilityDischargeTracking
DataMart
CSB End-State Topology
Data Strategy§ Use incremental approach to conversion
– Phase 1 DLSS/LC Demographics and Data Mart– Phase 2 CSB/DCS Demographics, Financial and Contact Data– Phase 3 Move to VDC and additional Web enhancements
§ Build on existing DLSS schema– Identify and correct issues or limitations– Augment schema to accommodate CSB data– Work with FSA Data Strategy Team
§ Clean and reconcile data– Identify redundant data and “error” data– Develop business rule and resolve conflicts– Validate data integrity using independent teams (IV&V and QA/QC)
§ Implement Data Archiving– Use separate partition for archived data to increase performance
Impact on Independent Software Developers
§ CSB will maintain all interfaces while the legacy systems are operational
§ CSB will follow FSA Data Standards– XML– Common Record– School ID– Borrower ID
§ External interfaces will not be changed without consultation will all trading partners
Summary
§ CSB integrates processes, data and systems for Servicing, Consolidation, Collections, and Disability Discharge
§ CSB Contract Team comprised of familiar faces that have been supporting FSA for a combined total of over 30 years
§ CSB Solution supports FSA’s Performance Objectives and IT Standards
§ CSB is a Performance-based contract which helps ensure optimum results
§ CSB saves taxpayers money
Questions and Answers
