Avoid describing processes in “how” trees…
There are two ways to answer to a “how” question. The first is to describe one particular solution process to reply to the question (e.g. to the question “how to go from NYC to London?”, reply: first, choose an airline; second, buy a ticket; third, go to the airport; etc.). The second is to describe the various alternatives in which one can answer the question (e.g. “by plane, by helicopter, by balloon, by boat, etc.).
“How” trees don’t describe processes, instead they spell out the various ways to answer to your key question, organizing these solutions in a MECE way.
You’ll probably have to force yourself to use “how” trees that way. In my experience, we have a tendency to describe processes and it takes a conscious effort to, instead, describe the various ways to reach a same goal. So get prepared for some hard work, but remember that this is where the big pay-off is: by forcing yourself to consider various solutions, you have to be innovative.
… but leverage them in “why” trees
On the other hand, “why” trees can benefit from thinking in terms of processes and their steps. Since your problem occurs because at least one of its part doesn’t function properly, all you have to do is to break your process in MECE steps before testing each step.
For instance, suppose that you want to understand why parts that you order don’t come on time. Map out the process as a collection of successive, MECE steps and these will be the structure of your issue tree. Of course, you can then refine each of these steps, mapping out their respective components into further detail (the six sigma methodology suggests at least five layers; that sounds like a good minimum in most situations).