BPM.com
Got the following suggested post from Forum contributor Michal Rykiert.  While we've covered the Cloud quite extensively before, it is always good to be reminded of the basics.  It is below:
 
4 Things to Consider Before Moving BPM to Cloud
 
By Michal Rykiert, WEBCON
 
Cloud is becoming more and more popular worldwide. Some even say it is currently fashionable to have it. Naturally, cloud arrived also at BPM world. Although marketers and salesmen would want us to use cloud right away, it is always good to consider certain solutions individually and independently.
 
The advantages of cloud BPM are well known and among them most commonly repeated are: low TCO, fast implementation and  easy maintenance. I think there’s no need for further comment in this area, as there are already dozens of articles about that on the Internet.
 
I’d like to point out several factors that are worth considering before making a decision whether to move BPM(S) to cloud or not. Please note I’ll be referring to ‘cloud’ as to all infrastructures and solutions offered by external providers.
 
1.       Integration –in most cases BPM system is not the first IT solution in a company, but usually an another one. Apart from optimizing/automating business processes, it’s task is also to integrate back office processes, that are handled by other systems. For those companies which already have some IT solutions implemented, whether on premises or in cloud, an integration may be a considerable obstacle. Making two separate systems work together (let’s say ERP and BPM) requires to have as good communication as possible. Only that ensures optimal outcome, especially when you consider the fact that usually BPMS is utilized by most, or even all organization’s employees. Using different systems in different clouds, will put you in the situation when any kind of integration is significantly more difficult.
 
Additionally, according to Oracle’s report ‘Cloud for Business Managers: the Good, the Bad and the Ugly’: ‘75% [of companies] say their ability to innovate using their cloud apps has been hindered and the main hindrance is a lack of integration (53%)’. That being said, research and deep consideration of possible outcomes (of implementation BPM in cloud) is necessary.
 
2.       Availability – my experience shows that sooner or later BPM suite becomes critical to most organizations that implemented it. It usually takes no more than 1-2 years. That being said, what if server’s motherboard goes down? How to handle situations like that? When you have an infrastructure on premise, you’ll be able to go to a store ‘around a corner’, buy a new one and migrate ad hoc. It may sound crazy, but life shows it happens!
 
When it comes to cloud service, you have no influence on how long repairs would take. Off course you can trust slogans such as “24/7 access”, offered by vendors of cloud based hosting services, but always check the actual policies and agreements you sign. The point is, not to stumble on situation when nobody in your organization cannot do their job and your only redress for a downtime, is a discount for additional service...
 
3.       Efficiency – when it comes to more complex and complicated business processes, efficiency and responsiveness might also be an issue. Recent research shows that not every cloud vendor and not every cloud service will guarantee the performance you may want to achieve. Therefore, before you move your BPM to cloud, conduct necessary tests to be sure you choice is right. Naturally, cloud also requires an investment in very high speed internet connection, especially when amount of end-users and interchanged data is considerable.
 
4.       Security – I think it is safe to assume that security level in cloud is equal or even higher than on-premise infrastructure. It applies both to IT (firewalls) as well as to physical protection, like e.g. fire suppression for servers. However, big companies and data centers are more likely to be attacked by hackers (I’m sure you’ve seen recent news). An infrastructure offered to thousands of clients, is more “attractive”, than a small, privately owned sever. It reminds me the famous quote: ‘With great power comes great responsibility’, and the reality shows sometimes it’s hard to live up to certain expectations.
 
Cloud BPM will be particularly useful for those companies which already moved their other solutions to cloud. One of the biggest advantages it offers, is that organizations can try whether certain solution works out for them or not. However, who has ever heard that correctly implemented BPM(S) that didn’t bring return on investment? :)
 
Ultimately, the question is: ‘What do we really need and what is more important for us?’ For now, there’s no better solution in general. Both cloud and on premise solutions have their pros and cons. The thing is not to follow hype and marketing slogans and evaluate solutions according to current situation and business strategy. Then choose the one that fits better.

It’s been my experience that running a BPM project requires a delicate balance between high level business modeling and innovation, highly organized methodology planning, and a strong focus in the relevant technologies (IBM BPM, Pega, Oracle, etc).

By and large, my customers/champions don’t really care about the last two, unless they have a direct impact on the first. I’ve been lucky enough to work with mostly fortune 100 companies over the last 10 years in the BPM space, and their vision often transcends technology.

