This is possibly a matter of terminology.

Have a look at the Yourdon reference you were referred to below.  Also take a first pass at a level 0 and level 1 context diagram.  You don't need much in the way of process analysis to get this done.

A top level context diagram shows you much of what is important - what significant inputs and outputs are there to and from the organisation and key business units.

Another thing you can workshop before getting stuck into process modelling is the business model.  I quite like Alex Osterwalder's framework for workshopping this.  (Google him or check out slideshare.)

Adrian' advice to take an integrated approach to interviewing SMEs is very valid.  Work as a team. 

The BAs should not be shielded from frontline users and SMEs by the BPAs.  This is a certain path to requirements failure.  (On that topic take a look at Nick Malik's Inside Architecture blog this week.)

And lastly - don't make the mistake of putting the process modelling project ahead of the system development.  Apart from the analysis reasons above there are two major risks associated with doing this;

1. You essntially have 2 projects running concurrently and are putting your system development into a dependency on a successful process project.  Whatever you do - avoid depending on in-train projects.  They always result in train wrecks.

2. The IT system is typically like an iceberg - and the process dependent parts are the bits above water.  Most process stuff is only a part of a full blown enterprise system.  There are plenty of other features that can be worked on while the processes get ironed out.

All you need forthe systems is a 'process on a page' view which you can get form some of the artefacts I described earlier.

Sincerely hope this helps.