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: EHardman
New Today: 2
New Yesterday: 73
Overall: 142294

People Online:
Visitors: 59
Members: 2
Total: 61 .

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 - Enterprise Wide Change Management and Release Management
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Enterprise Wide Change Management and Release Management

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


Joined: Jan 23, 2006
Posts: 13
Location: San Francisco, CA

PostPosted: Thu Sep 14, 2006 1:51 am    Post subject: Enterprise Wide Change Management and Release Management Reply with quote

We are in the process of rolling out change management, release management, and configuration management enterprise wide. Our first phase is to roll these processes out to our critical/SOX systems. Do most large companies have enterprise wide CM and RM functional teams?

Currently we have a CM team for infrastructre and a CM team for our applications. Is it really feasible to set one up enterprise wide?

With regard to Release Management we currently have each application group providing their own RM. We are a company of about 20,000 employees. If most companies do have an enterprise wide RM process, what does the structure look like? Do they have release engineers at the application level that roll up to an enterprise wide release engineer(s) that is/are responsible for scheduling releases, etc.?
Back to top
View user's profile
Fabien
Senior Itiler


Joined: Sep 27, 2005
Posts: 207

PostPosted: Thu Sep 14, 2006 3:29 am    Post subject: Reply with quote

You need to look at the practical way to implement this. In some very centralized companies you could centralize the CM process. In a lot of companies though it's just not feasible. Just taking down the different kingdoms in IT is challenging enough sometimes.

It does matter that there is a central authority that owns the process and the policy overall to ensure proper coordination, which is the essence of the process. You cannot delegate accountability.

But once the framework is defined, it needs to be organized in a way that makes sense for your particular case.

As my guide, I always keep in mind that I want someone to own a process, I want it fully defined, and I want it controlled by some "opposing" interests. That's how you keep things straight.
_________________
BR,
Fabien Papleux

Accenture
Technology Consulting | Service Excellence
Red Badge Certified

Twitter @itilgeek
Back to top
View user's profile Send e-mail Visit poster's website MSN Messenger
m_croon
Senior Itiler


Joined: Aug 11, 2006
Posts: 262
Location: Netherlands

PostPosted: Thu Sep 14, 2006 5:10 am    Post subject: Reply with quote

Debbie,

With Config, in a company your size, I would start with the 'IST' ('what is') instead of the 'SOLL' ('what should be'). Formally, anything to be changed (!) in the cmdb is meant to be under control of change management. Therefor, a well maintained cmdb gives you insight in all changes executed on the infrastructure. This can be very important for auditors etc. I have no insight in the priorities of your company on this subject.

If you invest in inventory tooling however, that will map your infrastructure 'as is' instead of 'as it should be', you will gain insight in things such as used licences, deviations in software versions etc. This insight will be of use to convince people to (also) work on the administering of the 'soll', i.e. the administrative proces of altering the cmdb through known/legal changes.


Hope this helps,

Michiel
Back to top
View user's profile Visit poster's website
Guerino1
Senior Itiler


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

PostPosted: Fri Sep 15, 2006 7:24 am    Post subject: Reply with quote

Hello Michiel,

In your response, you stated:

m_croon wrote:
Formally, anything to be changed (!) in the cmdb is meant to be under control of change management.


I'm going to disagree with you on this. The function of Change Management is nothing more than to act like a control tower in an airport. It coordinates what Changes are on which runways and how they get into the sky, along with coordintating where they are in the sky, so as to avoid Incidents.

Change Management's stake in the CMDB is nothing more than to have access to the information within it to be able to understand changes, impacts, etc., just like any other stakeholder in the enterprise.

Each Product, Release, and Change configuration is controlled and owned by the Product Ownership team. It is typically their responsibility to put configuration information into the CMDB and keep it updated. Therefore, the configuration itself is owned by the Product Ownership team.

The CMDB itself is typically owned by by something like a Software Engineering Team, who owns all infrastructure software and who manages upgrades to the CMDB like any team manages upgrades to through controlled Releases for any Product. The are the Product Owners of the CMDB as a stand-alone Product that has to be managed, just like all other Products.

