Appian Forum: Accelerating BPM Adoption Through An Integrated Business Framework

I skipped out on the breakout sessions this afternoon, but am back here for Michael Melenovsky — formerly with Gartner, now senior BPM leader at Satyam — discussing how to accelerate BPM adoption through an integrated business framework: more of a methodology framework than a code framework, however.

He listed the three ways in which BPM projects are initiated, and how that influences the approach to be taken:

  • Executive leadership, where an executive goes to seminar or reads an article on BPM, and says “hey, let’s get us some of that”. The objective is strategic alignment and increasing corporate performance; because it’s very top-down, it’s only possible to push down the ideas so far, and often they’re not implemented.
  • Middle management, with the goal of operational improvement and cross-departmental coordination, with the BPMS seen as a tool for modeling processes and standardizing work procedures.The key challenge here is getting buy-in from both the top and bottom.
  • Line of business management, with the objective of improving productivity, decreasing costs, increasing quality, and providing greater agility. The BPMS is seen as a development platform, and 80% of these projects are driven by the IT department. There is no comprehensive vision, and implementation can take a long time.

He points out that the process layer makes explicit the role that people and systems play at each step of the process. Instead of a world where the IT organization must interpret the process, there is little visibility beyond a department’s boundaries, and it takes a long time and technical resources to change a process, the addition of a process layer makes the process model explicit and allows the model to drive the process execution, with process changes made by non-technical people.

There are three different perceptions of BPM, between business people, IT people and process people in terms of what creates the competitive differentiation and the best way to approach BPM. Each of these has a bias, and it turns out that the process people are the best ones to own a process, not the business people as is commonly assumed. The process people can form a bridge between IT and business, and keep the focus on the process rather than either the people or the systems involved in those processes.

He presented some sample requirements that might be included in a BPM project:

  • Business analysts and IT can collaborate around a single executable process model
  • Business can simulate the performance of the process for optimization purposes
  • Real-time monitoring and analytics
  • Task analytics guide human resources in task prioritization
  • Automated human workflow with simple to use task routing
  • Search capabilities for operations to review standard work procedures
  • Task user interfaces that are built quickly using an integrated composite application framework
  • Business rules and policy management for non-technical users to manage and modify

BPM provides value to both business and IT: we usually focus on the business benefits, but IT benefits through reduced solution development time, a more comprehensive architecture (usually in conjunction with SOA initiatives), reduced application maintenance costs, and shifting attention to higher-value topics instead of always being down in the code trenches.

He listed six critical success factors for BPM:

  • strategic alignment
  • culture and leadership
  • people
  • governance
  • methods
  • information technology

These aren’t specific to BPM, of course: any project with a significant technology component will rely on the same factors.

He showed a pyramid with a strategy layer at the top, followed by processes, applications, transactional systems, and tools; most companies are missing the process layer, hence try to go directly from strategy to applications, with high-level business executives stating that they need a specific solution, rather than stating their requirements in terms of a business process.

He walked through the participants in a cross-functional BPM project team, and finished up with getting started with BPM:

  • identify key stakeholders
  • define BPM in the context of benefits
  • determine the phases of value that BPM will deliver
  • develop a 3-year BPM roadmap

Satyam, of course, offers strategy and solution frameworks for BPM projects.

Appian Forum: AGF

John Jarrett, director of BPM at AGF Trust, spoke next about their Appian implementation; they’re the trust subsidiary of AGF Management Limited, a mutual funds company in Canada — very familiar territory for me, since the system integration company that I used to run implemented about half of the mutual funds imaging and workflow systems in Toronto in the 1990’s.

AFG Trust initially leveraged the parent mutual fund organization’s back office imaging and workflow system (either Jewelstone or Unisen, I believe, which were owned by AGF), but license expiry required that they look for another solution and they decided to strike out on their own with respect to systems in order to get something that was more suited for their specific needs. Instead of the document-centric solution that they were used to, they decided to take the BPM approach and focus on visibility, flexibility, agility and excellence in their processes. Their goals were to gain a more complete understanding of their own business so that they could understand the bottlenecks and inefficiencies; they also had to deal with the issue of a huge temporary workforce hired for a couple of months during tax season when there is a large influx of transactions as consumers scramble to invest in their retirement accounts before the tax-year-end deadline.

They’ve seen a number of benefits, both hard and soft:

  • increased control over business processes
  • process change and improvement flexibility
  • improved risk management and compliance practices
  • support of continued business growth
  • control expense growth

They selected Appian because of the ease of use and human-centric collaborative approach, the flexibility of having the process designers within the business unit, and the fact that the Appian product included all of the functional components that they required. The project team was positioned as a BPM center of excellence between IT and the operations group where the system was used, with Jarrett and 5 business process designers drawing on some IT resources and some business subject matter experts, plus Appian professional services as required.

They used a less agile approach than some of the other customers that we heard from today, documenting the to-be processes and requirements in great detail before starting implementation. Although he didn’t specify the implementation time, I suspect that this waterfall-style development approach took longer than an agile approach. Their pilot launch was in January of this year, with 1 product and 25 users, then a second launch in April for 3 product lines and 250 people (almost their entire user base within their loan and mortgage business). A third launch is coming up in October, adding more specialized products and lesser numbers of users, and they’re planning for other lines of business. They launch about 250,000 processes per month, since many business processes spawn multiple executing processes in order to complete.

Appian Forum: MEGA Partnership

Terry Lee, MEGA’s VP of North American operations, gave us an overview of MEGA, both in terms of their business process analysis and enterprise architecture capabilities. He stated the real reason for using a BPA tool, rather than just the modeling environment within the BPMS, is the ability to analyze the processes within a larger context: relative to risk analysis, enterprise architecture, and corporate performance management.

A process is analyzed and some level of design is completed in MEGA, then the process is handed off to Appian through a manual export/import for further work in their process designer — no mention of round-tripping, although I happened to be sitting beside Dan Hebda (MEGA’s VP of technology) and passed him a note asking about this. He replied that round-tripping would be supported, but isn’t in the current prototype that they’re demonstrating here at the conference. I have a meeting with Dan tomorrow at Gartner, where I’m sure to get a lot more information on this, and Terry summed at the end of his presentation by mentioning that the future integration would include round-tripping.

Metrics for the executing process are captured using the MEGA Advisor and fed back to the models in MEGA to allow for process analysis and optimization.

I believe that there’s a lot of benefit for many organizations in using a BPA tool such as MEGA for modeling processes — especially the portions of processes that are not automated, hence may not be represented in the process models within a BPMS — and the larger enterprise architecture context. For success, however, this requires two key areas of integration: a seamless bidirectional exchange of process models, and the ability to load executing process logging data back into the BPA. It appears that Appian and MEGA are working hard to achieve both of these.

Appian Forum: Enterprise Rent-A-Car

Pat Steinmann and Dion Beuckman of Enterprise Rent-A-Car presented on their Appian implementation; I didn’t realize that not only are they the largest rental car company in North America, but are family-owned. Steinmann is from corporate IT, and Beuckman is with an operating unit in southern California, and they talked about two independent implementations of Appian within Enterprise.

Steinmann started off the presentation, discussing how the focus of their implementation was on the requests for IT services. Originally, they had an AS/400-based request system that was highly manual and error-prone, and they often could not meet the requirement to have a request successfully submitted to IT within 3 days from the original request. It was costing them $212/request in administrative overhead, or $600k/year, any increase in volume required a linear increase in staff, and the time required to train a new employee could stretch to 9 months. Over 200 services were available for request, with the work executed by 60 teams.

They created their Request Online system with a vision to automate the workflow and task execution where possible, allowing the human participants to just do the value-added activities; provide more visibility into the process; and reduce training time for new employees. This led to two basic design goals:

  • Translate a submitted request into specific, actionable tasks
  • Ensure that submitted requests are acted upon

Not only did this require automated processes, but also integration with other systems, rules to define what type of requests could be made by specific users, and process agility.

Four of their own developers and 3 Appian resources created their implementation in 6 months, using joint application design (JAD) sessions with business and IT for what Steinmann described as a very agile development environment: so much so that they had only one design change after they went live.

They have been able to be more proactive with their support of users, for example, by collecting a list of users who were interested in Outlook-iPhone integration, then automatically notifying them when new information was available. They’ve also made the portal easy to use so that users don’t need much (or any) formal training on how to use it, since it’s available across the organization.

Beuckman then went through another implementation that they did, for the vehicle maintenance payables process. They process over 18,000 invoices per month, all paper-based and manually processed, and have a geographically-dispersed workforce that might be involved in approving invoices before payment. Since there are rarely purchase orders for the invoices, there are some fairly complex business rules required for validation of the invoice.

