The elements of good change control procedures for supporting a complex commercial ERP environment

The factors should be taken into consideration when designing change control procedures and the potential areas of vulnerability, even after well-designed procedures have been put into place

The change control procedure is the key to a successful for any project let alone a complex ERP implementation that spans across countries and involves a suite of products. In my view, and in my practice, I’d consider the following are the key elements in addressing the change control management

• Updated Organizational Change Management Plan: The plan needs to be updated as we are moving over from the blueprinting phase to the realization phase. The realization phase consists of development and technical solutions, will definitely pose a threat to the agreed up on scope. Since this phase has a large scope for the scope creep, a careful amendments to the existing change control plan needs to be incorporated, with the participation of the technical team. In my view, This will involve three main components:

·         Stakeholder Review

·         Risk Mitigation plan review

·         Reviewing Stakeholders

• Sponsorship Engagement: As the realization phase gets traction, there will be a lot of issues that might end up in the following category:

·         Solution is available

·         One or More solutions are available

·         No Solution available: Vendor may provide a solution.

·         No Solution available and the vendor can’t provide a solution.

Since this process is going to go back and forth between the technical teams, business teams and the users (project group), time is of the key element. An SAP suite of solution which has an intensely integrated applications, demands that the issues are raised, discussed and mitigated in time to avoid project slip overs. And also as against the blueprinting phase, here the solutions are tangible and options have to be finalized. I’d think of the following factors are important in this section:

·         Targeted sponsorship report and updated action plans (BRA): This will keep the focus on the people who need to take decision and to facilitate the escalation process to gain visibility.

·         Leadership Coaching: To make faster and effective decision

·         Critical Conversation: Involving all functional streams related to the issues.

• Communication during Realization: As I said, time is the key element as we develop technical solutions and start closing the issues. Since the ultimate approval or suggestions for improvement belongs to the business, a proper communication plan needs to be established and maintained. In my experience, I’ve taken the following steps:

·         Key Messages during Realization: This needs to be done as a periodic process. The team as a project group allocated a specific time to discuss the issues, follow ups and the options available. An issue owner is identified to take the issue to the closure.

·         Optimized FAQ Database and Feedback Loops: In my experience, Most of the issues will have a similar path to the resolution. This process is very critical, so that the focus is on the issue as a whole as against ‘bits and pieces’ of information.

·         Updated Communication Plan: As the realization process unfolds, proper adjustment to be made to the communication plan (This is a part of the best practices of project management)

·         Maintaining the Communication Plan

• Organizational Alignment: This part in specific to the technical solution pertains to the job roles for the end users and how the business functions are mapped in the system as transactions and approval process. As an overall technical solution lead in my current project implementation I’ve spent a great deal of work in this cross application area and consider the following key steps:

·         Organizational Impact Review

·         Job Role Impact Assessment

·         Organizational Alignment Strategy Update

·         Assessing Job Role Impacts

•  Project Team Change Management: This pertains to all forms of project phase and I think the following are the key components and I strongly believe in this as I’m as good as my team.

·         Effective Project Teams

·         Maintaining Project Team Efficiency

The areas of vulnerability are the scope creep that happens as a part of the technical solution. This happens predominantly, if the person or the team does not have a clear understanding of the business process or the understanding of the SAP’s solution architecture. The focus on enhancements that are not supported by SAP, pose a great risk of non-compliance and will affect the future upgrades. This I call it as unnecessary customization lead in to huge development component. The rational for this ‘WILL’ happen in most cases is:

Customization and development of all sort of add-ons to make SAP pleasing seems to be gratifying activity for analysts, developers and sometimes even users. However, first they cost, second, when all pros and cons are considered they often become liabilities to the project and in longer-term to the organization. I insist they should not be done whenever they can be avoided but still it comes easy to justify doing them. We need to take them under effective project governance. I’ve devised a four step principle to avoid it:

·         Adapt before build. First adopt SAP standard functionality wherever possible. Convince users to adapt: check if process can be tweaked if cannot adopt SAP functionality. If process cannot be tweaked are there any workarounds?

·         For any type of request that is not part of standard SAP, analyze the requirements first. Is it really required? Can we use standard SAP data element (note if this is a SAP standard field consider future usage of that data element). Just because it may not be used now does not mean it will never be used.

·         For reports, check standard reports to see if most of the requirements can be satisfied

·         In case of screen simplification, we either simplify the existing screens or if the function is simple (e.g. infotype maintenance) we can build from scratch. But we cannot apply the same to other complex transaction (e.g. PO or Sales order entry). In summary we do not reproduce SAP functionality.

Further to that these were translated in the change control process as:

·         Before considering a custom solution the functional analysts develops a thorough understanding of the requirement and validates it; checks standard solution, proposes alternatives or workarounds if standard solution is not available.

·         In case it is a showstopper – a critical requirement, the functional analyst defines the requirements for custom solution. The custom solution has to be completely defined in terms of why it is needed, what are the consequences of not developing the custom solution, any business implications around this.

·         The definition of the custom solution needs to be submitted to technical team lead who can then decide whether to conduct technical feasibility and estimation of effort and impact on development. The technical lead may decide not to develop the custom solution based on the priorities and workload and specifics of a request – then it will be the end of the procedure.

·         The technical lead forwards the definition of the custom solution along with the feasibility, resource, and impact summary to Project Technical Manager, who is authorized to issue a final negative decision.  Project Technical Manager will communicate the decision to the technical and business lead.