Chapter 12: Incorporating Supervisor Settings into the Universe Design

 < Day Day Up > 



Designer allows you to build and maintain a universe. Supervisor allows you to grant users access to the universe and other resources. This book assumes that most of your users have already been defined to Supervisor and focuses on the settings a universe designer, security administrator (Supervisor), or power user must understand that affect BusinessObjects functionality. It is not intended to cover the more technical start-up aspects of the Supervisor module.

While most of the work in Designer is done offline and then exported, Supervisor updates repository information in real time.

Security: A Philosophy

Security can be a touchy subject in many organizations. How much information should be public within a company? If information is overly restricted, how much will that impede decision-making? Bernard Liautaud, Business Objects CEO and author of e-Business Intelligence: Turning Information into Knowledge into Profit (McGraw-Hill, 2000), does an excellent job of describing the attitude toward information within organizations. Liautaud discusses four models:

  1. Information dictatorship, in which few people have access to information

  2. Information anarchy, in which data is duplicated in multiple forms, resulting in chaos

  3. Information democracy, in which information flows in a free but managed way

  4. Information embassies, in which information flows beyond the immediate organization to partners, suppliers, and customers

Unfortunately, many companies are stuck in an information dictatorship. They have not yet realized that to survive in today’s competitive environment, decision makers need access to information now, not when the IT programmer can create the report or when the financial or business analyst can build a new query. Information dictatorships often result in data chaos; the financial controller will run a huge report and create an MS Access database so that decision makers within the business unit can access information. Bravo for the users (at least in the short term) and pity the poor IT person who has wasted so much time and effort building an overly secure reporting system.

Many business users would be happy if their company could at least reach the information democracy stage; information embassies are still a distant dream for most. As the BusinessObjects supervisor, it is probably beyond your control to change your company’s security philosophy. However, you can make gaining access to information easier or harder. Supervisor allows you to restrict information down to the individual user, row, and column level. If you overly restrict access, the whole BusinessObjects implementation risks failure.

Ultimately, security philosophy should be driven by a cost-benefit analysis. It is costly and resource-intensive to secure data. The more granular the security, the more costly it is to implement and maintain. If the security impedes user productivity and decision making, you run a high risk of users’ sharing passwords, ultimately rendering the security controls a failure. When restricting access to information, consider the following criteria:

  • Are there legal reasons for securing the data (employee details, patient medical records, and so on)?

  • What harm could be done if employees access the information? Is the cost to restrict access to a specific level higher than the potential harm an employee may cause?

  • What opportunities may be missed if employees can’t access the information?

Finally, if your data warehouse, data mart, or ERP system has its own restrictions, do not add any more in Supervisor; ensure you use individual data source login IDs (refer to Chapter 6, “Connections”) to leverage that security. If you add a layer in BusinessObjects, you will be wasting your time and your company’s money, as well as exhausting users’ patience.

Understanding Your Company Organization

Before creating and modifying users and groups, you must understand your company’s organization and how you want that to translate to your Supervisor definitions. What follows is an example of a matrix organization. Table 12-1 shows a partial list of employees for a company that has five functional departments. Figure 12-1 shows an organization chart for how this company may be represented in Supervisor.

Table 12-1: Employees May Work Across Multiple Departments

Employee

Job Title

Finance

Human
Resources

Manufacturing

Sales and
Marketing

Supply
Chain

Al Saraisky

CEO

Ö

Ö

Ö

Ö

Ö

Brendan McConnan

Supply Chain Manager

    

Ö

Jami Blake

Finance Director

Ö

    

Lauren Saraisky

Legal Counsel

Ö

Ö

 

Ö

Ö

Mary Olen

HR Director

 

Ö

   

Megan Michelle

VP Marketing

   

Ö

Ö

Peggy Eschbach

Medical Consultant

 

Ö

   

Samuel Steven

Manufacturing Director

  

Ö

 

Ö

click to expand
Figure 12-1: A department at the upper level is called an ancestor, and its children are descendants. Each user can be defined to one or more groups; each copy of a user is called an instance.

