Again, back to the house analogy. Once you have all the building materials available, and if you can get a good schematic of the house, you can remodel it with the right tools. You can move walls, add on to the existing structure, or even start over again on the same foundation. Within Oracle E-Business Suite, Metadata Analysis gives us the schematic, your data and business processes are the building materials, and we have the software tools to remodel EBS any way that you want, whether it is merging data together, splitting it apart, changing it, or moving data to realign it with the changes in your business.

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…

Because cost savings will continue to be the focus for the foreseeable future, this paper will review best practices in workflow improvement that reduce costs for three key business processes: Procure to Pay, Period-end Close, Order to Cash. At some point when the economy moves out of recession, organizations will begin hiring again. Keeping an eye on our concluding key performance metrics will help organizations better decide when it’s time to flip the hiring switch. Read more…

Similarly, companies have invested enormous resources in their ERP systems, nurturing them and adding to them over time as the needs of the business changed. The original Oracle E-Business Suite implementation, for example, was designed with the best of intentions. The team, along with the busload of consultants, tried to build a system that would last the company for years and through generations of change. They provided each location the ability to govern its own system and configure it for flexibility to meet the operational needs of that entity. As with children, providing a good foundation prepares the organization for change, but it is difficult to predict the external factors that influence the adaptation and performance of the company over time. Read More…

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…

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…

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.

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.

1. 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.
2. The scope expands and the change control process has not been considered carefully.
3. 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.
4. 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.

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.

1. 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”.
2. 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.
3. 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.
4. 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.
5. 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.