Introduction

ServiceNow Saipem is a useful enterprise case study for understanding how a large engineering and energy organization can use a centralized service-management platform to standardize IT operations, improve process visibility, and gradually extend digital workflows beyond traditional IT support. Saipem selected ServiceNow as part of a broader digital transformation initiative, initially focusing on IT Service Management and subsequently expanding the platform across areas including IT Operations, IT Business Management, Facility Management, and HR-related services.

For Oracle Fusion Cloud consultants, this case is particularly interesting because enterprise customers rarely operate a single application. A typical organization may have Oracle Fusion Cloud HCM, ERP or SCM, ServiceNow, identity platforms, payroll systems, cloud infrastructure, data platforms, and other business applications.

In such environments, ServiceNow frequently becomes a service-management and workflow layer, while Oracle Fusion remains a system of record for specific business processes.

This article examines the documented Saipem ServiceNow journey, explains the major architectural components, walks through representative implementation scenarios, and then shows how an implementation team could approach ServiceNow-to-Oracle Fusion integration in a comparable enterprise environment.

Important: The Saipem-specific facts in this article are based on publicly available ServiceNow and Saipem material. Where an Oracle Fusion integration architecture is discussed, it is presented as a practical implementation pattern rather than a claim that Saipem uses that exact Oracle integration.

What Is ServiceNow in the Saipem Context?

Saipem is a global engineering and construction organization operating across complex environments, including offshore, onshore, drilling, and energy-related activities. Its operating model creates a significant IT and operational-management challenge because services, users, infrastructure, suppliers, facilities, and business operations can span multiple countries and locations.

Saipem publicly described its adoption of ServiceNow as part of a transformation intended to improve efficiency, reduce operational silos, and improve management of internal processes. Its initial ServiceNow implementation focused on IT Service Management, with the first module going live in January 2018 according to the ServiceNow case study. The program was subsequently expanded to additional areas.

The documented ServiceNow solution set included:

The important implementation lesson is that Saipem did not attempt to transform every process simultaneously.

The transformation started with ITSM and then expanded the platform as the organization gained experience with the technology and operating model.

Why the Saipem ServiceNow Implementation Is Significant

Large enterprises often have a problem that is bigger than simply selecting a software product.

The real challenge is connecting processes.

For example, consider an employee who cannot access an application.

The business process might involve:

1. Employee submits a service request.

2. Service desk validates the request.

3. Identity information is checked.

4. Application ownership is identified.

5. Approval may be required.

6. A technical team performs the change.

7. The employee receives confirmation.

8. The request is closed and measured against SLA.

Without a centralized service platform, each step can exist in a different application or email chain.

A ServiceNow implementation can turn that sequence into a controlled workflow.

This is particularly valuable in a global organization because standardization becomes more difficult as the number of countries, locations, suppliers, applications, and service teams increases.

Key Capabilities in the Saipem ServiceNow Model

1. IT Service Management

ITSM was the starting point of the documented Saipem implementation.

The objective was to replace an existing proprietary IT service-management solution and improve the efficiency and transparency of IT processes.

A typical ITSM implementation includes:

• Incident management

• Request fulfillment

• Change management

• Service catalog

• Knowledge management

• SLA management

• Assignment groups

• Service ownership

• Notifications

• Reporting and dashboards

For example, instead of an employee emailing an IT team about a laptop problem, the employee can submit a categorized request.

The platform can then automatically determine:

• Which service is affected

• Which support group owns it

• Whether an approval is required

• Which SLA applies

• What notifications should be generated

• When escalation should occur

2. IT Operations Management

ITOM extends service management toward infrastructure and operational visibility.

ServiceNow’s documented Saipem case describes ITOM as providing improved visibility and traceability into IT service delivery, with benefits for security and business continuity.

This is especially important in a distributed enterprise.

An organization may have:

• Servers

• Databases

• Network devices

• Cloud resources

• Applications

• Integration endpoints

• Corporate offices

• Offshore assets

• Remote infrastructure

The operational challenge is not simply knowing that an infrastructure component exists.

The real requirement is understanding its relationship to business services.

For example:

Business Service → Application → Database → Server → Network

If a server fails, operations should be able to determine which application and business service could be affected.

3. IT Business Management

ITBM introduces a management perspective above individual tickets.

Instead of asking:

“How many incidents were closed?”

management can ask:

• Which IT services consume the most resources?

• Which initiatives require additional investment?

• Which services have recurring operational problems?

• Where are suppliers creating delays?

