Today I requested a SIM (special interest meeting) at the conference in Las Vegas to compare notes on how people configure and use change management in Windchill. Don't know assigned day/time yet. If interested, please look for it and attend. Note:I have a few simple diagrams that I'm working on facilitate discussion that I'd be happy to share ahead of time.
We continue to struggle to configure Windchill change management for our needs (as a regulated medical instrument company). It comes down to three primary fundamental areas and we're interested in seeing how others business process compare in these areas, and how you have configured / customized Windchill to accomodate:
a) We require that a change be fully defined, and then approved prior to making the change. The definition of the change needs to include Disposition and Effectivity. A markup / redline / annotation is the central element in this, and needs to be fully handled by the system.
b) In our case, an approvedbusiness document is prerequisite for all changes, and must be referenced on each change. For new product development, this is a PMP (Project Management Plan) and covers all changes thru initial release on the defined product / product lline. After initial release,a CP (Change Plan) is used. By definition, these are one-to-many relationships, Plan to Changes. Windchill accomodates many-to-onefor PR to CR and CR to CN, but this is opposite. Maybe something in ProjectLink would be more appropriate.
c) OTB, Windchill provides a process such that one person (Change Admin) takes action in Windchill after the CRB / CIB meeting instead of having each approver do so via a workflow assignment. It seems that pretty much everyone instead configures the workflow to have each approver do so in Windchill. Foreach category of business purpose for each type of data (e.g. labeling, fabricated part, finished goods, product software, etc., etc)we define which business Roles need to approve changes. This leads to requiring a variable routing for approval on each change, with traceability to the Roles that have approved in theaudit record. The workflow editordoes not easily accomodate this variable routing (essentially a variable CRB for each change).
In general, Windchill Problem Reports, Change Requests, Change Notices, and Change Activities do not accomodate these needs well; we have so far pretty much stuffed a round peg into a square hole many places it seems. Examples: a) We have a sophisticated method to parse a text string in the Comments field of the Change Request to be the Disposion and Effectivity, and have disabled this in the Change Activity. b) We use a sub type of Problem Report as the Change Plan, and link to multiple Change Requests. We have huge workflow templates with lots of conditionals and code that allow for variable routing each time thru. There are many, many other small areas where things are currently very painful.
To date, we have done appr. 11,000 changes in Windchill, so it's not a new thing.We are going to invest considerable time going back to fundamentals on how we can use Windchill change management objects more effectively in the coming months. We'd very much like to havea group of similar companies with similar issues be able to compare notes, ongoing.
Note: Not a request for consulting - thank you
