‍What is change management?

‍

Configurations in your Encompass LOS (or any highly configurable platform, like your CRM) should be treated just like code changes in custom software. The purpose of practices like Software Change Management (SCM), Software Development Life Cycle (SDLC), or Enterprise Change Management (ECM) are to protect your business and customers from the unintended consequences of change.

‍

If we rush changes into production we risk the very real possibility of errors, corrupted data, or even fraud. In the case of the Encompass LOS, this can result in originating unsellable loans, consumer complaints, or repurchases. It can also cause more subtle but still costly losses due to rework, delays and employee dissatisfaction.

‍

When considering agile methodologies, like SCRUM or LEAN remember agile does not mean chaotic. What you get from an agile process is a systematic means of responding to changing priorities. In a mortgage company environment, it is easy to chase the issue of the day, or a new product- avoid this temptation. Work in sprints, allocate a fixed portion of the sprint capacity to support, and do not make changes to the content of the sprint. Over time you will deliver more quality solutions and more value to the business than if you are constantly shifting priorities.

‍

At a high level, proper change management processes consist of methodical, repeatable, steps that are strictly followed. These steps usually include:

‍

• Discovery: Identifying the need for change by understanding the current state and recognizing potential improvements and challenges.
• Definition: Outlining the scope, objectives, and specific requirements of the change to align with the overall business strategy.
• Implementation: Executing the planned changes, allocating resources, and managing risks to achieve the desired transformation.
• Testing: Rigorously evaluating the changes to ensure they meet the requirements and function correctly without introducing new issues.
• Acceptance: Reviewing and formally approving the changes to confirm they meet the predefined criteria and business objectives.
• Documentation: Creating and updating essential documents to clearly record the changes and facilitate future reference and management.
• Deployment: Releasing the changes into the live environment, often involving careful planning and communication for a smooth transition.
• Support: Providing ongoing assistance, training, and resources to ensure users adapt well to the changes and any issues are addressed promptly.

‍

These steps are sequential, and should involve both business and technology resources, and should implement a clear separation of duties so that no one person can originate, implement and deploy a change without checks and balances.

‍

While this may seem like unnecessary overhead, think about the last time you had an avoidable prod issue. How many closings were delayed? How many locks were lost? How much friction was created between sales, ops and tech? These all equate to real costs and add-up quickly.

‍

How do I track changes in Encompass

‍

In the software development world change management is a well-worn path, and there are a variety of tools and best practices for teams to use. In the Encompass world it’s a little more murky. The smallest of organizations will send an email or ticket to the Encompass administrator who will implement and deploy the change (or make it directly in production). Other organizations will follow the best practice of adding a comment on a business rule each time it is changed.

‍

Done properly, you should have a written change management process that includes all of the steps listed above. You should also have a system for detailed tracking of that process; minimally, a queue in your helpdesk platform, ideally a full SCM platform like Jira and Bitbucket, Github, or Azure Devops.

‍

Prior to implementing the changes ensure that you have a copy of the existing configuration you can refer or revert back to. This is a must if you need to investigate an issue caused prior to a change or changes, or as a roll-back point if a deployment fails. Items involving code like Business Rules, DDM Rules or Custom Forms can be exported from Encompass and stored in a change control system. Other settings can be exported with the help of third-party tools like Biz Rule Analyzer, and the resulting report added to change control as well. It is also a good idea to use the practice mentioned above of using comments in your code to summarize all changes.

‍

What does an Encompass change process look like?

‍

Detailed discovery and definition documentation should be maintained current so that the solution as implemented matches the documented requirements. This can be accomplished by creating a detailed specification document or using a more brief user story with acceptance criteria format. 

‍

Your changes should be implemented in your dev environment. Then they should be peer reviewed and tested by another tech resource, and finally undergo rigorous user acceptance testing prior to being deployed to your production environment.

‍

Your dev environment will become messy with bad test data and in-process or abandoned changes that will invalidate your acceptance testing. It is highly recommended that, if you have the resources to support it, you request a third Encompass instance from Ice where you can maintain a proper configuration and conduct your UAT.

‍

Once UAT is complete and you have the approval to deploy to the production environment, you need to schedule your update and distribute release notes. Only then are you ready to touch the production environment.

‍

Once production has been deployed, your highest priority needs to be support of any issues that arise from your changes, and any time lost here needs to be factored into your future delivery commitments.

‍

For a free Encompass management consultation, please reach out below.

‍