This content is part of the Essential Guide: Enterprise architect's guide to optimal BPM workflow
Manage Learn to apply best practices and optimize your operations.

Master cloud BPM without bloopers: Dos, don'ts

BPM expert Steve Weissman explains why cloud BPM is not a cure-all solution for business processes.

If a company decides to move its business processes to the cloud, there are a few things that must be accomplished beforehand.

First, there's nothing magic about cloud BPM in terms of its ability to improve the efficacy of business processes. If they're crummy now, they'll be crummy in the cloud, too.

Second, there's nothing magic about the cloud in terms of its ability to improve the quality of process data. If there are mistakes, omissions or duplications now, they will be in the cloud, too.

Third, the processes aren't actually going anywhere -- they'll still be taking place in and around the organization, tended to and participated in by employees and their collaborators. The supporting software, however, will be run on somebody else's server, not the company's, and the ramifications of that are potentially quite beneficial.

This means that business processes are still the enterprise's responsibility, and there's nothing about offloading the execution engine to a cloud provider that will change this. However, there are certain dos and don'ts that can ease the transition. Here are just a few to get the project started:

DO spend the time and effort to study and improve the targeted business processes before executing them in the cloud. Companies will have to study them anyway in order to specify the resources and performance targets required by the provider, so why not get processes to run better at the same time?

DON'T migrate processes just because it's possible. Figure out which ones need the most attention -- consider aging technology, workforce expansion or reduction, cost control, etc. -- and make them the primary focus.

DO spend the time and effort to clean up data -- process rules, user directories, etc. -- before moving it. Companies do this before migrating their data to another in-house solution, so why wouldn't they do it before migrating to the cloud?

If there are mistakes, omissions or duplications now, they will be in the cloud, too.

DON'T move everything all at once – and don't move everything. Pick spots, especially at the beginning, when the initiative for success could be rigged by starting small and proving the concept to organizational doubters.

DO test the migrated processes before going live to ensure operational goals are understood and, perhaps more importantly, to ensure initial expectations are met or exceeded. Also, use non-essential or dummy data in case something goes awry.

DON'T just assume the new cloud BPM system will work with existing solutions any better than old on-premises one did. Business processes have a nasty propensity to intersect and overlap, so be sure issues related to integration and interoperability are properly addressed

More on BPM

Holistic management and BPM drivers

The impact of devices on mobile BPM

More on BPM workflow management

DO communicate with end users before, during and after the migration takes place. This should be common practice with any technology change effort a company undertakes. The more comfortable they are with any new interfaces or procedures they're given, the better off the company will be in terms of its ability to meet chartered objectives.

DON'T forget to set some measures of success before getting started, and to collect metrics of all kinds once the migration is underway. Things like system performance, process completion time, error rates and financial returns are all fair game, and it'll be impossible to know whether the migration was worth it unless the costs and benefits are accounted for. Finally, compare the result with the predetermined target.

Though listed with cloud migration in mind, these bullets are worth heeding whether or not a company plies that route. They represent best practices for migration of all sorts. With any luck, companies will already be on board with most or all of them, and will understand that there's nothing magic about cloud BPM when it comes to doing the job the way it ought to be done.

Next Steps

Learn how BPM and iBPM differ

Dig Deeper on Cloud application migration

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

Did the cloud help streamline your organization's business processes?
As the article clearly points out, the business process is independent of the cloud, so the cloud doesn't streamline. When we did a DW migration to a cloud vendor, we discovered thousands of bad records in the master. Reconciling and isolating the cause of these failures took too much time and effort, in retrospect. Since the cloud required a different DI strategy anyway, we ended up having to create a new environment anyways, with new failure modes and data quality issues. The cloud transition offered an opportunity to revisit the business process, but the cloud does not fundamentally streamline these processes, they simply push processes around, introducing new end points with their own new failure modes. In particular, private to public shifts are much harder as the security requirements are tougher.
Illuminating story; thanks for sharing it. Hope it had a happy ending!
yes we have regular sessions on maintaining existing business processes - rules and data and key metrics coming out of the process on the cloud.
I agree with the above comment by Watson7341 in that, by itself, the cloud won’t necessarily help you streamline your organization’s business processes but it does provide the opportunity to examine existing processes. I do think, however, that moving to cloud solutions can help streamline business processes by offering new and improved tools, functionality, or methods, but the same could be said for non-cloud-based technologies.
As Watson7341 states clearly, all the cloud is is a platform. Business processes and workflows are independent of the platform and deployment. A different deployment *can* alter behavior is the interaction is done primarily through a web browser, as opposed to a dedicated client server app, but that again has more to do with the coded workflow rather than the actual underlying infrastructure.