ibela brd ea-research_tool_v1.2

Information Technology Tier 1 Business Requirements Document

(T1 BRD)

IB ELA: EA Research Tool

Revision #: 1.2

Last Revised: 06/24/2013

PPM #:

PPM Link:

Requested By:

Business Author: Michael Shields

BRD: EA Research –V1.0 of 70

Contents

1. OVERVIEW/ EXECUTIVE SUMMARY .......................................................................................................... 4

1.1. Executive Summary & High Level Scope.........................................................................................................4

2. BUSINESS REQUIREMENTS .................................................................................................................. 6

2.1. Overview ......................................................................................................................................................6

2.2. The EA Research Tool – Process Overview ................................................................................................... 10

2.3. EA Research Tool Use Cases ........................................................................................................................ 16

2.4. EA Research – Functional Overview ............................................................................................................. 18

2.5. EA Research Table of Requirements ............................................................................................................ 21

3. MOCKUPS/EXAMPLES ...................................................................................................................... 37

3.1. EA Research Tool – Main Screen Image with Summary Field Explanations .................................................... 37

3.2. Gather Potential EA’s .................................................................................................................................. 43

3.3. Admin Configuration Mockup/Example ....................................................................................................... 54

3.4. Intentionally Blank ..................................................................................................................................... 55

3.5. EA Research Scenarios – Functional Mockups .............................................................................................. 56

4. INTEGRATION ................................................................................................................................... 70

4.1. Systems ...................................................................................................................................................... 70

5. REVIEW AND SIGN-OFF ..................................................................................................................... 70


REVISION HISTORY

Version No.

Date Name (Alias) Description of Change

1.0 06/11/2013 Michael Shields Created a BRD

1.1 06/17/2013 Aaron Pinto Updated BRD (EA Research – Functional Overview, EA Research Table of Requirements, &Gather Potential EA’s sections) based on feedback from Gerard Power

Updated BRD (EA Research Table of Requirements) based on feedback from APJBusiness Operations – Paul Bailey

1.2 06/24/13 Aaron Pinto Updated BRD (EA Research Tool Use Cases, Data Sources, Application Launch Points, User Supplied Order Number, Export Results, Gather Potential EA’s, Mockup: Displaying Status Results sections) based on feedback from Mary Sullivan


1. OVERVIEW/ EXECUTIVE SUMMARY

1.1. Executive Summary& High Level Scope

The EA research tool’s purpose is to assist users in determining which EA’s belong to a ‘customer’.

Multiple VMware teams, partners, and large customers routinely expend effort to research which EA’s belong to a given customer.

Today, several internal/externally facing EA lookup tools exist, but they all require users to enter imprecise search criteria (name or email domain) and then use their knowledge of VMware data and business rules to try and interpret the customer EA relationships. This has proven to be, at best, inefficient; and at worst inaccurate and error prone. In the IB ELA project (which is sponsoring this tool), almost 20% of the IB ELA quotes undergo revisions due to inaccurate list of EA’s supplied for the IB pull. In addition, teams such as GSS licensing routinely spend multiple hours assisting the field with EA research on quotes where the customer is questioning the IB listed on the quote. The EA research tool will be designed to emulate much of the expertise that a VMware expert would employ to determine an accurate customer EA list. The end result will be that VMware teams involved with manual EA research and eventually Partners and Customers will have a tool that will significantly optimize this effort. The new EA Research tool will: 1) Automatically research VMware data sources to gather a list of potential EA’s associated to the ‘customer’. 2) Automatically evaluate and prioritize those EA’s to rank the EA’s which are most likely associated to the customer. Also allow the user to adjust those EA’s based on customer interaction. 3) Save the results for future use, so that subsequent EA research needs for that customer will be minimized.

Scope

Description Comment

In Scope

EA research tool (launch-able from VMStar as well as standalone) to produce a prioritized list of EA’s associated to that VMStar account/that EA.

Integration of VMStar, MyVMware, and Oracle data sources to be used in the research.

One tool searches all data sources

Functionality to save/manage EA relationships to support future transactions.

Allow different business functions to manage their EA/customer relationships (Support, Sales, Partner, or VMware corporate, each may have a different view of the EA to account relationship.)

Ability to select EA’s to display IB and launch the new one-click view

Integration with the new customer master system.

EA Research tool will leverage the EA relationships stored in that system.

Out of Scope – 1st

release (November)


EA data cleanup Data errors, EA merge/split tools, and EA governance will not be impacted by this project.

Feedback to Customer Master on changes to customer hierarchy based on saved EA relationships.

This is an important activity, but will need to be a process created under a separate initiative.

Partner, customer implementations The tool will be designed to anticipate customer/partner usage, but this will not be implemented in phase 1.

Success Criteria

These are under development as part of the overall ELA IB Program. However there are three key success areas that will be in play: 1) Percentage of time that the field needs to revise an ELA quote due to a ‘missing’ EA. 2) A reduction of work for the new EA Research team. 3) A reduction of effort for other teams involved in EA research (GSS licensing, License Deployment, etc.)


2. BUSINESS REQUIREMENTS

2.1. Overview

What are the EA Research and Quotable Asset View Tools?


EA Research: What is a ‘customer’? The EA research tool will be designed to support users that need to determine a set of EA’s that belong to the customer they are transacting with.

Company A Company A - Subsidiary Company B

EA#1 EA#2 EA#3 EA#4 EA#5 EA#6





VMware Corporate

VMware Sales - APAC

VMware Sales - EMEA

VMware GSS Tech Support

Partner

Different Teams Can Have Different View of the Customer EA Relationships

Designated teams will need to be able to evaluate potential EA’s with different criteria, view the selected IB, and then save unique EA relationships for the same ‘customer’

Different Customer Transactional Views:

VMware Execs

Sales

GSS

Compliance

Renewals

CSO

Partner

Customer

Corporate View: All EAs + Subsidiaries All of the EA’s associated to the VMware corporate relationship

X X X X X X X

Sales View: All EA’s in their VMware sales relationship This is the list of EA’s that are part of the customer which the ‘deal’ covers. Sometimes this is a territory slice, sometimes it a geographic slice, sometimes it is a specialized slice. √ Global (worldwide includes

X X

X


VMware Execs

Sales

GSS

Compliance

Renewals

CSO

Partner

Customer

subsidiaries) √ Named/Public Sector (By Sales Territory/Country) √ Federal (US, EA Type) √ Specialized ELA √ SMB?

Support View: All EA’s in their Support Relationship Large customers may set up their internal support structures to cover multiple EA’s (i.e. a global or regional helpdesk); or the EA’s may each have their own support; or a single EA can have multiple support contacts.

X

X X

Customer/Partner View: All EA’s in their customer definition Both partners and customers may have a different view of what EA’s make up a customer.

X X

Distributor View: All of the EA’s in their ‘Partners’ VMware and Distributors may have their own definition what EA’s make up a customer and their installed base.

X


EA Research Tool and One-Click View are building blocks for a future state The IB ELA project has two major recommendations which together will build a 1-click view of a customer’s quotable assets. The first recommendation is the EA research tool to help determine the EA’s that belong to a customer.. The second recommendationis an IBview that will show a field/customer/partner friendly version for the EA’s that make up that customer. This EA Research tool + 1-click view is a first step at a broader vision: While the phase 1 (November) focus is clearly targeted at the sales teams, the architecture and design of the EA Research tool should therefore anticipate use by customers and partners. One of the consequences of this is that both the EA research tool and the one-click view should be designed to be utilized at some point by MyVMware/Partner Central as well as a standalone tool:

EA Lookup Tool User Launch Point

November Release

Sales/GSS VMStar (Account Plan, Account, Opportunity)

Renewals, Compliance, EDG Standalone/BI Dashboard

Future

Customer MyVMware

Partner MyVMware/Partner Central

17 Confidential

One-click view

EA ResearchPossible Customer Future State Capabilities

Can define their own EA associations to facilitate

MyVMware cross EA views

Selected self-service view/request quote capability

Semi-automated compliance management

Identify/Request IB Adjustments

Possible VMware Future State Capabilities

Seamless integration with opportunities/account

planning

System suggests targeted possibilities for sales rep

Possible Partner Future State Capabilities

Partner self-service quoting capability

System suggests targeted possibilities for partner

Can define their own customer/EA associations to

facilitate customer reporting/management.

+

Should be

designed as the

first steps to

enable a future

state


2.2. The EA Research Tool – Process Overview

21 Confidential

EA Research Overview

EBS VMStar MyVMwareCompany

Master

EA Research Tool

BI Dashboard VMStar

EA Research tool + One click views in November can be launched directly from

VMStar or standalone from the BI Dashboard. After that, they will be made

available to Customers/Partners.

Tool will have

access to all

VMware data

sources such

that, it can

search data in

any combination

needed.

For example, it

can gather data

directly from

VMStar and use

it to search EBS

data

MyVMwarePartner

Central

November 22 TBD


TO BE Process Flow – Sales (High Level)

Click EA Research Button in VMStar

(Account, Account Plan, Opportunity)

EA Research Tool Generates EA List

Confirm/Refine EA ListLaunch 1-click View from

EA Research Tool

Generate Quotable Assets View + Validation +

MyVMware MappingShare with customer

IB Team Validation

Sales:Upload IB to Model N

Send to DD

Refine EA List (if needed)

Store EA Relationships

STOP

NO DEAL FOR NOW

NO VALIDATION ISSUES

Correct IssuesIB Team:

Upload Corrected IBto Model N

PROCEED WITH QUOTE

VALIDATIONISSUES

Field Team

IB Team

DD/GSS

Help Needed?


VMStar Account, Account Plan, Opportunity Pages

Standalone or VMStar Tab

EA Research Tool Automatically Researches For Related EA’s and Generates Results

User Selects the EA’s to Generate One-Click View of the Quotable Assets

Optional After Review, if EA’s are Missing, the User Refines Results (Supplies Additional Research Criteria)

Optional (User Adds Additional Accounts for Research, i.e. Subsidiaries)

User Supplies Initial Research Starting Point(s)

System/User Saves EA Relationships for Future Use

VMStar Account

EA Research Tool Process


Process Steps (Mockup) 1. Rep launches tool (VMStar Opportunity, Account Plan, or Account)

2. EA Research Tool Produces Initial Results


3. Rep selects EA’s and clicks to show quotable assets

4. Share with customer/refine as needed. If EA research assistance needed, contact EAR team.

5. If quote, and no validation errors, pass to deal desk. If validation errors, pass to IB Team.


6. Results Saved for future use


2.3. EA Research Tool Use Cases

Use Case(s) Who EA Research Tool Comment

Sales

Research potential deals Sales is creating an Account Plan/exploring deals with large customers. They want to determine which quotable assets the customer has. They then sit down with the customer and discuss interests in ELA for all/any of these previously purchased products + any new products (gaps)

Field/Partner Research using VMStar account as starting point.

ELA IB Initial Quote Field is preparing an ELA quote for the customer. They want to present the initial quote to start the negotiation process. The initial quote should contain all of the quotable assets for the ‘customer’

Field, DD, Partner Research using VMStar account as starting point.

Identify/Resolve ELA IB Quote Issues Quote is underway. The customer has raised questions as to why a product has been included/or why a product is missing. Field needs to determine if this is because of an EA being excluded/included; or because of another issue.

Field, DD, GSS, Partner, Customer

Basically, the customer has looked at the IB pulls associated to the initial set of EA’s and indentified product/license keys that are ‘missing’ Will need to expand the starting points to include subsidiary names, license keys, contracts, or orders

A paused/previous opportunity/quote has come back to life. Customer had expressed interest in a deal but needed to pause/slow the process (budget, etc.). Now, sometime later, the opportunity becomes seriously active again.

Research using VMStar account as starting point.

Have you ever been a customer? ISR has received a campaign response or is trying to penetrate a ‘whitespace’ company. They are trying to identify a potential lead. They need to determine whether the contact or ‘customer’ has ever done business with VMware.

Field, Marketing, ISR, LDR

EA Research tool needs to be able to research based on contact information + be able to access and evaluate person parties.


Use Case(s) Who EA Research Tool Comment

Renewal Quote Renewals needs to research customer to determine current renewal opportunities + co-termination opportunities

SSI, Sales Need to discuss with Renewals – Contract number/EA Name as starting point?

License Compliance Determine which EA’s belong to a ‘customer’ to validate the accuracy/completeness of license compliance reports submitted by the customer

Compliance, CSO, Customer

EA Name, ELA Contract number as starting points

Resolve IB Issues (Post Sales) Order has been booked; customer discovers missing/deactivated licenses.

Customer, GSS, CSO, Compliance

EA Name as starting point.

Escalated/Problem Customer Understand all of the sales, support and other transactional history related to the ‘customer.

Execs, GSS, Partner


Customer Management/Reporting Determine which EA’s belong to your function’s definition of the customer such that you can report/manage your customer relationship.

Execs, Sales, Partners

EA Name as starting point

EA Governance Need to analyze the EA’s belonging to a customer to determine EA merge/split/maintenance activity

GSS, CSO, Customer, Partner



2.4. EA Research – Functional Overview

Functional Overview

EA Research Tool Function Comment

Automatically gather up a list of potential EA’s belonging to the ‘customer’ by matching them to a series of categories. When launched from VMStar, the user is not required to enter any search criteria. The starting point will be a VMStar account

Using a combination of known relationships, transactional information, and company/user attributes produce a list of ‘potential’ EAs associated to an account. ‘Potential’ should mean that there is at least one significant data point that suggests the EA may belong to the account in question.

Evaluate and prioritize those EA’s according to the user’s purpose:

Based on the user’s purpose, evaluate and prioritize the list of potential EA’s to determine which EA’s probably belong to the customer and those that probably don’t . A key component will be to explain to the user why EA’s received a categorization such that the user can (in most cases) make a judgment call without further EA research. Possible functions requiring different evaluation criteria: √ ELA IB Quoting √ Renewal Quoting √ Compliance Validation √ Customer Escalation Management √ ‘Customer’ Relationship Management/Reporting √ EA Governance √ Partner √ Customer

Save the EA relationships for subsequent use .

Once the potential EA’s have been retrieved and evaluated, the results should be stored for future use: √ There can be different EA relationships for the same ‘customer’ (i.e. the Partner, Sales, VMware Execs can have different definitions of the EA’s that belong to a customer. √ Storage mechanism/structures should complement the Customer Master and be available in VMStar.

Configuration – Allow an application administrator to configure profiles which will control the behavior of the EA research tool and One-Click View

√ For each profile: 1) Configure search categories and matching rules. 2) Configure One-Click View layout and validation rules. 3) Configure how EA relationships are stored for future use.


Data Sources For Gathering Potential EA’s

Data Source Description Value Comment

System

Company Master VMStar UUID link to Customer Master which will have all related Parties/EA’s associated to that UUID.

High Customer Master 1.0 will be built from DUNS relationships plus some additional criteria

Previously stored EA relationships

Saved EA relationships (a set of EA numbers associated to the ‘customer’

High The new EA research team will start saving EA relationships during the June pilot.

DUNS DUNS Number associated to the VMStar ID linked to EBS parties with the same DUN

Medium This may duplicate the customer master functions

Hoovers/Google May contain subsidiary names. TBD

Transactional

Orders/Bookings Orders contain sold-to-contacts, addresses, partner information, and potentially contain EA numbers

High

Some orders have VMStar relationships

Support Cases Contain contacts, may also contain EA associations.

High

If cases are associated to the VMStar Account, search to see if any EA #’s have been associated to those cases. In VMStar if there are other accounts with the same (normalized name) + VMStar territory, check cases for those accounts as well.

Historical Quotes ELA IB quotes submitted through Model N may contain a list of EA numbers associated with the initial IB pull.

Medium

Contracts May contain subsidiary names if the parent company is buying on behalf of the subsidiary.

High

License Keys

Customer/partner may have a specific license key

High If supplied by the customer.

Contact Names

VMStar, Party Contacts,MY VMware Super User, Procurement Contact

Email addresses High May match the SU/PC/Admin for an EA.

Once Above EA’s are Gathered

Domain(s)

For the domain’s associated to the gathered EA’s, search for any other EA’s that have the same domain.

High


Data Source Description Value Comment

Normalized Name

Do any of the gathered EA’s share the same normalized name with other EA’s

High Normalized name is the EA stripped of spaces, special characters, and patterns such as Inc, Corp, GMBH….

Address EA Addresses, Party Site Addresses. Medium


2.5. EA Research Table of Requirements

Requirement considerations 1. We are trying to build a tool which, by excellence, will replace the current EA lookup tools. 2. With minimal user interaction, the tool will emulate much of what an ‘expert’ would do to research and develop a list of customer related EA’s 3. Too many possibilities are bad as too few. Just because we can search/consider almost everything doesn’t mean we should. 4. We should provide information to help the field/customer actually confirm which EA’s actually belong to the customer.

#

Priority

Requirement

Comments/Open Questions

1.0 Application Launch Points

1.01 Must VMStar Account Page EA Research tool should be able to be launched from the VMStar account page.

In this case: 1) User would click on the launch button 2) EA Research tool would run with the VMStar account research field pre-populated 3) User optionally searches, adds additional Account Names 4) User triggers EA Research tool 5) EA Research tool would run and automatically start to gather potential EA’s associated to the EA on the account page. 6) Display EA Results.

