Skip to content

{ Category Archives } Gartner

Getting Business Process Value From Social Networks #GartnerBPM

For the last session of the day, I attended Carol Rozwell’s presentation on social network analysis and the impact of understanding network processes. I’ll be doing a presentation at Business Rules Forum next month on social networking and BPM, so this is especially interesting even though I’ll be covering a lot of other information besides social graphs.

She started with the (by now, I hope obvious) statement that what you don’t know about your social network can, in fact, hurt you: there are a lot of stories around about how companies have and have not made good use of their social network, and the consequences of those activities.

She posited that while business process analysis tells us about the sequence of steps, what can be eliminated and where automation can help, social network analysis tells us about the intricacies of working relationships, the complexity and variability of roles, the critical people and untapped resources, and operational effectiveness. Many of us are working very differently than we were several years ago, but this isn’t just about “digital natives” entering the workforce, it’s about the changing work environment and resources available to all of us. We’re all more connected (although many Blackberry slaves don’t necessarily see this as an advantage), more visual in terms of graphical representations and multimedia, more interactively involved in content creation, and we do more multitasking in an increasingly dynamic environment. The line between work and personal life blurs, and although some people decry this, I like it: I can go to many places in the world, meet up with someone who I met through business, and enjoy some leisure time together. I have business contacts on Facebook in additional to personal friends, and I know that many business contacts read my personal blog (especially the recent foodie posts) as well as my business blog. I don’t really have a lot to hide, so don’t have problem with that level of transparency; I’m also not afraid to turn off my phone and stop checking my email if I want to get away from it all.

Your employees are already using social media, whether you allow it within your firewall or not, so you might as well suck it up and educate them on what they can and can’t say about your company on Twitter. If you’re on the employee side, then you need to embrace the fact that you’re connected, and stop publishing those embarrassing photos of yourself on Facebook even if you’re not directly connected to your boss.

Social network classificationsShe showed a chart of social networks, with the horizontal axis ranging from emergent to engineered, and the vertical axis from interest-driven to purpose-driven. I think that she’s missing a few things here: for example, open source communities are emergent and purpose-driven, that is, at the top left of the graph, although all of her examples range roughly along the diagonal from bottom left to top right.

There are a lot of reasons for analyzing social networks, such as predicting trends and identifying new potential sources of resources, and a few different techniques for doing this:

  • Organizational network analysis (ONA), which examines the connections amongst people in groups
  • Value network analysis (VNA), which examines the relationships used to create economic value
  • Influence analysis, a type of cluster analysis that pinpoints people, associations and trends

Rozwell showed an interesting example of a company’s organizational chart, then the same players represented in an ONA. Although it’s not clear exactly what the social network is based on – presumably some sort of interpersonal interaction – it highlights issues within the company in that some people have no direct relation to their direct reports, and one person who was low in the organizational chart was a key linkage between different departments and people.

She showed an example of VNA, where the linkages between a retailer, distributor, manufacturer and contract manufacturer where shown: orders, movements of goods, and payments. This allows the exchanges of value, whether tangible or intangible, to be highlighted and analyzed.

Her influence analysis example discussed the people who monitor social media – either within a company or their PR agency – to analyze the contributors, determine which are relevant and credible, and use that to drive engagement with the social media contributors. I get a few emails per day from people who start with “I read your blog and think that you should talk to my customer about their new BPM widget”, so I know that there are a lot of these around.

There are some basic features that you look for when doing network analysis: central connectors (those people in the middle of a cluster), peripheral players (connected to only one or two others), and brokers (people who form the connection between two clusters).

There are some pretty significant differences between ONA, VNA and business process analysis, although there are some clear linkages: VNA could have a direct impact on understanding the business process flows, while ONA could help to inform the roles and responsibilities. She discussed a case study of a company that did a business process analysis and an ONA, and used the ONA on the redesigned process in order to redesign roles to reduce variability, identify roles most impacted by automation, and expose critical vendor relationships.

Determining how to measure a social network can be a challenge: one telecom company used records of voice calls, SMS and other person-to-person communications in order to develop marketing campaigns and pricing strategies. That sounds like a complete invasion of privacy to me, but we’ve come to expect that from our telecom providers.

The example of using social networks to find potential resources is something that a lot of large professional services firms are testing out: she showed an example that looked vaguely familiar where employees indicated their expertise and interests, and other employees could look for others with specific sets of skills. I know that IBM does some of this with their internal Beehive system, and I saw a presentation on this at the last Enterprise 2.0 conference.

There are also a lot of examples of how companies use social networks to engage their customers, and a “community manager” position has been created at many organizations to help manage those relationships. There are a lot of ways to do this poorly – such as blasting advertising to your community – but plenty of ways to make it work for you. Once things get rolling in such a public social network, the same sort of social network analysis techniques can be applied in order to find the key people in your social network, even if they don’t work for you, and even if they primarily take an observer role.

Tons of interesting stuff here, and I have a lot of ideas of how this impacts BPM – but you’ll have to come to Business Rules Forum to hear about that.

Fujitsu process discovery case study #GartnerBPM

I first saw Fujitsu’s process discovery offering last year, and it looked pretty useful at the time, but it didn’t have much of a track record yet. Today’s session brought forward Greg Mueller of Electro Scientific Industries (ESI), a manufacturer of photonic and laser systems for microengineering applications, to talk about their successes with it.

Basically, the Automated Process Discovery (APD) uses log files and similar artifacts from any variety of systems in order to derive a process model, analyzing frequencies of process variations, and slicing and dicing the data based on any of the contributing parameters. I’ve written a lot about why you would want to do process discovery, including some of the new research that I saw at BPM 2009 in Germany last month.

ESI wanted to reduce inventory and improve manufacturing cycle time, and needed to understand their opportunity-to-order process better in order to do that. They used APD to determine the actual process flows based on about 15 months of data from SAP and other systems, then validated those flows with the team who worked with those flows. They wanted to look at variations based on business unit and other factors to figure out what was causing some of their cycle time and inventory problems.

