Fellow Members,
In this blog, I would like to share my experience with recent Change Request Management projects. I read a blog on ChaRM on a Developers perspective and I liked it and it was close to the 'things' that you hear in a ChaRM Project. In the same lines, I tried to compile my notes from my work diary and present it here in plain English. The idea behind this effort is to highlight the quote "In theory there is no difference between theory and practice; but in practice there is.!!"
P. S: All the content expressed here are my personal opinions and do not represent my employer or SAP.
1. Concept of Change Request and Change Document
Often during the blueprint discussion phase of ChaRM projects, the most frequently asked question is 'Why do we need two documents in ChaRM process?'. Most of the customers I worked with, find this concept little confusing. The confusion is more profound if the customer does not have a established change management process or used to any other tools (like sharepoint, custom web forms or editable PDF forms..etc) as Change Request Forms. The hard time for consultant will be to convince the customer and make them understand, how Change Request will be used only for Approvals and Change Documents would be used for handling Transport Management aspects of entire process. So be prepared to convince that the Change Document is where all the action is.
2. Who will create Request For Change?
This topic sometime gets overlooked. The organization structure of companies running SAP varies from one organization to other. So we can not go with a notion that one size fits all concept. During a initial discussion phase, the work of consultant would become easier if the customer has a well established change management practice. Sometime the end user would be sales agent on the field or sometimes it's the help desk team. Sometime there would be scenarios where in the end user does not have access to SAP system and have to call the help desk hotline to raise a CR on behalf of him/her. So identifying the right set of people for end user trainings is an important factor to be kept in mind while designing the process. Understand your end users of the process.
3. Approvals in Change Request.
This topics varies from customer to customer and consultant needs to be prepared to expect more than 4 or 5 approvers for a single change request. The standard out of the box configuration has 2 level of approvers(Change Manager and Change Advisory Board). However speaking from my past experiences,average number of approvers I have encountered is minimum three. This means for consultant would need to customize new partner functions and CRM UI aspects of it. It is possible to have up to 10 partner functions in Change Request UI, so technically we can have up to 9 approvers for a change request(one of the partner function is being reserved for Requester/End User). In some scenarios, the end user raising a change request would not be knowing who would be his 3rd level of approver for the request of change. In such cases we need to design automatic partner function determination using categories. This would ease the process. Also if the organization is huge, then expect to have a very long list of categories to be added to multi level categorization in a change request. In addition, if you could customize the approval procedure determination using categories then it would be applauded by the end users for sure !! :smile: So try to incorporate automatic Partner determination and Approval Procedure Determination based on categories.
4. Emails in Approval Management
Everyone loves to receive a email if he/she was made as a approver for a change request(if possible in HTML mail format). The scenario would be even more useful, if the approvers receiving emails in a sequential way i.e first Change Manager receives an email, once he approves, Chnage Advisory Board receives email...so on. BUT unfortunately in a standard process offered by SAP as of 7.1 SP12, the approvers only receive worklist emails in their SO01 inbox. And in the practical world I have never seen anyone checking their SO01 inbox for mails !. So by default, approvers in change request will not be notified via email for approvals. This was very disappointing for me in the beginning because this is one of the most frequently asked feature in ChaRM by all the customers I have come across so far. However later I learnt that with little customization you can convert these SO01 inbox worklist email to outlook/inbox email notifications. However please note, this converted email notification would be in plain text and not a fancy email you wish to see. There is a long thread ChaRM: Approval Settings - Email Functionality in Change Request by which I learnt how to do it. Email notifications for approvers as a part of worklist is one of the most needed feature in out of the box ChaRM solution, hope SAP would incorporate this as a standard feature in future releases. :oops: So If you are on 7.1 SP12 or below be prepared to be surprised that there is no html email for approvers !
5. Which Change Documents to use?
Again, this is one of the most debated topics and strangely, I have seen customers reluctance to use Normal Changes for maintenance purposes. Some of the feedback I hear during blueprint discussion meetings are like, Normal Change is too much 'clicks here and there' and Normal Change is not very flexible in 'what if..' situations. There could also be scenarios where Basis team is trying to minimize their efforts in Change Management and Transports execution process. In such situations they would always push for the Urgent Change instead of Normal Change. Normal Change fits perfectly if the customer has a defined release cycle concept. However in scenarios where the customer is so much comfortable with existing ad hoc transports import, then they expect your new process to work the same way. With the new preliminary imports and other enhancements as of SP12, things have started to change and Normal Change is finding more and more relevance for everyday change processes. The consultants job would be to thoroughly understand the customer requirement and compare that with Maintenance Cycle, Normal Change, Task list and other tools provided by SAP and design a best suitable solution.
There is another perspective for this. Some customers would only be looking to automate the Transport Management process and other would be interested in complete re-haul of their change management practice to adopt to best practices. So it depends on whose boarding room you would end up :smile: So bring in the clarity on type of change document to be used andemphasize on importance of having a disciplined release strategy.
6. Approval for Transport Import inside individual Change Documents
I encountered this request 2 out 3 times in my previous engagements. Even though Change Request is approved(in some cases by CIOs too) and handed over to functional/development team for implementation; the leads/managers of functional/development teams would still want to control the transport import process to follow on systems via approval apart from just controlling the phases of cycle. Again you can trace the origin of this type of requests to traditional email approvals that the team leads/managers used to provide before implementing new process. This type of requests can be handled easily by tweaking couple of new actions and statuses in the change documents. No big deal, but time consuming for consultants :smile: So be prepared to expect some more approvals in random places.
7. Simply the User Experience and UI as much as possible
Before you hand over the process to user trainings, try going for minimalistic approach in the CR or CD UI. By default you have lot many tabs inside CR or CD which may not be relevant for every customer. So tweaking the UI and removing not used tabs can add lot more value for the end users. In one of the projects, I was requested to simplify the UI to look like 7.0 version CR screen (with tabs on the top instead scrolling down UI). I have written a blog on how to transform the UI look from long scrolling form to simple tab based UI. Please refer that blog. So go with a lean design.
8. User Trainings
According to me, this is one of most time consuming process in ChaRM implementation projects; it is every human's basic nature to be reluctant for the unknown or new things anyway :razz: . I recently used one of SAP's tool in training and content management portfolio, WPB (Workforce Performance Builder) and this tool turned out to be very useful for end user trainings in ChaRM. Users liked the way of learning new process ( like creating a new CR ...) in a completely new UI with relative ease. So be well prepared with Kubler Ross theory !
Source: Kubler Ross Change Curve
9. We went Live on ChaRM, what's next?
The entire success of your ChaRM project depends on the effectiveness of Basis team in handling Change Documents post go live. The maintenance of ChaRM related task should be owned by competent Basis team, as Esteban highlighted in the comment section, establishing roles and responsibilities in the supervising the Change Management process is vital. There should be a run book available with FAQs and common error situations in handling change documents.
Hope this helps all the consultants out there who would be handling ChaRM projects for the first time !!!
I would love to hear from all of you on your experiences, suggestions and feedback in the comment section.
With Regards,
Vivek
- SAP Managed Tags:
12 Comments
