Posts Tagged ‘ItemType’

Using PLM Change Control Workflows to Manage the PLM System’s Own Definition in Aras

June 4, 2012

MarcL: The PLM solution should be able to have workflows managed by the system itself as objects that can be placed under change control and can be assigned versions.

Peter Schroer:

Aras Innovator’s Workflow Maps (e.g. Aras term for the business process definition) are Item Types (e.g. business object) in the PLM system.

As such they have permissions, versions, and can be controlled by their own change approval workflow.   In this way, the PLM is used to control its own internal system definition of processes.

This style of change management for the PLM system can also be applied to Forms, Lifecycles, business rules, etc.

NOTE:  while Aras can be used to control its own system/process definition,  and changes can be made in real-time by real-people,  this is not the recommended best practice after the system Go-Live to production.

At one point in the evolution of a PLM deployment the end-users are thrilled that PLM change requests (add a field, change the form, etc) are made in real-time as fast as they ask for the changes.

Later though, if the form layout continues to change in real-time when they are using the system,  the video arcade effect of the moving buttons will affect productivity.

The recommended best practice after Go-Live is to instantiate three instances of the PLM solution;  Development, Test, and Production.

All model changes made using the Solution Studio drag-and-drop design tools, can be exported as XML Packages, and easily moved between Aras Innovator instances (this is also how we synchronize federated networks of separate Aras Innovator instances).

Normal practice is to move multiple Packages from development to Test for integration testing, and then at defined intervals, move the tested Packages into the Production environment for rollout.

We provide training on how to tailor, customize and manage Aras Innovator’s workflows and business items.

For additional information see ‘PLM Solution Tailoring and Customization by End Users in Aras’ and ‘Electronic Signatures, Workflows, Lifecycles and Security in Aras’.

Advertisements

Item Tracking, Status and Exception Reporting in Aras

May 21, 2012

MarcL: PLM solutions need to provide tracking, status, and exception reports and the reports should be able to be tailored to specific needs such as selected release level and specific attributes. There should also be the ability for reporting by exceptions, in particular on missing or incomplete objects belonging to a predefined set.

Peter Schroer:

Aras Innovator out-of-the-box includes default settings and tools for the Administrator to configure the level of history and audit trails that will be tracked, by Item Type.

For example a Part may have history of every transaction (view, update, create, etc) and audit trails supporting complete traceability,    while a Product Release Plan only has tracking of edit events.

These rules can be changed and updated at any time.

The Aras Innovator platform also provides a set of standard events for the solution developer to hang business rules (tests for exceptions, etc).

The most common approach is to link the exception testing to Lifecycle State changes,  and the exception testing can result in either just a message to the user, or a forced roll-back of the lifecycle status change until the exceptions are resolved.

This is all standard OOTB functionality in Aras Innovator.

We provide training on how to set-up, administer and customize these capabilities as well.

For additional information on these capabilities see the previous post ‘Business Intelligence, Custom Reports and Secure Reporting in Aras’ or check out the Posts Tagged ‘Reporting’ and ‘Administration’.

BPM / Workflow Escalation in Aras

May 8, 2012

MarcL: PLM solutions must be able to define escalation rules for workflow notification so that when a notification has not been responded to for a specific period of time, another pre-define user or group is notified.

Peter Schroer:

The Aras Innovator workflow web service supports a variety of escalation structures out of the box, and the escalation structure of a specific workflow process can depend on the item’s classification or other business rule.

The Aras Innovator workflow at the platform level has 2 levels of Escalation as a standard out-of-the-box Web service.

The first level is an escalation at the Activity level (there is an administrator defined escalation identity for each Activity).

The second level escalation is a notification of the process owner when the Activity fails to be completed on time by the first level escalation.

Additional escalation rules can be configured as well.

We provide training on how to implement, customize, and optimize these for self-sufficient operation of your PLM environment.

For additional information on workflow see the posts ‘BPM / Workflow Voting and Promotion Authorization in Aras’ and ‘Lifecycle, Workflow and Other Types of Process Management in Aras’ or check out the Posts Tagged ‘Workflow’.

Versioning of Items & Files in Aras

April 19, 2012

MarcL: PLM solutions at a minimum should provide Version tracking for the most recent released revision and previous revs with date/time stamps. A new version should be based on an update of the PLM database which should occur whenever an item is checked into the PLM solution, and also should occur when the user initiates an update, but typically does not need to coincide with the user saving changes on their local disk.

Peter Schroer:

Aras internally used the terms Major_Rev, Minor_Rev and Generation.

The “Version” and “Revision” are just labels that do not impact the underlying web services behaviors.  In our experience, everyone calls it something different;  it’s the defined behaviors that are important. 

CMII revision behaviors are supported by the standard out-of-the-box Aras configuration.

All edits, whether work-in-process or formal releases are tracked in Aras Innovator (these are the Generations), and your company decides which of the increments are exposed to which users.

Once a File is checked-out,   a Generation is reserved,    and that user can make multiple edits which are saved to disk without bumping the Generation.

This Generation behavior is configurable and for security intensive scenarios can be set-up to log every save, but the default settings allow local saves that are not recognized by the PLM system.

For more info on this see posts like ‘Version & Revision Release Levels in Aras’ and ‘Data Relationships and Fixed / Float Rules in Aras

Or check out the Posts Tagged ‘Revision & Version’.

Version & Revision Release Levels in Aras

April 17, 2012

MarcL: PLM solutions must provide support for user-defined multiple release and revision levels, and should be able to assign default release levels based on object types or other attributes, as well as, be able to reset release levels for specific items at check-in by users with appropriate assigned authority.

Peter Schroer:

The out-of-the-box Aras Innovator data model has 3 levels of versioning control on all business items (Major, Minor, and Generation).

Your company can use the three levels to implement just Revisions, or      Revisions + Versions, or    Versions + Revisions + Baselines,    etc.

The exact terminology belongs to you / your company, and you can make it whatever you need. The underlying platform handles the 3 revision levels, and you can use the OOTB setup or configure them however you need.

Our out-of-the-box installation implements the standard CMII processes as defined by the Institute of Configuration Management.

Out-of-the-box Aras supports the ability to assign default release levels based on object types or other attributes as well as the ability to reset release levels for specific items at check-in, and this is easily extended or modified over time as needed.

Each ItemType is linked to a defined Revision sequence (and these can be different for different ItemTypes),  and the standard methodology would be to use the Lifecycle engine to trigger revision changes.  This behavior is driven by CMII standards in the OOTB Aras solutions, and can be easily tailored as needed or applied to add-on solutions or custom solutions that your company develops.

You can quickly enable special scenarios for manual revision changes, over-rides, executive decisions, and other behaviors which occur in the real world – or any combination of these.

Learning how to configure the revisioning rules is covered in the Aras introductory class “Configuring Solutions”, and we provide training on how to customize Aras Innovator for self-sufficient operation to satisfy your company’s on-going requirements.


%d bloggers like this: