Operating a Shared Service Center in R12 Using EBS

PDFPrintE-mail

This article discusses the characteristics of a Shared Service Center (SSC), the differences between centralized operations and an SSC, and how R12 facilitates the implementation of a Shared Service Center in E-Business Suite.

Multi-National Corporations (MNCs) with widespread global operations must treat separate (usually location-defined) parts of their businesses differently due to local statutory requirements, taxes, accounting methods, languages, and currencies, yet still must comply with corporate standards. The business must manage issues around security, ownership, reporting, and control for all transactions.

For a MNC operating in 47 different countries spread across 6 continents, daily operations is a tedious exercise that requires that each business unit operates and supports operations independently while sharing data among other parts of the enterprise to leverage sourcing opportunities, inventory, and back-office transactions. Implementing a SSC enables the company to significantly reduce costs by having a central pool of employees to handle day-to-day tasks such as Procurement, Disbursement, Collections, Fixed Assets, Tax Compliance, Training & Development, and Payroll. Instead of carrying out these tasks in each of the 47 different countries and repeating each operation 47 times, a SSC combines similar tasks carried out throughout the enterprise and shares the overhead cost of providing these services internally. Offering these tasks as Shared Services enables the corporation to capitalize on the economies of scale and scope (in the form of reduced headcount, reduced operating costs, greater service levels, greater leveraging of resources, etc.) that come with the elimination of duplicate efforts.

Standardized business practices across the enterprise ensure that all parts of the organization conform to practices that are consistent with corporate objectives. A Shared Service Center offers the following benefits:

  • Establishes global processes and accessibility to data.
  • Hastens incorporation of new business units.
  • Establishes the right balance of centralized and decentralized functions.
  • Standardizes and automates processes with self-service.
  • Focuses on core competencies.
  • Assures that management everywhere is reading from the same page.
  • An important impact of the deployment of shared service centers is that the number of control points in a process and the number of variations of a process are greatly reduced, dramatically mitigating the risk of process error. The consolidation of data and processes in Shared Service Centers also mitigates against the risk of error and of poor decision making.

Implementing a Shared Services Center is different than centralizing operations. A Shared Service Center generally operates as a profit center providing a specified service (i.e. billing or expense reports) for a unit cost. A Shared Service Center might charge the entities it services a fee for every invoice that it processes. The fees to each internal organization are usually subject to the terms of a formal service-level agreement and are based on the volume of invoices or expense reports it processes. Centralizing operations, on the other hand, is usually associated with conglomeration of resources in a central location for the purposes of offering services upward to executive management. Centralized services typically operate as a cost center focused on providing centralized controls and decision making and approvals for the organization as opposed to sharing resources and processing for different entities across worldwide operations.

A Shared Service Center, by its nature, enforces internal controls on inappropriate processing. For example, in traditional local operations, an invoice of one operating unit (perhaps a company in a country) cannot be paid by a payment from a different company in a different country. This would amount to tax fraud. By contrast, in a Shared Service Center environment, processes that allow one company to perform services for others – with appropriate intercompany accounting – require that users access the data of different companies, each complying with different local requirements.

The Oracle E-Business Suite allows you to be both locally and corporately compliant while increasing efficiencies through Shared Service Centers. Consider an environment where the orders are taken in several different operating units (OUs), each representing different registered companies. These OUs segregate the orders and data appropriately. However, all of these orders can be managed from a "shared service" order desk through a single Responsibility in R12 of the E-Business Suite.

Core components of the E-Business Suite architecture that support Shared Services:

  • Operating Units (OUs) provide a powerful security construct in the applications by creating a tight relationship between the functions a user can perform and the data that a user can process. This security model is appropriate in a business environment where local business units are solely responsible for managing all aspects of the finance and administration functions.
  • Responsibilities can be associated with a single OU or with multiple OUs.
  • Multiple Organizations Access Control expands the relationship between functions and data. You can isolate your data by OU for security and local level compliance and also enable certain users and processes to work across them. (new R12 feature)
  • Subledger Accounting enables transactions to be entered in compliance with local and regulatory requirements and reported to meet corporate requirements. Each operating unit of a corporation can enter transactions in a local currency and according to their local chart of accounts, calendar, and accounting method. Release 12 maintains a real-time global view of the company based on the way each OU has set up its Secondary Ledger. (new R12 feature)
  • Subledger Users are assigned responsibilities. A responsibility can be attached to one or more operating units as required, using Multiple Organizations Access Control. In a Shared Service Center, users are given access to OUs that are owned by the legal entities that the Center serves. For example, users at an Ireland Shared Service Center will be employed by an Ireland Legal Entity and have access to OUs that represent the United Kingdom, France, Germany, and the United States. A shared service user with Multiple Organizations Access Control can select invoices stored in different operating units, combine them into one bank instruction, and send them to the bank for issuance.
  • Ledger Sets are used to manage ledgers, including opening and closing of periods and running reports. Ledger sets support adjustments and allocations and specifically support adjusting ledgers. This separation of ledger data and ledger management is designed to support the creation of ledger shared service centers and moving ledgers into sets that are centrally managed. (new R12 feature)
  • Legal Entities may share bank accounts over various operating units. Legal Entities may be governed by different tax jurisdictions.
  • Customer and supplier bank accounts are now in the Trading Community and can be shared. (new R12 feature)

