You have perhaps already divided your customer territory into different regions and have different people managing different regions. If so, please provide us with your Region hierarchy in an excel spreadsheet. Please keep the following concepts in mind:
- Regions can consist of multiple leaf level regions. There can be multiple super level regions e.g Northern California => NA West => NA => Worldwide. Note that Accounts (Customers) by definition belong to leaf level regions, while Users can belong either to lead level regions, or to super regions to control data visibility.
- You can specify a Region Mapping that maps Country, State, Zip Code range to a particular region. You can also associate the Regional Manager, Rep Firm and Distributor to a particular Region in the Region Mapping. If you have such a region mapping already in place, please provide us the mapping details in an excel spreadsheet. Occasionally customers will have split regions (such as Northern California and Southern California). Please let us know the details if you have this situation.
How to setup Region Mapping in NEHANET?
To setup Region Mapping you need to have Administrator privileges. Please follow the steps below:
- Go to Admin -> System Configuration -> Region Mapping
- Once you edit the Region Mapping section, you will see all these headers.
Country, State, City, Start Zip Code, End Zip Code, Region, Rep Firm, Disti Firm, Account Manager
- Fill in the data as needed and save it.
- Then while creating Accounts in Accounts module, the data which are already saved will be auto-picked.
Keep in mind that Country, State, Citry, Start Zipcode and End Zipcode is the unique key. So if you export the current Region mapping and enter a new row or modify one of the above fields for the current row, it will create a new record in the Region Mapping table.
While defining your regions, keep in mind that security and access control is often defined by a combination of regions and roles. For example, Reps and RSMs are typically region based, whereas Marketing Managers may be Business Unit or Product Family based etc.
Roles are used to control who sees what, both for application/module visibility and data accessibility. Roles define a given users privileges in the system. For example, a user in Sales Rep role may not have Export or Delete privileges. Please define your Role Hierarchy in Excel while keeping the following concepts in mind:
- Each user in NEHANET will be assigned a Role in the system in the Users module.
- Roles can be hierarchical with a parent-child relationship. Child roles DO NOT inherit permissions from their Parent role, allowing for greater flexibility in the role definition process.
Scoping Rules/Account Teams
- Roles are associated with a Scoping Rule — such as Scope By Region. The scoping rule controls the data access for all users in that role. For example,Users in a Role scoped by Region will see all Accounts (and related Opportunities/Forecasts/Quotes/Samples, etc in their region, and therefore see all opportunities, forecasts, samples etc for the accounts in their region.
- Account Teams: In addition to seeing Accounts in your Region, you can give selective access to Accounts in other Regions by making users Teams members to the Account. It requires Admin privilege to assign Team Members to Accounts. Once Team Members are added to an Account, the list of Team Members for that Account is visible in the corresponding Account details page. Once an Account is visible to a user, the corresponding Opportunities, Forecast, Quotes, Samples, etc. are visible to the user. This feature is useful for sharing Global Accounts with your Regional users without needing to assign multiple Regions to the Regional users.
Users in Admin/SysAdmin role will see all Accounts and related Opportunities, Quotes, Samples, etc. There is no need to set User Region Mapping for users in Admin/SysAdmin role.
Users in Rep role will only see those Accounts where their Company is marked as the Rep Firm. Similarly Users in Disti role will only see those Accounts where their Company is marked as the Distributor for the Account. There is no need to set User Region Mappings for users in Rep and Disti role.
NEHANET can be set up to control access control along several additional dimensions, which are useful in managing large complex organizations:
- Users belonging to a particular Business Units will only see opportunity and other data for parts belonging to that Business Unit.
- Users belonging to particular Rep locations or Distributor branches will only see opportunity and other data for accounts belonging to them. However, Users associated with the Rep or Disti Head Office will see opportunity and other data for all branches/locations of that particular Rep or Disti office.
Setting Up Roles
For each role, please specify in Excel the scoping rule you desire for that role. NEHANET Services will set your system up as closely as possible to your requirements; and will get back to you for clarifications or to ask you to adjust your requirements to match the system’s capabilities. Do note that NEHANET will create your Roles to get you going and will be glad to setup the security for each role if you can provide us with your requirements, however, it is your responsibility to edit each role and make sure that the permissions for each role are correct.
Please let us know if either the Business Unit or the Rep/Disti Branch setup are of interest to you while setting up the system.
Accounts are one of the pillars of your NEHANET system. Please keep the following concepts in mind.
- Accounts can be Customers or your Reps and Distributors. This is controlled by the Type of the Account. Valid values for Type are: Direct Customer (Accounts managed Directly), Disti Customer (There is a Disti involved in managing the Account), Rep Customer (There is a Rep involved in managing the Account), Rep, Disti, Contract Manufacturer and Chipset Manufacturer.
- Accounts can also be categorized into different tiers using the Sub Type field. You can create groups like Strategic or Key Accounts. This will help you model Strategic Account Analysis.
- All Accounts are associated with an Account Manager, who is one of your HOST company Users or Contacts, typically the Regional Sales Manager (RSM) for that account. If an account is of type Rep Customer or Disti Customer, then you need to specify the associated Rep and/or Distributor. You also have the option of specifying the contact at the Rep or Disti firm who is managing the account for you.
- Accounts can have both Users and Contacts associated with them. Contacts can be promoted to Users if required.
- Accounts are tied to leaf level Regions. Regions can be manually entered when the Account is created or set automatically via Region Mapping. Your system can also be set up to autofill the regions if you have provided a region mapping as mentioned earlier.
- You can create any number of Custom Fields for Accounts. These fields can be arranged in a Custom Layout in the Account Edit page.
- You can attach documents like NDA, Contract pricing Agreement, etc to the Account record allowing for an easy way to share additional information with your users.
Customer Type drives global information sharing and visibility
NEHANET supports several Customer Types out of the box which serve a key role in sharing and controlling access to information. For examples, customers can be categorized as Direct Customers, Rep Customers or Disti Customers. Partners can be categorized as Reps, Distributors, Contract Manufacturers etc.
If an account is categorized as a Rep Customer, then NEHANET recommends that a Rep be associated with that account (either manually or automatically using the Region Mapping). NEHANET will then restrict access to that account only to that Rep. Similarly, if an Account is categorized as a Disti Customer, associating a Distributor to that Account, restricts the visibility that that Account only to that Distributor.
If an Account is categorized as a Direct Customer, NEHANET recommends that neither a Rep nor a Distributor be assigned to that Account. NEHANET then restricts access to this account to the Account Manager or Team Members for that account. None of the Rep or Disti Users can see this Account.
There is a System Field in Accounts called “Export Control”. This is a pick list with two values: “Cleared Party” and “Denied Party”. You can set a default value for this during Account creation and set permissions for this field so only certain roles have access to modify this field. This is useful for identifying which Accounts are cleared for working with restricted parts. Additional Business rules can be added as needed.
Please provide a spreadsheet with a large enough subset of your current customer data, so that our Services team can either use that to configure your Accounts module properly and load in your sample data, or review and get back to you for any clarifications. Do also note that NEHANET can import your entire accounts data from Excel, or we can migrate the accounts data directly from the database server underlying your current customer master.
We can set your system up such that you can keep your Custom Master in your ERP, and have it updated in NEHANET automatically every so often. At the same time, you can allow users to create new accounts in NEHANET and keep them separate from the accounts in your customer master. A typical example is that reps will create sample requests for new customers, which typically might not be in the ERP. Therefore the Rep can create a new account, and this account is differentiated from the accounts already in your Customer Master. Please specify in your Requirements document if this is indeed your immediate or long term requirement, and we will keep that in mind during your rollout.
Please do not use Customer name “*Unknown*” in the system. That is a NEHANET reserved word and will not show up in the grid.
Please provide us with an excel spreadsheet consisting of your Users. Please keep the following concepts in mind when providing us with this list.
- Users are associated with Roles, which you have already specified in your Requirements document earlier. The User’s data access rules are controlled by the Scoping Rule specified for that Role.
- Users are associated with Regions, which you have also already specified in your Requirements document earlier. Note that Users can be associated with leaf level Regions or Super Regions. For example, Reps and RSMs will be associated with leaf level regions, while RSD and Marketing/Sales Executives will be associated with high level super regions.
- Users are associated with Accounts, which can be either the Host Company if they are work for your Company, one of your Business units, or your Reps and Distributors.
Please provide us with the login name, desired initial password and email address for each user as well. Note that it is your responsibility to get each user to change their password upon initial login.
Parts can be grouped under Part Families. They can also be associated with Business Units.
- When deciding the list of Product Families, please keep in mind that you can have different feature/attribute sets for different Part Families. These are used to drive functionality off the Parts database. For each attribute, such as Voltage, Package etc, you can have different attribute values.
- When deciding the list of Business Units, please keep in mind that this is often used to control Marketing access to Sales information. For example, marketing users in one business unit can see all opportunities, forecasts, samples etc for the products in their business unit, but not for the products in a different business unit. Please see Users section to learn how to associate Users with Business Units.
Do keep in mind that you can set up custom fields in the Part module and have them drive high level business processes. Several examples are:
- Specifying whether a given part should be Forecasted, Sampled and/or Quoted etc.
- Specifying MOQ at the part level and having it used in the Quoting approval process.
- Specifying Cost at the part level and using it for margin calculations in the Quotes module or POS and Sales Order modules.
- Specifying Inventory levels at the part level and using it in stock rotation.
As a first step, please provide us with the list of Part Families, and the list of Feature (attributes and their values) for each Part Family. Please also provide the list of business units. Once this information is provided and your system is setup, the NEHANET Services team can provide you with a set of templates for each Part Family. You can use these templates to provide part data to NEHANET for import, or you can do the import yourself. Note that NEHANET can migrate parts data from your existing system if you so require.
NEHANET can also setup your system such that the Part Master in kept in your ERP system and updated automatically to NEHANET on a periodic basis. Please provide more details on this point in your Requirements document if this is an immediate or possible long term need for you so we can optimize your system accordingly.
The NEHANET Business Rules Engine is one of the most advanced yet flexible and easy to use fully integrated business rules engines available today. The Rules Engine provides unprecedented flexibility in cross linking business processes and information flows, and in setting up and managing business processes in NEHANET. Please keep the following concepts in mind.
- Business Rules tie Objects or Entities to each other. To be more precise, Business Rules tie specific attributes or fields of objects or entities to each other. For example, if a customer is marked Inactive, then all Quotes for that customer should be marked Invalid. Or, if a new account is created in the system, the new account should be placed into a certain workflow Q for review and approval by the right people.
- Business Rules link all major Objects in NEHANET to one another. This includes Custom Objects as well. So Accounts, Parts, Opportunities, Quotes, Samples, Debits, Sales History, POS, Escalations etc all can be linked thru the Business Rules Engine.
- Futhermore, as a special note: Objects can be linked to themselves, in what is called Self-Referential Rules.
- The Business Rules Engine provides support for standard conditional operations. For example, set the Account Status to reassign if the account is assigned to an User who has now been marked Inactive. In addition, the Rules Engine provides support for custom logic. This allows you to implement complex business logic for a given rule and make it part of your NEHANET system.
- Rules can be flagged as Active, Development or Inactive. Rules in Development status are executed as though they are Active Rules. However, the actual data update is NOT trigged, allowing you to test the Rule properly prior to activating it.
- The Business Rules log keeps detailed track of which rule was executed, at what time, why, and on what objects.
- Properly defined and implemented business rules can give your system a lot of flexbility and power. However, badly designed business rules can have adverse and often unforeseen effects. We recommend, as a first step, to discuss and provide our Services team with your requirements and have them configure and test the initial set of rules for you. Once that is done, and you become more familiar with the power and flexibility of NEHANET, you can manage and create additional business rules yourself through the Business Rules administration interface.
NEHANET is available for deployment in two ways:
A. Cloud Solution:
NEHANET runs as a Cloud application and is available 24×7 without the customer having to install or purchase any additional software or hardware. The NEHANET Cloud is hosted at Rackspace (www.rackspace.com), a reputable managed hosting provider.
B. In-house Solution:
Unlike many other Cloud providers, NEHANET is also available for deployment on-premise at the Customer’s facility. If the Customer selects this option, they are responsible for providing the hardware and software described below. They are also responsible for administrative tasks such as security firewalls, database backups etc.
- Servers: The hardware should be sized proportionally depending on the Customer’s size and deployment scenarios.
- Operating System: Windows 32-bit, 64-bit
- Web Server: Tomcat 5.5 or later. Apache Tomcat can be downloaded for free from http://www.apache.org. NEHANET Services can download and install it if needed.
- Database: Microsoft SQL Server 2008 or later The customer will need to provide this.
- Java™ 5.0. This is free from http://java.sun.com
Estimated Setup Time: Up to 10 hours (NEHANET services billable hours).