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: JJuarez
New Today: 44
New Yesterday: 85
Overall: 141568

People Online:
Visitors: 49
Members: 3
Total: 52 .

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 - Standard application functionality CM or Not
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Standard application functionality CM or Not

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


Joined: Dec 01, 2006
Posts: 4
Location: Colorado

PostPosted: Fri Aug 17, 2007 7:44 am    Post subject: Standard application functionality CM or Not Reply with quote

We are using Oracle ERP and want to change the restriction on passwords from 6 characters to 8 characters. This will be done through standard functionality within the application.

Can anyone tell me if they consider this a candidate for the CM process?

It seems that we are taking CM a little to far when we start reaching into application provided functionality.
Back to top
View user's profile
dboylan
Senior Itiler


Joined: Jan 03, 2007
Posts: 189
Location: Redmond, WA

PostPosted: Fri Aug 17, 2007 11:01 am    Post subject: Reply with quote

It sounds like you talking about making a change that will affect both written organizational Policies and affect training documentation. If this is the case, and you have version controlled your documents, then yes. You are in fact making a change that will affect the Attributes of items that should be considered Configuration Items.

I say "should be" because I don't know how mature your Configuration Management process is. But even if your Config process is non-existent, you should think in terms of "Would this change affect hardware, software, or associated documentation that should be kept in a controlled state?"
Back to top
View user's profile
Worac
Newbie
Newbie


Joined: Dec 01, 2006
Posts: 4
Location: Colorado

PostPosted: Sat Aug 18, 2007 1:24 am    Post subject: Reply with quote

dboylan,

Interesting perspective that I had frankly not considered. I was looking at it more from the point of view of where do you draw the line when using standard functionality within an application.

I am now thinking that any configuration/setup change that might change the way an application works or how the user interacts with the application might be a candidate. Like you indicated, this would also potentially change the policies and training documentation as well.

Thanks for the feedback.
Back to top
View user's profile
UKVIKING
Senior Itiler


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

PostPosted: Tue Aug 21, 2007 12:44 am    Post subject: Reply with quote

Worac

Also,

think this way as well

1 - Development environment - loose to no configuration or change from an operational POV. Version & revision control applies to code and packages

2 - UAT / Testing Environment - Medium control from a operational environment. You want tto have the UAT & Live environment as == as possible.

So Configuration of the h/w & version of the S/w are kept. and changes to the environment are controlled.

Version and revision code kept.

This is where you write the documentation and test the documentation against the application....

3 - Live - tight control. Push to live for application and documentation in parallel. May have a staggered roll out / training etc...
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

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


Joined: Dec 01, 2006
Posts: 4
Location: Colorado

PostPosted: Thu Aug 23, 2007 8:16 am    Post subject: Reply with quote

UKVIKING,

Thanks for your comments as well. We have restled with having to create RFC's for changes to a Dev instance. We have a fear of never getting any work done if we guard it too tightly.
Back to top
View user's profile
UKVIKING
Senior Itiler


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

PostPosted: Thu Aug 23, 2007 6:50 pm    Post subject: Reply with quote

Womac

There should be a live change control when there are systems added to any environment.
Or O/S or other S/W upgrades and patches.

If you track Databases as CI that are 'permanent' and are created outside of dev tools, then track via change.

If in dev you use some sort of version control, that is your change tool for your work....
_________________
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: Mon Aug 27, 2007 4:59 am    Post subject: Reply with quote

Hello Worac,

Worac wrote:
Thanks for your comments as well. We have restled with having to create RFC's for changes to a Dev instance. We have a fear of never getting any work done if we guard it too tightly.


In a mature environment, RFCs are entered long before any work is done in "any" environment, so that they can be planned and addressed through normal lifecycle procedures. Depending on the type of RFC, you will have different levels of approvals and/or control.

The problem arises in that too many people in enterprises want a hand in everything that's going on. The reality is that control of a Dev environment is something that should be far more flexible and rapid than control over a Production environment. However, if you do it correctly, you should still see your Changes marching across all of your environments, sequentially, as the best practice is that if a Change modifies a configuration that other systems depend on, that Change needs to be tested, thoroughly, before deployment to your Production environment.

It's always a smart thing to create and manage RFCs through all environments. It will help you understand their impact, more effectively, long before you try to roll them out to Production.

I 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
Worac
Newbie
Newbie


Joined: Dec 01, 2006
Posts: 4
Location: Colorado

PostPosted: Tue Aug 28, 2007 12:08 am    Post subject: Reply with quote

Frank,

Make sense. We have a long way to go before we are that mature, but it gives us a goal.
Back to top
View user's profile
Guerino1
Senior Itiler


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

PostPosted: Tue Aug 28, 2007 12:37 pm    Post subject: Reply with quote

Hello Worac,

Worac wrote:
Make sense. We have a long way to go before we are that mature, but it gives us a goal.


It's real simple to become that mature...

Put an attribute on your RFCs that is called "Environment", where the values would be:

- Awaiting Development/Engineering
- Private Workspace
- Common Development Staging
- Common Development
- Systems Integration Testing Staging
- Systems Integration Testing
- User Acceptance Testing Staging
- User Acceptance Testing
- Production Staging
- Production

When RFCs are created, always assign them to "Awaiting Development/Engineering" as the default Environment.

Then, ensure that the appropriate groups have regular approval meetings, "before" Development and Engineering starts.

Once the RFC is approved, have the appropriate teams work on it in the appropriate environment(s) and control its promotion to the next environment.

While this isn't a perfect solution (no solution is), it's a solid start.

My Best,

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


Joined: Feb 06, 2007
Posts: 41

PostPosted: Thu Sep 06, 2007 12:53 am    Post subject: Reply with quote

Hi Frank,

This is what we are struggling with. We have defined our change management process as "gate keepers". So any promotion of code to any of our environments, excluding development of course, requires an RFC.

We are not at the point of how to handle software changes up front with RFCs, we are just getting knowledge of "releases" when they want to be deployed into an environment. But I want to change that like you laid out in your previous post.

How do you track the "release" through each environment without an RFC, how does that process work?

Example:

Somebody wants to change our application because of an incident or the business requested a new feature, so an RFC is submitted, lets say its to fix a defect found in production.

So the user enters RFC stating the change.

This goes to CAB for review.

Everyone agrees, the change is needed and approves the change.

What do you put in the proposed change date? As in when does the requestor want to make this change. Now, to us this means put change into an environment, not actual go and build.

How do you scheduled the actual change date (we have these on our RFC forms as to when the change will be implelented), would this mean when will it be deployed to production?

What CIs do they pick, say they are changing the current version of XYZ 1.0, they would link the RFC to this, but they would also need to create a new CI XYZ 1.??

Now they go in development and make the change, compile the code and test it and are ready to deploy it to our testing environment. How does the current RFC track this and as well track the CI status/lifecycle? Do you enter another RFC to request deploying XYZ 1.?? into Testing? How does this get approved to go into the testing environment? As we track CIs in our testing environment. Once XYZ 1.?? goes into testing, we would update our CMDB to reflect this, XYZ 1.0 would lose its relationship to the server its installed on and we would create a new relationship to ZYZ 1.?? to that server.

Hope this came out right and you understand where I am going with this.

Thanks.
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.