1.02 Strong Want

VMStar Account Plan Page EA Research tool should be able to be launched from the Account Plan Page.

Process same as VMStar Account Page.

1.03 Must VMStar Opportunity Page EA Research tool should be able to be launched from the opportunity page. In this case the EA Research tool would start its research using the VMStar Account associated to that opportunity.

Process same as VMStar Account Page.

1.04 Must BI Dashboard EA Research tool should be able to be launched directly from the BI dashboard. In this case, the user would supply the initial criteria that would serve as the starting point for the EA research.

√ When launched from the BI Dashboard, the user must supply the EA or VMStar accounts to be researched.


#

Priority

Requirement


1.05 Must One-click view (Refine Results) When the user has used the one-click view to display IB, they should be able to invoke the EA Research tool to help refine results.

In this scenario, the research starting point would be the EA’s that had been selected for the one-click view User would add additional EA’s for research; or add/subtract EA’s to display IB for. See mockup/further description in section 3.5 below.

1.06 Strong Want

VMStar TAB EA Research tool should have a tab on the Sales and Call Center views.

When launched from the tab, the tool should b launch as if it had been launched from the BI Dashboard (user must supply initial criteria)

1.07 Strong Want

Admin Portal EA Research tool can be launched from the account details page.

In this case, the EA research tool would launch and be pre-populated with the EA whose details were being shown. See section 3.5.7 below for a mockup.

1.08 Future Build for future launch points Application should be built such that it can be exposed to the customer and partner and launched from MyVMware/Partner Central.

TBD where the research would start if launched from those applications.


#

Priority

Requirement


EA Research Starting Points User must supply at least one VMStar account or EA to start the research process. If launched from a VMStar page or from the Admin Portal, the initial values are pre-populated.

Automatic (When Started from VMStar)

2.01 Must Pre-Populate the Accounts to be Researched field with the VMStar Customer ID When the user launches the EA Research tool from the VMStar Account, Account Plan or Opportunity pages; the system should pre-populate the first Accounts to be Researched field with the VMStar Customer ID of the account on the page.

√ If no account account/opportunity has been selected, the launch button should be inactive.

Automatic (When started from the Admin portal)

2.0.2 Strong Want

Pre-Populate the Accounts to be Researched field with the EA Number When the user launches the EA Research tool from the Admin Portal EA Details page; the system should pre-populate the first Accounts to be Researched field with the EA Number on the EA Details Page.

√ If no account account/opportunity has been selected, the launch button should be inactive.

User Supplied (When starting from VMStar tab or BI Dashboard OR when refining a One-Click View result)

2.03 Must User Supplied EA or VMStar Account Name (or number) User can search for EA’s or VMStar Accounts by Name (or number)

√ User can select a search type (EA Name, or VMStar Account Name) and enter a search string (with wildcards): 1) EA or VMStar Accounts are displayed (depending on the search type). 2) User selects 1 or more EA’s or VMStar accounts to research √ Before initiating the search, the user may use additional search type(s)/search string(s) and select other accounts to be researched √ When desired EA’s are selected, the user clicks a button to initiate the research process. √ System should recognize whether the user has entered an EA Number or Customer ID. If


#

Priority

Requirement


a number has been entered, only that EA/VMStar account number should be displayed.

2.04 Must User Supplied Order Number User can enter a specificVMware Salesorder number (no wild card or partial key searching)

√ User enters an order number 1) If the order number is found, the system displays the EA associated to the order. 2) User may select that EA to start the research with. √ User may enter other criteria and select other EA’s before clicking a button to initiate the research process.

2.05 Must User Supplied License Key User can enter a specific license key or cloud key (no wild card or partial key searches).

√ User enters a license key 1) If the license key is found, the system displays the EA associated to the key. 2) User may select that EA to start the research with. √ User may enter other criteria and select other EA’s before clicking a button to initiate the research process.

2.06 Must

User Supplied Contract Number User can enter a specific contract number (no wild card or partial key searches).

√ User enters a contract number 1) If the contract number is found, the system displays the EA associated to the number. 2) User may select that EA to start the research with. √ User may enter other criteria and select other EA’s before clicking a button to initiate the research process.

2.07 Must User Supplied EA Domain User can enter an email domain (wildcard searches allowed). (This domain search will search for any EA where the SU/PC for that EA has a domain that matches).

√ User can enter a search string (with wildcards) to search all active EA’s with the associated domain: 1) Search Results are displayed. 2 User selects 1 or more EA’s to be used to start the research √ Before initiating the search, the user may enter additional search string(s) and select other EA’s (to search for subsidiaries) √ When desired EA’s are selected, the user clicks a button to initiate the research process.


#

Priority

Requirement


2.08 Strong Want

User Supplied Combined Party/EA Name Search both EA Names and active Party Names. If Party names found, retrieve the EA’s associated to those Party Names. Do not display duplicate EAs.

√ User can enter a search string (with wildcards) to search all active EA and Party Names 1) Search Results are displayed. 2 User selects 1 or more EA’s to be used to start the research √ Before initiating the search, the user may enter additional search string(s) and select other EA’s (to search for subsidiaries) √ When desired EA’s are selected, the user clicks a button to initiate the research process

2.09 Strong Want

User Supplied Combined EA Domain/Party Domains Search all domains associated to the EA and Domains associated to the contract users of the party. If Party Domains found, retrieve the EA’s associated to those Party Domains. Do not display duplicate EA;s.

√ User can enter a search string (with wildcards) to search all active EA and Parties for a domain: 1) Search Results are displayed. 2 User selects 1 or more EA’s to be used to start the research √ Before initiating the search, the user may enter additional search string(s) and select other EA’s (to search for subsidiaries) √ When desired EA’s are selected, the user clicks a button to initiate the research process

2.10 Future Future Criteria (Partner) May include distributor order number, partner P.O. number.


#

Priority

Requirement


2.11 Strong Want

User Supplied Instance Number User can enter a specific Instance order number (no wild card or partial key searching)

√ User enters an Instance number

2) If the Instance number is found, the system displays the EA associated to the instance number.

2) User may select that EA to start the research with. √ User may enter other criteria and select other EA’s before clicking a button to initiate the research process.

Gather Potential EA’s Once the EA/VMStar accounts to be researched are selected and the RESEARCH button is pressed, the system will gather all EA’s that are potentially related to this account.

See section 3.2 below for details of sources and logic.

Configuration Requirements See configuration mockup in section 3.3 below.

3.01 Strong Want

Configure which research rules use/exclude System should allow the business to turn specific search rules on or off without having to release a new application version

√ The logic for gathering other potential EA’s should be segmented into blocks which can be run independently of another block of logic. √ These blocks of logic should be able to be turned on or off by an application administrator in case a block of logic proves to be a performance issue/or adds minimal value. √ Logic blocks should be able to be turned on or off for a particular target audience, i.e. we may not want to have the EA research tool execute certain blocks of logic for partners or customers. For example, say the EA Research tool has 3 blocks of logic: 1) VMStar UUID or EA Number to search Customer master. 2) VMStar DUNS number to search Oracle Parties 3) VMStar cases associated to the CUST ID that have EA’s associated to it, And then we discover, in practice, that the VMStar case check adds little value. The business should be able to request that logic block 3 be turned off (blocks 1 & 2 would still execute). √ Blocks can be set up per profile such that a


#

Priority

Requirement


given profile can execute different search blocks than another. This will be crucial for future partner/customer profiles. √ If all blocks for a category are turned off for a profile, the category should be hidden from users with that profile

3.02 Must Deep Search Option Rule blocks may be configured by an administrator as ‘standard’ or ‘deep’

The research tool will automatically execute standard blocks. If the user selects the ‘deep’ search option, the additional ‘deep’ rules will be executed as well.

3.03 Must Research Progress System must display a regular status on the research and give the user the ability to cancel if the research should get ‘stuck’ from a performance standpoint.

See example in section 3.5.2

4.0.1 to 4.10.1

Search rules/sources for potential EA’s See section 3.2 below for a detailed list of the requirements for sources to search and the search rulesfor each source/category.

Prioritize Potential EA’s

5.01 Must EA Evaluation Rules Once potential EA’s are gathered, they will be categorized in one of three classifications: Strong, Probable, Possible Prioritization rules are based on the categories and match strengths calculated when gathering potential EA’s. Prioritization scoring should be configurable by the Application Administrator.

Setting Strong Match Priority √ An EA that scores in any of the following will receive a ‘Strong Match’ priority: 1) ‘S’ Match in Saved Relationship or Domain Match or Normalized Name Match or Customer Master + at least 1 other category ‘S’ match. 2) 3 or more ‘S’ matches in any categories. Setting Probable Match Priority √ An EA that scores any of the following will receive a Probable Match priority: 1) 2 ‘S’ Matches in any categories 2) One ‘S’ Match in any non-transaction category (not a match in cases, orders, or quotes) and at least 3 ‘W’ matches. Setting Possible Match Priority √ Any other EA that receives at least 1 ‘W’ match in any category should receive a ‘Possible’ classification.


#

Priority

Requirement


5.02 Strong Want

Configure rules for Strong, Probable, and Possible categories. System must allow the application administrator to configure the rules for calculating the 3 priority categories

√ System should allow the Administrator to create multiple rules for each category. √ Rules should be a combination of the match strength of any match category (Save EA’s, DUNS, etc.) and counts of match strength categories. See section 3.3 for mockup

UI Fields/Functions See section 3.1 for annotated screen image

Application Setup/Configuration

6.01 Strong Want

Application Configuration Button This page has two sections related to the EA Research tool: Profile Setup (Available only to the Application Administrator) User Preferences (Which can be adjusted by the user)

Profile setup is hidden if the user is not an application administrator. Profile setup capabilities: Add, delete a profile 1) Create a new profile; delete an existing profile; modify an existing profile. EA Research Tool 1) Configure which research rules are executed for which profiles 2) Configure for a profile if a search rule is ‘deep’ 3) Configure the prioritization rules for the 3 categories (Strong, Probable, Possible) 4) Configure default fields to show in EA Results. User Preferences 1) Results fields to show (from a selected list) 2) Default filter settings See section 3.3 Admin Configuration Mock-up/Example

6.02 Strong Want

User Profile User is assigned a profile based either on their VMStar role (if launching from VMStar, their Admin Portal User, if launching from the MyVMware Admin Portal, or a BI Dashboard Profile. This profile determines the behavior of the research processes, and the format of the one-click report.

See section 3.3 Admin Configuration Mock-up/Example


#

Priority

Requirement


User Selected Research Option

6.04 Must Standard/Deep Search Deep search option causes the research tool to execute search rules classified as ‘deep’ in the application configuration.

√ See table 3.2 below for which rules are categorized as ‘deep’ by default. √ Application administrator can change rule configuration from standard to deep and back again as needed.

Research Accounts (VMStar/EA Accounts that will be used by the EA research tool to initiate its research )

6.05 Must Enter VMStar/EA Accounts System must allow the user to select one or more accounts to be used to generate the research process. User cannot directly enter a number. They must use the search function provided

√ If the application has been launched from a VMStar, this field will be pre-populated with the VMStar account. √ If the application is launched from the Admin portal, this field will be pre-populated with an EA Number. √ If the tool is standalone, the user must supply at least 1 EA (they can use the research tool to search EA’s and select one). √ User can add additional VMStar or EA numbers as needed. [6.07 below] (they can search directly on a number). See requirements 2.03-2.10 above for the specific search criteria allowed.

6.06 Must Research Accounts Button Pressing this button initiates the research process for the selected accounts.

Button is grey if there is not at least one VMStar or EA Number in the Accounts box.

Add Additional Accounts for Research User uses drop-down menu to select the type of search they want to perform:

6.07 Must EA/VMStar Account Lookup Button Pressing this button reveals the fields which will allow the user to search for accounts to be used for EA research:

√ See 2.03-2.10 above for search options. √ Results are displayed in the form of # + Account Name √ Users can move selected EA’s into the


#

Priority

Requirement


1) Search Type 2) Search String 3) Search Results Box 4) Ability to select/deselect accounts to be sued for research.

Accounts to be Researched field. √ Users can de-select accounts to be researched √ No pagination – should allow the user to scroll through results. See section 3.5.5 below for mockup + more on this function.

Display Research Results – the EA Research tool will display the following results for all matching EA’s.

6.08a Must Result Categories System will categorize the EA’s gathered as Strong, Probable, or Possible; and then display the appropriate EA’s within each category.

See 5.01 above

6.08b Want Numbers of Results System should display the number of EA accounts that fit into each category.

6.08c Must Filter Results System must allow the user to filter the results that were gathered during the research process.

√ Filter by country √ Filter by domain √ Filter by name (including a contains filter) √ Filter out any category combinations (i.e. remove DUNS matches)

6.08d Must

Export Results System must allow the user to export the results into an Excel Spreadsheet format

√ The list of EA’s retrieved and all related details fields should be exported. √ The prioritization levels (strong, probable, and possible) should be moved to Excel columns such that the results can be sorted alphabetically.

6.09 Must EA Number Number of the EA.

6.10 Must EA Name Name of the EA.

6.11 Must Country(s) Displays the countries associated to the EBS party/party sites that make up the EA. Show the 2 digit ISO code.

√ For each party associated to the EA; inspect all of their sites. Display each country code in the field separated by commas. √ User can drill into this field and display the


#

Priority

Requirement


list of parties and unique sites that are associated to theEA. See section 3.4.2 below for mockup

6.12 Must Want

Note (System Generated) Contains a note that the system generates using specific rules. The intent of this note is to give advice to users about which may help the user determine the overall usefulness of the EA.

√ If the EA has no active IB associated to it; display the message ‘No Active IB’. No IB where Status Code is equal to ACTIVE, CNV_ACTIVE, DPL_HOLD, ELA ACTIVE, EXPIRED, HOLD, PENDING RENEWAL, QA_HOLD, RENEWED_ACTIVE, RENEWED_EXPIRED, SIGNED

Also, if the above conditions are met, the system should also check to make sure there are no BCS/MCS associations. √ If the EA is a person party, display the message ‘Individual Account’ √ If the EA is of type ‘Federal’, display the message ‘Federal Account’ If the EA is of type ‘Global’ display the message ‘Global Account’ √ If the EA is ‘Do Not Touch’, display the message ‘do not touch’ [Note, this requirement is dependent on the MyVMware enhancement being implemented] √ If the EA contains an active ELA contract, then display ‘Active ELA’. √ If there have been any merges, or LATF’s for the EA; display LATF (IN) for licenses transferred in; display LATF out (if licenses were transferred out). √ Display any information if the EA contains Merges, Splits, ACF’s, iACF’s, non-std LATF. An account note may have multiple values.

6.13 Strong Want

Sites Show the number of unique sites associated to the EBS Parties which make up the EA.

√ A ‘unique’ site is a city + country combination within the EA. If party 1 has a site at 101 Main Street, City A, NZ; and party 2 has a site at 345 A Street, City A, NZ; then there would be only one site displayed √ User can drill into see a list of all unique sites.


#

Priority

Requirement


See section 3.4.2 below for mockup

6.15 Must Domain Show the domain(s) associated to the EA.

√ Display the domains associated to the EA: 1) For each party associated to the EA; inspect all of the domains associated to the contract. 2) Display each unique domain. √ User can drill into see a list of unique sites + domains. See section 3.4.2 below for mockup

6.16 SU Name/SU Email Display the SU Name + Email for each EA

6.16.1 Strong Want

Procurement Contact name & email Display the PC Name + Email for each EA

Category Matches

6.17 Must Categories: Company Master Saved EAs DUNS Orders Cases Quote Email Domain Normalized Name Address Contact SU/PC License

√ See section 3.2 below for rules on how these fields get populated. √ Users can click/hover on any match criteria to see the rule/data involved in making the match. (see section 3.4.3 mockup below)

One-Click View

6.18 Must One Click View Selection User can select each EA in the results to display the IB in the One-Click view.

√ There should be a ‘Select All and ‘Select All Strong/Probable) option. √ Users may deselect an EA that has been selected.

6.19 Must Show Quotable Asset Button Clicking on this button will launch the one-click view which will display the IB for the checked EA’s.

√ Clicking this button will also save the clicked results in the save relationships (see 7.01 to 7.08 requirements below) √ When pressed, the One-Click view would be launched and any EA’s selected in the EA research tool would be used to generate the IB in the view. √ The EA research user can also select EA’s


#

Priority

Requirement


individually, and launch separate one-click views for each. √ User should be able to do other EA research activity while the One-Click view(s) are being generated; i.e. the One-Click view should not lock up the EA research tool when it gets launched.

Saving EA Research Results Both ‘interim’ and ‘final’ EA relationships need to be saved for future use.

Use Cases: 1) Use as a basis to refine the EA results for the current quote/deal/transaction. 2) Use as a starting point for a future transaction for that customer. 3) Use for BI reports on a ‘Customer’ See section 3.5.6 below for mockups, and a series of saved relationship scenarios.

7.01 Must Ability for the EA Research tool to save results of EA Search For each EA that the user selects ‘Show Quotable Assets’ for and presses the Show Quotable Assets button, the system should save those EA’s for future use.

√ If no relationship exists, a new relationship is created. √ If, at any time, the user changes the EA numbers selected and clicks on the show quotable assets button (this includes returning from the One-click view): If an EA was ADDED, the system should automatically add the EA to the relationship. If an EA is SUBTRACTED then the system should prompt the user to ask whether they want to have the system remove the EA from the relationship (we want to prompt because an EA can be removed as part of the sales negotiation process. √ There is no hierarchy; a relationship is a set of EA numbers. √ Sales relationships are tied to a VMStar account. Other relationships are tied to other


#

Priority

Requirement


EA numbers √ In the future, relationships can be attached to a partner ID. √ Only one Sales relationship is allowed for any VMStar customer ID. √ An EA number can be associated with multiple relationships. See section 3.5.6 below for mockups, and a series of saved relationship scenarios.

7.02 Must Ability to View and Manage Saved EA relationships with the EA Research tool. Users should be able to search for a stored EA relationship, and update them as needed

√ Search by EA Number, EA Name, VMStar Customer ID or Account Name. √ Users can only modify relationships made by the same profile (sales, support, etc.) but can view any relationship. √ Users can: a) Delete the relationship b) Add/subtract an EA c) Create a new EA relationship d) Change the status of a relationship e) Add a comment to a relationship.

7.03 View: Must Manage: Strong Want

Ability to View and Manage Saved EA relationships in VMStar.

√ Users can access the Sales EA relationships from the VMStar account page. √ Users can: a) Delete the relationship b) Add/subtract an EA c) Create a new EA relationship d) Change the status of a relationship e) Add a comment to a relationship.

7.04 Strong Want

Relationship by Profile Each profile can establish its own EA relationships for a given EA or VMStar Account.

√ A relationship can exist for each unique profile, i.e. GSS and sales can have their own relationship for an EA or VMStar account. √ In the future, partners and customers may have their own relationships


#

Priority

Requirement


√ The relationship must be unique for each profile, i.e. sales cannot have two different relationships for the same VMStar account.

7.05 Must Status – ‘Interim’ and ‘Complete’ Relationships should have a status which can be set to ‘Preliminary’ or ‘Completed’.

√ Status at creation = Preliminary. √ Users with the same profile can update the status to ‘Completed’ in the EA research tool or VMStar. √ Users can move the status from preliminary to completed and back to preliminary as needed. √ If the opportunity associated to the sales relationship is changed to closed-won, then if there is an EA relationship associated to account, it will be changed to complete status.

7.06 Must Store date and time stamp + who last modified the relationship Each relationship should have a date/time stamp which preserves the create date and time, and a separate date/time for when the relationship was updated. Who created/last updated should be preserved.

7.07 Strong Want

(VMStar) System prompts sales rep to confirm save EA relationship when opportunity status is changed. If the Rep changes an opportunity with and associated ELA quote to a Closed Won/Closed Lost status, then the system should prompt the rep to confirm the stored EA relationship.

System should show the user a summary of the EA relationship and prompt them to: Confirm, Update, or Delete. Clicking on ‘Confirm’ will change the status of the EA relationship to ‘complete’ Clicking on ‘Delete’ will remove the relationship. Clicking on ‘Update’ will take them to the VMStar Account relationship page.

Security

8.01 Strong Want

In the future, certain profiles will have restricted data access/views. TBD – Partner TBD – Distributor TBD -- Customer

System should be set up to allow certain data fields to be excluded from access to certain profiles.

8.02 Must VMware Access VMware access should be restricted to

For internal users, there is no restriction once you can access the system. All data will be available.


#

Priority

Requirement


authorized users who have access to VMStar, the Admin Portal, or Dashboard BI.

User Search Histories

The objective here is to keep track of how users are actually using the system (what search criteria, which sources, and how effective the research is.

9.01 Must Launch Points Keep track of how the user has launched the application.

√ Which VMStar pages √ From VMStar Tab √ From BI Dashboard √ From Admin Portal

9.02 Want Popup Survey Periodically, launch a context pop-up survey to gather user feedback on search effectiveness.

√ Application administrator can configure the frequency for which a survey would pop up to capture in-context feedback. √ Application administrator can designate specific questions to ask.

9.03 Must EA/VMStar Research Names Keep track of which/how users are supplying Accounts/EA Names for EA research and WHAT those values are.

√ Names being researched √ Search types/search strings √ Use of wildcard characters √ Accounts pre-populated from VMStar/Admin lookup

9.04 Must EA Research for the same account How often research is repeated for the same account

√ Number of unique times the Research Accounts button is pressed for the same VMStar Account/EA (or the same set) √ For those unique times, what were the changes to the additional accounts √ Which EA’s were selected for One-Click View.

9.05 Strong Want

Results/Filters

√ Numbers of results in each priority level (Strong, etc.)


#

Priority

Requirement


Keep track of the number of results for each research, and the filters used.

√ Which filters are used to filter results.

9.06 Must Research Times Times it takes to execute the research.

√ Elapsed time from when Research Button is pressed until results are displayed. √ Elapsed time for each rule to be executed.

9.07 Want Drill Down Number of times the drill down fields are being used.

√ Site/Domain Information √ Match rules (Category/Rule)

9.08 Strong Want

Saved EA’s Number of times EA hierarchies are accessed and modified by users.

√ Through VMStar √ Through EA Research tool.

3. MOCKUPS/EXAMPLES

3.1. EA Research Tool – Main Screen Image with Summary Field Explanations

Here is a mockup of the EA Research tool followed by a section by section summary description of the fields and functions. For more details, please see the requirements tables or the extensive scenario mockups/examples in sections 3.3 and 3.5,


Section Description

Field Access Purpose

User Profile Read only Controls application behavior (which research rules to use)

Application Configuration Accessible to all; brings you to a new page Used to add/modify profiles and set


with three tabs (EA Research Setup, Quotable Assets Setup; and User Preferences) Setup tabs are available only to the application administrator.

user personal preferences

Manage EA Relationships Accessible to all; brings you to a new page to search/manage saved EA relationships. Can also be accessed by drilling into the Saved EA match category.

Allows users to view saved relationships; and to modify relationships for their own profile type (sales can modify sales relationships only)

Field Behavior Purpose

Accounts to be Researched Can only be set by being pre-populated at launch or through selection on the EA/VMStar account lookup.

Determines accounts to be researched. Must be either an EA or VMStar number

Research Accounts Accessible to all; must have at least one research account populated to be active.

Starts research process.

Search Preferences Accessible to all; defaults to ‘Standard’ Determines whether or not ‘deep research rules are applied. Deep rules are more through, but may take a lot longer and may return some EA’s of minimal value.

EA/VMStar Account Lookup Accessible to all. Used to add accounts to be researched (over and above the pre-populated ones).



Search Criteria Available to all. Drop-down menu. Must select 1 value. Defaults to EA Name.

Determines the type of search. See requirements for full list of criteria.

Search String Accessible to all; user enters search string

String to be used in the search.

Results Shows results of the search type/string; VMStar Customer ID or EA Number + Name. No pagination, must allow for deep scrolling.

Allows user to view potential research accounts.

Search Accessible to all; Starts the search process. Must have a value in the search string.

Starts the search process.

Move, Move All, Remove, Remove All

Accessible to all; must have values in the Accounts to Research to use remove.

Add or remove accounts to be researched.


Priority of the results (Strong, Probable, Potential)

System generated Shows priority of EA in the research results.

Number of results System generated Shows the number of results in each priority category

Export Results Available to all Exports results to Excel file.

Filter Results Available to all Allows user to filter the results


EA Name System generated – user can click on this to view EA details in the Admin portal.

Show Name of EA

EA Number System Generated Show EA Number

Country(s) System Generated – user can click on this to view details of all EBS sites associated to the party.

Show all countries associated to the EA.

Note System Generated – user can click on this to view details about each note.

Show several advisory notes on the EA. Use to help determine which EA’s to select.

Sites System Generated – user can click on this to view details of all EBS sites associated to the party.

Show number of unique sites associated to the EA.

Customer Domains System Generated – user can click on this to view details of all EBS sites associated to the party.

Show all contract domains associated to the EA.

SU Name System Generated Shows SU of the Account

SU Domain System Generated


Match Criteria (Categories) System generated Shows the category(s) that the EA has matched on.

Match Strength (for each category)

System generated; User can click on this field to view the details

Shows the match strength for each category.

Show quotable assets Available to all; at least one EA must be Launches the Quotable Assets view


selected in the Selection Box field.

which will pre-populate with the EA’s selected.

Select All Available to all; Clicking on this button selects all EA’s in the results list (the select box becomes check).

Select All Strong/Probable Available to all Clicking on this button selects all EA’s in the Strong/Probable priorities in the results list (the select box becomes check).

Selection Box Available to all Select an EA to have its IB shown in the quotable assets view.


3.2. Gather Potential EA’s

Req#

Priority

Category

Start Point (VMStar/ Standalone)

Match Rule

Search Level Standard, Deep

Category Match Rule S = Strong; W= Weak; Blank = No Matches

4.01 Must Company Master

VMStar Customer ID

UUID match If the EA research tool has been launched from VMStar, search the Company Master and retrieve any EA #’s associated to the Company Master hierarchy.

Standard If the match is made to a VMware business supplied hierarchy in the company master, set the match strength for this category to ‘S’. If it is made on the default hierarchy (based on DUNS) set the category match strength to ‘W’eak.

4.02 Must EA Number EA Number Match If the EA Research tool has been launched from the BI Dashboard, use the EA(s) entered to search the Company Master and retrieve any EA#’s that are also associated to that hierarchy.

Standard Same as above.

Gather Potential EA’s Tool will start from either the supplied VMStar Customer ID or from an EA number and using defined rules search/evaluate data sources to gather/evaluate potential EA’s. Each search rule will be categorized such at a match for a rule will result in the flag on the UI for that category being set. Search rules will also set the strength of the category match at Strong, Weak, or ‘Blank’ if the EA has not matched that category at all. Search rules will also be flagged as standard or deep. The deep rules will only be executed on user request.

Match Categories

Match Strength


Req#

Priority

Category


Match Rule



4.03 Must Saved EA Relationship

VMStar Customer ID

Saved EA relationship Search the saved EA Relationship table by the VMStar Customer ID. Retrieve all EA’s associated with that customer ID. If there is a Customer ID entry with an EA list, also search the table using EA’s that are in that list to see if there are any other saved relationships for those EA’s.

Standard If relationship profile type matches user profile AND If status of EA relationship is ‘Certified’ Set match strength to ‘S’; Otherwise, set match strength to ‘W’

4.04 Must EA Number EA Number Match in saved EAs Search the saved EA relationship table use the EA number(s) that were used to initiate the search.

Standard If status of EA is ‘Certified’ Set match strength to ‘S’; Otherwise, set match strength to ‘W’

4.1.1 Strong Want

DUNS Number

VMStar Customer ID

VMStar DUNS Number EBS Party DUNS Number Using the DUNs number associated to the VMStar account (if any); search the EBS party data to see which parties (if any) match the VMStar DUNS value. Search the Party DUNS, DUNS Domestic Ultimate, and DUNS Global Ultimate. .

Standard If there is a DUNS or Domestic Ultimate Party match, set the match strength for this category to ‘S’trong. If the match is made to the Global Ultimate, set match strength to ‘Weak’

4.2.1 StrongWant

Hoovers It would be desirable if there could be a search of the Hoover’s data to determine any other subsidiary/parent names associated with the VMStar Account or EA.

Deep


Req#

Priority

Category


Match Rule



4.3.1 Must Orders/Booking

VMStar Customer ID

Order Associated with VMStar Accounts Find other VMStar Accounts with the same normalized name + country. For each VMStar account, search VMStar order associations. For each order, search the order information in EBS/EMS to find the EA Name/Number associated to the order.

Standard Consideration: EA’s can be associated to the wrong order. √ For each EA, compare the normalized name of the VMStar account with the normalized name of the EA account. If equal, set match strength to ‘S’ √ Compare the upper domain of the sold to/licensed to contacts on the order. If they match the upper domain of any contact, set match strength to ‘S’ √ Otherwise, set match strength to ‘W’

4.3.2 Must VMStar Customer ID

VMStar Contacts are the Sold To or License To Contact on any Order. Find other VMStar Accounts with the same normalized name + country. Examine active contacts for all of these accounts. Remove contacts with upper domains on their email such as ‘Gmail’ (see Eloqua rules). For each remaining active contact associated to the VMStar accounts, use the email address to search orders. For each order where the VMStar contact is either the sold to contact or license user on that order, select the EA associated to that order.

Standard Consideration:We need to protect against the scenario where the contact on the VMStar account represents a partner/contractor. So, we need to perform the following qualification: If the upper email domain associated to VMStar contact is <> domain associated to the EA referred to on the order, then set match strength to ‘W’eak. If the upper domain on the VMStar contact is singular for the entire VMStar account (only 1 contact has that domain) then set match strength to ‘W’eak.


Req#

Priority

Category


Match Rule



4.3.3 Must EA number EA Order Associations From the supplied EA numbers, look at all of the orders associated to those EA’s. Build a list of all of the Sold To/Licensed contacts for those orders. Find all other orders that those contacts are also the sold to or licensed user on. Select those EA’s.

Standard Set match strength to ‘S’

4.3.4 Must VMStar Customer ID

Additional Sold To/License To Contact Associations For any orders associated to the VMStar account, if the Sold To or Licensed User for a given order is not a contact on the VMStar accounts/EA’s, then search for any other orders that those users may be associated with. Select any unique EA’s.

Deep Same as above VMStar Contact Rule

4.4.1 Strong Want

VMStar Cases

VMStar Customer ID

Cases Associated to the VMStar Account (VMStar) Find other VMStar Accounts with the same normalized name + country. Search the cases associated to those VMStar accounts. Determine if there is an EA number associated to those cases.

Standard √ If the normalized name of the VMStar account is equal to the normalized name of the EA associated to the case, set match strength to ‘S’ √ If the normalized name of the VMStar account is <> to the normalized name of the EA associated to the case AND the upper domain of the primary case contact occurs more than once on the VMStar account contact list, then set match strength to ‘S’ √ Otherwise, set match strength to ‘W’.


Req#

Priority

Category


Match Rule



4.4.2 Want VMStar Customer ID

VMStar Contacts have submitted cases not associated to this VMStar account. Find other VMStar Accounts with the same normalized name + country. For each active contact associated to the VMStar accounts, use the email address to search other VMStar cases that the user has submitted.

Deep See Above Strange VMStar accounts.

4.4.3 Must

EA Number EA Contact email Case submission For each EA selected, look at the users associated to those EA’s in MyVMware. Search MyVMware for all of the cases that those users have submitted and retrieve all of the unique EA #’s associated to those users

Standard √ If the normalized name of the EA account is equal to the normalized name of the EA associated to the case, set match strength to ‘S’ √ If the normalized name of the EA account is <> to the normalized name of the EA associated to the case AND the upper domain of the primary case contact occurs more than once on the EA account contact list, then set match strength to ‘S’ √ Otherwise, set match strength to ‘W’.


Req#

Priority

Category


Match Rule



4.5.1 Strong Want

Historical Quotes

VMStar Customer ID

Quotes tied to the VMStar account where an IB pull was requested. Search Model N data for any quotes associated to the VMStar account. Check the field IB search parameters and parse them to see if they are EA #’s or email domain(s). If EA#, add to possible EA’s If domains, search for any EA’s associated to those domains (see below)

Standard If Quote reached the validation stages, set match strength for this category to ‘S’; otherwise, if EA match set strength to ‘W’.

4.6.1 Must Contacts VMStar Customer ID

VMStar Contact Email is the SU/PC or Admin on an EA. Find other VMStar Accounts with the same normalized name + country. For each active contact associated to those accounts, use the email address and search for any active EA’s where that email address belongs to the SU, PC, or Admin.

Standard √ If SU or PC, then set match strength to ‘S’ √ If Admin, then if normalized name on the VMStar account = normalized name of the EA account, set match strength to S Otherwise, set match strength to ‘W’.

4.6.2 Strong Want

VMStar Customer ID

VMStar Contact Match to EA For each contact on the VMStar account, check to see if that user also a user on any EA.

Deep If normalized name on the EA is the same as the normalized VMStar account name AND the upper domain of the VMStar contact occurs more than once on the VMStar account, set match strength to ‘S’ Otherwise, set match strength to ‘W’.


Req#

Priority

Category


Match Rule



4.6.3 Strong Want

EA Number EA User Match to other EA’s For each user on the supplied research EA’s, determine other EA’s that the user is associated to

Standard √ If user is SU/PC on both the supplied EA and the associated EA, then set match strength to ‘S’. √ If first 8 characters of the EA name of the supplied EA and associated EA are the same as the first 8 characters of the associated EA, then set match strength to ‘S’ √ If the upper domain of the user on the supplied EA equals the domain of the associated EA, then set match strength to ‘S’ √ Otherwise, set match strength to ‘W’.

4.7.1 Must Domains VMStar Customer ID

VMStar Domain matches domain of other EA’s. Examine all of the contacts associated to the VMStar accounts. For each upper email domain that is not Gmail, etc.) that occurs more than once, search for all EA’s that have that contain that domain association.

