When researching the term change management, you will find that there are various forms, guiding principles and ways to go about it.
Depending upon who you speak to within your organization, you will more than likely get several different definitions of what exactly change management is and why it is important to the business. For instance, someone in human resources may see change management as the act of preparing people for change, as in helping them transition from one job role or function to another. Someone who is at the C-level might define change management as a process of continuous improvement or as a form of business transformation.
In the most general sense, change management is defined as an approach to transitioning individuals, teams and organizations to a desired future state. While this definition doesn't truly capture the type of change that we will be discussing in this e-book, it does touch on the fact that you need to follow a defined process in order for change management to be successful.
Regardless of whether you are an application owner, analyst, developer or database administrator, implementing a proper, proven change management process is the crucial first step, and it ensures the security, compliance and auditability of your key applications and data.
In the first chapter of this e-book, we'll focus on change management as a process your IT team undertakes in order to ensure that any modifications in code are properly migrated across your IT stack. Ultimately, the goal is to help you learn a planned approach to change management that enables you to maximize the benefits of your enterprise resource planning (ERP) applications and reduce the potential risks associated with ERP solution changes.
You'll discover:
While we quickly provided you with a definition of ERP change management, it's important to add that change management is more than simply ensuring modifications in code are properly migrated into your production environment.
Change management is well-defined, proven processes that, when automated, can empower your organization and enable you to properly align your IT objectives with those of your key stakeholders.
Whether you are introducing a new business process or adopting new corporate regulations, implementing changes in and around your ERP systems can be a scary undertaking since they aren't without their risks. And when these risks have the potential to disrupt your entire business and impact key systems such as finance or operations, it becomes even more critical to have a strong plan in place. That is why when managing change, following a proven, defined process is crucial in order to avoid service disruptions, delays or even knocking the systems you use to run your day-to-day business offline.
Layering that with the need to ensure the security, compliance and integrity of sensitive data and applications, it is important that while you are working under these tight controls to leverage an integrated and automated change solution rather than relying on manual processes and disparate management tools or activities to achieve these goals.
Even if your organization has an existing ERP system(s) in place — whether it's Oracle E-Business, PeopleSoft or some other platform — understanding the importance and need for effective, centralized and secure change management is important. However, some organizations are simply not willing to take the necessary and difficult steps to change the way they do things. It is this apprehension to change that often introduces risk into your business and results in secure information and applications being made vulnerable to breach.
Change is inevitable in any IT environment, especially when you have product upgrades and patches, and customizations that need to be applied in order to meet your business requirements.
That is why change management is often seen as a necessary evil since the process can be rather daunting, but when not properly followed, the result is even worse. However, many organizations still fail to proactively plan for change, that is, until something goes wrong.
By implementing an effective and systematic change management process, and following it to the letter, you are not only able to effectively account for the unexpected, you are also able to establish a strong chain of security throughout each step of the process — and properly enforce it.
For instance, as new change requests are made, the activities and workflows must be reviewed and approved before these changes are planned for and implemented, and it is this approval process that establishes the first link in the security chain. Ultimately, as you move through the various stages and work the change process, each step layers more controls and security, ensuring that only the right people have the right access at the right time. In the most basic sense, the change management process is defined by rules, and the security policies are the means by which these rules are enforced.
As with any process, the human element often introduces unknown variables that, if not properly monitored and audited, can affect the overall success of the project. To that end, your technical team members spend a significant amount of time applying patches and migrating changes from one environment to another. Subsequently, your team may be forced to take shortcuts or skip specific steps in the process in order to save time, money or meet service-level agreements (SLAs).
As harmless as this might seem, failing to follow the defined procedures and processes can lead to the introduction of human error. Investing in the right automated change management solutions can help you significantly reduce the potential impacts of human error during migration steps.
While your change management process may be well defined, it doesn't mean it's easy to follow. Manual processes for repetitive tasks can be automated to secure data, minimize downtime, reduce workload, eliminate human error and help to control soft costs. Moreover, automation frees skilled resources to focus on more valuable and fulfilling tasks, and such tasks as patching can improve the change process.
For example, there is a balance between effective use of resources and security. Because of security concerns, only a few of your people may be allowed to access the production servers. Restricting access is good practice, but can also place those few people on the critical path of the change process. Automation can eliminate the need for you to distribute passwords. However, it will still be necessary for you to monitor each patch's activity to identify when the source object for a custom object is modified. When customizations are present, it's even more critical to analyze how these changes are potentially impacting your environment. Automating the impact analysis process can ensure that customizations are not impacted/affected by these changes.
Adopting a sound change management process enables your organization to address the "necessary" while minimizing the "evil."
Failing to properly define roles and segregate duties within your production environment can result with critical data being overwritten, altered or left vulnerable to breach. Following the principle of the least privileged enables you to deliver a robust, role-based access control model that eliminates the need for privileged access and defines the role of developers, managers and other key personnel within your database and production environments, ensuring that they only have the necessary level of access to perform their job role or assigned tasks.
By properly defining roles and duties, you are able to meet control objectives and ensure that changes cannot be implemented within your production environment until all the necessary steps, approvals and strategic objectives have been met.
Best practices state that no change should be immediately introduced into a production system without giving the change due diligence in non-production systems. As each change evolves through the lifecycle, IT controls and security become tighter and enable you to demonstrate how they map to key business objectives. Ultimately, an effective change management process includes the following elements that affect efficiency of change through its lifecycle.
One of the biggest opportunity areas for realizing both improved productivity and faster adoption is automated code promotion and compilation processes. With the right promotion and generation tools, you can even implement compile checks to ensure that a program compiles error-free before it is moved into your production environment. At the same time, automated promotion and compilation processes are easier to both implement and enforce controls.
A rich body of theory is available on effective approaches to process management. Quality management (or total quality management) is part of this approach and says that if you adopt management principles for a process-based approach, you will be able to improve quality while also reducing cost. These principles provide a framework for defining a change management process and applying it to your organization. Ultimately, applying a robust, process-driven approach to change management within your ERP systems is very sound and makes sense from a security standpoint.
Consider this process as a system involving many people throughout the organization, each playing a different role in the flow of change through the process. Metrics can be defined to measure the quality of the process. Below are a few of the quality metrics that can be applied to all organizations:
Process control refers to controlling the process, not the people involved with the process. Control provides the means to which the process can be trusted. Process control includes several elements.
A process must allow staff to perform their job functions while preventing others from violating the process. Processes are defined by rules, and security policies are the means by which those rules are enforced. An effective process must allow security policies to be easily adapted to a changing workplace, especially as employees leave an organization and new ones are hired. It's important that your security policy evolve to incorporate new initiatives and skill sets that address your organization's changing needs.
The security policy must define who can apply patches and to which environments. It may be fine for certain users to apply a patch to a development environment to validate if a patch corrects an issue in production. A good security policy regulates these variables in order to enforce the chosen processes.
Workflow defines the lifecycle for change according to rules, activities and relationships that you set for your organization. A workflow is essential for patch management to ensure that issues are researched before a patch is applied and that every patch is fully tested.
A workflow for the patch process may begin with the identification of an issue. Activities may require the issue to be researched with collaboration from several team members depending on the nature of the issue. If a patch is identified as the solution, the workflow rules may require the patch to be applied to a development environment first so that you can certify that the patch addresses the issue without having adverse effects on other standard or customized application functionality.
Your policy for security and workflow should be complemented with a mechanism for approvals to authorize change, and approval activities can be included in your workflow. Change flowing through the process may reach several critical points that may require business-level approvals before continuing.
Versioning is essential for managing change to individual objects. When a change is introduced into your application environment, the original version of the modified objects should be retained in an object repository. Groups of objects can be labeled and associated with change requests, and older object versions can also be used to back out a change. If you have a larger development team, you may also need to support concurrent development of objects.
Security, workflow and approval controls do not prevent errors from occurring — and even the most well-designed change process is vulnerable to errors. Once you have identified an error, auditing can be very useful in isolating what events may have introduced the error. There are two types of auditing: auditing the change process and auditing the change.
Auditing the change process is concerned with the who, what, where, when and why. For example, when a security policy is changed, auditing shows you who changed the security policy. When a patch is applied, auditing shows you which patch, when it was applied, who applied the patch, who approved the patch, who tested the patch, which files were modified and so on. Auditing also alerts you when a customized object has been changed or when the original object used to create the custom object was changed.
In the most basic terms, this is issue tracking. There's a reason each patch was applied — either a bug was found or a new patch set was released. These reasons should be tracked from inception to postmortem for proper auditing of the change.
Achieve strategic alignment by automating workflows and migrations, applying business rules and gaining approvals before moving changes in code into production. Ultimately, automation of the change process enables you to demonstrate the value of ERP applications by reducing human error, increasing availability and improving the overall service delivery.
A change management process must account for planning of both the short-term and long-term demands of the change management process in order to forecast future changes, ensuring effective time management for organizational resources and so on. Patches can place substantial demands on the change process — significant resources are needed to deploy patches, and system downtime may be lengthy.
You can accommodate these demands with accurate planning. Best practices suggest planning for one major patch upgrade each year. This major event incorporates testing from all business units. However, additional budget must be allocated for periodic patching throughout the year to install hot fixes and accommodate changes in business requirements. Planning is critical to a successful change management process in both instances.
Reporting is critical for assessing the state of each environment. What's the difference between production, test and development? What will a patch do to a system before it is applied? How do testers know what to test when a patch is applied? What area of the business could be put at risk and to what extent?
Auditing data can be used to report the current, future and past state of an environment; activity that has affected the state; and the differences between two or more environments. It's common for a patch to affect files that may seem unrelated to the patch. Trying to determine what a patch will do to an environment before it is applied by manually inspecting the patch file is an approach fraught with inefficiency and prone to error.
The best approach to determining patch impact is to use a tool designed for that purpose. This will allow you to identify the affected files without modifying the environment. Other tools can be used to determine which database objects will be modified based on modified files. Although identifying the modified objects can be exceptionally tedious, especially for large patches, the risk of applying a patch blindly is typically greater.
Best practices provide methods for customizing objects without fear of a patch destroying these customizations. New custom objects are often created, so it is important to know if a changed object was customized or used to create a custom object. Customizing in this fashion prevents the customization from being destroyed by a patch, though other objects referenced by the custom object may change and break the custom object. Although these best practices are relatively easy to adopt, they are often not followed.
By not adopting best practices for customizing, each patch has the potential of destroying the customization. It is important to know if a changed object was customized or used to create a custom object. Performing patch impact analysis before applying the patch, even to a development environment, can reap rewards. Doing so enables developers, business analysts and QA teams to identify downstream objects which may be impacted prior to the patch, thus minimizing the impact to the stability of the development environment and not delaying other development or testing projects.
When a new issue is identified, an existing issue is closed or the status changes for an issue, people with a stake in the issue should be notified. When activities fail or do not get completed on time, people with a stake in the issue should be notified. For example, if a patch fails, systems may be left in a corrupt state and business functions may not be available. Therefore, communication is critical to alert your team when a patch is applied successfully or fails. The communication element identifies when and how these people are notified.
Managing change, technical performance, user productivity and access while ensuring the security of your business-critical data and applications is a tall order for even the most process-driven IT organizations.
Whether you are implementing customizations within your financial systems, addressing new business requirements or applying patches to correct defects or lapses in security, it's important that whatever solution you use to manage change provides the right level of automation, control and security to support the needs of your business.
Most upgrades take months to plan and take even longer to implement. Utilizing a comprehensive change management solution to track and control changes, version objects, automate migrations and patches, and report on activities can help you complete your upgrade project in a secure manner, on time and within budget.
With Stat from Quest®, you can manage all types of ERP applications, including Oracle E-Business Suite, PeopleSoft, and other packaged and legacy applications. Industry analysts have consistently recognized Stat as the leading solution for PeopleSoft. Stat for Oracle E-Business Suite leverages the same proven architecture and is currently the only solution on the market that has gone through Oracle's rigorous Validation Integration program. In fact, Stat is validated by Oracle for integration with both the Oracle E-Business Suite and PeopleSoft Enterprise solutions.
With Stat, access to virtually every feature is controlled through a security privilege. While every organization defines slightly different roles or privileged access based on resource availability and skill sets, Stat delivers security rights bundled into security groups for functional roles. Its security model allows organizations to define user classes that are given privileges to Stat features by assigning security rights or groups. Each user is assigned one or more user classes. This approach allows you to tailor Stat to address your security requirements and protect sensitive data.
Stat can help you master a planned approach to change management that enables you to maximize the benefits of your ERP applications and reduce the potential risks associated with ERP solution changes. Learn more at quest.com/ERPChangeManagement
Quest helps our customers reduce tedious administration tasks so they can focus on the innovation necessary for their businesses to grow. Quest® solutions are scalable, affordable and simple-to-use, and they deliver unmatched efficiency and productivity. Combined with Quest's invitation to the global community to be a part of its innovation, as well as our firm commitment to ensuring customer satisfaction, Quest will continue to accelerate the delivery of the most comprehensive solutions for Azure cloud management, SaaS, security, workforce mobility and data-driven insight.