The Change Management team is a consumer of the information in the CMDB, just like the Service Delivery Teams, Service Management Teams, Incident Management, and Problem Management teams are. They all equally need access to configuration information, made available via the CMDB.

Anyhow, I hope you find this information useful.

Regards,
_________________
[Edited by Admin to remove link]
Back to top
View user's profile Send e-mail Visit poster's website
m_croon
Senior Itiler


Joined: Aug 11, 2006
Posts: 262
Location: Netherlands

PostPosted: Fri Sep 15, 2006 8:11 am    Post subject: Reply with quote

Hi Frank,

Thank you for your opinion. Although your statements on the information role of configuration management are definitely true, I find them incomplete and possibly a bit biased (no offence) since you are clearly working for a software developing company (Nothing wrong with software dev. co's. By the way, is your company doing anything with ASL?). Your product managers/owners are certainly not clearly around in every company!

A true and properly implemented change management proces should leave all product owners in their own value, while at the same time convincing them of the shared interest as they all work for the same company and possibly for the same clients.

The position of configuration management within the set of ITIL processes is almost unique. It is the spider in the web, as configuration management is indeed supposed to give information to almost all other processes. Without proper config info, problems cannot be resolved, on site support will visit a wrong location whilst trying to solve an incident, changes cannot be assessed on their impact etc. etc.

However, configuration management has an aditional relationship with change management: any change to be executed should lead to an adjustment of a CI, and therefor to an alteration of the cmdb. If this was not the case, the impact assesment for any changes after the very first one you did would be useless.

But maybe our disagreement is only a matter of definition. When I say "under change management control", I leave open which dept., role or function will actually decide if a change gets a Go for production. This decision would certainly not be made by the change manager, he/she should merely facilitate (basicly your tower-control) that all parties involved (including product managers/owners if available) agree on the matter as participants in the change management process. If they all agree, the change was actually under control of change management, and altering the cmdb is than a matter of administration. The actual composition of a CAB (Change Aproval Board (ITIL says Advisory Board)) will differ between organisations.

I am curious about your reaction Cool, do let me know.

Cheers,

Michiel
Back to top
View user's profile Visit poster's website
Fabien
Senior Itiler


Joined: Sep 27, 2005
Posts: 207

PostPosted: Fri Sep 15, 2006 8:18 am    Post subject: Reply with quote

Guerino1 wrote:
Change Management's stake in the CMDB is nothing more than to have access to the information within it to be able to understand changes, impacts, etc., just like any other stakeholder in the enterprise.

Frank, you've just blown my mind. Shocked Shocked Shocked

A change to the CMDB (not in the CMDB) is a change, and is therefore subject to the Change Mgt process, though the tool should have an owner. A Change in the CMDB is the responsibility of the Configuration Manager who likely works in connection with numerous people from different groups.

However, the CMDB needs to be designed in a way that the access control is clearly defined, sometimes at field level, to determine who updates what. What we need to avoid here is that a security administrator can modify the configuration of a firewall, update the CMDB and never tell anyone else. If that can happen in your organization, then you are going to miss on the promise of 'increased reliability and control'.

Your CMDB should only be populated with CI's that are under the control of Change Management, or else there is no way of guaranteeing that the CMDB is accurate and that the CM actually controls change.

The Configuration Manager is the one who ultimately organizes the vegetables to make a good soup.
_________________
BR,
Fabien Papleux

Accenture
Technology Consulting | Service Excellence
Red Badge Certified

Twitter @itilgeek
Back to top
View user's profile Send e-mail Visit poster's website MSN Messenger
Guerino1
Senior Itiler


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

PostPosted: Fri Sep 15, 2006 2:34 pm    Post subject: Reply with quote

Hello Michiel,

Please understand that a disagreement is just a disagreement and an opportunity to discuss and share our knowledge, so I never hold anything personal and I hope you don't, either, as I never intend anything personal in my responses.

Please find my responses, embedded below...

m_croon wrote:
Although your statements on the information role of configuration management are definitely true, I find them incomplete and possibly a bit biased (no offence) since you are clearly working for a software developing company (Nothing wrong with software dev. co's.


To give you some background, I run an IT utility company that offers managed services. We do not ship software. Clients connect to our platform, we do all of the hosting, development, maintenance, etc., ourselves. Leading this enterprise is a recent development. Before this, I've managed many different globally distributed product development teams and IT organizations in many different large companies, some of the largest in the world, including the largest financial company in the world. When I provide information on this forum, I always try to give the biggest picture views that I can.

I have multiple different perspectives that I always try to bring to the table, in an attempt to add value:

- The perspective of my prosects and clients who, while I can't directly speak for them all, make it very clear as to how they do things and what their expectations are of ITIL and of service/solutions providers like myself.
- The perspective of my own experiences running large IT organizations (architecture & strategy, development, engineering, support/Service Deliver, QA & Testing). While I can't say that I've seen everything, I can comfortably say that I've seen quite a bit, as I have more than 25 years with small, medium, large, and extremely large enterprises.
- The perspective that comes with my experience in implementing ITIL disciplines: processes, tools, policies, procedures, the restructuring of world-wide organizations to accommodate all of it, etc.... many times over. I have yet to meet a single person or team that has implemented more solutions for ITIL, more times over, than my team has.
- My experience as the leader of an enterprise selling IT/ITIL/ITSM services and solutions into the industry. This helps shed light on the market, its reaction(s), its expectations, and what it means to provision for and sell into it.

So while you think my answers may be biased, please rest assured that they're not. I usually stress when something is my opinion in my posts. You can go back and read others to see the statement.

So, when I post responses, I hope the readers understand that I am truly hoping to share whatever knowledge I can, as doing so also allows me to learn from those I share with. I come to this forum because it adds value and because I hope I can add value to it.

Now enough about me and let's get back to your statements & questions...

Quote:
By the way, is your company doing anything with ASL?).


If by ASL you mean Application Services Library, my answer is both yes and no. ASL is nothing more than a weak re-attempt at "Product Lifecycle (PLC)" and "System Development Lifecycle (SDLC)" theory and practices, which have been around for many decades. We find that anyone who has any hardcore experience in partially distributed to highly distributed software design is very skeptical of ASL and can pick out many of its issues, gaps, and weaknesses very quickly. It misses many critical aspect of application development. It also makes the mistake of trying to segregate Application Lifecycle from Product Lifecycle. Product Lifecycle is a far greater superset of responsibilities and treats all products exactly the same, whether they're software, computers, financial portfolios, cars, radios, etc. While we agree with what ASL is attempting to provide and applaud its attempt at being a banner for best practices, we find it far too incomplete to add any real value to any team that has any serious experience in developing and managing large critical applications, especially those that go out to commercial market.

Quote:
Your product managers/owners are certainly not clearly around in every company!


I guess I don't understand this statement. If you mean that every company doesn't implement Product Owners and Product Managers, yes, this is sadly true. We find that those enterprises that don't are typically the ones that are in the greatest state of chaos.

In my opinion and from my experience (see I prefaced the statement with "in my opinion!") I believe that the first thing every enterprise must do to improve their IT situation and get everything under control is to assign a single and definitive Product Owner to each and every Product in their enterprise and a single and definitive Service Owner for each and every Service in their enterprise (NOTE: Service managers are nothing more than Product Owners of Services and when I refer to Product Owners I mean both.) Making such an assignment will eliminate confusion, contention, and clearly define who is accountable and the single point of contact for any and all information about that Product. The second thing I recommend is to get all Products into a single Product Catalog (This is a flaw/gap in ITIL, as it does not address a Product Catalog, at all, which is critical to successful IT management. Assets are "instances" of Products.).

Note: You may want to read "Crossing the Chasm" by Moore. It's a great book and a classic that defines what Product Management is and explains the role of the Product Manager and how he/she is a delegate of the Product Owner. It's not a techie book but more of a marketing and strategy book.

Quote:
A true and properly implemented change management proces should leave all product owners in their own value, while at the same time convincing them of the shared interest as they all work for the same company and possibly for the same clients.


I totally agree to this and did not say anything that contradicts this. I reread my post multiple times to be sure. Enterprise Change Management is what all Product Ownership teams must perform, consistently, in a common enterprise, as part of the benefit of the whole. We not only pitch this every day, we teach enterprises how to do it successfully.

Quote:
The position of configuration management within the set of ITIL processes is almost unique. It is the spider in the web, as configuration management is indeed supposed to give information to almost all other processes. Without proper config info, problems cannot be resolved, on site support will visit a wrong location whilst trying to solve an incident, changes cannot be assessed on their impact etc. etc.


I completely agree. Well over 90% of the configuration information comes directly from the Product Ownership teams. They specify the design configurations, the storage configurations, the build/packaging configurations, the deployment/distribution configurations, the installation configurations, the instantiation configurations, the behavioral/execution configurations, the role back configurations, and much more. Anyone that has ever done Product Development of any form (software, hardware, financial portfolios, widgets, etc.) will attest to this. It is for this reason that Configurations are "owned" and dictated by the Product Owners and their direct delegates, such as the designers, implementers, etc. (affectionally known as Product Development teams). This was my point in the previous post. Change Management does not own the configurations or the CMDB. They are consumers of it, like all other stakeholders outside of the direct Product Ownership, Management, and Development teams.

Quote:
However, configuration management has an aditional relationship with change management: any change to be executed should lead to an adjustment of a CI, and therefor to an alteration of the cmdb.


Yes, any change to be implemented should lead to a change to a CI. I agree. However, that Change is usually designed for and implemented long before any Change Manager ever is introduced to the Change. It is a very rare organization that has their Change Management team privvy to all Changes before they're actually implemented. We know this because this is a unique feature in our platform that adds advantage for us. All people see all information in our platform the moment it's created. That means that any RFCs entered into the system are instantly visible to all other stakeholders, the moment they're entered. Change Management sees the RFCs before they go into evaluation, design, and development by the Product teams. In most enterprises this is not at all the case. Change Management teams don't see RFCs until they're submitted for near future deployment to the Production environment. It's the rare organization that manages RFCs from inception, through development, through testing environments, and ultimately through to production where it's intended to be closed.

Quote:
If this was not the case, the impact assesment for any changes after the very first one you did would be useless.


Again, this is true but it is the Product Ownership teams that own this responsibility, not the Change Management teams. Change Management is a consumer of the information, not the owner of it. They help schedule, coordinate, communicate, evaluate, and understand change to the environment(s). That is it. Change Management doesn't update the CMDB, as configuration data should already have been in the CMDB long before it got to Change Management. The only thing they modify in the CMDB (and this is very rare) is the RFC, itself. The reason this is rare is because there are less than 5 known products (and that's stretching it by 3) that have "true" RFCs/Changes "in" a "true CMDB". We're one of them.

