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:
The Windchill Pieces I know about:
What am I missing?
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:
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.
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?
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.
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:
The two key use cases I have seen for this are:
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.
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?
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)
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.
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.
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.
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.
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
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.
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.
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
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 1st 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
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?
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:
Difficult to put this in standard flowcharts and swimlane diagrams but worth at least trying to do so.
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:
I just want to learn the mechanics of doing this in Windchill. The PTC help files and eLearning courses and documentation aren't helping.
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
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!!
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).