Reach Us +44-175-271-2024
All submissions of the EM system will be redirected to Online Manuscript Submission System. Authors are requested to submit articles directly to Online Manuscript Submission System of respective journal.

Organizational Consequences Linked to the Incorporation of ERP into Companies' Service-marketing Activities

Larry Bensimhon
Senior Lecturer, Conservatoire National des Arts et Métiers, Groupe de Recherche en Economie et Gestion (GREG), Paris
40, rue des Jeûneurs, 75002, Paris, France
Larry Bensimhon is a Senior Lecturer at CNAM, Paris, France. His areas of interest are market finance, behavioral finance, and operational risk management.

Aldo Levy
Professor, Conservatoire National des Arts et Métiers and ISC Paris Business School Groupe de Recherche en Economie et Gestion (GREG), Paris
40, rue des Jeûneurs, 75002, Paris, France
Aldo Levy is a Professor at CNAM, Paris, France. His areas of interest are management control and finance.

Georges Pariente
Dean of Research, ISC Group, Paris
ISC PARIS Business School
22 Boul. du Fort de Vaux 75017 Paris, France
Georges PARIENTE is a Professor and Dean of Research at the ISC Paris Business School. He specializes in international finance.

Visit for more related articles at Journal of Internet Banking and Commerce


ERPs offer a two-fold answer to the need for integration. The first is technical in nature, since the architecture of these programs is designed to ensure the compatibility of their software components and the transparency of their data. They also offer a dynamic approach, because ERPs are mechanisms for incorporating a company's specific functional elements. However, the ERP solution cannot replace every existing management computing system. Accordingly, applying ERP to existing systems will have a significant cost, whether it occurs in the implementation of ERP itself or in the work of making over the firm's own information system. The field surveys that have been carried out show that good management practices already included in non-ERP computing systems can easily be transposed into ERP systems. Conversely, applications that do not follow a horizontal management structure create incompatibilities if we attempt to transfer them into an ERP. The influence of the firm's structure on the implementation of ERP will depend on how compatible it is with the underlying structure of the ERP (structure must follow strategy: A. Chandler.)


ERP, organizational structure, strategy, information system, integration.


The impact of worldwide digitization is forcing companies to step up their service-marketing activities and to install ERP systems, which raise problems concerning both their purpose and their scope.

The installation of Enterprise Resource Planning (ERP) software products is sometimes described as an implantation (introduction), and sometimes as an implémentation (implementation). In an attempt to find our bearings, we refer to the dictionary1:
“Implémenter comes from the English 'to implement’, meaning to execute or carry out. In computing we say that we install (a particular program) on a computer, to implement a new operating system."

“Implanter means to introduce something into a new environment, and cause it to develop in a sustainable manner.”

Thus because we can assume that any firm that is likely to use ERP will already have a computer system, it is more reasonable to speak of implementation. Nevertheless, we will see that there is still room for debate, since the total re-engineering of information-processing systems and the restructuring of the firm could be seen as a starting-over from zero.

In the course of the 20th century, many generations of computer-based management systems have followed one another in quick succession, limiting the possibilities for variation, and forcing firms to make technological leaps. Companies thus find themselves at the dawn of the 21st century with limited options, facing the same need to integrate their information systems and the same difficulties in finding a solution.

ERP (Enterprise Resource Planning) is a software package that centralizes a company's data, its management functions, and its customer-oriented activities. It holds out the promise of correcting the structural defects of company information systems and of answering the emerging needs of e-commerce

ERP offers a two-fold response to the need for integration. The first is technical in nature, since the architecture of these programs is designed to ensure the compatibility of their software components and the transparency of their data. The second is dynamic, because ERPs are mechanisms for incorporating a company's specific functional elements. However, the ERP solution cannot replace every existing management computing system, and this poses a problem. Applying ERP to existing systems will therefore have a significant cost, whether in the implementation of ERP itself or in the work of making over the firm's own information system.

The field surveys that have been carried out show that good management practices already included in non-ERP computing systems [J. Akoka and I. Comyn-Wattiau, 2002] can easily be transposed into an ERP [Meignan 2002]. Conversely, applications that do not follow a horizontal management structure create incompatibilities if we attempt to transfer them into an ERP.