My point, very simply, is that Change Management does not own the CMDB or the data within it. They are consumers of it.

Quote:
But maybe our disagreement is only a matter of definition. When I say "under change management control", I leave open which dept., role or function will actually decide if a change gets a Go for production. This decision would certainly not be made by the change manager, he/she should merely facilitate (basicly your tower-control) that all parties involved (including product managers/owners if available) agree on the matter as participants in the change management process. If they all agree, the change was actually under control of change management, and altering the cmdb is than a matter of administration. The actual composition of a CAB (Change Aproval Board (ITIL says Advisory Board)) will differ between organisations.


Yes, I agree with all of this except when the CMDB gets updated. If done properly, it is updated long before it ever gets to Change Management for review.

Anyhow, I hope this helps clarify.

Regards,
_________________
[Edited by Admin to remove link]
Back to top
View user's profile Send e-mail Visit poster's website
Guerino1
Senior Itiler


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

PostPosted: Fri Sep 15, 2006 3:09 pm    Post subject: Reply with quote

Hello Fabien,

Please see my responses, embedded below...

Fabien wrote:
Guerino1 wrote:
Change Management's stake in the CMDB is nothing more than to have access to the information within it to be able to understand changes, impacts, etc., just like any other stakeholder in the enterprise.

Frank, you've just blown my mind. Shocked Shocked Shocked

