While in an informal setting you can have a process with multiple starting points it is not a best practice to have such models.  A process generally has a definite starting point.  It would help to have your example in order to better help you out but here are a couple of thoughts:

• If you process tasks do not vary but what vary are the events that can trigger the process then you would simply model to show that the process can be started by any one of a list of events.  If you are using BPMN (Business Process Modeling Notation) (see: bpmn.org) to model your process then your start even would look like a single circle with a start inside which means complex/multiple start event.
• If you do have variation in the processes then there must be a "reason" which determines one path vs. another.  For example, if you are modeling a manual process which a human must follow then, before the human even begins the process he/she would have to make a deterministic decision as to which "start" to use.  Again that's not a good way to model it so one alternate option is to have only one start but the first task after start would be a decision (XOR) with the 8 options available to the user.
• But there probably is an even better way to model your process.  My gut feeling tells me that you probably have 8 distinct processes which have some steps in common so you should model these using 8 distinct process flows each with its own start event.  For example: let's say that you are modeling the process for requesting a catalog from a widget distributor.  The customer could order the catalog in a number of ways such as: send an e-mail to the company, send a letter to the company, use the company's website, or call customer service.  These would be 4 distinct processes with many steps in common (the steps used by the widget company to print the label, pack the catalog, and ship to the customer).  So what you can do in this case is to model a 5th process (in BPMN it would be modeled as a sub-process) which would only contain the fulfillment steps.  This "ship catalog" sub-process would simply be the last step of each of the other 4 processes.  This way, your model makes it clear that you have 4 processes yet it also makes it clear that there is a common/reusable component.
• As Craig mentioned, if you were to model this using use cases, you would have 4 use cases one for each of the 4 distinct processes and you would have a 5th use case which would be an include to the other 4.  Another way to model this would be to have one abstract use case called "order catalog" and have the other 4 use cases "inherit" (via the generalization relationship) the common steps in the abstract use case.

Hope this helps!

- Adrian

I think this scale is quite common when new workflow systems are being implemented.  Business units and teams develop their own local processes and the things breed like rabbits.  Because all the business SMEs deal only with their local activities people lose sight of the fact that there are only really a handful of processes with many variations.

Regardless, you still need to go through documenting them all as a part of the "as is" analysis before going on to design the future proesses for your new system.  This is so all variations (and constrainst and special requirements) can be identified.  Otherwise when you roll out your new workflow system a whole lot of extra-system process workaround are required.

Have fun with them.