Their aim was to automate non-value-added tasks, expedite cross-departmental (and likely geographically distributed) workflow, centralize A/P processing while maintaining distributed decision-making, reduce error rates, increase process consistency, reduce handoffs and touchpoints, and increase productivity.

Their Appian implementation, used by about 60 employees, deployed their first process about 6 months from the start of development using 1 internal and 1 Appian resource. They did an 8-week pilot with one region, then rolled out the remaining 12 regions over 12 weeks so that now 100% of their maintenance invoices are processed through the application. Their second application, body shop payables, then only took them 6 weeks.

They reduce the human steps in the process from 9-19 down to 1-6, with 40% now auto-approved and loaded directly to PeopleSoft. They have real-time visibility into the process, and can easily identify system bottlenecks and locate missing invoices to determine process problems.

On the surface, this is a pretty standard A/P imaging and workflow application, with one major difference from most similar implementations: they had it up and running in less than 6 months.

Appian Forum: Archstone

The next presentation was from David Carpenter, Director of BPM at Archstone, a residential apartment investor and operator with about 2,600 employees. One of their main challenges was a high employee turnover rate, and the necessity to reduce the learning curve for new people. They wanted to move away from paper-based forms and manual workflow to a more automated workflow with dynamic online forms, with the goal of processes becoming more consistent and coordinated. At the same time, they needed people to be able to use the system with little or no formal training.

They selected Appian because it is a completely web-based solution, has dynamic forms, and requires a minimum of IT resources since there was more configuration than coding involved in the implementation. Their first focus was a broad but shallow implementation that supported their 2,200 field associates, and have settled into 90-day development cycles with the goal of delivering 3-6 new processes in that time. They have done this with a team of three non-IT staff, supported by in-house IT resources and Appian’s professional services.

They rolled this out to the field by going on a country-wide road show to present what they were doing and collect feedback, then rolled that feedback into the implementation — he sees this constant communication and integration of the users’ ideas as a key part of the end-user acceptance of the system. They signed a contract in November of 2006, and rolled out 3 critical processes to their 2,200 field associates by the end of April 2007. As of the end of July 2008, they’ve implemented 25 processes, representing 2,000 process instances per month, plus a customized portal for each community, and a central forms repository containing 300 standardized forms.

They’ve just delivered phase 4 of the project, targeted at both community and corporate users, and are planning for phase 5 and beyond: truly a continuous improvement model of change.

Carpenter sees Appian becoming one of their core applications: just like users login to their email first thing in the morning, they login to Appian as well, since that drives their work processes each day.

Like Nokia Siemens, they’re using a non-IT group since IT just doesn’t deliver fast enough (that’s my assessment, he didn’t say that): in my experience, this is a very common problem when BPM projects are run by IT, and a product like Appian that can be selected and implemented by non-IT resources has a huge advantage as long as the corporate culture supports business-led technology implementations (most don’t).

Appian Forum: Product Update from Malcolm Ross

Malcolm Ross, Director of Product Management and someone who I once referred to as an über demo god, gave us an update on the Appian product. He started with their product development philosophy:

  • flexibility
  • ease of use
  • comprehensive
  • build for the future, which is how they position their web-based AJAX process modeler, in contrast with most of the competitions’ Eclipse-based desktop process modelers
  • listen to customers

He reviewed the enhancements in their latest version, Appian Enterprise 5.7:

  • improved web services handling
  • custom data types, allowing for complex data sets based on XML structures
  • WSRP portlet consumption for creating mashups directly within an Appian dashboard (which, of course, he illustrated by showing my RSS feed integrated into a dashboard)
  • improved security for outside-the-firewall applications
  • a number of smaller enhancements, mostly around usability for designers

They’ve also released Appian for SharePoint, providing single sign-on and the ability to snap a number of different Appian views into a SharePoint page, and access SharePoint content from the Appian environment.

He gave a bit more detail on the Appian-MEGA integration, although I think that it’s still early days on this, and he didn’t comment on round-tripping, although he implied that it was possible. He described being able to discover Appian processes from MEGA — the opposite of what is usually done with BPA-BPM tools integration — and I’m waiting for the (I hope) more in-depth details in this afternoon’s session. Their overall goal is to integrate process models into a larger enterprise architecture picture, allowing for risk analysis and other corporate performance analysis and management.

Appian Anywhere, their software as a service solution, is based on the same core code base as Appian Enterprise, so these enhancements will be available there as well.

He gave us a brief summary of what’s coming up in Appian Enterprise 6.0 in the first half of 2009, including new end-user and application designer interfaces, and support for managing distinct process-based applications within their environment.

Appian Forum: Nokia Siemens

Nick Deacon, Global Head of BPM for consulting and systems integration within Nokia Siemens Networks, a global network communications services firm. The consulting and systems integration group, with a staff of 3,500-4000 and annual sales of 400M Euro, has the usual problems of managing a workforce of service providers, and were looking for a BPM solution — easy to use, relatively low cost and easy to customize — to help them better manage what he referred to as the Mean Time Between Surprises. They were looking to quickly implement their core processes of sales, service execution, and resource and competence management, before global IT noticed what they were doing and turned it into a mega-project.

Since the project started in February (yes, this February), they have implemented their first module (service delivery process) and rolled it out to 400 users across all of their global regions, including portals and dashboards for analyzing and managing the business. At the same time, they were working on the resource and competence management process module, which is about to start into testing, and the sales and technical support processes will be ready for deployment in November. Product and portfolio management will follow in December, and offshore delivery management in February. Basically, that means that they will have deployed BPM across all of their major business processes within 12 months.

Through reduced data entry, increase sharing of information and increased reuse of project assets, they expect productivity savings of 12-16M Euro per year, which (I hope 🙂 ) provide an ROI of much less than a year.

There’s now interest from other areas within NSN, and their projects are becoming a sort of proof of concept for BPMS across the much larger organization, not just within the consulting and systems integration group.

Deacon had nothing but good things to say about Appian in terms of both the product and how their professional services has worked with NSN to deliver the right business functionality on a tight schedule across a global enterprise. He sees them as being aligned with NSN’s vision and strategy for BPM, and have been a true partner on their implementation. They looked at larger BPM vendors, but found their solutions too rigid and too expensive.

Appian Forum: Matt Calkins

Appian’s CEO was up for the only vendor executive presentation of the conference, to discuss Appian and its community of customers and partners. As a somewhat late entrant to the BPM market, they had only about 15 customers in 2004 growing to almost 80 (active) customers in 2007, and expanded from a primarily government focus to include many other industry verticals.

Appian’s view of BPM is that although it’s becoming mainstream, email still owns 99% of what could be the BPM space through the implementation of ad hoc processes. Because of that, it’s essential for BPMS to easy for all types of users — both designers and end users — and provide very little resistance to adoption. A fully web-based product suite is one part of this, and Appian is one of the few vendors to provide a web-based process designer, and their move into a hosted model reduces the frictional costs further. He discussed a number of their technical innovations, stating “we didn’t do this just because we’re nerds”, but sees them as essential to providing a good BPMS.

With the downturn in the US market, Appian and other vendors are being forced to look outside their borders for new customers, and finding — surprise! — that there are significant international opportunities. Their EMEA sales grew by over 300% year-over-year, and they’re seeing more potential business there.

He also announced Appian ShareBase, a wiki (his word, but actually more of a shared repository) of code objects pertaining to Appian, including process models, rules, smart nodes and any other design objects that can be shared, all of it available free for other Appian customers to reuse. Appian will be seeding ShareBase with a substantial amount of their own intellectual property. No word on the licensing ramifications here, but based on the “free to reuse” statement, I assume that it’s pretty open.

He also discussed their new partnership with MEGA for process modeling and enterprise architecture, more of which will be discussed later in the day.

Appian Forum: Connie Moore keynote

Three days ago, I was in Rome — original home of the Roman Forum and the Appian Way — and now I’m at Appian Forum: Appian‘s first user conference. Samir Gulati, VP of Marketing, delivered some short opening remarks including the “Sandy Kemsley Conference Checklist”, showing how they measured up on my basic requirements for conferences: wifi, online agenda, good content, frequent networking breaks, and other good stuff. They missed on the power plugs at the tables, but other than that, I have to give them full marks.

They had about 150 people sign up for the conference, although I don’t think that were are that many in the room this morning; this was not a paid conference, which tends to result in a higher number of no-shows, but there’s a good cross-section of Appian’s customers and partners, as well as analysts.

After Samir’s short introduction, he turned it over to Connie Moore of Forrester for a keynote on Design for People, Build for Change (wait, this sounds familiar…). She had a great graphic that expand on some of the things that I’ve heard Forrester people talk about in the past, highlighting the “design for people” part of the equation through social networking and other techniques, whereas we’ve often focused (maybe too much) on the “build for change” part of business innovation.