They assumed a relatively simple four-step process of opportunity-quote-order-shipment, possibly with 3-4 additional steps to allow revisions at each of these steps; what they actually found when they looked at about 11,500 process instances is that they had over 1,300 unique process flows. Yikes. Some of this was cycling through steps such as order change: you would expect an order to be changed, but not 120 times as they found in some of their instances. There were also loopbacks from order to quote, each of these representing wasted employee time and increased cycle time. They found that one task took an average of 58 days to complete, with a standard deviation of 68 days – again, a sign of a process out of control. They realize that they’re never going to get it down to 25 unique process flows, but they are aiming for something far lower than 1,300.

They did a lot of data slicing and analysis: by product, by region, by sales manager and many other factors. APD allows for that sort of analysis pretty easily (from what I saw last year), much like any sort of dimensional modeling that you would do in a data warehouse.

They observed that less than 20% of their opportunities followed the happy path, and the rest were taking too long, duplicating efforts, having too many rework loopbacks, and sometimes not even shipping after a great deal of up-front work.

In their process improvement phase, they established 22 projects including a number of improvement features such as automating processes to reduce repeated steps, improving entry flow to reduce time intervals, require the entry of initial data early in the process in order to reduce loopbacks and rework. Since their business runs on SAP, a lot of this was implemented there (which begs the question of who did such a crappy SAP implementation for them in the first place such that they had problems like this – seriously, insufficient required data entry at the start of an process?), and they’re able to keep extracting and analyzing the logs from there in order to see what level of improvement that they are experiencing.

After a much too short presentation by ESI, Ivar Alexander from Fujitsu gave us a demo of APD with ESI’s basic process; I’ve seen a demo before, but it’s still fascinating so see how the system correlates data and extracts the process flows, then performs detailed dimensional analysis on the data. All of this is done without having to do a lot of interviews of knowledge workers, so is non-invasive both from a people and system standpoint.

It’s important to recognize that since APD is using the system logs to generate the process flows, only process steps that have some sort of system touch-point will be recorded: purely manual process steps will not. Ultimately, although they can make big improvements to their SAP-based processes based on the analysis through APD, they will probably need to combine this with some manual analysis of off-system process steps in order to fully optimize their operations.

Dynamic BPM versus agility #GartnerBPM

Jim Sinur led a session this morning on dynamic BPM and how to deal with the demands for change. He started with the statement that dynamic BPM is more than just another type of BPM technology, it’s a requirement for a transformational advantage, and took a look at how BPM will become more dynamic in the future.

Change is driven by unexpected exceptions in processes, and patterns of these unexpected events can indicate trends in your business environment that the processes need to accommodate. Typical change cycles in IT, however, tend to be slow and steady, which doesn’t at all match either the business dynamics or the external forces that shape them. Being able to handle these spiky demands drives the requirement for more dynamism in how processes and rules are managed, and drives the requirement for the business to be able to manage these directly rather than having to engage IT for all changes.

Gartner’s definition of dynamic BPM is the ability to support process change by any role, at any time, with very low latency. Change agents include everyone from customers and business people through business and process analysts, and on to architects and developers; if the people at the business end of this spectrum aren’t allowed to make process changes, then they’ll just work around it and invent their own processes using their own tools. This isn’t just about each individual’s personal preferences for how they work, however: if knowledge workers can make changes to their processes, they will tend to make them more efficient and effective, which has enterprise benefits.

A significant part of this is the inclusion of explicit rules within processes, so that scenario-driven rule sets can detect and respond to conditions, even without the process participants having to make those changes themselves: the basis of what James Taylor was saying in his presentation this morning. What used to be monolithic lumps of code can be split into several parts, each of which has the potential to be agile: user interface is managed by portals and the web; decision points are handled by rules engines; paths of execution are managed by BPMS; and data definitions are handled in databases or XML data representations. All of those parts used to be under the control of the developers, but turning it inside out and using more agile technologies allows people to customize their UI, change their rules on a daily basis, modify their processes, and define their own data structures. Dynamic BPM isn’t just about changing process models, it spans requirements, recompilation, data binding, loading and versioning.

There was quite a bit about services composition environments and CEP that I felt didn’t really belong in a presentation on dynamic BPM: yes, you need to have services and CEP in order to build agile processes in the first place, but it seems like filler.

One brief slide on “Web 2.0”, really just a quick laundry list of enterprise social software aspects that could impact BPM, including collaborative process design and execution, but no meat. Sinur merely read the list and pointed out that there are vendors at the showcase showing some of these capabilities. That was a bit of a disappointment, considering that the term “dynamic BPM” is being used by many (including Forrester and several vendors) to describe collaborative processes that are created or modified at runtime by the user.

He finished up with some sensible advice about separating rules and other application components from the processes in order to push towards more agile processes, although not different from the message that we’ve been hearing for quite a while now.

This wasn’t a new presentation: it was mostly recycled material that I had seen in previous Gartner presentations (either at conferences or on webinars) about agile BPM using rules, services and complex event processing. There’s been some new verbiage put around it and a few new slides, but only the briefest nod to the type of user-created ad hoc collaborative processes that represent the most dynamic form of BPM.

The five dysfunctions of a team #GartnerBPM

Jeff Gibson of the Table Group gave the morning keynote based on some of the concepts in his colleague’s book, The Five Dysfunctions of a Team: A Leadership Fable.

He started with the idea that there are two requirements for a company’s success: it has to be smart (strategy, marketing, finance, technology) and it has to be healthy (minimal politics, minimal confusion, high morale, high productivity, low turnover). Although a lot of management courses are focused on the smart side, the healthy side is a multiplier of the smart side, boosting the success far beyond what you can do by being smart alone.

He then moved on to the five dysfunctions of a team:

  1. Absence of trust, specifically personal trust and exposing vulnerability to other team members. The role of the leader is to go first in order to show that it’s okay to make mistakes.
  2. Fear of conflict, which can lead to misunderstandings because people don’t speak their mind. The role of the leader is to search out conflict amongst team members, draw out the issues and wrestle with them.
  3. Lack of commitment, particularly to tough decisions. The role of the leader is to force clarity and closure on those decisions to ensure that everyone is committed to upholding them.
  4. Avoidance of accountability. The role of the leader is to confront difficult issues, such as problematic team behaviors.
  5. Inattention to results. The role of the leader is to focus on collective outcomes, not allowing a “superstar” on the team to make themselves look good to the detriment of the team result.

Usually I find these external keynotes that are unrelated to the conference subject to be so-so, but I really enjoyed this one, and could have used this advice when I was heading up a 40-person company. I’ll be checking out the book.

Advanced decisioning #GartnerBPM

I managed to get out of bed and down to the conference in time for James Taylor’s 7am presentation on advanced decisioning. If you’ve been reading here for a while, you know that I’m a big proponent of using decisioning in the context of processes, and James sums up the reasons why: it makes your processes simpler, smarter and more agile.

Simpler: If you build all of your rules and decisioning logic within your processes – essentially turning your process map into a decision tree – then your processes will very quickly become completely unreadable. Separating decisions from the process map, allowing them to become the driver for the process or available at specific points within the process, makes the process itself simpler

More agile: If you don’t put your decisioning in your processes, then you may have written it in code, either in legacy systems or in new code that you create just to support these decisions. In other words, you tried to write your own decisioning system in some format, but probably created something that’s much harder to change than if you’re using a rules management system to build your decisions. Furthermore, decisions typically change more frequently than processes; consider a process like insurance underwriting, where the basic flow rarely changes, but the rules that are applied and the decisions made at each step may change frequently due to company policy or regulatory changes. Using decision management not only allows for easier modification of the rules and decisions, it also allows these to be changed without changing the processes. This is key, since many BPMS don’t easily allow for processes that are already in progress to be easily changed: that nice graphical process modeler that they show you will make changes to the process model for process instances created after that point, but don’t impact in-flight instances. If a decision management system is called at specific points in a process, it will use the correct version of the rules and decisions at that point in time, not the point at which the process was instantiated.

Smarter: This is where analytics comes into play, with knowledge about processes fed into the decisioning in order to make better decisions in an automated fashion. Having more information about your processes increases the likelihood that you can implement straight-through processes with no human intervention. This is not just about automating decisions based on some initial data: it’s using the analytics that you continue to gather about the processes to feed into those decisions in order to constantly improve them. In other words, apply analytics to make decisions smarter and make more automated decisions.

To wrap up James’ five core principles of decisioning:

  • Identify, separate and manage decisions
  • Use business rules to define decisions
  • Analytics to make decisions smarter
  • No answer is static
  • Decision-making is a process

He then walked through the steps to apply advanced decisioning, starting with identifying and automating the current manual decisions in the process, then applying analytics to constantly optimize those decisions.

He closed with an action plan for moving to decisioning:

  • Identify your decisions
  • Adopt decisioning technology
  • Think about decisions and processes, and how those can be managed as separate entities.

Good presentation as always – well worth getting up early.

Using BPM to survive, thrive and capitalize #GartnerBPM

Last session of the day, a panel with Jim Sinur, Elise Olding and Michele Cantara on using BPM to survive, thrive and capitalize in a turbulent economy. I realize that this session has the same title as a webinar that Cantara and Janelle Hill did a while back, and there’s a lot of repeat material from that so I won’t bother to recapture it here. There’s a link to the webinar replay in that post, and I recommend checking it out if you weren’t here in Orlando today.

Off to the vendor showcase; that’s it for day 1 of the Gartner BPM summit.

Using a center of excellence to deliver BPM #GartnerBPM

Michelle Lagna of JPMorgan Chase, a Pegasystems customer, gave a presentation on their CoE as one of the solution providers sessions. Their CoE focuses on the use of BPM tools (primarily Pegasystems) to support their 30+ active systems. It was instrumental in allowing them to break down the departmental silos within the organization, establishing standard governance models, standardizing training and contributing to reusable assets.

The CoE supports all lines of business in planning and implementing BPM initiatives:

  • Creating and maintaining architectural standards
  • Centralizing and formalizing the housing and reuse of business-configurable assets
  • Promoting standard methodologies, tools and education

They use the Agile development methodology (and promote and educate on Agile across the organization), and believe that it is instrumental to their success by reducing time to market and aligning business and IT. They’ve made a gradual transition from waterfall to Agile in order to ease into the new methodology.

They’ve developed a standard engagement model (unfortunately depicted on the presentation slide in micro-print and low contrast colors):

  • Operational walkthrough and end-to-end review, including identification of process improvements and ROI
  • Impact analysis review, identifying execution gaps and automated solutions, plus IT and business sizing
  • Project initiation training, including both BPM and Agile training
  • Application profile, high level use case requirements and reusable asset review
  • Project setup and design review, including identifying assets leveraged from other projects, functionality specifications and a design compliance review
  • Environment build-out, including generating a base framework
  • Bootstrap session, which equips the project team to complete use cases on their own
  • Direct capture of objectives to elaborate use cases, design specifications and traceability matrix; this is specifically assisted by the Pega project
  • Identification of reusable assets, then harvesting those assets and making them available for reuse by other projects

The CoE is heavily involved in the early phases, but by the time that they get halfway through the project, the project team is running on their own and the CoE is just checking in occasionally to make sure that things are proceeding as planned, and to help resolve any issues. They had to make some organizational changes to ensure that the CoE is engaged at the right time and that siloed solutions are avoided.

She presented some of the key benefits provided by the CoE:

  • Common class structure for reusability
  • Library of reusable assets with tools to track usage
  • Standardized engagement model, including a “Perfect Start” training and certification stage
  • Monthly educational webcast
  • Improved release planning process (which I’ve seen listed as a key benefit of a CoE at other customers that use other BPM products)
  • Allowing for faster changes to improve business agility

