Having gone through this process (no pun intended) many times with many organizations, I’ve come up with 5 simple questions that help organizations determine what processes have automation potential and the possibility of offering high value results.  Here it goes:

• Do you have any  “paper heavy” processes? Is there a paper form that gets routed to different process participants as part of the process?

• Do your process workers waste time looking for forms or documents they need to complete a specific step?

• Does the process require manual duplication of data? Where maybe an email address has to be manually copied from one system to another?

• Do your processes “hang” because one of the process workers didn’t receive an email that tells them to proceed with the next step?

• Are there other “routine” tasks that are very time consuming or can halt the process in its tracks if the task owner goes on holiday or simply forgets  one day?

If you can answer “yes” to one or more of the above questions, you are looking at a process with automation potential. If you’re still not 100% sure whether a process is a good fit for automation or you want more time to  figure out the impact of such a “yes” then it’s time to  speak to the people who perform the process day in and day out.

But beware, these process owners might be comfortable with the status-quo, in fact they might find what they do today is the ideal process. It could be that many of them have already created their own workarounds to avoid potential process problems. Either way, you should gather these details first hand so you can create the perfect automation scenario that reduces error rates and significantly decreases process cycle times. Would you agree?

The post 5 Questions to Ask Before You Automate Your Business Processes appeared first on Reality Check.

Let’s start with the age old question of, what’s required to get IT and the business aligned? And equally important, how do we keep them aligned beyond the first  meeting? It’s not as simple as asking the  business to describe their requirements as a process model. Although process models are a good start and an important  approach to build on, I believe we can get much closer to an approach that business and IT can follow together.

Here is the recipe I have in mind:

1. Tools alone are not sufficient enough for successful business / IT alignment and good project results. Solid project management and communication structures, together with a good methodology, are crucial if an organization hopes to achieve good results with Business Process Management.

•  Business people need a way to capture and document processes with all the elements important to them. The tool that supports this activity has to be usable by non-developers.

2. Processes that have been created by the business need to be communicated to IT in a way that they can use the model as a starting point for the technical implementation. Without having to re-model the process from scratch. So you need a model transition from a process design tool to a full-fledged developer environment without media breaks due to different model formats and such.

3. In the course of the technical implementation of a process, the model always gets changed (i.e., to illustrate exception handling, task locking, etc.). Now IT needs a mechanism to communicate these model changes back to the business.  Why? Because the business needs to be able to understand if the original intent of the process logic is still represented in the technical model.

4. Next you need a way of comparing the technical model to the original model and also a mechanism that allows the business user to approve or reject any changes in the technical model. This approval / rejection mechanism also implies that we need the ability to go back and forth iteratively between the line of business and IT during the process implementation phase until the result satisfies both sides.

Having such an iterative approach that works through bi-directional communication between the business and IT means that all subsequent change requests can be handled in a structured way. If the business has new ideas a few months later, the above mechanism would allow for transparent collaboration. Also, if the IT infrastructure changes these changes can be communicated back to the process owner on the business side.

5. For all of the above, it is important to route and track interactions between “the business guys” and “the IT guys”. Email notifications for all involved parties and task tracking of what needs to happen next with the process model will ensure delays due to a lack of transparency don’t become a problem.

6. Last but not least, the tools should provide transparency between the process lifecycle and the lifecycle of services, as well as the data model that feeds processes. This might not be obvious to everyone immediately, but trying to manage dependencies between processes and the underlying service landscape can become a huge challenge very quickly if you don’t have a good solution in place.

Do you think these 6 steps could help better align IT and the business in their quest to communicate the right requirements and have a successful BPM implementation?

The post It’s About More Than Just Getting the Requirements Right appeared first on Reality Check.