Should Configuration Management ever be used for procurement

[kinger]

I have recently started a new role, and have found that the Configuration Management team is used more as an SR team for procuring licences and raising orders for new software, it seems to take priority over the management and maintenance of CIs and the CMDB.

In my exerience in the past, Configuration Management should ideally not be responsible for these activites, and whilst the relationship between the two should be close, they should not overlap to the extent that Configuration Management should be ordering the equipment.

I am aware that each business uses the ITIL structure in different ways, and that there are scenarios where certain ITIL functions can be combined and the lines blurred, however my company is very ITIL heavy and does have teams specifically responsible for procurement.

It is my belief that CFM should be solely responsible for managing software as well as all the other CIs and should not be procuring items where there is an alternative sensible home for it. If CFM is to be used in this way, it should be clearly defined with roles set in the team so the two do not overlap.

I am hoping to approach management here with my suggestions of either removing the procurement role from CFM, or splitting the team to clearly define the boundaries. Would you agree with this? If anyone has any advice on approaching management with this kind of suggestion it would also be approciated.

[asrilrm]

Hi kinger,

Sorry, your post just slipped my eyes.
I personally see that there is no direct connection between CFM and procurement team.
And I would say that CFM should not hold the role of procurement
First, because CFM is a process and not a function.
They should have no accountability to produce PO, RFP, etc.
Second, if they do have it, then it might lead to a conflict of interest.
Because they control of the CMDB, they have a high possibility to make fake justification to purchase new but unnecessary things.
I'm sure there are a lot more but those two are the most critical from my point of view

Cheers,
Asril

[kinger]

[UKVIKING]

I too would treat procurement separately from config

Config mgmt is the recipient of what ever they order in procurement

Take this scenario to heart

Procurement gets a good deal on some machines

The machines get ordered, paid for, delivered and stored in a secure storage area

During this phase CfM does not have anything to do with them (in one world view)

The implementation team for a project wants to use one of the machines for a project

They get one from the controlled secure storage area

the system gets rack, stack, O/S, powers, IP'd, switched and patched

Then the system gets tested by the implemetnationt team on whether it actually will work for the project

lo and behold... the server does not have enough memory for that project nor does it have enough HD space. The machine is crap or a returned system (why it was so cheap) . The Impl team finds the device - unfit for purposes

SO they go to procurement and btich bicth and complain

Procurement did not bother to ask what was needed .. instead they jsut went out and got... crap for cheap

BTW: This actually happened but with mice and floppy disks (80s - early 90s) when 3 1/4 disks were the prime

Our procurement got a good deal on 2 cases of floppy disks but 9 out of 20 would not even hols 720 kb

and the mice .... worse than packard belll
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter

[kinger]