A change to the CMDB (not in the CMDB) is a change, and is therefore subject to the Change Mgt process, though the tool should have an owner.


I don't believe I've said anything to contradict this and agree with this statement. A change "to the CMDB" is, in fact, a change to an application that is a CMDB. Yes, that should result in an RFC. This is not at all what we were speaking of and I believe you misinterpreted the post.

Quote:
A Change in the CMDB is the responsibility of the Configuration Manager who likely works in connection with numerous people from different groups.


Yes, "a change to information inside the CMDB" is the responsibility of the person responsible for the specific configuration(s).

- Design Configurations
- Build/Packaging Configurations
- Deployment/Distribution Configurations
- Installation Configurations
- Instantiation Configurations
- Execution/Behavioral Configurations
- Rollback Configurations
- Environment Specific Configurations for every permutation of the above
- Organizational Configurations
- Consumption Configurations
- Communications Configurations
- Etc.

Please note that it is a very rare organization that has a dedicated Configuration Manager. As a matter of fact, a highly mature enterprise generates the majority of their configuration information 1) from planning and design and 2) from point-in-time actions such as scripts that have built-in "callback" (i.e. "phone home") facilities. Manual Configuration Management is typically the sign of a very immature enterprise.

Quote:
However, the CMDB needs to be designed in a way that the access control is clearly defined, sometimes at field level, to determine who updates what.