The BPM market, that is.

Everybody's got an opinion.

Earlier this year, in a study apparently sponsored by my neighbors at Kofax, Forrester Research predicted that BPM will produce $7.6 billion annually by 2016, up from $4.4 billion last year. Pretty much on the same page, though perhaps a tad less optimistic, Wintergreen Research predicts a $7 billion market by 2018. IDC declines to publish their BPM-specific estimates (unless you buy their research), although they have said that the combined BPM and middleware market is on the order of $18 billion (in an incredible coincidence, Magic Johnson and I combined for 18 points per game in 1985).

And then there's my friend Theo Priestly over at Software AG, who may or may not know the answer, but isn't saying.

It's tempting to write off forecasts. Most of us have heard the quote attributed (probably incorrectly) to Thomas Watson, founder of IBM, in 1943. He is supposed to have said, "I think there is a world market for maybe five computers"—a prediction that, regardless of who actually made it, rather missed the mark.

But what's the actual source of confusion here: the size of the market, or the product that's being presented to that market? No doubt there really is a pretty limited audience for a computer that does calculations at the speed of a third grader, occupies the square footage of a soccer pitch, and requires frequent vacuum tube maintenance. As long as that's the technology we're talking about, you can't really fault the single-digit market estimate.

The failure was to imagine what a computer might be and do as technology advanced. 

BPM predictions, I believe, suffer from the same failure of imagination. Sure, we can look ahead a bit and make some educated guesses. Having conquered the back-office processes for which most companies originally adopted it, BPM will spread outward to customers, partners, and suppliers. BPM-based processes will be driven less by flowcharts and more by time, goals, and events. Case management will take a greater (or lesser) role, eventually supplanting (or ending up as just one of many implementation varieties of) BPM.

Those are all interesting trends, and they're all important. But they assume pretty much the same market drivers and the same thinking about BPM that we have today. I'd argue there's more to BPM's future... and I'll do just that, in my next post.

In the meantime: do you think there's an explosive trend that will drive BPM to unexpected success in the future? Plenty of space in the comments section below to share your thoughts.

a1sx2_Thumbnail1_Facilitator-2013-09-07-at-12.02.56-PM.pngYes, Business Process Improvement Facilitators need to know group process skills, but that is not all. Four categories of skills are listed below. (Note Part 1 of this blog covered what a BPI Facilitator does, why they are needed in addition to the Project Lead, and what responsibilities they have and don’t have in a BPI Project.)

General Facilitation Skills

  • Guiding group sessions with departmental, cross-functional, or external groups
  • Interactions and presentation to senior management
  • Conducting face to face and virtual meetings
  • Planning, conducting, and following up for meetings
  • Managing group dynamics
  • Managing the process, and staying out of the content
  • Staying neutral, while listening, building trust
  • Moving the group toward the meeting objective

BPM Methodology Skills

  • Building a charter
  • Process Modeling with large groups
  • Building process diagrams with software tools
  • Using techniques for process analysis, and process design
  • Identifying and gathering data
  • IT collaboration and coordination
  • Which BPM tools and techniques to use and when
  • Using a shared repository
  • How data integrity and data management is important in the process
  • Where integration with other applications is needed

Interpersonal Skills

  • How to keep the project on track with the Project Lead
  • How to assist in change management

Political Skills

  • Identifying red flags in the BPI effort and addressing them with the Project Lead and Process Owner
  • How to work with the culture
  • How management is important to the process and how to engage them
  • Where integration with other divisions/functions is needed

Tips for the BPI Team Facilitator

For Building the Charter

  • The Team Facilitator and Project Lead should be talking with the Process Owner, and if possible the Executive Sponsor.
  • Provide a completed template example ahead of time.
  • Plan for 60-90 minutes and get it done in that time.
  • Follow the template sections during the charter.
  • Don’t let the Process Owner talk about challenges for more than 5-10 minutes
  • Don’t let the Project Lead get into the weeds when doing the high level map.

For Doing Current State Process Diagrams

  • Start with a single instance (use case) of the current process and map that. Doing multiple instances at one time creates spaghetti diagrams.
  • Use I-4 Lists as a parking lot to stay on track
  • Keep asking “What happened next?” to help the team stick to the instance.
  • Get everyone engaged- contributing to the swim lane model, or adding to the parking lot I-4 Lists.
  • The purpose is to finish the model (in 2 hours or less) not to get it perfect.

