Category: process

business process management

EnterpriseCamp (the unconference edition)

I’m not sure why Bryce Johnson thought that he’d have full turnout at 9:30am on a Saturday, even for something as exciting as EnterpriseCamp, but a few of us managed to make it on time. Of course, my brain is still in a time zone some where east of here and I’m waking up at 5am so it’s easier for me this week.

We kicked off a bit late and the attendance was lower than the signups, but there were some great sessions (and I’m not just talking about mine). Like other unconferences, there was no set agenda, just a blank grid of time slots for sessions and a pad of Post-It notes; those of us interested in leading a talk outlined our topic verbally to the group, then posted it in an open time slot. The schedule was pretty fluid all day long, which fit well with the mood of the group and the small number of simultaneous sessions (3 at most, I think), but we still managed to fit in all the proposed sessions and finish up on time.

One cool thing that the organizers did was create icon stickers that we could put on our nametags to designate our interests: people tagging, if you will. They also provided great food (breakfast and lunch), a huge variety of herbal teas (important for us non-coffee types) and a notebook containing some Enterprise 2.0 articles and the all-important key to the people-tagging icons.

The first session that I attended was Carsten Knoch talking about bringing Web 2.0 features into the enterprise, which was a perfect lead-in to my session on a specific example of this, namely, integrating Web 2.0 functionality into BPM software. Carsten talked more in general terms about what features and techniques could be introduced, techniques for building applications, and why all of this Web 2.0 stuff is scary to the enterprise. He had a pretty comprehensive presentation, a bit unusual for an unconference, and I hope to see it posted somewhere.

I followed immediately after Carsten, and although I had the best intentions to prepare a little presentation the night before (but ended up out for dinner with friends) or at least a few notes on the subway on the way to EnterpriseCamp (but ended up chatting with a South African backpacker on his way around the world), I took the floor with a blank flip-chart and wrote four lines:

  • tagging
  • RSS
  • zero footprint
  • mashups

I then riffed on each of these, with lots of great input from the audience, with my focus on how they apply in the world of BPM but some expansion into other types of enterprise software. Great discussion: I love it when I can learn something while giving a presentation. I could have gone on for hours, except for the smell of pizza wafting in from the lunch area.

In the afternoon, I sat in on Tom Purves and Jevon MacDonald discussing adoption of Web 2.0 technology (specifically their product, for the most part) within the enterprise. That evolved into a discussion about Consulting 2.0 and a variety of other topics.

I also attended Bryce’s session on tagging, taxonomies and folksonomies, which generated some really interesting discussion. The idea of creating tag relationships rather than tag pruning as applicable to Enterprise 2.0 tagging applications: you want people to be able to add tags that are meaningful to them, but if others are using different tags that mean the same thing, find some way to relate the tags.

Definitely a worthwhile way to spend my Saturday. Many thanks to Navantis and Microsoft for their sponsorship of EnterpriseCamp.

EAI Journal…no, BIJ…no, BTI

A couple of years ago, EAI Journal — a vendor-supported but generally useful free publication — cast off an overly-constraining name and became the Business Integration Journal (BIJ) (I’m not sure of the exact date, but it was recent enough that if you go to the old EAI Journal URL, it still takes you to the BIJ site). Now, they feel that another name change is in order, and are becoming Business Transformation and Innovation.

I totally understand the switch from EAI Journal to BIJ, since EAI was fast becoming a term that defined only a narrow part of the market, and the publication really addressed the entire range of integration technologies, but my problem with the new name is that it doesn’t actually mean anything.

I would publish a brief excerpt of the editor’s explanation of the new name and mandate, but they don’t allow copying from their PDFs, so you’ll just have to read it for yourself. Basically, it’s along the lines of "first magazine of its kind", "Senior Executives", "working together to quickly adapt to changing business needs", and "maintain competitive advantage". Yeah, yeah. And, they want you to go to the new site and subscribe again, even if you’re already a subscriber, since it’s a "brand new magazine", although when I went to the site, I realized that it’s because they want you to –wait for it — PAY! Even for the digital version! Hahahahaha.

There’s a ton of free information on the web of the same calibre as EAI/BIJ/BTI, including what you’ll find here on ebizQ, on BPM Institute, and even on direct vendor sites such as BPM Basics: short articles, typically written or sponsored by vendors or consultants, that can help to supplement other sources of information such as analyst reports or personalized research. I’m not saying that articles written by vendors or consultants don’t have value, but I am saying that they are fundamentally a form of marketing for the company in question, and I have the same aversion to paying for them as I do to paying for a t-shirt with a vendor logo on it.

BPMG Toronto: Implementing Pega

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.

10 Things You Can Do To Improve Your Business with BPM Right Now

A bit of a wordy title, but it’s actually an article over on BPM Enterprise written by Jeff Mills, VP of Channel Development and Marketing for Bluespring Software. He discusses the following 10 points in detail, with ROI approximations for each:

  1. Eliminating mundane work
  2. Sustaining compliance
  3. Extending out enterprise applications
  4. Simplifying people’s jobs
  5. Reducing risk
  6. Knocking out process-related “pain points” or nits
  7. Establishing full visibility into how your business operates
  8. Building an agile infrastructure
  9. Reducing the burden on IT
  10. Building a process infrastructure

