Johnson & Wales University — Multi-Phase CRP2 Purchasing & AP Implementation

Executive Summary

Johnson & Wales University — a private culinary and hospitality university with campuses in Providence, Denver, Charlotte, and North Miami — undertook an Oracle EBS implementation to modernize its procurement and financial operations across a geographically distributed institution. The engagement was structured as a phased implementation: Phase 1 covered Purchasing (PO) and Accounts Payable (AP) with Cash Management integration; Phase 2 proposed extending to additional modules pending budget and resource availability.

The CRP2 methodology was applied with a strong emphasis on training — recognizing that university staff, many of whom were not technically oriented, would need more preparation than a corporate implementation typically requires. Training materials were developed separately from setup documentation, reflecting a deliberate distinction between system configuration (consultant responsibility) and user capability building (joint responsibility).

The multi-org structure reflected the university's campus organization: each campus operated with some financial autonomy while reporting into a consolidated university ledger — a common pattern in higher education that Oracle's multi-org architecture handles well, but only if the operating unit design is aligned to the institution's actual governance model.

Engagement Context

Higher education institutions present a distinctive Oracle EBS implementation context. Budget cycles are annual and tied to academic calendars — go-live timing must avoid the beginning of fall semester (peak purchasing activity) and fiscal year-end (peak AP and GL activity). Procurement patterns are seasonal and category-heavy: food service purchasing dominates at a culinary university, requiring supplier relationships, purchasing categories, and approval authorities aligned to that reality.

University AP departments typically process a high volume of low-value invoices — food suppliers, facility vendors, student activity purchases — making invoice matching efficiency and payment batch automation more important than at a manufacturing company processing fewer, higher-value invoices. The payment terms and cash management cadence are also institution-specific: universities often operate on net-30 to net-60 terms with most vendors but have strict payment timing requirements for student-facing services.

The phased implementation approach was appropriate for an institution with limited IT resources and a staff that would be learning Oracle EBS for the first time. Attempting to implement all Oracle Financials modules simultaneously would have overwhelmed both IT staff and end users. Phase 1's focus on the highest-volume processes (purchasing and AP) delivered immediate value while building institutional Oracle competency before Phase 2 expansion.

Oracle Implementation Scope

Purchasing (PO) — Multi-Campus Structure

The PO implementation was structured around the university's campus organization, with each campus designated as an Oracle operating unit. Campus-level buyers were assigned to campus-specific purchasing responsibilities, while university-wide contracts (food service, office supplies, facilities) were managed centrally through a shared services operating unit. Approval hierarchies were designed to reflect campus budget authority alongside university-level approval requirements for large purchases.

PO Phase 1 covered standard purchase orders, blanket purchase agreements for recurring suppliers, and the request-for-quotation process for competitive sourcing. PO Phase 2 (proposed) would add web requisitions and iProcurement for campus requestors — extending purchasing self-service to faculty and staff who currently submitted requests by email or paper form.

Accounts Payable (AP) — Period-End Focus

AP configuration emphasized period-end close procedures — a consistent pain point for university finance teams that must close periods on a rigid schedule tied to board reporting and grant accounting requirements. Invoice matching was configured for three-way matching on goods purchases and two-way matching on service invoices. Payment batches were configured for the university's primary payment methods, with bank account assignments aligned to each campus's bank relationships.

Cash Management (CM)

Cash Management was implemented to support bank statement reconciliation across the university's multiple bank accounts. The CM training module was delivered as a standalone session, reflecting the finance team's specific request for hands-on bank reconciliation practice before going live with the new process.

General Ledger (GL) & Accounts Receivable (AR)

GL served as the consolidating ledger for all campus operating units. AR was configured to support student tuition billing and third-party receivables — an area with higher institutional sensitivity given the student relationship dimension of AR collections.

Methodology Applied