To learn more about Release 12’s Subledger Accounting, see this article.

Add comment


Security code
Refresh

Email Newsletter icon, E-mail Newsletter icon, Email List icon, E-mail List icon Enter your email address to sign up for our Newsletter

Sign up now

captcha
TEChanges - Agility by Design

May Puzzle

David is often referred to as Rainman due to his peculiar ability to effortlessly figure out a certain date's day of the week. He recently displayed this talent when I asked him if there was a conflict with the upcoming Fuzzy Dice Conference and our weekly court-ordered community service. He asked the date of the convention. It was April 20th, 2012.

"Oh, that’s a Friday," he said, effortlessly. "And your sentences have you committed for the next few dozen Wednesdays so you'll be able to go." And of course he was right.

One day a few weeks ago I asked out loud in the office about the date June 5th. And of all people, my brother Tommy piped up and said "Oh, that's a Tuesday."

"That's right," said David.

Well how about Otcober 3rd?

"That's a Wednesday," said Tommy. Then I asked about Christmas Day 2012.

"Oh, that's a Tuesday." David nodded in agreement.

Do we now have two rainmen? Or had Tommy figured something out?

Show solution...

Solution

Here's what was going on. Tommy was using something called anchor dates. And these dates apply to each and every year. April 4th, or 4/4 we’ll call it from now on, June 6th or 6/6, 8/8, 10/10, 12/12, are all the same day of the week, each and every year.

So too are 5/9 and 9/5, May 9th and September 5th. So too are 7/11 and 11/7, and all the above dates are the same day of the week, as is the last day in February, Leap Year or not. And they’re all the same day as January 4th, it would otherwise be January 3rd, but this was a leap year, and that’s changes the anchor day from January 3rd to January 4th.

Tommy also knew that New Year's Day was a Sunday. He was sobered up by then. And he knew it was a Sunday because Christmas was a Sunday in 2011, so New Year's Day is a Sunday, so the Anchor Day for 2012, January 4th, has to be a Wednesday!

So if that's a Wednesday, then 4/4, 6/6, 8/8, 10/10, 12/12, 5/9, 9/5, 7/11, 11/7, and February 29th are all the same day of the week, and they're all Wednesdays. So when I ask for example, about October 3rd, he knew October 10th was a Wednesday, 10/10. So 10/3 must also be a Wednesday. 12/12 is a Wednesday in 2012, so it’s 12/26, which is two weeks later. So 12/25, or Christmas Day, must be a Tuesday.

Success Tips for Oracle Project Management

  • Create a standard for documentation at the beginning of your project, and hold team members accountable for completing documentation requirements as well as keeping them at and above the standards required.
  • Before promulgating user documentation or training, it’s also a good idea to choose a representative from the among the business users base to review materials first.
  • If you are not sure about the resources and budget required, obtain several estimates from people that have experience with the same size and scope of your project.
  • Be explicit, before beginning the project, what internal resources are required for execution. This includes people, infrastructure, hardware, and software.
  • Help the project champion understand the impact your project will have on the organization and how its successful completion will make him or her an internal hero or heroine for supporting it.
  • Break up your project into smaller projects (try for projects that can be completed in 4-6 months, especially early on) to get success and demonstrate momentum.
  • Make sure that your testing includes reports, upstream and downstream interfaces, customizations, enhancements, and workflows.
  • Ensure that comprehensive transition reports and meetings between departing and incoming personnel are completed.
  • Instead of spending time and resources implementing third-party reporting, consider consolidating multiple instances, moving to a global chart of accounts (CoA), and/or standardizing on a consistent calendar.
  • Include governance, risk, and compliance management as part of the project plan.
  • Finally, celebrate the successes. Too many projects focus on defects, failures, or small cost over-runs without looking at the big picture and what was accomplished.

The Analyst Corner

John Van Decker, Research VP of Gartner, states:

"A single chart of accounts allows consistency in financial reporting across the enterprise by standardizing on common metrics and reporting structures, reduces dependencies on a separate financial consolidation system, and significantly reduces the costs incurred with ongoing, complex conversions and translations."