OK moving on now let's understand what all the key stages of change management the Key Stages of Change
Management are actually mapped to two key groups of people the business team and the technology team.
And for a successful change management they should follow the simple four step process step one collect
ideas and requests from users.
So when we talk about request musically it can be of any form.
It can be major business initiatives.
It can be minor business changes or even system defects or bugs or performance enhancements.
Basically of any form the request can be of any form.
So step one is all about collecting ideas and requests from users.
Step two step two is analyzing and prioritizing a request.
So now that we have collected on the request we got to prioritize them.
We got to analyze them so that there is a balance and they use it an option that is a balance in the
innovation that is a balance in the new functionality.
You have to maintain a balance between all these by analyzing and prioritizing the requests that you
go live as part of that particular release.
Step three configuring and developing enhancements.
This is where we actually do the development of the release management.
And in the forthcoming sessions we'll be discussing about the various tools that we'll be using for
that.
And finally step foot training and communicating to the users after a day of release we actually do
this as a part of the policy release activities.
We train the users we communicate all the enhancements that we have made to the application so that
they can make the best use of it.
So the four simple forced a process for successful change management.
Well let's understand each of the steps in detail step one collecting ideas and request from users.
Actually every project every business has their own ways their own methods of collecting the ideas and
request from the users.
Some projects they use.
The chatter group they create a public group then and users can post ideas which they use as a means
for collecting the request in some projects.
They use samples ideas when they can pull the idea and they can old for that particular idea and depending
on all the big request and in some projects the user the case object the case object within you can
raise a case and all those cases will be accumulated in the backlog and then like you work on the backlog
you analyze you prioritize the requisite A-Z in the backlog and then like you work on that.
So there are different methods different approach that we use in different business for collecting the
request from the users.
And step two we know analyzing and prioritizing request as we discussed earlier.
Every project has got their own ways they own means of collecting the request.
Okay.
So now that we have collected all the requests to all the requests out there in the backlog.
So how do we analyze them.
How do we prioritize the request.
Given this is a very very key process in change management because you got to analyze you got to prioritize
the request and see which has to go first in which you're relieved that you are working on or in the
forthcoming release.
So be child request has to be put together for a particular release.
So this step completely talks about how do we analyze the request that we have and how do we prioritize
them.
So we prioritize a request based on the overall business goals and strategy and who defines these business
goals the business stakeholders they define the business goals.
All right.
So we know what are the business goals and we prioritize the request based on the business goals and
we prioritize the request in such a way that he does high outline driven means the return investment
is high.
So depending on that to be prioritize the request.
But definitely yes we do need to have a small amount of budget for minor enhancements as well because
in many times what are you in these minus changes makes or gives a very big impact to the end users
let's say for example are they want a particular business process that will be changed in a particular
way so that it can consume more it can take away most of their manually offload or for whatever reason.
So even these minor changes they makes very good business impact.
So for as part of this change management we need to have some space have some budget for those minor
announcements last week.
And once we are done with this analyzing and prioritizing the request then we go to configure and develop
the enhancements.
And this is where we actually do the development for the particular release management solely in real
time when we actually work on these changes when we actually work on the request we do either daily
releases we do minor releases and we do major releases.
So what are these daily releases.
As long as it stays daily releases or definitely these are the minor changes that we work on it might
be some bug fixes or it might be some minor business configuration that do like a second off.
One report that you add are some dashboard that you do all these like it falls under the daily releases
but then like even if it's a daily release we just go to definitely ensure that the end users are communicated
about the change.
It might be even just a simple mail sufficient.
But then we just got to ensure that the end users that communicated on those changes in the releases
these miners releases are kind of new business functionality that we implement and agenda leave target
these minor releases a monthly and we definitely go to the levels of some testing for these minor releases
because it is new functionality that is implemented.
So we just got to ensure that it does not confuse thing with any one off the existing functionality.
So definitely we gotta concentrate on testing when we do minor releases and major releases major releases
are major business initiatives that you implement and sales force and agenda leave these major releases.
They have a major impact on the application.
So we target them on a quarterly basis like a four times in a year.
And they're definitely like as it is major release we got to do.
We got to spend significant amount of time in testing and definitely training is very very essential
for major release and generally for major release it is kind of a classroom training when and like you
bring in all the end users you bring in like all the business units which are related to that and then
give a training of a classroom training letting them know that the Manute business initiated that we
have taken and how you have implemented that and Salesforce they'll be the release is a daily release
or a minor release or a major release.
The development process remains the same.
And this development process that you'll see is very much aligned to the normal standard software development
process that we have we established that any change in the development environment and then like we
moved to the integration environment where and like you check with all the integration points that you
have in the organization.
And then finally the 280 in LatAm into get in the end deals as also do their testing.
And finally after it's tested after it walks fine like after it leaders signed off by all the stakeholders
then finally move the change to production and all these law environments that is development integration
and unity.
These are all sandboxes.
And finally does move to production and that these sandboxes either they can be a full day enough and
what's generally the UAE is a full data sandbox and the development environment and the integration
environment think it can be a developer sandbox and develop a pro sandbox and it is totally up to the
business.
It is totally up to the business to design on Lake which kind of a sandbox they want for which environment
but then the overall development process remains the same.
Beta minor release our major release on a daily release.
The process remains the same.
Any change say for example you create a report flustered in the development environment and the like
move it to integration environment and we'll be do you ready to move into production finally.
But these environments like it is you just kind of the generalized terms that I have put on here that
is a development indication you 80 in the force basically from project to project some project positivity
some project clauses staging some project closet pre pride is totally up to the business up of the project
and for this process of development and deployment we'll be using various tools and in the forthcoming
elections we'll discuss about the various tools that we'll be using for deployment of data from development
to integration integration to UAB you Eddie to production say for example like you create a workflow
rule in development environment how would you deploy the metadata from Def to integration how would
you deploy the metadata from integration do you really.
So there are multiple tools that we can use and Salesforce for deployment of metadata and in the forthcoming
sessions we'll be discussing in detail about each of the tool and how do we use those tools for migrating
the meditator.
And the final step is training and communication be the daily release Beta minor release Beta major
release communicating to the end users communicating to the respective business units and the stakeholders
is very very essential.
Say for example it's a daily release that leads like we go to send an email communication as simple
as that to let the users know of the change that you have basically made with the main daily release
and for minor releases you definitely go to document the changes you go to document which are all the
business you want it to be should all the stakeholders will be affected by that and for a major release.
As we discussed earlier definitely we ve got to have some sort of classroom training that in a you in
white all the business units all the stakeholders all the end users what related to that and explain
them about the major release that you explain them about the business impact that you have done using
the changes that you have made in sales force.