A well-structured organization is key to efficient operations, clear reporting, and effective collaboration. Whether managing a company-wide framework or organizing projects within Omega 365, having a logical and flexible structure ensures the right people have access to the right information while maintaining security and operational efficiency. This guide outlines key considerations and best practices for setting up an organizational structure that supports business needs, enhances collaboration, and optimizes workflows within Omega 365.

1. Understanding Organizational Structure

The main structure of Omega 365, organization structure, is built around org units organized into a hierarchy / tree structure where all org units will have one and only one single parent. These org units can host any type of data such as documents, risks, activities, workflows ++. In order to have access to data a user will need to have a role for a given org unit. Various roles gives access to a different set of data.

Users have access to data via roles. Some roles gives read-only access and other roles will have read/write access to the data. A particular user may have some read-only roles and some read-write roles.

Key Components of an Organizational Structure:

• Org Unit: A core entity within the structure representing a business unit, department, or project.

• Hierarchy: A parent-child relationship where each org unit has a single parent, ensuring logical flow and accountability.

• Domains: Groupings of multiple org units under a shared umbrella, enabling controlled data sharing within the domain.

Inheritance gives access to sub org units

As a default users inherit access down the org structure meaning that if you have a role in an org unit you also have that same role in all underlaying org units.

Restricted org units (do not inherit)

Some org units are marked as restricted. For these org units it is not enough to have a role in an org unit further up in the hierarchy. Only those users with a role directly on the restricted org unit will get access.

A person with a role in "Region E" will have access to "Section #2" and "Section #3" (including "Project D"), but he/she will not have access to "Project A/B/C" or Section #1.

Persons also "belong" to an org unit

In addition to all kind of information and data also persons are treated as an information object that belong to an org unit. The same restrictions when it comes to access for viewing and updating is implemented for person records.

2. Defining Your Organization Structure

Align with Reporting Needs

Your structure should reflect the most commonly used reporting and operational processes. A general approach often includes:

• Enterprise: The top level representing the entire organization.

• Business Area: Major functional or operational segments.

• Division: Specific market segments, geographic locations, or legal entities.

• Asset: The organization's assets (in this context this could be buildings, airport, railway networks & stations, gas processing facility, wind park, data center etc)

• Project: Individual initiatives managed under an asset.

• Contract: A key level representing legal agreements and contractor management. In some cases, sub-contractors may be set up as individual org units within the structure.

Flexible Yet Structured Approach

While organizational structures should be well-defined, they must also allow for adaptability. In Omega 365, the organization structure is flexible, enabling modifications when necessary. However, before making changes, consider their impact on integrations, reporting, and other dependencies.

3. Ensuring Effective Data Access and Security

Role-Based Access Control

Users should only access relevant data based on their roles within specific org units. Omega 365 implements:

• Role Inheritance: Users automatically gain the same access level for all underlying org units.

• Restricted Org Units: Specific units requiring explicit role assignments, even if a user has access to higher-level units.

By implementing these controls, organizations can balance transparency with security, ensuring that only authorized personnel can access sensitive data.

4. Handling Project Structures and Phases

Organizations often manage multiple projects with different stages and funding phases. Structuring these correctly ensures clarity in tracking budgets, reporting progress, and managing contracts. Best practices include:

• Project Phases as Org Units: A good practice is to separate the main phases into separate org units; typically separating the phase before and after sanction. There are cases where the 'pre-sanction' phases again has been split into mutlipe org units. What will be the most practical can differ based on how these phases are managed, which again may depend on complexity, budgets, funding, company procedures and more. 

• Work Breakdown Structure (WBS): A complementary framework that further decomposes projects into smaller, manageable components. Structuring these correctly ensures clarity in tracking budgets, reporting progress, and managing contracts. Best practices include.

The Project's Work Breakdown Structure is a central structure for cost and scheduling.

5. Contracts and Frame Agreements

Frame agreements are contracts that span multiple organizational units, enabling organizations to manage long-term relationships with vendors, contractors, and service providers across various projects or divisions. Handling frame agreements effectively requires a structured approach to ensure consistency, transparency, and proper data access.

Since a Frame Agreement will span across multiple projects, the org unit for the frame agreement needs to be placed above the project. The contracts, call-offs, against the frame agreement, is then located under the project, alongside the other contracts. On the Contract itself, one can link it back to the frame agreement.

6. Leveraging Common Org Units for Shared Information

In large organizations and projects, there is often a need for a centralized space to share templates, procedures, and documents with all project members, including contractors. Common Org Units are designed to facilitate this.

Key Features of Common Org Units

• Automatic Creation: A common org unit (e.g., "[Name of Domain]/Common") is automatically created for each domain, ensuring a shared space for relevant documents.

• Controlled Access with Roles: A predefined role, "View Common," ensures that only authorized users have access to shared information.

• Granular Sharing Mechanism: Instead of the deprecated "Publish To" functionality, users can now share documents and scope items by selecting a specific org unit role.

• Enhanced Security and Performance: Reducing unnecessary access prevents data exposure and optimizes system performance.

Use Cases for Common Org Units

1. Sharing Project-Wide Documents with All Users:

   • Assign the "View Common" role to all contractors and internal users.

   • Share the necessary documents with the "[Name of Domain]/Common" org unit.

   • This ensures streamlined access without exposing data beyond the intended audience.

2. Providing Risk Managers Access to Specific Information:

   • Share documents and scope items with the org unit "BD - Business Development" and role "Risk Manager."

   • This method ensures only designated personnel access critical risk-related information.

3. Establishing Standardized Templates and Procedures:

   • Store company-wide templates, guidelines, and procedures in the "Common" org unit.

   • Users from multiple projects can access standardized documentation, ensuring consistency across the organization.

By incorporating Common Org Units, organizations ensure efficient, secure, and structured information sharing across projects while maintaining role-based access control.

7. Integration and Portfolio Management

Cross-System Data Integration

A structured organization must integrate seamlessly with financial, scheduling, and risk management systems. Key considerations include:

• Defining project initiation triggers. Will the structure correspond to a organization structure managed in another system?

• Mapping system responsibilities to avoid redundancy. What system is the master for which data

• Ensuring data consistency across platforms. When integrating with different systems, having alignment on the key structures, such as the organization structure, makes it less complex.

Portfolio-Level Reporting

Organizations require flexibility in viewing consolidated reports across different structures. A well-configured organization structure allows dashboards to display data based on legal entities, project types, or regional breakdowns, supporting diverse business needs.

A well defined organization structure enables efficient portfolio reporting - where KPI's can reported at all levels in the organizations.

Conclusion

Setting up a fit-for-purpose organizational structure requires careful planning, alignment with reporting requirements, and flexibility for future needs. Whether structuring a corporate hierarchy or managing a multi-tiered project framework, organizations should prioritize logical grouping, clear role-based access, and seamless integration with business processes. By following these principles, companies can enhance operational efficiency, improve data governance, and drive better decision-making.