The influence of the firm's structure on the implementation of ERP will depend on how compatible it is with the underlying structure of the ERP.

Particular attention is focused on the effects of this integration on the purchasing function of the company in question.

The Company's Pre-ERP Structure

Raising the question of the effect of company structure on the implementation of an ERP requires that we consider the types of company that ought to switch to this method of integrating their information systems.

The problem of managing innovation

Our society has actually seen few new inventions over the last fifty years, outside of computing itself and what the computer has made possible in other fields of technology, whether directly (calculating and modeling), indirectly (computer-based management), or collaterally by technologic spin-offs (digital electronics). New products that are non-digital are most often not really innovative either. They tend rather to represent the use of technologies that were poorly understood2, too complex to manufacture,3 or too expensive4 for the application of mass production.

It is not easy to compile a list of several dozen truly innovative major products that have appeared over the last fifty years. If we eliminate all the ones that are directly related to advances in the electronic processing of data, to computing5, and to the technologies that it has financed6, not many are left. And most of these7 have an affordable price, compatible with mass selling, only because of the embedded computers that now replace more costly mechanical equipment.

Advances in computing do not come only from inventions. There are also successful innovations

Process innovation

This involves the setting up or adoption of new methods of organization, development, production, or distribution.

Breakthrough innovation

An innovation is said to be a breakthrough [Couturier et al 2002] when it completely changes the way in which customers use it.

However, the management of organizational change is an arduous process (Pettigrew, 1990), and as Segrestin [2004] observes, "companies will never be finished with the beauties and risks of change".

In fact, the deployment of ERP projects [Besson 1999] involves transformations not only in positions and qualifications, but also in organizational processes. Examples: industrial manufacturing by robots in place of workers, and mail-order selling going from the mail to the Minitel and then to the internet.

All the big firms have gone through the same technologic cycles.

The rapid pace and sudden advances of technologic change have finally produced a convergence of behavior among many companies. Although individual choices may have been different, technologic breakthroughs are unifying by nature.


• 1960-1970: the infancy of computerized management

The late 1960s and 1970s saw the first use of computers in management. Initially limited to processing applications requiring many calculations and printouts, such as invoicing and payroll, the activity gradually expanded its scope to include the whole of management, the main objectives being to incorporate general accounting, cost accounting, and then budgeting. Data entry, traditional but automated processing, and printing accounted for most of the machine time8.

Computers were too costly to have more than one. The company's information was naturally centralized on this single machine, and its consolidation was organic. Although the computer was restricted to essential work, there eventually came a unique moment when the integration and compatibility of the data became comprehensive and easy because they were structural.

• 1970-1980: the end of the mainframe monopoly

The early 1970s saw the appearance of the minicomputer. This was a more affordable machine than the mainframe. At first it was used as a principal computer by customers who did not possess the large budgetary resources needed to own a mainframe. However, the minicomputer also gradually began to find its place as an additional computer in companies that already had a powerful mainframe. A minicomputer allowed departments that had only limited access to shared mainframes to have their own information system as well. The mainframe still provided integrated processing for the company's core information system, but a portion of the data now eluded it!

The departmental data processing carried out on these minicomputers increased the computer coverage of the company's functions and provided a considerable added value to its management, but at the cost of a separation. The remaining data were now outside the main information system, and were therefore poorly consolidated or even left out of it. However, the gain was immense, even if it was inevitably accompanied by structural flaws that would eventually lead to serious problems.

As technology continued to advance, the microcomputer9 and the workstation10 made their appearance.

The microcomputer was built around a mono-circuit processor and was relatively cheap. It was a very economical computer, but its capacity was very limited.

Microcomputers and workstations are not shared. They are available only to their sole user. These personal machines11 would exacerbate the fragmentation and dispersal of data, because the computers did not communicate with each other. The company systems were not designed for such scattered computing. There were remote connections via very limited modems with a typical speed of about fifty characters per second12. These were followed by Ethernet systems of 1 MB and then 10 MB capacity, but the lack of software support (OS13 and applications), and the cost of cabling and network cards14, were powerful brakes on their development.

Three approaches were now competing for the corporate data-processing business.