The CoE has been backed by senior executive sponsors within JPMC, which has been key to its acceptance. They are run (and funded) as a shared service, so there are normally no direct chargebacks to the projects unless the CoE team is required to be onsite for an extended period of time due to a rush or urgent situation. Interestingly, the CoE is not all co-located: there are five offshore development resources that handle harvesting the reusable assets, although they are managed from an onshore resource.

Great case study, and a lot of material that is of use regardless of which BPM product that you’re using.

Hidden costs of unstructured processes #GartnerBPM

Elise Olding and Carol Rozwell kicked off the afternoon with a session on the hidden costs of unstructured processes: although a lot of focus of BPM efforts (time and money) is on structured processes, as much as 60% of an organization’s processes are unstructured – and probably also unmonitored, unmanaged, unknown and unruly.

Gartner defines unstructured processes as “work activities that are complex, nonroutine processes, predominantly executed by an individual or group highly dependent on the interpretation and judgment of the humans doing the work for their successful completion”, and notes that most business processes are made up of both structured and unstructured processes. Unstructured processes are costing organizations a lot of money in lost productivity, lack of compliance and other factors, and you can’t afford to ignore them. Although most processes aimed to meet regulatory requirements are structured, unstructured processes provide a company’s unique identity and often its competitive differentiation, as well as supporting operational activities.

In order to start managing unstructured processes, you need to get some visibility into them; start by understanding the critical path through the process. This can be a bit tricky, since as you start to map out your unstructured processes, there will be some points at which the process participant just has to wing it and make their own decisions. These are, after all, knowledge workers, and it’s not possible (or desirable) to map every possible process permutation. Instead, map the structured portions of the process, then the points at which it becomes unstructured, but don’t try to overengineer what happens in the unstructured parts. The unstructured parts can be modeled by the notification mechanism (how someone is notified that a piece of work requires attention), the information provided to the participant to allow them to complete the unstructured work, and how the outcome is recorded.

They presented a number of analysis techniques for getting to the heart of unstructured and folklore processes:

  • Observe work being done, and challenge tasks that don’t make sense. Keep asking “why”.
  • Use storytelling (“tell me what happens when…”) to uncover decision-making logic, methods and best practices: these types of narratives are not well-captured in standard process documentation.
  • Analyze the unstructured interactions between people (e.g., customers and CSRs) and extract the themes and patterns. Rozwell wrote a report “Business Narratives Supplement Traditional Data Analysis” that discusses one technique for doing this, although it wasn’t quite clear what it was from the discussion.
  • Get clarity around roles and who is the decision-maker in any given process.

There are a variety of different areas of knowledge that you need to consider when analyzing unstructured processes, from identifying what metadata is used for collaboration, to looking at alternative analysis techniques such as mind mapping and social network analysis. Understanding collaborative technologies is also key, since unstructured processes are often collaborative in nature, and make use of the participants’ social graphs.

Their final recommendations are to keep an eye on the technologies that can support unstructured processes, but not to go overboard on monitoring and managing these processes.

Navigating the BPM Wonderland #GartnerBPM

Alan Trefler lunch addressAlan Trefler of Pegasystems gave his traditional lunch address – entertaining as always, starting with a “White Rabbit” audio clip – with an Alice in Wonderland theme of how we have to chase our business goals down whatever rabbit hole that they disappear down. Continuing on the theme, he contrasted the “one pill makes you larger” end of the spectrum with monolithic applications, and the “one pill makes you small” end of point solutions, and how you need to look at something in the middle. Don’t be afraid to ask for advice (even from hookah-smoking caterpillars), watch for those delusional Mad Hatter software salespeople, and be sure to meet the needs of the Red Queen boss lady so that you don’t get your head chopped off in the process.

Trefler is a former chess champion, so it’s inevitable that he introduced an Alice-themed chess analogy when examining his recommended steps for implementing BPM:

  • Directly capture objectives, so that your BPM implementation is focused on business intents and goals.
  • Automate the programming: the computer can write code much better than human beings, which is much less expensive in the long run even if off-shoring development appears to make it cheaper up front. In other words, use a system that allows for model-driven development and zero-code (or near-zero-code) deployment.
  • Automate the work wherever steps can be automated.

I love the term that he introduced: “heritage systems”, which are just legacy systems that we like a little bit better, probably because we’ve wrapped them to allow them to be more easily integrated with other systems and processes.

Deciding on process modeling tools #GartnerBPM

Bill Rosser presented a decision framework for identifying when to use BPA (business process analysis), EA (enterprise architecture) and BPM modeling tools for modeling processes: all of them can model processes, but which should be used when?

It’s first necessary to understand why you’re modeling your processes, and the requirements for the model: these could be related to quality, project validation, process implementation, as part of a larger enterprise architecture modeling effort and many other reasons. In the land of BPM, we tend to focus on modeling for process implementation because of the heavy focus on model-driven development in BPMS, hence model within our BPMS, but many organizations have other process modeling needs that are not directly related to execution in a BPMS. Much of this goes back to EA modeling, where several levels of process modeling that occur in order to fulfill a number of different requirements: they’re all typically in one column of the EA framework (column 2 in Zachman, hence the name of this blog), but stretch across multiple rows of the framework such as conceptual, logical and implementation.

Different types and levels of process models are used for different purposes, and different tools may be used to create those models. He showed a very high-level business anchor model that shows business context, a conceptual process topology model, a logical process model showing tasks within swimlanes, and a process implementation model that looked very similar to the conceptual model but included more implementation details.

As I’ve said before, introspection breeds change, and Rosser pointed out that the act of process modeling reaps large benefits in process improvement since the process managers and participants can now see and understand the entire process (probably for the first time), and identify problem areas. This premise is what’s behind many process modeling initiatives within organizations: they don’t plan to build executable processes in a BPMS, but model their processes in order to understand and improve the manual processes.

