Cluster meeting “Emergent/Adaptive Software”

August 25th, 2010 Frank Michael Kraft No comments

Today I am visiting the Cluster meeting for “Emergent Software” in the Area “Rhein-Main-Neckar” in Germany, my home country. The Cluster is a network of Companies in the area of Software and from the region and is supported by the German government.

The goal of the cluster – as I understand it – is to enable software companies of the region to collaborate for the common goal of adaptive business processes. Yes – the term adaptive business processes has been on the slide describing the goals of the cluster. Maybe they are also reading my blog :-) . However the term emergent business processes has been used interchangeably. I do not exactly know, what emergent processes means, but I believe it means something similar like adaptive. Probably over the course of time – if there is a difference – it may become clear. But my guess is that emergent is more like an academic term.

The talk defined an adaptive process as flexible and secure integration of ERP processes with Web Services (SOA). That is quite a different definition as the definition we use for Adaptive Case Management. Adaptive Case Management does not depend on ERP processes, nor on Web Services (SOA) – although there is no reason why they should not be integrated with ACM – as I argue in my chapter of “Mastering the Unpredictable”. In the end, ERPs and SOA is less flexible than ACM, so ACM can adapt to the form of ERP and SOA, if they are built in a way that integration is possible.

That little “if” is a big “if”. In my experience it is not just defining a WSDL interface for an ERP systems interface to make process integration a reality. If the ERP service is not built by design for integration, then integrators will have a hard time. Middleware does not solve the problem. Maybe many readers might disagree, but I am convinced of what I say: Middleware does NOT solve the problem!

Before we can solve this challenge we must look at some ugly truths in the first place.

I make a simple example. If an ERP system has a purchase order and the purchase order does not wait for purchase order confirmations (i.e. the ERP system does not support this functionality) before a purchase order update may be sent to the supplier, but the suppliers ERP system can only handle updates after the confirmation, then there is a problem, that even middleware can’t solve. Yes, some purchase order updates may be blocked by the middleware – but what does it help? The confirmations will find a different purchase order state which leads to further conflicts, error tickets, misunderstandings and all bad things.

That is the ugly truth about process integration.

So in the first place the challenge for ERP/SOA integration is to make it work at all. Then, in a second step, flexibility comes into play. Sure, flexibility is demanded. But not always. If you walk over a bridge you don’t want it to be too flexible. It’s the same with business processes. You don’t want the flexibility to bypass the posting of a cheque for example or to send the money to a different account. So flexibility means controlled flexibility.

Both problems can only reasonably be solved by modeling. The web service interaction – the choreography – must be modeled, not only the WSDL signature. This is possible now by using BPMN 2.0 Choreography modeling, which is brand new. I must add some coaching is needed to use it. So I expect the cluster needs to discover this great method of describing the web services in the first place, then find principles of designing their business processes in a way, that they are able to be integrated, and then in the end ACM can also be integrated – that’s the easy part then.

Categories: BPM Tags:

Mentoring in Knowledge Work

August 23rd, 2010 Frank Michael Kraft No comments

Peter F. Drucker writes about the future relationship of managers and knowledge workers in his essay “They’re Not Employees, They’re People” (Harvard Business Review – February 2002). He writes:

Similarly, leaders in knowledge-based businesses must spend time with promising professionals: Get to know them and be known by them; mentor them and listen to them; challenge them and encourage them.

I think Drucker picks up a very important thought here. The whole essay is about relieving managers from routine work, so that they have more time for investing in people. This is a very important thought, in my eyes.

I always felt uncomfortable to refer to employees or project members as “human resources”. I think this is a term that was coined in the ages of industrial revolution. There are “human resources” and “financial resources”, “natural resources” and “production resources”. A resource is a source that can be used to achieve a goal. And – the use of it can be planned. I might agree that it makes sense to call the routine work of a person or his ability to perform it a resource that can be planned – although I would still not call the person a resource.

In my eyes knowledge work is different. The key to knowledge work, as I believe, is creativity. And creativity is the one thing that cannot be preplanned, nor demanded, nor predicted. It is like pulling a small tree that it might grow faster. It is obvious, that the tree needs certain conditions to grow, sometimes it needs nurturing. In the same way knowledge work needs an environment, where it can grow, as well as nurturing. Knowledge workers need nurturing and mentoring. That is how they learn to become productive.

In the same way the role of the manager of knowledge workers needs to adapt. I would call the future role a knowledgeable manager. The reason is very obvious. In the industrial age, work was comparatively easy to plan. Repetitive processes had to be established and maintained. It still was difficult – but it was easier than planning today’s knowledge work. Managers often have to decide. How can they decide, if they do not understand, what their people are talking about? How can the manager guide the discussion into the right direction, if the manager is not himself an expert of the subject matter?

How does a manager become knowledgeable? He must have gone the way before us. I know that this is a challenging statement. Is this part of today’s management curriculums? I have doubts. The knowledgeable manager cannot know only from books. He must have been through it. Then he has the practical wisdom plus the current state of expert knowledge that is needed. And then he is able to mentor his people. This is the best way to become knowledgeable. The other way is to listen to his people. Listening is hard. It takes time. Sometimes it is 6 months of listening, sometimes a year before it dawns to the manager, where the real problem lies.

