BPM and the Knowledge Economy by Ronald G. Ross

BPM often simply overreaches.  Understanding, modeling, and managing a business effectively requires a balanced view of six basic questions, not just one, as given in Table 1.  I follow Zachman in these matters so, yes, the table is Zachmanesque.

	Interrogative	Basic Business Question	Kind of Model
1	What	What inventory of things needs to be managed to support business activity?	structural model (e.g., concept model,[1] data model)
2	How	How do transforms of things in business activity need to take place to add value?	process model
3	Where	Where does business activity occur?	network model
4	Who	Whocollaborates with whom to undertake business activity?	interaction model (e.g., organizational chart, use case)
5	When	When does business activity take place?	temporal model (e.g., schedule, event model, milestone model)
6	Why	Why are results of business activity deemed appropriate or not?	strategy model (e.g., Policy Charter,[2]constraint model)

If your business does nothing but manufacture or produce physical widgets (forget all the meta-data about those widgets), you will probably emphasize question 2 (i.e., process) above the others.  Your overall approach and architecture will reflect that.  You will naturally gravitate toward BPM.

That tendency has at least three basic risks, even for organizations that do fall into the nothing-but-widgets category:

• Your metrics will largely focus on process productivity (e.g., throughput, bottlenecks, latency), rather than strategic goals and alerts centered on external risks.  C-suite executives tend to be much more focused on the latter.


• Your mindset will be procedural, rather than declarative, which can cause you to embed business rules in process flows rather than externalize them.  As a result your process models will be unnecessarily complex and your overall solutions un-agile.


• Your approach will fall woefully short in addressing the intellectual capital that underlies your processes.  Such operation business knowledge ranges from simple meta-data, to the business logic that underlies operational business decisions.

Fewer and fewer business problems these days fall into the nothing-but-widgets category.  Even for widget-centric businesses, at least three needs are increasingly urgent:

1. Ensuring the quality of meta-data.


2. Demonstrating compliance-based actual rules, rather than the artifacts and effects that IT systems produce.


3. Retaining, teaching, and repurposing intellectual capital.

These are not strengths of common BPM practices.

For all the non-widget-centric business activity in the world — which includes just about every conceivable form of white-collar work — these needs become paramount.  And make no mistake, the future lies with automation of that white-collar work.

What would I do to correct the shortcomings of BPM?  Our answer is to become more why-centric, as opposed to narrowly how-centric.  That shift has several essential features:

• Understanding business strategy as something distinct from business processes (and BPM).  Business goals and business risks should be drivers of business process design — not the other way around.  You need to be strategy-driven, not simply process-driven.


• Designing core metrics around business goals and business risks — the things that concern C-suite executives the most.


• Realizing that for white-collar work the 3-D world of widgets has vanished, and that tolerances and quality can be expressed only in terms of business rules.


• Treating business rules as a first-class citizen, externalized from process models.^[3]


• Identifying operational business decisions (based on encoded business rules) as a crucial focal point in re-engineering business processes.


• Including a Why Button as part of every business solution.^[4]  Pressing the Why Button leads immediately to the business rules that produced the results you see from any process.

For further information, please visit BRSolutions.com      

References

[1]  Refer to Refer to Business Rule Concepts:   Getting to the Point of Knowledge (4th ed), by Ronald G. Ross, 2013, Chapter 1 and Part 2.   http://www.brsolutions.com/b_concepts.php  

[2]  Refer to Building Business Solutions:   Business Analysis with Business Rules by Ronald G. Ross and Gladys S.W. Lam, 2nd ed. (Sept, 2015), an IIBA Sponsored Handbook, Chapter 4.  http://www.brsolutions.com/b_building_business_solutions.php  

[3]  Refer to the Business Rules Manifesto, now in almost 20 languages:http://www.businessrulesgroup.org/brmanifesto.htm  

[4]  Refer to Ronald G. Ross, "The Why Engineer™," Business Rules Journal, Vol. 14, No. 11 (Nov. 2013), URL:  http://www.BRCommunity.com/a2013/b727.html 

SOURCE: Ronald G. Ross, "BPM and the Knowledge Economy," Business Rules Journal, Vol. 16, No. 11 (Nov. 2015), URL:  http://www.BRCommunity.com/a2015/b835.html  

What Is the Future for Processes?

To understand the future of processes, you must dig a little deeper than many people do.

Process thinking goes back well over a century, to the origin of modern iron and automobile production.  The raw materials and finished goods of such manufacturing and production processes are literally spatial — 3-dimensional.  What can you do to significantly improve productivity in a 3-dimensional world?  The answer these days is simple:  You build robots.  Robotization has literally changed the world during the past 30–40 years.

Rather than manufacturing and production processes, however, the world is now increasingly focused on white-collar and digital processes.  What 3-dimensional presence do the raw materials and finished goods of these processes have?

Well, exactly none.  The raw materials and finished goods of these processes aren't physical and simply have no spatial presence whatsoever (except maybe for paper artifacts).  Robots (at least physical ones) aren't an option.  That fact of life makes a huge difference in how you have to think about automation for such processes.

Instead, the raw materials and finished goods of such processes are all about your operational business knowledge — your intellectual capital — and your capacity to express and apply it.  That capability, in turn, depends directly on your business terminology and business language.  For white-collar processes you have no choice — the world is semantic.  So you must deal with the subject matter semantically.

That takes us in a very different direction than most professionals currently foresee.  For one thing it takes us toward natural language and away from diagrams.  That's a huge shift in mindset.  Imagine having a business conversation with your smart phone about gaps and ambiguities in business policies and in the meanings of the vocabulary you use to talk about subject matter knowledge.  Don't think that's possible?  Have you watched your kids talking to their smart phones lately?

Sooner or later businesses will realize that operational business knowledge differentiates their product/services and enables their ever-more-automated processes to function.  Capturing, managing, and re-using that intellectual capital puts a premium on structured business vocabulary (concept models^[1]) and on business rules expressed in structured natural language.^[2]  Those business rules are the only way you have to ensure quality from white-collar and digital processes.

What about Case Management?

Many 'processes' people are looking to implement these days are clearly best viewed as case-oriented — e.g., patient care, mortgage applications, etc.  Individual cases must be orchestrated through various states, often with undesirable or wayward transitions.  There is significant variation in the paths that various cases take.  Things just don't always move along as predictably as on a production line.

For such problems you'll want a more case-oriented style of modeling.  (For business practitioners that technique may or may not prove to be CMMN.^[3])  You might not use traditional process modeling at all.  Whatever your approach you'll definitely want to be very clear about what milestones are relevant, and which business rules apply for each.  That puts a premium on business rules.

What about Cognitive Computing?

People are also starting to ask why current processes are so dumb.  For example, why can't they:

• learn from experience? 
• be more goal-driven?
• dynamically balance between conflicting goals? 
• self-adapt? 

Some people suggest use of cognitive computing to help make processes smarter.  I doubt anybody today really knows how far this idea can be taken.  I can, however, say two things with certainty:

• If you don't know what your business rules are (i.e., what rules guided previous executions), can you really expect a machine to figure them out?  A machine can undoubtedly identify patterns, but that's a far cry from demonstrating compliance, guaranteeing consistent results, or customizing appropriately case-by-case.
  
• Suppose self-adapting processes do become reality.  The question I have is what will keep such processes from going out of bounds?  How do you avoid them doing things that are undesirable, self-defeating, or even illegal?  These are critical questions that will always bring you right back to business rules.

For further information, please visit BRSolutions.com      

References

[1]  Refer to "What Is a Concept Model?" by Ronald G. Ross,  Business Rules Journal, Vol. 15, No. 10 (Oct. 2014), URL:  http://www.BRCommunity.com/a2014/b779.html  

[2]  E.g., in RuleSpeak®.  Refer to http://www.rulespeak.com/en/  

[3]  Case Management Model and Notation  

SOURCE: BRCommunity

5 factors to help company growth

1. Dynamism

You should not settle for a rigid business model. The speed of adaptation to change is critical to the success or failure of a company. Competition is increasing and how quickly companies adapt to changes in the business ecosystem will determine the success of their actions as a company.

The use of a BPM system with well defined Business Rules ensures that adaptations to changes are made almost instantly. A change in regulations could be a major headache for paperwork however with a BPMS, such changes are automated.

1. 

2. The Big Picture

All departments should work in unison, not solely focusing on their own work but seeing the bigger picture. The idea is to encourage participation among all members of the company to promote unification and achieve the end results. If everyone works with the same vision it will lead to greater productive development.

3. Technologization and technification

Technological integration is a common factor amongst startup companies. Indeed, the technological evolution is linked to our development and any company which chooses not to adopt new technologies will be left behind and will struggle to remain competitive.

4. Project confidence

It is vital to have a high level of confidence in the company, therefore projecting confidence, the momentum to achieve objectives, sincerity, respect for each and every person involved in the business and belief in their own projects are essential factors in the day-to-day running of every company.

5. Perseverance

Objectives are not always met, but we shouldn’t get disheartened. Indeed, we often learn valuable lessons from failure. Failing should be seen as good training and we should try again. It is all a question of reformulating ideas and insisting on the desired objective.

The adoption of intelligent analytic systems integrated in our business process management system can help us determine what went wrong and thus change these factors.

SOURCE: AuraPortal

Are Your Operations Doing the Right Things, at the Right Time, in the Right Way?

Companies have focused on efficiency for over 15 years now.  But are they making the processes effective?

For this column, let’s consider efficiency to be doing work as quickly as possible with a low error rate.  Then let’s consider effectiveness as eliminating all work that is not really necessary – doing the right things, at the right time, and in the right way.

Too many BPM efforts however, are so narrowly focused on cost takeout that they miss the fundamental question of need – “do we need to do this in the first place?”  Of course, the answer to this question must be backed by the answer to the question “why?”  Anything that falls outside of this need is extra and is a candidate for elimination.  

Not surprisingly, doing this before the team considers efficiency will save a lot of time and cost.  Why improve things you don’t need to do?  But it will also leave holes that will need to be removed.

Effectiveness

Efficiency lives in process – no real news there.  But where does effectiveness live?

I submit that effectiveness lives in fundamental “need”.  What do you really need to do?  The framework for identifying this “need” and thus effectiveness is set by the company’s strategy and given context in the company operating model.  Anything beyond this fundamental or basic need in producing the service or product is extra.   What is left will require specialized support activities to knit together – but that can be managed through careful action and task justification.

So we can find what we need to do to be effective, and we can then make that efficient.  But before we make anything efficient we need to first look at how we can guide work so that the right answers, components, business operations, and assemblies come together to deliver the service or product component.  We need to find a way that guarantees the right logic is considered and the right questions are asked to comply with legislative and operational requirements while constantly being guided to the next step in the work.  

This requirement for guidance is the realm of business, manufacturing, technical, and other rules.  The fact is that rules define the “what” of the business - while process defines the “how”.  If we consider process to be the life blood of the company, carrying the components that are needed to produce something and thus keep the company operating, we can consider rules to be the “brains of the outfit”.  They direct everything and tell us how things need to be done.  Rules thus set the operating framework and are both interpreted and supported by standards to set performance measurement limits on the work.  Taken together, rules and their supporting standards, define how operational effectiveness will be viewed – within the context of company strategy.

Finding rules

Rules are everywhere.  Most are, however, not written and those that are, are seldom up to date.  So where do you start?  The following is one approach – it is not the only one however.  But, it works.  Let’s start with effectiveness in any process, business unit’s work flow, or the applications that support the work.

