If a company decides to move its business processes to the cloud, there are a few things that must be accomplished...
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?
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
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.
Learn how BPM and iBPM differ