Oracle Modern Best Practice, and the documents that carry an HCM Cloud implementation.

A published library of common business processes that Oracle has optimized to take advantage of the latest Fusion Cloud applications and technologies. They're distilled from analysis of 10,000+ delivery projects — both successful and unsuccessful — then reviewed by Oracle experts and published for public reference on oracle.com.

Crucially, an OMBP is not a click-by-click application flow. It's a digital business process — an end-to-end depiction of how a process (say, absence through to payroll) should run when it fully leverages Oracle technology. You use it as the target picture to design toward.

Oracle describes OMBP with a handful of defining traits. The ones worth memorising:

• Dynamic — updated regularly to match evolving customer needs and new application capabilities (tracked against quarterly release versions like 25D, 26A).
• Trusted — every process is validated and tested by Oracle experts, not theoretical.
• Modern / technology-enabled — built to exploit AI/ML, analytics, mobile and more, rather than digitising old manual steps.
• End-to-end — spans departments to remove silos, connecting global process owners to real business outcomes.

What makes a best practice "modern" is the set of digital enablers embedded into each process step. Each OMBP diagram tags which of these it leverages:

In HCM, the ones you meet most are AI/ML (recommendations, predictive attrition, resume screening), Analytics (embedded dashboards, OTBI), and Mobile (self-service on any device).

For Human Capital Management, OMBP maps the whole Hire-to-Retire employee lifecycle into optimized sub-processes — for example Recruit to Onboard, Absence to Payroll, Time to Pay, Goal to Reward, and Talent Review to Succession. Each shows the AI- and analytics-enabled path through Core HR, Absence, Payroll, Time & Labor and Talent.

Oracle's guided platform that brings OMBP into the project instead of leaving it on a website. Cloud Success Navigator lets a team browse OMBP processes by industry and functional area, open each activity to see its Key Features (with effort/impact indicators), and align their implementation to quality benchmarks at each stage of the cloud journey.

A predefined configuration of Oracle Cloud Applications, aligned to OMBP, that Oracle can deploy into a customer's test environment. It ships with sample master and transactional data and predetermined usernames, so the team can see the best-practice process running from day one and configure by tailoring it, rather than building from an empty pod.

Oracle positions OMBP as usable at every stage of the journey — to educate stakeholders, demonstrate what new capabilities enable, plan the path to the target solution, and benchmark scope, progress and benefits. In practice, on an HCM project it anchors the design phase: it's the reference "to-be" you hold your Fit-Gap and configuration decisions against.

Oracle's own implementation methodology for Fusion Cloud. It's built around configuration over customization, standard-first design, and iterative prototyping — and it embeds OMBP as the process foundation. TCM is the method Oracle-led and many partner-led Cloud HCM projects follow today.

Oracle's full-lifecycle, phased method that predates the cloud-specific TCM and is still widely referenced by system integrators. It defines the classic work-product library (requirements, analysis, design, build, test, transition, production). Many document names consultants still use — RD.xxx, MD.050, MD.070, CV.xxx, TE.040 — trace back to OUM (and its predecessor, AIM).

The core analysis activity: take each required business process and compare it against Oracle Fusion's standard functionality (the OMBP target). Every requirement is classified as a fit (standard covers it), a gap (needs an extension, workaround, or process change), producing the backlog that drives every design document downstream.

A structured walkthrough where the team demonstrates the configured system to the business against real scenarios, to validate that the design matches requirements before deeper build. Projects usually run several rounds (CRP1, CRP2…), each tightening the configuration. Each CRP has its own scenario scripts and captured feedback.

A typical Cloud HCM lifecycle, and which documents each phase produces:

1. Plan / Prepare — project charter, scope, instance strategy.
2. Design / Architect — BRD, Fit-Gap, FDD, TDD, Security & Solution design (Section 3).
3. Configure / Build — Config Workbook, data conversion, integrations, fast formulas, reports (Section 4).
4. Validate / Test — CRP, SIT and UAT scripts and results (Section 5).
5. Deploy / Transition — cutover plan, go-live checklist, training (Section 5).
6. Operate / Run — hypercare, SOPs, and continuous adoption of new quarterly features.

The signed-off statement of what the business needs — process requirements, rules, volumes, and success criteria, gathered in requirement workshops. It's the baseline every later document traces back to. On OMBP-led projects, requirements are gathered solution-first: you demonstrate the standard process, then capture where the client genuinely differs.

The written output of the Fit-Gap activity (2.3): a register of each requirement marked Fit / Gap, with the recommended disposition for gaps — standard config, a personalization/extension, a manual workaround, or a business-process change. It's what turns "what the client asked for" into "what we're going to build."