For Selecting Which Analytical Techniques to Use

  • Do the four required techniques (Read my blog for more details, We’re Done Process Modeling. Next is Optimization –WRONG)
  • Then see if other techniques are needed based on the Process Owner’s Improvement targets.
  • Get quantitative data and use it.
  • Build a Visual Analysis Model to bring the analytics to life. Process Owners and Executive Sponsors love them!

For Doing Facilitation in a Virtual Environment

  • You must share documents on screen so everyone can see them.
  • Build documents on screen as well.
  • Allow a bit more time for the work, and keep the total session to 2-3 hours maximum.
  • Do a roll call of participants to start.
  • Use chat to get responses from multiple participants.
  • Participants should tell the group if they are leaving the meeting for a few minutes.
  • Call on people to make sure everyone participates.
  • Have roles for small groups to present work or do work offline.

Want to learn more about the Team Facilitator role and all the roles in a BPI project, as well as what BPM Methodology will make the project successful? Register for my online workshop, Analyzing and Optimizing BPM Processes, Nov. 20 and 21, 2013 or Starting and Organizing a BPM Project, February 2014.

BPM FacilitatorFor sure. For without a Facilitator for a business process improvement (BPI) project, the project is likely to

  • Take considerably longer
  • Not stay focused on the goal and instead go off on tangents
  • Be controlled by the project manager
  • Miss input from key stakeholders
  • And more

Yes, a Facilitator is needed for a BPM improvement project. I call it the Team Facilitator. The Team Facilitator is one of the four key leadership roles in a BPI project. Each of these roles is shown below with short descriptions.

BPM Leadership Roles

This blog concentrates on the Team Facilitator role. The other roles are the topics of former blogs, such as Project Managers and Process Managers—Many Similarities But a Different Focus or Getting Started with BPM: Find the Right Process Owner.

What Does the Team Facilitator Do?

The Team Facilitator knows the BPM methodology and runs the meetings using the BPM tools. He has good group process skills and neutrally facilitates sessions and meetings with the team, making sure that agenda objectives are accomplished, time is wisely used, and team members all participate. The Team Facilitator does not need to know anything about the process. Do not choose someone who works in the process; it can be someone in the same department or unit, but not someone who would have any desire to influence the solution in a particular way. Instead choose someone with good facilitation skills and BPM knowledge.

Below is a description of the Team Facilitator role with criteria for selection, and key responsibilities in the different phases of a BPI project.

Team Facilitator

Criteria for the Team Facilitator

  • Experienced in both process improvement methods and group facilitation
  • May or may not be a member of the process being analyzed

Responsibilities

Initiation and Ongoing Work during the following phases: Chartering and Resourcing; Process Discovery, Process Analysis; Process Design

Business Process Analysis

  • Assists the team in the development of the project scope and quantifying project objectives
  • Assures the quality of the business process analysis methodology
  • Helps the team select tools for the process improvement modeling, analysis, and redesign
  • Moves the team toward the improvement targets using the BPM methodology.

Group Facilitation

  • Facilitates weekly working team meetings and team sessions in the daylong workshops.
  • Raises issues and concerns with the Project Lead and Process Owner
  • Ensures that all team members’ points of view are heard.
  • Is not responsible for implementation in the organization, nor resolution of interpersonal ‘people’ problems.
  • Assists the team in reviewing “lessons learned”

Implementation and Results Phase

  • No formal responsibilities although the Team Facilitator could choose to stay on to work with the Implementation team in a similar role.

Continuous Improvement, Sustaining Phase

  • No responsibilities

The Team Facilitator is not the same as the Project Lead. The Project Lead is a strong subject matter expert, probably a manager, is accountable for meeting the Process Owner’s goals, and will be the lead for operationalizing the improvements in the workplace. (If you want a list of all four leadership roles and their responsibilities, email me at shelleysweet@i4process.com.)

The Team Facilitator can be an internal person or an external consultant. I often come in to be the external Team Facilitator if the organization does not have someone in their organization with both group process skills and BPM methodology skills. I also get asked to do the role if the function does not want to learn BPM skills (e.g., a legal department) or if the organization does not have the bandwidth to provide an internal facilitator. An external Team Facilitator is also helpful if the BPI team is large (more than 12 people).

But my preference is to have an internal Team Facilitator. Who might that be? All of these organizational roles could be a BPI Facilitator: Business Analyst, Lean Six Sigma Practitioner, PMO Project Manager, or a Process Improvement Specialist. Each of these roles might have some skills to learn or unlearn.