The first step is the archeological dig through the company dustbins – existing documentation.  Procedure manuals, HR rules, financial rules, sales rules, and compliance rules should be collected and the rules vetted.  That is the foundation – you may very well find rule conflicts, out of date rules, and rules that no one knew existed.  Vetting them is tedious and will probably be resisted.  But it is critical and needs to be done to create a foundation for the operation
.  
These rule collections will first focus on the business operation.  IT should next add its technology related rules – the Do’s and Don’ts that must be considered in any business activity support design.  To make this collection useful, care will need to be taken in finding a rules “engine” or storage application, coding the rules for electronic storage, and defining an indexing structure that will make it easy to find and thus modify, version, or reuse any rule.

With this foundation in place, it will be time to look at the business operation itself.

Any look at what makes a company effective must really start with strategy outcome and work backward.  The outcome description is where you first know how goals will be delivered and where the business model must be changed to support the strategy.  All capabilities will be identified and defined as part of the outcome definition. The capabilities then tie to process and a walk back up the process is a look at what it takes to build the product or services.  

The activity in a business unit represents the work that actually creates the components and does the construction of a solution.  The rules in the company guide every action, every decision, and every step of the work.  But when many teams look at a BPM project, they focus on the activity, not the rules that help identify if the activity is even needed – if the activity is not important or complex enough to require guidance the team really must ask why it exists. Similarly, if the rules do not support the actual work, why do they exist?  The two are partners in a corporate dance that determines what should be done and how it should be done.
Of course, if the rules are overly complex, the team will need to see if they can be streamlined.

In addition to the “easy to find” rules, teams will find other rules (often the most important ones) in the heads of the staff.  They do the work and apply rules constantly – some they make up to control new work.  Many of these unwritten rules are not found anywhere in the “documented” and now vetted rules.  In some cases, these rules may be imbedded in applications that the staff has learned about over time through use.  In other cases, the rules are work-around rules that have had to be informally created to get past changes in the operation, in law, and in application systems.  I call these “white space” rules.  Only the people doing the work of getting around things know these rules. 

The fact is that these rules will tell the team how the activity really works.  Comparing these rules with the ones you have already documented will point out redundancy, differences, conflicts, and erroneous activity.  In some cases I have found old rules that no one knew were still in use had to be changed immediately to comply with current legal requirements.

Rules
As noted rules are everywhere and at many times are the hidden mandate for any activity.

But today we see that many from the BPM world do not pay enough attention to business rules and many from the BPMS world look at rules from a technical perspective – aligning them to the applications in the project or solution.  In both cases, these rules are generally poorly defined and unavailable for general use.  They are also not really adequately shared between the business and IT sides in creating a new business solution.

The need to address this is critical and cannot be underemphasized – you must get a handle on your company’s business, technical, production, customer, compliance, and financial rules.  In healthcare, there are even more rule categories on the clinical side of services.  Without a detailed understanding of applicable rules and immediate access to them, it is difficult to look at change and anticipate impact.  

However, what we should do with rules is a matter of opinion.  The same is true in determining what we need to do.  The fact is that both considerations are often debatable.  Today, I find that rules are often one of the orphans of the modern IT and business operation activities.  Both IT and the business seem to have divided business transformation and IT solution development and in many ways are recreating the divide of the past 50 years.

The problem is that many teams really don’t look closely into the rules in a business or IT operation and ask the probing fundamental questions.  These include:

1.    Is the procedure manual up to date?  How can we bring it up to date?
2.    Do we really know all the rules that guide the work or the creation of IT support?
3.    Are the company rules written down?  Have they been reviewed by business area managers?
4.    Has legal and finance reviewed the rules and vetted them?
5.    Are the rules stored in a rules library?  How are the rules organized?  Are they linked to business activity and are they easy to find in the rules library?
6.    Do we know every place in the business and every application that uses each rule?
7.    Are all compliance related rules defined and aligned to the business activity work? – Are we in compliance with all important state, federal, and international (for the countries we do business with) rules?
8.    Have we been fined for reporting violations in the past?  What did we do about that?