Actually, here is where I will disagree with you. What you offer is only one strategy for how to implement a CMDB. There are many. There is the "open information" strategy that uses all eyes on the data to ensure its quality and allows anyone and everyone to modify the data, while logging each and every change, who made it, when it was made, etc. We personally like this one and we're finding that most enterprises are starting to see its value over a locked down CMDB which silos critical data.

Quote:
What we need to avoid here is that a security administrator can modify the configuration of a firewall, update the CMDB and never tell anyone else. If that can happen in your organization, then you are going to miss on the promise of 'increased reliability and control'.


Again, in a mature enterprise, the modification of the firewall configuration is 1) Controlled by planned Changes that are evaluated long before they get implemented and long before they go to Change Management a,d 2) are scripted and pre-tested such that the modification scripts read configuration files that are specific to the firewall product set and dump details about the configurations to log files, the CMDB, etc. Actual configuration rules for the firewall go into the Product specific branches of the DSL with the modification scripts, where they are all controlled through source code control, build and deployment infrastructure, etc. They should not be in the CMDB as anything more than a symptomatic side effect that proves the execution of the work and establishes impact linkages/relationships in the CMDB.

Quote:
Your CMDB should only be populated with CI's that are under the control of Change Management, or else there is no way of guaranteeing that the CMDB is accurate and that the CM actually controls change.


I beg to disagree but this is an incorrect statement you've made. The CMDB is much larger in scope and in purpose than meeting the sole needs of Change Management. Most, if not all, configuration information should be in the CMDB long before Change Management ever needs it, as many other groups/stakeholders will need it, too. Also, there is a tremendous amount of information that goes into the CMDB and not all of it is CI related (e.g. Release Units, Relationships, Audit Records, Logs, Dynamic Data, Reports, etc.).

Quote:
The Configuration Manager is the one who ultimately organizes the vegetables to make a good soup.