Some of these, such as eliminating mundane work, are the low-hanging fruit that may have already been plucked in any process improvement project, but others, such as compliance and risk, will serve to enhance the relatively new compliance procedures that may have been implemented within an organization. The last three are more forward-looking in terms of enhancing the infrastructure, although they don’t mention SOA, which would be a key part of any infrastructure rework these days.

Mark your calendar: BPM Think Tank 2007

I attended this year’s OMG BPM Think tank, blogged extensively about it, and generally concluded that it was a great conference with excellent opportunities both for learning and for participating. The dates for the 2007 BPM Think Tank have now been announced as July 23-25, with a general theme of “Developing Your BPM Success Factors Roadmap” (a buzzword-enabled conference title if I’ve ever heard one). No venue announced yet, although the last two were in the Washington DC area.

From the announcement email:

The Object Management Group™ (OMG™), in partnership with BPTrends, and OMG’s BPMI Steering Committee encourage you to “Save the Date” for BPM Think Tank 2007: Developing Your BPM Success Factors Roadmap. The event will be held July 23-25, 2007.

This popular annual event will once again feature presentations by leading experts and roundtable discussions actively involving attendees. BPM Think Tank 2007 will gather together experts and practitioners alike to discuss the practical application of BPM standards, technologies and practices to achieve successful business results. A unique format with roundtable discussions, as well as technology exhibits, case study presentations and expert panel sessions, will allow participants to gain uncommon insight into BPM in the real world, within the standards community, on the IT drawing board and in the process owner’s office.

This year’s theme, “Developing Your BPM Success Factors Roadmap” will focus on issues of interest to those who have recently started a BPM initiative or who are just now evaluating BPMS (Business Process Management Systems), as well as those experienced with BPM who want to get to the next level.

Conference Overview

BPM Think Tank 2007 will feature a full day of beginning tutorials and two days of advanced roundtable discussions with experienced “been there and done it” people, leveraging their knowledge to develop real-world roadmaps for delivering business value using BPM. At BPM Think Tank 2007, learning will be action-oriented around a success factors template.

For businesses, the case study approach will be used by presenters from businesses that have implemented BPM and have real “lessons learned” to share. Participants will discuss those lessons, the costs and the benefits with their peers, as well as gain an understanding of the practical value of BPM standards.

For vendors, participants will interact with other vendors who have implemented BPM technologies and competed in the market. Participants will discuss not only the “whats” of the main BPM standards, but also the “hows,” the “lessons learned” and the “shortcuts.”

The unique, highly interactive BPM Roundtables are small group sessions moderated by subject matter experts who will facilitate group discussion around specific topics as diverse as BPM Project Governance and A Roadmap for BPMN. Presenters will include technical specification authors, as well as senior process managers and individuals in charge of their company’s IT architecture and application development. These BPM Roundtables have been a highly acclaimed feature of the BPM Think Tank in the past and clearly differentiate this event from others in the BPM marketplace.

This year’s BPM Think Tank 2007 is being co-chaired by Phil Gilbert, Chair of the OMG’s BPMI Steering Committee and Paul Harmon, Founder and Executive Editor of BPTrends.

For more information, visit http://www.omg.org/e-tt/. BPM Think Tank 2007 is produced by the Object Management Group in partnership with BPTrends (www.bptrends.com). Exhibit space is available; for more information contact Kevin Loughry at [email protected], +1-781-444 0404. Sponsorship opportunities are available; contact Ken Berk at [email protected], +1-781-444 0404.

Podcasting the future of BPM

As the year draws to a close (okay, I admit it, I’m already in holiday mode), there are inevitably the articles and blog posts about “the future of [insert anything here]”, and BPM is no exception. TIBCO’s doing this with a podcast, where Jeff Kristick, their VP of product marketing, gets together with Peter Fingar, author of BPM: The Third Wave and Janelle Hill of Gartner.

Unfortunately, it’s not an interactive conversation, but rather a series of clips from interviews, so the moderator talks a bunch, then inserts a clip from Jeff, then talks some more, then a clip from Peter, and so on. Still, there’s a lot of interesting concepts in here for 15 minutes on the treadmill with your iPod, such as the notion that BPM implementations remain tactical in nature and departmental in size because the industry has failed to produce a standard BPMS based on an abstract BPMS data type, which would allow end-to-end process management. Janelle Hill has some good words to say about process agility, and how the shift to explicit process management allows organizations to perform constant incremental process improvement rather than a single big bang approach once every 10 years. She goes on to say that by building process models and creating process visibility, it raises the awareness of all the process stakeholders and sparks further improvements and better designs: in other words, get something in there to start, then let the process participants decide what should be done next, a strategy that I always try to use in BPM implementations.

You can find all the podcast landing page here, or a direct link to the MP3 for this podcast here.