She discussed four factors creating the “perfect storm” that’s led to the current situation:

  • Design evolution, where more products are being designed for optimal use and customer experience, rather than the conveniences of the manufacturer or based on the preconceived notions of the designer. There are many consumer products that illustrate this, but it holds equally true with business computer systems.
  • Process evolution, where we do more continuous improvement than big bang reengineering for both technical and cultural reasons. The current range of BPM products, with monitoring and optimization built in, allow for this sort of continuous improvement in ways that were not previously possible, which has helped to facilitate this shift.
  • Workforce evolution, with the boomers — along with their knowledge of business processes — starting to retire, and the systems developed for those boomers not really suitable for the millenials who grew up digital. This forces the move to different computing paradigms, particularly social networking, as well as different corporate culture in order to attract and retain the talent.
  • Software evolution, moving from a traditional model to software as a service, Web 2.0, open source and free software in both consumer and enterprise environments.

All of this means that we need to bridge between structured human activities and system-intensive processes that we’ve dealt with in traditional enterprise systems, and the ad hoc, messy, chaotic human activities that we see in the new generation of dynamic business applications. Earning her keep, she highlighted how Appian brings content and collaboration to the usual BPM functionality seen with other vendors, then walked through an example of a dynamic business application.

She discussed the need to forge partnerships between stakeholders, preferably by collocating the business and IT people on a project team so that they create a more seamless project. I’ve seen a lot of projects where there is a serious disconnect between the business and IT participants, and having them sit and work together could only help that situation.

Forrester went out to a number of enterprises to see how they build for change, and saw a few different models:

  • An IT-focused model where the technical team always makes changes to the process (hopefully based on conversations with the business)
  • A blended model where the business owners meet with the project team on a regular basis, and the process changes are made by business analysts or technical team members, depending on the requriement

There needs to be a change model that allows for both continuous change — every 1-2 weeks for process tuning — and for new process versions — every 2-6 months for new processes and major changes. This change model needs to be incorporated from the beginning in any process project to allow for continuous improvement, or you’ll end up with inflexible processes; at the very least, plan on a minimum of 3 iterations shortly after implementation before the process is even remotely correct. At the same time, you need to consider forming a process center of excellence to help with overall process improvement, and consider the link to SOA in order to provide a technical framework for dynamic business applications.

When Forrester asked enterprise architects about the primary benefit of BPM, the largest response (24%) was increased productivity, with process visibility (18%) and agility (15%) following. Other benefits included the ability to model processes, consistent processes across business units/geographies, and reduced reliance on IT for process improvement. By looking at the perceived degree of success and the existence of a BPM center of excellence, they found a clear correlation: about half of those who said that BPM was a rousing success had a COE, whereas less than 5% of the failing efforts had a COE.

Her experience — which matches mine — shows that going with a large systems integrator is not a good way to build the necessary skills within an enterprise to achieve ongoing process improvement, and sees direct skills transfer from the BPM vendor has a greater degree of success. Business analysts need to become process analysts, and developers need to become assemblers of dynamic applications. She finished up with several suggestions on how to get started, for business people, IT and executives.

Although there was a lot of repetition from earlier versions of this message that I’ve heard her deliver, I do see some evolution and refinement of the message. Some of the stats and ideas go by pretty fast, however; the audience might benefit from a bit less of a PowerPoint karaoke feeling.

There was an audience question about how Web 2.0 concepts and products — mostly being developed by tiny companies — will be integrated with traditional BPM products from larger companies; Moore didn’t really answer the question, but discussed how the BPM platform vendors are building their own Web 2.0 functionality, and many other BPM vendors are partnering with SharePoint or other collaborative tools. I think that there’s a lot of room for the Enterprise 2.0 vendors and the non-platform BPM vendors to get together to create social networking-enabled processes that are far beyond what’s available from any of the platform vendors (although IBM is doing some pretty innovative stuff), or through SharePoint integration.

This week in BPM conferences

Last week and this week saw some very difficult choices for conference attending: I went to the International BPM conference in Milan last week, but missed Office 2.0; this week, I’m attending Appian’s user conference and Gartner’s BPM summit in Washington DC, but missing SAP’s TechEd and all my Enterprise Irregulars peeps (although I won’t at all miss going to Las Vegas).

Watch for my coverage of the Appian user conference tomorrow, then Gartner starting on Wednesday.