Which type of process modeling tool to useProcess modeling tools can come in a number of different guises: BPA tools, which are about process analysis; EA tools, which are about processes in the larger architectural context; BPM tools, which are about process execution; and process discovery tools, which are about process mining. They all model processes, but they provide very different functionality around that process model, and are used for different purposes. The key problem is that there’s a lot of overlap between BPA, EA and BPM process modeling tools, making it more difficult to pick the right kind of tool for the job. EA tools often have the widest scope of modeling and analysis capabilities, but don’t do execution and tend to be more complex to use.

He finished by matching up process modeling tools with BPM maturity levels:

  • Level 1, acknowledging operational inefficiencies: simple process drawing tools, such as Visio
  • Level 2, process aware: BPA, EA and process discovery tools for consistent process analysis and definition of process measurement
  • Levels 3 and 4, process control and automation: BPMS and BAM/BI tools for execution, control, monitoring and analysis of processes
  • Levels 5 and 6, agile business structure: simulation and integrated value analysis tools for closed-loop connectivity of process outcomes to operational and strategic outcomes

He advocates using the simplest tools possible at first, creating some models and learning from the experience, then evaluating more advanced tools that cover more of the enterprise’s process modeling requirements. He also points out that you don’t have to wait until you’re at maturity level 3 to start using a BPMS; you just don’t have to use all the functionality up front.

Patterns for Business Process Implementations #GartnerBPM

Benoit Lheureux from Gartner’s Infrastructure and Architecture group gave a presentation on process implementation patterns. I think that he sees BPM as just part of SOA, and presents as such, but I’m willing to give him a pass on that.

He discussed five styles of flow management in SOA:

  1. Microflows: fine-grained services implemented via flows amongst software components. This is a process from a software development standpoint, not a business-level process: probably 3GL code snippets assembled into what we old-timers might refer to as a “subroutine”. :)
  2. Service composition: coarse-grained services implemented by assembling fine-grained flows (microflows). This may be done with a BPMS tool, but is low-level service composition rather than business processes.
  3. Straight-through process: automating business processes involving multiple services across systems, but without human intervention.
  4. Workflow: pretty much the same as STP, but with human intervention at points in the process.
  5. Semi-structured processes: a combination of structured processes with unstructured activities or collaboration.

He has some good strategic planning assumptions based on these four patterns, such as 75% of companies will use at least three different products to implement at least three different styles of flows. His primary focus, however, is on B2B, and how internal process connect to multi-enterprise processes, and the ultimate goal of shared process execution across enterprises. This led to the four B2B flow management styles:

  1. Blind document/transaction exchange: loosely-coupled, with each partner managing their own internal processes, and no visibility outside their own processes.
  2. Intelligent document/transaction exchange: visibility across the shared process to provide a shared version of the truth, such as a BAM dashboard that provides an end-to-end view of an order-to-cash process across enterprises. Although this isn’t that popular yet, it is providing significant benefits for companies that are implementing it, and Lheureux estimates that 50% of B2B relationships will include this by 2013.
  3. Multi-enterprise applications: shared execution of a process that spans the enterprises, such as vendor-managed inventory. This may be hosted by one of the partners, or may be hosted by a third-party service provider.
  4. Multi-enterprise BPMS and rules: centralized processes and rules, such as shared compliance management on a shared process. By 2013, he predicts that at least 40% of new multi-enterprise integration projects will leverage BPMS technology.

He showed a chart that I’ve seen at earlier conferences on identifying process characteristics, classifying your processes as case management, form-driven workflow, content collaboration, multiparty transactional workflow, participant-driven workflow, and optimization of network relationships based on the unit of work, process duration, degree of expertise required, exception rate, and critical milestones that progress work. Then, consider when to use BPMS technology rather than code when there are specific process characteristics such as complexity and changeability.

The final recommendations: don’t try to use the same tool to handle every type of process implementation, but be aware of which ones can be best handled by a BPMS (and by different types of BPMS) and which are best handled in code.

BPM in Times of Rapid Change #GartnerBPM

For the next couple of days, I’m at the Gartner BPM Summit in Orlando. Jim Sinur and Janelle Hill gave the opening keynote this morning on BPM in times of rapid change, starting with a view of the global economy: basically, it’s down this year, although not as bad as expected, and the leading economic indicators are starting to trend up.

Gartner did a survey of CEOs in late 2008, and found that their top priority is shifting back from cutting operating costs to increasing revenues, although only by a slim margin. The resulting message: the time to return to business growth is now, and leveraging BPM to assist growth can provide a first-mover advantage if the economy does trend up in 2010 as predicted. BPM still provides assistance in restructuring operations (including mergers and acquisitions) and cutting costs that goes along with a down economy, so you might as well leverage what you’re already using to cut costs, and start looking forward and repositioning for growth. In many cases (in my experience), improving business processes using BPM has the impact of reducing costs of the specific processes, which can either translate to reduced operational costs through reduced headcount, or increased revenues due to the increased capacity of the process to handle new business: these are just two sides of the same process improvement coin.

Going into 2010, most large enterprises have already completed their cutbacks – reduced headcounts, reduced infrastructure, renegotiated contracts and elimination of redundant technologies – but their budgets are going to be pretty flat. If you already have a BPMS in your organization, then this might mean some incremental expansion, but if you don’t, you need to look at how to justify the technology acquisition. Fortunately, that’s getting easier as the capabilities of the BPMS products expand: consider the value of process modeling (reduced redundancy and better use of people in the process) as well as process and application orchestration (automating the linkages between many existing applications) and composite application development environments (bringing together many applications into a single user view).

Focus on improving processes that defend revenue and cash without impacting customer experience, such as order-to-cash, sales processes, and customer service. Depending on your industry, this could also be the time to take some risks in order to gain that first-mover advantage: reconsider institutionalized behaviors and what you might think of as best practices, and see if there’s an innovative way to improve processes that provide a competitive edge. There should be no processes that are immune to change: challenge the status quo. I see this all the time with how companies are embracing social media in addressing customer relationships: the ones that are successful at it are those that throw away all the old ideas about how companies communicate and interact with their customers. These customer-facing processes are no longer about executing transactions, they’re about coordinating social interactions and developing social relationships.

The hot button these days is unstructured processes (which I’m sure that we’ll hear a lot more about this week), and how some new BPMS functionality allows for dynamic collaboration instead of, or within the context of, a structured process. This provides methods for gaining visibility into processes that might exist now only in email or other ad hoc methods, and likely aren’t managed well in their current state.

It’s not good enough, however, to use old-style BPMS/workflow products: you need to be considering products that have model-driven development, composite application development, process discovery and optimization, and customized dashboards for different roles and personas within a process. Otherwise, you’ll just be stuck back in the same old waterfall development methodology, and won’t achieve a lot of benefit from BPM. Interestingly, Sinur and Hill highlighted three specific products to show examples of what they consider BPMS innovation: Vitria’s composite application development, Pallas Athena’s process discovery and simulation, and Global 360’s persona-based user interfaces.

In the recession of the 1980’s, business process reengineering was a high-profile, strategic activity with top executives involved; as the recession eased, the executives’ interest in BPR waned. The same cycle will repeat now: executives are very interested right now in process improvement and BPM, but that’s not going to last when the economy starts to recover, so you may want to take advantage of their interest now and get something going.

You can track the Twitter backchannel for the Gartner BPM summit here.

Gartner webinar on using BPM to survive, thrive and capitalize

Michele Cantara and Janelle Hill hosted a webinar this morning, which will be repeated at 11am ET (I was on the 8am ET version) – not sure if that will be just the recording of this morning’s session, or if they’ll do it all over again.

Cantara started talking about the sorry state of the economy, complete with a picture of an ax-wielding executioner, and how many companies are laying off staff to attempt to balance their budgets. Their premise is that BPM can turn the ax-man into a surgeon: you’ll still have cuts, but they’re more precise and less likely to damage the core of your organization. Pretty grim start, regardless.

They show some quotes from customers, such as “the current economic climate is BPM nirvana” and “BPM is not a luxury”, pointing out that companies are recognizing that BPM can provide the means to do business more efficiently to survive the downturn, and even to grow and transform the organization by being able to outperform their competition. In other words, if a bear (market) is chasing you, you don’t have to outrun the bear, you only have to outrun the person running beside you.

Hill then took over to discuss some of the case studies of companies using BPM to avoid costs and increase the bottom line in order to survive the downturn. These are typical of the types of business cases used to justify implementing a BPMS within conservative organizations in terms of visibility and control over processes, although I found one interesting: a financial services company used process modelling in order to prove business cases, with the result that 33% of projects were not funded since they couldn’t prove their business case. Effectively, this provided a more data-driven approach to setting priorities on project funding, rather than the more common emotional and political decision-making that occurs, but through process modelling rather than automation using a BPMS.

There can be challenges to implementing BPM (as we all know so well), so she recommends a few things to ensure that your BPM efforts are successful: internal communication and education to address the cultural and political issues; establishing a center of excellence; and implementing some quick wins to give some street cred to BPM within your organization.

Cantara came back to discuss growth opportunities, rather than just survival: for organizations that are in reasonably good shape in spite of the economy, BPM can allow them to grow and gain relative market share if their competition is not able to do the same. One example was a hospital that increased surgical capacity by 20%, simply by manually modelling their processes and fixing the gaps and redundancies – like the earlier case of using modelling to set funding priorities, this project wasn’t about deploying a BPMS and automating processes, but just having a better understanding of their current processes so that they can optimize them.

In some cases, cost savings and growth opportunities are just two sides of the same coin, like a pharmaceutical company that used a BPMS to optimize their clinical trials process and grant payments process: this lowered costs per process by reducing the resources required for each, but this in turn increased capacity also allowed them to handle 2.5x more projects than before. A weaker company would have just used the cost saving opportunity to cut headcount and resource usage, but if in a stable financial position, these cost savings allow for revenue growth without headcount increases instead.

In fact, rather than two sides of a coin, cost savings and growth opportunities could be considered two points on a spectrum of benefits. If you push further along the spectrum, as Hill returned to tell us about, you start to approach business transformation, where companies gain market share by offering completely new processes that were identified or facilitated by BPM, such as a rail transport company that leveraged RFID-driven BPM to avoid derailments through early detection of overheating problems on the rail cars.

Hill finished up by reinforcing that BPM is a management discipline, not just technology, as shown by a few of their case studies that had nothing to do with automating processes with a BPMS, but really were about process modelling and optimization – the key is to tie it to corporate performance and continuous improvement, not view BPM as a one-off project. A center of excellence (or competency center, as Gartner calls it) is a necessity, as are explicit process models and metrics that can be shared between business and IT.

If you miss the later broadcast today, Gartner provides their webinars for replay. Worth the time to watch it.

Next week: Toronto, not San Diego

Yes, it’s true, I’m going to miss a North American Gartner BPM summit for the first time in, well, maybe forever. There’s two reasons for this: first and foremost, I’m 110% busy with time-critical client work right now, and a week in sunny San Diego just doesn’t fit into my calendar. Also, if you review my coverage of last fall’s summit, I’m not finding enough new material at each summit since they moved to the two/year format: I’m not learning much, and there’s not much new to write about. I believe that they’ve started to add some new material specific to BPM in a tight economy, and they had a pretty successful event in London a few weeks back, so I look forward to catching up with the material – and those of you attending – at the next one.

For all of you who have sent messages asking if we can meet up in San Diego next week, I’ll raise a glass to you from these chillier climes.

Gartner webinar: First 100 days as BP director

In keeping with other recently-installed change agents, Elise Olding of Gartner delivered a webinar today on your first 100 days as a business process director. As she points out, you have 100 days to make some key first impressions and get things rolling, and although you may not necessarily deliver very much in that time, it sets the tone for the ongoing BPM efforts.