Not in a mature organization. In a mature organization, the design team has pre-defined the configuration of the product in each and every environment, long before the product ever gets implemented/built. Point-in-time actions, such as builds, deployments, etc. only serve to ensure that you take live, traceable, and repeatable snapshots of how, when, and where things occured so that you can debug and recreate things if you have to. In a mature enterprise there is no need for a dedicated configuration manager. That function is handled by the Strategy/Design/Engineering/Architecture team(s) that dictate product, environment, business and market strategy. Point-in-time actions collect realtime configuration snapshots that are used as actual data to compare to the expected reference data that should come from these teams.

Having a dedicated Configuration Manager, as a real role, is usually the mark of a highly reactive organization that doesn't plan and manage its configurations long before they get to their targeted production environment(s). Up front planning usually eliminates the need to spend funds on such a dedicated role.

I hope this helps.

Regards,
_________________
[Edited by Admin to remove link]
Back to top
View user's profile Send e-mail Visit poster's website
Fabien
Senior Itiler


Joined: Sep 27, 2005
Posts: 207

PostPosted: Fri Sep 15, 2006 10:19 pm    Post subject: Reply with quote

Well, this is interesting as I see how ITIL can be open to interpretation.

A couple of points that confirm where we seem to disagree:

1. If the organization does not have a Configuration Manager, there is no person responsible for managing the process itself, measure and control its effectiveness, and ultimately be accountable for its accuracy. That is pretty clear to me.

2. I personally do not believe that you can maintain a CMDB with an "open information" method. Without proper controls in place, you have no safeguard to ensure the DB's accuracy and, therefore, you are leaving the Change Mgt group with doubtful information.

3. The CMDB contains CIs and relationships. A release unit is a CI, just like an SLA or a user as far as I am concerned. The reason why I talk about up to field-level access control is to establish the change processes specific to certain CIs. For instance, the introduction of a new user is subject to the Change Mgt process. Hopefully there is a pre-defined workflow associated with it of course. But we could very establish that changing a user's home address is a change authorized by the HR department. Anything in your DB that is not under the strict control of a defined process is going to allow someone to make a mess in there.

Anyway, we seem to disagree and I guess that will happen Wink
_________________
BR,
Fabien Papleux

Accenture
Technology Consulting | Service Excellence
Red Badge Certified

Twitter @itilgeek
Back to top
View user's profile Send e-mail Visit poster's website MSN Messenger
Guerino1
Senior Itiler


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

PostPosted: Sat Sep 16, 2006 2:10 am    Post subject: Reply with quote

Hello Fabien,

Please find my responses embedded, below:

Fabien wrote:

1. If the organization does not have a Configuration Manager, there is no person responsible for managing the process itself, measure and control its effectiveness, and ultimately be accountable for its accuracy. That is pretty clear to me.


Centralized configuration is a very rare thing, regardless of the size of an enterprise. This is a role that very few enterprises can justify a true investment for. There is no clear and obvious ROI on Configuration Management for most enterprises. It doesn't mean that I don't believe in it. It just means that of all the ITIL disciplines, this is one of those that is very difficult to financially justify.

SMBs tend to rarely implement the role, at all. In a large and distributed organization, I have yet to find a successful implementation of a centralized and single Configuration Management authority. I believe this is because centralized Configuration Management does not scale well when an enterprise grows beyond a certain size.

In highly mature enterprises, Configuration data comes from so many different channels/sources that it is virtually impossible to have any one person or team manage the understanding and management of "all" configuration information. (e.g. design teams, dev teams, packaging teams, build teams, deployment teams, installation teams, support teams, engineering teams, administration teams, etc.)

The role of a Configuration Management team or member in such an enterprise is to define "how information will be consistently generated, collected, stored, recalled, rendered, reported, etc. This usually falls in the space of a strategic and centralized Software Systems Engineering team that is accountable for big picture software management (what ITIL incompletely describes as Application Management).


Quote:
2. I personally do not believe that you can maintain a CMDB with an "open information" method. Without proper controls in place, you have no safeguard to ensure the DB's accuracy and, therefore, you are leaving the Change Mgt group with doubtful information.


