Life cycle of an ERP system implementation project using the example of packaged SAP and 1C solutions, as well as custom developments

Rumors about the need to replace imported software products have been circulating since 2014. But until 2022, it seems many organizations and their CIOs saw it more as a marketing gimmick than a real need. The departure of most foreign vendors from Russia caused panic among the management of the IT industry. Which later turned into a number of different projects: urgent transitions from the global SAP template to the local version, implementation of 1C products, creation of custom developments to fill emerging gaps in the market, as well as long-term initiatives for import substitution. All this affected many in our field: by focusing only on SAP projects and products, we missed many other software solutions and ways of implementing them, which demonstrate the diversity in the world of information technology and enterprise information systems (CIS).

Along with the cascade methodology, which is the basis for the implementation of most SAP projects and hybrid SAP methods, which actually live only on paper, specialists have access to Agile principles applicable in custom development, spiral implementation models recommended by 1C in TKB technology (corporate implementation technology) and much more another thing that we did not pay due attention to under the dominance of Western software products.

Having participated in several projects for implementing 1C solutions, as well as custom developments, and having more than 15 years of experience in involvement in SAP projects, I would like to share the results of comparing the features of their implementation. Further material will be considered in the context of the following projects: replication of SAP ERP, automation of purchasing activities based on SAP ERP MM/IM/FM, implementation of 1C ERP, BP and ZUP, preparation of target IT architecture based on 1C ERP, as well as implementation of custom SRM- solutions for which it was critical to select a relevant implementation model and deliver the result on time.

We start with the life cycle of corporate information systems. Figure 1 shows the main stages that are inherent in any software product, regardless of its size and class. It all starts with an idea, which then turns into a design, then the design is implemented, the product is put into operation, and finally the software solution is completed. The latter can start the life cycle chain all over again: the old version is replaced with a more modern and functional one, that is, the program is radically updated.

The life cycle of an enterprise systems implementation project is a more detailed description of the stages that must be completed to put a software product into operation. In Figure 2 you can see an example of such stages. The exact steps and sequence of actions may vary depending on the software provider.

If we are talking about custom development, it would be useful to refresh your knowledge on flexible methods for implementing software products – these are classic iterative and spiral models (multi-pass models), currently represented by the Agile methodology. Here we should remember Stacey's matrix on business and technological uncertainties, which clearly defines the scope of application of Agile methods. So, if business requirements are static and there is a strict understanding of how they will be technically implemented, a waterfall implementation model is used; in all other cases, agile development methods are used (Figure 3). It is also worth emphasizing that the use of flexible methods, for example, Agile Scrum, requires a complete transformation of the project team compared to its classical organization in a waterfall implementation scheme. However, no one is stopping you from applying Agile principles in implementation projects based on the waterfall model.

I’ll add a few words about ERP systems; at the moment, this class of systems is the most representative in terms of completeness and coverage of the functionality of the automated system. Classic ERP class software is a set of separate information systems (IS) that automate various areas of the enterprise: finance, procurement, sales, production, etc. Consequently, the methods of implementing IS and CIS differ: the success of implementing an ERP system is largely determined by the rigor organizing the implementation process and the ability to work with requirements and their changes. This once again emphasizes the importance of choosing a rational model for implementing a software product.

Now let's return to ERP projects and focus on SAP solutions. SAP products are associated specifically with corporate information systems: large-scale software capable of automating holdings and international organizations. In this regard, the vendor first promoted the ASAP implementation methodology, which represents a cascade implementation model, and later the hybrid SAP Activate model, focused on the development of software systems. The ASAP methodology contains the classic project stages:

Despite the active mention of ASAP and the provision of accelerators for it, represented by ready-made document templates and a list of project tasks, it was not entirely suitable for the Russian market. Practical experience has shown that a more effective implementation scheme for an ERP system, let’s call it ADM, includes the following stages (Figure 4):

The advantages of the proposed ADM model are that:

• attention is focused on requirements that are clearly identified, described, and prioritized during the analysis phase. All subsequent stages are based on them. This is an important difference from the ASAP model, where requirements are actually developed in parallel with the solution design, which often led to increased project scope;

• Particular emphasis is placed on the testing phase, which was specially added and adapted to Russian conditions. Thus, product verification is carried out through continuous acceptance testing, which is closely related to the classic V-test-driven development model.

The ADM model has proven its applicability in both greenfield and replication projects. Its main area of ​​application is the implementation of large-scale software solutions of the ERP-ERP3 classes or their analogues. Examples of successful use of ADM include: replication of SAP ERP in an alcohol company, automation of purchasing activities based on SAP ERP MM/IM/FM in a large international retailer.

