If you ever want the ultimate in flow charting, check out Six Sigma.
Actually, Six Sigma goes waaaay beyond flowcharting; its a methodology that encompasses a vast amount of knowledge on understanding processes, process flow, and how and why errors accumulate in processes, and how to measure for these errors in order to correct them effectively and efficiently.
Flowcharting (known in Six Sigma as "process mapping"), when done properly, can do much more than map out how something works; it can quickly tell you, visually, whether your process is correct and efficient.
Your first step is to define your problem; you must do this in a concise, logical, and complete (to the best of your knowledge) manner. Every detail of the process to address the problem shouldn't be written down at this stage, but the general idea should be there.
Write it down on paper; think about it, does it seem complete? Does it feel correct?
Once you have done that, work from that description to generate your first process mapping iteration. Use boxes for the processes within the overall process, diamonds for decision/branching, circles for start and end - parallelograms can be used to represent data in and out; be sure to use arrowheads at the end of lines connecting each item to show the direction of flow (never put two arrowheads on the end of the same line; use two separate lines with individual single arrowheads).
At this stage, you should only have a minimum of boxes and branches, because the problem was so generally (but accurately) defined. If you have way more than needed (and this can't be defined; it depends on the problem domain and the skill of the person or group involved in creating the process map - you get better as you practice), or if things are defined incorrectly in some manner, you will be able to see it on the flowchart. A sure sign of a problem is if you have lines all over the place or crossing each other too many times; it is a visual version of "spaghetti code". Indeed, if you flowcharted such a piece of code, you would instantly see the real visualization of the process; it isn't pretty!
Once you have this first iteration concise and clean, look at each box on the diagram. Can they individually be broken down into their own processes? Most likely, they can, if you think about it carefully and logically. Take those areas, and process map them (in the same general manner to the best of your ability and knowledge as you can). You will either want to fuse this detail of the map within the same structure as the first iteration, or you will want to note in the process boxes on that iteration a note for a the detail (ie; see "flowchart_1b"); many programs that allow you to flowchart provide a method whereby you can link from the process box to the flowchart which represents it.
After process mapping, perform the same check again on the map: Is it too complicated? Are there lines crossing? Does it look messy?
Once again, you'll generally be able to spot problems visually. Correct them (if you can) and move on. Sometimes, these problem areas might actually be caused by missing a step, or not thinking the problem domain for that area of the overall problem completely through.
Continue this iterative approach to the problem in order to study the entire domain in detail; the level you ultimately want to try to strive for is something akin to understanding the process to take apart a brick until you reduce it to atoms. This degree of attention to detail isn't always practical or possible, but always try to strive for it.
If you process map a problem domain effectively (especially if it is a process involving human interaction and effort; processing mapping the problem of bug tracking is an interesting area), you will quickly find areas of the problem where people honestly don't know (and don't generally think about) how the process worked, until you ask them and discuss it with them. In many cases, the problem or part of the problem is solved in a "soft" manner; which generally involves a social aspect or something (ie, calling and discussing an issue with somebody) outside hard inputs and outputs - even so, they should be properly process mapped; they are a part of the process.
That leads to the final piece; one that leads more into the meat of Six Sigma: Every process has inputs, and outputs. Know these items for every process in your problem domain. Know and understand how the outputs of one process flows into the inputs of the next. Once you know them, you can then apply numbers to them, as well as devise a process scoring system.
This scoring system (which are almost always customized; though I think there is a Sig Sigma Patterns book for some common problem domains and such) ultimately allows you to see how well a process is working, and how changes to one or more inputs of a system affect the other parts (via propagation and otherwise).
This is just a high-level overview, one in which I probably missed something or got something else wrong; I never studied Six Sigma in any depth, I just worked for a membership organization here in the Phoenix, AZ area as a web developer for their website (which was an amazing project in and of itself, actually). I will gladly defer to anyone's deeper understanding of this topic. It is a very complex system of systems and methodologies, as I noted previously.
Hope this helps someone! 
if you lay out your problem efficiently, starting with a general overview
This evening I was trying to figure out how to get my sketch to go through some steps and I remembered one of my favorite tools: the flowchart.