2010-01-23

LinkedIn: Process Mapping - How to Stop the madness?

<discussion ref="http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&gid=2057992&discussionID=12653567&sik=1264241010512&trk=ug_qa_q&goback=.ana_2057992_1264241010512_3_1" />

A few recommendations.

1. Clarify the context

It is necessary to ask a few times WHY they need 2000 processes to get a fuller context as Kenneth said. ( your < aligning everything with the customer and correspondingly aligning the business strategy to that and so on down to the process level> is a good approximation)

2. Discover the architecture (as a tool)

What “process architecture” do they have or envisage? It is
a) a nomenclature of main artefacts (i.e. processes)?
b) a set of principles for governing the design, execution and evolution of this portfolio? c) a holistic approach with balanced amount descriptive (i.e. the item “a” above) and prescriptive (i.e. the item “b” above) aspects?

Is this processes architecture aligned with business architecture? Or do they want that this processes architecture will be a “centre of crystallization” for future business (and enterprise) architecture?

In any case, some understanding HOW this set of processes will EVOLVE and will be USED is necessary.

3. Defined your way how to eat an elephant [tip: together and piece-by-piece]

3.1 Start from top-down step-by-step detalisations of the big picture by structuring TOGETHER processes/services/capabilities and other artefacts (something like http://improving-bpm-systems.blogspot.com/2009/11/linking-concepts-and-expressions-used.html ). The top of the enterprise (i.e. business model, business architecture) is a slow-moving part of the enterprise (agree with Susan), so “AS-IS” is very valuable – agree with Dick.

This can be done by a BPM architecture team together with the top management. A few important considerations about this horizontal span over the organization:
• Please, do not forget to include into models EXPLICITLY external participants (customers and partners).
• Where to stop this detalisation? Sensing the feedback of the top management – this big picture should be understandable by everyone.

3.2 Then carry out a few vertical spans to demonstrate and develop internal modeling/etc. practices. This can be done by the BPM architecture team and line management/super users/IT architects/etc. If necessary, develop a few quick prototypes.

3.3 Present the results to the top management, listen/reflect their feedback, and tune the practices.

3.4 Train line managers to use those practices and let them advance with their processes by themselves.

3.5 Monitor and help/guide them if necessary.

Note: After the first iteration you may get a mixture of "as-is", "to-be", executable, etc. maps. This will show the maturity of processes and experience of people within the organisation. Use it for next iteration.

Thanks,
AS

No comments: