Column 2

We wrapped up day 2 of Gartner BPM 2013 with David Rock, author of Your Brain at Work: Strategies for Overcoming Distraction, Regaining Focus, and Working Smarter All Day Long, on neuroleadership and the neuroscience behind organizational change. Neuroleadership deals with how leaders make decisions and solve problems, regulate emotions, collaborate, and facilitate change; this last one is of key focus in his presentation today. In order to create change effectively using a brain-based model, we need to create a “toward” state, facilitate new connections, and embed new habits. Basically, our brains are really bad at doing things that we’ve never done before, because that requires using the relatively small prefrontal cortex. In other words, if we have to think about something, it’s hard. Furthermore, if you’re threatened or stressed, the capability of the prefrontal cortex decreases, meaning that you’re only going to be able to do simple tasks that you’ve done before.

He outlined three levels of thinking: level 1 tasks are simplistic things that you’ve seen/done a lot before, such as deleting emails; level 2 tasks are things that you’ve seen less often, such as scheduling meetings; and level 3 are more complex concepts that you’ve never seen before, such as writing a business plan. When you’re really stressed, you’re pretty much only good for doing level 1 tasks, although peak performance does happen when you’re under a bit of stress.

Change requires a lot of cognitive processing, but when change is perceived as a threat, cognitive processing function decreases. Having change not be perceived as a threat requires creating a toward state, that is, something that is rewarding; since our brains are deeply social, to the point where social pain is the same as physical pain within the brain, social rewards can be used to create that toward state. The five domains of social pain/pleasure are status (your perception of your position relative to others), certainty (uncertainty arouses the limbic system), autonomy (the brain likes to predict and have a say in the future, and having some degree of choice can reduce stress levels), relatedness (categorizations of similar/different to decide who’s on your team and shares your goals), and fairness (unfairness is the same as pain, to the brain). Having higher levels of these social rewards reduces stress, and we protect against the threat of them decreasing. Change, however, can create threats in all of these domains, and you need to find offsetting rewards in one or more of these domains in order to get people thinking about the future rather than just mentally cowering in a corner.

Once a toward state is created by addressing the social reward domains, you can facilitate new connections in people’s brains by creating an environment that permits them to have insights, which starts to form those new pathways that lead to habits.

Thought-provoking talk about the neurological motivations behind change, and a good way to end the day.

Tonight, I’m off to a TIBCO customer event — as a matter of disclosure, TIBCO provided me with one of their conference passes to be here, although I paid my own travel expenses — and I’ll only have time for one or two sessions in the morning before I head for the airport.

It’s the end of day 2 at Gartner BPM 2013, and I’m in my first session with Janelle Hill — hard to believe, because usually I gravitate to her topics since she’s such an insightful speaker. She admitted that she is feeling like it’s day 4 (of a 2.5-day conference), so glad to know that I’m not the only one experiencing a bit of conference fatigue. Of course, this is my third week in a row at conferences, so that could be a contributor, too.

She’s doing one of their short “To The Point” sessions, only 30 minutes including Q&A, with a quick review of dynamic BPM and what it means to change a process in-flight. There are a number of things that can be done to change a process, ranging from small changes such as reassigning work during runtime, deleting outdated activities, or changing a monitoring dashboard; to mid-range changes such as adding new performance metrics or changing a business rule; to large changes such as major resequencing or mapping to different underlying services. This was a bit of a confusing classification, since some of these were clearly runtime changes to a specific process instance or set of instances, while others were more design-time template changes that would impact all process instances created from that point on. Regardless, it comes down to what kind of things you might want to change in your process, and what could be considered as changes that business could make directly or could collaborate on with IT. And, as soon as process changes are made by the business — or made at all — there need to be changes to the mindset: developers no longer should think about building to last, but rather building to change. This seems like just good practice for most of us, but there are still a lot of enterprise developers who don’t think about a modular service-oriented architecture, and using declarative business rules to enforce constraints.

She finished up with some must-haves for enabling dynamic BPM, which were all technology-based; this was a bit disappointing since she only briefly addressed the topic of what cultural and role/responsibility changes need to be made in order to have business people actually make the changes that the technology now allows them to make. The technology in this area is becoming fairly mature, but I find that the mindset required for IT to relinquish control of process changes, and business to assume responsibility, is the part that’s lagging. She did point out that business people are becoming more comfortable with being involved with model-driven design, but it’s way more than just knowing how to use the tools.

