Which comes first: the use case or the process map?

Use case, user story, whatever, the requirements specification always comes first. Doesn't mean the process map can't be elaborated simultaneously, but the "what" always comes before the "how."

Now, I'm going to watch the semantic argument on the process map also being part of the "what." My opinion, it's more the "when, who and where."

Use Case always has to come first. And this needs to be revised a few times with stake holders before any process mapping starts.

Without getting into a semantics game about what constitutes a process map or how that is exactly related to a use case: in our experience, defining the process, clarifying the use cases, and automating the process all happen together in an iterative cycle. If you try to "waterfall" the whole thing—as large corporations are wont to do—then you can expect your effort to shatter on the rocks below.

I guess the question is, do we mean a process map reflecting on the business process or the underlaying automated processes? Our method is to start with the end-to-end (business) process map. Then, depending on the goals and requirements, start with use-cases that are input for work/automated processes.

I found greater success with having a high level Use Case(or user story) first. One might ask what is the definition of high level is but I would leave that to another reponse. Then I see process maps coming into play. This sets the context to evolve and depending on the methodology and approach there could be deeper dives into use case and the process maps and/or depending on the technology, there could be straight development and walk thrus for processes ready to be imbedded in a tech platform (vs. being in the strategic stage of business design and reengineering). The challenge is how to bridge the business/user community with the technology during the elicitation and elaboration of requirements. There are visual folks as well as folks who prefer written forms of requirements. The key is how to get everybody started and on the same page. What comes first is setting context to engage the relevant folks then comes the balancing act of how much documentation one does vs. buidling the solution to achieve faster to market.

Given that build can now take place in the process map with in built adaptability it is possible to build first cut in hours in front of users! You do not need to have a final spec as users give feedback new ideas once they see their processes coming to life. However most situations will have a "discovery" phase before hitting the graphical build tool.

Definitely, usecase holds a upper-hand when compared with process maps. Process Maps, help a lot in getting a visual representation and reinforcement of a the long listed story-board as a simple flow diagram with swim-lanes and roles, easy to understand and interpret. Having said that, without a detailed story-line or usecase it all becomes null and void.
To cite a blunt example:
If the End Product I need is a "Shirt"
It is very important to have a detailed requirement and usecase defined :
- What is the Color of the Shirt?
- Full sleeve or half sleeve?
- What are the Measurement Details?
- What is the Collar design?
- How many pockets are required ?
- ... many more
Now, based on the detailed story-board, the process can be crafted by the tailor(or the Process Designer),
- How to cut the piece of cloth and how best it can be chopped for better reuse and less wastage
- How best it can be designed to give a better look and feel
- How the task can be split among the tailor staff, for stitching individual pieces and finally putting it together.
So, in a nutshell, we cannot cut a piece of cloth without having a detailed spec of the requirement!!