Here's some background:
A "Process" is a "Set of interrelated or interacting activities, which transforms inputs into outputs". (ISO 9000)
Time is involved. A Process is not something that happens instantaneously, and a Process is not atomic; it can be broken down into Activities. String those Activities together to accomplish an objective, and you have a Process.
Some Processes are highly structured (like processing a Student Loan), other Processes are very un-structured (like writing a blog entry).
Managed Processes are highly structured: The transitions from one Activity to another are automated (by software). Whenever any Activity completes, pre-defined rules (the Process Definition) are used to determine the next Activities to perform.
If all of the Activities in a Process can be performed by one Participant, then the Process is probably not a Business Process. Business always involves interactions between multiple parties (like a buyer and a seller). Prior to computers, Business interactions were always between people... but today the participants in a Business Process include both people and automated systems.
Whenever any Activity completes, pre-defined rules (the Process Definition determines transitions) are used to determine the next Activities to perform and who should perform them (the Routing Logic determines the Participant).
If none of the Activities in a Managed Process require Human input, then the Process is Fully-Automated... Business Processes are seldom Fully-Automated.
So here's how to spot a Managed Business Process...
If a Process has multiple Participants, at least one (usually more than one) of the Participants is Human, and the transitions between the Activities are controlled by an automated system, then it's a Managed Business Process.
A huge percentage of the Software that we write is intended to implement some aspect of a Managed Business Process... but often the Programmer is not fully aware of the Process as a whole.
For example: A Programmer may be engaged to develop a web-based application that helps a user prepare and submit a Student Loan Application. The Programmer must be aware of the steps that are necessary to prepare and submit the application, but they are often only vaguely aware of the steps that take place after the application has been submitted (the actual processing of the application).
In some respects, letting Programmers focus on a single Activity can be a good thing: If the Process has been properly defined, and the Interface between the Activity and the Process has been correctly defined (what information flows into the Activity, what information flows out of the Activity) then the Programmer will probably do a pretty good job.
The down side of focusing on Activities is that it encourages Programmers to view their projects as Integration Efforts: First they develop an Activity, then they figure out how to connect it to "the other" Activities. The end result is usually snippets of code that glue the Activities together rather than a cohesive Process Definition.
The "Activities First" approach to building an MBP is a lot like Managing by Committee rather than having a single Manager... If the Process needs to change in the future, you'll have to deal with all the integration points rather than a single entity.
The answer is, of course, BPM... but you already knew that I was going to say that ;-)
With BPM, the Process Definition comes first and the Integration between Activities is pre-defined (some might say constrained) by the underlying Process Framework. The "Manager" of the MBP is a distinct entity... Give the Manager the Definition of your Process and voilla!... Your BP is now an MBP ;-)