Telscape Communications — Oracle EBS vs. Microsoft Dynamics Evaluation & Financial Architecture Design

Client	Telscape Communications
Industry	Technology — Telecommunications Services
Oracle Version	Oracle Financials (Pre-Selection Assessment)
Modules	PO AP GL
Engagement Period	1996 – 2001
Project Type	ERP System Evaluation — Oracle vs. Microsoft Dynamics (Great Plains)
Complexity	Medium · System Selection · Financial Architecture · Baseline Process Documentation · Cost-Benefit Analysis

Executive Summary

Telscape Communications — a telecommunications services provider — engaged William Delaney Consulting across two distinct phases spanning 1996 to 2001. The earlier phase (1996) produced high-level financial system architecture diagrams covering Fixed Assets, General Ledger, financial flow, distribution accounting, and legal entity structure — foundational architecture work for a company building its financial systems infrastructure. The later phase (2001) became a formal ERP system selection engagement: a structured evaluation comparing Oracle EBS against Microsoft Dynamics (Great Plains) across Telscape's financial business processes, culminating in a platform recommendation with supporting cost-benefit analysis.

The 2001 evaluation artifacts — Oracle vs. Great Plains specification document, licensing cost workbooks for both platforms, Oracle implementation budget estimate, and an accounting system evaluation presentation — represent a complete system selection engagement. This is one of the rare cases in the portfolio where the engagement outcome was a platform recommendation rather than an Oracle implementation — an outcome that reflects the realities of ERP selection: not every company of every size at every growth stage is the right fit for Oracle EBS.

Engagement Context

The Oracle vs. Great Plains (Microsoft Dynamics GP) decision is a well-defined system selection problem with a generally clear answer that depends on company scale, complexity, and growth trajectory. Oracle EBS is the appropriate platform for large, multi-entity, multi-currency organizations with complex procurement, manufacturing, or project accounting requirements. Microsoft Dynamics GP is appropriate for mid-market companies with simpler financial operations, smaller transaction volumes, and limited multi-entity requirements. The evaluation challenge is placing a client accurately on this spectrum — not choosing Oracle because it sounds more prestigious, and not choosing Dynamics GP because it appears less expensive upfront.

For a telecom services company in 2001, the decision carried additional complexity: telecom companies have high transaction volumes (billing, commissions, capacity purchases), complex revenue recognition (recurring services billed in advance, usage-based charges), and regulatory reporting requirements that impose financial reporting demands beyond standard commercial accounting. These factors push toward Oracle EBS. Against this, a mid-size telecom services company may not have the IT infrastructure or Oracle expertise to support an Oracle EBS environment — a practical constraint that pushes toward Dynamics GP.

The baseline process documentation — Current Baseline documents covering Budgeting, Commissions, Customer Payment, Employee Expenses, Financial Accounting, Fixed Asset Accounting, General Business, Invoice and Disbursement, Invoice Generation, and Procurement — provided the process foundation for a structured gap analysis: which platform best supported each of Telscape's identified business processes, and where would each platform require workarounds or customization?

Engagement Scope

Phase 1 — Financial Architecture Design (1996)

The 1996 phase produced foundational financial architecture artifacts in Visio: high-level Fixed Asset accounting flow (HIGHFA.VSD), General Ledger structure (HIGHGL.VSD), overall financial flow (FLOW_FIN.VSD), distribution accounting design (flow_dst.vsd), and legal entity structure (LEGALENT.VSD). These diagrams established the conceptual financial architecture for Telscape's accounting system — the legal entity hierarchy, the GL account structure, and the key accounting flows — regardless of which software platform would ultimately implement them. Architecture work done at this level is platform-agnostic and remains valid even as the software platform decision changes.

Phase 2 — ERP System Evaluation (2001)

The 2001 evaluation followed a structured methodology: baseline documentation of current business processes, identification of functional requirements, platform capability assessment against requirements, and cost-benefit comparison across platforms.

The Current Baseline document series captured Telscape's as-is state across ten functional areas — providing the requirements foundation for the platform evaluation. The Comparison.xls workbook structured the feature-by-feature comparison of Oracle vs. Great Plains against these requirements. The platform-specific workbooks (GP License.xls, Great Plains License.xls, Oracle Implementation Budget1.xls) quantified the cost dimension of the decision: Oracle's higher implementation cost vs. Great Plains' lower licensing and implementation cost, weighed against Oracle's superior scalability and functional depth.

The Business Availability Requirements and Technical Architecture Requirements documents captured non-functional requirements — system availability targets, integration requirements, infrastructure specifications — that affected platform selection beyond functional fit. For a telecom company with 24/7 billing operations, system availability and integration capability with billing and operations support systems (OSS/BSS) were significant selection criteria.

The Acctg Sys Eval.ppt presentation delivered the evaluation findings to Telscape's executive leadership — synthesizing the functional fit analysis, cost comparison, and implementation risk assessment into a recommendation with supporting rationale.

Key Deliverables

Deliverable	Type	Purpose
Financial Architecture Diagrams (1996)	Architecture Design	High-level GL, FA, financial flow, distribution, and legal entity architecture diagrams
Current Baseline Process Documents (10 areas)	Process Documentation	As-is documentation of Telscape's financial processes across all major functional areas
Oracle vs. Dynamics Specification	Evaluation Artifact	Structured feature comparison of Oracle EBS against Microsoft Dynamics (Great Plains) by functional area
Platform Licensing Cost Analysis	Cost Analysis	Oracle and Great Plains licensing cost workbooks for total cost of ownership comparison
Oracle Implementation Budget	Cost Analysis	Estimated Oracle EBS implementation cost including consulting, licensing, and infrastructure
Accounting System Evaluation Presentation	Executive Recommendation	Platform recommendation presentation to executive leadership with supporting rationale and risk assessment

Consultant Insights

On Oracle vs. Mid-Market ERP Selection: The most common error in Oracle vs. mid-market ERP selection is anchoring on the current state. Companies evaluate platforms based on their current size and complexity, then select based on that snapshot — but ERP systems serve companies for 10–15 years. The question is not "what do we need today?" but "what will we need in five years, and which platform supports that trajectory at an acceptable cost?" Oracle EBS's higher implementation cost is more defensible if the company is on a growth trajectory that will exhaust Dynamics GP's scalability within three to five years.

On Baseline Documentation as Requirements Foundation: The Current Baseline document series used in this evaluation is an underutilized technique in system selection engagements. By documenting the current-state process before evaluating platforms, the evaluation anchors on actual business requirements rather than platform marketing materials. Each current baseline document implicitly contains a requirements list: if the current process does something, the new system must also do it (or replace it with something better). Evaluators who skip baseline documentation often discover post-selection that the chosen platform doesn't support a critical current process — at implementation time.

On Financial Architecture Before Platform Selection: The 1996 architecture work — defining the legal entity structure, GL design, and financial flows before any platform was selected — reflects a discipline that is rarely practiced today. Financial architecture is conceptually separate from the software that implements it: the right legal entity hierarchy, the right chart of accounts structure, and the right intercompany accounting design are correct regardless of the platform. Organizations that jump to platform selection without first establishing their financial architecture end up letting platform constraints drive financial design decisions — which is backwards.