That Old House
Posted by Natalia Warren 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.
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.
Looking For Numbers in Boxes – Excel Tips and Tricks
Posted by Chris Busbee in Chart of Accounts Structure, TECHANGES, Tips on March 19th, 2009
The following Excel® tips are widely applicable to reducing time on business projects, whether they are finance- or IT-related. It’s never too late to learn a couple of new tricks, and one of them just might wind up saving you hours of precious time on your next project. I recently had a seasoned IT consultant tell me that one of the maneuvers I’m about to show you was “the best thing he has learned in all his years of consulting.” You may already know some of these, but if not, it might be worth it to bookmark this page, or at least print it out and file it away somewhere.
This article is outlined with the easy tips you might already know up front, and we end with the all too elusive “Go To Special”. If you are working with spreadsheets that contain thousands, or even millions, of rows of data, then the “Go To Special” information will prove to be a helpful tool if you need to change a large or small amount of that data based on any kind of logical behavior. We’ll focus on 7 different tips, none of which involve macros or Visual Basic whatsoever – they are purely ground-level functions and features of Microsoft Excel. >>SHOW ME!!
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.