Overview of Multiple Business Units in Sales

Setting up your enterprise structure with multiple business units (BUs) lets you have separate units that can perform different business functions and that can be rolled up into the management hierarchy.

In the sales applications, these business objects support the use of multiple BUs:

Contracts
Leads
Opportunities
Resource Organizations
Territories

Benefits of Using Multiple BUs

Before implementing a multiple-BU model, think about how your organization would benefit from implementing multiple BUs. This evaluation is, of course, specific to each organization, but some of the considerations include:

Access customer data across BUs: Realize a complete, single view of your customers and their interactions across all BUs.
Global reporting and forecasting: Get company-wide analytics for key stakeholders and executives. Forecasting and pipeline management can be done globally.
Standardize business processes: Use best practices and standardize sales processes across the enterprise.
Improve collaboration: Sales teams across BUs can collaborate on deals with the same customer, avoiding conflicts for similar products and improving cross-sell and upsell opportunities.
Reduce integration costs and data duplication: Fewer integrations are needed between sales and ERP systems, with improved data quality in the sales system.
Reduce duplicate development: Lower ownership costs for implementation and consulting resources. Avoid duplication of setups and company-defined development artifacts.
Reduce subscription costs: Users supporting different BUs don't need to sign on to multiple systems that require separate licenses.

Benefits of Multiple BUs

In the sales applications, depending upon your business needs, structuring your enterprise with multiple BUs can be beneficial within the sales business objects that support multiple BUs.

This table lists some of the ways your implementation can benefit from using multiple BUs:

Business Object	Usage or Benefit	More Information
Contracts	You can associate contracts with a BU, allowing them to be restricted by BU. You can specify some Contract Terms Library components at the BU level. For example, you can enable clause and template adoption at the BU level.	See the topics on setting up business units for the contract terms library in the Implementing Enterprise Contracts guide.
Leads	You can associate leads with a BU, allowing transactional data to be restricted by BU. You can select which assignment rules and assessment templates to use for your leads. You can use set-ID-enabled lookups to segregate lookup values by BU. This type of configuration lets you present different lookup values to users in different BUs.	See these topics in this chapter: Overview of Multiple Business Units in Leads Set Leads Business Unit Properties Add the Business Unit Field to Leads Map the Lead Business Unit for Territory Assignment
Opportunities	You can associate opportunities with a BU, allowing transactional data to be restricted by BU. You can use set-ID-enabled lookups to segregate lookup values by BU. This type of configuration lets you present different lookup values to users in different BUs. You can set profile options at the BU level, including the close opportunity required fields, default sales method, and territory assignment method. You can associate several opportunity attributes with a set ID, allowing them to be shared across reference data sets.	See these topics in this chapter: Overview of Multiple Business Units in Opportunities Set Opportunity Business Unit Properties Add the Business Unit Field to Opportunities
Resource Organizations	You can associate sales resources and resource organizations with a BU, thereby limiting the sets of data that the sales resources have access to.	See these topics in this chapter: Overview of Sales Resources and Multiple Business Units Associate Business Units with Resource Organizations
Territories	You can define the coverage of a sales territory by selecting a BU. Leads and opportunities identified with your defined BU are assigned to the territory.	See: Territories Defined with Business Units topic in this chapter Territories chapter section on dimensions

Here's an illustration of the different data types associated with multiple business units. The diagram shows master data, such as customer data, products, and users, independent of BU-striped data. The BU-striped data includes reference data, transactional data, and resource organization and resource user data.

The figure shows the interaction of the different data types, resource organizations, and resources.

Multiple BUs Use Case

The use case described here can help you understand the concepts associated with multiple BUs.

In the use case, Vision Enterprises is a global high-technology company with two divisions: Vision Corp., focused on software, and Vision Systems, selling high-end servers and engineered systems that combine hardware and software in a single stack. Both divisions operate globally across North America, Europe, and Asia Pacific regions, so they create BUs for each of these areas.

BU use case — This figure shows the use case. The diagram shows Vision Enterprises as encompassing its two divisions, Vision Corp. and Vision Systems. The diagram shows the two divisions, Vision Corp. and Vision Systems, as each encompassing three BUs: North America, Europe, and Asia Pacific.

Sales Administrator and Multiple BUs

Keep in mind that by default, sales administrators have access to only the data available in the BU to which they're associated. However, there are few access paths, such as organization hierarchy and default business unit, through which an administrator could get access to opportunities outside her BU.