Barbara Fackelman and Regina DeGennaro of Pershing (a BNY Mellon subsidiary providing outsourced financial transaction services) presented at Gartner BPM 2013 about their BPM initiative, as it grew from reengineering a broken process related to federal reserve exchanges — saving them $1M/year — to a BPM center of excellence (COE). As I often recommend for growing a COE, they built their COE as an offshoot of their initial project by building a reusable BPM framework along the way, then communicated that out to the rest of the organization to undercover other potential spots for process improvement.

They started to identify sub-processes and functions that are reusable across different processes, such as document rendezvous, which impacted document scanning and handling processes as well as the downstream transaction processing. With that in their portfolio, they were able to implement additional BPM projects with significant savings, making the BPM COE a very popular service inside Pershing.

Their BPM COE reports up to the executive committee, and gets input from a number of other sources internally:

• Architecture review board
• Technology prioritization committee
• Dedicated programming groups and QA
• Process owners
• Quality management office
• BPM solutions team

They have a number of key roles in the BPM COE:

• Executive sponsor
• Process owner
• Process architect
• Product owner
• Governors
• Development leads
• Quality assurance
• Product manager
• Business analyst
• Process librarian
• Metrics master (BI architect)

With all of this in place, they have a mature COE that supports process optimization and innovation, and reviews new technologies to support the enhanced vision. Interestingly, they treat their BPM COE like any other process project: having defined and implemented it, they are constantly monitoring what/how their COE is doing, and continuously optimizing it. As an outsourcing firm, their main focus is on maximizing straight-through processes, and they can measure the performance of the COE since STP is a specific mission of the COE. As they have found, nothing succeeds like success: their STP process improvements to date have led to more collaboration and projects in other areas of their organization.

They’re using a lot of homegrown stuff, plus IBM BPM and Pega; like most big financial services organizations, they are piecing together a lot of this themselves to make it work best for them.

Jean Lastowka of Electrolux and Dave Brooks of SoftwareAG presented at Gartner BPM 2013 on process intelligence and visibility; apparently, SoftwareAG chose to include a white paper that I wrote for them in the conference handouts (which I neglected to keep), so if you’re here, check out the package.

Electrolux makes home and professional appliances — best known in North America for vacuum cleaners, but they have a much broader repertoire — and were looking to do some internal alignment in order to serve customers better. To meet this goal, they established their BPM practice a week before last year’s Gartner BPM conference, established a BPM framework, did collaborative process modeling and launched a new ERP system for their new end-customer distribution channel over the next five months, then brought on SoftwareAG’s iKnow product for process visibility in October, and launched it to their business community in November.

Their BPM efforts were initially around end-to-end process mapping of the new processes in ARIS, allowing business and IT to have a shared knowledge of the processes; they are not using a BPMS to automate processes, but the processes are encapsulated in the ERP system implementation and procedural knowledge. Unfortunately, with these new processes and a new ERP system, people were still trying to manage the processes in the old ways (including Excel), causing a lot of customer dissatisfaction. iKnow allowed them to take their process models, connect up event feeds (I assume) from the ERP system (and presumably other systems), and show real-time order tracking and KPIs overlaid on the process model. This allows for predictive analytics, providing advance warning of potential lead time failures based on inventory levels, for example, and allowed them to track order trends and provide a single view of on-hand and in-transit inventory. Best of all, the visualizations — inventory displayed on a geographic map, for example, as well as real-time alerts based on KPIs — allowed the business to more easily consume the data than in the textual format that they had previously received.

This was a good example of what BPM looks like without a BPMS automation project: collaborative process modeling, processes implemented in some other system (an ERP system, in this case), then metrics and KPIs gathered and displayed relative to the process model in a dashboard, with items requiring action flagged and pushed to the appropriate people. Bracketing the ERP system with process modeling and monitoring transforms it into a process-centric BPM initiative that drives process improvement and provides actionable information.

There are a couple of vendors in this part of the BPM technology business, providing tooling to allow you to see the processes that are running in your other (non-BPMS) systems in real-time. For many organizations, this is the only option since they have core ERP, CRM and legacy systems that run their business, but that don’t provide good visualizations nor explicit process models. Process visibility is the first step to process excellence.