Linkedin: How do you look at BPM ? Is it a link between IT and Business?

<discussion ref="http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&gid=70120&discussionID=12657424&sik=1264751381706&trk=ug_qa_q&goback=.ana_70120_1264751381706_3_1" />

Although, the classic EA documents enterprise assets (or artefacts), there is still a lack of explicit knowledge about how the “enterprise genotype” (a full nomenclature of enterprise artefacts) defines the “enterprise phenotype” (a set of observable characteristics such as performance).

Agree with previous posts that proper use of BPM is the way to structure such explicit knowledge. I recommend to consider enterprise BPM systems (a portfolio of business processes of the enterprise, as well as the practices and tools for governing the design, execution and evolution of this portfolio as a system - see http://improving-bpm-systems.blogspot.com/2009/04/should-we-consider-third-forgotten-bpm.html ) and to architect them with the following principles:

• All artefacts (events, processes, services, rules, roles, data, documents, activities, KPIs, etc.) must be evolved to become digital, external, virtual and components of clouds.
• All artefacts must be versionable throughout their lifecycle.
• All relationships between these artefacts are modelled explicitly (e.g. a business process is a complex relationship between many other artefacts).
• All models are made to be executable (this is the essence of the BPM discipline – what you model is what you execute).

Considering that EA does a great job in describing the “enterprise genotype” and there are many techniques to evaluate the “enterprise phenotype”, then the BPM with its executable models of relationships between artefacts can form the bridge (an enterprise executable model) between the “enterprise genotype” and the “enterprise phenotype”.

Thanks,
AS

Linkedin: Is it required for a BPMS to have IT systems like CRM, ERP etc. in an organisation or is BPMS alone capable of handling such complexity???

<discussion ref="http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&gid=41075&discussionID=12709315&sik=1264408758735&trk=ug_qa_q&goback=.ana_41075_1264408758735_3_1" />

I would say that existing specialized systems can be eclipsed by a BPM suite (similar to a astronomical event).

From the architecture of the business as a system, a process is an executable and explicit relationship between many artefacts: processes, services, events, rules, roles, business objects (data structures and documents) , audit trail, KPIs, etc. Any modern BPM suite greatly facilitates assembling those artefacts into processes. But, very often those artifacts are actually locked and “diluted” into existing applications, e.g. CRM and ERP. So, if you can externalize atrefacts from existing applications then you can move any coordination of work (i.e. workflows) from existing applications to your BPM suite.

Such approach – coordination of several specialized systems by a specialized system (i.e. BPM suite) can help you to use better some commercial off-the-shelf (COTS) or “canned apps”. Because they are eclipsed by a BPM suite, their missing functionality can be added with some generic tools (such as business rules engines, BAM, BI, etc.) connected directly to the BPM suite. So, there is no need to customize COTS. This is like the renovation of an old farm when good old walls are amalgamated with the new structure.

My opinion is that BPM suites should concentrate first on the full life cycle of business processes (model, automate, execute, control, measure, optimize) and leave other artefacts to other specialized systems. For example, ECM for documents. CRM and ERP may become repositories for business objects such as materials, customers, etc. as well as some business rules. Such repositories may produce some business events which initiate some processes.

Thanks,
AS

Practical process patterns: HENS

Hiding Explicitly Nested Structure (HENS) pattern is about selection of the presentation of a diagram.

This is a process to check (solvancy, legality, etc.) of clients. To model it I used step-by-step detalisation to keep the each step easy to understand. It happened that each iteration was just adding a new level of details and I used a new pool at each step. The result (see figure below) is a nested structure.

Obviously, such a diagramm is rather unusual for some people because many processes have a linear structure. So I put the whole process into one pool (see figure below).

As a possible variant, I removed some BPMN "sub-processes" (see figure below).

So, all three diagramms are equvalent, but which is better? All depends. Ask people who work with this process -- which diagramm they prefer.

Thanks,
AS

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

Linkedin: How does architecture ensure system flexibility?

Continue from http://improving-bpm-systems.blogspot.com/2010/01/linkedin-how-does-architecture-ensure.html


A few comments:

RE: <The better question would have been - "How much am I willing to spend to ensure flexibility of my systems?".>

The first consideration – it is known that

• “80 % of software lifecycle costs occur during the maintenance phase”, and
• “80 % of maintenance is due to unmet or unforeseen user requirements; only 20 % is due to bugs or reliability problems”.

These values were reported in 1992 as an average for the IT industry; the current situation for some enterprises is worse – the development and deployment of an application can be only 5 % of the total cost of its ownership. What is also disturbing is that these values are not widely known to many people from the IT industry, and IT staff typically estimate these values completely differently – see below http://www.samarin.biz/misc/EPI-TCO-c.png

The second consideration: A desired level of agility / flexibility may be different in different industries and, moreover, it may change over the time. For this reason, I prefer to talk (see the already mentioned presentation) about “optimal agility”.

RE: < One answer is: by using appropriate design patterns. >
Also architectural principles are useful – my list is the following:

• A few definitions can be useful
• Endorse the “building block” architectural concept from TOGAF
• Avoid modification of shrink-wrapped commercial or freely available software
• Danger of premature optimization
• Avoid the trap of the selection of “top-down” vs. “bottom up”– use the “pinball” style
• Explicit is better than implicit
• The big picture
• Horizontal and vertical coordination
• Long-running processes
• Avoid dispersion of the business logic
• The importance of business events
• Visibility of artefacts
• You may break any principle provided that you master it

RE: < Overall flexibility is a too generic concept to drive an architecture effort.>
As usually, we deal with a system of systems (or even with more “nested” structures) then the architecture of each system should address flexibility in its own way. So, the architecture of the top system of systems may provide “overall flexibility”.

Thanks,
AS

Book review by Michael Poulin - "All processes are services", says new book on BPM

<quote>
he author believes into strong coupling between BPM and SOA, and, when defining term 'process', adds: "some operations of a service can be implemented as a process, and a process includes services in its implementation." So, when you read about processes in this book, you may mean services.
</quote>

See the full review at http://www.ebizq.net/blogs/service_oriented/2010/01/all_processes_are_services_says_new_book_on_bpm.php

Thanks,
AS

Book review by TARANEON

<quote>
In contrast to other publications on the topic which fail to evenly balance the business and IT aspects and tend put to readers off by either being too abstract of too technical, this book manages to successfully walk that fine line. Alex leads the reader from the basic premises of BPM as a business discipline to the development of an architectual framework which – as he says in the introduction – ‘is not about how to make your products better, different or more attractive for the market place – this is for you to decide. What we offer is to help you reduce the overheads in doing so …’
</quote>


See the full review at http://www.news.taraneon.com/?page_id=97

Thanks,
AS

Linkedin: Towards applied enterprise architecture

<discussion ref="http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&gid=1426597&discussionID=12055573&sik=1263588623939&trk=ug_qa_q&goback=.ana_1426597_1263588623939_3_1" />


This is clause 13.5 from my book "Improving enterprise business process management systems" www.samarin.biz/book

The classic EA way is to document the existing (so-called “AS IS”) state of an enterprise to a very high level of detail, with many views, and in accordance with different existing EA frameworks. A bulky document with a lot of artefacts (goals, objectives, policies, standards, processes, data, KPIs, events, services, etc.) and some relationships between them certainly can impress the customer.
But such a document is just the beginning. The customer’s typical expectation is that this document will help the customer to take informed decisions for different business scenarios. The following typical scenarios are quoted from Google “The enterprise architecture network” group: merger, changing of a functional unit’s structure, survival in heavy competition, cost cutting, modernisation of legacy applications, outsourcing the whole functional unit or just its IT environment, portfolio rationalisation, etc.
So far, EA cannot provide precise guidance for these scenarios, because the future (so-called “TO BE”) states in these scenarios are not known precisely in terms of artefacts, and thus cannot be compared with the current “AS IS” state to a good level of accuracy, although a good description of the “AS IS” state may give some hints. So, in the absence of a good global direction, the business takes its favourite approach via small incremental modifications based on their implicit logic thus permanently changing the “AS IS” state.
We think that the gap is in the absence of explicit knowledge about how the “enterprise genotype” (a full nomenclature of enterprise artefacts) defines the “enterprise phenotype” (a set of observable characteristics such as performance). Considering that EA does a great job in describing the “enterprise genotype” and there are many techniques to evaluate the “enterprise phenotype”, then the BPM discipline with its executable models of relationships between artefacts can form the bridge (an enterprise executable model) between the “enterprise genotype” and the “enterprise phenotype”.
Of course, such an enterprise executable model may change over time and even be built with different best practices. But if both the “AS IS” and the “TO BE” states have enterprise executable models which are built on the same principles, then one can

1. compare and evaluate different “TO BE” states to select the desired one, and
2. produce better and more systematic transformations from one enterprise executable model to another to reach the desired “TO BE” state faster.

The ingredients of an enterprise executable model are the following.

• Choose a proven way to conduct the business, e.g. a process- and service-centric enterprise will have “AS IS” and “TO BE” states which can be compared.
• Establish a comprehensive inventory of all enterprise artefacts, including those from business (roles, processes, events, etc.), information systems (data, services, etc.) and technology (servers, etc.), as normal housekeeping practice.
• Explicitly model relationships between these artefacts (e.g. to fulfil the business process Z we need the information systems X1 and Y2) to reveal all hidden relationships and to structure them. This can also help an enterprise to estimate better certain characteristics such as service availability and the cost of particular operations.
• Make all models executable. The best example of an executable model is a business process model. This is an aggregation of events, human and automated activities, roles, objects, rules, audits, etc. Again, this is the essence of BPM – “what you model is what you execute”.
• Make all artefacts digital, external and virtual so that they can be used in executable models and are easy to evolve.

We have observed that most of the items in this list are usually in place in many enterprises, but the items are often treated separately. For example, the business offers services and uses processes which are described only in the Quality Management System (QMS documentation. The inventory of artefacts and their relationships are defined by an EA tool. Everything that is executable is kept by the IT unit.
There is nothing fundamentally unusual in this approach – it’s just a question of making previously separate things work together. Of course, this is not a mechanical but a holistic aggregation.
This synergy provides very important information for decision making – how many resources are consumed by a particular artefact and what is the contribution of each artefact to the enterprise’s objectives? The information that application X is used in process. A is useful, but it is even more valuable to know that application X is supported by N persons, but was used in only a few instances of process A, and most of these were cancelled without any financial outcome.
Now let us see how this approach can help enterprises with some of the scenarios mentioned previously for business transformation. In any merger, one of the problems will be the intermixing of two previously independent enterprises, e.g. the services provided by one enterprise are to be embedded into the processes executed by the other enterprise. By analysing the gaps between the service interfaces and process definitions, one can properly estimate the cost of such intermixing.
For any cost optimisation scenarios, the real contribution of each artefact to the enterprise performance should be a clue. In portfolio rationalisation, the economic effect of each project is easy to evaluate because the projects deal with schematically similar and transparent process- and service-based business. Moreover, it is possible to anticipate that one project improves artefacts which are to be reused in another project.
Any enterprise has its own architecture, but is this architecture fit to face the challenges that the enterprise will encounter? And if the top management accepts to improve the architecture of an enterprise, who will be chosen to manage this job? Any candidate should have a wide range of skills to be able to play different roles, and should demonstrate comprehensive knowledge of the business, information systems and IT.
Thanks,
AS

Linkedin: What are the most important questions in BPM?

<discussion ref="http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&gid=2087324&discussionID=11857025&sik=1263569046293&trk=ug_qa_q&goback=.anh_2087324.ana_2087324_1263569046293_3_1" />

Although this post didn't solicit answers I use these questions as a very good first step in understanding BPM. Some answers are very brief because they are based on my book “Improving enterprise business process management systems” – see www.samarin.biz/book

In those answers I separate explicitly three concepts often mixed under the abbreviation “BPM”
1. BPM as management discipline is "manage enterprise by processes".
2. [Enterprise] BPM system (portfolio of the business processes as well as the practices and tools for governing the design, execution and evolution of this portfolio) which DOES manage processes within an enterprise on their full lifecycle.
3. A BPM suite (software product) which may help in the implementation of an enterprise BPM system.

>Theme A: Creating a shared understanding resulting in practical action
>1. How would my organisation be different if we implemented process-based management?
Use of BPM is not is not about how to make your organisation products/services better, different or more attractive for the market – this is for you to decide. What the right use of BPM can offer is to help you reduce the overheads in doing so – your flexible BPM system will become an enabler for your business innovations.

>2. What is the link between organisational strategy and business process management?
BPM disciple will help you to manage better your organization – implementation of strategy will be more straightforward because of explicit and executable business process and flexible BPM systems. Desired TO-BE organization can be modelled and its behavior can be simulated to validate expected performance.

>3. How do I create exciting BPM visions to lead to entire new process visions for my organisation?
>4. What are the compelling reasons for my organisation to adopt process-based management?
>5. How can we capture executive attention and transform it into commitment?
>6. Why should my organisation invest now in developing a process management capability?
>7. How can we develop a critical mass of people interested in BPM?
>8. Why should our day-to-day operational managers care about process management?
>9. How can we make the ‘idea of process’ highly contagious?
We have observed that implementing BPM requires a lot of communication with practically everyone within the enterprise, and everyone should be treated as a stakeholder of the BPM system. Each group of stakeholders has different views, different concerns and a different understanding of the BPM system. The different groups of stakeholders are generally the following: top managers, enterprise architects, business line managers, process owners, super-users, normal users, project managers, business analysts, IT managers, IT solutions architects, IT developers, IT operators.

It is necessary to explain to each group of stakeholders how their concerns will be addressed and how their current working practices will be changed for the better. (This is a typical duty of the chief architect of the BPM system.) Coherent and clear explanations in the business language are vital for the success of a BPM project. Success is not about saying “Yes” to all requests from the “more important” staff members; it is about building a common understanding and agreement between all stakeholders.
The book helps you with ideas on how to present BPM to a particular stakeholder.


>Theme B: Modelling, measuring and delivering process improvements
>10. How can I use process models for improved engagement and communication?
Executable business process models can serve simultaneously as:
• artefacts in software design
• input for project planning and execution
• executable program for coordination of work
• documentation for all staff members

>11. What are innovative ways to model beyond complying to dominant process modelling standards?
Make your processes a) executable, and b) understandable for all stakeholders.

>12. How do my process models best inform the software development lifecycle?
Use a modelling procedure which explicitly produces artifacts understandable by business and IT, e.g. roles, rules, services, data structures, documents, audit trail, etc.
Also align BPM with your PM, EA and SDLC practices.

>13. How can we measure things that are difficult to measure?
>14. Can we justify the cost of measurement?
Can’t measure = can’t manage. Do we need to justify cost of absence of management?

>15. How can process performance be integrated with financial, unit and individual measures?
A set of proper KPIs, risks and money should be “attached” to processes. For example, during execution of a process instance, it should be possible to evaluate the risk of breaking the SLA of this process.

>16. How can we make sure that the To Be becomes the new As Is?
Good architecture, small iterations and executable processes.

>17. What are the current limitations of, and future prospects for, BPM Systems and related technology?
I think you mean “BPM suites” not “BPM systems”. The current BPM software is built for the vendor-centric market. This software should be adjusted to a customer-centric market.

>18. Are you seriously suggesting ‘continuous improvement’ with all the disruption that will bring?
A good architecture can make continual improvement easy.

>Theme C: Creating an environment that sustains business process success
>19. What does it mean to be ‘accountable for process performance’?
Person’s KPIs are based on process KPIs

>20. How many process owners does it take to change the operational performance of a light bulb?
>21. How can I be accountable for the performance of something that I do not control?
>22. What is the ROI for a Process Centre of Excellence?
I offer to build a “Process Centre of Excellence” for a half of Return from all BPM projects to be carried out by this centre.