• Which projects should receive additional attention?

This moves ServiceNow from a ticket-processing system toward an enterprise management platform.

4. Facility Management

Facility-related services are another important extension.

Consider a request such as:

“The air-conditioning unit in an office meeting room is not functioning.”

A modern workflow can capture:

• Building

• Floor

• Room

• Asset

• Request type

• Priority

• Assigned facility team

• SLA

• Work completion

• User confirmation

This provides a common service-management model while allowing the underlying process to remain specific to facilities.

5. HR Service Delivery

Saipem’s ServiceNow journey subsequently expanded beyond IT. ServiceNow publicly described HR and facility processes as areas where Saipem wanted greater efficiency and transparency.

HR service delivery can support employee requests such as:

• Employment documentation

• HR policy questions

• Personal information requests

• Payroll-related questions

• Benefits queries

• Employee lifecycle requests

• HR case management

The architectural principle is important:

Employee → Service Portal → HR Case → Assignment → Approval/Workflow → Resolution

This is different from making ServiceNow the system of record for every HR transaction.

In an enterprise architecture, Oracle Fusion HCM or another HCM platform may remain responsible for core employee data while ServiceNow provides the service-management experience.

Real-World Implementation Scenarios

Scenario 1 – Enterprise IT Incident Management

Assume a multinational engineering organization has users reporting application problems through email, phone, and messaging.

The implementation team establishes ServiceNow ITSM as the controlled entry point.

A user reports:

“Engineering application unavailable.”

ServiceNow captures the incident and categorizes it.

The workflow determines:

Category: Application
Service: Engineering Application
Priority: High
Assignment Group: Application Support

The support team investigates the issue.

If multiple users report the same problem, the incidents can be correlated with a broader problem or outage-management process.

The practical benefit is not simply faster ticket creation.

The organization gains traceability from:

User → Incident → Service → Support Group → Resolution

Scenario 2 – Infrastructure Discovery and Service Mapping

Consider a global infrastructure containing thousands of nodes distributed across offices and operational locations.

A ServiceNow ITOM implementation can discover infrastructure components and establish relationships between configuration items.

A practical implementation flow is:

1. Identify infrastructure discovery requirements.

2. Define network and security prerequisites.

3. Deploy the appropriate discovery mechanisms.

4. Discover infrastructure components.

5. Normalize configuration items.

6. Establish relationships.

7. Validate service maps.

8. Link infrastructure to business services.

9. Build operational dashboards.

A public profile associated with a Saipem ServiceNow project describes discovery of infrastructure components across multiple continents and vessels, illustrating the complexity of the environment involved.

Scenario 3 – Oracle Fusion and ServiceNow Employee Service

Now consider an enterprise using Oracle Fusion Cloud HCM together with ServiceNow.

A common architecture could be:

Oracle Fusion HCM → Integration Layer → ServiceNow

Oracle Fusion remains the authoritative source for employee information.

When an employee is created or updated:

1. Employee information is generated in Oracle Fusion.

2. Integration logic identifies the relevant change.

3. Employee data is transformed.

4. ServiceNow receives the required attributes.

5. The ServiceNow user record is created or updated.

6. Subsequent HR requests can reference that employee.

Only the required attributes should be synchronized.

For example:

This architecture should be designed carefully so that two systems do not become competing systems of record.

ServiceNow Saipem Technical Architecture

A simplified enterprise architecture can be represented as follows:

Users / Employees

↓

ServiceNow Portal

↓

ServiceNow Workflow

↓

ITSM / ITOM / HR / Facilities

↓

Integration Layer

↓

Enterprise Applications

↓

Oracle Fusion / ERP / HCM / External Systems

The integration layer is particularly important.

For Oracle environments, Oracle Integration Cloud can act as an integration platform where appropriate.

A typical architecture could look like:

ServiceNow REST API

↓

OIC Gen 3

↓

Transformation / Mapping / Validation

↓

Oracle Fusion REST or SOAP API

↓

Oracle Fusion Cloud

For outbound processing:

Oracle Fusion

↓

OIC Gen 3

↓

ServiceNow REST API

↓

ServiceNow Record / Workflow

This architecture separates the business applications from the integration logic.

Prerequisites for a ServiceNow Enterprise Integration

Before building an Oracle Fusion–ServiceNow integration, establish the following.

Business prerequisites

Document:

• Business process

• System of record

• Data ownership

• Trigger conditions

• Required fields

• Approval requirements

• Error-handling expectations

• SLA requirements

• Security requirements

ServiceNow prerequisites

