We're interested in this and would like to participate in discussions.
Along this line, we're currently putting quite a bit of effort into developing configurations and a process in our production Windchill system for using Windchill change management for management of changes to the Windchill system itself.
On using change management for this, our approach is still in development, but consists of primarily:
- Separate object types for Problem Report (PR), Change Request (CR), Change Notice (CN), Change Task (CT), each with appropriate attributes
- Separate Library for just these changes objects, open only to Admin (except that all users can create PRs against the system here)
- Admin group takes on all change management Roles
- Where change management for product data focuses on revising and editing documents and parts on CTs with controlled state change, change management of the system instead focuses on a series of assignments on the CN, with the CTs used only for the documents that need to be Revised and edited for the update; these consist mostly of user best practices & procedures, along with global configuration documents.
- We're using CRs for development work assignments (including for example rehosting various systems), and CN's for deployment to Validation, Training and finally production, with all needed files such as workflow templates, OIR's etc as attachments to the CN (or pointers to code files stored in separate code management system).
- Note: Intent is to have the overall Windchill system configuration labeled as and traceable to the latest implemented CN Number.
Haven't yet started using this for real - would like to learn how others are handling. Happy to share our experiences.
