I want to shortly explain the context of my approach to Business Process and Choreography Modeling Coaching. My guiding philosophy is a full cycle coaching approach. That means, that not only the creation of choreography models is the goal, but the role of them within the context of the preceding and succeeding steps. I intend to explain this in more detail in Webinars and Seminars in the future.

Model Business Process

First of all the Business Process itself is modeled. The focus of this activity is to identify the steps that need to be performed to reach the goal and their dependency. This is done irrespective of the participants, which are not completely clear at this point in time.

Break into Participants

This is a design decision. Often Participants are companies of the business world. Still it is a design decision how fine or coarse granular they are designed and which part of the process is executed in which participant. For example it is possible to define different departments within a company as one or many participants.

Model Choreography

Now the interaction between participants can be modeled by means of the choreography model. This is a top-down approach. Therefore it defines the frame of subsequent detailed process modeling within the participants.

Model Public Processes / Services of Participants

As a next step the public processes and services of the participants can be modeled. It is decisive to model which services which participant exposes and which constraints exist between the service operations (e.g. an order needs to be confirmed, before it can be delivered).

If a complete system is designed from scratch, the public process models and the services are designed as To-Be processes and services. But in most instances the participants will at least in part already exist. Therefore As-Is models will be created and must be aligned with the To-Be model. This is the most challenging part of all. Because if the public process of a participant cannot be freely designed, because the cost to change it is too high, then the choreography must be changed, which in turn means, that the other participant may need to change. This is the most challenging negotiation in the design process.

Derive Business Objects

Before an implementation can start, Business Objects, which implement the behavior of the participants, need to be derived. The behavior of the Business Objects needs to be made consistent with the public behavior of the participant.

In the end the public behavior of the participant will be an abstract process, while the business objects will be concrete. This will also be very clear, when it is time to model correlation rules – i.e. which message instance is processed by which process instance. At this point in time, the most natural process instance will be the business object instance. Remember: The public process is only an abstract process – therefore it does not have instances.

Model Common Monitoring Process

Now the details have been modeled and we want to re-aggregate the execution of the processes into a common process view on instance level. The Monitoring Process View is needed as a re-simplification of the already modeled details. In the optimal case the monitoring process is equal to the original process model which stood at the beginning. Most probably there will be deviations for good reasons. This of course is also a good exercise to re-confirm the original requirements and justify the deviations from it.

I was recently asked if I like this idea: Handle everything, that is coded in an ERP systems today as Process Patterns and instead design it as process models, that can be adapted to the requirements of the customer. The context of the discussion was if the combination of ERP/BPM/SOA would not have tremendous potential.

I aswered, that I have experience with that and that I agree that there is a tremendous potential with that. That really was an interesting discussion, because I did not hear such analysis before in the discussions in the public marketplace. I think this is the right direction to think.

I had already governed the design of the process of about 200 or more business objects, creating about 2.000 models including roughly about 5.000 web service operations. I didn’t use BPMN for that, because it was not flexible enough for this purpose, neither any of the existing languages. I used an own Domain Specific Language (DSL) for Modeling the behavior of those Business Objects.

My summary of that exercise is, that I agree to the original question. Only by modeling the process of Business Objects which are part of the ERP system, the ERP system’s web services will as a result have the right granularity. What is the right granularity for web services? Reusability. If web services are reusable, then they pay off most. In order for them to be reusable, they need to fulfil certain conditions. A web service operation should only do one thing at a time., i.e. not trigger an endless chain of activities in the system. It should have clearly defined preconditions. The effects and results of the web service operations must be clearly defined in terms, that can also be preconditions to other web service operations. That are the most important criteria in my view.

A system must be designed for this philosophy from the beginning. I strongly believe that adding web services to an existing system falls short of this goal. Even if it has some value, it would not use the full potential.

In general what I miss in the public standards is a language to describe the behavior of web services. Yes, BPMN 2.0 goes into that direction. But BPMN 2.0 still has to prove that it can fulfil the promise in practice. I think to a degree it can. It will turn out later, if it is possible to simplify the language or if it becomes an inspiration for other approaches (e.g. constraint based instead of workflow based).  And using BPMN 2.0 in itself does not guarantee the success. Additional guidance is necessary, certain quality criteria that each model must fulfil.

However, if the behavior of web service operations of an ERP system is defined, and if the granularity of the web service operations are so, that they are reusable, then the potential is very big. Because it means, that it is possible to attach own processes to that ERP service and even to interweave own processes in-between ERP processes. For example to add an approval before the release of an order under certain conditions, to add an own method of calculating benefits for the payroll and the like.

However as a limitation to the original question I would say, that not all of the processes modeled could be customized or changed arbitrarily. There are certain core processes, that the ERP system offers, that can not be changed without the danger of losing the consistency of the process. Therefore it is clearly necessary to describe which part of the process needs to remain stable and which parts of the process can change or are open for additions and interweaving. This of course must be part of the model.

Today I wanted to do a little bit of CRM – manage my Leads. I asked myself how I could utilize Salesforce.com together with XING. I searched, but did not quickly find a ready-to-use integration.

Therefore I quickly extended Salesforce with what I wanted.

[nggallery id=1]

It is a lightweight integration with minimum data redundancy. Within a matter of one hour I added four links into my Lead.

1. Link to XING Profile
2. Link to XING Group Membership
3. Link to XING Messages – Inbox
4. Link to XING Messages – Outbox

These Links are calculated from the Name of the Lead, so I do not need to enter them. The only thing I need to enter is the profile name in itself – in my example FrankMichael_Kraft. Probably this can be calculated as well – if I can confirm if they are constructed.

The resulting page is displayed within the salesforce Lead. I can interact with that page as well.

So I have minimum data redundancy: I need not to copy the correspondence into the lead for example. I just use Salesforce mainly to maintain the status of the Lead.

So what I like about the Salesforce approach to CRM is:

• There are ready-to-use Business Objects – I can start in a matter of minutes.
• It is relatively easy to add new fields and links.
• The new fields and links are operative immediately. No deployment, whatever. Just run.

What I do not like so much about the Salesforce approach to CRM (as of my knowledge of today):

• I’d prefer more a social approach to CRM. I disregard mass email production. This is my preference.
• It is not clear to me how Lead Activities integrate with Email outside of Salesforce CRM.
• To add a Link you have to manually add it to every (in my example 4) layouts to be complete.
• I first missed the link construction syntax. However there was no errormessage. Just no page displayed.
• In the customization of Leads it promises to be able to change the Lead Process. But all you can do is to remove one or more of the 4 predefined statuses. This is much less than I expected.

However I am quite happy about this lean solution, that I can use right away.