An overview of capturing a business process in Windchill?

[mdebower]

Does anyone know of a document showing the overall process to capture a business process in Windchill?   I think I am picking up all the separate pieces, but am not entirely sure how they fit together in the puzzle yet....

Anyone have a good example they can share?

If not, I was thinking of a somewhat generic process like requesting a quote:

1. Engineer creates a purchasing quote request, and sends to Purchasing dept.
2. Purchasing sends RFQ to vendor(s)
3. Vendor(s) sends quote to Purchasing
4. Purchasing loads quote(s) into Windchill.
5. Engineer is notified.

The Windchill Pieces I know about:

• WTDoc type for quote.
• OIR to use the WTDoc type
• Document lifecycle template  (Maybe a generic one for many WTDoc types, maybe a specific one for this type.)
• Workflow Template
• Lifecycle template for the workflow

What am I missing?

-marc

[bsindelar]

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.

[MikeLockwood]

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

[mdebower]

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?

[BrianToussaint]

You tie your LC State to a workflow and then when that state is selected the workflow kicks off.  This shows a workflow for Creation but you can have one kick off for the state when you do a revise on the object that is different.

[bsindelar]

Assuming you want to run a workflow for that particular part and NOT use a Promotion Request or Change Object, then what you do is the following:

• Create the workflow template you would like to use.
• Create the life cycle template for this object.  Make sure it is an "advanced" life cycle type instead of a "basic" type.  This will allow you to associate workflows.
• In the life cycle edit wizard, you need to associate the workflow to kick off with a particular state.  I believe you can configure the workflow to fire off upon exiting or entering any state in that life cycle's template.  Note that once you associate workflows to states, it will always be that way while the life cycle template is configured that way.  You won't be able to ad-hoc select different processes for different WTParts (but you COULD based on other factors, like the context it resides in, for example).

The two key use cases I have seen for this are:

1. Have the workflow kick off when entering the initial life cycle state of the object.  Thus, a newly-created object will immediately kick off a workflow.
2. Have the workflow kick off on a "later" state (usually 2nd state in the template).  This lets the user iterate the object as necessary before using a "set state" or other mechanism to kick off the workflow at the user's request.

Your workflow would most likely drive life cycle state changes too, which may or may not drive different paths in your flow or even different templates altogether.

As Mike brought up too, there are packages and routing functionality that may make more sense to use to communicate with vendors outside of your WC system.  There really are very many ways to accomplish this.

[mdebower]

AHHHHHHH!   This is very frustrating and confusing.   How does anyone learn this stuff?

I was told that you use basic lifecycle types for WTDocuments and CAD Documents etc.., and advanced lifecycles for the workflows that make changes to those objects.  Like a promotion from In Work to Released.  The object isn't using the advanced lifecycle, the promotion is.

Is this correct?   If so, how do I apply that principle to my example?

[MikeLockwood]

i only learned this stuff from playing with it on my laptop for hundreds and hundreds of hours at home.  The courses help with the mechanics but not so much how to "design" with the elements of the system like LC, WF, etc. (which is why consultants are needed in general)

[mdebower]

Mike,  I can appreciate that, and I will get there eventually.   I don't have a budget for this and my boss is wanting results. Oh well...

[bsindelar]

That's what consulting is for .

I'd be happy to give you an assessment for free on how I would see your RFQ processes (and other processes, if applicable) would fit into your Windchill ecosystem.  If you are interested, send me an e-mail and we can discuss further.

[BenLoosli]

Having consultants do the work for you does NOT teach you how the system works. You still have to maintain and enhance the system long after the consultants have cashed their check and moved on.

There needs to be additional traning offered by PTC in how to implement and configure Windchill. Also training classes in basic customization would be a benefit for most system admins.

I cannot use consultants because of the nature of the work we do.  I can sometimes get a training class approved, but that is rare. I have to spend lots of hours reading poor documention and try to piece it together to make it work for us.