Each functional department translates to a separate group within Supervisor. The main group at the root level is the company, Plastics Express. This is referred to as an ancestor of all five departments, which are called descendants. In Figure 12-1, Finance has two additional subgroups, Accounts Payable (A/P) and Accounts Receivable (A/R). Both Plastics Express and Finance are ancestors to A/P and A/R. Understanding these relationships is critical for determining which rights get inherited.

As CEO of the company, Al Saraisky serves multiple roles within the organization and works across all departments. In Supervisor, each occurrence of Al within a group is called an instance. The first instance is denoted with a solid figure; each additional instance is gray. In Figure 12-1, there are five instances of Al. Lauren Saraisky is the chief legal counsel and so will need access to any information that may have legal implications. She needs access to employee contracts (Human Resources), customer credit records (Sales and Marketing), and material safety data sheets (Supply Chain), and so has three instances. Peggy Eschbach is the company’s medical consultant and needs access only to employee records (Human Resources) and has one instance.

Resources

A universe is a resource that can be associated with the company, one or more groups, or the individual employee. Documents, stored procedures, configurations (software functionality), and domains are also resources that can be associated with each of these levels.

In Table 12-2, there are several universes. Some universes will be used by one and only one department. For example, Human Resources is the only group with access to the Human Resources universe. However, the Orders universe is associated with both the Manufacturing group and the Supply Chain group. Manufacturing personnel may want to know which orders are coming in for production planning, while Supply Chain personnel must keep track of on-time shipments. The test universes are used for training purposes and can be used by all employees in the company.

Table 12-2: Universes Can Be Associated with One or More Groups or Departments

Universe
Name

Filename

Finance

Human
Resources

Manufacturing

Sales and
Marketing

Supply
Chain

Orders

Orders.unv

  

Ö

 

Ö

Sales

Sales.unv

   

Ö

Ö

Bank
Account

Debit_cre.unv

Ö

    

Human Resources

Humanres.unv

 

Ö

   

Test Fashion

Testfash.unv

     

Island Resorts Marketing

Tbeach.unv

     

Figure 12-2 shows how these resources get linked to each individual group or to each individual user. The test universes TESTFASH and TBEACH are linked at the root, Plastics Express, level. All descendants will inherit access to these universes. The HUMANRES universe is linked to the Human Resources department only. Therefore, members of the other departments cannot use this universe unless it is specifically linked to the user. A document, Health Report, has been linked to the individual user Peggy. Only she can access this report; others within Human Resources cannot.

click to expand
Figure 12-2: Resources such as universes, documents, stored procedures, and timestamp settings get linked at each group. The descendants inherit access to these resources.

It is possible to link a universe at an ancestor level and then disable it at a descendant level. However, because of the way Supervisor stores these settings, your repository will be smaller if you use link rather than enable/disable.

Caution 

When a designer exports a universe to the repository, if the designer is defined at the root level, the universe always gets exported to the root level. The general supervisor must always unlink the universe from the root group, or descendant groups may unintentionally gain access to data. Ideally, designers should also be defined within groups to ensure universes are correctly exported to the corresponding group.

User Types and Profiles

The list of employees and available resources translates into the Supervisor settings shown in Figure 12-3. Notice also that each user has a different symbol or user type associated. The user type is determined by a profile assigned to each user. Table 12-3 explains each profile.

click to expand
Figure 12-3: Groups and users are linked to resources in Supervisor. Each user has a profile that determines which software and menus the user sees.

Table 12-3: Supervisor Allows You to Assign Profiles to Each User

User Type

Products

Icon

Explanation

General Supervisor

All

Keys

Created during setup. This user cannot be disabled or deleted. The General Supervisor has access to everything and can control the BusinessObjects repository and its contents.

Supervisor

Supervisor, BusinessObjects

Green person

Creates and maintains individual users; grants access to resources.

Designer

Designer, BusinessObjects

Pink person

Creates and maintains universes.

Supervisor-Designer

Supervisor, Designer, BusinessObjects

Red person

