Part Numbers at Preliminary lifecycle phase :Should we delete or leave them alone?

Item Part Numbers at Preliminary status

We have thousands of Prelim IPNs in the database , some were created more than 2 years ago. What do you normally do about them ? If deleted they are lost forever , if left alone , we may want to recycle the Part Numbers by editing their Descriptions and other Fields . Does it make sense to do “housekeeping” and delete them all ? Will retaining them cause system performance issues at all ?
Thanks for your inputs !
Keith

Add Comment
6 Answer(s)

Keith, this is really a personal preference.  There will be no impact to Agile by keeping these but… with good housekeeping practices you may want to explore perhaps a aging limit.  I have a PX that looks for objects that have not been released for 180 days and deletes them.  One other option that I utilize is a generic corporate-wide Dashboard view that will list any items or changes I have created yet not released so I personally can find any relics that may have fallen off my radar.  Oh and one more automation we utilize, for any items or changes that are less than 180 days and the originator is no longer an active account, we transfer those objects to the manager.  Like I said, it is really up to how you feel… hope these help.

Agile Angel Answered on July 15, 2015.
Add Comment

Thanks Patrick ! I have not used any PX at all in our environment ,so was wondering how do we get one just like yours ?
Your other option sounds much like a discipline kind of thing . I would encourage all my users (who have Agile privilege to Create Items) to do just that ,but it would be difficult to enforce this housekeeping rule , or even to monitor if they are actually keeping track .Nevertheless , it’d nice to know the setup for that Dashboard View to ” list any items or changes I have created yet not released so I personally can find any relics that may have fallen off my radar. ” , care to elaborate ?
Best regards,
Keith
July 16th/2015/SGT 10:19am

Agile User Answered on July 16, 2015.
Add Comment

Sure Keith,

I am not a technical guy so I would start by looking through the listing on the following page for a PX that may be helpful;

http://www.oracle.com/technetwork/indexes/samplecode/agileplm-sample-520945.html

The Agile Dashboard is a very personal tool that can place data at a user’s fingertip or at least as the landing page each time they log in.  Since roughly 80% of the user community simply consumes data in Agile and does not participate in the change process it is very critical to get data into their hands as quickly as possible and I find the Dashboards are a great tool for this.  You can place charts (internal or external) as well as data tables (searches) results on the Dashbaord.  

The Dashbaord itself is constructed of widgets and I find that no more than 3 high and wide is perfect.  To access Dashboards in the Admin GUI simply navigate to Settings>System Settings>Dashboard Management.  You will find that you will already have some default Dashboards.  Personally I design each Dashboard view with a group in mind.  For example, my document control group would need to see any change that have been submitted, change in progress for more than 7 days, etc… so I have made a Dashbaord for them with the widgets specific to their needs.

On a corporate-wide level I have created a very generic Dashbaord that shows any documents I have created and not released;

  Page Two.Create User In   $USER   AND  
  Title Block.Rev Release Date Is Null          

Additionally the same logic but for parts.
Another for changes I have created yet not released;

  Cover Page.Originator In   $USER   AND  
  Cover Page.Status In   $STATUSTYPE.HOLD;$STATUSTYPE.PENDING;$STATUSTYPE.REVIEW;$STATUSTYPE.SUBMIT;$UNASSIGNED      

And one more for change I have yet to review that require my attention;

[ Workflow.Approver Contains   $USER   AND  
  Workflow.Workflow Status Equal To   $CURRENTSTATUS   AND  
  Workflow.Approver Action Equal To   Awaiting Approval ]    

I would start by going into your test system and start playing around with the Dashboards…. I learned these in a very organic manner by experiencing and then rolling out as my understanding increased.

Once you build the views you will need to assign then to users and to do that navigate to Settings>User Settings>Privileges>Dashbaord Tab View and create the privilege and assign it to role… login and take a look!  Additionally you can set the view as your default landing page by going into the user account and, under the Preferences tab under the heading Display Preferences, set the Preferred Start Page to the Dashboard view.

Hope this helps!  Kinda a crash course in Dashbaords.

Agile Angel Answered on July 16, 2015.
Add Comment

One more point that I didn’t touch on Keith.  You say you have NOT installed any PX’ in your environment.  One thing you must be aware of is that once you start installing the PX’ you must be conscious of these customizations any time you are looking to upgrade the Agile app.  Need to include these in the test cycles…. they tend to make upgrades ‘funner’.

Agile Angel Answered on July 17, 2015.
Add Comment

Hi Patrick,
Many thanks for your article on Dashboard – I will need to try it for myself and then recommend to my users community at Allied Telesis worldwide . I took a quick look also at the link for the sample PX ,and may test it out on my Dev server .
Thanks heaps !
Best regards,
Keith

Agile User Answered on July 20, 2015.
Add Comment

Hi Keith,

I think it’s a good approach to find out unused items and soft-delete them, if not delete permanently. 

You can verify if the items are not having any related objects such as MPNs / Pending Changes /Where Used Item / Cancelled Change and are existing in system for say 1 /2 years. Then you can de-link these items from the dependencies and delete them. 

Regards,
Arif

Agile Angel Answered on August 1, 2016.
Add Comment

Your Answer

By posting your answer, you agree to the privacy policy and terms of service.