So people like Mark and myself end up learning the system, implementing it the way our company wants and are still here to maintain and make future changes.

[mdebower]

Ben, you asked about training in this area a while back, did you ever find anything suitable?

Looking for Workflow/Lifecycle/OIR training

[BenLoosli]

Not really, just consultants saying they could do it without compromising my system security, which the security and IT team would not approve.

There were also offers of one-on-one consulting/mentoring, but I have no budget for that sort of 'training'.

Finding answers through the community only goes so far. I know most of the answers are available in the PTC help but finding it is like looking for a needle in a haystack, at times.

[BuddyHudson]

AMEN on the need for PTC to offer training classes!

[MikeLockwood]

Maybe I'll offer some workshops on this - web sessions.

I'm back at Alcon primarily because even though I'm a good admin, I discovered that I'm a very lousy businessman.   Helped a lot of people w/o getting paid for many of the hours actually spent during the past year consulting on my own (w/many smaller companies, most with but lots of interests and needs but no budget).

Have to figure out some way to actually get a few bucks.

[BobLehman2]

Mike,

Amen to that .  It  Would be cool if there were some place to on this forums to advertise services available and for customers to post needs, without the whole thing becoming dominated by sales folks.  My two cents.  I used to use the exploder to let people know I was looking for work and that worked pretty well.  I do not know if we can do that in the forums or how successful it would be.   I see lots of customers using larger 3rd party IT companies that I think probably provide little value to acquire Windchill talent - consulting or direct.  I think it would be way more valuable to have a direct communication.  If someone is looking for a Windchill expert I would like to think they are lurking in this forum - at least they/we used to lurk on the exploder.   My two cents - worth exactly what you paid for it minus the two cents

--Bob

[mdebower]

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

[LewisLawrence]

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.

[mdebower]

Lewis,

Thanks,  I do have a flowchart, but it probably could use some more detail.  I guess I will be giving the test server a workout soon.

-marc

[LewisLawrence]

I would suggest that your flowchart needs a lot more detail, there is nothing showing where any decisions are being made. Nor is there any provision for re-work/loopback options. Some suggestion to think about would be:
Do you need an approval for requesting a Quotation?
What if you have a situation where the purchasing representative thinks the WTPart needs some enrichment before being suitable for quotation?
What if the vendor asks for some clarification? Who supplies that (Engineering or Purchasing)?
What if plans change while waiting for the quote and you no longer require the order?
What happens after the quotation is loaded? Should there be some approval/acceptance of the order and a green light from Engineering?
If there are multiple quotes who is actually picking the best one?

Incidentally many business systems (MRP/ERP) have some sort of mechanism for this kind of thing, Windchill may not be the best system for actually managing this process. But the logic for how you want the process to function should not be system specific and will work for implementation regardless, good luck.

[ChrisPLM]

Hi Marc

Sorry for late reply. I agree with Lewis, If you aim is to improve/implement a business process which is going to be supported by Windchill first forget about Windchill and create your “swimming lanes” process. If you do not know what it is, check out those images

https://www.google.cz/search?q=swimming+lane+process+flow&espv=2&biw=1214&bih=869&tbm=isch&tbo=u&source=univ&sa=X&ved=0CDoQsARqFQoTCLWQ3ozOo8cCFUZdFAod2iYKOA

You can complete the horizontal lanes with vertical lanes which represent which system you use in case your process flows between systems.

Let us know if you have more questions about such diagrams.

Once you have this done, (first draft/version), this is where you look at your tool (here Windchill and see what you need to use).

Depending on your overall knowledge of the desired process and Windchill capabilities, you may need to go through a few iterations in developing the implementation plan of the process. I mean by that, you may realize that depending on the tool you use (here Windchill) some of the task in your draft process could be automated.

For instance.  A task is to be completed and someone must be informed that the task is completed. If you do not know that your tool can send automatically email notification, your first draft may include two tasks

Task 1: Complete such work

