I’m not in position to make statements about all or majority of organizations. Besides it depends much on the process maturity of the organization.

My observations are from BPM/ACM experts community, i.e. professional blogs and conferences.

In our organization, we face a decision about whether to continue to look at work as something very unique to each case that is not even worth discussing in terms of details that might indicate a mixture of routine work and decisions made ad hoc. Vendors have at least made ​​it clear that there is a cooperation between the ad-hoc work and standardized processes, hence providing integration between the tools that they market. Those who primarily advocate the idea that they should live apart is the outsourced management group of the tool support we have for CM. It’s a shame because it is in their very interest to consolidate the differences. I believe the same debate and political standpoints is similar everywhere among organizations and vendors, don’t
you think?

Yet I believe there is a consensus today about cases and processes being two sides of one coin. Nobody needs distinct systems managing cases and processes separately because as you rightfully noted they interact (call) each other. Besides, they tend to mutate to each other: e.g. a certain type of work may be a process in essence yet we may decide to treat it as case for the sake of agility or vise versa: a mature case work may be reshaped into a process. One more argument towards unification is that both cases and processes have task management as a common basement.

So they definitely will evolve and they are in fact already involving. It’s a matter of time and of the fear of cannibalizing their current separate offerings that some vendors may have.

I agree that dynamic processes and predictable processes should be treated differently, but there are so much relationships in between them. They interact with each other.

I’m trying to understand the reasons for organizations not to standardize what should be regarded as routine work. What is not standardized and, by extension, can not be regarded as an object of automation should be such which has exceptional impact on the company’s distinction to be competitive. I mean that there should be good reasons to regard work as impossible to classify as routine just because it has some elements of human presence. I think it’s easy to dismiss the work could be standardized only to parts of it requires a knowledge worker’s input. This leads to missed opportunities that exist to automate work.

Would you say these two aspects of a process has a future to evolve together or should they be treated as different things?

Yes, now you’ve got me right.

Regarding cases, I believe that case and notation are mutually exclusive. Case is a dynamic check list plus associated data.

I must have interpreted your post wrong. My mistake. I thought you were describing a new type of processes as a BPMN process.
Should I read your post as what processes could be expressed with BPMN?
If so, would a Case (a dynamic process) be possible to express with BPMN or are there other notations more suitable for this kind (such as CMMN)?

“Just a process” may mean a lot of very different things depending on the context. For example, manufacturing process or a process in PMBOK sense differ considerably from BPMN process.

Project is not a process but still consitute a non-atomic work to be done. Same is true for cases. I was writing about it here http://mainthing.ru/item/681/