Search
Topics
  Create an account Home  ·  Topics  ·  Downloads  ·  Your Account  ·  Submit News  ·  Top 10  
Modules
· Home
· Content
· FAQ
· Feedback
· Forums
· Search
· Statistics
· Surveys
· Top
· Topics
· Web Links
· Your_Account

Current Membership

Latest: KFKF
New Today: 131
New Yesterday: 202
Overall: 130695

People Online:
Visitors: 58
Members: 7
Total: 65 .

Languages
Select Interface Language:


Major ITIL Portals
For general information and resources, ITIL and ITSM World is the most well known for both ITIL and ITIL Books. A shorter snapshot approach can be found at ITIL Zone

Related Resources
Service related resources
Service Level Agreement
Outsourcing

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.


The Itil Community Forum: Forums

ITIL :: View topic - How to classify & then handle request for DATA change
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

How to classify & then handle request for DATA change

 
Post new topic   Reply to topic    ITIL Forum Index -> ITIL Discussion
View previous topic :: View next topic  
Author Message
psychstorm
Newbie
Newbie


Joined: May 03, 2007
Posts: 7

PostPosted: Fri May 04, 2007 1:08 am    Post subject: How to classify & then handle request for DATA change Reply with quote

Hi Guys & Gals,
I have a dilemma which I hope you can help with.

I'm having problems with categorising requests for DATA change. Example. Bob rings up and says my salary is wrong in my HR personal page.

Question, is that an incident? or is this a request for change ? (and therefore requires RFC or is under Change management, maybe standard change?) Because its a change to DATA (or in affect an attribute) is it really a change ? Its not really an incident because its not preventing the user from working.....and its not a request for a new service

If its a request for change, is a RFC raised and the incident closed immediately? (thinking metrics)

If its an incident then I'd say the incident has to stay open whilst the data is wrong. so if there is a weekly batch run to fix figures, then this incident must stay open until that is done to reflect the time it takes to fix.

In terms of process flow would you:
Open incident, raise RFC, close incident and wait for RFC to do the change
OR
Open incident, raise RFC, wait for data to be fixed, then close incident

Would love to hear your experiences with this...
Thank you !
SS
Back to top
View user's profile
jpgilles
Senior Itiler


Joined: Mar 29, 2007
Posts: 123
Location: FRance

PostPosted: Fri May 04, 2007 1:51 am    Post subject: Reply with quote

As I suppose, the DATA are not CI's in your CMDB, I would say this is NOT a change (theorical point of view)

And sincerely, this should never be considered as a change, otherwise you would need to request all your users to enter a RFC everytime they need to change data (order entry, invoicing) ...that would lead to almost double the user population...not sure that would be well perceived....(practical point of view)....
To elaborate more on this (not really needed but just for fun): IT is responsible for the systems and the services that facilitate and support thoses systems , but IT is not and will never be responsible for the DATA business users can put/delete/modify IN the systems...

That leads to another important point that becomes obvious at this stage: the Owner of the data sits in the business community . Which needs to be seriously considered in terms of security management : e.g. who authorizes to access Production Data in write mode???? (if you still work that way)...that should not lie in the IT dpt...

Now I am wondering why such requests (changing data) would come to IT and not be executed directly by the users....
_________________
JP Gilles
Back to top
View user's profile Send e-mail
psychstorm
Newbie
Newbie


Joined: May 03, 2007
Posts: 7

PostPosted: Fri May 04, 2007 3:49 am    Post subject: Reply with quote

Hi JPGgilles,
Thank you for your response. Basically very complicated situation, the people are not strictly IT, but a dept within a dept who look after confidential data etc. However we'd like a way to measure what they’re working on and also decide how to accommodate such requests in the SLA (so they don't murky the waters in the sense of traditional "incidents")
It also left me thinking how it would affect metrics etc.

I'm sure there are people out there who do this, so I'm hoping to get some good ideas / explanations of how you guys deal with this type of issue.

As for why the users don't do it yet, self-service is not fully implemented, but planned.

Thanks again !
Back to top
View user's profile
Ed
Senior Itiler


Joined: Feb 28, 2006
Posts: 411
Location: Coventry, England

PostPosted: Fri May 04, 2007 4:54 pm    Post subject: Reply with quote

Hi psychstorm

This, as JP rightly says, is not a Change. It is using the system as it was designed.

The fact that the data was incorrectly entered, does not affect any of your CIs. You cannot militate for every stumble-fingered user.

The metrics needed to control such people has to come from within their own department. Smile

I would expect that this system allows for correction of erroneous data, if only by paying your salary + a misc payment to cover this month's shortfall (real world thinking).