The most critical build document: it defines how each requirement will be implemented functionally — the setup choices, business rules, approval flows, and expected behavior. In HCM it's written per area (e.g. an FDD for Absence plans, one for Payroll elements, one for an interface). The technical team builds from it; testers verify against it. MD.050 is its classic OUM/AIM code.

The technical companion to the FDD, written for anything custom — integrations, extracts, BIP/OTBI reports, fast formulas, and extensions. It specifies the technical how: data sources and mappings, logic, tools (OIC, HCM Extracts, HDL), error handling, and performance. Written by the technical consultant/developer. MD.070 is its classic code.

The enterprise-level design that sits above the module FDDs: enterprise structures (legal entities, LDGs, business units), the module footprint, the integration landscape, and the instance/environment strategy. It's the architectural view that keeps individual designs consistent and prevents shared foundational objects from being designed twice.

The design of the role-based access model: which job roles, duty roles, data roles and security profiles exist, who gets them, and how segregation of duties is enforced. In HCM this also governs sensitive data access (health, compensation, personal data), so it's where compliance rules like data-privacy restrictions get implemented.

The master tracker of everything beyond vanilla configuration: Reports, Interfaces, Conversions, Extensions, Forms/Fast Formulas, and Workflows. Each row links to its FDD and TDD and carries status, owner, and complexity. It's the single list that tells a PM how much custom work remains.

The record of every setup value applied in the application — often a workbook mirroring the Functional Setup Manager (FSM) task lists. It captures what was set, in which environment, so configuration can be reproduced across pods (Dev → Test → Prod) and audited later. BR.100 is the legacy name still used for it on many projects.

The plan for moving legacy data into HCM: what objects convert (workers, assignments, balances, elements…), the field-level mapping, cleansing rules, load sequence, and reconciliation approach. Split across a strategy document and mapping sheets (classic codes CV.010 / CV.040). Data readiness is a top cause of go-live slips, so this starts early.

The concrete load artifacts behind the conversion strategy. HCM Data Loader (HDL) uses pipe-delimited .dat files with METADATA lines defining each object's attributes; the design records which business objects, keys (user keys vs source keys), and file structures are used. The Spreadsheet Loader (HSDL) is the lighter, spreadsheet-based alternative for smaller loads.

The specification for each inbound/outbound interface between HCM and other systems (benefits providers, payroll third parties, finance, IdM). It defines the source/target, tool (OIC, HCM Extracts, web services), frequency, field mapping, and error handling — effectively a TDD focused on integration. Often tracked collectively in an interface inventory.

Documentation for each Fast Formula — Oracle's rule language for element calculations, absence accruals, eligibility, proration, skip rules, and validation. The design records the formula's purpose, inputs (database items), logic, and return values, so the rule can be reviewed, tested, and maintained rather than living only in the pod.

The catalogue and design of custom reporting: BI Publisher (BIP) pixel-perfect outputs (payslips, statutory reports) and OTBI analyses and dashboards for operational reporting. Each entry specifies the subject area/data model, columns, filters, layout, bursting, and security. Standard OMBP dashboards cover a lot, so this inventory should list only genuine gaps.

The umbrella documents for validation: the Test Strategy sets the approach, types (unit, SIT, UAT, regression, performance, parallel payroll), environments and entry/exit criteria; the Test Plan schedules cycles, resources, and defect management. Together they make testing systematic rather than ad hoc.

Step-by-step scripts that validate end-to-end process flows across modules and interfaces — e.g. hire in Core HR → absence → payroll → outbound interface to a third party. Run by the project team, SIT confirms the pieces work together, not just individually. Each script lists steps, test data, and expected results.

Business-owned scripts where real end users validate the system against their requirements using realistic scenarios, and formally accept it. UAT sign-off is the primary gate to go-live. Scripts trace back to the BRD, closing the requirement-to-acceptance loop. (TE.040 is the classic script code.)

The minute-by-minute sequence of tasks to move to production: final data loads, config migration, validations, approvals, and the fallback/rollback plan — each task with an owner, dependency, duration and timestamp. It's usually rehearsed in a mock cutover before the real one so timing and gaps are known in advance.

The go/no-go readiness list confirming everything is in place before switching on: data reconciled, security assigned, integrations verified, UAT signed off, training delivered, support model ready. Each item has an owner and a status, and the whole list is reviewed at the go/no-go decision meeting.

The end-user enablement set: role-based user guides, quick reference cards, and training workbooks — increasingly delivered in-app through Oracle Guided Learning (OGL) so help sits inside the Redwood screens. Good training is what turns a technically correct go-live into actual adoption. (DO.070 is the classic user-guide code.)

The post-go-live set: the hypercare plan (heightened support right after launch — issue triage, SLAs, escalation), and SOPs / operational runbooks for recurring tasks (payroll runs, quarterly-update regression, period processing). This is where the project hands over to a sustainable run model.