She breaks this down into what you should be doing and delivering in each of the first three months:

  • The first month is about planning and getting a number of activities kicked off. If you’re new to the business area (often, the BP director is coming in from another part of the organization or from outside), then learn about the organization and the business. Start an assessment of how BPM will impact the business, interview key executives, and make sure that you understand the key drivers for BPM to ensure that the project actually has a long-term vision and goals. By the end of that first month, you should have delivered a high-level plan, figured out who’s going to be on the team and how it will be staffed (internal, external consultants, new hires), and create a “what is BPM” presentation to use for eduction within the organzation.
  • The second month is about getting the strategy in place. The team should be mostly in place, with roles and responsibilities defined, and you should have ties established with complementary groups such as enterprise architecture and strategic planning. Some amount of documentation needs to be created by this point, including the BPM charter, methodology for BPM projects and the BPM governance structure (including a competency center) that dovetails with other governance within your organization. At this point, you should also have a first draft of your BPM strategic plan and a communication plan.
  • The third month is about starting to deliver results. With the internal team fully in place and some new hires likely still ongoing, you’ll need to determine training needs both for the team and to roll out on a larger scale. The actual process improvement work should be started, looking at the details of processes in the business areas and considering the application of BPM practices (we’re not talking technology implementations here) to start understanding and improving processes, and try to complete two “quick win” projects where you’re showing value in the organization. The business process competency center should be kicked off and the charter drafted, and governance bodies such as steering committees in place, and you should finish your final strategic plan.

In some organizations, this will seem a wildly optimistic schedule for all of these activities, and Olding admitted that she has seen many cases of this stretching to around 18 months. I’m sure that hiring Gartner to help you out will speed things along, however. :)

She ended up with some recommendations that are pretty good advice on any type of project: understand the organization and have a plan that is flexible enough to accommodate theirpecific needs; communicate, particularly showing BPM in the context of business imperatives; and advocates within the business to help with the adoption process. Gartner has published quite a bit of research on getting started with your BPM initiatives, including governance and competency centers, but she recommends actions such as getting a collaboration site (e.g., SharePoint, or a hosted solution such as Google Sites if you have external participants) set up early to gather ideas and information about BPM.

Elise went into quite a bit of detail on each of these; definitely worth checking out the replay of the webinar in full (the registration was here, so the replay will likely show up there somewhere). Also, they have two BPM conferences coming up: February 23-25 in London, and March 23-25 in San Diego, and there’s a discount code given at the end of the webinar for $300 off the San Diego conference.

Comparing BPM conferences

The fall conference season has kicked off, and I’ve already had the pleasure of attending 3 BPM conferences: the International BPM conference (academic), Appian’s first user conference (vendor), and the Gartner BPM summit (analyst). It’s rare to have 3 such different conferences crammed into 2 weeks, so I’ll sum up some of the differences that I saw.

The International BPM conference (my coverage) features the presentation of papers by academics and large corporate research labs covering various areas of BPM research. Most of the research represented at the conference is around process modeling in some way — patterns, modularity, tree structures, process mining — but there were a few focused on process simulation and execution issues as well. The topics presented here are the future of BPM, but not necessarily the near future: some of these ideas will likely trickle into mainstream BPM products over the next 5 years. It’s also a very technical conference, and you may want to arm yourself with a computer science or engineering background before you wade into the graph theory, calculus and statistics included in many of these papers. This conference is targeted at academics and researchers, but many of the smaller BPM vendors (the ones who don’t have a big BPM research lab like IBM or SAP) could benefit by sending someone from their architecture or engineering group along to pick up cool ideas for the future. They might also find a few BPM-focused graduate students who will be looking for jobs soon.

Appian’s user conference (my coverage) was an impressive small conference, especially for their first time out. Only a day long, plus another day for in-depth sessions at their own offices (which I did not attend), it included the obligatory big-name analyst keynote followed by a lot of solid content. The only Appian product information that we saw from the stage was a product update and some information on their new partnership with MEGA; the remainder of the sessions was their customers talking about what they’ve done with Appian. They took advantage of the Gartner BPM summit being in their backyard, and scheduled their user conference for earlier the same week so that Appian customers already attending Gartner could easily add on a day to their trip and attend Appian’s conference as well. Well run, good content, and worth the trip for Appian customers and partners.

Gartner’s BPM summit (my coverage), on the other hand, felt bloated by comparison. Maybe I’ve just attended too many of these, especially since they started going to two conferences per year last year, but there’s not a lot of new information in what they’re presenting, and there seems to be a lot of filler: quasi-related topics that they throw in to beef up the agenda. There was a bit of new material on SaaS and BPM, but not much else that caught my interest. Two Gartner BPM summits per year is (at least) one too many; I know that they claim to be doing it in order to cover the east-west geography, but the real impact is that the vendors are having to pony up for two of these expensive events each year, which will kill some of the other BPM events due to lack of sponsorship. Although I still think that the Gartner BPM summit is a good place for newbies to get a grounding in BPM and related technologies, having a more diverse set of BPM events available would help the market overall.

If you’re a customer and have to choose one conference per year, I’d recommend the user conference put on by your BPM vendor — you’ll get enough of the general information similar to Gartner, plus specific information about the product that you’ve purchased and case studies by other customers. If you haven’t made a purchasing decision yet and/or are really new to BPM, then the Gartner BPM summit is probably a better choice, although there are other non-vendor BPM events out there as well. For those of you involved in the technical side of architecting and developing BPM products at vendors or highly sophisticated customers, I recommend attending the International BPM conference.

Gartner BPM: Global 360/Carlson Marketing

Robert Lang of Global 360 to talk about an implementation at Carlson Marketing, a travel, meeting and event planning company. They had a lot of paper-based processes that included hand-offs between departments with complex approval processes; not only was the basic process difficult to manage, but changes to a customer proposal were difficult to execute efficiently.

