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

Page 2 of 70

Contents
1. OVERVIEW/ EXECUTIVE SUMMARY .......................................................................................................... 4
1.1.

2.

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

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.

5.

Systems ...................................................................................................................................................... 70

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


Page 3 of 70

REVISION HISTORY
Version
No.

Date

Name (Alias)

Description of Change

1.0
1.1

06/11/2013
06/17/2013

Michael Shields
Aaron Pinto

1.2

06/24/13

Aaron Pinto

Created a BRD
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
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


Page 4 of 70

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
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.

Comment

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 oneclick view
Integration with the new customer master system.
st

Out of Scope – 1 release (November)

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


Page 5 of 70

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?

Page 6 of 70


Page 7 of 70

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.

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 Teams Can Have Different
View of the Customer  EA
Relationships

Company A

Company A - Subsidiary

Company B

VMware Corporate

EA#1

EA#2

EA#3

EA#4

EA#5

EA#6

VMware Sales APAC

EA#1

EA#2

EA#3

EA#4

EA#5

EA#6

VMware Sales EMEA

EA#1

EA#2

EA#3

EA#4

EA#5

EA#6

VMware GSS Tech
Support

EA#1

EA#2

EA#3

EA#4

EA#5

EA#6

Partner

EA#1

EA#2

EA#3

EA#4

EA#5

EA#6

Different Customer Transactional Views:
VMware
Execs

Sales

X

X

X

X

GSS

Complia
nce

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

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


Page 8 of 70

VMware
Execs

Sales

GSS

Complia
nce

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

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.
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


Page 9 of 70

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:

Possible Customer Future State Capabilities

EA Research

+
One-click view

Can define their own EA associations to facilitate
MyVMware cross EA views
Selected self-service view/request quote capability
Semi-automated compliance management

Should be
designed as the
first steps to
enable a future
state

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.

17

Confidential

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
November Release
Sales/GSS
Renewals, Compliance, EDG
Future
Customer
Partner

Launch Point
VMStar (Account Plan, Account, Opportunity)
Standalone/BI Dashboard
MyVMware
MyVMware/Partner Central


Page 10 of 70

2.2.The EA Research Tool – Process Overview
EA Research Overview
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.

TBD

November 22

BI Dashboard

VMStar

MyVMware

Partner
Central

EA Research Tool

EBS

21

VMStar

MyVMware

Confidential

Company
Master

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


Page 11 of 70

TO BE Process Flow – Sales (High Level)
Field Team

Click EA Research Button in
VMStar
(Account, Account Plan, Opportunity)

Generate Quotable Assets
View + Validation +
MyVMware Mapping

EA Research Tool
Generates EA List

Share with customer

Confirm/Refine EA List

Refine EA List
(if needed)

IB Team

Sales:
Upload IB to Model N

Send to DD

VALIDATION
ISSUES

IB Team Validation

NO DEAL
FOR NOW

Help
Needed?
PROCEED WITH QUOTE

NO VALIDATION
ISSUES

Launch 1-click View from
EA Research Tool

Correct Issues

IB Team:
Upload Corrected IB
to Model N

Store EA
Relationships

DD/
GSS

STOP


Page 12 of 70

EA Research Tool Process
VMStar Account, Account Plan, Opportunity
Pages

Standalone or VMStar Tab

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

User Supplies Initial Research Starting
Point(s)

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)

System/User Saves EA Relationships for Future Use

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

2. EA Research Tool Produces Initial Results

Page 13 of 70


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.

Page 14 of 70

6. Results Saved for future use

Page 15 of 70


Page 16 of 70

2.3.EA Research Tool Use Cases
Use Case(s)
Sales
Research potential deals

Who

EA Research Tool Comment

Field/Partner

Research using VMStar account as starting point.

Field, DD, Partner


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’

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)

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’
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.

Will need to expand the starting points to include
subsidiary names, license keys, contracts, or
orders

Field needs to determine if this is because of
an EA being excluded/included; or because
of another issue.
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.
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)
Renewal Quote

Page 17 of 70

Who
SSI, Sales

EA Research Tool Comment
Need to discuss with Renewals – Contract
number/EA Name as starting point?

Compliance, CSO,
Customer