Now let's look at 1C implementation projects. The vendor offers three technologies for implementing 1C products: standard implementation technology (TSI), quick result technology (RRT) and corporate implementation technology (TCI). Following the information from 1C, the implementation of ERP class software products can be carried out primarily on the basis of the 1C: TKV method. According to the 1C: TKV model, we will represent the implementation process as a classic spiral model, where the implementation stage consists of a set of iterations for the development and configuration of a software system according to Agile principles. Let's imagine the implementation project in phases (Figure 5):

further repeating stages according to the spiral implementation scheme:

• IS design;

• IP development;

• preparation for putting the IS into trial operation (TE) and/or pilot industrial operation (PIO);

• carrying out OE and/or PE;

• preparation for introducing IS into PE;

• carrying out PE

and finally the completion of the project.

Despite the availability of a detailed description of the technology, the variability of stages and tasks, the existence of accelerators, the implementation of 1C solutions by many IT companies was often carried out in an arbitrary manner. And this was acceptable for projects in small organizations, however, it is fraught with failure in the case of large and distributed enterprises. As it turned out, the 1C: TKV technology, recommended for large projects, has poorly developed issues of migration, transition, and testing in general. To my surprise, the methodology used in SAP projects was ideal for implementing large-scale 1C solutions (Figure 4). In particular, in the project of implementing 1C ERP, BP and ZUP in a large manufacturing company, the 1C: TKV methodology simply did not work here, as well as in preparing the target IT architecture based on 1C ERP in a large wholesale organization, where the management committee did not agree with the composition stages and work according to 1C: TKV, reducing the implementation model to the ADM scheme.

Let's move on to custom developments; it is important to note that the scope of their application is limited to specific business requirements, which are practically or completely not implemented in any of the packaged solutions. A custom software product development project has a number of features:

• emphasis on building a technical IT architecture;

• long period of project implementation;

• reengineering the software product, not the customer’s processes;

• Agile-oriented approach to project organization and implementation;

• different composition of the project team.

Unlike boxed software solutions from SAP and 1C, in which the functional core of the system has already been implemented, and its additional configuration and modification are considered as “bows”, development from scratch requires significant effort in the detailed development of the future software solution: programming languages ​​for implementing front-end and backend components of the system and/or the use of existing services and technical solutions, integration technologies, database management systems, etc., which by default increases the duration of the project several times. The future software product is determined by a set of functional and business requirements. Since all requirements must be developed from scratch, the need to prioritize them in order to distribute development over time becomes urgent. Therefore, in my case, when developing an SRM system, there was a strong need for iterative and spiral implementation models. Having experience in implementing packaged programs, it was decided to use not the Agile Scrum model, but a methodology close to 1C: TKV:

• all requirements were prioritized and 3 waves of implementation were formed;

• within each wave of implementation, the development stage was divided into iterations, within which part of the software product was implemented and subsequently demonstrated to users;

• the stages of preparing and conducting MA and/or PPE were replaced by a single testing phase.

The proposed implementation model was obtained as a hybrid of those illustrated in Figures 4-5, and includes phases (Figure 6):

Then the steps were repeated three times according to the spiral implementation scheme:

The structure of the project team has also undergone changes due to the features of custom development and the Agile-oriented implementation model; the following roles have appeared:

• technical architect;

• data architect;

• integration architect;

• testers

in addition to the generally accepted ones: project manager, consultants and developers. If the implementation of a boxed ERP system on average requires 6-12 months, then in our case this was the period of only one of three waves of implementation.

Despite the differences in vendors, software solutions and their types, and initial implementation methodologies, all the considered project examples have a similar feature: the success of program implementation depends on the correct organization of work and effective requirements management. The first is usually determined by the implementation methodology, and the second by the mechanisms for processing change requests. The differences between projects for the implementation of SAP, 1C and custom solutions are presented in the table below (Table 1). From it it is easy to notice that there are no significant differences; Moreover, experience in implementing some software products may be applicable when implementing others.

Table 1. Differences between projects for implementing packaged and custom software solutions

To summarize, I would like to note the following. The market for Russian software products is naturally changing: foreign solutions are being replaced by our domestic ones, which can be seen in the example of SAP, 1C and custom developments. Despite the seemingly obvious differences in these solutions, the methods for implementing projects to implement them are close and mutually usable. The best methods for implementing SAP products are applicable to 1C projects and custom developments, and vice versa, certain ideas and approaches of Russian IT practices are relevant for Western and international implementations.

All work on the implementation of ERP systems is based on the chosen methodology, which determines how the project will proceed. Everyone involved in such activities is at least somewhat familiar with PMBoK: a set of basic project management knowledge. Its main idea is to follow a cycle of planning, executing and controlling work, and handling deviations. It is important to choose and apply the implementation project life cycle model correctly to successfully complete tasks on time and avoid problems. As Benjamin Franklin said, “Ill preparation is a recipe for failure.”