I am only mentioning these thoughts to argue, that classical management methods will change and have already changed with the advent of knowledge work. The style of management will be less prescription and more collaboration, even mentoring. Good managers will need to know more and good knowledge workers will need to manage more.

Knowledge workers are only successful, if they are able to align their goals with the goals of many stakeholders and with many projects, where they are stakeholders, and with peer projects and groups. This is quite some management. They can’t rely only on their manager to organize all of this for them. They will take the initiative and be responsible for the result.

So the manager becomes more knowledgeable and the knowledge worker becomes more of a manager. What then is the difference between the two? I think the difference in the type of work they do is only marginal. Yes, the manager has a little more to manage and the knowledge worker has a little more to know. Maybe the difference grows with distance in the number of management levels. But I still believe that even top management will need to know a lot about the subject matter they are responsible for. I think the main difference between the manager and the knowledge worker is their individual set of relationships they need to maintain. The knowledge worker has more contact to his manager than to his manager’s peers or his manager’s manager. And he has more contact to his peers than his manager has. So the quality of work is similar, but the relationships are different. This is what is called self-similar. In my eyes the quality of work of knowledge-intensive organizations is and will be self-similar on all levels. That’s why there is common glue between them. Today it is email and the meeting calendar plus spreadsheets and documents of different forms. In the future – that’s what we believe – it will be ACM.

There is a third role in organizations that I want to discuss, the business process analyst. The classical task of a business process analyst is to develop and maintain the enterprise process landscape, monitor process performance and planning the process portfolio. This is applicable to routine work, while it has also been tried to apply it to knowledge work. It is a cross function in the organization. However the difficulties with that have already been discussed when comparing classical BPM with Adaptive Case Management (ACM). One of the difficulties is that knowledge work processes tend to be unique and tend to be very much influenced by the knowledge that results from earlier process stages. I other words it is very hard for an external observer, that is not part of the process itself, to plan the process. Also it does not make much sense in this instance to include the process into a process portfolio, if it is only executed once or a small number of times. The lifecycle of the process may be very short, which makes it very ineffective to observe it, document it and measure its performance based on that by an external observer.

But: measuring process performance is still necessary. It’s only, that it is not a preplanned process. Everybody would be interested in measuring process performance. The knowledge worker is interested in his own performance or the performance of processes that deliver results to him. The manager is interested in the overall performance of his team and related teams. And the business process analyst would want to focus on cross functional process performance.

Knowledge workers and often also managers do not care so much about formal process performance measuring. They are certainly interested in the performance of the processes, but it’s often not formalized. Business process analysts know many ways to measure process performance. Now with ACM this can become reality also for knowledge work processes. If business process analysts buy in to ACM, they are the best people to mentor managers as well as knowledge workers in how to measure performance. At the same time the business process analysts will find it useful to understand more about the content of the processes they are measuring, what they are about. They might find themselves helping the manager to solve process performance problems (which in many cases in knowledge work are full stop blocks instead of tuning percentages). For the manager and the knowledge worker it is then a little bit more formalized, but not overdesigned.

I believe the future of the business process analyst in knowledge work will be more like an expert for one area of expertise, which is cross functional process performance and adaptive case management. Managers and knowledge workers will need to know how to make best use of ACM to achieve best cross functional performance. For example some case templates may be needed to speed up work with another department. This is an area that ACM mentors would take on.

There is a lot more to say about mentorship in knowledge work, but maybe that’s a good starting point for further discussions.

Categories: BPM Tags:

Does Unpredictable Work Exist – continued

I want to comment more about the discussion Does Unpredictable Work Exist?

Jean-Jacques goes on to explain, that classical BPM has neglected the state transitions of resources and only focused on activities. He goes on to explain that there is a relationship between state transitions of resources and activities and that this will bring a new level of enlightenment to the BPM community. I can’t agree more. I hope that we can do some work about this.

However he argues that therefore processes are predictable. That is not true, because in creative processes it is not know a priori which resources (Business entities – for example research reports, experiments, designs, models, customer quotes, …) will result from the creative process.

The discussion goes on with some definitions and a medical example. Then JJ says:

It is like saying, to start a journey, a path must be chosen. All you need is a map, maybe even a compass would do.

I really like this comparison. The activity model is the path, the resource / business object composite state model is the map. I agree that the area of using business object composite state models has not been used in BPM as it should have been used. Therefore maybe JJ is more fighting for that idea. That I very strongly support as well. But what if you neither have a path nor a map? These situations happen very often.

To me it is not enough to assume a “could be” map or path. As a vivid example I have my company startup. Of course there are predefined process snippets for this and that (for example for the tax process – certainly for the tax process!!!). But in the end the tax depends on decisions I do – which legal form I choose, which depends on other considerations. Product and service definition, strategy, financing, partners, market strategy – the special combination of all of that are all unique to my new company (I hope!) and therefore the activities leading to the needed results are unique. And they depend on many decisions that I cannot predict as well. Of course if you do abstraction, then it is the same as with all startups: Write a business plan, Create a product or service, sell it – but I have argued before the abstraction leads to a useless plan. So what I am actually doing is to merge specific process snippets – some predefined like tax – some newly invented by me (product and service innovation) – into one big workstream that is unique, concrete and unpredictable.

To be continued…

Categories: BPM Tags: