Custom Search

Monday, August 16, 2010

Integrating All Information Assets Part Three: What Constitutes Integration?

What Constitutes Integration?

So, whether the need for integration arises from the proliferation of business applications within your own enterprise, the results of mergers and acquisitions, or from the demands of e-business, integration emerges as a significant challenge in responding to the demands of business today. What then constitutes integration and how to you go about meeting these challenges?

Oddly enough, just as there are three predominant reasons why integration is an issue, there are three aspects of integration:

The most basic requirement of integration is at the data level.

The second aspect is perhaps the most complicated and problematic level since it is the one that is buried the most deeply into the application. This second aspect involves the actual application logic itself.

The third level is one of consistency and universality of access and visualization.
This is Part Three of four-part excerpt from the book ERP Optimization (Subtitle: Using Your Existing System to Support Profitable E-Business Initiatives) and is available through www.crcpress.com.

Parts One and Two presented the reasons integration is an issue.

Part Three covers what constitutes integration.

Part Four discusses what approach you should take.

Data Level

At the data level, there is master data, transactional data, and data that might be viewed as somewhere in between. This "in-between" data is that which is typically stored with the master data but becomes dynamic as the result of transactions—inventory and account balances, allocations, and reservations.

With the proliferation of applications comes proliferation of master data. Within a single company or division, having multiple copies of master data such as customer, supplier or inventory data, in itself, is not the problem. The fact that the information resident in these multiple copies may be different is the problem. In a rather simplistic example, an order entry application, whether it is a back-office application or a web-enabled electronic storefront, must have access to customer and credit information and inventory availability. Supporting master data can potentially reside in an order entry system, an inventory system and an accounts receivable system. Theoretically ERP took care of this problem with the introduction of a single integrated database.

Theoretically yes, but universally? No. The comprehensiveness of ERP implementations in general has been overestimated. Many companies that have purchased ERP systems, are still running a hybrid mix and as the push to web-enable legacy systems increases, this condition will grow. The need to share common data between applications will grow along with it.

In a multi-organizational environment, particularly one that has grown and developed either by acquisition, or with a planned level of autonomy, the goal is typically to gain access or a view of data across multiple sites and applications. In our simplistic example, the inventory availability may be from any number of warehouses or manufacturing facilities, across multiple operating units or companies.

Application Logic

But then there is further integration that goes beyond the data level and must involve application logic. For example, our centralized order entry function, which has access to multiple sources for inventory, may need to apply certain logic to determine the priority sequence of locations from which to pull inventory. Do you always ship from the closest warehouse? Do you always ship from a certain location unless there is no availability? If so, how do you select the alternate location? These examples require more than simple sharing of data. They require the logic that applies business rules, decisions, and policies.

Presentation or Visualization

And finally there is the level of integration that resides in the presentation or visualization layer? When integrating multiple disparate business applications, do you concern yourself with a common and consistent look and feel? And how is access achieved? When there is a combination of legacy system with new web-enabled applications, do you front-end the legacy systems with a browser-based front-end?

There are several products on the market today that provide you with the ability to bring legacy applications to the Web. This is generally the least disruptive approach in that the underlying application remains the same, along with the application logic and process flow. This may be an acceptable alternative if in fact the existing "green screen" application generally supports your business processes. But it does nothing to improve the underlying application, so if the overall objective is also to provide additional functionality, you may be better off supplementing your existing application with a new web-enabled application that extends the feature/functionality of your existing system. Just how far you go will be determined by what you are really trying to accomplish.

This concludes Part Three of four-part excerpt from the book ERP Optimization (Subtitle: Using Your Existing System to Support Profitable E-Business Initiatives) and is available through www.crcpress.com.

Parts One and Two presented the reasons integration is an issue.

Part Three covers what constitutes integration.

Part Four discusses what approach you should take.

About the Author

Cindy Jutras has over twenty-nine years of experience in applying software solutions to business problems. Experienced in a wide range of functions related to the software industry, including sales, marketing, product development, customer support and product management, she is also an industry observer and trend-setter in business and business applications. Having worked with manufacturing companies for the full extent of that time, she is both a visionary and a pragmatist.

She is currently the Director of Solutions Management for SSA Global, since their acquisition of interBiz, previously a division of Computer Associates. At Computer Associates she was the divisional Vice President of Product Strategy and was instrumental in defining and guiding the product direction of ERP systems as well as advanced technology products.

source:http://www.technologyevaluation.com/research/articles/integrating-all-information-assets-part-three-what-constitutes-integration-17242/

No comments:

Post a Comment