Skip to content

{ Category Archives } AppianForum

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.

Appian 6 application marketplaceTheir 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.

Appian 6 composite app including the ubiquitous Google mapThere 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.

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.

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.

Tagged ,

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.

Tagged ,

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.

Tagged ,

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).

Tagged , ,

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.

Tagged ,

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.

Tagged , ,

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.