This chapter covers the following topics:
Oracle Territory Manager supports role-based access control of data security. Each user is assigned one or more territory roles. When users log in to Oracle Applications, all menu items associated to their assigned roles appear on their personal home pages. The following roles are available for assignment:
Sales Team Search User: Provides access to the stand-alone sales team search
Territory Reports User
Sales Territory Reports User (includes Territory Reports User role)
Sales Territory User (includes Sales Team Search User)
Territory Manager Application Administrator
Sales Territory Administrator (includes Sales Team Search User and Sales Territory Reports User)
Collections Territory Administrator (includes Territory Reports User)
Partner Management Territory Administrator (includes Territory Reports User)
Service Contracts Territory Administrator (includes Territory Reports User)
Service Territory Administrator (includes Territory Reports User)
Trade Management Territory Administrator (includes Territory Reports User)
Having a separate role for each usage makes it possible to restrict a user to see and work with territories, matching attributes, and so on within their usage only.
For example, a user with only the Service Territory Administrator role can only manage service territories and will not have access to territories for another usage, such as sales or collections.
Oracle E-Business Suite Security Guide
The planning phase is the most important step in territory setup. Before using Oracle Territory Manager, a territory planning team should be established to analyze the territory setup in your organization. This territory planning process needs enterprise-wide cooperation and feedback.
Note: Multiple territory revisions in the first months of operation should be expected as your enterprise discovers omitted information or territories that do not work on a day-to-day basis
Based on your business needs, your team needs to determine the following:
Usage: What applications need territories?
Transaction Type (which is based on usage): for example, leads, opportunities, service requests, and delinquencies.
How many territories are needed?
What transaction matching attributes should be enabled?
What resources should be attached to the territories?
What should the territory hierarchy structure be?
How many winners are allowed? A winner is the territory that receives the transaction or customer.
How are winning territories determined?
Will Sales implement named account territories?
Do you want to implement self service territory deployment?
This list is not all-inclusive and planning factors depend on your business needs.
Perform the following steps to plan your territories. This procedure is usually done in a group with pen and paper.
Review your existing territories.
You need the following types of information:
What is your usage? In other words, what business applications are you building territories for? For example, Oracle Sales, Oracle TeleSales, Oracle Collections, or Oracle Service.
What transactional objects within your chosen usage are you assigning resources to? This is your transaction type. For example, for Sales, it is account, opportunity, or lead.
How are your territories currently assigned (by state, by industry, by zip code, by account, and so on)?
Is Sales currently using named account territories, even if being manually maintained?
What are the names and current territory assignments for your sales or service personnel?
What are the names of employees in other organizations who receive account, lead, and opportunity information and how is that information accessed and used?
What are your products and how are they differentiated?
Decide what matching attributes you want to use to assign objects to territories.
Decide on the hierarchy of territories.
Identify any overlapping territories and decide the order in which the application chooses them.
Rank any overlapping territories from 1 to N to determine the order. A territory with a lower number wins over a territory with a higher number rank within the same level of the hierarchy. In case of a tie, the assignment is made randomly. The Territory Assignment Program for Sales objects assigns the tied object to the territory that was created first.
Decide how many territories will win. For example, do you need one territory to win, which can be appropriate for service, or multiple winners, which can be appropriate for sales?
Decide if named account territories are needed.
Decide if you will use self service deployment for named account or geographic territories.
Test the strategy before implementing territories throughout the company and consider any future territory maintenance efforts.
Consider future territory maintenance efforts.
Note: Remember that the first territory setup is not necessarily the one that works best. You achieve optimum territory definition only gradually after much fine-tuning to accommodate user reactions and various interests in your organization.
This territory planning example utilizes best practices for a fictitious company with a typical sales model involving named accounts and geographic territories with overlay sales organizations.
Business World is a large manufacturer of computer equipment selling in the US and Canada. They organize their products into three families: servers, desktops/laptops, and storage. In their direct sales model, Business World has a named account sales force consisting of an account manager working specific accounts, and a telephony sales force working the remaining general pool of customers. A product overlay sales force works with account managers and telesales reps based on what products a customer is interested in. Each account manager or telesales representative works with three overlay specialists, one for each product family. In planning for FY2008, Business World is expected to have the following:
US and Canada have separate sales forces
The direct sales forces manage their top 200 key accounts
The general business telesales forces manage their remaining customer pool
The overlay sales forces service all opportunities for a product family and associated customers. There are 3 types of product specialists: Server, Desktop/Laptop, and Storage product specialists.
The following table shows the sales model:
|Account Managers||15 account managers manage 150 large, key customers||5 account managers manage 50 large, key customers||Account manager territories encompass all leads and opportunities associated to a key customer.|
|Telesales Representatives||6 Telesales representatives in 6 geographic territories||3 Telesales representatives in 3 geographic territories||Telesales representative territories encompass all leads and opportunities associated to a customer.|
|Overlay Product Specialists||3 product families, 9 product specialists for each product family and region||3 product specialists. Product specialists cover their mutually exclusive product families for the entire country.||Product specialists service all opportunities for a product family and geographic location and their related customers (they are only allowed to view customer information).|
Each account manager and telesales representative has a Server, Desktop/Laptop, and Storage product specialist.
Which business objects (transaction types) are being assigned to each type of resource? Are we defining territories to access customers, leads, or opportunities for account managers, telesales reps, and product specialists? Do you need to provide read access only or update privileges as well? To what territory usage are the business objects associated?
Business World is going to assign customer, lead, and opportunity transaction types for all territories assigned to account managers and telesales reps.
Territories assigned to overlay product specialists will have a transaction type of opportunity because they need update privileges for opportunities. Oracle Sales products (Sales and TeleSales) provide, by default, read only access to customers if a resource is assigned to the sales team of any of the customer's opportunities.
Investigate how to set up Oracle Territory Manager business objects in conjunction with the Oracle Sales data security model. If you need update access to customers, leads, or opportunities in Oracle Sales or Oracle TeleSales, then you will need to assign them in Oracle Territory Manager.
We enable the following matching attributes:
CUSTOMER NAME RANGE, to identify the 200 named accounts
COUNTRY, because this qualifier is used as a first criterion in identifying territory and offers the ability to support “Catch All” territories
POSTAL CODE, to create geographic territories composed of postal codes. One can use less granular geographic matching attributes such as state or province as well.
STATE, to create geographic “Catch All” territories for overlay product specialists
OPPORTUNITY PRODUCT CATEGORY, to create overlay territories for product specialists.
Review Choosing Appropriate Matching Attributes to analyze your particular situation in greater detail.
The hierarchy is largely designed for ease of maintenance and for the creation of “Catch All” territories. Hierarchies allow you to inherit matching rules and territory properties such as date effectivity and number of winners. Catch alls will be discussed later in Step 4.
For the Sales and TeleSales usage, different territory structures are supported for a business unit by selecting an independent number of winners within the top five levels of the territory hierarchy.
Under the Sales and TeleSales usage, we need to create a top-level territory representing Business World's FY2008 Sales territories. This FY2008 Sales territory will be effective from January 1, 2008 and does not have any transactional matching rules or resources. It is the top of the FY2008 Sales territories and is used to maintain the date effectivity of all territories underneath it and is used to set the number of winning territories (number of winners = 1).
Sometimes we create territories purely for organization and ease of maintenance. The territories under the US Catch All territory are an example of this.
Within the US and Canada, there are named account sales forces and geographic sales forces. We create two territories under the US Catch All territory:
US Named Accounts, with no matching attributes or resources
US Geographies, with no matching attributes or resources
Similarly, Canada has 2 territories called CAN Named Accounts and CAN Geographies underneath the Canada territory.
Oracle Territory Manager supports the self-service deployment of named accounts and geographic territories. Following are some things to consider before deciding whether or not to utilize this feature:
How often do your named account assignments change? If they change frequently, then a self service deployment is recommended.
How large is your territory administration staff? What is the required timeliness of activating territory reassignments? How important is it to expose territory ownership to the sales force?
If representatives have very few named accounts and there is little change, then the self service deployment may not be necessary. However, we believe visibility to clear ownership is a best practice.
How many named accounts do you have? At what granularity do you need to define named accounts, for example, by customer name range and country or by customer name range and postal code?
If you defined your named accounts by customer name range and country and have a manageable number of customers, use the Forms Navigator to create your territories. If you have many named accounts and need to define territories by customer name range and postal code, then use self-service named account territory management.
Self service allows your total cost of ownership to decrease, reduces your time to implementation, and at the same time empowers your sales management with the ability to manage their own territory distribution and midyear adjustments. Steps 6 (Define Catch Alls) to 11 (Rank) are still relevant regardless of your implementation, but can be managed and generated through the self service flows for geographic and named account territories.
Business World has separate sales forces for US and Canada so we will create two child territories underneath FY2008 Sales; one called US with a transaction matching rule COUNTRY = 'UNITED STATES' and another called Canada with a transaction matching rule COUNTRY = 'CANADA'. The COUNTRY matching rules will be inherited by all child territories, easing maintenance. These two territories will also serve as “Catch Alls” for exceptions of the assignment process. These are important because customers, leads or opportunities that do not find matching leaf node territories will fall into these “Catch All” territories based on their country matching attribute and can be assigned to a designated owner (typically the territory administrator) for resolution. The territory administrator should have customer, lead, and opportunity access.
Catch Alls are used to “catch” business transactions that fall through the cracks (leaf node territories) and usually are assigned to territory administrators. To be more exact, they “catch” all business transactions that fall into the catchall territory itself or any territory below it in the hierarchy that does not have a resource.
It is recommended that you use the term “Catch All” in the naming of these territories to help visually distinguish this type of territory.
From a business perspective, there are various types of territories. Organizations will pull particular customers from the general pool that they deem as critical and assign a specific resource to it. These are termed “named accounts”. In an attempt to organize the remaining pool of customers, general business customers are segmented by a simple criteria such as SIC code, state, or area code.
Named account territories may have rules utilizing the CUSTOMER NAME RANGE matching attribute in combination with a geographic matching attribute such as state or country. For example, if IBM is a named account you define a territory with CUSTOMER NAME RANGE like 'IBM%' and CUSTOMER NAME RANGE like 'International Business Machines%'. This assigns IBM to the account manager regardless of how many customers exist that begin with IBM or International Business Machines.
The US direct sales force consists of 15 account managers, each responsible for a territory of large key accounts. There will be 15 US named account territories as children of the US Named Accounts territory, one for each account manager. There will also be a catch all territory for the US named accounts. Similarly there will be 5 Canadian named account territories as children of the CAN Named Accounts territory plus a catch all territory.
Lowest level territories or leaf node territories should always have resources assigned to them and therefore also require access types to be defined. All account managers are associated to territories with customer, lead, and opportunity access.
See Choosing Appropriate Matching Attributes for a discussion on the selection of matching attributes for named accounts.
The decision to utilize geographic territories should be based on your business requirements. Following are questions to ask before implementing this type of territory:
What granularity is used to distribute your geographies?
Do you distribute territories based on geographical requirements such as states, provinces, or postal codes? This will help determine what geographic matching attribute you use.
In our test case the US and Canada each have separate telesales forces, which are responsible for all non-named accounts in a particular geography. The US telesales force has 6 geographic territories as children of the US Geographies territory. The Canada telesales force has 3 geographic territories as children of the CAN Geographies territory. Each geographic territory will have transactional matching rules containing the postal codes that the respective telesales representatives will be responsible for. All telesales representatives will be assigned customer, lead, and opportunity access.
The following chart displays this example.
We recommend that you implement Overlays in a separate territory hierarchy.
The desired business behavior is to find:
Either a named account OR a geographic general business territory
AND one overlay territory.
Increasing the number of winners in the FY2008 Sales hierarchy and putting the overlay territories underneath it would not accomplish this. However, with the FY2008 Sales hierarchy and number of winners set to one, Territory Manager selects either a named account territory or a general business territory. With a separate FY2008 Overlay hierarchy and number of winners set to one, Territory Manager selects a single overlay territory.
Under the sales usage, you will need to create another top-level territory representing Business World's FY2008 Overlay territories. This FY2008 Overlay territory will be effective from January 1, 2008 and does not have any resources. It does have transaction matching rules to distinguish it as an overlay hierarchy, for example:
OPPORTUNITY PRODUCT CATEGORY= 'SERVER',
OPPORTUNITY PRODUCT CATEGORY= 'DESKTOP',
OPPORTUNITY PRODUCT CATEGORY= 'LAPTOP',
OPPORTUNITY PRODUCT CATEGORY= 'STORAGE'.
It is the top of the FY2008 Overlay territories and is also used to maintain the date effectivity of all territories underneath it and is used to set the number of winning territories. Note the OPPORTUNITY PRODUCT CATEGORY matching attributes are necessary to distinguish these territories from Business World's geographic TeleSales territories.
Product specialists work opportunities, so we are going to assign Opportunity transaction types for all overlay territories.
We have separate sales forces for the US and Canada so we will create two child territories underneath FY2008 Overlay: one called USA Overlay with a transaction matching rule COUNTRY = 'UNITED STATES' and another called Canada Overlay with transaction matching rule COUNTRY = 'CANADA'.
Do you require Catch All territories and how are they organized? If Catch All territories are required, these need to be reflected in the hierarchy.
Is your sales management organized by product family or by geographic area? The territory hierarchy should closely mimic your sales management hierarchy for ease of understanding and maintenance.
Overlay territory hierarchy BY GEOGRAPHY
If Business World's overlay sales force is organized by geography and wants Catch Alls by geography, then we create three territories underneath the US Overlay territory:
“US East Overlay Catch All”, with transactional matching rules STATE = 'NY', STATE = 'NJ', STATE = 'MA', STATE = 'VT', and so on, and resource = Eastern Overlay territory administrator
“US Central Overlay Catch All”, with transactional matching rules STATE = 'IL', STATE = 'OH', STATE = 'AK', STATE = 'WI', and so on, and resource = Central Overlay territory administrator
“US West Overlay Catch All”, with transactional matching rules STATE = 'CA', STATE = 'NV', STATE = 'OR', STATE = 'WA', and so on, and resource = Western Overlay territory administrator
Similarly underneath the Canada Overlay territory, we create three territories:
“Server CAN”, with the transactional matching rule OPPORTUNITY PRODUCT CATEGORY = 'SERVER' and resource = Canadian server specialist
“Desktop CAN”, with the transactional matching rule OPPORTUNITY PRODUCT CATEGORY = 'DESKTOP' and OPPORTUNITY PRODUCT CATEGORY = 'LAPTOP' and resource = Canadian desktop/laptop specialist
“Storage CAN”, with the transactional matching rule OPPORTUNITY PRODUCT CATEGORY = 'STORAGE' and resource = Canadian storage specialist
As Canada has a smaller number of customers, three product specialists cover the entire country, one for each product family.
The US overlay sales force consists of nine product specialists, each responsible for a territory of product family and geography. As there is no fixed teaming of account managers or telesales representatives to product specialists, we have chosen to implement the overlays separately as children of the country overlay territory. There will be nine US overlay territories as children of the US Overlay territory, one for each product specialist. Each specialist will cover one of three geographies: East, West, or Central.
All product specialists will be associated to territories with customer and opportunity access.
Alternative overlay territory hierarchy BY PRODUCT FAMILY
If Business World's US overlay sales force requires Catch Alls by product family or is organized by product family, we would create three territories underneath the US Overlay territory:
“US Server Catch All”, with the transactional matching rule OPPORTUNITY PRODUCT CATEGORY = 'SERVER' and resource = Server territory administrator
“US Desktop Catch All”, with the transactional matching rule OPPORTUNITY PRODUCT CATEGORY = 'DESKTOP' and OPPORTUNITY PRODUCT CATEGORY = 'LAPTOP' and resource = Desktop territory administrator
“US Storage Catch All”, with the transactional matching rule OPPORTUNITY PRODUCT CATEGORY = 'STORAGE' and resource = Storage territory administrator
The same 9 US overlay territories created in the first example are re-shuffled underneath the appropriate US product family Catch Alls.
To the left of all the territory names in Figures 1, 2 and 3, is the rank of each territory. Named account territories are always ranked higher than geographic territories because a named account in California should fall in a named account territory and not the geographic territory that includes California. Catch Alls are always ranked lower than their associated territories. The rank applies to the territories on the same level in the hierarchy. Territories lower on a hierarchy always win over territories higher in the hierarchy. See Leverage Territory Ranking and Number of Winners for a detailed discussion of territory rankings.
Stand back and review your business requirements for sales territories. Ensure your territory implementation has met all your business requirements. How will you validate your territories are correct? Create and enable your territories on a test environment. Ensure you have an implementation plan in place that involves systematic validation and user acceptance testing. Don't forget about your ongoing maintenance requirements. See Migrating Territories for a discussion on how to migrate territories from one year to the next.
For any implementation to succeed in the long run, clear and consistent business processes should be implemented to complement your territory setup.
Territory hierarchies do more than organize your territories. They also organize your transactional matching rules, critical to improving the ease of maintenance. Child territories always inherit transactional matching rules.
If you are building a set of 100 representative territories exclusive to the US, it is a best practice to introduce a hierarchy layer representing countries which should include the transactional matching rule “Country = United States”. In this manner, all the 100 child territories will inherit its transaction matching rules. Instead of maintaining the rule in 100 territories it can be maintained in one parent territory.
These parent territories can also be assigned resources and act as “Catch All” territories in case the customer, lead or opportunity did not match one of the child territories. We have two catch alls in our business world example: one for Canada and the other for the US. Assigning a resource to “Catch All” territories will route customers, leads, and opportunities to the designated resource for resolution. Catch alls are typically assigned to territory administrators.
The number of winners refers to the number of winning territories allowed. The number of winners can be defined for territories up to five levels down the hierarchy for the Sales and TeleSales usage. It can only be defined at the top level for other usages. Territory rankings work in conjunction with the number of winners = “w” by selecting the top ranked “w” territories within a level of the hierarchy. Territories lower in a hierarchy have an inherent higher ranking compared to territories higher in the hierarchy. When a winning territory is found, all of the resources assigned to it are assigned to the business object.
A good example of this is the difference between named account territories and geographic territories. You don't want to have to maintain the exclusion of named accounts from the geographic territories explicitly. Rather, you would set the number of winners to one and use the customer name range matching attribute in the named account territories and rank these higher than the geographic territories utilizing postal code qualifier. The territory engine finds that both territories match but the number of winners and rankings dictate that the higher ranked named account territory wins.
The matching attributes used in defining named account territories are:
Customer Name Range and Postal Code
The Customer Name and Postal Code matching attribute identifies organizations through ranges of names or even partial name matches. Unless you have strict data quality management policies in place and there is only one occurrence of each customer, we recommend that you use the Customer Name and Postal Code matching attribute for named accounts.
The DUNS Number qualifier identifies organizations through DUNS number matches.
Registry ID from TCA
Party Hierarchy from TCA
These matching attributes identify TCA (Oracle Trading Community Architecture) organizations or customer sites.
Be careful not to confuse SIC code, geographic, and so on territories with named accounts. Many organizations will attempt to implement geographic or SIC code based territories as named accounts because they say they have always done it this way.
Questions to ask:
How many named accounts does the organization have?
If sales management claims that named accounts make up more than 20% of all TCA organizations, then they are likely to have incorrectly implemented named accounts.
For example, a Telecom territory is composed of 50 SIC codes. Implementing a Telecom territory as 20,000 named accounts would require a minimum of 20,000 CUSTOMER NAME RANGE qualifier rules. Clearly, it would be better implemented as a territory with 50 SIC CODE matching rules. There is a diagnostic test within the Oracle Diagnostic Framework for this.
How many named accounts does a typical resource have?
If sales management claims their reps have any more than a hundred named accounts, they are likely to have incorrectly implemented a simple territory as named accounts. Investigate how the business derived the set of named accounts. Typically, reps do not have the bandwidth to manage more than 100 named accounts and give them the proper attention associated to critical customers.
Does your business matching attribute fluctuate in the context of the business object you are assigning? Does it segment customers periodically based on a dynamic business matching attribute?
It is important to examine the fluctuation of the dynamic matching attribute in the context of the business object you are assigning. For instance in the credit card industry, customers are segmented by their total A/R balance every quarter into three territories (e.g., <$250k, $250k-$500k, >$500k) and customers maintain their segmentation even though their balances change.
In these cases, we recommend that you designate account classifications based on the dynamic matching attribute periodically and then use the account classification matching attribute in Oracle Territory Manager.
Using named accounts in lieu of geographic territories is an ineffective way to distribute a representative's territory. It is ineffective in terms of application performance, scalability, and ease of maintenance.
20,000 customers are segmented by the number of employees quarterly into three territories:
Less than 100 employees
100 to 1000 employees
Greater than 1000 employees
In this case, the territory assignment is quickly performed because there are only three rules.
Suppose that instead of maintaining three matching rules based on the number of employees matching attribute, you are maintaining a minimum of 20,000 customer name range matching rules. Territory assignment performance is directly correlated to the number of matching rules. Territory assignment will be slower with 20,000 matching rules than with three.
Best practices around matching rules are the simplest to follow because they are very concrete. Matching rules are converted to SQL and are subject to the same performance constraints. The use of the % wildcard as the first character of the matching attribute value prevents the use of indexes.
For how long are your territories active? Your sales organization may migrate to new territories yearly or quarterly and you want to use the existing territory hierarchy as a starting baseline. By following best practices, it will be easier to migrate territories to the next period. The trick is to define a territory start date at the top level territory, since all those below it will be gated by the start date property. Copy the top-level territory, which will automatically copy all the child territories as well. Rename the top-level territory and give it a new start date. Don't forget to go back to the old territory hierarchy and end date the top-level territory. You can create territories with a future start date in order to have your territories created and ready to become active.