Siebel 8 Territory management

This morning a reader contacted me to ask me what exactly Territory Management is in Siebel and the difference, for example, with Assignment Manager. Unfortunately I could not answer immediately as I was on the phone with a prospect, so I am going to explain Territory Management in this post, for him and whoever might be interested. I am going to describe Territory Management as it is in the last Siebel version 8, because new features have been introduced and so I want this post to be useful also for the people that already know assignment manager rules in previuos Siebel versions.

In this first post I will limit the scope to the administration process flow and the setting up of the environment. If anyone was interested in seeing in detail some specific parts, just leave a comment and I will be glad to go deeper in that direction.

Well, first of all let me introduce some order: Territory Management is the set of Siebel functionalities to manage sales and service territories, while the assignment manager is the engine that, based on defined rules, assigns Sales Reps to account, contact or opportunity teams (in a SFA case) or assign ownership of assets to field service engineers (in a field services case).

Technically speaking, assignment manager is a Siebel Server component group dedicated to the execution of the assignment rules defined by assignment criteria.

The territory management functionality is mainly offered in order to avoid requiring developers for the modification or creation of workflow/batch assignments, while giving administrators a platform to create assignment rules (supposing that all the necessary fields to construct the filter are available).

This is quite clear if you observe the figure 1, the model 2 diagram representing a classic process flow: allmost all the activities are delegated to the Administrator. Unfortunately I had to split the image in two for dimensions reasons, but consider the second part as the continuation of the first (horizontal oriented swimlane).

Figure 1. Process Flow for territory management.

In relation to the configuration setup I am going to use, on the contrary, example diagrams belonging to the first model of the Crm-Up methodology (CRM Use Case Analysis). There are specific reasons behind this choice that are in any case out of this posts' scope and more related to the Crm-Up methodology. It's just to say that probably some UML purist could look with suspect our use case modeling approach, but this is part of the innovation in Crm-up methodology and our aim is usability and high adoption by all the stakeholders of a CRM implementation project, business users included.

Anyway, in the Figure 2 you can find a description of the first step in the configuration setup, that is the enablement of the component groups.

Figure 2. Setup - first step: enable component groups

In figure 3 you can find the third territory management setup step, that is the enablement of all the necessary Workflows.

Figure 3. Setup - second step: enable workflows

Last but not least, in figure 4 the third setup is represented, that is the load splitter configuration.

Figure 4. Setup - last step: load Splitter configuration

Well, that's pretty much all for this first post; as I said, if anyone is interested in the details of any of the described steps, feel free to contact me and I will be glad to describe them.

Think about it ;)