Standard If 1st 8 characters of the

normalized name of the additional EA(s) = the 1

st

8 characters of the normalized name of any other EA’s already gathered, set match strength ‘S’; else set to ‘W’

4.7.2 Must Both Domains from EA’s already gathered Perform this search AFTER all the above search rules are executed For each EA gathered, look at the domain associated to that EA. Search for any other EA’s that match that domain.

Standard If 1st 8 characters of the

normalized name of the additional EA(s) = the 1

st

8 characters of the normalized name of any other EA’s already gathered, set match strength ‘S’; else set to ‘W’


Req#

Priority

Category


Match Rule



4.7.3 Strong Want

Both Domains from Parties associated to EA’s gathered. For each EA gathered, search to see if that domain matches the domain associated to ANY EBS party. Determine the EA associated to that party.

Deep Consideration: EA’s can have multiple domains associated to them (at the party/site level) If 1

st 8 characters of the

normalized name of the Party Name ) = the 1

st 8

characters of the normalized name of any other EA’s already gathered, set match strength ‘S’; else set to ‘W’

4.8.1 Must Names VMStar Customer ID

VMSTAR Normalized Name equals EA Name Normalized Name Find all EA’s where the VMStar Account Normalized Name equals an EA normalized name. For EA’s already gathered, for each unique normalized name find any others EA’s matching that normalized name.

Possible normalized name logic: For EA Names, MyVMware Names, and Party Names, create normalized name keys where special characters and words and spaces filtered out.

Possible algorithm:

Standard If match is made on the VMStar account normalized name OR if match is made on another EA name already gathered AND that additional EA has at least one prior match strength category of ‘S’ Then set match strength = ‘S’ Otherwise, match strength = ‘W'


Req#

Priority

Category


Match Rule



Strip out: 'The ', ' A ', ' of ' Strip out: Inc, incorporated, Co, Company, Corp, Corporation, LTD, Limited, KG, LLP, LLC, SA, S.P.A/SPA (in Italy Only), GMBH, S.R.O/SRO, BV, PLA, AG, AS Strip out: ?,& ( ).#/- spaces

4.8.2 Must EA Name Normalized EA Name Match For every EA Name supplied in the initial request, as well as every EA Name already gathered by the above searches, find any additional EA’s where the normalized names match.

Standard

If match is made on the supplied EA Name(s) normalized name OR if match is made on another EA name already gathered AND that additional EA has at least one prior match strength category of ‘S’ Then set match strength = ‘S’ Otherwise, match strength = ‘W'

4.8.3 Strong Want

Both Normalized Name Matches on Party Name Using the normalized names of the potential EA’s gathered above, search EBS Party names for any other unique EA’s not already gathered.

Deep Search for Party normalized name matches. Once found, look to see what EA that Party belongs to. If that EA is not already on the list, add it to the potential EA list. Set match strength to ‘W’.

4.8.4 Strong Want

Both Partial EA/VMStar normalized key match For the above non-Party Name searches, if the first 8 keys of the normalized name match, select those EA’s as well.

Deep Set match strength to ‘W’


Req#

Priority

Category


Match Rule



4.9.1 Want Addresses VMStar Customer ID

VMStar equals EA Address Search all EA’s. If the address line 1 + city + country of the VMStar account matches the address of any EAs, then select those EA’s

Deep If exact match than set match strength to ‘S’; There is no ‘W’ match strength for this rule.

4.9.2 Want Both Potential EA Site Address Match For all of the potential EA’s gathered to this point, if their normalized address line 1 + city + country matches the site address of any other EA, add that EA to the potential list.

Deep Set Match Strength ‘W’

4.10.1 Must License Key EA Number Supplied license key matches EA number.

Standard

Table of Category Match Rules Summary Rule Block

Profile Category Key Type Retrieves Additional Category Strength Rule

Category Strength

1 Customer Master

VMStar UUID or EA Number

Standard EAs in VMware Business Supplied Hierarchy

S

Standard EAs in DUNS Generated Hierarchy W

2 Saved EA Relationship

VMStar Customer ID or EA Number

Standard EA's in Sales Saved Hierarchy - Completed

S

Standard EA's in Sales Saved Hierarchy - In progress

W

Standard EA's in Hierarchy Saved by other profile

W

3 DUNS DUNS on VMStar Account

Standard Parties associated to DUNS Normalized Names of VMStar + Party are =

S

Standard Parties associated to DD Ultimate Normalized Names of VMStar + Party are =

S

Standard Parties associated to Global Ultimate W

4 Orders VMStar Account Relationship/EA Number

Standard Other VMStar accounts with normalized name/country match to Order Number --> EA's associated to order

Normalized Names of VMStar Account/EA =

S

Standard Order Number to Licensed User to other orders where user is licensed/sold-to to EA's


S

5 EA SU/PU Standard Order Number to Licensed User to other orders where user is licensed/sold-to EA's


S


Rule Block

Profile Category Key Type Retrieves Additional Category Strength Rule

Category Strength

VMStar Contacts Deep Order Number to Licensed User to other orders where user is licensed/sold-to EA's

VMStar Domain occurs more than 1; Normalized Name

S

6 Cases VMStar Cust ID Standard Other VMStar accounts with normalized name/country match Associated Cases with EA #'s

1st 8 keys of normalized names of VMStar + EA =

S

Deep Other VMStar contacts where domain occurs more than once on VMStar account to Cases Submitted to EA's


S

EA Number Deep Cases submitted to that EA to contacts to other cases submitted by contacts to EA's


S

7 Prior Quotes VMStar Account Standard Opportunity to MN Quotes to EA's Requested for IB Pull

Opportunity Closed/Won

S

8 Contact VMStar/ EA's Contact

Standard EA's where the VMStar (2x domains)/EA Contacts are the SU/PC/Admin

S

9 License Key License Key (User Supplied)

Standard EA Number Associated to the License Key

S

10 Email Domain VMStar Contact Domains

Standard If VMStar domain occurs 2x, Retrieves EA's associated to those domains

Match to contact upper domain

S

10a EA Contact Domains

Standard If EA contact domain occurs 2x; retrieve other EA's associated to those domains

Match to contact upper domain

S

10b VMStar/EA Contact Domains

Deep Associated EA's to Parties Associated to those EA's to Domains Associated to that Party

1st 8 keys of normalized names of EA and Party =

S

10c Domains from EA's Already Gathered

Standard Domain to other EA's with those Domains

1st 8 keys of normalized names of EA and Party =

S

11 Normalized Name

Normalized Name Standard Normalized Name to Other EA's with Same Normalized Name

Exact Match S

11a Deep Normalized Name to Other EA's with Same Normalized Name

1st 8 characters W

11b Deep EA's associated to Normalized Name to Normalized Party Names associated to those EA’s

S

12 Addresses VMStar or EA Address line 1 + city + country

Deep Other EA's with a site that matches the address information

Strip out leading numbers

S


3.3. Admin Configuration Mockup/Example