Part 2 of this blog provides skills for the Team Facilitator in four areas: General Facilitation, BPM Methodology, Interpersonal, and Political. It suggests what the Business Analyst, Lean Six Sigma Practitioner, PMO Project Manager, and Process Improvement Specialist need to learn and unlearn.

Want to learn more about the Team Facilitator role and all the roles in a BPI project, as well as what BPM Methodology will make the project successful? Register for my online workshop, Analyzing and Optimizing BPM Processes, Nov. 20 and 21, 2013 or Starting and Organizing a BPM Project, February 2014.

As many of you know from my time at the ebizQ Forum, I have asked this question, What is BPM? before.  But seeing how quickly BPM changes, it seems I could ask this question every six months and get a different assortment of answers.  Not from everyone, of course, as I'm very aware that for many, a process is still a process, something businesses have been doing and refining since the beginning of time.

But seeing how the speed of enterprise IT has been accelerating, I was quite curious how this discussion was going to go.   This was mostly due to my thoughts on an earlier question I had asked the BPM Forum, which was, Is BPM at a Unique Point in its History, or is This Just Another Step in BPM's Long Evolution?  There are many arguments you could make that BPM is just on a continuum of change, and this is just another point in the continuum   

But the one thing I don't think you can argue is the impact today of technology on business, and the fact that the era of the IT illiterate CEO is nearing an end.  That's why I think all enterprise technology is going through a tectonic shift today, and BPM (combined with mobile, social, and big data) will be more valuable to a company than ever.

So the question I asked the Forum was: 

What is BPM?

Right off the bat, Theo Priestley kicked off the discussion with: Might be easier to define what BPM is not. 

I was worried that this was the direction the discussion was going to take.  I had asked for a concise answer, and now I was wondering if a concise answer on BPM was even possible. 

Ashish Bhagwat added to Theo's response: It's almost a way of life for doing business right... combined with functions! 

Emiel Kelly agreed with Theo, saying: Processes are daily business, so everything companies do to execute and manage those processes to make them do what they promise is BPM.

All certainly correct so far.  But still, with all the brainpower we have in the Forum, I thought there must be some kind of actual definition, some kind of consensus we might be able to reach.

Patrick Lujan gave the quick and concise: Automation, integration, continuous process improvement. 

Ashish Bhagwat followed with:

A Management Practice for organizations to align their resources (people, information, systems), internal as well as external, in a systematic and continuous manner, in order to achieve adaptive and responsive business operations to deliver customer value. In essence, BPM is a strategic competency for enterprise performance and agility. 

Then he concluded with: Leave out any part of it and it could mean anything else, not BPM. 

Kevin Parker chimed in with a real-world view: For my customers it starts with Basic Process Management and leads to Big Process Management and ends up being Business Process Management. 

The real world was also echoed by David Chassels with: BPM supporting technology ready to deliver Enterprise Adaptive Applications empowering people reflecting the real world of work  

Dr. Alexander Samarian broke it down for various layers of a company. The one I found of most interest was: project managers: a way to speak the same language within the project.

I think this is an important point, as in our love of the latest gadgets and apps in IT, one thing that is often overlooked with BPM is management, and one of the key parts of management is communication.

Michael Poulin chimed in with: BPM = be purpose minded!

I thought that was good, and catchy, but perhaps a bit difficult to implement.  Keith Swenson wrote the following excellent breakdown: The practice of developing, running, performance measuring, and simulating business processes to effect the continued improvement of those processes.

Scott Francis went right after our insular IT bubble with the thought that too many of these definitions were too IT centric, writing: BPM is about managing business processes, and there are lots of "kinds" of business processes out there.

He followed with: I know it is frustrating to some to have a term not have hard boundaries, but isn't that true everywhere in technology. 

So we're back to BPM being almost too big to define, except with a certainty that it is about managing business processes.  

Sharif Aboulnaga finished the discussion with an excellent additional point, saying that while the definition hasn't changed: one key difference today is the availability of a variety of tools that can be used.

How Would I Define BPM?

In a way, I pretty much agree with all the definitions.  Have just returned from the iBPMS Expo, and seen all the vendor presentations and demos, it really is surprising how vast and varied the BPM market is.  So what is BPM?  It's exactly what the business at that time and process maturity level needs it to be to improve their processes.