They used Global 360, SharePoint (as a portal), InfoPath (for complex forms UI) and SQL Server to implement their travel proposal request process, including automating the routing of work requests related to the proposal process. They automated some operations, and made other operations considerably more efficient by maintaining a common folder for the proposal that could be accessed by any relevant participants. They allowed for spawning related but independently-executing processes.

Their benefits:

  • Faster processing of proposal requests
  • Better accuracy in data collection
  • Less rekeying of data
  • Consolidation of data into a centralized database for historical analytics
  • Improved turnaround time by 30%
  • Reduced number of personnel required to process a proposal request by 19%
  • Ability to identify and address bottlenecks in the business process
  • Dynamically reconfigure and reassign staff to optimize work

They plan to use Global 360 for other projects, including A/P, HR and their call center.

That’s it for me for this Gartner BPM summit: after spending most of the last 2 weeks traveling to 3 conferences, I’m skipping the vendors’ parties tonight and the last half-day of content tomorrow morning. I’ve been thinking about a wrap-up post comparing the 3 very different conferences — one academic, one vendor and one analyst — so watch for that over the next few days.

Gartner BPM: Global 360/Citi Cards Imaging and Workflow

Global 360 has a bit of revolving door with analysts: first, they hire Jim Sinur from Gartner. Then, they hire Colin Teubner from Forrester. Then, Sinur leaves. And here today at the Gartner show, which he admits is his first-ever, Teubner presented on behalf of Global 360 about putting people first in BPM. He really only did the introduction, however, before turning over the presentation to one of their customers, Richard Van Hoever, SVP of Customer Service Paper at Citi Cards.

Citigroup uses a lot of Global 360: 10,000 users worth. They’ve implemented a pretty standard imaging and workflow transaction processing application, with work queues that push work to participants rather than allowing cherry-picking, work prioritization and routing, and load balancing across their domestic, nearshore and offshore workforces. The big challenges are the volume of work, tight integration between document management and BPM, and geographic routing.

They were able to get 75% of their required functionality out of the box with Global 360 (they were promised 90%, but that type of discrepancy is pretty common). Most of the customization was around the work filtering, sorting, assignment and presentation, as expected; Global 360, like other BPMS’, does most of the behind-the-scenes stuff out of the box.

What amazes me is that this is fundamentally not different from the types of imaging and workflow systems that I’ve been helping organizations to implement for about 15 years; the only thing that has changed is that the relative sophistication of today’s tools means much less custom code and greater process agility. However, the business process is the same inefficient, key-from-paper/image process that’s been happening the same way for years. Undoubtedly, the relative volume of some transaction types will have reduced due to online self-service, but it’s clear that many large financial services organizations have a long ways to go in terms of making it easier for their customers to do their data entry for them.

Gartner BPM: SaaS and BPM

Having bugged out of the Agile BPM session, I arrived late to Michele Cantera’s discussion of whether software as a service is a viable option for process improvement projects. She covered off some of the same material as the SaaS and BPM session in February, but there was some new information as well. I won’t repeat the material from that session on the topic of BPM SaaS delivery and multi-tenancy models, so you might want to go back to that post and check that out as background for this. Go ahead, I’ll wait.

One interesting bit, based on 2007 estimates, segmented the BPM SaaS adopters into four categories:

  • Pragmatists, forming 49% of the market, who are replacing departmental on-premise applications but don’t have an enterprise-wide scope.
  • Beginners, 40% of the market, who are replacing low-end software tools with simple utility applications. These are often small or medium businesses who don’t want to grow an IT department.
  • Masters, 10% of the market, who are weaving SaaS applications into their enterprise-wide application portfolio.
  • Visionaries, a mere 1%, who are actively replacing on-premise applications with SaaS wherever possible.

She showed these plotted out on two axes: comprehensive strategy versus IT ability to execute. Pragmatists are low on comprehensive strategy but high on IT ability to execute; beginners are low on both, masters are high on both, and visionaries are high on strategy but low on ability to execute (since they don’t need to have internal IT skills). I really like this segmentation, since I think that it provides a good way to characterize SaaS customers in general, not just SaaS BPM customers.

She went through the list of current BPMS SaaS vendors, split out into business process modeling, process-based applications, and BPMS as a service. The SaaS modeling vendors are Lombardi, Metastorm and Appian; BPMS as a service is offered by Appian and Fujitsu. Process-based applications are typically offered by companies who have taken a commercial BPMS and built a specific vertical application on top of it; the underlying BPMS is not necessarily offered as SaaS directly, and in most cases, the BPMS vendor is not the one providing the service (with the exception of DST, whose BPM product grew from their own mutual fund back-office application), since most of them are not in the vertical applications market. There are going to be more entrants into all of these spaces in the near future, as well as changes to the multi-tenancy models offered by the vendors; you’ll want to keep your eye on what’s happening in this space if you’re considering BPM via SaaS, and start to consider how you’re going to handle process governance when your business processes aren’t running on your own systems any more.

She also showed a chart of different SaaS services types (BPO, application outsourcing, hosting, traditional ASP/SaaS model, process-based applications using BPMS/SaaS, BPMS as a platform, BPMS as SaaS-enabling platform) mapped against operating characteristics (operational cost, degree of customization, process agility, cost of process agility, number of suppliers): for example, BPMS as a platform has high process agility, whereas a traditional ASP/SaaS application that likely doesn’t include a BPMS has low process agility.

There was a list of do’s and don’ts of using SaaS for process agility, such as using BPMS via SaaS for pilot projects in order to make the business case for on-premise systems. Of course, if you do that, you might just find that you like the SaaS model well enough to stick with it for the long run.

Gartner BPM: Agile BPM methods

In the spirit of discouraging conference organizers from scheduling sessions that start before 9am, I boycotted the 8:15 keynote session, but showed up for the session on Agile BPM methods. Unfortunately, it appears to be a complete rerun of David Norton’s session from February, so I’m heading out to find a different session.