This segmentation of computing was a serious problem for e-commerce. The groups of people who used mainframes, minicomputers, and individual computer workstations had different methods, techniques, strategies, and cultures. Each group wanted to develop its own model of computing. The other approaches were perceived as the competition, even the enemy, and the cooperation that is essential if synergies are to be obtained was not sought by any of the groups, which would lead to hidden costs when implementing ERPs.

• 1990-2000 Implosion and explosion

During the 1990s, one of the firm’s objectives was to regain control of all of its data.
The mainframes would first attempt to limit the drain of applications to mini- and microcomputers by encouraging user requests via the concept of an information center15 and its various manifestations.

This approach quickly reached its limits. The central systems were unable to respond effectively to the needs of all of the constituencies in an integrated company. The proliferation of computers was inevitable. The answer to this dispersal was technical in nature.

The proliferation of software packages16 would enable each entity to choose its own software in isolation, on the basis of their effectiveness in meeting their own functional needs. But this would create enormous heterogeneity both among the components of each group, and within each entity.

In the late 1990s, the emergence of an inexpensive, worldwide network (the internet), and the replacement of minicomputers and workstations by powerful, economical microcomputers would cause corporate computing to implode.

The term implosion is a good description of the unique data-processing structure, which had broken into pieces, scattered throughout the whole entity.

The corporate information system thus became a mosaic of equipment and applications, with connections that were local and partial. Stripped-down applications were developed for user stations, using the three standard office packages: spreadsheets, file-management, and word-processing. Simple one-off processing17
Because business software did not lend itself to automation, which nevertheless came under the central data-processing department, was performed locally on a simple personal office station. This was a logical response on the local level - for users who possessed simple bureaucratic tools of adequate power - to the inability of ISDs to provide functionalities as quickly or as effectively as they required. Such processing was carried out with a great deal of confusion, ignoring the rules of the data-processing departments, and made any consolidation or reporting impossible.

Because business software did not lend itself to automation 18 of its operations,

numerous human interventions were required to perform each processing, which led to errors or modifications19.

In the case in question the SOPELI Group, one of the small subsidiaries (250 persons), had outsourced its payroll operations to a provider without discussing the matter with the HRD or the Group's ISD. The provider would be replaced on January 1, 2008 by the Group's own provider, which used Hypervision. This migration, which could easily have been avoided, obviously had a direct cost: €100 K (€400 per employee), to which must be added the hidden costs of changing the process.

Another trend is the outsourcing, by one component of the entity, of a portion of its processing that the central computing department cannot handle. In contrast to facilities management conducted by the computer department, which does not raise issues of compatibility in processing and data, these uncontrolled outsourcings are carried out by personnel who do not belong to the central computing section. They often have neither the technical skills nor the knowledge of the data-processing regulations applied in the entity to handle this type of operation.

“The transfer of the skills and knowledge necessary for using ERP is a critical act. A number of studies have shown the decisive role played by the training of end users in the success of SI projects [Davis, Bostrom, 1993; Olfman, Pitsatorn 2000]"20.

• A search for compatibility in the early 2000s

Together with the need to market their services, the company's objectives then became compatibility and the free circulation of data at the group level21. The goal was to enable the deciders to recover visibility and control over all of the components of major companies, whose size was continuing to grow because of the concentration demanded by globalization22. The Year-2000 computer bug23 was a powerful force in making people aware of the dangers of dispersed computing services.

The arena is a vast one. There is a need for a unified structure that will integrate all the software components that have proliferated over the last decade. The management of production, purchasing, sales, personnel, customers, and suppliers has been added to traditional applications like invoicing, payroll, and accounting. The other components that make up a data-processing system are also in need of compatibitlty. Operating systems, networks, databases [Akoka, Comyn-Wattiau, 2003] and intelligent interfaces must also be integrated. was a powerful force in making people aware of the dangers of dispersed computing services.

• An approach to integration without a data overhaul: SOPELI's business-management tool

