sandy

Gartner BPM: Customers say the darnedest things

At the lunch presentation today, Alan Trefler (CEO of Pegasystems) discussed how it’s necessary — and possible — to put BPM right in the hands of the business users, and let them do it themselves. There will be some IT architectural oversight and support, of course, but you just have to convince the users, Tom Sawyer-like, that they really want to paint this fence.

I was sitting beside the BPM architect from one of Pega’s customers, and at the end of the talk I turned to him and asked “Do your business users do this?” His response: “Oh, hell, no!”

We still have a ways to go on this issue…

Gartner BPM: Opening Keynote

I arrived a bit late, transferring from the Ritz out in Tysons Corner down to the Gaylord in National Harbor (which Google Maps still thinks is a construction site), but caught the last half of the opening keynote with Janelle Hill and Michelle Cantera.

They started with some of the forces affecting business, both business and technology. Technology forces of change include having to balance enterprise-class and global-class computing, by which it appears that they mean custom, heavy-duty, special-purpose applications versus mass consumer applications: she makes the analogy between a custom, craftsman-made desk for the Oval Office versus an Ikea desk for the rest of us. Business forces of change include globalization, regulatory oversight, the evolution of the workforce (this is sort of a rerun of Connie Moore’s message of yesterday), and the complex value chains created by collaborative enterprises.

Since we’re here to talk about BPM, the next part was on how BPM helps us to cope with these forces of change. Their current BPM definition includes management practices, a structured approach using the management practices and software tools, and a cultural transformation (this last one is new in their definition, and long overdue). Overall, BPM is a set of disciplines plus technologies; it both encourages and enables continuous change in response to external forces, with a focus on optimizing end-to-end processes rather than specific functions. A key part of the approach is iterative (not phased), time-boxed, agile delivery, which I agree is critical but rarely see in practice.

BPM is being used heavily by companies that need to cope with frequent process change, usually in their customer-facing processes: from changes several times a year down to weekly or even daily frequency, plus ad hoc changes to executing process instances. What you need to think about, then, is how BPM changes your planning practices: Gartner suggests planning on shorter cycles and making plans dynamic and more transparent, with explicit guidelines for business outcomes rather than an explicit path by which those outcomes are reached. BPM also changes your organization and leadership by empowering employees (that’s a bit of a tired expression) and encouraging more fluid, virtual teams. It’s not clear that BPM is the real contributor here, however: I have the sense that they could take this same slide and present it at a number of different technology conferences (e.g., Enterprise 2.0) without changing anything but the title.

To use BPM effectively, you have to take advantage of monitoring and optimization, which is hopefully built into your BPM solution. This allows for better alignment of goals, metrics and results.

They finished up with a discussion of the skills and competencies required to build a BPM center of excellence (or as Gartner calls it, a center of competence), and a flying tour of their business process adoption and maturity model. Surprisingly, this tag-team presentation went way over time, not a good start for the day.

Not much new and exciting here — pretty much what you expect from a keynote — but a good overview of BPM in the context of business for the newbies in the crowd.

Appian Forum: Wrap-up

Samir Gulati returned for a brief wrap-up of today’s event before we headed for cocktails and the technology showcase, with Malcolm Ross describing the technical sessions that will be held over at Appian headquarters tomorrow, and Matt Calkins thanking us all for being here.

There are sessions tomorrow targeted primarily at their customers, including one-on-one executive briefings, so I’ll be headed over to the Gartner BPM summit in the morning instead.

I was impressed with Appian’s first user conference, which had great content and was well-run. Kudos to the whole team.

Appian Forum: Mercer

Chris Gardner, VP of Development at Mercer (who provide HR consulting, HR outsourcing and investment management services), presented the last session of the day; Mercer Outsourcing, with which he is affiliated, provides HR benefits administration.

They rolled out their first 3 processes in April of this year, with the BPM projects involving IT, their operational effectiveness practice and the operational units. Their key drivers are to drive out costs through increased productivity, increase automation of process steps and integration between systems, and standardize processes. Previously, it was difficult for them to reuse or even standardized processes across clients, and many processes required that disparate systems be integrated through human effort. Although in many cases, they thought that they had standardized processes, forcing them onto a common platform exposed their process variability and allowed them to address it directly.

Their benefits from implementing BPM include reduced errors, reduced cycle time, increased SLA attainment (hence reduced penalties for violating SLAs), and greater user productivity (and therefore reduced staffing requirements per client, key since their business in expanding). Automating steps and standardizing processes also allows them to offshore some parts of their processes, reducing costs even further.

Unlike most of the other case studies today, which focused on the human workflow side, they make extensive use of web services for increased automation and, where possible, straight-through processing. One of their projects was an unattended data extraction and file transmission application, where data was extracted from their system via web services calls to an ETL tool, PGP encryption, and FTP of the resulting file to the appropriate third party. Now, the only time that a person is involved in this process is for exception handling, and they have it rolled out to 60 client teams transmitting more than 500 files per week, with 85% of the transmissions being completely hands-off. This creates very different process design challenges than with primarily human-facing processes, such as handling web service unavailability. Even for the hands-off processes, they generate various reports directly from Appian as input to their compliance requirements.

The second application that they’ve implemented manages inbound data files, where Appian acts as an orchestration engine coordinating tasks spreading across their own proprietary systems and other commercial systems. They surface many of the errors and exception handling through Appian, which is exactly what you should be using an orchestration engine for.

He was very excited to hear about Appian’s earlier announcement about ShareBase, since he feels that they have a lot of intellectual property that they share without compromising their own proprietary methods and processes, and encouraged other clients to participate fully in this.

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.