Richard said:

"The main area that I am interested in is linking the organisational chart, to the job maps and department maps and then linking the processes and being able to link between them."

This is how Business Analysis was attempted back in the 60's.   Patitioning a system by organizational considerations is classic forced, artifical partitioning - otherwise known as "sledge hammer partitioning".   

Kimbo is right.   The result, unless you are dealing with simple systems, is going to be a rats nest of interfaces between the organizational-based partitions.

This swim-lane approach is  one of the reasons (another being esposuing that all diagramming can be done based on sequential techniques) that BPMN is so misleading

Tony

 I almost forgot, one last item is a linear list of requirements that can be used as a checklist. For this use an RML Requirements Mapping Matrix. The RMM lists all the process steps in a spreadsheet form and then allows you to list the requirements that map to each process step. You then map business rules to the requirements.

The value of this method is that users are very good at thinking about process flows to make them complete because they only have to think about what happened before and what happens next. The number of functional requirements need to enable an L3 process step is usually quite small, typically less than 4. This means that as the users think about each step they only have to manage thinking about a few requirements at a time. 

Finally when your vendor comes in, you can use the KPI Model to ask questions like

1) Show us how the software would enable us to perform the following process

2) Since the process is different to the way we do it now, prove to us that the volume and quality level that we have today is supported by the system

Where software selection usually goes wrong is that people generate a list of features, but they dont consider exactly how they will access those features and in what order. Organizing the features against the process flow dramatically helps to organize the process and allows you to see whether the software can actually be used by the users to hit their metrics.]

 BPMN is useful but it simply isnt enough to model a system. Over the last 20 years people have come up with many different aspects of modeling, RML brings many of them together under one roof. How does BPMN help you to model how the business views data objects, the rules associated with fields, or the interfaces between systems? How does BPMN help you to model user interfaces or even business objectives.

Before you encourage people to stay away from RML, I encourage you to actually read about RML to understand the models. We certainly dont sell RML, we created it to fulfill a huge hole in the analysis body of knowledge. Analysts are constantly trying to use a single model to model requirements. Whether that is use cases, data flow diagrams, process flows etc. a single model is simply not sufficient. Im not sure how you can argue against that, but I would certainly be open to discuss it.