This blog series is designed to help in understanding the concept and usage of change projects in business configuration. The idea of this series is to explain the features of the change projects, and some do's and dont's while working on it. This blog series will contain following articles:
- Introduction - Concept and Usage
- Change Project Types - Remote or Local
- Change Project - Merge and Sync with Production
- Change Project Life Cycle
- Change Project FAQ Page
Introduction - Concept and Usage
Change project is a mechanism to bring in new business configuration (scoping) changes into a production system once that production system is set to live. How should this "live" be inferred? To explain this, I need to explain the life cycle of the first implementation project in a customer production system.
When a customer requests a new production system, that system comes with an implementation project with title "First Implementation". This implementation project can be seen in Business Configuration work center, Implementation Projects work center view.
In case the above production system is requested from a test system with solution profile copy option, then the implementation project in the production system will be a copy of the same name project from the test system. In case, this production system is a fresh request, then the implementation project will be a pre-configured project delivered from SAP. You can get more information on different kinds of possible tenant request scenarios here.
Once you have the above implementation project in your production system, you can continue with your business configuration setup. You can do scoping as well as fine tuning related changes. There are various milestones in an implementation project. These milestones are reviewed at different project stages. The last and final milestone of this "First Implementation" project is "Confirm Go Live". This milestone is only available in a customer production system but not in a test system. This milestone is set to confirmed once the customer solution is tested and accepted by business users community. Once this milestone is set, the implementation project status changes to "Live".
Once an implementation project is set to live in a customer production system, this brings in certain constraints on carrying out changes in business configuration. A customer should be able to carry out maintenance of most of the fine tuning activities, i.e. maintaining a code list. However, a user will not be able to carry out any changes with respect to scoping in the implementation project. This restriction is set to minimize risk at the production scenarios at the customer. Bringing in new changes, without proper testing etc., will put the current production processes at risk.
Now, I come to the first sentence of my blog article, which states that change project is a mechanism to bring in business configuration (scoping) changes into a customer production system.
How do I create a change project? Once the first implementation project is set to live, the "New" button on the list in the Implementation Projects work center view will be enabled. This button is used to create a new implementation project, which is also called a change project to infer that this project is created to bring in some changes.
What happens when a user creates a new change project? This results in the creation of a new implementation project which in fact is a copy of the existing live implementation project. This way, a user starts to carry out changes on top of his existing live solution scope.
Will the changes I am doing in a change project impact my production system? The answer is no. The change project is not associated with the runtime of the production system. Or in layman terms, the processes in a production system work with the live implementation project. These processes do not access a change project at any point of time. This way, we are able to separate out the project which should be used to run processes and a project which can be used to carry out new changes. Once a change project is created, there is no automatic synchronization between this change project and the live project. This means, in case you make some fine tuning changes in your live project, those changes will not automatically come to the existing change project.
Can I have more than one change project in my production system? The answer is yes, however not recommended from SAP. Technically, you can have multiple change projects in a production system. Whenever you create a new change project, it copies the live implementation project and creates a new implementation project as per your given description. A valid use case of multiple change projects could be that a customer wants to carry out two separate line of changes and wants to keep these as different projects.
But you can already observe here that if you have multiple change projects then there would be issues with syncing these different change projects at any given time. Let's try to understand the scenario from above picture. In the above picture, we see two change projects, CP1 & CP2. First CP1 was created, and after some time CP2 was created. As you can see, both these change projects started with the copy of the same First Implementation. Now, there can be chances that the state of the First Implementation at the time of creation of these two change projects was not the same. A user might have done some changes (fine tuning) in between the creation of CP1 & CP2.
At some point of time in future, a change project needs to be merged with the live project. And at the time of merge, user will run into conflicts in case a change project and live project is not in sync. Therefore, if you have multiple change projects, keeping those in sync would be a time consuming task.
Of course there are remedies to overcome this, however the conflict resolution among different change projects is not that easy. We will learn about syncing change project with live project in a latter article.
The next article in this blog series deals with the types of change projects and how you can perform testing for the changes carried out in the change projects.
- SAP Managed Tags:
15 Comments
| User | Count |
|---|---|
| 4 | |
| 3 | |
| 2 | |
| 2 | |
| 2 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 |