SOPELI is the parent company of a group that specializes in the provision of services inside the radioactive containments of nuclear power stations. The group's expertise includes worksite assistance, servicing, maintenance, training, the measurement of radiation levels, decontamination, and the processing of radioactive wastes. The group comprises six subsidiaries, five of which are 100%-owned, and one 75%-owned but eventually expected to be fully owned also. The group is itself a wholly-owned subsidiary of the Baxtor Group, in which it constitutes the Maintenance Business Unit. The group as a whole employs 2,70024 persons, including 1,200 for SOPELI.

The SOPELI Group is one of the major players in the sector, because of its mastery of all the technologies in the field, including the most advanced decontamination techniques such as high-velocity spraying of dry-ice granules and the use of chemical gels and foams. persons, including 1,200 for SOPELI.

At the end of 2005, the group was experiencing problems due to a fragmentation of management data. Each company had its own computing department, which was inconsistent with the group's own very high level of integration. The gateways between the companies' computing services were limited, and it was impossible to obtain a true, consolidated picture of the group's management data. The profits of the individual companies did not reflect the reality because there was a strong synergy between the group's various activities. A company might appear unprofitable whereas that company's activity provided the support for another component of the group, which derived great benefit from being subsidized. Positioning with respect to competition from global tenders was also difficult, because of this lack of a consolidated picture of the costs within the group.

SOPELI had two main objectives in using a horizontal application:

− To have direct reporting for the whole group, i.e., without time lags and without the skewing produced by asynchronous data transfers coming from mixed applications.

− To settle the tricky problem of the components of the wages of employees who work in radioactive environments.

SOPELI did not want to launch an immediate integration of the group's data, which would however have been the logical solution25. Overhauling the computing services of all seven companies was a very onerous undertaking, and SOPELI naturally wanted to find a simpler alternative. The publisher of Abyss convinced SOPELI's management to choose its "Din" management software package for service companies, a multi-company, multi-component integrated product. The generic term for this type of software product is PRM (Project Resource Management).

Functionally, the "Din" software package represents the integration of four main modules:

− A planning-management module of Microsoft Project type (dates, durations, etc.)

− Management of variable costs by project (purchases, salaries, expenses )

− Management of invoicing

− A financial-analysis and reporting tool in the form of performance charts

Secondary functions are also included in the package:

• Functions: Contract management, estimate management, skills management, etc.

• Additional functions

An essential component: "Din” enables data to be exported. It employs an XML format.


The various components of Abyss’s "Din" software package

Abyss had removed all of its outstanding reservations, claiming that its "Din" software product:

• could adapt to the business rules of each of the group's entities

• would provide full service for major projects while remaining easy to apply to smaller projects.

• could interface, via a company reference system, with the other applications that made up the existing information system:

- Payroll

- Accounts

- Purchasing management

- Skills management

• Could interface with the SAP ERP if the company had to migrate, as its parent company Baxtor had already done.

The ability to interface the software with SAP was a constraint, but SOPELI hoped to put off a migration to this ERP as long as possible. SOPELI was also counting heavily on the "Din" software package to ward off the need for an early move to another integrated-management program, whether ERP or other.

After two years of efforts, only three of the six companies were using this tool. In fact, it was really two of the six subsidiaries, since the parent company, SOPELI, did not introduce any skewing or time lags in the initial versions, based entirely on transfers, since it was itself the reference.

A disappointing performance: This very partial integration was a failure. This setback for the management of SOPELI's information systems was analyzed, and two major causes were identified:

• Support for the change was not handled properly. There were three reasons for this:

- Since extending the application to all of the group's businesses was complicated, the ISD itself did not have a clear picture of how the procedures should develop.

- The applications previously handled by SOPELI's information-systems management were intended for SOPELI alone. By their very nature they fitted perfectly into the company's computing architecture and processes. The change was very limited and SOPELI’s information-system management had therefore not developed a support culture for change, and had neither the methodology nor the expertise required.

- The relationships between SOPELI's information-system management and the company's other components were simple and direct, which allowed problems to be solved before they became a liability. Relationships with users belonging to other companies in the group, even if they were wholly-owned subsidiaries, were complex, and had to be built up and formalized. SOPELI's information-system management had not succeeded in managing the distance, the cultures, and the independence of the users in other members of the group.

• The creation of interfaces and making the necessary adjustments to the application so that the data would be compatible with all of its software programs were not simple tasks, and led to difficulties, delays, and malfunctions that produced opposition and roadblocks.

