Does anyone have experience with Configuration Management of Genesys Telephony?

Drew,
I wish I had a dime for everytime I've run into such a conflict with the tool "experts." Problem is, they know the tool but don't know CM and they always want to grab the low-hanging fruit from the tool perspective. For example, when you set up a workflow in SBM (new name for TeamTrack), field control (Required, Read Only, Optional) through the states is transition-centric. That is, if you want a field to be generally "Read Only" but "Required" in a single state of your process, you can set the default as "RO" but then set an override of "Required on Transition X." Then when the owner of that state selects Transition X, the form cycles back into the same state, but this time there's an error message and the field shows as "Required." The result for the end-user is frustration because (s)he didn't have a required field and now does and (s)he has to transition the form twice - once to find out there is such a field and once to send it on its way once its done. This "transition-contolled" attribute can be overridden, but this means the "expert" has to do a little bit of work. And they get away with it because no one else has the expertise to argue with "If it has a bug, it's almost impossible to find out where it is."

With all that said (far too lengthy), let me address your question?

To me, establishing control over the configuration of your tool would be much like any other "product" (here the product is the "tailoring" of an instance within the tool for a product). As you know, we control a configuration by controlling its "description information" (plans, designs, source code, scripts, publications, etc.)

It gets abstract to be sure, but in this instance all that tailoring (flags/attributes/does Genesys have a process controller?/etc.) comprises the "product." So you control that description information - Design drawing of the process flow, attributes of fields, flag settings, group/role names, group/role permissions, etc.

Suppose we have a new Blivet to create and we need to create an area in the tool to maintain the artifacts. Further, we want to exercise CC on the "area."

First, make sure the "expert" understands that (s)he is to incorporate what has been defined and IF (s)he wants to do it another way, it may not be done without authorization through your defined decision making process.

For such an area, IDENTIFICATION consists of a spiral of subfunctions:
Selection - We are going to place the area under CCM.
Ident - Apply unique ID it
Decompose - Break the instance into its component parts such as a list of group/role names, permissions assigned to each grp/role, process map, state/stage owners.
Selection - Determine which component parts to CC and which to simply manage
Ident each as appropriate
Decompose - to further detail (if applicable)
Return to Selection

Now you have all this stuff documented and you have the basis for exercising CCM through the Change Proposal/Request Process. In this case, the controlling body (CCB?) probably consists of managers and team leads. The documented "description information" provides the basis for conducting a CA against the "current" setup in Genesys.

Hope that helps,
Bill

Drew,

This situation that you are in makes me cringe. Not because you have to put up with this blatant disregard for the help you are offering for their own good. What makes me cringe is the fact that you will probably be blamed if there is a catastrophic failure of the Genesys system for not doing enough to "version control" the system. Thats the sad part.

So what do you see as your options here? I would think your options are limited to warning the upper management of the foolishness of the "experts" or just doing the best you can to get some semblance of version control system in place in hopes that it is enough if the catastrophic event does occur.

All of this assumes that "upper management" would even understand what you are talking about. Good luck with finding a suitable solution.

Regards,

Joe

[b]Drewster wrote:[/b]
[quote]Unfortunately - (in my view/experience) "only" Managing systems in the astract requires a certain degree of maturity and dicipline to make it work.[/quote]

As I said, "First, make sure the 'expert' understands that (s)he is to incorporate what has been defined and IF (s)he wants to do it another way, it may not be done without authorization through your defined decision making process."

[b]Drewster wrote:[/b]
[quote]Updates are applied to the "real" system and (sometimes/eventually) applied to the Documents etc - but by the time the Documents are up to date - further changes have already been applied (in total reverse).[/quote]
As I said, "CCM through the Change Proposal/Request Process." This implies that changes to the system should be dependent upon documented approved ECPs, Defect Reports, Test Problem Reports, and other types of CR.

[b]Drewster wrote:[/b]
[quote]The additional "headache" is that in order to carry out an "Audit" we want to get out of dependency on the Techies.[/quote]
At the risk of sounding holier than thou, "Well, duh!" As you know, a robust CCM process will help warrant the integrity of the audit, which in turns helps warrant the integrity of the "product," i.e., the Genesys setup. Of course the techies don't want to go through all that stuff. Their view is that the customer (management) values an operating application more than documentation.

[b]Drewster wrote:[/b]
[quote]Typical scenario:
We need to prove/demonstrate that Design X has been accurately delivered to Live.

Design X Document - 1 month old
Live delivery - 1 day old

Great - on the surface that looks "ok".... hang on 1/2 dozen changes were needed to fix defects (and I know at least 1 of them "should" have required a Design amendment).[/quote]
Again I fall back on the notion of a robust CCM process.
"First, make sure the "expert" understands that (s)he is to incorporate what has been defined and IF (s)he wants to do it another way, it may not be done without authorization through your defined decision making process." AND

"The documented "description information" provides the basis for conducting a CA against the "current" setup in Genesys."

Those various forms of CR - ECPs, Defect Reports, Test Problem Reports, etc. - are part of the description information.

For your Design==>Delivery paragraphs, this whole thing hinges on management in two respects. First, they must have a decision-making process (authority) and second, they must enforce it. If that won't happen, then I suggest that you succumb to total paranoia and document each and every instance where you said "proper controls" and received a negative response. "Just because you're paranoid doesn't mean they are not after you."

Your situation is rather like those who want to create working software and document it later. What it may well turn out to be is a case of "We will create something, document what it does, and then we can audit." The problem is such cases is that audit verifies that the document reflects the functionality of the created product, not the functionality that was contracted for.

Oddly, I saw again a documentary about restoration of the Parthenon in Athens. The major problem is that there are no existing drawings or descriptive writings to show/tell what it was supposed to look like. So, now, they draw what it does look like, interpolate the missing pieces, redo the drawing, and assume that the result is what it was supposed to be. Sounds like your "techies" are doing the same thing, except they aren't even bothering to interpolate or redocument.