A couple of weeks ago, I was at the first BPMG Toronto chapter meeting, along with 25-30 others: pretty good attendance for an initial meeting, although I think that 3 of them were from the host, webMethods, 2 were the speakers, and 1 from BPMG. Based on some later conversations, the split between vendors and practitioners was around 50:50, and the split between business and technical people was around the same.
Jim Baird, who is organizing the North American chapters, gave a brief introduction to BPMG; as usual, this left me with the burning question “Is 8 Omega just a silly pun on Six Sigma?” as well as wondering how the BPMG process maturity model differs from BPMM and others. There was also a weird bit taken from the Australian chapters that states that presentations from vendors and consultants can’t be more than 5 minutes; since I get slotted into that “consultant” category, that implies that there’s no perceived value in what I might talk about, and that it would just be a sales pitch. As a fairly regular conference presenter, I beg to differ.
The main event, however, was a presentation by TD Bank on their BPM projects. Like any other large financial organization, TD has 100’s of systems, a ton of manual processes and procedures, and an expectation from management that they must “do more with less”. A few years ago, this wouldn’t have been a problem, since there was plenty of low-hanging fruit for implementing some degree of automation and gaining some benefit; that fruit, however, is long since plucked, and the benefits were used to pay for point solutions (like tactical uses of Visual Basic and Adobe Acrobat) that can’t grow with the business. What they were left with were ad hoc existing systems that were “good enough” for the job at hand, and no easy business case to replace those with systems that provided both agility or reusability.
They did have one big thing on their side: an executive-level vision of continuous process improvement, which led to the establishment of a corporate competency centre in business process modelling, an enterprise licence for Pega BPM, and a workflow team within the IT group. The CIO had the insight to provide the time, money and air cover for a production proof of concept within 4 months, and it was the workflow team’s challenge to find the right first project and get something from the drawing board to production in that time frame. By applying some agile programming techniques, which I found pretty remarkable for a large financial services organization, they were able to go from concept to production in 4 months, including a month of QA, and have only had 1 defect reported to date: amazing on all counts.
Of course, there were challenges. First, a problem that I often see in projects, was the business users’ desire to include everything in phase 1 of a project, which makes it difficult to select a project and also to control scope creep. Part of the problem is that the users can have a hard time envisioning how they could do their job with only part of the functionality that they think that they require, but a big part of it is a (historically supported) dread that this is their only chance, and that the workflow team is never coming back again after phase 1. Second, they had to shift from data-centric thinking to a process-centric view in order to get the focus on process improvement rather than data processing, and found out that not everyone “gets” process thinking. Third, they didn’t fully understand the capabilities of the Pega product before they started, so likely did things less effectively — and possibly with less reusability — than they will in future projects. In particular, they’re not using the rules engine that lies at the heart of Pega for anything other than basic validations, but they recognize the need to take a closer look at that for future implementation.
Some great lessons learned:
- Define and publish common terminology (“process”, “workflow”, “agile”, etc.) for use in all project communication. It doesn’t really matter if you use definitions put forward by a standards group or by your BPMS vendor, it only matters that you’re all communicating consistently.
- Understand the capabilities and limitations of the selected BPMS, so that you don’t end up building something that you can’t grow with. I’ve seen many, many cases of over-customization of BPMS because the core capabilities of the product were poorly understood, which can lead to un-agile and non-reusable systems as well as masking many of the key functionalities of the BPMS. I’ve written (ranted) about the dangers of over-customization many times before.
- Start small but deliver value. They didn’t try to do a complete process rework, but settled for some incremental process improvement that could show some benefit.
- Understand corporate culture and how it impacts team dynamics and development approach, then pick an approach that can be blended into your culture. You’ll want to check out a couple of different approaches to see what fits best.
- Accept that you’re going to make mistakes; this requires team members to live with some degree of uncertainty, which is difficult for many people within large, conservative organizations.
- Choose team members who have a commitment to doing what’s right for the organization. I find this one to be particularly important, since it drives the decision-making on a project, but also difficult, since you need to find people who are not necessarily influenced by popular opinion or corporate politics.
A couple of odd comments along the way: it was stated that BPM is “new in Canada”, yet the project that I heard described is not different in nature from what I was implementing at Canadian financial institutions in 1994 (although the tools are much, much better now 🙂 ). Also, when I asked if the process modelling at TD was being done as part of a larger enterprise architecture modelling effort, EA was positioned as being “under workflow”, which implies that they actually mean IT architecture and don’t have a sense of enterprise architecture at this level. Because they’re using Visio for process modelling, which has a direct link to Pega, they’re not using more rigorous modelling tools that might tie in with EA modelling efforts.
Interesting stuff Sandy. Particularly interesting comment re: TD and their view of EA – absolutely chimes with what I hear from a lot of organisations, where the “Enterprise” in EA is seen as a synonym for “big” (as it is in the sales of software products) rather than as an idea about the scope of the concern.
Neil, I see that a lot: the confusion of “enterprise architecture” and “IT architecture”. I’ve written about this in the past, particularly about how EA should report to a strategic level in the organization, and be between business and IT rather than a part of IT. I think that the term architecture is greatly misused to mean a variety of things (such as programming) that aren’t architecture at all.