An application administrator can determine, for each profile, the search rules to apply; which rules will be executed only when the user selects the ‘deep’ option; and whether the ‘strength’ rule(s) which determine if a category is S or W will be applied (if not applied, then any match to the category will be ‘S’. The application administrator can also add new profiles as needed. This page should also allow one-click view configuration


Three tabs: EA Research Configuration – Show EA Research Configuration Page Quotable Assets Configuration – Show Quotable Assets Configuration Page User Preferences – Show User Preferences Page Search/Sources Rules √ Each rule can be turned on or off for a profile (Perform Y/N) √ Each rule can be configured as Standard/Deep (Deep rules are executed only when user selects that option) √ Use Strength rule (if rule is turned off, then category strength is always ‘S’ Priority Rules √ There can be multiple rules for when an EA gets classified as ‘Strong’, ‘Probable’, or ‘Possible’ √ In each rule the Administrator indicates the various combinations of match category strengths which need to occur OR the counts of any particular match strengths across all the categories. For example, if the Administrator wanted a rule that calculated when any 3 categories match to ‘S’ then the overall strength rating is ‘Strong’; in the STRONG column, they would set each category to ‘ANY’ and enter ‘3’ in the Count box. If the Administrator wanted a rule that calculated that an EA has a match strength as ‘Probable’ if the Domain and Name checks were ‘S’ then in the PROBABLE column, they would set the categories DOMAIN and NAME to ‘S’ and the other categories to ‘Any’,

3.4. Intentionally Blank


3.5. EA Research Scenarios – Functional Mockups

3.5.1 Search Criteria Mockup User assembles the list of EA/VMStar account names to be researched (at least one name must be supplied). If launched from the VMStar Account, Account Plan, or Opportunity page; the first Account Name will be pre-populated. User could now click on RESEARCH ACCOUNTS to have the tool research all EA’s related to GE Medical Systems

Note: The user could have also optionally added additional subsidiary or name variations (see example below).


3.5.2 Mockup: Displaying Status Results Once the research process begins, the use sees a periodic progress report. The user can cancel the search at any time.

Research in progress: Step 1 of 12 - Company Master Check: Complete (1 match found) Step 5 of 12 - Order/Booking Check: Complete (3 matches found)

Press ESC to cancel search


3.5.3 Drill into Site Details Once EA results are displayed, the user can drill into selected fields to get more information:

Party Number Party Name DOMAIN(s) ADDRESS_LINE_1 CITY POSTAL_CODE

2993152 GE Consumer Finance Co Ltd GE.COM, SHINSEIFINANCIAL.CO.JP L.1 CENTER, 1-2-43 IMAGOME OSAKA 578-0903

2993152 332 MINNESOTA ST SAINT PAUL 55101-7707

Shows all of the countries associated to the parties which make up the EA. Clicking here will display site details

This field shows the number of unique party sites. Clicking here will display site details

This field shows the domain(s) associated to the EA + parties that make up the EA. Click to view site details.


3.5.4 Notes Field The Notes field will display text to help the user determine the usefulness of the EA prior to displaying the One-Click View.

EA Note values (may be broken into two fields): 1) No Active IB in EA 2) Individual Account (i.e. person party) 3) Federal Account 4) Do Not Touch flag is set 5) ELA Contract active for the EA 6) EA merge, split, or LATF activity has occurred.


3.5.5 Drill into Match Details When the research is completed, the results will show all EA’s which have matched on at least one criterion, and the strength of that match (strong/weak). The user can (1) click on any Category Title to read an explanation of that category, or (2) click on the match code (S/W) to view details of the match:

User can click on the ‘S’ and show the rules which caused the match strength to be set.

Rule Case Number VMStar Normalized Name Normalized EA Name on Case

Associated case to VMStar Account and 1st 8 Characters of Normalized Name Match

12345 GEMedical GEMedicalConsumerDivision

1

2

1

Company Master contains official VMware hierarchy for a customer…etc.

Hover Box


3.5.4 Drill into EA Relationship details Click on the category ‘Saved EA’ match value allows you to drill into the EA relationships.

The EA Research Tool would display:


The account relationships can also be viewed or managed on the VMStar Account page:


3.5.5 One-click View to EA Research Tool (to refine results) Once the One-click view has displayed EA results, the user may determine that there have been EA’s overlooked by the initial EA research effort. If so, they can click on REFINE EA RESEARCH RESULTS:

The Original Research query/results are displayed. The User can then choose to (1) Add or Subtract EA’s selected from the original research results (first mockup); or (2) enter click on the EA/VMStar Account Lookup to select additional EA/VMStar names to be researched (2nd mockup): Original results used to generate the one-click view are displayed:

MY VMware View Refine EA ResearchResults

2

1

1

Use can add/remove EA’s to be displayed in the Quotable Assets view from the original research list of EA’s

Use can add additional EA’s i.e. if the customer says a particular license is missing, you could search for that license value and add the EA to the Research list.


At this point, after pressing EA/VMStar lookup, a search box would appear. If the user wants to add additional EA/VMStar accounts to search, they (1) use the search box to select the type of search they want (by EA Name, VMStar Name, etc.) and (2) then execute a search and view search results. They can then (3) move additional EA’s into to the ‘Accounts to Research’ box, and then (4) click on RESEARCH ACCOUNTS

1

2

1

3

Additional EA # 1

Full list of Search Criteria include: EA, VMStar, and Party Name/Domains; License Key, Contract Number, Order Number.

4


3.5.6 Save Relationships A set of EA relationships will be maintained to facilitate subsequent transactions for a given ‘customer’.

VMStarEA Research Tool (BI

Dashboard)Future (MyVMware/Partner Central)

Profile TypeVMStar Cust ID/EA

NumbersLast Modified By Comment Status

Date/Time Stamp

Sales,GSS,Partner,Customer.Renewals,Compliance,Etc.

Each profile can have a unique relationship for a given EA or VMStar Account

Multiple Cust ID or EA Numbers that are part of this relationship

(No hierarchy, just a group of related accounts)

In Progress:

Set by EA research tool or profile creator/owner

Completed

Set by profile user, or, in certain conditions, the EA Research tool

Account Page:

Use can add, delete, or update a relationship for a given VMStar Account

(Both Sales/GSS Profiles)

User:

Can add, delete, or update a relationshipfor an EA or VMStar Account

(Any Profile Type)

EA Research Tool:Creates/updates a relationship for the profile

When EA’s are selected/deselected forthe One Click View

User:

Can add, delete, or update a relationshipfor an EA or VMStar Account(Partner/Customer Profiles)

EA Research Tool:Creates/updates a relationship for the profile

When EA’s are selected/deselected forthe One Click View

EA Relationship Table

These relationships can be managed in the EA Research tool, within VMStar, and eventually MyVMware. In the EA Research tool, the interface might look like this:


And in VMStar:


EA Relationship Scenario: When the user selects EA’s for the quotable asset view, if one doesn’t already exist for the Profile/Account Number combination, then the system will automatically create a new saved relationship with a status of ‘In Progress’

Relationship table entry would be created:

Profile Type Accounts Status Last Modified By Date/Time Comment

Sales EA 1, EA 2, EA 3, Cust ID 1

In Progress EA Lookup Tool EA Research auto created for

If the user subsequently selected anadditional EA for the One-Click view that would be added to the relationship by the EA research tool:


Sales EA 1, EA 2, EA 3, EA 4, Cust ID 1

In Progress EA Lookup Tool EA Research tool updated based on additional EA.

If the user subsequently deselected anEA for the One-Click view, the system would prompt them to see if they wanted to remove the EA from the saved relationship – the prompt is because an EA may be removed from the One-Click view as part of the sales negotiation process): Clicking on REMOVE would result in the relationship being updated:



In Progress EA Lookup Tool EA Research tool updated based on removing an EA.

Would you like to remove this EA from the stored EA relationship? REMOVEKEEP


If GSS Licensing used the EA research tool involving the same VMStar account, a second table entry would be added:



In Progress EA Lookup Tool EA Research tool updated based on additional EA.

GSS EA 1, EA4, EA 5, Cust ID 1

In Progress EA Lookup Tool EA Research tool created.

If the sale rep in VMStar then updated the sales relationship on the VMStar Account Page, then the table might look like this:



Completed Sales Rep Customer verified EA’s for quote.



If the Rep forgets to update the saved relationship (the status is still ‘In Progress’), when the rep went to the associated Opportunity and changed the opportunity status to Closed Won/Lost, then VMStar would prompt: If the user clicked on CONFIRM, the entry in the relationship table would be updated to:



Completed Sales Rep



A saved EA relationship was created for this account: EA 1 EA Name EA 2 EA Name EA 3 EA Name CONFIRM DELETE UPDATE


3.5.7 EA Research launched from the Admin Portal – Account Details Page

User can launch the EA research tool from the Admin Portal details page. In this case, the EA Research tool would launch pre-populated with the EA on the detail page.


4. INTEGRATION

4.1. Systems

The following table highlights the integrations referenced in the above requirements (assumes the research data architecture will be in place such that the EA research tool will not need to directly interface with any data source.

System Integration Required

Admin Portal Launch EA Research Tool from the EA Details Page pre-populated with the EA on that page.

Allow user to click on the EA Name in the research results page and display the EA details page

VMStar Launch from Account Page – pass VMStar Customer ID

Launch from Account Plan Page – pass VMStar Customer ID

Launch from Opportunity Page – pass VMStar Customer ID

Account Page – View/update saved EA relationships

Opportunity – Prompt on opportunity close to change status on saved EA relationship (if any)

Quotable Assets View Launch Quotable Assets tool and auto-start the view for the selected EA’s.

Customer Master Assume data will be imported into new architecture

Model N Assume data will be imported into new architecture

5. REVIEW AND SIGN-OFF

Below is a list of required reviewers and approvers:

Name Role Contact Signoff Date

ibela brd ea-research_tool_v1.2

Technology

ea research v1

manual ea research

ea research tool process

ea research tool revision

new ea research tool

ea research tools purpose

subsequent ea research

customer ea relationships