At a Glance
The big picture: Organizations using a system integrator for their Oracle Fusion Cloud transformation will want to take several critical steps before signing the contract to facilitate success.
Why it matters: Subjective, misinterpreted or neglected contract elements can cause delays, missed scope and cost overruns.
The bottom line: Transformations can be disruptive, but investing time in contract development will ultimately save time and money.
Oracle Fusion Cloud transformations often result in major efficiencies and procedural improvements for adopting organizations – end results often include increased transparency, control and decision-making abilities for key business activities. In hindsight though, stakeholders often wish they’d structured their system integrator (SI) contracts differently. Despite hiring a highly regarded, credentialed or recommended SI, organizations often feel their contracts did not adequately prepare them for the actual implementation experience, with change orders and frustrations being a symptom. Aside from general contracting best practices, there are specific elements and techniques organizations will want to consider prior to inking the agreement that typically spans multiple years, and seven or eight figures of spend.
Key components
This isn’t an exhaustive list of contractual elements that could be subjective, misinterpreted or neglected – but it includes some repeat offenders.
- Scope – Bill of Materials (BOM)-based terminology: A BOM represents what the organization is purchasing or licensing from Oracle (suite, applications, etc.), and therefore is the population of where implementation help may be needed. SIs may use a different vernacular, given the evolving Oracle landscape or their interpretation of the need. Ensure the SI covers all needs to avoid modules/functional areas being left behind.
- Program management (PM) methodology – Agile vs Waterfall: Unless the organization has executed large-scale, time-boxed and milestone-based programs in an Agile fashion before, don’t relent to SI pressure to veer from traditional Waterfall approaches. Although the SI may be adept at Agile execution, an inexperienced organization will be expected to keep up. If delays are experienced and the blame is placed on the company, it could result in costly change orders or failed delivery given pace-based assumptions. Regardless of methodology, an actionable project plan – detailing both SI and customer responsibilities – should be produced early in the program. Instead of perceiving a high task count as robust and thorough, focus on sound project plan cornerstones such as:
-
- Tasks identify responsible parties,
- Interdependencies are captured, and
- Critical path is defined.
Deliverables should also meet certain, prespecified acceptance criteria as to align on what good looks like. This will go a long way in minimizing iterations and costly churn.
- Clarity of task responsibility – RACI matrix: A transformation requires significant collaboration between internal and external parties, often worlds apart culturally. A Responsibility/Accountable/Consulted/Informed matrix should be leveraged to eliminate misinterpretation of task ownership, which inevitably results in “I thought someone else was handling that…” disconnects. This tried-and-true PM method is especially helpful for workstreams where handoffs or co-leadership is agreed to (e.g., data conversion). Also, gaining such clarity early on can help facilitate proactive backfill-related conversations, enabling critical personnel to participate in more appropriate capacities.
- Adjustments to the internal control framework: The control landscape that previously mitigated unacceptable risk for the organization will not magically be ready for a transformed, future state. Overhauling efforts are not typically handled by a SI, nor should they be. One immediate value-add stemming from this track is improved visibility into necessary key reports; if the legacy state needed 200 reports for business decision-making and control purposes, why would a significantly lower number (50) be sufficient from a contractual standpoint?
- Application security: Minimize (unnecessary) spend and risk while enabling end-users: This workstream commonly results in “rescue missions” or “re-dos”, simply because it is almost always underestimated. Decrease that likelihood per the following:
- Seeded vs. custom and how many?: The answer is two-fold; publicly traded companies beholden to Sarbanes Oxley (SOX) obligations cannot simply utilize out-of-the-box security due to common Segregation of Duties (SoD) risks. A reliable rule of thumb for setting the contractual floor is to anticipate approximately five job roles per module; an administrator, a read-only, a manager and a few transactional intensive roles.
- Plan for Tier 1/Help Desk access – everything is not an option: Application Managed Services (AMS) providers desire to utilize the seeded Application Implementation Consultant (AIC) job role to fulfill day two obligations, but this is the single most powerful and expensive (per licensing – see next bullet point) job role Oracle provides. Allowing anyone to have system administrator access within production isn’t acceptable for most organizations, especially in those with disciplined change management processes.
- Role licenses – not all are created equal: Oracle job roles are comprised of privileges, with predetermined ones enabling certain functional area access within the platform. Some seeded Oracle job roles can trigger 20+ licenses, regardless of whether your organization uses that functionality or not. Ensure security methodology considers this to avoid future invoice sticker shock.
- SoD Tool – BYOD or use ours: The organization will be obligated to maintain baselined security architecture and that cannot be done manually. Often, SIs utilize their own proprietary or preferred SoD tool rather than the organization’s, which should strive to have its tool be the definitive measure – this will go a long way in ultimately getting an external auditor on board from a reliance standpoint.
- Data Conversion – getting data into the target destination: SIs regularly assign customers the primary responsibility and accountability to convert their own data, while providing some support. This typically translates to the customer putting the data into Oracle’s provided File Based Data Import (FBDI) files and the SI pushing upload; if it fails – triaging and resolution will fall to the customer. Sounds simple, but there can be multiple FBDI templates for a single data element, and there will likely be north of 25+ data elements. This extrapolates to 50+ files, each of which are not “smart,” meaning they don’t provide data integrity validation features. Do not underestimate this workstream.
- Interfaces – map necessary data inroads: Odds are, the existing system has a lot of hooks into it, with boundary systems pumping in information (e.g., banking integration, credit card reconciliation for expenses, CRM systems, etc.). Having a complete picture of the system landscape will aid the SI in quantifying the number of integrations the Oracle platform should accommodate. Similar to reports, if the SI partner estimated 10 integrations for your transformation – but 50 currently exist, it’s likely a change order will be signed.
Available techniques
The above may seem like a minefield to navigate, but it is possible to drive towards a right-sized contract:
- Commission an “early start” or “phase 0”: Pay the SI to better understand the organization and produce a more tailored contract based on the organization’s unique needs. Proactively spending one to three percent of total transformation budget, up front, could mitigate material overages.
- Proactively catalog current-state controls, reports and interfaces: While the current-state is not directly indicative of where the future-state is headed, it can serve as a sanity marker.
- Ensure contract interpretation consensus: A 50+ page document, full of “consultant-ese” can mean a lot of different things to different people. Conduct a “safe space”, internal read-through with key stakeholders to flesh out ambiguous elements.
- Commission a third-party contract review: Prior to execution enlist an unbiased entity who is versed in the implementation space, who can highlight areas needing increased definition.
Transformations are intentionally disruptive, but it is possible to prepare for greater success by participating in the contract’s structuring.
Read our 2023 Global IT Executive Survey: The Innovation vs. Technical Debt Tug-of-War.
To learn more about our Oracle solutions, contact us.
