Tekelec — Oracle EBS Requirements, CRP2 Implementation & Post-Acquisition Financials Setup

Client	Tekelec
Industry	Technology — Telecom Signaling Software
Oracle Version	Oracle E-Business Suite 11i
Modules	AP AR FA GL OIE
Engagement Period	2003
Project Type	Oracle EBS Requirements Gathering, CRP2 Testing & Acquisition Integration Setup
Complexity	High · 5-Module Scope · Post-Acquisition Entity · CRP2 · Custom PLL

Executive Summary

Tekelec — a Calabasas-based developer of signaling software for telecommunications networks — undertook a multi-module Oracle EBS 11i implementation in 2003 covering Accounts Payable, Accounts Receivable, Fixed Assets, General Ledger, and Oracle Internet Expenses. The engagement began with a structured requirements gathering phase in September 2003 (questionnaires across all five modules), progressed through formal Business Requirements Documents, and advanced to CRP2 (Conference Room Pilot Phase 2) testing — covering the full implementation methodology from requirements through configuration validation.

A significant mid-engagement complexity: the "Tekelec - Santera Financials Set Up" document confirms that Tekelec's 2003 acquisition of Santera Systems — a competing telecom software startup — created an immediate post-acquisition financials integration requirement. The Oracle financials environment being configured for Tekelec needed to absorb Santera's financial operations, requiring legal entity setup, chart of accounts alignment, and intercompany transaction framework decisions within the same project timeline as the base implementation.

Engagement Context

Tekelec specialized in Signaling System 7 (SS7) protocol solutions — the signaling layer that routes phone calls and SMS messages across global telecom networks. Their customer base was tier-one carriers (AT&T, BT, Deutsche Telekom) and their revenue model was a combination of software licenses, hardware platforms, and professional services. This revenue mix — license recognition at contract execution, hardware at delivery, services over time — creates AR configuration complexity: multiple revenue streams with different recognition triggers required multiple AR transaction types and careful auto-accounting configuration.

The 2003 acquisition of Santera Systems (a startup developing softswitching platforms) added private company accounting to a public company's Oracle environment. Santera had its own chart of accounts, its own vendor base, and potentially its own fixed assets — all requiring rationalization against Tekelec's Oracle configuration. Post-acquisition financial integration in Oracle is a common engagement pattern but rarely a simple one: the acquiring company's Oracle structure was designed without the acquired entity in mind, and adapting it requires decisions about operating unit structure, intercompany balancing, and cost center mapping that affect every downstream module.

The remote connectivity infrastructure visible in the engagement artifacts — .pcf (Cisco VPN profile) files for Calabasas CA, Raleigh NC, and Richardson TX locations — confirms that Tekelec had multi-site operations requiring remote Oracle access for both consultants and distributed user communities. The TNSNAMES.ORA configuration file reflects the Oracle network connectivity setup required for multi-site Oracle access in the 2003 era (before modern Oracle cloud infrastructure).

Implementation Scope

Requirements Gathering (September 2003)

Module-specific questionnaires were developed and completed for all five modules: AP, AR, FA, GL, and OIE. These questionnaires — the structured discovery instrument of Oracle AIM methodology — captured Tekelec's existing business processes and requirements in each area, providing the foundation for the Business Requirements Documents (BRDs) that followed. Separate questionnaires per module ensure that subject matter experts in each functional area participate directly in requirements capture, rather than having requirements filtered through a single implementation team intermediary.

Business Requirements Documents

Five BRDs were produced — one per module — defining Tekelec's Oracle configuration requirements in each area. The BRDs documented: AP payment terms, supplier types, matching rules, and approval workflows; AR customer classes, transaction types, revenue recognition rules, and collection procedures; FA asset categories, depreciation books, and capitalization policy; GL chart of accounts design, period structure, and consolidation approach; OIE expense types, approval hierarchy, and reimbursement rules. These documents served as the configuration specification and client sign-off artifacts before configuration began.

CRP2 Testing

The CRP Testing Points document and BPI3 Test Script Excel workbook supported the CRP2 phase — a structured walk-through of Oracle's configured functionality against real business scenarios. CRP2 in Oracle AIM methodology follows CRP1 (initial fit-gap), with the Oracle environment more fully configured so that test scenarios reveal configuration gaps, not just conceptual gaps. The BPI3 test script designation suggests this was the third business process iteration of testing — indicating a rigorous multi-cycle test approach.

Post-Acquisition Santera Financials Setup

The Santera Financials Setup document addressed the most complex aspect of the engagement: integrating Santera's financial operations into Tekelec's Oracle environment after the acquisition closed. This required decisions about whether Santera operated as a separate Oracle operating unit (maintaining separate AP, AR, and GL visibility) or was merged into Tekelec's existing operating unit structure. The Financial Setup Document Issues artifact reflects the configuration challenges that arose from this decision — issues that emerge when an organization's Oracle structure must accommodate a new entity with different historical data, different vendor relationships, and different accounting practices.

Custom PL/SQL Library

The Custom PLL.doc documented custom PL/SQL library development — utility functions supporting the Oracle implementation, likely including account defaulting functions, expense validation routines for OIE, and custom formatting for AR transaction processing.

Key Deliverables

Deliverable	Type	Purpose
Module Questionnaires (AP, AR, FA, GL, OIE)	Requirements	Structured discovery questionnaires capturing Tekelec's business processes and configuration requirements per module
Business Requirements Documents (5 modules)	Oracle AIM BRDs	Formal configuration requirements per module — the specification and sign-off artifact before Oracle configuration
CRP2 Test Scripts	Test Documentation	BPI3 test scripts for CRP2 phase covering business scenarios across all five modules
Santera Financials Setup	Configuration Document	Post-acquisition Oracle financials setup for Santera entity integration into Tekelec's Oracle environment
Financial Setup Issues Log	Issue Tracking	Active issue log for Santera financials integration challenges with resolution tracking
Custom PLL Documentation	Technical Reference	Documentation of custom PL/SQL library functions developed for Oracle configuration support

Consultant Insights

On Post-Acquisition Oracle Integration Timing: The Santera integration occurring mid-implementation illustrates the timing risk of acquisitions during Oracle projects. An acquisition that closes during an active Oracle implementation forces a choice: pause the implementation to redesign for the new entity, proceed with the original design and retrofit the acquired entity later, or accelerate both in parallel. None of these options is clean. The best mitigation is early and honest scoping: if an acquisition is anticipated during the implementation window, design the Oracle structure with the additional entity in mind from the beginning — even if the entity doesn't yet exist in Oracle.

On Multi-Revenue-Stream AR Configuration: Telecom software companies with mixed revenue — license, hardware, services — require AR transaction types that match each revenue stream's recognition logic. A single AR transaction type trying to handle all three creates an accounting mess: licenses recognized at execution, hardware at delivery, and services over time cannot share the same auto-accounting rules or memo line configurations. Design AR transaction types to match the company's revenue recognition policy, not its customer invoice format.

On OIE in Technology Companies: Oracle Internet Expenses in technology companies typically has higher per-transaction value and more complex approval requirements than in commercial environments: engineers on customer site for weeks at a time, international travel expenses requiring multi-currency reimbursement, and customer-billable expenses that must be tracked separately from overhead expenses. OIE expense type configuration, approval hierarchy, and billable flag setup require input from both Finance and the project accounting team to get the coding right — not just the expense management team.