Archive for category Upgrade vs. Reimplementation
Strategy Analysis: Considerations for Moving from Oracle 11i to R12
Posted by skip straus in Data Quality, News & Articles, TECHANGES, The Changing Enterprise, Upgrade vs. Reimplementation on October 12th, 2009
The IT leaders who run Oracle E-Business Suite know the objective. R12. It’s the release that will carry them to 2015 or beyond. They will run one instance, it will be global in scope, and all the business users on the planet (well, the ones who logon to their instance) will follow the same business processes. R12 will be the single source of financial truth. Some 11i customers have already made the transition, others are in process, many are planning, and a few are too busy with other priorities and will wait.
Making the transition to a major release of an enterprise system with E-Business Suite’s scope is a huge endeavor, with many people in different roles, and there is a lot of freedom of action on the playing field. On one level, it’s a game – a complicated one – that takes several years to play. IT teams don’t really compete against each other. Most will actually get to R12, but the ones with the lowest costs, best looking R12 environments, and fastest times will be the winners.
There are four distinct strategies for achieving an objective: Direct, Divisional, Delay, and Indirect. The strategist selects the one that best fits the situation profile, the landscape, and available resources. How does the R12 strategist select the transition strategy to get to R12? What will they depend on to win? Let’s look at some examples. Read more…
Not Your Mother’s Software
Posted by Helene Abrams in Blogs, Data Quality, Data Systems, The Changing Enterprise, Upgrade vs. Reimplementation on September 16th, 2009
Some of you might be too young to remember - it used to be that the reconciliation and monthly closings were done on a hand-written ledger, and every adjustment was done in pencil so it could be changed. If an account needed to be changed, it was changed only on a going-forward basis with possibly a restatement and a single entry to reflect the change. Then there came the spreadsheet – and there was a lot of resistance from the accountants to adopting spreadsheets as the standard.
Still, with spreadsheets, there was no clear drill down process. Further, as organizations grew and required maintaining thousands of spreadsheets rather than a few, the accuracy and integrity of the data became questionable, and for good reason. Now, the ERP system has taken away some of the burden of manual reconciliation and spreadsheets, but even large ERP systems don’t reflect the fact that companies change. There are countless places that are touched when making changes in a relational database, and it is difficult to perform all of the changes required to maintain the relational integrity of the underlying structures that were initially set up. But it is also difficult and time-consuming to re-implement or reconcile, or to migrate to a new chart of accounts, a new organization unit, or a new ledger and go through a complete test cycle every time a company reorganizes, acquires another company, or sells part of the business (or, if they have just outgrown their current system). That difficulty, along with the deterioration of data integrity that results from companies having to resort to thousands of spreadsheets to reconcile the changes, doesn’t make a manual process any more accurate or auditable, and it severely limits a company’s agility.
eprentise and FlexField software products deal with the technical aspects of the change so that EBS can re-align to the current business environment. The ability to change is now part of the normal lifecycle and ongoing maintenance of an enterprise application.
Organization Setup in R12
Posted by Helene Abrams in Data Systems, TECHANGES, Tips, Upgrade vs. Reimplementation on June 15th, 2009
There are many changes in how organization units are defined and used in R12. An Organization can represent a Ledger, a Business Group, a Legal Entity, an HR Organization, an Operating Unit, and an Inventory Organization. You may define the relationships among organizations.
A Business Group is the highest level in the organization hierarchy structure, usually representing the consolidated enterprise, an operating company, or a major division. The business group secures the employee information in all applications except for HR. For example, when you request a list of employees for approvals or expense reports, you will see all employees assigned to a business group. This is a little bit confusing, because within the HR applications, you can assign a security profile at the HR organization level providing a much more granular view of confidential information such as salaries or social security numbers.
The concept of a Legal Entity is much more developed in R12 than it was in 11i. A legal entity is the organization unit level at which you report taxes and maintain the corporate banking relationships. The LEGAL_ENTITY_ID column is added to the transaction tables in 12, allowing the ability to track transactions at a Legal Entity level. In R12, you assign a Legal Entity to a Ledger instead of to a Set of Books. It is recommended that you assign one (or more) balancing segment values in your chart of accounts to a legal entity.
An HR Organization typically represents the functional management or reporting groups within a business group. You may also define HR organizations for tax and government reporting or for third-party payments.
The Operating Unit is tied to a ledger (instead of a Set of Books) and, as it was in R11, continues to partition transactions. A ledger can have many operating units assigned to it. Responsibilities determine the security for operating units. A responsibility can access only the transactions for the operating unit(s) to which it has been assigned. An operating unit also controls access to reports and concurrent requests. If you set up a profile option MO: Operating Unit, then the responsibility can only access a single operating unit. If you want a responsibility to access multiple operating units, then you must define a security profile with multiple operating units assigned and assign it to the MO: Security Profile option. The MO: Default Operating Unit option also allows you to specify the default operating unit for the transactions entered by that responsibility. Operating units are not directly associated with legal entities, though they are assigned to a ledger and to a default legal context (Legal Entity). A user can assign any operating unit to a transaction or copy transactions to a different operating unit if access to the operating unit is authorized by the security profile for the responsibility.
With the new Multiple Organization Access Control (MOAC) feature in R12, transactions may be posted to different operating units and legal entities from a single responsibility. In order to do this, you set up a security control (MO: Security Profile) to assign multiple operating units and legal entities to a single responsibility.
An Inventory Organization is the organization that manufactures or distributes products or for which you track inventory transactions and balances. An inventory organization is associated with a parent operating unit, but can serve other operating units under a different ledger. As such, each inventory organization is attached to a legal entity and a ledger. You can specify the inventory organizations that are available for each responsibility. You can enter purchase orders and assign for receipt any inventory organization. Your purchase order operating unit and receiving inventory organization can be in different ledgers to receive against a purchase order. The following applications secure information by inventory organization: Oracle Inventory, Bills of Material, Engineering, Work in Process, Master Scheduling/MRP, Capacity, and Purchasing receiving functions. To run any of these applications, you must choose an organization that has been classified as an inventory organization.
Other organization structures may be set up to reflect hierarchies in different subledgers. For example, you can define organizations for project expenditures to manage project control requirements in Oracle Projects. Oracle Assets uses asset organizations to perform activities for a specific Oracle Assets corporate book.
Some information is set up at the organization unit level, while other data is set up once for the entire E-Business Suite. All flexfield definitions, customer and supplier headers, Oracle Assets, General Ledger, Oracle Inventory, and Oracle Manufacturing products are set up only once in the instance. Oracle Cash Management, Accounts Payable, Purchasing, Accounts Receivable, Order Management, Project Accounting, and Sales & Services are set up at the operating unit level. Site information for suppliers and customers is also at the operating unit level.
A table near the bottom of this page shows the data that must be set up for each operating unit.
Putting Numbers in Boxes – Spring Cleaning for Charts of Accounts II
Posted by Helene Abrams in Chart of Accounts Structure, Designing a Chart of Accounts, TECHANGES, The Changing Enterprise, Upgrade vs. Reimplementation on February 20th, 2009
Last month, this newsletter had an article about putting numbers in boxes that presented the current chart of accounts and design considerations for a local/county government. This month, we are continuing that article with design considerations for a CoA for a high tech manufacturing company. We will refer to this company as HTM in this article. HTM has many of the same issues that the county government had, with segments representing multiple types of data and with different kinds of information within one segment. This chart is a little more complex because HTM is a global company with different statutory and regulatory requirements. Trying to get global consensus on a new chart around the world is also very difficult politically because everyone feels ownership of their current values and they want to continue doing things in the way that they are used to doing them. The current accounting flexfield for HTM has nine segments…>>MORE
An Overview of R12 Ledgers
Posted by Helene Abrams in Basic Accounting, TECHANGES, Upgrade vs. Reimplementation on January 20th, 2009
R12’s accommodation of multiple ledgers enables smart decision-making by continuously and quickly providing key financial information crucial to important business decisions. The structure of accounting using multiple ledgers also allows for more consistent processing and GL management as well as secure but widely accessible data. For example, a single transaction in a primary ledger can create multiple accounting representations in multiple currencies in the same ledger set (a ledger set is analogous to a set of books in R11). For a slightly technical look at subledger accounting, see this article.
R12 provides the ability to define accounting rules that derive other transactions. The user enters a transaction one time, then uses the Create Accounting function to populate other ledgers in a ledger set. A ledger may have a different currency, calendar, chart of accounts, or accounting method (i.e. US GAAP, IAS ). The ability to automatically create a new transaction in a different ledger that is linked to an original transaction reduces data entry time and errors, and avoids reconciliation issues because the subsidiary ledger transactions are always in sync with the primary transaction. Straight-through processing allows real-time, single-step posting to all relevant ledgers with a clean audit trail delineating the derivation of primary, secondary, and reporting ledgers. The transactions are transparent with full drill-down. A draft-mode accounting feature allows review and modification of the generated transactions before posting.
The following functions can be performed across ledgers:
- Open and close periods
- Create journals
- Translate and revalue balances
- View information
- Submit standard reports
- Submit financial statements
- Perform allocations
Ledgers allow a consistent approach, standard policies, rules, and processes for global accounting. The common functions across ledgers reduce the workload and produce processing efficiencies.
Putting Numbers In Boxes – Part I
Posted by Helene Abrams in Basic Accounting, Chart of Accounts Structure, Designing a Chart of Accounts, TECHANGES, Upgrade vs. Reimplementation on January 17th, 2009
Once on a consulting engagement, an accountant told me that he described his job to his five year old daughter as, “I put numbers in boxes.” That was a great explanation, and it helped define a pretty abstract concept. There are two basic premises to putting numbers in boxes. The first is that when you put a number in a box, there is some logic behind what box that number goes into, and second, that someone else can find the numbers in the boxes. The following actual case study provides insight into designing an accounting flexfield so that the “boxes” can help organize the important segments of the business. >>MORE
A Dollar Today Is Worth More Than a Dollar Tomorrow
Posted by Helene Abrams in Return on Investment Analysis, TECHANGES, Upgrade vs. Reimplementation on December 20th, 2008
Making an investment in your E-Business Suite today for a big pay-back tomorrow
Your friend must choose between two offers:
- You offer your friend $1,000 to be paid a year from now.
- You offer your friend a smaller amount today – maybe $900.
Your friend will choose the second offer: A dollar today is worth more than a dollar tomorrow. The old adage rings true in IT organizations. It is difficult to justify a project to streamline your EBS and make it align with business changes when money is tight. An IT department is willing to spend more money over time maintaining current applications rather than making an investment today. It is much easier to continue to spend money and effort reconciling systems with thousands of spreadsheets and custom reports because the money goes out in a slower stream and is less “visible”, doesn’t need approval from stakeholders, and the users have lived with the pain for so long that postponing a solution for a year or two later doesn’t really matter. By investing a chunk up front to change their applications, companies can reduce long-term maintenance costs caused by having different EBS instances, thousands of operating units, and different charts of accounts, but companies choose not to spend the money now and to spend more over the course of a number of years. One large cost today seems bigger than many smaller costs over time, but in reality, making an investment in streamlining systems ends up saving the business money in the long haul.
The cycle begins when implementing Oracle E-Business Suites. To contain costs, and because a company didn’t understand how to utilize all the features of EBS, the original configuration was not scaled to accommodate growth. Companies had already made the investment in Oracle’s E-Business Suite, only to find that with time, the business has changed and the implemented system hasn’t changed with it. Instead, it is much more difficult to recognize a return on their ERP investment because multiple instances or operating units have been configured differently due to requirements that are different for parts of the business. ERP doesn’t represent the “Enterprise” anymore, and the Total Cost of Ownership (TCO) is going up – money is spent on “running” the business, maintaining systems, and developing workarounds to meet changing regulatory and reporting requirements, rather than on innovation and on utilizing the system to get more revenue to the bottom line. It is difficult to perceive the value in spending money on a project now rather than maintaining myriad configurations over a longer period of time.
Political attributes of management can also get in the way – consider when lines between budgets become blurred and spending buckets spill over into others. It is common for companies to dip into other budgets and misuse funds not originally appropriated for maintaining current applications to do just that. One company was spending 40 percent (about $2.5 million) of its application development budget to maintain interfaces between disparate systems, while it could have more aptly used the funds for their original purpose: removing – rather than promoting – silos and disparity. In an E-Business Suite environment, such improvements include consolidating operating units, inventory organizations, or entire instances, or redesigning the current chart of accounts (moving to a single enterprise version) to minimize cross-validation rules, utilize logical ranges, and reduce data entry and spreadsheets.
Let’s return to the original offers and tweak them a bit:
- You offer your friend $1,000 to be paid a year from now, if he is willing to invest $100 today
- You offer your friend $1, 000 to be paid ten years from now if he is willing to pay $80 a year for the next ten years.
In this case, it is much easier to justify spending the money upfront and to go with the first option. A dollar today is worth much more than a dollar tomorrow. Unfortunately, the second scenario is much closer to the situation in IT than the original offers, but IT management fails to see it. Projects to change existing applications invariably get pushed to the back burner. The ongoing costs of maintaining current systems are so much higher than a comparative immediate investment to change systems that it is difficult to understand why so much capital is poured into maintenance. It is wiser to develop an effective plan to change current applications and align them with future business requirements, as well as to use the money and effort saved in maintenance to respond to new opportunities and become more competitive in the long term.
Under the Covers with Subledger Accounting
Posted by Chris Busbee in Basic Accounting, TECHANGES, Upgrade vs. Reimplementation on August 17th, 2008
The major change in R12 is that there are no Sets of Books. Instead, there are subledgers that handle the transaction processing from other modules (AP, AR, FA, etc.). The Set of Books is replaced by the term Ledger. For a slightly technical look at R12’s subledger accounts, read on.
Operating a Shared Service Center in R12 with E-Business Suite
Posted by Helene Abrams in Data Quality, Data Systems, Return on Investment Analysis, TECHANGES, Trends & Technology, Upgrade vs. Reimplementation on July 17th, 2008
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. >>MORE
Agility by Design: Finished But Not Done
Posted by Helene Abrams in TECHANGES, The Changing Enterprise, Trends & Technology, Upgrade vs. Reimplementation on June 20th, 2008
Enterprise applications must continually change in order to support the ongoing business changes of the enterprise. Enabling and facilitating those changes so that they can occur with a minimum of cost and business disruption is the essence of designing for agility. The backbone of potential design agility is most often the enterprise resource planning (ERP) application, whether it is the Oracle Business Suite, SAP, or another similar system. In larger firms, of course, the ERP systems do not run in isolation – the ERP systems are to differing degrees supplemented, complemented, and duplicated by other applications. The average Fortune 1000 company has approximately 300 different “enterprise” systems. Nevertheless, since the ERP systems contain the most central data and business processes of the company, their implementation is a focal point for design agility. >>MORE