>23. How do we integrate BPM with other management disciplines?
Many management disciplines use the idea of management by processes (BPR, ISO 9001, Lean, TPS, 6S). BPM is pushing this forward by considering the process as the main artifact.

>24. What is our realistic pathway to increased BPM maturity?
Apply BPM as management discipline, define your architecture, build a flexible system, use a commercial tool

>25. How can we make process-based management truly sustainable?
By satisfying business needs in a few times better/faster/cheaper than others

>26. How can we create and maintain a process mindset throughout our organisation?
See question 9.

>27. If it takes 3 years to raise BPM Maturity, why are most organisations still at such low maturity levels after so many years?
Vendor-centric BPM market; lack of agreed BPM reference model

>If we had the answers to all these questions, would we know everything?
They are just a tip of the iceberg – more questions will come from more people when they move to BPM.

Thanks,
AS

Blog: Is BPM a Dirty Word?

<discussion ref="http://www.theprocessninja.com/process/2010/01/is-bpm-a-dirty-word.html" />

Of course, BPM is a dirty word in its current (mis-)use - because BPM is a vendor-driven market - "The most important success factor of a BPM project is a selection of the right BPM tool".

Agreeing with the post and previous comments - BPM should be returned to business and must become a customer-driven market. I think, it may be done in the following sequence:

1. BPM is discipline to use processes to manage the business (a reference BPM model is very important)
2. BPM is a system (hence architecture is very important) to manage the full lifecycle of processes within an enterprise
3. A BPM tool should be selected on the basis of that architecture.

Thanks,
AS

Linkedin: Which of the two should be key metrics for measuring successful BPM?

<discussion ref="http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&gid=1847467&discussionID=10601888&sik=1263196787644&trk=ug_qa_q&goback=.ana_1847467_1263196787644_3_1" />

In favor of a more generic measure. BPM as a tool for improving enterprise business performance is capable to carry out different combinations of different types (operational, tactical, strategic, competitivity) of improvements as required in different moments of time. So, a set of KPIs may be different at each particular improvement. Thus the key metric is how easy to apply/use BPM to improve the enterprise business performance.

Sure, that your BPM system should be very flexible and this flexibility should be architected.

Thanks,
AS

Linkedin: Brainstorming on Adaptability / Flexibility

<discussion ref="http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&gid=84758&discussionID=11789589&sik=1263141957825&trk=ug_qa_q&goback=.ana_84758_1263141957825_3_1" />


My area is to improve not general, but IS/IT capacity of change, because the latter is the main blocking factor in many organizations. Usually, we do some specific initiatives first and then spread and generalize the experience. I use several techniques:

1. Show the slide 4 from http://www.slideshare.net/samarin/creating-synergy-between-bpm-and-ea-in-an-egovernment-environment to indicate importance of flexibility.
2. Coach the business how to request and test flexibility of different IT products (instead of just compliance to the specs), e.g. a vendor of BPM suite should be asked to implement a simple process and to carry out some changes during the live presentation.
3. Prepare prototypes which demonstrate flexibility.
4. Rescue “rotten” projects.

A recent example – a tender for an MIS for a governmental agency.

• High level of flexibility explicitly required
• Budget 4,5 MCHF
• About 10 offers

Some contenders:

• Classic development – 17 MCHF
• ERP hidden under workflow – 4 MCHF
• BPM-based – 2,5 MCHF

The latter has demonstrated a simple prototype and that helped to win the tender. Of course, to calm down the internal IT department, the winner has to do an extra “feasibility” step -- quickly demonstrate a very advanced prototype, which works at the client’s IT environment.

Thanks,

AS

More details are in my new book “Improving enterprise business process management systems” www.samarin.biz/book

Linkedin: SOA or not?

<discussion ref="http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&gid=36604&discussionID=11868557&sik=1263034934834&trk=ug_qa_q&goback=.ana_36604_1263034934834_3_1" />

I agree that just defining all processes and then “converting” activities into services is not a good idea (e.g. because of potential absence of a good structure as mention in that anti-pattern). Also, I noticed that, just defining all services and “pushing” processes into them is a challenge.

I consider the following relationships between services and processes:
• all our processes are services,
• some operations of a service can be implemented as a process,
• a process includes services in its implementation.



To find out these relationships at a particular enterprise, I recommend a 4-phase modelling procedure

which incrementally structuring processes and services, as well as avoids diagrams like


“Services are not supposed to make assumptions about the context in which they are invoked. Driving service identification from the process risks making the service useful in only that process.”

Sure, no assumptions. Services are designed to work in context – the latter defines functional and non-functional characteristics of a service. The usage of the same modelling procedure increases probability that two different people will find similar services in the same context. Also, the high level of flexibility is necessary to quickly refactor slightly different services into one reusable service.

Thanks,
AS

More details are in my new book “Improving enterprise business process management systems” www.samarin.biz/book

Linkedin: How does architecture ensure system flexibility?

<discussion ref="http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&gid=1523&discussionID=10617743&sik=1262950490126&trk=ug_qa_q&goback=.ana_1523_1262950490126_3_1" />

Any complex system is a dynamic set of artefacts (or building blocks), e.g. in case of a BPM system those artefacts are: processes, services, events, data structures, documents, rules, roles, activities, audit trails, KPIs.

Artefacts are interconnected and interdependent. We have to anticipate potential changes: policies, priorities, compliance, technology, etc. Implementation of such changes necessitates the evolution of some artefacts and the relationships between them. It must be easy to modify all artefacts and relationships without causing any negative effects.

My main architectural principles for creating flexible systems:
- All artefacts must be evolved to become digital, external, virtual and components of clouds
- All artefacts must be versionable throughout their lifecycle
- All relationships between these artefacts are modelled explicitly
- All models are made to be executable

See http://www.improving-bpm-systems.com/pubs/AS-AW08-keynote.pdf

Thanks,
AS

More details are in my new book “Improving enterprise business process management systems” www.samarin.biz/book

Be explicit with BPM as a management discipline

Business Process Management (BPM) as a management discipline means "using processes to manage business" ("stolen" from Connie Moore's twit).

French version should be "Gestion par processus", but not "Gestion de processus métier".

Russian version is "Управление предприятием на основе процессов".

Of course, "management of business processes" is also necessary.

Thanks,
AS