EA Name, ELA Contract number as starting points

Customer, GSS,
CSO, Compliance

EA Name as starting point.

Execs, GSS,
Partner


Execs, Sales,
Partners

EA Name as starting point

GSS, CSO,
Customer, Partner


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

License Compliance
Determine which EA’s belong to a ‘customer’
to validate the accuracy/completeness of
license compliance reports submitted by the
customer
Resolve IB Issues (Post Sales)
Order has been booked; customer discovers
missing/deactivated licenses.

Escalated/Problem Customer
Understand all of the sales, support and
other transactional history related to the
‘customer.
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.

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


Page 18 of 70

2.4.EA Research – Functional Overview
Functional Overview

EA Research Tool Function
Automatically gather up a list of potential EA’s
belonging to the ‘customer’ by matching them to a
series of categories.

Comment
Using a combination of known relationships, transactional
information, and company/user attributes produce a list of
‘potential’ EAs associated to an account.

When launched from VMStar, the user is not required to
enter any search criteria. The starting point will be a
VMStar 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.

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

√ Storage mechanism/structures should complement the
Customer Master and be available in VMStar.
√ 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.


Page 19 of 70

Data Sources For Gathering Potential EA’s
Data Source
System
Company Master

Description

Value

Comment

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
Transactional
Orders/Bookings

May contain subsidiary names.

TBD

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

High

Support Cases

Contain contacts, may also contain
EA associations.

High

Some orders have VMStar
relationships

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.

Contracts

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

License Keys

Contact Names
VMStar, Party Contacts,MY
VMware Super User,
Procurement Contact
Once Above EA’s are
Gathered
Domain(s)

Medium

High

Customer/partner may have a specific
license key

High

If supplied by the customer.

Email addresses

High

May match the SU/PC/Admin
for an EA.

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

High


Page 20 of 70

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


Page 21 of 70

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.

#
1.0
1.01

Must

Strong
Want

Requirement
Application Launch Points
VMStar Account Page

Comments/Open Questions

EA Research tool should be able to be
launched from the VMStar account page.

1.02

Priority

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.

VMStar Account Plan Page

Process same as VMStar Account Page.

In this case:

launched from the Account Plan Page.
1.03

Must

VMStar Opportunity Page

Process same as VMStar Account Page.

launched from the opportunity page. In this
case the EA Research tool would start its
research using the VMStar Account
associated to that opportunity.
1.04

Must

BI Dashboard
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.


Page 22 of 70

#

Priority

Requirement


1.05

Must

One-click view (Refine Results)

In this scenario, the research starting point
would be the EA’s that had been selected for
the one-click view

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.

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.

1.07

Strong
Want

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

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)

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

Page 23 of 70


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 prepopulated.

2.01

Must

Automatic (When Started from VMStar)
Pre-Populate the Accounts to be
Researched field with the VMStar
Customer ID

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

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

2.0.2

Strong
Want

Automatic (When started from the Admin
portal)
Pre-Populate the Accounts to be
Researched field with the EA Number

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

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.

User Supplied (When starting from VMStar
tab or BI Dashboard OR when refining a OneClick 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


Page 24 of 70

#

Priority

Requirement

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

2.04

Must

User Supplied Order Number

√ User enters an order number

User can enter a specificVMware Salesorder
number (no wild card or partial key searching)

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.

Must

User Supplied License Key

√ User enters a license key

User can enter a specific license key or cloud
key (no wild card or partial key searches).

2.05

1) If the license key is found, the system
displays the EA associated to the key.
research with.
research process.

User Supplied Contract Number

√ User enters a contract number

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

2.06

1) If the contract number is found, the system
displays the EA associated to the number.

Must

research with.
research process.
2.07

Must

User Supplied EA Domain
User can enter an email domain (wildcard
searches allowed).

√ User can enter a search string (with
wildcards) to search all active EA’s with the
associated domain:
1) Search Results are displayed.

(This domain search will search for any EA
where the SU/PC for that EA has a domain
that matches).

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)
clicks a button to initiate the research process.


#
2.08

Priority
Strong
Want

Requirement
User Supplied Combined Party/EA Name
Search both EA Names and active Party
Names.

Page 25 of 70

wildcards) to search all active EA and Party
Names