This is your opinion and, again, there are many ways to skin a cat. We deal with a significant number of enterprises that not only function successfully with "open information" CMDBs but they demand it. The largest financial institution in the world does it successfully. Remember, there is nothing in an enterprise that doesn't belong "to the enteprise". Many smart leaders want no silos (data, organizational, or otherwise) in their enterprises. Silos create heavy expenses, create barriers for success, slow down response times, require expensive integrations between silos, etc.

The world is moving more and more to open information methodologies. Reference Google & Yahoo. You may want to get used to it or you may be left behind.

Quote:
3. The CMDB contains CIs and relationships. A release unit is a CI, just like an SLA or a user as far as I am concerned.


This is absolutely true and I completely agree. As a matter of fact, very few people understand that RUs are, in fact, CIs. If you read ITIL's content on RUs, you'll realize it's very weak/vague on this topic, as there is a significant level of complexity that's introduced in software, where RUs can be distributable source code, interpretted scripts, compiled libraries, compiled binaries, packages, etc.

Quote:
The reason why I talk about up to field-level access control is to establish the change processes specific to certain CIs. For instance, the introduction of a new user is subject to the Change Mgt process. Hopefully there is a pre-defined workflow associated with it of course. But we could very establish that changing a user's home address is a change authorized by the HR department. Anything in your DB that is not under the strict control of a defined process is going to allow someone to make a mess in there.


Actually, most enterprises never go through the Change Management process for the addition of a new user. They certainly want to manage the process and log the information but they definitely rarely (if ever) go through the ChM process. At most, they might go through a user approval process, such as a credit check before adding a new user.

The reason is that adding a new user doesn't change the behavior of any part of the application/system. If you run every enterprise change through your Ch Mgmt org, you will cripple your enterprise.

You may want to read through some other posts on this topic. Most people on this forum seem to agree that adding a new user is "not" subject to ChM.

I hope this information helps.

Regards,
_________________
[Edited by Admin to remove link]
Back to top
View user's profile Send e-mail Visit poster's website
Fabien
Senior Itiler


Joined: Sep 27, 2005
Posts: 207

PostPosted: Sat Sep 16, 2006 3:17 am    Post subject: Reply with quote

Guerino1 wrote:
Centralized configuration is a very rare thing, [...]


Frank, I never even suggested that. I said the management of the process needs to be centralized: management, not execution.

I am not suggesting that there is a dedicated team to maintain the CMDB or even a single person. The Configuration Manager is a role, not a function. Whoever it is and whichever position that person holds depends on the organization, but there must be one person that controls what goes in the CMDB, how and when.

Quote:
The world is moving more and more to open information methodologies. Reference Google & Yahoo. You may want to get used to it or you may be left behind.


Advocating 'open information' is not the same as advocating 'open write-access to information', and thus 'no control'. I am not 100% sure to pick up your nuances. It is hard for me to think that you are saying that anyone should have access to everything in your CMDB with no control over what is done. There is no point in having a CMDB that does not contain control and access structures.


Quote:
Actually, most enterprises never go through the Change Management process for the addition of a new user. They certainly want to manage the process and log the information but they definitely rarely (if ever) go through the ChM process. At most, they might go through a user approval process, such as a credit check before adding a new user.


The only reason why the addition of a new user never gets in front of a Change Mgr is because it is defined as a standard change in all organizations I know. It is nevertheless a Change and, to be sure of that, you only need to wonder whether anyone can modify that process without due diligence. This is a cross-functional process who has an owner and which needs to go through the hands of several people when a change to it is required. It is absolutely controled, and thus subject to a Change Mgt process. It doesn't have to be that the Change Manager managing HR-related data is the same as the one managing the IT infrastructure. But it is controled.

Actually, here is a good one. The following quote is from HP's IPRC course:

"The mission of Configuration Management is to identify, control and audit the information required to manage IT services by defining and maintaining a database of controlled items, their status, lifecycles and relationships and any information needed to manage the quality of IT services cost effectively."

