conferences – Page 22

The Decision Dilemma #brf

The Business Rules Forum has started here in Las Vegas, and I’m here all week giving a presentation in the BPM track, facilitating a workshop and sitting on a panel. James Taylor and Eric Charpentier are also here presenting and blogging, with a focus more purely on rules and decision management; you will want to check out their blogs as well since we’ll likely all be at different sessions. I’m really impressed with what this conference has grown into: attendance is fairly low, as it has been at every conference that I’ve attended this year due to the economy, but there is a great roster of speakers and five concurrent tracks of breakout sessions including the new BPM track. As I’ve been blogging about for a while (as has James), process and rules belong together; this conference is the opportunity to learn about both as well as their overlap.

We kicked off with a welcome from Gladys Lam, followed by a keynote from Jim Sinur on making better decisions in the face of uncertainty. One thing that’s happened during the economic meltdown is that a great deal of uncertainty has been introduced into not just financial markets, but many aspects of how we do business. The result is that business processes need to be more dynamic, and need to be able to respond to emerging patterns rather than the status quo. At the Appian conference last week, Jim spoke about some of their new research on pattern-based strategies, and that’s the heart of what he’s talking about today.

One of the effects of increased connectivity on business is that it speeds the impact of change: as soon as something changes in how business works in one part of the world, it’s everywhere. This makes instability – driven by that change – the normal state rather than an exception. Although he focused on dynamic processes at the Appian conference, here he focused more the role of rules in dealing with uncertainty, which I think is a valid point since rules and decision management are much of what allow processes to dynamically shift to accommodate changing conditions; although perhaps it is more accurate to consider the role of complex event processing as well. I am, however, left with the impression that Gartner is spinning pattern-based strategy onto pretty much every technology and special interest group.

The discussion about pattern-based strategies was the same as last week (and the same, I take it, as at the recent Gartnet IT Expo where this was introduced), covering the cycle of seek, model and adapt, as well as the four disciplines of pattern seeking, performance-driven culture, optempo advantage and transparency.

There’s lots of Twitter activity about the conference, and it’s especially interesting to see reactions from other analysts such as Mike Gualtieri of Forrester.

BPM Customer Panel #appianforum

The first day of Appian Forum ended with a panel of Appian customers – Archstone, AGF, Enterprise Rent-A-Car and Mercer Outsourcing – hosted by Clay Richardson of Forrester. Clay started with a question about which BPM project to do first: instead of the old “start small, think big, act fast” mantra, many organizations are choosing to start with a bigger project where they’re experiencing a lot of pain. Not, however, the organizations represented on the panel: they all indicated that they either started with a smaller project, or started with a big one and regretted it. I think that the key is balance: select a big enough project to be meaningful and use an iterative approach so that you don’t get swamped by it.

The discussion continued on to include data integrity/cleansing and return on investment, and the audience chimed in with questions on testing BPM applications to ensure correctness (getting a working system in front of the users earlier for validation and testing helps, as do frequent releases), production support (often done by original project team, which cuts into time for new development and CoE activities, but ideally project team is second line of support and leverages shared services support for underlying server and network infrastructure) and business change management/buy-in (requires communication, participation and vision). I think that my presentation on BPM centers of excellence that immediately preceded this had an impact: a couple of the questions directly referenced what I was talking about, particularly in the last question on process asset reusability across projects (difficult unless there is a CoE that manages an asset repository or otherwise governs reusability).

My job here is done: tomorrow is a more in-depth day for customer product training, so I’m headed back to Toronto tonight.

Benenden Healthcare Society BPM case study #appianforum

Ian Grant of Benenden Healthcare Society, a UK not-for-profit, user-pay healthcare provider with almost a million members. They had a need to improve their business agility, and identified that they needed a new case management system as well as better auditability of the decisions made within processes. They reengineered their processes first, then had their three short-listed vendors build out those processes to see how quickly (and well) it could be done; Appian was the unanimous choice of the selection panel.

They created Service Management System (SMS) to document and manage all interactions with members. Typically, when a member calls in, the service rep accesses all previous case data for this member, gathers some information about what is wrong with the member in layman’s terms – so that the service rep doesn’t have to be a clinical expert – then the rules and processes built into SMS present the services available to that member, and generates the necessary paperwork and follow-on processes. When they go live (soon), they expect to reduce their service rep training time from months to three weeks, and improve their customer satisfaction rating from 95% to 99%. They’ve created some lightly-customized user interfaces that allow for fast information gathering and problem resolution.

During implementation, they completely ignored the current state, and only considered the to-be processes and functionality. Although they had a waterfall requirements process up front with formal signoff, they moved into a more iterative prototype development cycle (although one that seems to have taken a year, so not so agile).

They’ve already achieved two million GBP in savings through renegotiations with their service providers based on their expected future-state process, as well as seeing some improvements across all processes. This is fairly common, since the act of examining and reengineering a business process almost always has the effect of improving it since many of the inefficiencies will be exposed and resolved even before any technology is brought to bear on the processes.

They have involved 85% of the entire user base in some way in the creation of the new system, which has resulted in a high degree of user buy-in since they developed the requirements themselves. They’ve already identified their requirements for the next phase, and are creating the development plan now to deliver that by the end of next year.

I’m left with the impression that there is still a lot of waterfall methodology at Benenden; whether that hinders their efforts will be seen once they’ve rolled out the first version.

Lean Process Improvement Revisited #appianforum

As with Jim Sinur, my schedule is overlapping with that of Clay Richardson of Forrester several times this month. This morning, I heard some new material from Jim, but Clay had much the same presentation that I saw him give at the Forrester Business Technology Forum a couple of weeks ago so I don’t have a lot to add here, although it’s worth reviewing the original post since he had a good presentation on the implications of Lean principles on BPM.

He did have a new bloated-lean-anemic case study about the Territory Insurance Office based on Tom Higgins’ presentation at the BTF; hopefully we’ll see a paper from Clay on this soon.

Appian 6 Release #appianforum

Malcolm Ross was up next to give us an update on Appian 6, being released in GA this week. I had a briefing a few weeks back, so I’ll include my notes from that here for a more complete view.

Their claim is that Appian 6 is the fastest way to deploy process applications through rapid design and collaboration, rapid deployment, rapid process improvement cycles; they claim that they can complete a production pilot before the big BPM vendors can install their product (I think that they could have the pilot complete before the big guys could sign a contract, but that’s another story). In a nice illustration, one of the Appian tech guys installed and configured Appian 6 on another screen while Malcolm was giving his 30-minute presentation, including deploying an application with process models, forms, rules and reports.

They have some unique technology differentiators to support their speed claims: an integrated portal for creating composite applications and zero-code model-driven design for implementation speed; in-memory architecture for execution speed; easy import and export of applications between Appian systems and the Appian Forum online community using a marketplace paradigm; and seamless migration between their SaaS and on-premise solutions for scalability or changing requirements. To support that, they have a services team and methodology with a CMM-like maturity model built in, including a center of excellence for sharing best practices.

There have been a number of improvements to the end user interface: intuitive URLs for navigating directly to specific applications, collaborative discussion forums, and realtime user presence. As we heard earlier, the UI has been simplified with tabs across the top to access different applications and areas; in general, there is a lot more glue to pull together the components into complete applications. The portal allows for mashups to be created not just of Appian components and applications, but of other widgets using JSR168 and WSRP, and an application can include different composite interfaces for different roles: in my previous briefing, I saw an application that included different user interfaces for a loan representative, IT staff member, and IT manager, displaying the same data in a different manner depending on the role. Controls to edit the dashboard and create ad hoc reports can be exposed to specific user roles so that they can modify their own working environment; other roles are limited to what the application designer provides to them. The key thing about a composite application built in this environment is that it is task-driven: the process is baked right into the application.

One of the things that I like about this release is the ease of packaging, deploying and exchanging applications. An entire application, including all of its components such as processes and rules, can be exported at XML; this can be managed in a source code control system, or imported into another Appian system while maintaining unique IDs for the components across all systems. This allows applications to be easily moved to and from the Appian Forum marketplace, an on-premise Appian system and a SaaS Appian instance.

Clayton Holdings BPM Case Study #appianforum

Clayton Holdings, which provides risk analysis, loss mitigation and operational solutions to the mortgage industry, have been using Appian’s SaaS solution, Appian Anywhere, for more than a year, and John Cowles from Clayton was here to tell us about their experiences. They have 135 users over 3 business units, with another business unit coming online soon, kicking off 40,000 process instances per month across 50 different process models. They’re doing all of the build and maintenance with 2 primary resources; considering that their first roll-out only took about six weeks, they’re doing a lot quickly without a lot of resources.