Creates universes and users.

User

BusinessObjects

Blue person

Builds queries, reports and analyzes data using any of the end-user tools.

Versatile User

Initially a subset of BusinessObjects

White person

This profile can be customized by a supervisor to provide a subset of menus or end-user products to certain users. One can modify this user type to include access to other products.

Supervisors may create additional profiles to restrict functionality. For example, Business Objects licenses its user modules in three parts: Reader, Reporter, and Explorer. The functionality is all in one executable, so if you license 100 Readers and ten Explorer licenses, 100 users could theoretically use the Explorer modules. Oddly enough, the company does not provide the corresponding profiles to restrict functionality to match product licensing; the supervisor has to create them. In this respect, command restrictions or menu items behave like resources that get assigned to each group or individual user.

Company vs. Department: Where to Create a User

Users can either be added at the root or company level or within a descendant group. For example, Plastics Express has a new customer service representative (CSR), Hermine Gallagher. As a CSR, Hermine will work within the Supply Chain organization. You can add Hermine directly to the Supply Chain group, or you can add her under Plastics Express and then specifically to Supply Chain. Where you initially define the user is a reflection of company organization, security policies, and how much power you want to give to BusinessObjects supervisors. It only minimally affects response time.

Centralized or Decentralized Security

Companies either centralize IT access or decentralize it by department, business unit, or function. Security definitions for all systems, not just BusinessObjects, are done centrally. In this case, the username most likely exists at the root; a BusinessObjects administrator may have done a mass import of all employees or potential BusinessObjects users from a company directory or ERP username table. In this situation, your role as supervisor is to ensure each existing user is correctly defined to each group or resource.

If security is decentralized by function or business unit, then a supervisor role should logically exist within each function or business unit. Decentralized supervisors may add users and may grant or deny privileges. However, it also means that one group’s supervisor may unwittingly delete a user that also accesses another group. The general supervisor may have added the user to this secondary group. Deleting a user from the repository will also remove any historical usage information, generally going against most companies’ retention policies.

Tip 

Add users centrally but decentralize control over resources.

Supervisor Control of Inherited Users: An Example

To better illustrate the practice just described, let’s look at the fictitious Plastics Express. Jami Blake is the Finance Director. She has been designated a supervisor and designer for this group. Al Saraisky is the CEO but is a member of this group so that he can access Bank Account information. As the supervisor of the Finance group, Jami can change Al’s profile to grant access to any Finance universes and can modify user definitions (disable login, reset password) that will affect Al’s access, even to universes that do not belong to the Finance group. However, Jami cannot delete Al from the repository definitions because Al’s ID was created at the root level. Only the BusinessObjects administrator or general supervisor can delete Al’s ID, because he was defined at the corporate, or root, level.

If, however, a new employee joins the Finance department and Jami creates that user, then Jami can subsequently delete the user. Jami cannot add users to groups she does not control (such as Human Resources).

Should Supervisors Add Users?

Okay, now the smart, security-oriented BusinessObjects administrator will look for ways to make sure that decentralized supervisors cannot create users (perhaps under command set restrictions described later, in “Software Functionality: Command Restrictions”). Perhaps in some organizations, the individual functions or business units can patiently wait until the central group creates the user. However, in most cases, this is where the whole security model falls apart: If a new logon ID is not available immediately, business users will simply share their login IDs and passwords; they are under pressure to get the new employee productive as quickly as possible. Of course it’s against policy! Of course they signed a form saying they would never give out their password! But it happens, and they do.

A workaround is to allow group supervisors to add users, but ensure that the general supervisor or centralized security group periodically reviews which new users group departmental supervisors have created. The following screen shows that a new user, Hermine Gallagher, was created in a group and does not yet exist at the root, or company (Plastics Express), level. To access this screen, select the root group, then click User/Group Properties.

click to expand



 < Day Day Up > 



Business Objects(c) The Complete Reference
Cisco Field Manual: Catalyst Switch Configuration
ISBN: 72262656
EAN: 2147483647
Year: 2005
Pages: 206

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net