This is not, to my mind, an incident

Regards

Ed
Back to top
View user's profile
psychstorm
Newbie
Newbie


Joined: May 03, 2007
Posts: 7

PostPosted: Fri May 04, 2007 8:48 pm    Post subject: Reply with quote

Thanks Ed
Back to top
View user's profile
Guerino1
Senior Itiler


Joined: Jan 01, 2006
Posts: 500
Location: New Jersey

PostPosted: Sun May 06, 2007 12:43 am    Post subject: Reply with quote

Hello Psychstorm,

The situation that you've described is definitely an Incident, specifically because there is a disruption in expected behavior of a system/service. So, classifying it as an Incident is not wrong. It's how you address the Incident that takes the next step...

In most companies, such a situation is handled one of two ways. However, before I get into it, please let me highlight that the control of data/content in such a way is typically referred to as "Content Management", which is the discipline and set of processes that enterprises use to control their content. Obviously, this is another critical area that an enterprise needs to run itself that ITIL doesn't cover properly, at all.

Anyhow, here are the two approaches to addressing such an issue:

1) An Employee Self Serve solution (where the employee can log in and change that data him/herself). In this case, the employee is entitled, by the Product/Service owner to log in, in a controlled manager, and make pre-approved content changes that are dictated by role based entitlements, which are programmed into the Product/Service, itself. In such a case, the Employee Self Serve module of the HR system is, in a sense, controlling "Pre-Approved Changes", that can be made by specific people and/or roles in the enterprise. It is up to the system to keep audit logs of who logged in, when they did, what they did, etc. This is very common in many systems and is extremely important for customer satisfaction, as many customers don't want to go through a Service Desk to get things done and want "On-Demand" facilities to get things done (the consequenses of living in an on-line and on-demand society).

2) In the second approach, a Service Request is spawned to invoke a Service that will change the data. (Note, if you're about to give me grief that a Service Request is an Incident, don't bother. ITIL v3 broke them out as distinct and separate entities and it gets released this month.) So, in this second case, someone calls the Service Desk asking for a data change. If the existing data is wrong, an Incident gets logged to track the unexpected behavior. Whether the data is right or wrong, the data change request yields a Service Request for someone to change the data in the system through a pre-approved Service. The reason it is a Service Request is because it is most likely a highly repeatable and controlled Service that gets invoked regularly by many different people for many different reasons. The Service Request gets assigned to the appropriate Resource and/or Organization that will execute it. Upon completion and signoff, the Service Request is closed and then the Incident is closed. Done correctly this process allows you and your enterprise to cleanly track, both, the fact that the original data was wrong, when it was expected to be otherwise (a bad data Incident) and track the controlled process that gets executed to fix the wrong data (a Service Request).

It's very important to understand that the Service Desk can't possibly do it all. A Service Catalog, that gets loaded with "traditional" Services (those that get invoked, on-demand, and which have an SLA for concrete delivery of solid deliverables) allows the Service Desk, as well as anyone in the enterprise to go directly to the Service Catalog, look up a Service, and invoke a controlled Service Request that gets routed directly to the Service Provider (a Resource and/or Organization) who is accountable for executing the Service, keeping status in the Service Request, delivering the deliverables, and ultimately closing the Service Request. In this fashion, an enterprise can now control, track, and manage all Services and all work requests (Service Requests) against those Services. The statistics and metrics that get collected from doing so are very impressive once you put this in place, as you get a complete break down of Service Requests:

- by Requesting Resources
- by Requesting Organizations
- by Requesting Locations (i.e. Regions, Facilities, etc.)
- by Service Provider Resources
- by Service Prodider Organizations
- by each Service in the Service Catalog
- Etc.

The beauty is you get to see a highly controlled flow of work and the labor against that work, as it gets invoked and executed. ITIL v2 was very weak in this area. In v3, ITIL finally got the point and broke Service Requests out from Incidents, since asking for a Service to be performed doesn't necessarily translate to something not acting the way it's supposed to (i.e. an Incident).

Anyhow, I certainly hope this helps.

My Best,

Frank Guerino, CEO
TraverseIT
On-Demand ITIL
Back to top
View user's profile Send e-mail Visit poster's website
UKVIKING
Senior Itiler


Joined: Sep 16, 2006
Posts: 3251
Location: London, UK

PostPosted: Sun May 06, 2007 2:45 am    Post subject: Reply with quote

To be honest, why would someone call the IT help desk if the HR data is in error.

Should this not be handled via the HP / Manager personnel process

That being said, if the IT service desk is the organization helpdesk then, yes it is an incident

However, in the environment I am currently working, the applications that they use - custom in house and modified purchased some times scramble the data or the data is not quite right

The company and I agree has used Chage Management as an audit / control mechanism to do backend data changes through scripts rather than the front end.

Primarily because the data is 'sensitive' both in the personal and financial area.

While no CIs are changed, the work - not a normal IS housekeeping work - does have significant risk and impact to the business; ....

and the business does not really have any version control software for the data...

So if the data change is from the back end... change is involved.. from the front end - where there is auidt and control nope
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter
Back to top
View user's profile
Guerino1
Senior Itiler


Joined: Jan 01, 2006
Posts: 500
Location: New Jersey

PostPosted: Sun May 06, 2007 1:56 pm    Post subject: Reply with quote

Hello John,

Comments embedded, below...

UKVIKING wrote:
To be honest, why would someone call the IT help desk if the HR data is in error.


It is quite common for the HR systems like any other business or IT systems to be managed as Services, for which the Service Desk will handle Level 1 calls.

Quote:
Should this not be handled via the HP / Manager personnel process


That organization and it's processes might be invoked either through Level 2+ Incident Escalation (for Incident resolution) or through Service Requests, for controlled and repeatable work.

That being said, if the IT service desk is the organization helpdesk then, yes it is an incident

Quote:
However, in the environment I am currently working, the applications that they use - custom in house and modified purchased some times scramble the data or the data is not quite right

The company and I agree has used Chage Management as an audit / control mechanism to do backend data changes through scripts rather than the front end.

Primarily because the data is 'sensitive' both in the personal and financial area.

While no CIs are changed, the work - not a normal IS housekeeping work - does have significant risk and impact to the business; ....

and the business does not really have any version control software for the data...

So if the data change is from the back end... change is involved.. from the front end - where there is auidt and control nope


I agree. I think it's fair to say that the complexity of the Change and its impact to the enterprise might dictate wether or not an enterprise will want to put in and track formal RFCs or whether it's adequate to control those Changes through simple and pre-approved Service Requests.

My Best,

Frank Guerino, CEO
TraverseIT
On-Demand ITIL
Back to top
View user's profile Send e-mail Visit poster's website
psychstorm
Newbie
Newbie


Joined: May 03, 2007
Posts: 7

PostPosted: Mon May 07, 2007 2:02 am    Post subject: Reply with quote

Frank, Thank you for taking the time to answer the question in such depth. It has helped a lot.

John, also thank you for your reply.

Off to find some ITIL v3 books, sounds like some interesting changes....
Back to top
View user's profile
Cekir
Itiler


Joined: Jan 12, 2007
Posts: 48
Location: Warsaw, Poland

PostPosted: Mon May 07, 2007 6:52 pm    Post subject: Reply with quote

UKVIKING wrote:
To be honest, why would someone call the IT help desk if the HR data is in error.


Let us have a poor written software the customer insist on using. The software makes it very likely to make a mistake while using because of very bad GUI. The software provides neither UNDO command nor the track of changes.
The customer agrees to pay for data fixes so that they are tracked by the service desk. The data change for this software is then included in the Service Catalogue and every time the user makes mistake, they call the Service Desk and initiates the Service Request.

Guerino1 wrote:
The situation that you've described is definitely an Incident

Frank,
Do you mean that in ITIL v2 it is an Incident and in ITIL v3 it is a Service Request?[/quote]
_________________
Krzysztof (Chris) Baczkiewicz
IT Standards Support
Eracent
Back to top
View user's profile Send e-mail Visit poster's website
psychstorm
Newbie
Newbie


Joined: May 03, 2007
Posts: 7

PostPosted: Mon May 07, 2007 9:21 pm    Post subject: Reply with quote

Hi Cekir,
Yes very similar to the scenario you just described....

I think I'm comfortable with the options presented here in order to prepare something which is going to be both useful and not too bureaucratic.

Thanks everyone !!
Back to top
View user's profile
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> ITIL Discussion All times are GMT + 10 Hours
Page 1 of 1

 
Jump to:  
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

Powered by phpBB 2.0.8 © 2001 phpBB Group
phpBB port v2.1 based on Tom Nitzschner's phpbb2.0.6 upgraded to phpBB 2.0.4 standalone was developed and tested by:
ArtificialIntel, ChatServ, mikem,
sixonetonoffun and Paul Laudanski (aka Zhen-Xjell).

Version 2.1 by Nuke Cops © 2003 http://www.nukecops.com

Forums ©

 

Logos/trademarks property of respective owner. Comments property of poster. Rest © 2004 Itil Community for Service Management & Foundation Certification. SV
Site source copyright (c)2003, and is Free Software under the GNU / GPL licence. All Rights Are Reserved.