Since the SOPELI Group was to migrate to an ERP-type management using SAP R/3, an assessment was made of this attempt at integration by application. None of the four objectives that had been set for this application received a satisfactory assessment, although some improvements were obtained, such as:

- Having direct reporting for the whole group. With only two of the five subsidiaries using the software, direct reporting has not yet been achieved. Manual transfers are still necessary, and there is therefore no advanced function such as reporting on demand. The easing of manual transfer tasks and the reduction in skewing are limited, and do not make up for the complications introduced by adding this new software to the packages already in place. The time lag remains, because transfers from the subsidiaries were made in parallel.

- Benefits from synergy in data collection This is the new application’s main contribution. The transmission, allocation, and application of data from the badge readers in Sensitive Units are now fully under control. This function has been checked and operates autonomously. It will therefore continue to be available, whatever subsequent computing choices are made.

- etc.

If we examine the components of this assessment, we can identify one very positive point and four negative or disappointing aspects.

Positive: the analysis and management portion of the overall data define a consistent corpus, even if it provides few benefits for horizontal applications.


– The development of a horizontal application within a structure is not a simple matter, owing to the multiplicity of exchange interfaces required. Such development is costly, because each of these interfaces has to be developed individually.

Managing the application's deployment in each of the entity's components requires expertise that information-system managements do not generally possess.

– The joint effect of the two preceding obstacles is that deployment in the daughter entities is not well done, which produces resistance and roadblocks.

– The progress towards integration is limited, and does not always make up for the complexity added by the combination software.

Thus "Organizational reconstructions both cause and support change, but do not always produce the effects expected. For example, certain companies have had the unpleasant surprise of finding that the data entered were of poor quality (Saint-Léger, 2004), that the ERP's functionalities were under-used [Brehmet al., 2001], that the productivity of their employees had fallen (Markus et al., 2000), and/or that the process logic had been misapplied (Beretta, 2002). An example of a failure that became world famous involves Fox Meyer, even though it is a company based in a technologically-advanced country: the United States. The common thread in all these companies is an underestimation of the changes caused by ERP projects, which has the effect of reducing the resources allocated for handling the change (Rosev et al., 2002)."26

Integration of Sopeli's Existing System into SAP

Integration of the “Din" software package into SAP

Scenarios for the migration of “Din" into ERP.

The first unacceptable scenario: denial of the failure and priority of "Din" over ERP

This consists of preserving all the "Din" functionalities. SAP must therefore deactivate all of its functions that are covered by the applications in the Abyss software package.

This was SOPELI's original preference, supported by its information-systems management. It is a somewhat extreme choice, but its adoption is not surprising. There are three sets of reasons for this:

• Integration into the SAP ERP was a decision made by BEXTOR, SOPELI's parent company. This group uses SAP itself and will provide the SOPELI Group with facilities management for the software package. These two items have very disagreeable consequences for SOPELI's management and its ISD:

– The group will have to migrate to SAP, as ordered, which represents a weakening of the authority of SOPELI's management;

– BEXTOR, its parent company, will if it so desires have total control over its data-processing and its data. BEXTOR will be free to carry out any audits and reporting that it may wish to perform.

• The SOPELI Group has directly invested €2 M in developing the "Din" solution, to which must be added indirect costs such as the time spent by management-services personnel on the deployment, which has never been assessed. Acceptance of the SAP solution in its entirety adds two other items that are very unpleasant for the management of SOPELI and its ISD:

– the failure of "Din" shows that they made a mistake in choosing it;

– the deployment of "Din" will have been pointless, and they will thus have cost the SOPELI Group a considerable sum of money. This loss will be passed on to BEXTOR since SOPELI is its wholly-owned subsidiary.

– SOPELI's management and ISD are greatly influenced by the service provider who developed the interoperability of their systems with "Din".

After two years, the failure to deploy it throughout the group is now described as follows: “After having been deployed in the principal entity, SOPELI, the tool is now being extended to all the other entities in the Business Unit".

This costly development is reduced to: "It was necessary to supplement "Din" with certain functional developments, which address various specific points".

In this scenario, database exchanges between "Din" and SAP are shown as follows:


