Question About Master Data Management

[Norbert]

I have some questions about ITIL.

1.) Is a request for a master data change (which belongs to an IT application) a service request that is managed by incident management or is this a change request and should be managed by change management?

Thank you very much for your help.

Kind regards, Norbert

[Ed]

Hi Norbert

It could actually be in both depending on the circumstances.

If the data change is required to correct a fault, then it will relate to an Incident, but will always be a Change and therefore come under Change Management.

As a Change Manager, I cannot think of any scenario where this would not be a Change.

Hope this helps

Regards

Ed

[m_croon]

I think that theoretically, it could be a service request (inc. mgt). The actions to take for the execution of this change could very well be standardized. However, the risk of such a mutation (master data) is so high, that you ought to adress this in your CAB.

[Lola]

It would definately be considered a change in our environment.

[CarlMattocks]

An update to a data structure should be recorded by change management. The need for change may originate with an incident that gets recognized as a problem or via a service request for new capability.

[Fabien]

This is a change without a doubt. However, it is the way your organization decides to handle this sort of change that is going to make it go through the Service Desk or not.

There is a number of parameters that you should probably consider:

- Does the Service Desk usually accept RFC's in your organization? If yes, that is probably where the process should start for IT.
- What is the expectation of the business? What is your charging model?
- Can you model that sort of change to help the Change Manager in processing it in the most efficient way? Do you have defined the proper CAB for this sort of change?
- Is it the sort of change that happens on a regular basis?
- If yes: Is it a defined & repeatable process? Is IT offering a specific response time? Should it be a standard change?

... I'm obviously not done but this gives you an idea of the sort of questions that I would looking at...
_________________
BR,
Fabien Papleux

Accenture
Technology Consulting | Service Excellence
Red Badge Certified

Twitter @itilgeek

[UKVIKING]

I have to say the following

It depends.

Is this configuration data or merely transitory content data.

If this data is configuration data, then yes then it is a Change

If the data is merely content, unless there is a content management change process, then it not a change

John hardesty

[Guerino1]

Hello All,

I will have to agree with John and say that it only results in a Change request if it will yield a configuration change AND it doesn't fall into some form of a sanctioned Change that can go through untracked and unapproved.

Regards,
_________________
[Edited by Admin to remove link]

[UKVIKING]

Thanks, Frank for the agreement

I would like to follow up that with the following

The other criteria to whether the work is a change is how drilled down and micro-focus the Change Management process is at the organization.

For Example, in Voice Application, certain things are configurable such as the menu choice and the wording of such.

These can be changed every 5 minutes by a competent engineer. Does teh engineer need to write and wait for the CM process to be gone through before the simple script change can be done? The answer is .. it depends.

If the group managing the script changes have some sort of work request which is auditable, trackable and identifiable & communicated, then the CM process would be superfluous and hinder the operations.

Like my first year accountancy course, dont spend a $1.00 to chase $0.01.

Now if there was NO process for the script change, then there should be some involvement of Change Management process - the lowest level of Change - Standard and Normal changes - would apply. The engineer would merely record that he was doing X. The change qwould get auto-approved because the work is repeatable and all issues are known and there is no need for a CAB review.

Frank had it half right in one of his comments - Change Management is like the Air Traffic Controller - CM is controlling the flow of the work.

The other thing that the prime focus of CM is make sure the change impacts the service the least and the service's users know how impacted the work will cause the service when it is implemented.
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter

[Guerino1]

Hello John,

Please see my response, below...

[UKVIKING]

Frank

I must disagree

As part of the approval phase of a change request, the approval & scheduling of the Change takes into account the impact of the change during specific times of the day/week.

The Change Teams I deal with have to take into account WHEN the change must be done.

For Example

Telco work on circuits should be done when the traffic is the least.
Switch and Router Upgrades should be done when the traffic is the least even if the routers are in pairs.
System and Application upgrades should be done when the use of the system and the application is the least.

A good change team, processes and procedure set even with the rudimentary tools can help limit the impact to the customer/user/service

This happens in the company I work for and it is a very large TELCO in the UK. It happens specifically in the departments I am the Change Manager for. We provide various services not only to internal customers but external as well

This is because senior mgmt has learned by major faults and embarassing outages that the concept - P Hex - always is the best.

In addition, if a Change Management process and procedures can not be scalable, then the process is fundamentally flawed and it is not designed/implemented with ITIL in mind.

The only issue is however, whether the senior mgmt and the operational mgmt understand that the services that they provide to the customers need to be managed and monitor so that the customer gets what they are suppose to have.

Things like Forward Schedule of Change (FSC) & Projected Service availability (PSA) which should come out of the Change Advisory Board on a regular basis would provide the customers/users with the data details about impacts to the services provided. In addition, customer relationship staff such as account teams and service managers should be a recipient of the FSC and PSA so that pertinent information should go to the customer. Conversely, the SM & AM staff should provide the Service Desk and the Change Team with customer critical phases and freezes.

But that would take time and the Change Mgmt team needs to have processes and procedures for things like Change Freezes, Regular Scheduled Patching for Security, Emergency Patching against exploits, standard maintenance windows.

They may not control these but they need to be involved.

The Change Team also does NOT need to know everything that is going on. That is why the CAB should consist of the CM and key players in the business.

Frank. A properly devised and implemented Service Support environment (Change Mangement) would mean that the regularly scheduled CABs would have representation from all the key Operational, Implementation and Service Level MGMT group. This is key to making sure that chaneg management works.

But... if the tool that is being used to manage change is merely used to replace the CAB for critical changes like SQL Slammer patch, Cisco IOS vulnerability, Microsoft monthly security patching; then the company merely has a tool which has replaced people.

A good ITIL oriented tool for Change Management should help the Change Team - not hurt or impede.

P Hex - Prior planning prevents piss poor performance
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter