Archive for category Data Systems
That Old House
Posted by Helene Abrams in Data Quality, Data Systems, The Changing Enterprise on March 10th, 2010
Maintenance of an ERP System
When you moved into the new house, everything was clean, uncluttered, and ready for you to personalize and adapt to meet your needs. So it is when you first implement an ERP system. However, many people bring with them boxes of things no longer needed – data and structures from their legacy system that were once required or that the users have simply become accustomed to. Once you move into the house, you begin accumulating stuff that looked like a good idea at the time, but now sits in a corner and collects dust. Even worse, those obsolete items need to be moved and re-boxed, and every time you need something, you might spend hours or days looking for it. Feng shui practitioners believe that clutter is low, stagnant, and confusing energy that drains energy from you. Depending on the area of your home where your clutter is located, it can also negatively influence, or even completely block, the flow of events in specific areas of your life. Once again, there are many parallels to an ERP system. Multiple Charts of Accounts or Org Units clutter the business processes and take effort to create workarounds. Hours and days are spent reconciling spreadsheets looking for data that you know is there, but that is “boxed” so that it is not easily found. ERP clutter is a barrier to the sharing of information, to streamlining business processes, and to complying with statutory and regulatory requirements.
After about 10 years of living in the house, you probably need to make some major modifications to accommodate changes in your lifestyle. Maybe your family has grown and you need to add more space, maybe your children have moved out, or maybe your furnace is not as energy-efficient as you’d like and is costing you a lot of money. Similarly, after a number of years, your ERP system needs to be modified to continue to support your business. You may have acquired some companies, sold part of your business, or want to take advantage of new technologies. The good news is that in the same way that remodeling your house and upgrading your appliances adds value to your house, cleaning up your ERP system adds value to your business in the form of reduced operating costs, reduced hardware, and fewer people for non-value-added activities. In your house, once you clear most of your clutter with feng shui and have a clear system to avoid its accumulation in the future, you will start experiencing high energy levels, more clarity, and a heightened sense of well-being. In your business, once you clear the clutter left from years of ERP accommodations, you will start experiencing greater visibility to the entire enterprise, transparency in your financial transactions, less complexity, and the ability to drive value from new initiatives. Click here to learn how to reduce ERP clutter…
Show Me the Money: Reduce the Costs of Running Oracle EBS Before Upgrading to R12
Posted by Helene Abrams in Data Systems, Return on Investment Analysis, The Changing Enterprise on January 19th, 2010
Reducing costs is the major strategic focus for most companies. An often overlooked cost is the general operation of financial operations. This paper details a methodology for calculating the costs of running each of the financial modules. The costs are compared against both internal and external benchmarks. After calculating the costs, the paper shows how to reduce costs in two ways: first, by eliminating work that is duplicated across different business units or divisions, and second by determining which operations that are currently distributed across the organization can be consolidated into a shared services center. Together these changes, both to the organization and the Oracle EBS system, can generate significant cost savings. Finally, the paper details how streamlining operations prepares for a better R12 implementation.
Calculating the Cost of Operations
The cost of operations is calculated by breaking down how much time is spent on an activity during the year by each person doing that activity, how many items were processed, and then calculating the cost using a baseline cost of FTE. As an example, for AP, each department would calculate the number of hours in a year spent on each of the following tasks or activities:
- Maintain policies and procedures
- Enter, code, match, and correct payment documents
- Prepare and issue automated checks
- Certify checks
- Process manual checks and special payment requests
- Respond to vendor and internal inquiries
- Perform Reconciliations
- Perform corporate and government reporting
- Create Corporate Chargebacks
- Other A/P Activities
The hours would be translated to a number of Full-Time Equivalents (FTEs) by dividing the hours by 2080 (the number of hours for a person working full time per year). A baseline average burdened (including benefits and expenses) salary is then multiplied by the number of FTEs to calculate the annual cost of that activity. To obtain the cost of an operation, multiply the number of items processed (i.e. number of checks) by the cost of the activity. For each of the finance areas, costs are calculated to measure the performance of each activity. For example, General Accounting would calculate the number of journal entries processed per FTE per year and compare those to an internal benchmark. Travel and Entertainment would calculate the number of expense reports processed per FTE per year. Fixed Assets would calculate the number of unique fixed assets or line items per FTE per year. Accounts Receivable would calculate the number of bills issued per FTE per year. In other words, each area would develop its own internal key performance metric and a way to calculate that metric against FTEs contributing to the process. In aggregate these calculations may uncover significant additional cost savings that could be realized quickly and relatively painlessly by migrating from a distributed services model to a shared services model.
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.
How Much Can You Save Now?
Posted by Chris Busbee in Data Systems, Return on Investment Analysis, TECHANGES, Trends & Technology on December 20th, 2008
If you are able to determine how much you spend with each of your suppliers, you may be able to renegotiate your discounts. Many suppliers will provide volume discounts if you commit to certain spending levels. By looking at your total spend across all operating units, you may be able to reach the thresholds required for greater discounts.
By increasing the number of days a company holds on to cash, additional interest will accrue, whether using a daily sweep checking account or another instrument for cash management. The following calculator analyzes the benefits of extending the payment terms with suppliers and calculating the value of having the cash on hand for an additional “float” period. >>See How Much You Can Save
Leveraging Purchasing in a Multi-Org Environment
Posted by Helene Abrams in Data Systems, News & Articles, Return on Investment Analysis, TECHANGES, Trends & Technology on December 20th, 2008
When companies originally set up multi-org in Oracle’s E-Business Suite, security and control were the primary drivers for separating data into different operating units. Plants wanted to run their own operations, negotiate their own contracts with suppliers, and set up their own invoicing, inventory and receiving practices. Moreover, there was a competitive environment among different divisions, product line operations, and general managers. One part of the company did not want another part to see the transaction detail. Little attention was paid to maximizing the purchasing power of the entire enterprise to negotiate better terms and discounts with common suppliers.
As a result, companies often set up hundreds of operating units, each with its own freight carriers, matching tolerances, approval hierarchies, supplier terms, and contracts. It was difficult to determine how much business was conducted with a particular supplier, difficult to determine the enterprise cost of managing and maintaining different supplier relationships, and the burdened costs of different inventories. >>MORE
The Bridge to Nowhere
Posted by Helene Abrams in Data Quality, Data Systems, TECHANGES on September 18th, 2008
The Bridge to Nowhere
Integration of diverse applications means building bridges that connect one application to another in order to pass data between them. There are several ways of integrating data, from writing code to insert data that is generated in one system into another system to using a hub-type technology with several adaptors that also includes a messaging system and a broker for routing and transformation of the data. In the above diagram, the blue lines represent data movement and messages that are passed through adaptors to other systems. The blue circles represent adaptors that are connected to a common interface table in a system. The red lines represent interfaces directly between any two systems. These interfaces are generally SQL code used to extract the data from one system and load it into another system.
As is obvious, both methods of integration can be very complex and difficult to maintain. The data may be in different formats in each of the systems, the interface code or the adaptors may need to change as each system is upgraded, the loads have to be done in a particular sequence to obtain the correct results, and the data itself may be inconsistent. Decisions have to be made regarding which application contains the correct data, how to deal with conflicts, and the frequencies of loads.
There are some basic principles that will help streamline the process of integrating data among disparate systems.
- Try to keep the same type of data within a single application, or at best, identify a single place where data is created and updated. This is the underlying concept of master data management efforts. All applications that reference that data should be “read only”.
- Set up data standards. Create naming standards and formatting standards for all systems across the enterprise. For example, all descriptions should be the same field length, telephone numbers should all be in the same format (for example, countrycode.areacode.number.extension), punctuation should be eliminated, and abbreviations should be standardized.
- Create a Data Map. This can be done in a spreadsheet, in a database, or by using database design software. The purpose of the Data Map is to show what each data element is mapped to in other systems and the “load instructions” for that data element. The data map is cross referenced for two-way interfaces. If using a spreadsheet, you would have a worksheet for each table with the attributes or columns of the table on the left of the spreadsheet (column A) with each interfaced system/table going across the top (Row 1). The first Application should be the current system. In the first intersection cell (B2), put the format of the data of the current system (i.e. varchar 10). After the current system is documented, allow 3 columns for each application to be integrated with the current system. In the second intersection cell (C2), put the table/column name that is the destination for the first data element in the first application to be integrated. In the third column (D2), put the format required for the first system to be integrated (i.e. varchar 25). In the fourth column (E2), you will document the transformation code required to get the data from the format in column B into the format required for Application B, Column D (i.e. rpad 15). Continue on until you have all the interfaces mapped and the transformations documented for each application to be integrated. Keep the data map current as systems are updated.
- Limit the interface to a “need to know” interface. In other words, if an application does not need to use the information as a trigger for a procedure or an action within that system, do not bring it into the new system.
- Define the processes that create, read, or update each type of data and put security and access controls in place so that the governance and ownership of the data is unambiguous.
Finally, evaluate all data that is integrated for completeness, consistency, and correctness between each source and each target. Validate that the correct number of records are transferred, the resulting data, and the reconciliation between each source and target so that the bridges you are building are stable enough to withstand change.
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
Before You Upgrade to Release 12 – Look at the Data
Posted by Helene Abrams in Data Systems, TECHANGES on September 20th, 2007
Release 12 brings with it many significant changes and enhanced functionality that will eliminate many customizations, allow companies to operate globally, and streamline major business processes. The decision to upgrade Oracle Applications® brings with it numerous business and technical issues along with a wealth of opportunities. The process of upgrading allows you to thoroughly examine your current application structure and re-architect it to support current and future business requirements, and to clean it up so that you can maximize your Oracle Apps investment and upgrade with confidence. >>MORE