They had a number of business challenges, many of them triggered by the meltdown of their financial/mortgage client base that reduced the amount of work that they had and called for tighter controls. They didn’t have a lot of visibility into their processes and metrics, and many of their key processes were manual; typical training time for the business processes was about six months, yet they had a high attrition rate that meant that people were leaving just as they became capable at the processes. With little internal IT bandwidth and slashed budgets, they decided on a SaaS solution to allow them to try out BPM without a lot of up-front costs or IT efforts.

They had some specific goals for their BPM implementation, particularly around having process visibility (and auditability) and reducing training time, plus reducing process variability by making decisions based on metrics. Their initial project team was the EVP of business operations, about eight subject matter experts, two process efficiency team members and one business analyst.

They do monthly releases with new or modified process models or UI enhancements; most processes are kicked off using web service calls driven by exceptions from Clayton’s internal systems, although they don’t integrate from Appian process instances back to the internal systems. Users can also instantiate processes manually from their dashboard as required, but most are created from the nightly batch of web service calls.

They see Appian Anywhere as a platform for building applications, and hope to replace some of their traditional development with assembly of components into applications using Appian.

Some of their benefits: 38% less headcount in spite of an increased workload to manage delinquencies, 100% more average value adds (e.g., where they detect a previously-overlooked revenue opportunity for their customers such as a penalty payment) per FTE, and the ability to shift the workload to geographic areas with lower costs because it’s all in the cloud. They have much better process monitoring, including reporting on their key metrics, and because of that have identified other process improvement opportunities.

Their lessons learned and best practices:

Focus on change management and process management early
Find net promoters and over-communicate rather than under-communicate
Limited or no system integration in first releases
Prototype everything
Frequent releases, e.g., monthly
Challenge the desire to simple push current variability into the new tool, i.e., don’t just pave the cowpaths
Emphasize the reporting desires up front since it influences design
Resist temptation to start at detailed level of a process

In the future, they plan to bring in another business unit and focus on integrating Appian with internal systems in order to reduce manual rekeying of data between systems. They’re also going to look at some internal process, such as HR and Legal.

Appian Corporate Update #appianforum

Matt Calkins gave us a brief address at the customer dinner last night, but there are many more people here today, and he provided a more in-depth review of the corporate picture. Amongst other indicators are a revenue increase of 150% and active customer increase of 58% in 2009: I’m seeing numbers like this from many of the midsized BPMS vendors, supporting my impression that the BPM market continues strong even in the face of an economic downturn.

Their new corporate slogan is “BPM Accelerated”, referring to both speed of creation and operational speed. Speed to create results in quick ROI and reduced risk while satisfying constituencies; speed to operate results in customer satisfaction, better cost structure and enables the optempo opportunity to adapt to changing conditions. Given their new professional services offerings “Live in 10” and “Live in 20” – meaning a fully operational production system in 10 or 20 days – supports their goal of implementation speed.

Appian is creating a new BPM implementation methodology based on the idea that great processes evolve, they’re not invented: the ability to gradually change a process in order to optimize it is a key factor. I completely agree with this very Agile tenet: if you can’t change your processes gradually over the first few months of operation, they will be unable to properly support your business.

He highlighted some of the new features in Appian 6, such as an application focus both in user interface and deployment. He also emphasized the benefits of their real-time architecture, that allows for subsecond response time for process data, rules and reports from the instance data stored in Appian’s proprietary database combined with the full business data in a relational database. They’ve taken a page from Google’s book and made their UI as minimalist as possible, displaying only the features that the user really needs, in order to make BPM as easy to use as email.

The old Appian Access online community has been rebranded as Appian Forum, and expanded to include a library of free applications (created by Appian, partners and customers) with a starting point of 25 applications contributed by Appian based on customer requests: again, speeding time to implementation for these types of processes.

Don’t Underestimate the Impact of BPM #appianforum

It’s the third time this month that I’ve been at a conference with Jim Sinur of Gartner, and he’s giving the opening keynote here at Appian’s user conference. Although a lot of the local people are held up due to weather and traffic today, they’re expecting over 300 people here: a huge success given the poor attendance and even cancellations that we’ve seen with other BPM events this year.