The distribution of processing also demands the exchange of data derived from processing.


There is no integration of data between the operational management handled by "Din" and the accounting maintained by SAP. This means the simultaneous loss of all that wealth of information, context, and history. The ‘drill down’ and ‘drill up’ functions, previously obtained by double clicking, are no longer available.

Transversality is thereby lost: applications remain as isolated as before, and have no real compatibility. There are thus no substantial benefits in switching to SAP.

Here is an example of a lost ERP functionality: the management rules installed in the ERP are valid for all of the processes involved. If we want to propagate a management rule such as the setting of thresholds for validation processes in "Din", we also have to parameterize this software package.

There is no single database, and therefore the corresponding synergies are lost. For example, it is not possible to access an overall history of the negotiations with a supplier.

If this solution were adopted, SAP would be reduced to simple accounting and it would still be "Din" that would attempt to produce a partial integration in the form of a superset.
This option was rejected for several reasons, each of them sufficient in itself:

− To use SAP as a simple accounting tool makes no economic sense owing to its price and the cost of deploying and operating it.

− BEXTOR, which fully grasps the ERP concept, would never have accepted a solution that would neutralize SAP.

− The personnel responsible for deploying the ERP would refuse to adopt an incompatible architecture that could only lead to problems and failure.

2.1.2 Other scenarios: the acceptable and the accepted

In this second scenario, "Din" manages only projects and timekeeping. The second scenario is a compromise suggested by SOPELI's management and ISD. Purchasing moves from "Din” to SAP. The database exchanges between "Din" and SAP may be seen as follows.


The distribution of processing still requires that data be exchanged after processing.


The number of imports and exports is smaller. This is an acceptable compromise but it opens the way to the next level. There now remains only project management, which SAP can handle at least as well as "Din". The only justification for leaving it in "Din" is to avoid changing the software package, which is unacceptable when a company is switching to the ERP method. On the other hand there are sound reasons for not leaving the project management in "Din". Management control is performed in two different software packages: in the project portion of "Din" and in the management accounting of SAP. The transfer of other charges into "Din” causes the loss of a large part of the added value of these data, which are complete only in SAP The number of interfaces remains large.

The integration of SOPELI purchasing into SAP

The purchasing workflow in the SAP ERP

In SAP, roles form the logical framework27 for human activities in a workflow28.A role is a group of one or more persons associated with a function of the company, of laws, or of tasks to be performed.

In the purchasing process, SAP defines five basic roles that follow one another:

1. the line officer who wishes to make a purchase;

2. the personnel of the Purchasing Department, who manage this request;

3. the technical personnel, who receive the corresponding delivery, typically the storekeeper in the case of a physical delivery (as opposed to a provision of services);

4. The financial manager who authorizes the expense;

5. The "Supplier" accounting department, which checks, records, and pays the corresponding invoice;

These basic roles may be:

− Eliminated. Example: The financial-manager's role may be eliminated, with the Purchasing Department authorizing the expense in an informal manner or by using an additional non-computer procedure. The elimination of a role is an impoverishment of the functional resources of the ERP.

− Replaced by automated processing alone. This is typically achieved via the possibilities in the ERP for defining rules for amounts and frequencies, and for having a horizontal view of the data. For example, purchases that do not lead to an exceedance of the amount fixed in the budget accounting for the category of expense of that management unit are automatically authorized.

− Simplified. Example: Financial approval for small purchases that do not exceed an amount fixed in advance may be eliminated

− Made more complex Example: Financial approvals may be made more numerous for major purchases above a fixed amount.

If we follow good ERP practice, a purchase's workflow comprises seven stages:

1. The Purchasing Department compiles supplier catalogs and lists of proposals that provide a framework for future orders.

− The supplier catalogs offer selections of items that can be consulted by line personnel who want to place an order. For any category of items, off-catalog purchases can be prohibited.

− The lists of requests for proposals are selections of suppliers who must be made to compete for a particular type of purchase.

2. A line officer expresses a need The choice of the product reference and the supplier depends on the kind of product:

− Standard product: purchase from the catalog created by the Purchasing Department, based on a search for the best compromise between price, deliveries, and qualities, from a limited list of suppliers.

− The product is highly technical: its selection requires skills that the Purchasing Department does not possess. The line officer selects one or more references from one or more suppliers. The Purchasing Department negotiates with the supplier only on the terms.

− The product is half way between these two extremes. The line officer typically makes a proposal for references from the relevant set of products and suppliers, in the form of a free choice or a request for proposals.

3. The line officer's request triggers three actions in the Purchasing Department:

• Product and supplier references. If the choice is:

− imposed or restricted, the Department confirms that these references comply with the established rules;

- open or semi-open, the Department performs a check on the best possible cost and delivery;

• Possible grouping of requests to reduce the buying expenses;

• Establishing the order.

4. Financial validation of the order

Depending on the rules for delegation, and on the nature and amount of the order, one or more signatures are required. If the signatures are not electronic, the Purchasing Department is responsible for collecting and entering them.

5. Upon delivery, there is an acceptance in the legal sense for products and sometimes for services. Typically, the storekeeper is responsible for this task if the product is in fact a good, and more probably a line officer, typically the author of the request, if it concerns the provision of a service.

6. On receiving the invoice, the supplier accounting department performs two checks:

- delivered quantity = invoiced quantity

- unit price on the invoice ≤ UP on the order

Partial or over deliveries (quantity delivered > quantity ordered) are handled by the software.

7. On the due date of the invoice, the supplier accounts department sends a payment order to the bank.

The benefits of moving from free-standing purchasing software to the processing of purchases by an ERP are many:

− There is no transfer of data between programs. All of the data related to one order are stored in a single database. The product reference, the supplier references, the quantity, the financial terms, the authorizations obtained, the delivery date(s), the description of actual delivery, the details of the invoice and its payment - everything is preserved and accessible, together with the history and context. This integration combined with the ERP's power offers possibilities with high added values:

− In SAP, the drill29 up and drill down functions enable any data (supplier, item, etc.)or set of data (order, delivery, accounting record, etc.) to be used to move up or down in the data or connected sets of data with just a double click.

− It is not only possible to follow the data throughout the workflow, but also to change branches in the data tree. An item's reference can be used to find the other items recommended by a supplier. The point of view can also be changed, as in a hypercube30, and one can look for the price variations over time of a given product, for one or more suppliers. It is also possible to use invoices to compare suppliers.

− Roles address the company's base of persons, which is stored in a unique space. A change in a person's profile is immediately reflected in all of his or her roles. This offers great flexibility and great security.

Purchasing functions in companies of the SOPELI Group

Three cases summarize the migration of the SOPELI Group's Purchasing function into SAP: two that were easy to transfer, and one that failed.

− The first case was one of the smaller companies in the SOPELI Group, which had no way to manage the expression of its needs. Line personnel completed a paper purchase order form and sent it to the purchasing department. In the absence of any formal framework, the department manager could change items (supplier, quantity, product reference) or reject the orders, usually after personally contacting the requesting party. In the event of a dispute, it was the management that decided. For this company the choice was a simple one. The decision was to adopt the new Purchasing process.

− The second case was a larger subsidiary that had installed a Workflow very similar to that recommended by good SAP practice, although less integrated on the data-processing level. However, it included a significant variant. Because of the highly technical nature of decontamination in the nuclear industry, orders could be submitted by the line officer or by a prescriber. If the order came directly from the line officer, the prescriber had to approve it. The conversion to SAP was simple. The purchase order was changed into an expression of needs and an additional role was created to preserve the prescriber's prerogatives. This role was considered to be worthwhile and a source of added value. It was put into general use in all the companies of the SOPELIS Group.

− The third case was "Din". As already noted, the software package and its rules were purely and simply deactivated, retaining only a support for the timekeeping function.

− The final workflow diagram for purchasing is shown below. It perfectly matches the SAP requirements and incorporates the specific features of the SOPELIS Group.


The SOPELIS purchasing process


The forced development of management computing between 1960 and 2000 typically produced fragmented information systems which used an assortment of software packages, dispersed in various parts of the entity.

The use of interfaces to perform periodic exchanges of data has demonstrated its limits, and entities have turned to partial integrations based on the use of horizontal software.
Now that this initial search for compatibility has produced disappointing results, the ERP solution is seen as the only complete and satisfactory one.

