primavera unifier in action - oracle primavera collaborate 14
TRANSCRIPT
REMINDER
Check in on the
COLLABORATE mobile app
Primavera Unifier in Action
Prepared by:
Greg Colf
Business Systems Analyst, Senior
Qualcomm Incorporated
User, Group, and Template Administration and Security - Best Practices for a Successful Implementation
Session ID#: 15460
Presenter Background
■ Currently
▪ Qualcomm Real Estate
and Facilities (1 year)
▪ Oversee all Unifier
development and
operations.
▪ Two additional staff
members
— Development/Cost
Controls/Support
— Training/User
Management/Support
■ Previously
▪ University of Utah
Facilities Management
— Unifier Development and
operations (6 years)
— FM Webmaster
— Application Training
▪ Southern Utah University
— Taught Information
systems and networking
courses. (10 years)
▪ Construction Management
Experience
Company Background
■ Qualcomm Facts
▪ 220+ CDMA licensees
▪ More than $22.35 billion in
cumulative R&D
▪ Approximately 26,600 full-
time, part-time and
temporary employees
▪ 188 worldwide locations,
with 78 US locations
▪ FORTUNE’s 100 Best
Companies to Work For
▪ FORTUNE’s Most
Admired Companies
■ Qualcomm Real Estate and Facilities
▪ 600 + Employees
— San Diego
— Domestic
— International
▪ Unifier for Construction
Management
— 2008
— 400+ Users
— 80~90 active projects
Agenda
• User
• Group
• Project/Shell
Review Template Structures
• Project Permissions
• Document Permissions
Examine Complexities
Establish Best Practices
Objectives
■ Abstract: User, Group, and Template administration in Unifier can be complex
at best. Key to the successful implementation and ongoing administration of the
Unifier environment is a well thought out and systematic approach that includes
the consistent application of project and permission templates. This session will
explore how these templates can be established and maintained throughout the
system life cycle.
Objective 1: Understand the user, group, and project templates
Objective 2: Examine the complexities involved in managing project and
document permissions
Objective 3: Establish an approach for managing security & administration
through the use of standards & templates
Objective 1: Understand the user, group, and project templates
User Management
■ Company Workspace User Types
▪ Company User
— Created and Managed by Company Administrator
— Company Password Policy Applies
▪ Partner User
— Created by Site Administrator, Assigned by Company Administrator
— Default Password Policy Applies
■ All user accounts are initially created at the Company Workspace
■ User status at Company Workspace
▪ Active, Inactive, On-hold
▪ Controls access to system
▪ Inactivates in all projects
User Management
■ User Attribute Form
▪ Configure Company User Log
▪ Configure Partner User Log
▪ Add user data elements to
attribute form
■ User Preference Templates
▪ configure the default user
preference settings for new
users
▪ update existing users’ user
preferences options.
▪ establish a standard for user
preference settings.
User Management - Permissions
■ Two Categories of Permissions
▪ Access Control Permissions
▪ Document Manager Permissions
■ Permissions can be granted at
▪ Company Workspace
▪ Project/Shell Template
▪ Project/Shell
Permissions versus Access Control
■ Manage individual user or
group permissions in the
Permissions tab
■ Quickly view or adjust
permission settings for a
particular user or group.
■ Copy a permission template
to quickly set permissions for
a new user or group
■ Save an existing user or
group’s permission settings
as a new template
■ Displays the permissions
granted to all users and
groups per module.
■ You can add, remove or
adjust permissions for
multiple users or groups
■ Generate and print an Access
Information table summarizing
permission settings.
■ Updates group at working
level but not templates
Permissions Access Control
Access Control
User Management Company Workspace Permissions
■ Permissions are granted to users to allow them access to Unifier features.
■ A user can be granted permissions individually, or can inherit them from the group(s) to which the user belongs.
■ Users can be granted individual permissions in addition to group permissions. If user-level and group-level permissions are different for a module, the highest level will be granted to the user.
■ If you grant permissions to project or shell level User Mode features from the company-level Permissions tab, the new permission settings will take effect on future projects or shells
■ Permissions in a project or shell template from which the project or shell is created override Company level permissions.
User Management Project/Shell Template Permissions
■ Users are identified by their unique User ID.
■ Any Active, Inactive or On-hold users can be pushed.
■ If the user does not already exist in the shell, the user will be added
to the shell with the permission settings and group membership.
■ If the user already exists in the shell, the user information is updated
(replaced) with the user information as entered in the shell template.
This includes permission settings and group membership.
■ If a group that the user was added to doesn’t already exist in the
shell, the group will be added, and the user will be added to the
group. Group permissions are not updated; this is done by updating
groups.
■ If the group already exists, the user will be added to it. Group
properties and permissions will not be affected.
User Management Project/Shell Permissions
■ At a minimum, a user must be a member of the project/shell
■ Once added to a project/shell
▪ cannot be removed
▪ can be inactivated at project/shell level
■ Permissions can be:
▪ Granted on an instance-by-instance basis
▪ Pushed through shell templates
▪ Users can be managed through groups or added individually to
instances
Group Management
■ Groups are a way to collect Users together so that adding new team members to the project and assigning permissions can be done quickly and efficiently.
▪ members of the same project team
▪ share the same access control privileges.
■ At the company level, groups can span projects. At the project level, all members of a group are members of a given project.
■ Different members of a project may have different access to Unifier functionality, depending on their role on the project.
■ Company level groups cannot be copied into a project.
■ Groups cannot contain other groups
Group Management
■ As users are added to a Group, they will inherit the Group’s permissions. If they are in more than one group, then the highest level of permissions granted in any group for a module will prevail.
■ When adding users to the group, you can choose eligible users from the sponsor company and any partner company users. The company short name will be listed in the User Picker window next to each user.
Group Management Updating Groups
■ Groups are identified by their unique Group Name.
■ All group properties, including permission settings, will be added or
updated in the shells that you selected.
■ If the group does not already exist, the group will be created with
the permission settings. Group membership (user list) will not be
updated in the shell.
■ If a group of that name exists, the properties and permissions of that
group will be replaced with the new group, but not the list of users.
■ Users are not automatically added to the group; they need to be
added by updating users (group membership).
■ Changing a group name will update group in template, but will
create a new group when pushed
■ Groups cannot be pushed to Document Manager Structure
Project Management
■ Projects can be created
▪ Manually
▪ Template
■ Advantages to using a template include
▪ Ease of individual project setup
▪ Consistency across projects
▪ Ability to update project configuration
■ Challenges to using templates
▪ Multiple project types increases number of templates
▪ Potential for inconsistent configuration
Templates
■ Permission Templates
▪ All levels of permissions
▪ All modules
■ Can be copied in to
— Company Workspace
— Project/Shell Template
— Project/Shell Instance
■ Cannot be pushed
Templates
■ Templates used in Project/Shell Templates
▪ Cost Sheets
▪ Folder Structures
▪ Funding
▪ General Spends SOV
▪ Reports
▪ Rules
▪ Schedule Sheets
▪ Activity Sheets
■ Cannot update Project/Shell Instances
Templates Shell Template
■ Used to build shell instances
■ Users can be inactivated and removed
■ Holds BP Configuration(s)
■ Document Folder Structure and Permissions
▪ Assigned through
template users/groups
▪ Built at Project Creation
▪ Cannot be pushed
Objective 2: Examine the complexities involved in managing project and document permissions
Project Templates
■ BP Configurations used in
multiple templates
■ User permission changes
and user pickers
■ Permissions are difficult to
track
■ Cost and Schedule Sheets
are difficult to update
■ Create “master” template
■ Maintain group consistency
between stage and prod
■ Use User/Group Export/Import
to avoid overwriting group
assignments
■ Assign permissions only
through groups
■ Plan for consistency across projects – easier reporting
■ Plan for added business processes (logical sources)
Project Document Manager
■ Initial Structure and Permissions flow from template
■ Groups added to template are not added to projects
■ Folder/Document Permissions are not as granular – No “View Company Records”
■ Users need permission for auto publish
■ Build a comprehensive folder structure, lock first level
■ Create more generic DM-specific groups
■ Limit access to DM node or folders . View attachments from BP record
■ Provide “Add Document” permission for folders
Objective 3: Establish an approach for managing security & administration through the use of standards & templates
Managing User Accounts
■ Users should be assigned to groups at all levels
▪ CW, P/ST, P/S
■ Assign permissions at group level – not Individual
■ Use caution when pushing user accounts from Project/Shell Template
▪ Consider project-specific assignments that might be overwritten
▪ Use User/Group Assignments Export/Import where appropriate
■ User must have appropriate folder structure permissions to publish/autopublish documents to a given folder
Managing Groups
■ Maintain consistency across Company Workspace, Project/Shell Templates, and Projects/Shells
■ Leverage Permission Templates
▪ Create 1:1 relationship between template and group
— Update Permission Template
— Copy to Project/Shell Templates
— Push group permissions from Project/Shell Template
■ Plan any group name changes carefully
■ Use caution when granting administrative mode permissions
Managing Project/Shell Templates
■ Create only as many as you need
■ Create a “master” template for business processes
■ Maintain group consistency across templates
■ Update processes and permissions consistently
■ Plan Cost and Schedule Sheets with care
▪ Updates are possible, but challenging
Document Folder Structure Permissions
■ Plan shell and document folder structure permissions separately
■ Document Folder structure permissions may need to be narrower or broader depending on design
■ Create groups for
▪ Document Publishers
▪ Document Managers
Reports
■ Create common reports at report template level
■ Copy report templates in to P/S Templates
■ Push reports from P/S Template
■ Turn off report permission notification before push
▪ User preferences template
■ Apply User-Defined Reports permissions with caution
▪ Create = Create user-defined reports
▪ Full Access = Access to all UDRs created for the project,
regardless of owner. User can edit, change permissions, or
delete reports.
▪ Users with Create permission can generate UDRs against
records they cannot see.
Questions?
Contact Information
Greg Colf, Qualcomm, Inc.
Business Systems Analyst, Senior
[email protected], (858) 845-8915
Please complete the session evaluation We appreciate your feedback and insight
You may complete the session evaluation either
on paper or online via the mobile app