He started out with some stats on the companies who submitted their achievements for Gartner’s BPM excellence awards: some outstanding examples of executive support and ROI, although you have to keep in mind that these are self-selected as “excellent”. There were, however, some unexpected results and out of the box thinking, where benefits from one organization were used to help those who were less fortunate, or unstructured processes were used to gain process improvement.

Unstructured processes used to handle exceptions within a more structured process are no longer considered unusual, but are a standard part of many processes that need to adapt to shifting conditions: they need to be considered an integral part of a business process rather than something to be avoided. Today’s agile processes allow businesses to deal with known exceptions, by allowing rules or processes to be changed on the fly, but future-thinking organizations have to be looking for unknown exceptions, and allowing their processes to be adapted for any scenario that might arise. There’s a huge amount of information that drives these scenarios and their early detection, including events from multiple disparate systems: the key is to look for patterns and understand the impact that they will have on your organization.

He outlined four disciplines of pattern-based strategy:

Pattern seeking, to seek and exploit signals that apply to you, particularly through collaborative knowledge
Optempo (operational tempo) advantage, to dynamically match organizational pace to changing conditions, requiring a harmonized and synchronized view of patterns across the organization
Performance-driven culture, to adapt to changing patterns in order to achieve target results
Transparency, enabling pattern-based strategy by exposing signals earlier

BPM is one of the technologies that helps organizations to adapt to the patterns, once they have been discovered and modeled in a seek-model-adapt cycle. We’re moving from managing processes to managing chaos, and pattern-based strategies are part of that.

Process Design Slam 2009 – The Final Judgement #SAPTechEd09 #BPXslam09

To wrap up the proceedings from last night, I was asked to critique the efforts of the groups and pick a winner: as it turned out, I was the only judge. Each of the groups did great work, and I want to call out some of the specific efforts:

The Business Use Case group had a great written story, including a lot of cultural and social background for our fictional city in order to provide context for the implementation.
The BPM Methodologies group had excellent documentation on the wiki, including graphics and charts to make it clear how the methodologies fit with the other groups.
The Business Rules group were stars at collaboration with the other groups, in part because everyone quickly realized the importance of business rules to data, UI and process, and solicited their input.
The UI and Dashboards group created mockups of monitoring dashboards that provide a starting point for future design slam work.
The Collaborative Modeling group led at international collaboration, using Gravity (process modeling within Google Wave) interactively with team members in Europe during the session, and produced a business process model.
The Service Implementation group also kicked off implementation, creating a service orchestration process model as a starting point.

In general, everyone seemed to have a good understanding of the importance of data, rules and process, but there could have been better cross-pollination between the groups; in future design slams, that could be helped by requiring some group members to move partway through the evening in order to ensure that there is a better understanding on both sides, something that is fairly common in real-life businesses where people are seconded from one department to another for part of a project. Although a certain amount of collaboration did occur, that was one area that requires more work. I saw one tweet that referred to the design slam as crowdsourced rather than collaborative, although I’m not sure that I would say that: crowdsourcing usually has more of a flavor of individuals contributing in order to achieve their own goals, whereas this was a collaboration with common goals. However, those goals were a bit fragmented by group.

Another issue that I had was the lack of an architectural view of process design: although all of the groups are contributing to a common process (or set of processes), there is little thought around the transformations required to move the process list developed by the Business Use Case group to the process model developed by the Collaborative Modeling group to the process design developed by the Service Implementation group. In enterprise architecture terms, this is a case of transforming models from one layer to another within the process column of the architecture (column 2 if you’re a Zachman fan); understanding these transformations is key so that you don’t reinvent the process at each layer. One of the goals of model-driven design is that you don’t do a business-level process model, then redraw it in another tool; instead, the business-level process model can be augmented with service-level information to become an executable process without recreating the model in another tool. In reality, that often doesn’t happen, and the business analysts draws a process in one tool (such as Visio, or in the case of the design slam, Gravity), then IT redraws it in a tool that will create an executable process (NetWeaver in this case). I have a couple of suggestions here:

Combine the Business Use Case and Collaborative Modeling groups into a single group, since they are both doing high-level business analysis. This would allow the process list to be directly modeled in the same group without hand-off of information.
Reconsider the use of tools. Although I have a great deal of appreciation for Gravity (I am, after all, a geek), the fact that it does not share a model with the execution environment is problematic since the two groups creating process models were really off doing their own thing using different tools. Consider using NetWeaver 7.2, which has a business analyst perspective in the process composer, and having the business use case/collaborative modeling group create their initial non-technical models in that environment, then allow the service implementation team to add the technical underpinnings. The cool Wave collaboration won’t be there, or maybe only as an initial sketching tool, but the link will be made between the business process models and the executable models.

When it came down to a decision, my choice of the winner was more a product of the early state of the design slam rather than the efforts or skills of the group: I suspect that my view would change if I were judging in Vienna or Bangalore when the process is further along. I selected the Business Use Case group as the winner at this point based on the four judging criteria: although they failed to include alternative media, their story was clear and well-written, it fit well with the other groups’ efforts, and they used good social and collaborative methods within their group for driving out the initial solutions.

The winning team was made up of Greg Chase, Ulrich Scholl and Claus von Riegen, all of SAP, with input from a few others as subject-matter experts on public utilities and electricity production, and started the discussions on pricing plans that ended up driving much of the Business Rules group’s work. Ulrich also has solar cells on his house that connect to the grid, so he has in-depth knowledge of the issues involved with micro-generation, and was very helpful at determining the roles involved and how people could take on multiple roles. They leveraged a lot of the content that was already on the wiki, especially references to communities with experience in micro-generation and virtual power plants. Besides this initial leg up on their work, they were forced to work fast to produce the initial use cases and processes, since that provided necessary input to the other groups to get started with their work, which left them with more of the evening to write a great story around the use case (but, apparently, not enough time to add any graphics or multimedia).

There was a huge amount of effort put into the design slam, both in the preceding weeks through conference calls and content added to the wiki, and at the session last night in Phoenix. I believe that a huge amount of groundwork has been laid for the design slams upcoming in Vienna and Bangalore, including process model, service orchestration diagrams, business rules decision tables, and monitoring dashboard mockups.

I had a great time last night, and would happily participate in a future process design slam.

Process Design Slam 2009 #SAPTechEd09 #BPXslam09

8pm

We’re just getting started with the Process Design Slam: one of the face-to-face sessions that make up the collaborative design process that started a couple of months ago on the Design Slam wiki. Marilyn Pratt has identified the six groups that will each work on their part of the design, collaborating between groups (a.k.a. poaching talent) as required, and even bringing in people from the Hacker Night and Business Objects events going on in the same area.

Business Use Case, led by Greg Chase
Collaborative Modeling, led by David Herrema
Business Rules, led by James Taylor
Service Implementation, led by John Harrikey
BPM Methodologies, led by Ann Rosenberg
UI and Dashboards, led by Michelle Crapo

Right now, everyone has formed into initial groups based on their interests, and is having some initial discussions before the food and beer arrives at 8:30. Since there was an initial story and process model developed by the online community, everyone is starting at something close to a common point. Participants within a group (and even the leaders) could change throughout the evening.

By the end of the night, each team will have created a story about their work, and give a 5-minute presentation on it. The story must include additional media such as video and images, and in addition to the presentation, it must be documented on the wiki. Each story must also be related to the output of the other teams – requiring some amount of collaboration throughout the evening – and include pointers on what worked and didn’t work about their process, and what they would do differently in the future.

At that point, the judging panel, which includes me plus Marc Rosson, Uli Scholl, Ann Rosenberg and Dick Hirsch, will render our judgment on the creations of the groups based on the following criteria:

Clarity and completeness of the story on the wiki, particularly if it could be understood without the presentation.
Creative use of media.
How well this story ties into the overall storyline of the night.
The social process that was used to create the story.

I’m floating around between groups to listen in on what they’re doing and some of their initial thoughts.

8:30pm

Beer o’clock. The Business Rules team is still deep in conversation, however, and Business Use Case comes over to them to ask for help in bringing the business rules and business use case together. Business Use Case outlines the actors that they have identified, and the high-level business processes that they have identified in addition to the initial business process of bringing new consumer-producers online.

9pm

BPM Methodologies has a much wider view than just this project: developing methodologies that can be used across (SAP) BPM projects, including assessing the business process maturity of an organization in order to determine where they need to start, and identifying the design roles. In the context of the design slam, they will be helping to coordinate movement of people between the teams in order to achieve the overall goals.

9:30pm

Service Implementation – viewed by groups such as Business Use Case as “the implementers” – have revised the original process map from a service standpoint; looking at the services that were required led to a process redesign. They are using the Composite Designer to model the service orchestration, including the interfaces to the services that they need and external services such as FirstLook, an wind assessment service based on location data. In their service orchestration process, they assume that the process is initiated with the data gathered from a user interface form, and they focus primarily on the automated process steps. Ginger Gatling doesn’t let me leave the table until I tell them what they have to do to win; I advise them to update the wiki with their story.

9:50pm

The Collaborative Modeling group is modeling the business process using Gravity, online with a couple of participants in Europe. This is a process model from a business standpoint, not an executable model; there is no concept of the linkage between this and what is being done by the Service Implementation team. I suggest that they should head over there to compare processes, since these should (at some level) just be different perspectives on the same process.

10pm

Business Use Case is identifying the necessary processes based on their earlier collaboration with Business Rules: this has given them a good understanding of business case, goals and incentives. They’re considering both human and automated usages, and have fed their results to the UI, Business Rules and Collaborative Modeling teams.

10:10pm

Business Rules states that they’ve had to gather information from numerous sources, and the challenge is to sequence it properly: data is captured by the UI, but is driven by the Business Use Case. They didn’t work with the Collaborative Modeling group directly, but there are links between what they do and what’s happening in the process. They’re also interested in using historical usage data to determine when to switch consumers between usage plans.

10:20pm

UI and Dashboards managed to recruit a developer who is actually coding some of their interfaces; they were visited by many of the other groups to discuss the UI aspects, since the data gathered by the UI drives the rest of the process and rules, and the data generated by the process drives the dashboard interfaces. They feel that they had the best job since they could just be consumers and visualize the solutions that they would like to have.

10:35pm

Presentations start. Marilyn Pratt is being the MC, and Greg Chase is wrangling the wiki to show what has been documented by each of the groups. Half of the Service Implementation team just bailed out. I have to start paying attention now. Checking out the wiki pages and summarizing the presentations:

Business Use Case worked with the UI, Collaborative Modeling and Business Rules teams, since those teams required the business use cases in order to start their work. They developed a good written story including cultural/social background about the fictional city where the power generation plan would go into effect. They defined the roles that would be involved (where one person could take on more than one role, such as a consumer that is also a producer), and the processes that are required in order to handle all of the use cases. They did not use any presentation/documentation media besides plain text.
BPM Methodologies had excellent documentation with the use of graphics and tables to illustrate their points, but this was a quite general methodology, not just specific to this evening’s activities. They worked briefly with the other groups and created a chart of the activities that each of these groups would do relative to the different phases in the methodology. I found the methodology a bit too waterfall-like, and not necessarily a good fit with the more agile collaborative methods needed in today’s BPM.
Business Rules focused on the rules related to signing up a new user with the correct pricing plan, documenting the data that must be collected and an initial decision table used to select a plan, although no graphics or other non-text media. They worked with the Business Use Case team and the UI team to drive the underlying business use cases and data collection.
UI and dashboards created the initial mockups that can be used as a starting point for the design slam in Vienna in a couple of weeks. They worked with Business Rules and Business Use Case in order to nail down the required user data inputs, and what is required for monitoring purposes, and included some great graphics of the monitoring dashboards (although not the data collection form).
Collaborative Modeling used Gravity (process modeling in Google Wave) not just for modeling with the group around the table, but also with participants in Germany and the Netherlands. They included photos of the team as well as screen snaps of the Gravity Wave that they created, although the text of the story documented on the wiki isn’t really understandable on its own. I’m not sure that they spent enough time with other groups, especially the Service Implementation group.
Service Implementation talked to the Business Rules and UI teams to discuss rules and data, but felt that they were running blind since there wasn’t enough of the up-front work done for them to do any substantial work. They used placeholders for a lot of the things that they didn’t know yet, and modeled the service orchestration. The documentation in the wiki is very rudimentary, although includes the process map that they developed; it’s not clear, however, how the process model developed in Collaborative Modeling relates to their map.

11:30pm

And now, on to the judging – I’ll write up the critique and results in a later post.