cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Community Tip - You can change your system assigned username to something more personal in your community settings. X

Fixing historical document malpractice and legacy data

icelynnin
10-Marble

Fixing historical document malpractice and legacy data

Consider the following hypothetical: you have a department who have been working in their own library area for many years but have always had a very poorly configured library environment, some basic policy rules set up for manager (full control) vs non manager (Read access) and one custom wtdocument subtype.

 

You have recently noticed that the worst possible practice has then been historically followed for document management in this area:

  • Creating new documents representing new Issues (noting the issue in the name)
  • Setting old issues of documents to the 'Canceled' state
    • non-managers, guests only have visibility of Released wtobjects
  • not always using the designated wtdocument subtype (using basic WTDocument at random times)
    • this is due to Full Control for WTObject in all states rather than any sensible policy rules
  • default wtdocument numbering has been used, therefore using up many numbers in a meaningless manner. The department also has an offline autonumber system used to determine next in sequence manually, to be put into the document name and thus lookup of document and the doc numbers are considered pointless.

Obviously you would want to modernise the processes but clearly a debt of historical data to be dealt with.

 

I wonder if anyone has any advice or best practice on how to handle such a data cleanup: reassigning WTDoc subtype, merging multiple WTDocs (folding docs into versions of the same doc under a WTDocMaster), renumbering etc.
I appreciate this can all be done using SQL (such as PTC provided script for subtype reassignment), scripts would need authoring and thoroughly testing- but merging wtdocs seems extreme.

I think the only realistic approach currently is to leave legacy data as is and transform their processes and new data to follow Windchill intent, and introduce correct training and instructions.

Then, a longer term task to consolidate the data manually and permanently retire the old docs (never deleting!).

Hopefully a few of you have relevant 'war stories' or cases about your own systems and internal clients, I thought it might be worthwhile to hear how these kinds of projects have been done generally and how successful they were.

1 REPLY 1

Hi @icelynnin 

It is always pain to correct wrong data based on very bad process 😄 

generally you need to plan plan plan and test test test

 

First I would start with creating a visualization schema of the existing data.

How they are stored what information they keep and the main point what is a goal. 

 

Then create a goal visualization schema and try to find a way how to transform old data to new schema,

This is a point where you would try to find a way how to do so.

Sometimes you find a wrong way and you go step back but you can find that something could not be done, and you need to find another solution. 

 

Very useful thing is if you have a developer who can customize Windchill because he can help you to automate many work.

 

I have experience with some retype changes based on a attributes that can be done just by SQL or customization. Change revision schema on existing objects, Change ACL rules based on some xls input. 

I add that we have a customer who realized that it is cheaper to install brand new system and import data manually 😄 and he's done it.

 

PetrH

 

Top Tags