Task 2: Send email to X to inform about completion.

When you come to see how you implement, you realize you can improve your draft process by removing Task 2 as task 2 will be done automatically by the system. Of course it must still be defined and you may want to use colour coding in your process chart to define what is done automatically by the system and what has to be done by the user.

This is during, what I call the iteration stage of aligning process and tool that a deep knowledge of the tool is required. I have seen solutions implemented which worked but were not making the most of the tool and therefore were not as efficient as it should be due to the lack of knowledge. (It is like driving a car (manual not automatic) you can travel far in 1^st gear only but you better off knowing there are more gear to drive efficiently)). Here a consultant can help as he or she should have a deep knowledge of the tool.

Once you have this inline (process chart and tool),  your job is not finished.

It will include validating the process by using the tool with your customers (ie your users, maybe not all but your key ones or SME, Subject Matter Expert).

There may well also be some data to be migrated as you want everything under one roof, so your existing data and process will need to be migrated, This can be considered as a sub project.

Hope this helps

[mdebower]

I will get to work on a more detailed flowchart,  I can see now that it is quite deficient.

I was hoping to use a simple example on my test server to learn the windchill side of things, and that was where my focus was.  More as a learning exercise for Windchill than getting the exact process down.

Or is there a better way?

[MikeLockwood]

Don't want to beat a dead horse here, but this is the essence of a major part of getting value from Windchill.  Need to find a way to establish an ongoing process with a lot of involvement from people in a lot of roles in the company.

Alcon has now executed > 50,000 workflow processes, involving ~ 40 different company Roles.  Some of the workflow templates are at iteration 80 or higher (from continuous tweaks).  A few lessons learned:

• Think about what the business needs, then think about Windchill objects to meet those needs, then starting filling in process.  Example: May use a document, and a change request and/or a managed collection and/or a document structure.  May use a document in a Library or maybe in a Project, then use Project Document Routing.  Lots more choices.
• A key decision is what object the workflow process is tied to.  Consider if the workflow process acts one object or possibly many. Think about whether attachment files are needed / would be useful.
• Think about how the users involved get assigned.  Lots of choices: Very manual, prepopulated from team templates, different in each context for same wf template, etc.
• Build query builder reports to be able to monitor how long it takes between each "milestone" of each process.  Can slice and dice by role, person, etc.
• Build verious Home Page table views for user convenience.  On the Tasks table, may want filters for Task Names.  On the Updates table, may want filters for type of object.
• Think about whether the initiating user has a "Tracking" task to be able to cancel or restart, etc.  note: OTB, the Project Approval workflow includes a Track Task in which the user (any user) can skip approvals).  Just need to be aware.
• Think about the state transitions for each object as the process proceeds.  Who can do what at each state?
• Start very simply and capture the normal process where everything goes right. Then and only then, add rework, cancel and other paths used by exception.
• Always make changes on a rehosted non-production Windchill system, then implement in production once tested thoroughly.

Difficult to put this in standard flowcharts and swimlane diagrams but worth at least trying to do so.

[mdebower]

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.

[ChrisPLM]

Oh boy... I did not realize you were still looking for answer to this type of questions.

The quick answer will not help you to broaden your understanding and make yours the new knowledge. As Mike said, there are a lot of learning by doing.

Mike has spent a lot of time, I have also spent a lot of time.

If I may recommend what I think the best approach would be is to actually sit down with a consultant.