There are two ways to make the move to ERP successfully.

− The first is limited to firms that already have the good management practices recognized by installed ERPs. The transfer of existing procedures into the ERP is simple, and the firm can retain its operating methods while also benefiting from the advantages of ERP's data integration.

− The second applies to firms that have made poor choices and find themselves with incomplete systems that enable a partial integration, i.e., an introduction. These architectures often improved matters at one time, but have since shown their limits and shortcomings. The sooner and the more completely the firm abandons its use of them, the fewer problems it will face when it migrates to an ERP. Although the above solution may be costly and difficult to implement, such firms must set aside their former software and move on, without regrets, to a comprehensive solution.

… and new ways to fail.

1 Le Petit Robert

2 On March 29, 1955, a modified Jeumont-Schneider BB9004 electric locomotive broke the world speed record with 331 km/hr. This record would not be broken in France until 1981, by a modified TGV (380 km/hr).

3 High-power lamps for video projectors.

4 Carbon in brakes and sailboards.

5 All the digital products: personal digital steros, cell phones, GPSs, ABS braking, electronic power-assisted steering, etc.

6 All the products derived from computer peripherals: CD, DVD, plasma and LCD screens, etc.

7 Airbags, electronic injection, automated gear boxes, etc.

8 This was the unit of measurement for the activity at a time when the very limited and very expensive power of the machines was a precious commodity.

9 The first microcomputer that was more than just a gadget was the 1975 Commodore PET. From the manager's standpoint, the machine that really opened the way forward was the 1980 IBM PC.

10 The first workstation was the Sun-1, in 1980.

11 This new concept of computing would be confirmed by the name of IBM's first microcomputer, the Personal Computer (PC).

12 600 baud.

13 The first Microsoft operating system to have a network stack was Windows 95.

14 Until the early 1990s, PC network cards were limited to Novell products, which were expensive and distributed only through integrators, often with lengthy delivery periods.

15 This concept had originally been developed in the mid-1980s.

16 A complete, documented set of programs designed to be distributed to a number of users, for the same application or function (source:

17 Invoices and pay slips produced on spreadsheets, and CRMs using Word backed by Access are examples that I have encountered several times in the management departments of small units that have given up on going to their ISD because of the delays, or the failure of ISD to meet their need for services.

18 Creating macros in Visual Basic, or programming applications using Microsoft Framework, did however enable the automation of applications that used Microsoft Office. The technical level demanded for this type of work is that of a computer analyst, and therefore beyond the reach of basic users.

19 In the late 1990s exports of files containing descriptions of thousands of students, sent by a service provider to one component of a large higher-education institution, were created with office software programs. They were imported by a program with a fixed format of EDI (Electronic Data Interchange) type; the reject rate was 25 %.

20 R. El Amrani, op. cit.

21 This need for integration can be demonstrated in hindsight. All of the 383 major French companies that have more than 2,000 employees use at least one ERP (source: IDC, quoted by

22 “In terms of sales, the concentration of service companies increased between 1993 and 2003. Over the same period, groups increased their dominance of this sector. Thus between 1994 and 2002, the share of sales made by groups went from 41 % to 64 % " (source: INSEE).

23 and the move to the euro for EU countries.

24 2007 workforce.

25“Almost all big firms now have at least one if not more ERPs. As for SMEs, more than half of them already have an ERP. These figures only confirm their central role in the use of SI by companies.” El Amrani, op. cit.

26 R. El Amrani, op. cit.

27 In the computing sense, it means the manner in which an automated system apprehends its environment. It contrasts with the physical view, which refers to the technical manner of processing the environment. The tables in a database are a logical image of information, as opposed to files on magnetic disks, which are its physical reality.

28 Successive flows of actions or processings formally performed by persons, and automated processings enabling a result to be obtained (after

29 Drill: by analogy to data mining, comparing the extraction of data from an information system to the extraction of valuable ores from a mine.

30 A hypercube is an abstract representation of multidimensional information, which enables data to be seen from different points of view: geographic, temporal, organizational, etc.





Copyright © 2024 Research and Reviews, All Rights Reserved