You probably know that you can create workorder successor/predecessor relations only within change.
You also probably know that with the exception of generic relations (which cannot be used in UI/DB rules) there is the only way to relate two work orders.
You might also probably know that even if HP give us the ability to create "entity reference" type custom fields there are certain limitations, like you cannot create a "service call" field in service calls or "work order" field in work orders.
In fact, if we have the ability to have custom "work order" fields in work order we could create successor/predecessor like relations without the need of the change module.
Well, it can be done. Do you like to live dangerously?
To accomplish that you must alter directly the service desk database. However, you can do this at a test environment (where you don't actually care if "do not touch the database" does not stand) and use ACES export/import to import the created field from the test database to the production database, thus having the ability to use this functionality where HP cannot claim that you altered the DB :)
Creating two "work order" fields like "parent work order" and "child work order" and with some ui/db rules you can have "poor man's change management" with the limitation that a work order can have at most one parent and one child.
This procedure involves for queries, two of them are update queries.
OK, here are the details. Remember to do this ONLY to a test server, this is unsupported by HP and probably gonna hate it :)
1st Step: Create a custom field of "entity reference" type for work orders. I used "change" due to similarity with work orders but you could use organization or another code. Press OK to add this.
After creating this, a new column should be created in 'itsm_wor_cft001'. In my case the name of the column was 'A3$_PARENTWORKORDER_OID'. Write down the name of this field.
now execute these queries and keep the results
our_column_col_oid -> select col_oid from ifc_columns where col_name='A3$_PARENTWORKORDER_OID'
our_atr_oid -> select atr.atr_oid from ifc_attributes atr inner join ifc_columns col on atr.atr_oid=col.col_atr_oid where col.col_oid=our_column_col_oid
Now its time to find the ent_oid of "Change" and "Work Orders" which will be used in the update queries. Write down the results of these queries
change_ent_oid -> select ent_oid from ifc_entities where ent_name='Change'
workorder_ent_oid-> select ent_oid from ifc_entities where ent_name='Work Order'
Now stop the application server. With application server stopped run these queries:
update ifc_columns set rel_col_to= where rel_col_to= and col_oid=
update ifc_attributes set atr_entity_to_oid= where atr_entity_to_oid= and atr_oid=
As you understand you must substitute the name in the <> with the ones you wrote down on the previous queries.
Start the application server. Open form designer and drag your custom field to a form. Open an item with this form (new or existing) and there you will be able to insert a parent work order :)
Do the same for child work order.
Now the good thing is that you can use these fields in UI/DB rules and of course in templates. For example you can create a UI rule to limit the value range of "Status" if parent work order is not empty and it's status is not closed and a custom boolean of "do not close child if not closed" is true!
Well, you can use your imagination.
Cool thing is that you can use the same technique to create custom service call fields to service call, custom incident fields to incidents etc etc!
Well, i have setup some ui/db rules and some templates in the test system and this procedure works like a charm!
We have change management like abilities within service calls, incidents, problems and workorders themselves! Work orders can start in predefined in templates order and there is no need to be linked to a change!
However I remind again that the functionality provided by this trick is "predecessor/successor" *LIKE* not "predecessor/successor" exact!
This works ONLY on 4.5 SP19 or later. It won't work on v5 since v5 doesn't have the ability of creation new custom fields. And even if they added the capability to a SP on 5.1 (which I seriously doubt) it also wouldn't work because v5 has a different DB schema.