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: MaluHari
New Today: 14
New Yesterday: 141
Overall: 131705

People Online:
Visitors: 55
Members: 2
Total: 57 .

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 - Application maintenance - in scope of CM
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Application maintenance - in scope of CM

 
Post new topic   Reply to topic    ITIL Forum Index -> Change Management
View previous topic :: View next topic  
Author Message
ThomasPiwniuk
Newbie
Newbie


Joined: Jan 04, 2010
Posts: 2

PostPosted: Mon Jan 04, 2010 10:11 pm    Post subject: Application maintenance - in scope of CM Reply with quote

6 months ago we have reviewed our Change Management process and the bottom line is - works fine. It is accepted (in general, there are some black sheep, as always) and followed.
But I have a problem with a "grey area" of application configuration / maintenance.
When do I start tracking changes to application done by build-in admin panels? Do I at all?
Let's say - change of document category in document management system – is that a change?
or change of company’s logo in screensavers - change?
or new object type in company's information system - change?
All those are done with use of application build-in functionalities. But they may have impact on users (usually, they are initiated by users).
Where do you draw a border in such cases?
Back to top
View user's profile
UKVIKING
Senior Itiler


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

PostPosted: Mon Jan 04, 2010 11:21 pm    Post subject: Reply with quote

The short answer is IT Depends

What does your change management policy say
how does the work get done
how is the work tracked
what is the 'amount ' of work needed to track via change as opposed to business process

lets take your issues / concerns and expand a question set

changes to application done by build-in admin panels?

Who can do this ? Every one or a chosen few ? Is this tracked somewhere ? What is being changed - code, data or configuration ? is this to reflect changes in business processes or such like ?

If the work can be done from the front office and the role / user base is limited to a few and it is done by a select few people..., then you haev to decide is the work being tracked anyway ?

change of document category in document management system – is that a change?

This is a change - it is a DMS process change, a business workflow change, etc. etc.. What is the impact of changing the category.. is there some sort of DMS admin team who makes / controls this or is this down / can this be done by on and all

change of company’s logo in screensavers - change

This is a change. This is usually required a script at the group policy level that must be tested and tried out. It is a change for me. The first 4 times it is done, the board has it tested and approved before deployment.. once it has been done successfully for 4 months, the board determines that it meets the policy description for a standard change. the crs are still raised but w/o board approval the work is done

object type in company's information system

This one stumps me ? If this is configuration mgmt defintions then this is actually part config and part change. this should be handled via the admin activities for config
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter
Back to top
View user's profile
ThomasPiwniuk
Newbie
Newbie


Joined: Jan 04, 2010
Posts: 2

PostPosted: Tue Jan 05, 2010 11:27 pm    Post subject: Reply with quote

First for all, thanks for quick, detailed answer.

The pre-approved changes in my organisation are defined as:
- low risk
- well known, proven tasks
- can be processed without delay, when authorised

We do have defined, closed list of pre-approved changes:
- action (i.e. change)
- authorisation,
- processing team,
- docks to be updated
- parties to be informed

E.g. new net folder? Department Mngr authorise, Back Office does, no doc to update. CM is not even notified.
new standard workstation? Again respective Department Mng to authorise, Client Computing to install. CMDB to be updated, CM to be informed.

The list of activities were constructed basing on surveys, experience and log of requests from our Incident and Request System, works well.

Everything else has to go thought Change Management and usually does. Fortunately, I don't have real "no-no bureaucracy, I renounce this stupid stupidness!", outstretched jumpers, IT geeks here.

Problems might arise only when the area is not precisied very accurately or there is a doubt regarding granulity of RFC (we don't go to single CI level). As for level of detail we have general guidance: set of coherent tasks, done by one specialist or one team, all at once or in short period of time. E.g. re-conig of FW to enable new service: we don't track single config lines, specific IPs to be changed, ports to be open. We'd rather record something like "enable SMPT routing for network XXX”.

Regarding configuration in question, its always done by one or max up to three specialists (depends upon shift / who is on duty). Changes done are "process steering changes" like change of DMS workflow or redirection of network traffic or update of standard workstation image or services to monitor list and livemap.

What I came up after consideration is a rule: "RFC for every config change affecting end users. RFC for every change requiring net design documentation or procedure update. RFC for every change requiring more than 2 hours of workload or cooperation of two or more teams." Of course every code or data change (well, we never change data manually).

But maybe is there more generic guidance, I could base on? Or best practice? Like categorisation of configuration activities and leads how approach them in context of CM?
Back to top
View user's profile
UKVIKING
Senior Itiler


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

PostPosted: Wed Jan 06, 2010 12:22 am    Post subject: Reply with quote

ITIL is best practice but it is up to your Change Mgmt policy on what is the scope for CM for your area.


For example: I dont deal with the help desk and the users in the company for change issues. such as new accounts, password changes (DONT START ANYONE), desktop o/s patching and application installs and patching. The main reason is that there is already a defined process within the service desk - (incident / service request)

the other thing I would note is that the Change Board /Manager determines whether there are new additions to the standard changes (approval not required)

Also, if it is fuzzy and 3 people say change and 3 people say not change board or approval .... bring it to cab a few times - if it works once without errors, then say - this is now a standard change. Clears the cobwebs

The key is making sure the right level of changes get to the right level of mgmt and the right level of information is available to those who need it
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter
Back to top
View user's profile
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> Change Management 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.