Don't have an account yet? You can create one. As a registered user you have some advantages like theme manager, comments configuration and post comments with your name.
NOTE: ® ITIL is a registered trademark of OGC. This portal is totally independent and is in no way related to them. See our Feedback Page for more information.
Search
Languages
Select Interface Language:
Advertising
Please contact us via the feedback page to discuss advertising rates.
The Itil Community Forum: Forums
ITIL :: View topic - Question About Master Data Management
Posted: Wed Aug 16, 2006 4:14 pm Post subject: Question About Master Data Management
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?
Joined: Feb 28, 2006 Posts: 411 Location: Coventry, England
Posted: Wed Aug 16, 2006 5:23 pm Post subject:
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.
Joined: Aug 11, 2006 Posts: 262 Location: Netherlands
Posted: Wed Aug 16, 2006 5:36 pm Post subject:
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.
Joined: Sep 12, 2006 Posts: 6 Location: bayville new jersey usa
Posted: Wed Sep 13, 2006 3:57 am Post subject: Master data
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.
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
Joined: Jan 01, 2006 Posts: 500 Location: New Jersey
Posted: Sun Sep 17, 2006 6:55 am Post subject:
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]
Joined: Sep 16, 2006 Posts: 3589 Location: London, UK
Posted: Sun Sep 17, 2006 9:21 pm Post subject: Master Data
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
Joined: Jan 01, 2006 Posts: 500 Location: New Jersey
Posted: Mon Sep 18, 2006 12:48 am Post subject: Re: Master Data
Hello John,
Please see my response, below...
UKVIKING wrote:
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.
This really depends. The Ch Mgmt team can't scale to do the type of work you're describing in a larger enterprise. It's ok for them to do the work you're describing for smaller enterprises but it just won't scale as the enterprise grows.
We've dealt with very large enterprises where the scale of their internal and/or external environment(s), applications, systems, and infrastructure is immense. The Ch Mgmt team cannot possibly understand everything that goes on. Therefore, the best they can do is make sure that all the right stakeholders are involved in understanding and evaluating the change. In this case they are functioning "only" like the traffic/flow controllers and getting the right people involved to understand and make the right decisions.
They, themselves, cannot and should not be involved in the decisions but, rather, act as facilitators for it, since they cannot possibly understand the grander picture or the impacts to it. If a larger enterprise tries to rely on Ch Mgmt for decision making, it will fail under the weight of the scale, unless it gives up the decision making authority to the those that do understand the bigger picture/landscape.
I hope this helps.
Regards, _________________ [Edited by Admin to remove link]
Joined: Sep 16, 2006 Posts: 3589 Location: London, UK
Posted: Mon Sep 18, 2006 5:24 am Post subject:
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
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum