Integrating ERP and CRM in Your Management

It also takes place in industrial companies and financial institutions. In my 1999 seminar on “High Technology” in Rome, Italy, one of the participants was the IT director of a large insurance company. Summing up what he said in a few words gives the message that the Middle Ages of EDP are still the “right stuff” today: “What was valid in the 1960s continues to be the best solution.” At least that is how they think in his company — and how they act.
These facts are brought to the reader’s attention because I have found them in existence — albeit in less acute terms — when ERP commodity software is introduced to a firm. Only the best companies changed things significantly, including their culture; and this because of the Internet’s open standards which, when correctly implemented, allow everyone to effectively communicate with everybody else following the same norms.
Another problem to be brought to the reader’s attention regarding the efficiency of ERP implementation is a tendency for IT integration firms to over-customize applications, which is synonymous with over¬complicating them. This runs contrary to the principle that off-the-shelf programming products should be used straight-out-of-the-box. As case-after-case demonstrates, changes run deep into the structure and functionality of bought software. Read the rest of this entry »

As the preceding sections brought to the reader’s attention, to a very substantial extent, companies run their mission-critical applications across a variety of platforms that are poorly integrated. They have been put together under one or many roots as if they were never intended to communicate with one another. Both the time to introduce ERP software and the risk that these mismatched platforms will not work as a system increase geometrically as the complexity of the communications chores and hardware/software configurations increases.
The fact that most computer applications available today grew like wild-fires in the 1954 to 2000 timeframe is not surprising. What is surprising is that far too many companies stick to this mismatch of technology platforms that offers them far too little gain. Sometimes they do so because of inertia. In other cases, they hope that their obsolete and expensive technology will not erode their finances or their competitive edge. They are wrong, of course.

- Nothing alienates customers and internal users more than technology that does not work in
user-friendly and effective ways.
- In a period of fast change, there are duties and challenges that cannot be put on the back
burner while sticking to the old stuff.
There is no better example of how counterproductive expensive old programming libraries can become than the huge amount of code maintained by the U.S. Department of Defense (DOD). A 1994 study asserted that (at the time) the DOD had more than 1.4 billion lines of code associated with thousands of heterogeneous, non-combat information systems. These were located at more than 1700 data centers.[2] This enormous inventory featured many functionally duplicative systems, thereby creating two classes of problems: Read the rest of this entry »

Whether referring to one company with many sites or to a cooperative Internet-oriented effort among many independent firms, each node in a multi-site ERP or supply chain implementation has a significant impact on the technology solution being sought, and vice versa. A similar statement is obviously true for the chosen business architecture, remote access mechanism, and telecommunications infrastructure.

It is quite evident that distributed implementations pose different challenges than centralized ones in terms of data replication, response time, and systems supports. A distributed architecture should be preferred for reasons of greater reliability, database performance, telecommunications costs, and other factors. Generally, distributed applications make it easier to handle incompatibilities between organizational conditions and standard ERP supports.

A rigorous analytical procedure can play a key role in attaining better performance. Effective analysis requires both a comprehensive understanding of critical organizational processes and a detailed knowledge of the ERP software to be implemented. Crucial to a successful application is the need to merge traditional system development with a process of organizational adaptation that has the ability to close the knowledge gap often characterizing the crevasse between existing IT infrastructure and supported ERP functionality. Read the rest of this entry »

Organizations with multiple sites requiring Internet-oriented ERP support should study ways to implement supply chain solutions so that data and processes of the entire enterprise can be integraed into a unified aggregate. In organizational terms, one of the first issues arising in a multi-site supply chain situation is scope and expected benefit: defining the extent and type of competitive advantages that can be derived. For a major firm, the application of supply chain solutions in only one or two business units provides much more limited benefits than implementation in every business unit. However, the use of one standard software across multiple units poses organizational and reengineering challenges, along the lines discussed in Chapters 2.2 and 2.3, that must be solved.

Precisely because of these reengineering challenges, many companies have chosen in the past to implement different ERP packages at their sites. This provided for a local choice that might better fit the local conditions. On the other hand, implementation of several different off-the-shelf packages has increased the in-house heterogeneity of ERP software and its interface(s) to the distributed database.

In an extranet sense, heterogeneity and problems derived from it are particularly pronounced in collaborative ventures, such as common Internet purchasing activities, where different companies work together to gain economies of scale in terms of procurement. Reengineering across a spectrum of companies — particularly big corporations — is not a job that is doable at current state-of-the-art. What can be done as a start is to establish dependable common metrics. This should be followed by: ■A project capable of identifying key processes relative to strategic goals of the common Read the rest of this entry »

To a very substantial extent, these results are obtained through information shared with the supply chain. Therefore, the reengineering program must support integrated analysis and design activities required to modernize the programs selected for migration to Internet-enabled ERP. The chosen methodology should implement streamlined functional and data requirements, even if the legacy systems being replaced had overlapping information and esoteric domain characteristics. The target configuration should be:

■A set of homogeneous machines

■An intelligent high-speed network

■Shared distributed databases

■A user-friendly programming environment that is strong in visualization and visibilization The chosen software must be adaptable to a range of applications by augmenting them with specific functional or performance capabilities, without requiring one to re-start the reengineering job or do a complete redesign. And mentioned in Chapter 2.1, this job should be performed without a hitch while the system is running. Read the rest of this entry »

My experience with restructuring, reorganization, and reengineering suggests that information technology and other projects will be so much more effective if one follows a methodology that has proven its worth, and therefore its ability to provide deliverables. In project after project, six basic steps characterize such a methodology:

• Write down the objective(s).
• Examine the basic elements to be reengineered.
• Define if these elements must be high duty or low duty.
• Put to work a small, well-trained group under an able leader.
• Apply stringent timetables for deliverables.
• Perform design reviews with authority to kill the project.

In my opinion, the best way to look at reengineering is as a method of maximizing the results of a thorough information technology reorganization, one that affects all or most platforms, basic software solutions, and applications domains. A crucial issue is restructuring of data components based on their dependency relationships, as established through logical data models. This produces the nearest thing to an optimal order to follow in platform unification, database design and datamining, networking of available resources, system integration, and overall performance.

How simple or how complex can this job be? The answer is largely situational. In the general case, the inventory of physical and logical evidence regarding IT resources is difficult to collect and analyze — but the job is doable. Even if there is documentation on past programming efforts, which is no forgone conclusion, it is often outdated or of poor quality. In addition, people with the required knowledge for reengineering are often not available.

In addition to the difficulties outlined in the preceding paragraph, the existing interfaces between information elements, whose job is transferring data instances, do not represent completely identifiable or shareable data structures. This is a problem of classification. There exist, as well, semantic requirements that must be addressed beyond what was done in the past. Read the rest of this entry »

Welcome to WordPress. This is your first post. Edit or delete it, then start blogging!