1. Phase 1 Scoping and CRP1: PO, AP, and CM scope confirmed through fit-gap analysis. CRP1 configuration completed and validated with a small group of finance staff.
2. CRP2 — Setup Parts One and Two: CRP2 was documented in two parts (JWU CRP2 PO Setup Part One and Part Two), reflecting the sequential nature of Oracle PO configuration — document management and approval setup in Part One, purchasing categories and buyer setup in Part Two.
3. Role-Based Training Development: Training materials were developed by Oracle role — Buyer, AP Clerk, GL Accountant, Cash Manager — with university-specific scenarios (food service PO, faculty expense reimbursement, tuition payment batch).
4. Production Training Delivery: Training was delivered in campus-specific sessions to account for campus staff availability. Hands-on practice in a training instance preceded go-live.
5. Period-End Close Readiness: Period-end close procedures were documented and rehearsed before go-live — ensuring that the AP team could execute their first Oracle period close without consultant support on site.
6. Phase 2 Proposal: Following Phase 1 go-live, an iProcurement and web requisitions Phase 2 proposal was developed for stakeholder review and budget approval.

Key Deliverables

Technical Architecture

The multi-campus multi-org structure required careful design of Oracle's MO (Multi-Org) profile option hierarchy. Each campus operating unit had its own AP payment processes, bank accounts, and period-end close schedule — while sharing the university-wide chart of accounts, supplier master, and GL consolidation ledger. The MO: Operating Unit profile option was set at the responsibility level, allowing campus-specific responsibilities to automatically restrict transactions to the correct operating unit without user intervention.

The period-end close sequence — AP period close before GL period close, with AP subledger transfer to GL validated before GL close — was documented as a specific procedural requirement, given that the finance team's prior system had not enforced this sequencing and several staff were unaware of the Oracle subledger-to-ledger dependency.

Critical Challenges & Resolutions

Challenge 1: Campus Budget Authority Alignment

Approval hierarchies needed to reflect both campus-level budget authority (campus finance director approves campus purchases up to threshold X) and university-level approval requirements (university CFO approves any purchase above threshold Y, regardless of campus). Oracle's standard position-based approval hierarchy did not natively support this dual-level structure. Resolution was a hybrid approval setup using both position hierarchy and approval groups, with clear documentation of the routing logic for each approval scenario.

Challenge 2: Training for Non-Technical Staff

University staff — including faculty administrators, food service buyers, and facilities managers — had limited experience with ERP systems. Standard Oracle training materials, written for business analysts who understand ERP concepts, were not appropriate for this audience. Resolution was custom training materials written entirely in university vocabulary, with scenarios drawn from actual JWU purchasing activity, and hands-on exercises that walked users through their specific job tasks rather than generic Oracle demonstrations.

Challenge 3: Seasonal Implementation Timing

The university's academic calendar created hard constraints on go-live timing: fall semester start (September) was the highest-volume purchasing period; fiscal year-end (May/June) was the highest-volume AP period. Implementation had to avoid both. Go-live was planned for January — low purchasing volume, mid-fiscal-year — providing a period of lower operational pressure during the Oracle learning curve.

Challenge 4: Food Service Supplier Volume

The food service operation required a large number of supplier records — daily delivery suppliers, specialty ingredient vendors, equipment suppliers — with frequent price list changes and complex blanket agreement terms. Supplier master data migration was a larger-than-expected effort, requiring a structured data cleanse and standardization of supplier names, tax identification, and payment terms before Oracle import.

Consultant Insights

Reusable Patterns

• Education Sector Multi-Campus PO Structure: Campus operating unit + central shared services operating unit + university-wide chart of accounts is the standard multi-org design for most multi-campus universities — reusable as a starting template for any higher education Oracle implementation.
• Dual-Level Approval Hierarchy Design: The campus-level + university-level hybrid approval structure is a reusable pattern for any organization with both local and central approval authority requirements.
• Role-Based Training with Client Scenarios: The training design approach — role-specific materials using real client data and actual job tasks — is directly reusable and produces better outcomes than generic Oracle training materials for any implementation with non-technical end users.
• Period-End Close Checklist Format: The checklist-format period-end documentation (step / owner / timing / exception handling) is a reusable template for any AP and GL period-end close documentation deliverable.

Lessons Learned

Related Engagements