Why is this important?
Compliance, HR, legal, and financial rules represent laws and require that you follow them or risk being fined and maybe go out of business.  Other rules determine how things will be done and provide order out of what would be operational chaos.  The fact is that rules are the logic of the company and project the beliefs and culture that executive management wants to infuse into the workforce.

In the context of this column, rules direct how all work is done and how all decisions are made.  They provide the framework for business activity and they guide workers and managers down a specific path in interacting with customers, building product, and running the business.

The simple fact is that without rules, even if they are not written, everyone in any business would be able to do their work in whatever way they thought right.  Chaos would reign and the company could not compete.  So why are rules important?  They simply guide all work and compliance with appropriate laws.  They keep you in business.

So who owns rules?

Who is responsible for finding them, defining them, and then both managing them and changes to them?  Not a small task.  There are thousands of rules in any mid-sized company and a lot more in a large company.  There are, however, no standards or norms for rule ownership that I am aware of.

There is also seldom anyone who has the authority to, or the responsibility to, collect, vet, index, and store rules.  This is one of the big problems that hampers effective and efficient business operation and slows any type of business improvement or transformation.

But the fact that there are rules everywhere and that there are business activity rules, decision rules, compliance rules, HR rules, finance rules, legal rules, social rules, policy rules, technology rules, data rules and on and on, makes finding, updating, and controlling their use a difficult task.  So who is responsible for rules?  This takes commitment from a person like the COO or the CIO and it must be considered to be a strategic necessity.  If not, it will not be funded.
The fact is that rules are a company asset!  

Rules allow the company to run with some consistency and efficiency – they help make certain work get done the right way.  They support strategy and compliance with laws.  They are the combined intelligent evolution of the company and how it works – gathered over all the years that the company has been in business.  They are one of the big things that provide any company with a competitive edge.

The fact is that whoever can change the fastest with the lowest risk will have a real advantage.  Those who can include access to all relevant information for these rapid changes will have an even greater advantage.  Arguably an advantage that combines rapid improvements to both effectiveness and efficiency offers a timing and cost of change advantage, and builds flexibility into the operation.

Because a company’s rules define and support this competitive differentiation, they should be considered to be undiscovered company assets.  Many will represent trade secrets and some may be based on patents and proprietary thought leadership.  All of which are company assets.

Formal rule definitions are also important in operations and business interruption – Disaster and Recovery.  If they are not known and if known but not formal, a remote hot site for Disaster Recovery is not really much use in many companies.  The computers will work in the hot site, but operations will be hurt.

Note:  A Disaster Recovery hot site is a remote location that has fully operational computers and work space running 365 days a year.

A looming catastrophe

Companies are about to lose many of their senior workers due to aging.  Without a clearly defined set of integrated rules that can be easily found we can expect the millennials who replace these workers to make procedure and execution errors – the infamous human errors that people are writing about. It is easy to predict serious competitive problems for companies that do not take the time or make the investment to create this foundation for understanding the business and how it functions.  This is not only a business problem.  It is also an IT problem, a manufacturing problem, and a problem in every corner of the business.

Tight budgets have caused cutbacks in the way BPM and BPMS groups look at creating solutions and in the move to integrating components into end to end processes for modernization.  But the market is opening and competition is heating up.  Given the changes in technology, business management, and the approaches to business streamlining, it is clear that some will leverage this emerging technology and some will not.  However, for those that do, change will have removed a major anchor that is slowing the company’s ability to adjust and evolve.  

The purpose of this column is to encourage BPM practitioners to increase their emphasis on identifying and defining business rules and in applying the understanding this discovery process will provide to looking at what rules and work are really necessary to start with.  From that point the traditional look at efficiency can provide even better results.

SOURCE: processexcellencenetwork

Business Process Management Implementation - the ultimate quick-fire Checklist

Business process management (BPM) aims to improve performance by optimising corporate practices and procedures.

Business processes are as diverse as the companies that implement them, so it’s difficult to find a one size fits all model. Added to this hodgepodge is the internal politics that threaten successful implementation of BPM. Opposition to cultural change can quickly turn BPM into an unwieldy beast. Gartner predicts that organisational politics will prevent at least one-third of BPM efforts in 2016.

Successful BPM can be achieved if you take the process bull by the horns. Be the master of the BPM arena by breaking down the method into these three digestible chunks:

1. Analysis and Design

You first need to know where you are before you can decide where you’re headed. Nailing this stage will go a long way in shaping what technical and business resources are needed to get things right. Do the following in this phase:

• Decide who needs to be involved – list all the skills you can think of and match them to the person.
• Hold a kick-off meeting – clarify roles and responsibilities.
• Identify gaps in knowledge and organise the relevant training.
• Establish the project scope – define the limits, considering the budget and time.
• Prepare the project plan – this includes the communication, change management, governance and training plan.
• Start process mapping – suppliers, inputs, processes, outputs and customers (SIPOC) diagram will be useful here.
• Identify challenges – what’s going wrong with the existing process?
• Define an improved process – what needs to be removed, added, merged or automated?
• Explain the structure for standardisation – how to name, categorise and model data.
• Create business process rules – these include schedules, escalations and notifications.
• Measure success criteria – what are your key performance indicators (KPIs)?
• Describe the user experience – logins, views, navigation and access levels belong here.
• Explain the reporting structure – choose the software and design the dashboard.
• Outline the system requirements – consider issues like the number of environments required and system integration.
• Map the data migration process – what data will be moved and how it will be transferred.

2. Program Management

This is divided into two areas – people and projects. Without the right hands on deck, the BPM implementation will be dead in the water.

Add the following to your BPM crew to help ensure plain sailing:

• Process owners are responsible for ensuring the business needs are met.
• Business analysts are the bridge between IT and business. They carry out process mapping, analysis and redesign.
• Process designers plan the technical parts of the process. They work out how the new process will fit within existing systems.
• Process developers have the job of designing new interfaces and database properties.
• Project managers run the daily aspect of the BPM implementation. Risk and issue tracking and resource planning are some of their tasks.
• Program managers are needed if the PBM project involves multiple organisations or a very large organisation. They choose priorities and make sure best practice is followed.
• Subject matter experts take part in the design and testing of the new processes and systems.

Now that you have the right people on board, add these elements to the BPM mix:

• A work breakdown structure which will form part of the project plan. 
• Resource management to account for absences and people leaving the organisation.
• Environment preparation so it should be ‘all systems go’ for deployment and integration.
• Change management processes help to maintain success after execution.
• Communication plans have details of what information is needed, where it’ll be kept and updated and who’s responsible for document control.
• Communication tools can include SharePoint, the intranet and newsletters.
• Lessons learnt logs to capture what went wrong and how it was fixed.
• Policy update documents show changes to policies and reflect the new processes.
• Testing schedules to include what will be tested, by whom and when.

3. Training

Implementing a BPM process is just the beginning. The business must be educated on the best ways to use, monitor and improve the processes.

These aspects will make your training more successful:

• Spell out the training objectives.
• Identify what training is specific to which group.
• Give every opportunity for training attendees to give feedback.
• Involve trainees early by asking them about their expectations at the start of the session.
• Make the training as relevant as possible by using real life examples.
• Make it clear what impact the new processes will have on jobs.

The perils surrounding BPM implementation can be lessened if you develop a good foundation. Ensure that you have the gone through these steps at a minimum.

The key is to remember that all successful projects involve getting the support from the right people. This is even more important with BPM. Save yourself a lot of stress by trying to get the right people on your side. You probably won’t win them all but the more you have for the BPM implementation, the higher the likely success rate.

SOURCE: DueDil

Can you use Agile and BPM together to solve business issues?

The perfect business process management system (BPMS) hasn’t been invented. Perhaps it never will be. However, that hasn’t stopped countless attempts to create the next wave of BPMS solutions. One of the approaches getting attention today is the combination of Agile development methodologies with business process management. It may not be a match made in heaven, but it seems to be producing results.