The way I have learnt things was by getting standard PTC training (started with an end user training, then business admin training), then get my hand dirty by doing things on test or development server, asking for help (generally the consultant).  When implementing my first process (It was a two steps global approval process to release to manufacturing the 3D drawings and there was a branch for the 2D drawings (different people approved 3D and 2D). Before the project started, my team and I undertook a customer training specifically on Workflow, during that day we went through different approaches and created simple workflow.

Nonetheless for the first release of this 2 step global approval process, the consultant created it, We validated it and the training helped us to understand how it was done and how to improve it. We saved a lot of time and energy. If we had tried to do everything by ourself we would have surely spent many more weeks and surely got our users very frustrated.

Also using workflow is not only about implementing it and telling the users how to start it. You need to know where the object is within the workflow, who received the tasks, when tasks are actionned, completed.  In addition, sometimes something goes wrong, the users click OK but he wanted to click or Not OK, too late, the workflow is already at the next stage. How do you cancel this action ?

When you have a workflow in place you want to map your value stream more efficiently (ie automatically), you want to know how long it takes for a task to be actions (waiting time ie the duration the task exists but no one is doing anything about it, vs the time it takes to actually complete the task.) If you have more than one user who could action the task, you may want to measure the team performance (how quickly a new task is actioned by the team) and then what the individual performance (ie how quickly an individual complete the task).  You may also want to report on how many workflow have been trigger, which ones are late (against pre determined target duration),  etc......

There are many things to consider from a business performance perspective as well as from a system perspective.

I think my best recommendation at that stage is to have a session of a couple of days with a consultant who will take through the business and system considerations.

He will get you started and on the right track.

Note: When my team and I had our custom training, The consultant asked me if another of his customers could join the training as he was not far from my office and had similar needs. I said OK.  I kept in touch with that guy.  He worked for a smaller company and he was supposed to do every by himself, He thought that the training itself would be sufficient. Well,... as you can now imagine, my workflow, which was much more complex than his was ready months before his and with less issues.  OK, it has costed me more in consultancy but the result was worthy.

PS:  PTC Help and eLearning are great to get you started but they focus on the Windchill fonctionalities. While at the moment you are at the business level sort of speak. It is like driving a car, when you know how to drive a car you can drive any car, but if you do not know how to drive a car (understanding the highway codes, that there are gears (even automatic ) etc... and you jump in the car and say where is the accelerator , I need to go to that place,  well let me tell you you won't have me as your passenger lol.

I hope this does not discourage you but you are entering a very efficient area but can end up quite complex and get your users very frustrated if you do not get it right, things can get stuck in workflow !!! (of course before go live, validate everything aspect with the users !!!)

Let us know how you get on and welcome on board !!!!   We all started the same way. ie from knowing nothing

Best regards

[mdebower]

Well, I have been an admin for a while, came from engineering, so am no IT Guru.  This is a new area for me, so am just starting out, and trying not to reinvent the wheel.

Good, Fast, or Cheap:  Pick any two.

Since it has to be good, and the company is way too cheap,  I guess this aint going to be fast!!  

[kpritchard]

Marc,

Answer to 1 & 2:  Use Basic Lifecycle for everything that you do not want to associate a workflow to.  Use Advanced Lifecycle for Workflows to get associated to the Object.

3)  If you use an Advanced Lifecycle on an Object (such as WTPart), then the Workflow starts when the "Phase" (State) is entered.  As an example, if you have a Document Type with an Advanced Lifecycle then the User would probably get a "Submit" Workflow Assignment in their Tasks Table (depends on how things are set up though).  Another way you may do this is to allow the User to Set State from a non Workflow State to a Workflow enabled State.  Many pitfalls here... In my opinion State has much value as an indicator of Level of Maturity (flag of believability) and for permissions, so you may not want to give users the manual capability or add additional States.  If I read between the lines with your use case, you probably want RFQ's run multiple times without making modifications or changing the "LOM".  You could consider sub-typing a Change Object (Problem Report comes to mind as a promising candidate) and attaching your RFQ workflow to a Lifecycle dedicated to that sub-type.

4)  No can do with a Basic Lifecycle, at least not directly.  You can include the Object(s) in a "carrier" object that acts upon the content objects as the container is moved through the container workflow.  Change Objects (Problem Reports, Change Requests, Change Notices and Change Tasks) as well as Promotion Requests all work as carrier objects and their workflows act upon these contents such as changing the State of Promotion Targets (contained data objects).