Confirm:

• ServiceNow instance

• Required application/module licenses

• Integration user

• Roles and permissions

• REST API availability

• Required tables

• Authentication mechanism

• Integration endpoint

• Field mappings

Oracle Fusion prerequisites

Confirm:

• Oracle Fusion environment

• Required REST/SOAP APIs

• User roles

• Security privileges

• Business objects

• Required attributes

• Integration requirements

• Data access restrictions

OIC Gen 3 prerequisites

For an OIC Gen 3 implementation, define:

• Connections

• Integration patterns

• Lookups

• Mappings

• Fault handling

• Monitoring

• Tracking fields

• Security credentials

• Environment-specific configuration

Step-by-Step Integration Build Process

Step 1 – Define the Business Object

Do not start by creating the OIC integration.

First define the business object.

For example:

Object: Employee

Required fields:

• Person Number

• Name

• Email

• Department

• Manager

• Location

• Employment Status

Then define which application owns each value.

Step 2 – Define the ServiceNow Endpoint

Identify the appropriate ServiceNow API and target table.

For example:

Operation: Create or Update User

The implementation team should confirm the exact ServiceNow API and table structure in the target instance rather than assuming that a standard table should always be used.

Step 3 – Configure the OIC Gen 3 Connections

Create the required ServiceNow and Oracle Fusion connections.

Typical connection responsibilities include:

ServiceNow connection

• Endpoint

• Authentication

• Credentials

• Security policies

Oracle Fusion connection

• Fusion environment URL

• Authentication

• API access

• Required roles

Store credentials securely and avoid hard-coding credentials inside integration mappings.

Step 4 – Build the Trigger

The trigger depends on the business requirement.

Possible patterns include:

Oracle → ServiceNow

Triggered by:

• Scheduled extraction

• Business event where supported

• Incremental data process

• API-based retrieval

ServiceNow → Oracle

Triggered by:

• New request

• Record update

• Workflow action

• REST request

Choose the trigger based on business requirements rather than forcing every process into real-time integration.

Step 5 – Transform the Data

Suppose Oracle Fusion sends:

PersonNumber = 100234
Email = user@example.com
Department = Engineering
Status = Active

The integration may transform it into the structure expected by ServiceNow.

The integration should also validate:

• Required values

• Email format

• Identifier uniqueness

• Department mapping

• Status values

Step 6 – Implement Error Handling

A production integration must handle failures.

Examples include:

• ServiceNow unavailable

• Oracle API timeout

• Invalid employee number

• Missing mandatory field

• Authentication failure

• Duplicate record

• Invalid department mapping

The integration should distinguish between technical and business errors.

For example:

Technical error

HTTP 500 – Service unavailable

Business error

Department value not mapped

These require different recovery procedures.

Testing the Integration

Testing should be performed using controlled test data.

Test Case 1 – New Employee

Create a test employee in Oracle Fusion.

Expected result:

• Employee record is identified.

• OIC processes the message.

• Required transformation occurs.

• ServiceNow record is created.

• Integration tracking shows success.

Test Case 2 – Employee Update

Change the employee’s department.

Expected result:

• Integration identifies the update.

• ServiceNow receives the new department.

• Existing record is updated rather than duplicated.

Test Case 3 – Invalid Data

Remove a required value.

Expected result:

• Validation identifies the problem.

• Transaction is not incorrectly committed.

• Error is logged.

• Support team can identify the failed record.

Test Case 4 – API Failure

Temporarily make the target endpoint unavailable.

Expected result:

• Integration captures the technical failure.

• Retry behavior follows the defined design.

• The error is visible in monitoring.

• No silent data loss occurs.

Common Implementation Challenges

1. Treating ServiceNow as the Master for Everything

This is a common architectural mistake.

ServiceNow may manage the workflow without owning the underlying business data.

For example:

Oracle Fusion HCM → Employee Master

ServiceNow → Employee Service Requests

These are different responsibilities.

2. Poor Data Mapping

Department values are a classic example.

Oracle may use:

ENG-001

while ServiceNow may use:

Engineering

A lookup or controlled mapping is required.

3. Duplicate Records

If the integration does not use a stable external identifier, repeated executions can create duplicate users or requests.

Use a reliable business identifier and design the integration for idempotent processing where appropriate.

4. Overengineering Real-Time Processing

Not every transaction requires real-time integration.

For some employee attributes, scheduled synchronization may be sufficient.

Real-time integration should be justified by the business requirement.

5. Ignoring Security