Since it burst on the scene in the early 2000’s, the desire to utilize Agile techniques in many aspects of businesses has taken off. You’ll hear about Agile manufacturing and Agile marketing and other seemingly misused commingling of the word “Agile.” However, the place where Agile software development is attributed with getting its start is summarized in the Agile Manifesto:  

• Individuals and interactions over processes and tools;
• Working software over comprehensive documentation;
• Customer collaboration over contract negotiation;
• Responding to change over following a plan.

Process Management Evolution

The idea that business process management lives in a silo is false. BPM has continued to grow and change with the business. BPM systems have continued to adopt and adapt to modern technologies. It’s in this way that Agile and BPM have and can come together.

BPM and Agile Together

There is a logical connection point where Agile development and business process management ideals can come together. BPM is all about the rules, follow through, dealing with exceptions, and back to more rules. This is the way business process management professionals think. This is how they are taught.

Of course, BPM has morphed and changed over the years to include more complex flows, including routing, re-routing, wait states, extremely complex rules, recursion and recursive processes, and a plethora of ways to included process iterations. All in an effort to insure the process can be documented… because a documented process can be followed.

Agile development runs almost 100% counter to this mentality. Agile values the individual over the process and prefers that something works versus something being documented. Agile prefers the human element to the business element. And, Agile allows for change instead of taking the planned path.

This last point is what may be the saving grace where Agile and BPM can come together. Since Agile values the human element and BPM has traditionally focused on the process over the people there is a logical connection point here. BPM systems are morphing to allow for ad hoc routing and exception handling. Some of these capabilities are the result of customer demands for a more flexible BPMS and others are from advances in computer processing, such as the increase in access and use of machine learning.

The implication is that there might be areas where Agile and BPM shouldn’t be used together. If you look to the “rules” of Agile development, they run counter to what traditionally has been considered the domain of business process management. Advanced computer processing and more powerful mobile platforms have allowed for the development of low-code solution platforms that put the power of Agile Development in the hands of the people that know the processes best, while allowing the IT department to provide guardrails to insure data and process governance.

Where Agile Might Be Heading

Now, it’s all about lean processes and the minimum viable product (the MVP), as espoused by Eric Ries in his seminal work in his book, The Lean Startup.

MVP thinking – In 2011, a book was released by Eric Ries. He espoused a model of thinking that was common in startups, but had not taken off in the corporate world yet: to develop a minimum viable product (MVP) with the highest return on investment versus risk. To do this, a minimum viable product only has the core capabilities to allow it to be deployed and nothing more. The idea behind MVP thinking is to allow for rapid development and iteration and not get bogged down in the minutiae of a traditional product development lifecycle.

In the future, I expect to see more thinking around designing, developing and deploying BPM systems around the concept of holocracy. While it may not make sense that a BPM system can be self-governing, that is exactly what can happen in an Agile development environment.

Holocratic thinking – The concept came to the forefront recently because the CEO of Zappos, Tony Hsieh, committed his company to adopt a new corporate structure: holocracy. The simplest way to describe a holocracy is that there are no more traditional bosses. Holocracy changes how an organization is structured, how decisions are made, and how power is distributed.

In the meantime, it is quite possible and useful to continue to think in terms of Agile computing to create and deploy both simple routing solutions as well as mission-critical BPMS offerings. The methodology has proven itself to be adaptable to multiple business models as well as flexible enough to change when the business changes. I expect we will continue to see Agile BPM solutions for the next few years. However, I also expect we will continue to see development on lean and holocracy-oriented BPMS offerings. Because as the post stated at the beginning … the perfect business process management system (BPMS) hasn’t been invented.

SOURCE: BPM Leader

Top 10 most important Business Process Management (BPM) capabilities

Whether you’re just getting started in Business Process Management (BPM) or have been doing it for a while, making sure that staff have the right combination of skills and tools is critical to success. So what are the common characteristics of companies that do BPM well? Contributor Janne Ohtonen looks at the top 10 capabilities.  I have been doing scientific research on business process management capabilities. Improving BPM Capabilities (BPMC) ensures more likely success in business process management initiatives built through people, process and technology aspects. The research has lead me to conduct expert interviews, surveys and case studies with three international companies over last two years. Through that research, I’ve identified ten of what I consider to be the most important BPM Capabilities organizations should have.  Here is BPM’s top 10 list in order of importance:

What are the key capabilities you need to be successful in BPM?

#1: Co-workers have confidence and trust in each other

The employees of an organization implement processes. Those employees need to be able to work well together and have trust in each other. Otherwise, employees will have to check what others have done and they are not willing to share their load with others so easily.

#2: There is open communication between employees and managers

Open communication between management and employees is crucial. Employees need strong but fair leadership, which removes obstacles from their way while executing the processes. If there is no open communication, then problems tend to be hidden and they hinder smooth operation of processes. Managers’ job is to serve the employees.

#3: Managers share vision and information with employees

Employees need to know which direction the organization is heading. Vision, mission and strategy cannot be just fluffy words with a lots of management talk behind it. People need to feel connected to the vision and managers need to be able to make the vision to come alive for the employees. Also, sharing information is very important, so that employees do not have to second-guess what is going on.

#4: The organization is able to respond to changes in markets quickly

The business world today is very turbulent. Customer requirements and expectations have evolved significantly over the last decade. But for some reason, many organizations still treat customers as they have always done. It is important to be able to respond to changes in markets quickly and that comes from aligning your processes to successful customer outcomes (SCO) as well as implementing adaptive process management.

#5: Senior management has confidence and trust in you and your managers

Senior management’s support is very important. Many companies have problems both between employees and middle management as well as between the middle and top management. Senior (or top) managers need to be able to trust their middle management and employees, so that the atmosphere stays open and creative. Also, the board of directors should have an open mind towards ideas coming from lower levels.

#6: There are efficient communication channels for transferring information

Nowadays, there is so much information that it is overflowing in people’s head. People use mobile phones, LinkedIn, Facebook, Twitter, blogs and many other mediums to acquire information. The communication inside the organization (and with the customer) can get lost in that jungle. People need to have the right and effective ways to communicate with each other (for example only one intranet website and instant messaging system).

#7: The organization has appointed people responsible for processes

Processes need to be identified and they need to have responsible people appointed. It is job of those people to make sure that the processes are running smoothly and if there are ways to improve them. It is easier for others send ideas and ask directions from a responsible process owner.

#8: The organization extensively uses information systems

Information systems are everywhere. Too often those information systems are not used extensively or cleverly. Legacy information systems may also hinder BPM initiatives. The IT strategy should be aligned with the BPM strategy so that the technology is used to optimize and automate anything that is worth automating.

#9: No one has to worry about losing his or her job because of process changes

Security is important for people. No one wants to improve and change processes if the first discussion is that who is going to get fired. There is no need for that. After using BPM you can transfer those people who are not doing productive work to other phases or process where their contribution is more meaningful. Nobody wants to do the dumb stuff, so giving your employees a good reason to do something cleverer they will gladly take it.

#10: Managers support changes in processes

Managers need to be on top of changing processes. Employees may have good ideas on how to improve processes, but have you actually asked them? And how do you handle those situations when they give suggestions? Do you listen to them and evaluate if there’s something to do, or do you just disregard them? Try to create an organizational culture, which fosters change in a positive way.

You can evaluate how these capabilities are in your organization and then make a roadmap for improving them. Each of these capabilities contributes to success in business process management initiatives and if they are not on an adequate level, you may face problems. If you are not sure on what level your capabilities are on, then you can do a BPMC (BPM Capabilities) research, which will use survey and interview methods to find out the current situation. That information can then be translated into a change roadmap, which will lead to increased BPM capabilities over time.

SOURCE: processexcellencenetwork