An overview of capturing a business process in Windchill?

Marc,

You've got the basics pretty much covered as far as the Windchill items needed to actually get a process in place, but there are a few key components to think about.  Here are a few:

• ACLs:  Depending on who needs to see/do what items/actions in what states, this can range from quite simple to very complicated.  You also could tie this in to life cycle states driven by workflows, like a form of promotion request without using the promotion request object.
• Workflows:  You might NOT want to use a workflow on the actual RFQ process document (using your example), but instead use a particular type of Promotion Request as the method.  The PR object would also be searchable and associated to the object, and would allow you the option to process multiple RFQs in a single workflow instance as opposed to forcing one flow per process (but that depends on your goals, of course).
• Workflow/Context Teams:  Would RFQs be created from a particular context in Windchill or could they be created anywhere?  Do the participants in the workflow vary from request to request, or depending on attributes about the request, or what context or product line the RFQ is associated to?  ACLs factor here as well.
• Functionality with Other Windchill Objects:  Do you use Promotion Requests, Change Objects, or WTParts in your WC system?  If so, how will RFQs be associated (if at all) to these types of objects?
• Revision Purpose:  Assuming these RFQs will be WTDocs, who will have the ability to make new revisions of RFQs and how formal will those revision processes be (if new revisions are even necessary)?  How do the life cycle states factor into this?
• Multiple Methods:  The example you mentioned could also be satisfied by elements supplied with the SUMA module to WC, with management of suppliers and their parts as well as approved manufacturer/vendor lists and also a "Part Request" object with it's own workflow - very similar to a RFQ.
• Legacy Data:  Is there a need to bring in past data as a mini-migration for historical purposes?
• Impact of this process on other processes
• Naming/Numbering Strategy

I have worked on many projects involving incorporating business processes within Windchill and have built several strong solutions, fitting the pieces of the puzzle together in the best way.  Feel free to reach out for additional advice, or if you'd like you can send me an e-mail and we could discuss bringing my company's services to your assistance.

Lots of ways to approach this - and this is the "art" of Windchill configurations and part of what makes it rewarding and fun.   I do a lot of this on the side.

For the need identified above, you might consider using for example (just a few possibilities):

- Not using a different type but using a different LC / WF in a specific Library meant only for quote documents.

- Use a Project instead and use Project Document Route (could use OTB or configure a new Routing LC and associated WF.  This has the major advantage of being able to evolve to where you no longer email any attachments, but instead add files to the Project as WTDocuments (possibly a sub type), the vendor picks them up directly, then deposits their quote in the same Project.  All involved can get notified thru Routing WF and/or subscriptions.  Can isolate vendors by different Projects or even by folders within a project.

- Can use a Windchill Package for this, collecting all needed info.  Can make a separate Delivery for each vendor, and Revise and repeat as needed.  Packages also have the opportunity to provide an offline-viewer of published content.  Can choose to include only nuetral files, etc.

- others...

Consider that what you start can be simple but should be able to evolve.  In general though, yes, the fundamental pieces are:

- Type / sub type (main reasons for a different type: attributes, permissions, LC/WF)

- OIR for the type, that specifies LC

- Possibly start WF from the LC for the object directly; alternately, start the WF from an intermediate object (e.g.. a Package)

- Solution may include templates

- Solution may include custom Searches made available to all users

- Solution may include custom query builder reports

Okay, maybe I don't as much as I thought...

For example,   how do you initiate a workflow?   In my example above,  I was envisioning choosing a WTPart, and kicking off the RFQ workflow.  But how?

All this talk of consulting is well and good, but it is neither relevant to the original question, nor very helpful in getting answers.

My recommendation as your starting point would be to ignore Windchill altogether and draw out a logic flowchart for exactly how you want things to process. So that you have every decision point documented with a Yes/No and routing out of that, as well as some words that describe what should be happening in each activity step of the process. No system/Windchill terminology in there at all, just how you need the information to flow and the logic process required to drive that. Meet with Purchasing and Engineering representatives (Expert Users) to agree this logic.

Once this basic design work is done it is much easier to make something work like you actually need using Windchill. In my experience where everyone goes wrong (particularly at first) is launching down a particular branch of Windchill functionality and trying to design their process on the fly with little clear direction of what they really need to achieve or a clear understanding of all the possible eventualities. Invariably this ends up with something that is either ineffective in some way or too complex/cumbersome to be useful.

Unfortunately you have to learn by doing, the experience you need is something you will only get just after you really needed it. You either have to commit to spending the time required to learn on the job, or pay someone with the necessary experience to save you some time. Either way you still need the basic design above which is where I recommend you spend your time, understanding business requirements and establishing a good relationship with users adds the most value.

Lewis Lawrence‌, Mike Lockwood‌, Chris C‌

Thanks for all your help so far, I think I understand the importance of planning the process out before getting it into Windchill. 

What I don't understand is the actual implementation of a process in Windchill.   Does anyone have a simple example to share?  Something I could recreate on my test server as an exercise?

Questions that I have:

1. When do I use a basic lifecycle?
2. When should I use an advanced lifecycle?
3. Can I start manually start a workflow as a user?  If so, how?
4. If I have an object type, like CAD Object that uses a basic lifecycle, how do I create a workflow to act on those objects?

I just want to learn the mechanics of doing this in Windchill.  The PTC help files and eLearning courses and documentation aren't helping.