Integration accounts should have only the permissions they require.

Do not use broad administrator access simply because it makes initial testing easier.

6. Lack of Operational Monitoring

An integration that works during SIT but cannot be monitored in production is incomplete.

The support team should know:

• What failed

• When it failed

• Which record failed

• Why it failed

• Whether retry is safe

• Who owns the resolution

Practical Consultant Best Practices

Start with the process, not the platform

Before discussing tables, APIs, or integrations, document the business process.

Ask:

What happens today?

Then ask:

What should happen after implementation?

This exposes unnecessary customizations early.

Establish system-of-record ownership

Create a simple matrix:

The exact ownership model depends on the customer’s architecture.

Use stable identifiers

Do not depend only on names or email addresses.

Employee names can change.

Email addresses can change.

A stable enterprise identifier should be used whenever possible.

Design for reprocessing

Production failures are inevitable.

A good integration design allows failed transactions to be diagnosed and safely reprocessed.

Keep integrations loosely coupled

Avoid embedding excessive business logic inside mappings.

Business rules should have clear ownership and should be maintainable without rebuilding the entire architecture.

Separate environments

Use separate configurations for:

• Development

• Test

• Production

Never assume that endpoint URLs, credentials, or lookup values are identical across environments.

Measure business outcomes

The documented Saipem case provides a useful example of measuring operational outcomes rather than simply reporting that a platform was implemented. ServiceNow reported metrics including reduced average ticket processing time and improved user satisfaction for support requests.

The implementation lesson is important:

Go-live is not the final KPI.

Measure:

• Ticket resolution time

• SLA compliance

• User satisfaction

• Reassignment rate

• Automation rate

• First-contact resolution

• Backlog

• Recurring incidents

• Integration failure rate

What Oracle Fusion Consultants Can Learn from the Saipem Case

The biggest lesson is that enterprise applications should be viewed as an ecosystem.

A customer may have:

Oracle Fusion HCM

for workforce information,

Oracle ERP

for financial and procurement processes,

ServiceNow

for service management and workflow,

OIC Gen 3

for integration,

and additional cloud platforms for infrastructure and analytics.

The consultant’s responsibility is therefore not merely to configure one application.

It is to understand the boundary between applications.

For example:

Oracle Fusion HCM

owns employee and assignment information.

↓

OIC Gen 3

validates, transforms and routes integration data.

↓

ServiceNow

manages the employee-facing service process.

↓

HR Support Team

resolves the request.

This separation makes the architecture easier to govern and maintain.

Frequently Asked Questions

1. What is ServiceNow Saipem?

ServiceNow Saipem refers to Saipem’s documented adoption and expansion of the ServiceNow platform as part of its digital transformation. The program began with IT Service Management and expanded into areas such as IT Operations, IT Business Management and Facility Management, with HR service delivery also becoming part of the broader transformation.

2. Which ServiceNow modules were associated with Saipem’s transformation?

Public ServiceNow case-study material identifies IT Service Management, IT Operations Management and IT Business Management as core solutions, while the broader transformation also included Facility Management and HR-related service delivery.

3. Can ServiceNow integrate with Oracle Fusion Cloud?

Yes. ServiceNow provides APIs and integration capabilities, while Oracle Fusion Cloud exposes supported integration interfaces. In an Oracle-centric architecture, OIC Gen 3 can be used as an integration layer between the two platforms when the customer’s requirements justify it. The actual API, authentication mechanism, data model and integration pattern should be validated against the customer’s licensed products and current product documentation.

Summary

The ServiceNow Saipem case demonstrates how enterprise service management can evolve from a focused ITSM implementation into a broader digital process platform.

The documented journey started with ITSM and expanded into IT Operations, IT Business Management, facilities and HR-related services. The important implementation principle was progressive adoption rather than attempting to transform every business process simultaneously.

For Oracle Fusion consultants, the case also illustrates an important enterprise architecture principle: ServiceNow and Oracle Fusion do not necessarily compete for the same responsibility.

A well-designed architecture can use:

Oracle Fusion Cloud → system of record

ServiceNow → service and workflow platform

OIC Gen 3 → integration and orchestration layer

This approach provides clearer ownership, controlled data movement, better monitoring and easier long-term support.

For Oracle-side reference material, use the official Oracle Fusion Cloud Applications documentation. For implementations involving employee time data, the Oracle Fusion Cloud Time and Labor documentation explains time entry, validation, calculation, approval and transfer processes. The 26A Time and Labor documentation should be used when working specifically with 26A functionality.