Sharing CAD data across multiple projects in program management-access control and duplication issues in aras-14.0

PLM Aras Innovator
, , , , , , , ,
1

We’re managing multiple concurrent projects in Aras 14.0 that need to share common CAD components - standard brackets, fasteners, enclosures, etc. The challenge is maintaining data integrity when the same part is used across 5-6 different projects with different release schedules.

Right now each project team tends to copy parts into their project workspace, which creates version management nightmares. We end up with multiple versions of the same bracket design, and when engineering makes an improvement, it doesn’t propagate to all projects using that part.

I’m trying to establish best practices for shared libraries with proper access control so all projects reference the same master parts. But I’m concerned about one project’s changes impacting others unexpectedly. How do you handle cross-project sharing while maintaining both reusability and isolation when needed?

2

We implemented a shared component library structure with three access control tiers. Tier 1 is fully released standard parts - anyone can use, no one can modify without formal ECO. Tier 2 is approved designs that projects can reference but might still evolve - projects must opt-in to version updates. Tier 3 is work-in-progress shared concepts - projects can view but not reference in released designs. This gives us controlled sharing without chaos.

3

Version management is critical for shared libraries. We use Aras major/minor versioning where major versions indicate breaking changes and minor versions are backward-compatible improvements. Projects reference parts with major version lock - they automatically get minor version updates but must explicitly upgrade to new major versions. This balances getting improvements automatically while preventing unexpected breaking changes from impacting project schedules. The version control rules are enforced through relationships and lifecycle workflows.

4

After implementing shared component strategies across multiple program management environments, I can share a comprehensive approach that addresses shared libraries, access control, and version management while maintaining data integrity.

The foundation is establishing a formal Shared Component Library structure in Aras with clear governance. Create a dedicated classification for shared components separate from project-specific parts. This library should have its own lifecycle workflow with stricter release controls than project parts - changes require broader review because impact is wider.

For access control, implement a role-based permission model with these levels:

  1. Library Administrators: Can create, modify, and release shared components. This should be a small central team or component engineering group.

  2. Project Engineers: Can view and reference shared components in their designs. Cannot modify library parts directly. Can submit change requests.

  3. Project Managers: Can view shared components and see which projects are using them. Receive notifications of proposed changes.

  4. Guests/Suppliers: View-only access to specific released versions they’re working with.

The critical aspect is that projects reference shared components rather than copying them. Use Aras relationship properties to track which projects are consuming which parts. This gives you full traceability and impact analysis capability.

For version management, implement a structured approach:

  1. Use major.minor.patch versioning (e.g., 2.3.1)

    • Major: Breaking changes (form, fit, function changes)
    • Minor: Backward-compatible improvements (better materials, cost reduction)
    • Patch: Bug fixes, documentation updates

  2. Projects reference parts with version policies:

    • Lock to specific version: Project gets exactly version 2.3.1, never auto-updates
    • Lock major version: Project gets latest 2.x version automatically
    • Always latest: Project always gets newest version (only for non-critical early-phase projects)

  3. Implement a ‘Where Used’ impact analysis tool that shows all projects using a shared part before any change is released. This should be built into your change workflow.

  4. Create a notification system that alerts project teams when shared parts they’re using have proposed changes. Give them a review period to assess impact.

For data integrity and preventing unexpected impacts, use these safeguards:

  1. Effectivity dating: When a shared part changes, use effectivity dates so projects can plan when to adopt the change based on their build schedules.

  2. Change impact classification: Tag changes as Critical (must adopt), Recommended (should adopt when convenient), or Optional (performance improvement, not required).

  3. Frozen periods: Allow projects to freeze their shared component versions during critical phases (manufacturing ramp, customer delivery). During freeze, they receive notifications of available updates but aren’t forced to adopt them.

  4. Validation workflows: Before releasing a change to a shared component, require validation that the change doesn’t break any project’s design rules or constraints.

Implementation strategy:

Phase 1: Identify and migrate your most commonly copied parts into the shared library. Start with truly standard items like fasteners, brackets, connectors. Establish the governance structure and access controls.

Phase 2: Implement version management policies and train project teams on how to reference shared components with appropriate version locks based on their project phase and risk tolerance.

Phase 3: Build the impact analysis and notification workflows. Every change to a shared component should trigger automatic identification of affected projects and notification to stakeholders.

Phase 4: Establish metrics and continuous improvement. Track reuse rates, version proliferation, change impact, and time savings. Use this data to refine your policies.

Best practices from successful implementations:

  • Maintain a shared component catalog with clear descriptions, usage guidelines, and approval status. Make it easy for engineers to find and use library parts.

  • Implement a change request process where project engineers can request improvements to shared components. The library team evaluates, implements, and manages release to all consuming projects.

  • Use Aras variants or configuration rules for shared components that need project-specific customization. This maintains one master design with managed variations rather than multiple copies.

  • Create shared component design standards that ensure library parts are truly reusable - parameterized, well-documented, with clear interfaces.

  • Establish retirement procedures for obsolete shared components. Mark them as deprecated, prevent new projects from using them, but maintain for projects already using them.

The outcome should be that projects benefit from shared components through faster design, reduced errors, and continuous improvement, while maintaining control over when they adopt changes based on their schedule and risk tolerance. The key is making sharing the easy path through good tools and governance, rather than forcing it through restrictions.