If Party names found, retrieve the EA’s
associated to those Party Names.

start the research

Do not display duplicate EAs.
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.

wildcards) to search all active EA and Parties
for a domain:
start the research

Do not display duplicate EA;s.
clicks a button to initiate the research process
2.10

Future

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


#
2.11

Priority
Strong
Want

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

Page 26 of 70

√ User enters an Instance number
2) If the Instance number is found, the
system displays the EA associated to
the instance number.
research with.
research process.

Gather Potential EA’s

See section 3.2 below for details of sources
and logic.

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.
Configuration Requirements
3.01

Strong
Want

See configuration mockup in section 3.3 below.

Configure which research rules
use/exclude

√ The logic for gathering other potential EA’s
should be segmented into blocks which can be
run independently of another block of logic.

System should allow the business to turn
specific search rules on or off without having
to release a new application version

√ 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

Page 27 of 70

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’

3.03

Must

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.

Research Progress

See example in section 3.5.2

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.
Search rules/sources for potential EA’s

4.0.1
to
4.10.1

5.01

Must

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
EA Evaluation Rules
Setting Strong Match Priority
Once potential EA’s are gathered, they will be
categorized in one of three classifications:

√ An EA that scores in any of the following will
receive a ‘Strong Match’ priority:

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.

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.


Page 28 of 70

#

Priority

Requirement


5.02

Strong
Want

Configure rules for Strong, Probable, and
Possible categories.

√ System should allow the Administrator to
create multiple rules for each category.

System must allow the application
administrator to configure the rules for
calculating the 3 priority categories

√ 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

6.01

Strong
Want

UI Fields/Functions
Application Setup/Configuration
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)

See section 3.1 for annotated screen image
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 Mockup/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 Mockup/Example


#

Priority

Requirement

6.04

Must

User Selected Research Option
Standard/Deep Search
Deep search option causes the research tool
to execute search rules classified as ‘deep’ in
the application configuration.

Page 29 of 70


√ 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

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

Pressing this button initiates the research
process for the selected accounts.

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

√ See 2.03-2.10 above for search options.

Pressing this button reveals the fields which
will allow the user to search for accounts to be
used for EA research:

√ 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.

Page 30 of 70

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

See 5.01 above

System will categorize the EA’s gathered as
Strong, Probable, or Possible; and then
display the appropriate EA’s within each
category.
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.
Export Results

6.08d
Must

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

6.09

Must

√ Filter by country
√ Filter by domain
√ Filter by name (including a contains filter)
√ Filter out any category combinations (i.e.
remove DUNS matches)
√ 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.

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

Page 31 of 70

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

6.12

Must

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).
Want

√ 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

6.15

Must

Page 32 of 70


Domain
√ Display the domains associated to the EA:
Show the domain(s) 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.

SU Name/SU Email

6.16

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

6.17

Must

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

6.18

Must

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

6.19

Must

Show Quotable Asset Button
Clicking on this button will launch the oneclick view which will display the IB for the
checked EA’s.

√ 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)

√ There should be a ‘Select All and ‘Select All
Strong/Probable) option.
√ Users may deselect an EA that has been
selected.
√ 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

Page 33 of 70

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

Use Cases:

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

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

√ If no relationship exists, a new relationship is
created.

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, 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

Page 34 of 70

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.

Must

Ability to View and Manage Saved EA
relationships with the EA Research tool.

√ Search by EA Number, EA Name, VMStar
Customer ID or Account Name.

Users should be able to search for a stored
EA relationship, and update them as needed

7.02

√ 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

Ability to View and Manage Saved EA
relationships in VMStar.

√ Users can:

Manage:
Strong
Want

7.04

Strong
Want

√ Users can access the Sales EA relationships
from the VMStar account page.

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.

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


Page 35 of 70

#

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’

√ Status at creation = Preliminary.

Relationships should have a status which can
be set to ‘Preliminary’ or ‘Completed’.

√ 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.

System should show the user a summary of
the EA relationship and prompt them to:
Confirm, Update, or Delete.

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.

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.

8.01

Strong
Want

Security
In the future, certain profiles will have
restricted data access/views.

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

TBD – Partner
TBD – Distributor
TBD -- Customer

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.


#

