Archive for category News & Articles
Why Workarounds Won’t
Posted by Natalia Warren in Data Quality, News & Articles, TECHANGES, The Changing Enterprise, Trends & Technology on November 10th, 2009
Every quarter, every year, and every month, financial organizations work hard to close their books and prepare financial statements in accordance with countless rules and regulations. And when their ERP systems, designed at great expense and some point in the distant past, can’t keep up with their ever changing needs, they resort to creative workarounds, relying on spreadsheets, diagrams, or other documents jut to get through another reporting period.
As time passes, documenting the period-end process becomes more complex, and maintaining the process documents takes more and more time. But the collective memory of the finance team hasn’t forgotten what it was like to get through that first ERP implementation project – not to mention its enormous expense – and any hopes of improving the situation are abandoned as soon as someone says, “What about the ROI?”
Finance teams would have a better chance of responding to the ROI question if they banded together with their colleagues in purchasing, HR, product management, manufacturing, sales, marketing, and IT as they struggle with the same legacy ERP systems. Ask around and you’ll find that all of them have created their own sets of creative workarounds just to get through another day.
It’s happening everywhere…. Read more…
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.
Using Lean to Win with Speed in the Global Marketplace
Posted by Mike Liddell in Blogs, TECHANGES, The Changing Enterprise, Trends & Technology on July 10th, 2009
Enterprise Resource Planning (ERP) systems such as Oracle’s E-Business Suite have advantages over legacy systems in that they allow businesses to be more flexible and agile. This article focuses on the concept of Lean Manufacturing, but the value of modern ERP systems is a far-reaching and evident in many industries.
Manufacturers in North America and Europe are struggling to meet the challenges of a stressed economy. The good news is that the coming recovery is expected to see early signs of a sharp increase in demand for steel because the street thinks that the steel industry will be among those to lead us out of the recession.
Many manufacturers realize that they must make changes if they are to survive and flourish in a world that promises to be very different from the past. A quick look at some of the factors that are already impacting our world gives us a small taste of what we can expect as we move into the 21st century.
• Customers are placing smaller orders.
• Customers are looking for faster turn around times.
• Customers are demanding more custom products
• Customers are constantly changing as they try to keep up with their customers’ demand.
In addition to these external factors, manufacturers are being pressured to be more profitable by reducing waste, improving efficiencies and becoming more responsive. The new paradigm is clear; manufacturers who want to be successful must be able to reduce inventories while learning to react faster and smarter to change. For those paying close attention this is not breaking news, but it appears that many companies do not yet have a clear understanding of the underlying problems and what they need to do.
Doing the same old things but faster is unlikely to work and is not the answer. This has been proven through the success achieved by companies such as Nucor. They have become one of the largest steel producers in the United States by putting in place strategies that have made them fast and nimble.
The underlying cause of the problem is that too many manufacturers are running their businesses with Enterprise Resource Planning (ERP) legacy systems that still have their manufacturing roots in early 1980’s MRP (Material Resource Planning) concepts and technology. These systems were primarily designed to address the needs of make-to-stock manufacturers who could rely on excess inventories at every level of their process. Many companies are starting to understand the limitations of this approach. This article is for those who are looking to be leaner and more flexible.
The limitations of a traditional MRP based planning system can be more easily understood if applied to a real life situation such as planning a wedding at say 2:00 pm on June 24. This is obviously unrealistic but it does highlight the consequences that stem from a system that can’t even create a starting plan that is accurate and precise.
Everyone involved is initially delighted when told that they can book their wedding on June 24 at 2:00 pm. What the wedding planner doesn’t initially know is whether or not other weddings are booked for that same day and time. This is a potential problem that could quickly evolve into pandemonium.
It would be nice if a planning tool had the ability to recognize a conflict and a need to re-schedule. MRP planning would not be able to do that because it doesn’t know there is a conflict and it has no logic to help it determine which weddings have priority. Even if it could prioritize the weddings, it couldn’t calculate precise new dates and times for each of the weddings. And if it could calculate a new date and time for each wedding, it would have no way of making sure that the priest was available at that time, and even if the priest was available, it would have no way of notifying the photographer and the chef and the restaurant, etc.
The underlying limitation behind all of these problems is that MRP-based planning systems can’t finitely plan even one constraint, and they certainly can’t synchronize multiple constraints. A few years ago a number of smart people who were frustrated with the limitations of such legacy systems started implementing a concept called Lean manufacturing. Lean was designed to remove complexity and waste and was made popular by the success of companies like Toyota.
At the planning and execution level, Lean is built on three key concepts of waste elimination – muda, muri, and mura. Without getting into too much detail, muda addresses the need to remove non-value added work such as overproduction (production ahead of demand) and excess inventories (all components, work-in-progress, and finished product not being processed).
Muri is defined mainly as the breaking down of tasks into their smallest constituencies, and mura refers to the need to make work flow from end to end by removing unevenness in the process rather than buffering it.
Other companies were starting to use a management strategy called Six Sigma that had been developed by Motorola to identify and remove the causes of defects and errors in manufacturing and business processes. Today these two concepts are often combined into one concept, which is sometimes called Lean 6Sigma or Lean Six Sigma.
Although most companies who decided to adopt Lean 6Sigma were able to achieve some level of success, manufacturers who had highly predictable demand patterns and a limited number of products were able to achieve the best results.
Other manufacturers who were still looking for ways to manage the daily bombardment of change saw only limited success. One of the reasons for this was that early Lean 6Sigma systems were manually intensive so they were unable to replace all the functions that had previously been performed by their Legacy planning systems.
So while Lean 6Sigma initiatives were working to reduce inventory levels their old planning systems were telling them to increase inventory levels. Because of the obvious conflict, mistakes were made resulting in inventory shortages, which led to late shipments and mass confusion. Faced with this situation, manufacturers realized that they either had to abandon their Lean initiatives or find planning systems that would not only dovetail with their need to reduce waste but would automate it where it made sense.
Without planning software that can prioritize and plan events at the detail level it is not possible to synchronize material and capacity constraints; without synchronizing multiple constraints, there is no basis for planning reduced inventory levels. Similarly, if something changes and specific materials are not available, this information must be synchronized back to the plan.
When the plan changes the new planning system must be able to instantly re-calculate the impact of each change on downstream activities, which, in turn, kicks off a new round of synchronizing and re-synchronizing. Right about now you should be starting to understand the problem because none of these things can be done with traditional legacy systems that rely on MRP planning concepts.
We believe that every second spent making the wrong product takes away capacity that could be used for products for which the customer is waiting.
Many industries, such as the steel industry, find it difficult to make only what their customers order because the efficient size of a production run is often much larger than the size of individual customer orders. Traditionally this means that they end up making additional stock that sits around forever.
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.
Growing Complexity Limits Business Value
Posted by Helene Abrams in Data Quality, News & Articles, TECHANGES, Trends & Technology on April 19th, 2009
The value of an ERP system lies in the promises of better information, consistent systems, and reduced operational costs. With an ERP system, the ability to share data across applications and among different business units translated into more clearly defined business processes. The promise and the value depended on consultants who defined the current state of the business and who had a crystal ball made up of their vast experience to anticipate the future state. Companies counted on their ERP systems to accommodate growth and business changes.
Alas, those crystal balls seem to be a bit cloudy, and not even the best consultants could predict the substantial changes that a company undergoes over the life span of an ERP system. As companies approach 5, 10, and even 20 years running the same systems (albeit with numerous upgrades and additional functionality), they are deriving less value from the system that was originally implemented. The number of spreadsheets has multiplied, many are considering a re-implementation, and there are hundreds, if not thousands of interfaces to systems that perform similar functions, consolidate the data, or translate it so that it is useful to the ever-changing business requirements. The promise of reduced operating costs and consistent systems has resulted in a very high cost of ownership and a loss of business value.
The character of ERP systems also changed from supporting a business’ requirements to supporting regulatory and control compliance. Of course, as those requirements changed, there was a need to invest more capital and add more resources to support the ERP systems.
Further exacerbating the problem of a changing business is the growing complexity of the ERP systems. As the following chart illustrates, complexity of Oracle E-Business Suite has escalated with each new version release, resulting in a system that is extremely difficult to maintain. For example, Oracle E-Business Suite R12.0.6 contains over 2.6 million columns (about a 25% increase over the number of columns in R11.5.10.2), each of which could be related to any other, or could be part of a check constraint, or part of a unique or primary key. There are about 36% more constraints in R12.06 than in R11.5.10.2. Even relatively “simple” changes such as finding the impact of a chart of accounts change now affects several hundred more columns in R12.06. Thus, the complexity of changing a chart of accounts went up by more than a third between releases.
Obviously, the larger the ERP footprint, and the more complex those systems are, the greater the capital requirements for maintaining and changing them. The economics and the corresponding value of the ERP system has changed. To compensate for the higher costs, ERP systems must be able to be extensible and adaptable to changing requirements over a longer life span. ERPs must provide data consistency and process integrity in addition to system consistency across the enterprise, As Gartner states, ERP systems must support the “consistent and seamless capture, persistence, transformation and delivery of information throughout the enterprise. To create this infrastructure, enterprises must align their metadata, standards, information formats and technologies for persisting, accessing and delivering data. The demand for tools and approaches that manage data more effectively will grow.”
Transformation software that enables ERP systems to change rapidly can change the value of the ERP spend. Along with the need to manage the complexity of the business and the complexity of the ERP systems, the need to cut costs and realign IT strategies is driving successful companies to invest in changing their existing ERP resources.
When Projects Go Sour
Posted by Helene Abrams in Data Quality, News & Articles, TECHANGES, The Changing Enterprise on March 19th, 2009
It’s happened to all of us who have consulted. We start a project with appropriate planning, and then something happens and it seems that nothing is working anymore. Budgets and timelines have gone out the window, the client is upset, and we are in recovery mode. Without pointing fingers, here are some of the reasons that projects go astray.
- The scope is not well-defined. Especially with what are perceived as smaller projects, it is easy just to say, “Create these reports,” or, “Create an interface from this system into that one. “The specific requirements are not written out or reviewed with the user. The user thinks he or she is getting something that looks like A, and the consultant is sure that the requirement is for B. The consultant thinks the requirement is simple, and the user and the consultant don’t communicate very well.
- The scope expands and the change control process has not been considered carefully.
- We didn’t create, monitor, update, or follow the project plan. Project plans are an integral part of a successful project. The more detail in the plan, the better the estimate is. Creating good project plans is a real skill, but there is a lot of art involved too. For those of us experienced in creating project plans, there are red flags in our heads that show up when something is not as we expected from our experience on other projects. These early warning signs are good indicators that it is time to review and update the project plan.
- The scope is well documented, we have followed a strict change control process, and we have a plan, but it is a project that we have not done before, so we grossly underestimated the level of effort and resources required.
Take the case of the project that was estimated at $100,000. The consultant prepared the estimate, submitted it to the client, and the client accepted the proposal. A couple of months into the project, the consultant realized that the project was much more complex than anticipated and would cost 5 to 10 times as much as estimated. Three things tend to happen in that case. The first is that he continues the project, and when the $100K has been spent, nothing works. The client is unhappy but figures that by throwing a little more money to the consultant, everything will be fixed, so the project drags on. The client just keeps throwing good money after the bad. The second thing that happens is that the consultant points a lot of fingers and says that the users didn’t really communicate the requirements clearly or that something has changed. He then fills out a change control form for a huge amount of additional money. Sometimes the client buys into this, but often the entire project is abandoned. In a third scenario, the client decides to engage a different consulting firm. However, when the new consulting firm comes in, the client’s expectation is that they have already spent $100K on the project, so the remaining work is minimal and they don’t want to go back and confess that the first consultant made a mistake. After all, it was the client who signed off on the initial consultant’s proposal in the first place, so maybe it is just as much the client’s fault as it is the consultant’s.
How do you avoid this mess? The secret to a successful project is great documentation.
Documenting the requirements, documenting all assumptions, documenting the discussion items and issues around the requirements, documenting deviations from the scope or the project plan, documenting the basis for each line of the estimate, and documenting each decision that was made and the impact of that decision, along with documenting all the procedures, processes and all aspects of the build or implementation allows you and the client to closely monitor progress and provides early warnings when something is not as expected. With proper documentation it is easy to turn a project around before it is in trouble.
Don’t Walk Away from $15,450,000
Posted by Helene Abrams in News & Articles, Return on Investment Analysis, TECHANGES, Trends & Technology on March 19th, 2009
Yes, the economy is in the tank and will be for some time to come. Yes, the credit market is tight. I am hearing from several customers that all projects in their companies are frozen, even those projects that have a pretty substantial return on investment and a pretty quick cost recovery. There was even one project that was projected to generate annual savings of more than $10 million dollars that has been put off until after 2Q, 2010. The project was to start in January of 2009 and go into production by July of 2009. Let’s break that down a little bit.
The project was to go live in July, 2009, but has been postponed until July 2010. The projected annual savings of $10,000,000 will not begin to show results until the new projected go-live date of January, 2011 (18 months after the originally scheduled go-live date). During the eighteen months, the company could have been recognizing the results of $15,000,000 savings in operations – savings that would have gone straight to the bottom line. Additionally, even with a modest 3% investment, the company would have earned $450,000 on the $15,000,000.
More importantly, that money could have been used for research and development or for marketing activities that would have made the company more competitive. When the economy is down, buyers should think about how to use the money they have so that they get long-term benefits, recognize results quickly, and grow. For some more ideas on how to grow your business during a recession, please see this article.
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.