Enhancing Admissions Workflow: E-AdmitTM Management System Phase 2

1. Implementing a Paperless Admission System Phase #2 Thomas Skottene & Nancy Walsh Office of Undergraduate Admissions University of Illinois at Urbana-Champaign

2. Agenda • Intro • Modules • Document Management • Processing • Review • Post Review • Reports • Applicant Experience • Framework Functionality • Q & A

3. Timeline & Resources • Largest Office of Undergraduate Admissions (OUA) project since the ERP (Banner) implementation in 2003 • eAdmitTM went live in August 2011 for the 2012 admissions cycle • Some parts will complete in fall 2011 and spring 2012

4. Scope & Benefits • Goal: • Replace our previous paper docket process with an electronic web based workflow and document delivery system • Benefits: • Do more with less, through • Increased automation • Improved transparency • Improved workflow

5. Development • Built by the Office of Undergraduate Admissions (OUA) with in-house resources • Browser Based Program • We can change it over time as we see the need • Banner interfaces • Daily import job • Some instant Banner updates

6. High Level Process Flow Scanned Documents & PDF Transcripts eAdmitTM 95% of all OUA work100% of College work DARwin No Change Keep as paper process for now Change Forms Goal: Get the Banner data we need and make Banner look like it did before eAdmitTM Some data flows instantly, most flow once a day Self Reported Academic RecordTM Daily import At 5:30AM Online Web Application Form BannerLess than 5% of OUA activity Test Scores

7. eAdmitTM Modules

8. Opening Screen • eAdmitTM users have the same opening or splash screen after logging in • Goal: • Make sure users are cognizant of our current application numbers • Data elements: • # of Scanned Documents • # of Applications • # of Decisions

9. Opening Screen • Screenshot

10. eAdmitTM Document Management Or DocQ

11. Document Management • Purpose • Receive, prep, index, match, and route incoming documents, electronic and paper • Non-eAdmitTM steps • Receive, open, and sort mail • Filter out materials that will not be scanned • E.g. letters of recommendation, CD of piano recital, certificate of health club membership, etc.

12. Scanning, Indexing & Uploading • All relevant incoming documents will be scanned • unless they are already in an electronic format we can use • All documents will be indexed/uploaded • Add identifying information such as name and DOB • Indentify what kind of document it is • Transcript (+ institution, if available), passport copy, fee waiver, etc.

14. Automated Matching • eAdmitTM will try to match a new document based on the known data to either a student or an applicant • A nightly job runs to match any new applications or students against existing uploaded documents in eAdmitTM • Success depends on the accuracy of the meta-data added

15. Manual Matching Component • For single matches a DM staff member will manually verify that eAdmitTM made a valid match by comparing: • Scanned Document • Banner Data • Indexed Data • If not, the staff member can exclude the match, leave the document, or search for another match • For zero or multiple matches a DM staff member can • Search for new matches • Narrow down existing matches • Provides tools • Partial or fragmented fields • Switch first/last name, etc • Manage applicant vs. student search

16. Document Search • DocQ allows searches for any document by available meta-data: • Name • DOB • Document Type • UIN (University Identification Number) • Document ID (internal reference number) • Handy for routing of un-matched documents • Institution • Handy if you need to find a transcript you know came from a specific school, but must have been mismatched

18. eAdmitTM Processing

19. Processing • Automated • Process steps that only require error reports and spot checks • Self-Reported Academic Record (SRARTM) • Semi-Automated • Steps that require limited human intervention • Manual • Steps that still require human intervention

20. SRARTM • Self-Reported Academic Record • Inspired by University of California system, Georgia Tech, Rutgers, and others • Freshman applicants self report their academic record • Self-reported data is used to review application & make decision • Once applicants accept their offer, we check the final transcripts for discrepancies • Large administrative savings • 7,000 vs. 28,000 transcripts, automation possibilities

22. Fully Automated Steps • Matching online forms • like the SRARTM, appeals, etc. based on their application ID • Academic calculations • Pattern analysis • English proficiency • Essay check

23. Semi Automated Steps • Dedicated screens for analyzing applicant responses - First Generation - Educational Goal

25. Manual Steps • Transfer Processing • Long list of manual tasks • Initial Validation • High School Work • College Work • eAdmitTM will only keep track of status and manage the workflow

26. Processing Summary • Automation where possible • Very large savings in time and effort • In theory, a freshman could apply at 5PM and be available for review by 8AM the next morning! • All wins come at a price  • Some issues might not be discovered until they reach review

27. eAdmitTM Review

28. Worklists • Review, like most work in eAdmitTM, is organized into Work Lists • Work Lists are chunks of work waiting to be done • Work Lists can be sorted or prioritized according to need • Work Lists can be assigned according to need

30. Review • Organization • All workflow is managed by worklists and committees • An applicant will show in a worklist based on their status which includes • Committee membership (most often program code) • Referral status • Number of reads and who did these reads • Decision status • College status • Special requirements status

38. These will open as PDFs

44. Transfer Review • Same application data as for freshmen • Different review sheet • Different worklists • Different committees

49. Other Reviews • We also have some processing and review that does not fall neatly into our common procedures: • Non-degree • Dual Admission • Etc

50. eAdmitTM Framework Functionality