Must

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


User Search Histories

9.01

Priority

Page 36 of 70

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.

Launch Points

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

Keep track of how the user has launched the
application.

9.02

Want

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

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.

√ 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.
√ Names being researched
√ Search types/search strings
√ Use of wildcard characters
√ Accounts pre-populated from VMStar/Admin
lookup

How often research is repeated for the same
account

9.04

9.05

Must

Strong
Want

√ 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.

Results/Filters

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

EA Research for the same account


Page 37 of 70

#

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

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

Times it takes to execute the research.
9.07

Want

Drill Down

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

Number of times the drill down fields are
being used.
9.08

Strong
Want

Saved EA’s

√ Through VMStar
√ Through EA Research tool.

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

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,


Page 38 of 70

Section Description

Field
User Profile

Access
Read only

Application Configuration

Accessible to all; brings you to a new page

Purpose
Controls application behavior (which
research rules to use)
Used to add/modify profiles and set


Page 39 of 70

with three tabs (EA Research Setup, Quotable
Assets Setup; and User Preferences)

Manage EA Relationships

Setup tabs are available only to the application
administrator.
Accessible to all; brings you to a new page to
search/manage saved EA relationships.

user personal preferences

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
Accounts to be Researched

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

Purpose
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 prepopulated ones).


Page 40 of 70

Field
Search Criteria

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

Purpose
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.
Accessible to all; must have values in the
Accounts to Research to use remove.

Starts the search process.

Field
Priority of the results
(Strong, Probable, Potential)
Number of results

Behavior
System generated

Purpose
Shows priority of EA in the research
results.
Shows the number of results in each
priority category

Export Results
Filter Results

Available to all
Available to all

Move, Move All, Remove,
Remove All

System generated

Add or remove accounts to be
researched.

Exports results to Excel file.
Allows user to filter the results


Page 41 of 70

System generated – user can click on this to
view EA details in the Admin portal.
System Generated
System Generated – user can click on this to
view details of all EBS sites associated to the
party.
view details about each note.

Show Name of EA

Show number of unique sites
associated to the EA.

SU Name
SU Domain

party.
party.
System Generated
System Generated

Field
Match Criteria (Categories)

Behavior
System generated

Purpose
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

EA Name
EA Number
Country(s)

Note

Sites

Customer Domains

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

Show all contract domains associated
to the EA.
Shows SU of the Account


Page 42 of 70

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.


Page 43 of 70

3.2.Gather Potential EA’s

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.

Match Categories

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 Strength

Search
Level
Req#

4.01

Priority

Must

Category

Company
Master

Start Point
(VMStar/
Standalone)

Match Rule

VMStar
Customer ID

UUID match

Must

EA Number

S = Strong; W= Weak;
Blank = No Matches

Standard,
Deep

Standard

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.

4.02

Category Match Rule

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.

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.

Standard

Same as above.


Page 44 of 70

Search
Level
Req#

4.03

Priority

Must

Category

Saved EA
Relationship

Start Point
(VMStar/
Standalone)

Match Rule

VMStar
Customer ID

Saved EA relationship

Standard

EA Number

EA Number Match in saved
EAs

Otherwise, set match
strength to ‘W’

Standard

Search the saved EA
relationship table use the EA
number(s) that were used to
initiate the search.

4.1.1

Strong
Want

DUNS
Number

VMStar
Customer ID

VMStar DUNS Number
EBS Party DUNS Number

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’

Search the Party DUNS,
DUNS Domestic Ultimate,
and DUNS Global Ultimate. .

Strong
Want

Hoovers

Deep
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.

If status of EA is
‘Certified’ Set match
strength to ‘S’;
strength to ‘W’

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.

4.2.1

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

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.
Must

Blank = No Matches

Standard,
Deep

Search the saved EA
Relationship table by the
VMStar Customer ID.
Retrieve all EA’s associated
with that customer ID.

4.04

Category Match Rule


Page 45 of 70

Search
Level
Req#

4.3.1

Priority

Must

Category

Orders/Book
ing

Start Point
(VMStar/
Standalone)

Match Rule

VMStar
Customer ID

Order Associated with
VMStar Accounts

Category Match Rule
Blank = No Matches

Standard,
Deep

Standard

Find other VMStar Accounts
with the same normalized
name + country.

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.

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.

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.
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.


Page 46 of 70

Search
Level
Req#

4.3.3

Priority

Category

Must

Start Point
(VMStar/
Standalone)
EA number

Match Rule

Category Match Rule
Blank = No Matches

Standard,
Deep

EA Order Associations

Standard

Set match strength to ‘S’

Deep

Same as above VMStar
Contact Rule

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’

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.
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.

4.4.1

Strong
Want

VMStar
Cases

VMStar
Customer ID

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

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
strength to ‘W’.


Page 47 of 70

Search
Level
Req#

4.4.2

Priority

Want

Category

Start Point
(VMStar/
Standalone)
VMStar
Customer ID

Match Rule

Category Match Rule
Blank = No Matches

Standard,
Deep

VMStar Contacts have
submitted cases not
associated to this VMStar
account.

Deep

See Above
Strange VMStar
accounts.

name + country.
For each active contact
accounts, use the email
address to search other
VMStar cases that the user
has submitted.

4.4.3

EA Number
Must

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

of the EA account is
equal to the normalized
name of the EA
associated to the case,
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,
to ‘S’


Page 48 of 70

Search
Level
Req#

4.5.1

Priority

Strong
Want

Category

Historical
Quotes

Start Point
(VMStar/
Standalone)

Match Rule

VMStar
Customer ID

Quotes tied to the VMStar
account where an IB pull
was requested.

Category Match Rule
Blank = No Matches

Standard,
Deep

Standard

Search Model N data for any
quotes associated to the
VMStar account.

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

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)

4.6.1

Must

Contacts

VMStar
Customer ID

VMStar Contact Email is the
SU/PC or Admin on an EA.

Standard

√ If Admin, then if
normalized name on the
VMStar account =
normalized name of the
EA account, set match
strength to S

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.

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.

√ If SU or PC, then set
match strength to ‘S’


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


Page 49 of 70

Search
Level
Req#

4.6.3

Priority

Category

Strong
Want

Start Point
(VMStar/
Standalone)
EA Number

Match Rule

Category Match Rule
Blank = No Matches

Standard,
Deep

EA User Match to other
EA’s

Standard

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

√ If user is SU/PC on
both the supplied EA
and the associated EA,
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
√ If the upper domain of
the user on the supplied
EA equals the domain of
the associated EA, then

4.7.1

Must

Domains

VMStar
Customer ID

VMStar Domain matches
domain of other EA’s.

Standard

Examine all of the contacts
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.

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.

st

If 1 8 characters of the
st
additional EA(s) = the 1
8 characters of the
normalized name of any
other EA’s already
gathered, set match
strength ‘S’;
else set to ‘W’

Standard

st

st
additional EA(s) = the 1
8 characters of the
gathered, set match
strength ‘S’;
else set to ‘W’


Page 50 of 70

Search
Level
Req#

4.7.3

Priority

Category

Strong
Want

Start Point
(VMStar/
Standalone)
Both

Match Rule

Category Match Rule
Blank = No Matches

Standard,
Deep

Domains from Parties
associated to EA’s
gathered.

Deep

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.

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

st
Party Name ) = the 1 8
characters of the
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'


Page 51 of 70

Search
Level
Req#

Priority

Category

Start Point
(VMStar/
Standalone)

Match Rule

Category Match Rule
Blank = No Matches

Standard,
Deep

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

Standard

If match is made on the
supplied EA Name(s)
normalized name OR

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.

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

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.

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

‘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

‘W’


Page 52 of 70

Search
Level
Req#

4.9.1

Priority

Want

Category

Start Point
(VMStar/
Standalone)

Addresses

VMStar equals EA Address

Blank = No Matches

Match Rule

VMStar
Customer ID

Category Match Rule

Standard,
Deep

Deep

If exact match than set
match strength to ‘S’;

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

4.9.2

Want

Both

Potential EA  Site
Address Match

There is no ‘W’ match
strength for this rule.

Set Match Strength ‘W’

Deep

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.

4.10.1

Must

License Key

EA Number

Supplied license key
matches EA number.

Standard

Table of Category Match Rules Summary
Rule
Block
1

Profile

Category

Key

Type

Retrieves

Customer
Master

VMStar UUID or
EA Number

Standard

EAs in VMware Business Supplied
Hierarchy
EAs in DUNS Generated Hierarchy

Standard
2

Saved EA
Relationship

VMStar Customer
ID or EA Number

Standard

Standard

EA's in Sales Saved Hierarchy Completed
EA's in Sales Saved Hierarchy - In
progress
EA's in Hierarchy Saved by other
profile
Parties associated to DUNS

Standard

Parties associated to DD Ultimate

Standard
Standard

Other VMStar accounts with
normalized name/country match to
Order Number --> EA's associated to
order
Order Number to Licensed User to
other orders where user is
licensed/sold-to to EA's
licensed/sold-to EA's

Standard

4

DUNS

Orders

DUNS on VMStar
Account

VMStar Account
Relationship/EA
Number

Standard

5

EA SU/PU

Standard

Category
Strength
S
W

Parties associated to Global Ultimate

Standard

3

Additional Category
Strength Rule

S
W
W
Normalized Names of
VMStar + Party are =
Normalized Names of
VMStar + Party are =

S
S
W

Normalized Names of
VMStar Account/EA =

S

Normalized Names of
VMStar Account/EA =

S

Normalized Names of
VMStar Account/EA =

S

Rule
Block

Category

licensed/sold-to EA's
Other VMStar accounts with
normalized name/country match
Associated Cases with EA #'s

Additional Category
Strength Rule
VMStar Domain
occurs more than 1;
Normalized Name
1st 8 keys of
normalized names of
VMStar + EA =

Category
Strength
S

Deep

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

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

S

EA Number

Cases

Key

Type

Retrieves

VMStar Contacts

6

Profile

Page 53 of 70

Deep

VMStar Cust ID

Standard

Deep

Cases submitted to that EA to contacts
to other cases submitted by contacts to
EA's
Opportunity to MN Quotes to EA's
Requested for IB Pull
EA's where the VMStar (2x
domains)/EA Contacts are the
SU/PC/Admin
EA Number Associated to the License
Key
If VMStar domain occurs 2x, Retrieves
EA's associated to those domains
If EA contact domain occurs 2x;
retrieve other EA's associated to those
domains
Associated EA's to Parties Associated
to those EA's to Domains Associated to
that Party
Domain to other EA's with those
Domains

1st 8 keys of
normalized names of
VMStar + EA =
Opportunity
Closed/Won

S

7

Prior Quotes

VMStar Account

Standard

8

Contact

VMStar/ EA's
Contact

Standard

9

License Key

Standard

10

Email Domain

License Key (User
Supplied)
VMStar Contact
Domains
EA Contact
Domains

10b

VMStar/EA
Contact Domains

Deep

10c

Domains from
EA's Already
Gathered
Normalized Name

Standard

10a

11

Normalized
Name

Standard
Standard

Standard

11a

Deep

11b

Deep

12

Addresses

VMStar or EA
Address line 1 +
city + country

Deep

Normalized Name to Other EA's with
Same Normalized Name
Normalized Name to Other EA's with
Same Normalized Name
EA's associated to Normalized Name
to Normalized Party Names associated
to those EA’s
Other EA's with a site that matches the
address information

S

S
S

S
Match to contact
upper domain
Match to contact
upper domain

S

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

S

1st 8 characters

W

S

S

S

S

Strip out leading
numbers

S


Page 54 of 70

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


Page 55 of 70

Three tabs:
EA Research Configuration
Quotable Assets Configuration
User Preferences

– Show EA Research Configuration Page
– Show Quotable Assets Configuration Page
– 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


Page 56 of 70

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).


Page 57 of 70

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:
Step 5 of 12 - Order/Booking Check:

Press ESC to cancel search

Complete (1 match found)
Complete (3 matches found)


Page 58 of 70

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

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.

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

Party Number
2993152
2993152

Party Name

DOMAIN(s)

ADDRESS_LINE_1

CITY

GE Consumer Finance Co Ltd GE.COM, SHINSEIFINANCIAL.CO.JP L.1 CENTER, 1-2-43 IMAGOME OSAKA
332 MINNESOTA ST

POSTAL_CODE
578-0903

SAINT PAUL 55101-7707


Page 59 of 70

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.


Page 60 of 70

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:
Hover Box

1

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

2
1

User can click on the ‘S’ and show the rules which caused the match strength to be set.
Rule
Associated case to VMStar
Account and 1st 8
Characters of Normalized
Name Match

Case Number
12345

VMStar Normalized Name
GEMedical

Normalized EA Name on Case
GEMedicalConsumerDivision


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:

Page 61 of 70


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

Page 62 of 70


Page 63 of 70

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:

MY VMware View

Refine EA ResearchResults

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:

2
1

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.

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


Page 64 of 70

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
Additional EA # 1

2

3

1

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

4


Page 65 of 70

3.5.6 Save Relationships
A set of EA relationships will be maintained to facilitate subsequent transactions for a given ‘customer’.
EA Research Tool (BI
Dashboard)

Future (MyVMware/Partner Central)

User:

User:

Can add, delete, or update a relationship
for an EA or VMStar Account
(Any Profile Type)

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

EA Research Tool:
Creates/updates a relationship for the profile
When EA’s are selected/deselected for
the One Click View

EA Research Tool:
Creates/updates a relationship for the profile
When EA’s are selected/deselected for
the One Click View

VMStar

Account Page:
Use can add, delete, or update a
relationship for a given VMStar Account
(Both Sales/GSS Profiles)

EA Relationship
Table
Profile Type
Sales,
GSS,
Partner,
Customer.
Renewals,
Compliance,
Etc.
Each profile can
have a unique
relationship for a
given EA or VMStar
Account

VMStar Cust ID/EA
Numbers
Multiple Cust ID or EA
Numbers that are part
of this relationship
(No hierarchy, just a
group of related
accounts)

Last Modified By

Comment

Status

Date/Time
Stamp

In Progress:
Set by EA research tool
or profile creator/
owner
Completed
Set by profile user, or,
in certain conditions,
the EA Research tool

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:

Page 66 of 70


Page 67 of 70

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
Sales

Accounts
Status
EA 1, EA 2, EA 3, In Progress
Cust ID 1

Last Modified By
EA Lookup Tool

Date/Time

Comment
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:

Profile Type
Sales

Accounts
Status
EA 4, Cust ID 1

Last Modified By
EA Lookup Tool

Date/Time

Comment
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):
Would you like to remove this EA from the
stored EA relationship?
REMOVEKEEP

Clicking on REMOVE would result in the relationship being updated:
Profile Type
Sales

Accounts
Status
EA 4, Cust ID 1

Last Modified By
EA Lookup Tool

Date/Time

Comment
based on removing an EA.


Page 68 of 70

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

Profile Type
Sales
GSS

Accounts
Status
EA 4, Cust ID 1
EA 1, EA4, EA 5, In Progress
Cust ID 1

Last Modified By
EA Lookup Tool

Date/Time

EA Lookup Tool

Comment
based on additional EA.
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:
Profile Type
Sales
GSS

Accounts
Status
EA 1, EA 2, EA 3, Completed
EA 4, Cust ID 1
Cust ID 1

Last Modified By
Sales Rep

Date/Time

EA Lookup Tool

Comment
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:
A saved EA relationship was created for this account:
EA 1
EA 2
EA 3

EA Name
EA Name
EA Name

CONFIRM

DELETE

UPDATE

If the user clicked on CONFIRM, the entry in the relationship table would be updated to:
Profile Type
Sales
GSS

Accounts
Status
EA 1, EA 2, EA 3, Completed
EA 4, Cust ID 1
Cust ID 1

Last Modified By
Sales Rep
EA Lookup Tool

Date/Time

Comment



Page 69 of 70

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.


Page 70 of 70

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
Admin Portal

Integration Required
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)
Launch Quotable Assets tool and auto-start the view for the selected
EA’s.

Quotable Assets View

Customer Master
Model N

Assume data will be imported into new architecture
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

Recommended

Recommended

More Related Content

What's hot

What's hot (11)

Similar to Ibela brd ea-research_tool_v1.2

Similar to Ibela brd ea-research_tool_v1.2 (20)

Recently uploaded

Recently uploaded (20)

Ibela brd ea-research_tool_v1.2