Observations that lead to a delay in project timeline

A few observations in our implementation of 6x that have lead to some delays:

• Need to allocate a lot of time in the conversion of data from an old system to Maximo 6.  We identified many items in our initial tests of the data load that made us realize we needed more time, and we pushed back.
• We invited users in for training, and they had not had very much hands on with the system as it was being developed.  This caused some concern from the users, as they identified areas that required further design work and we were past that point in the timeline.  We had to push out.  
• A key learning for us is to include a BETA Testing period into the timeline.  Get the users in the system as soon as it looks somewhat customized and has relevant data.   This pushes data conversion up earlier in the overall project plan too.
• When users are in involved in BETA, we can have more time to design features that are "must have" from the user stand point and were not identified in the requirements documentation phase.  I don't know about you, but I'm not perfect and we missed some things during the requirements phase.

Susan Leys

Will Wright here,

This may not be the best way to migrate data but it might help.

We are in progress of Max 621 configuration with data migration of Locations, Assets, JobPlan, JobTask etc.

No migration of Legacy Workorder, Wostatus, Labtrans etc.

We plan to maintain our old 5.1 system as read only for Legacy data.

Overall experience to data migration has been for the most part not going as easy as one might expect.

Using MS Acess and generating load tables for appendment so far have been the easiest way here.

Using Toad Expert for Oracle it actually becomes an easier process.

For Assets:

1. Back up the database!
2. Establish the next value =1 of the existing ASSETUID and ASSETID   apply the new value at the top of the load table and sequence to the last row
3. Drop any unique Asset Indexes (should be two of them, ASSET_NDX,  ASSET_NDX12) Commit
4. Drop ASSETIDSEQ and ASSETSEQ, commit   Recreate the sequences with the next value at the last row the Asset load table in our case the sequence numbers were identical
5. Append the new rows to the database. (check it first for any dup rows)
6. Recreate the dropped Indexes, commit both times.
7. For testing, Go back in to Maximo Appllications, select on inserted record and add something to the description attribute and save it
8. if that works insert a new asset with the field requirements and save it,  if good you are good to go to workorder and test it all the way through.

Back up your database each time the front end applications testing is sucessful!

The process is the same for the Assetancestor table as well and the inserted row count must match what was appended to Asset

The indexes are different and the sequences are of different last values.

The Sequences are different and some tables have two or more sequences to work with

Again the process worked out for locations, Locoper, Lochierarchy, Locancestor  (Each of these tables have one sequence)

All 4 tables must be complete and their respective sequences and  unique indexes put back in.

Person Table insert using sql query.

Here is a sample for inserting rows to the Person Table. Oracle 10.2.0.2 Database

of course there are other attributes to the person table just declare them and include the values in order.

INSERT

personuid

statusdate

personseq

COMMIT

Regards,

  -Will Wright

Previously Susan Leys wrote:

A few observations in our implementation of 6x that have lead to some delays:

• Need to allocate a lot of time in the conversion of data from an old system to Maximo 6.  We identified many items in our initial tests of the data load that made us realize we needed more time, and we pushed back.
• We invited users in for training, and they had not had very much hands on with the system as it was being developed.  This caused some concern from the users, as they identified areas that required further design work and we were past that point in the timeline.  We had to push out.  
• A key learning for us is to include a BETA Testing period into the timeline.  Get the users in the system as soon as it looks somewhat customized and has relevant data.   This pushes data conversion up earlier in the overall project plan too.
• When users are in involved in BETA, we can have more time to design features that are "must have" from the user stand point and were not identified in the requirements documentation phase.  I don't know about you, but I'm not perfect and we missed some things during the requirements phase.

 

Susan Leys