This as ITIL as you can get. Now, I am finding your tone a little condescending and I will leave this topic at that.
_________________
BR,
Fabien Papleux

Accenture
Technology Consulting | Service Excellence
Red Badge Certified

Twitter @itilgeek
Back to top
View user's profile Send e-mail Visit poster's website MSN Messenger
m_croon
Senior Itiler


Joined: Aug 11, 2006
Posts: 262
Location: Netherlands

PostPosted: Sat Sep 16, 2006 8:21 am    Post subject: Reply with quote

Guerino1 wrote:
Please understand that a disagreement is just a disagreement and an opportunity to discuss and share our knowledge, so I never hold anything personal and I hope you don't, either, as I never intend anything personal in my responses.

Frank,

I have no clue where you got the suggestive interpretation above of my previous remark. The only reason why I participate on this forum is to exchange information, to learn and to help other people. Anyway, a short (final) response on my behalve:

1. Bias
I repeat my opinion (!) that I find your post biased. In an ideal world, a mature organisation with responsible employees that only works on software development / selling / support / hosting can establish a lot with strong product management. However, I find those organisations rare in real life (I am honestly sure your company is an exception). However, it is my experience, that especially the larger sized companies you mention can only reach a state of operational excellence with central control / steering of any proces (where execution might be done very locally, for instance by product teams).
In my opinion, this means that the checks and balances should be levelled between product owners (yes, very important to have them) and a central proces owner, who has the task of balancing proper priorities between products (not necesarilly by deciding by himself, but by pulling the right managerial strings), steering on a generic way of working along all product teams and providing performance indicators on the proces (again: along all product teams).

2. team versus proces
On various moments in your posts, you talk about change management teams and config management teams. It is my opinion and experience (from customers I've worked with) that organisations who try and put a process inside a team (even only in name), usually do not have a working concept/grasp of a truely functioning proces.
A true proces should be a matter of working organisation-wide (i.e. over all products) according to the same guidelines, to reach a common goal (for example to have changes executed in a controlled way and according to accepted procedures, i.e. the goal of change management). I think this gives way to reaching a state of operational excellence.
Talking in terms of proces teams always gives me the feeling that those proces teams are the scapegoats for that 'extra bit of ("paper")work that we all hate but that we should do according to our anually visiting auditor'.

3. Maturity
Below is a quote from you, which includes a quote from Fabien (sorry, not properly indicated):
Quote:
Quote: (by Fabien)
The Configuration Manager is the one who ultimately organizes the vegetables to make a good soup.

Not in a mature organization.
DEFINATELY in a mature organisation. By the way, where is "your opinion"? Wink

4. Standard versus non standard changes
Again, a quote from you earlier in this chain:
Quote:
Actually, most enterprises never go through the Change Management process for the addition of a new user. They certainly want to manage the process and log the information but they definitely rarely (if ever) go through the ChM process. At most, they might go through a user approval process, such as a credit check before adding a new user.

Allow me to make a slight change in emphasis. In my opinion it is a mistake to see the addition of a new user as anything but a change. Adding a new user IS a change, therefor it goes through the change proces. An other thing is, whether this standard change is CONTROLLED by the change manager.
Do not get me wrong: I do not imply that it should be discussed in a CAB.
But as a proces, standard changes should still be controlled by the proces owner of change management. This can be done through weekly or montly reporting, and an active executing monitoring role for the service desk on (standard) change progress.
Many change managers I've met focus on their CAB changes / non standard changes, which are big(ger) in impact but usually much lower in numbers. They say they have their proces under control, but they only mean the non standard changes, and forget that the standard changes are a big mess. Business-wise, they are doing well by having the non standard changes under control. Customer/end user wise (customer sattisfaction), they are doing a poor job as simple standard changes are not reported done or not done at all. But maybe this is my own workspace management bias.

Anyway, I hope this helps. Let us agree that we disagree, and leave it with that.

Cheers,

Michiel
Back to top
View user's profile Visit poster's website
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.