Assuming that the logistics can be worked out, we'll be having an unconference edition of EnterpriseCamp in Toronto on Saturday, January 13th. You can find out more about it, and sign up to attend, here. From Bryce Johnson's description:

This is going to be a different focus then our regular events. This event focuses on enterprise software infrastructure, solutions and development. Topics could include Enterprise 2.0, Business Intelligence Applications, ECM, Collaboration, Employee Self-Service, Enterprise Search, Technology Infrastructure, Workflow Automation.

Posted by Sandy Kemsley at 10:20 AM in Enterprise2.0 • Web2.0 | Permalink | Comments (1) | TrackBacks (0) | Add to del.icio.us

I wrote a guest column for the Savvion December newsletter on Emerging Trends in BPM; you can find it here. In it, I talk about four areas of ongoing significant change in BPM: the interrelationship between SOA and BPM; BPM standards; the spread of process modeling tools; and the impact of Web 2.0 on BPM.

Posted by Sandy Kemsley at 03:47 AM in BPM | Permalink | Comments (2) | TrackBacks (0) | Add to del.icio.us

Between travel, vacation and the Christmas holidays, blog entries will be pretty thin on the ground until about the second week of January. Things should get pretty exciting after that however: Mashup Camp 3 in Boston in mid-January, some in-depth vendor reviews in late January (based on the blog stats, I know that everyone likes those), the ARIS ProcessWorld conference in February, and I'm speaking at ASMI's BPM Summit in March.

Posted by Sandy Kemsley at 10:20 AM in Blogging | Permalink | TrackBacks (0) | Add to del.icio.us

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.

Posted by Sandy Kemsley at 09:40 AM in BPM | Permalink | Comments (3) | TrackBacks (0) | Add to del.icio.us

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.

Posted by Sandy Kemsley at 08:32 AM in BPM • BPMG | Permalink | Comments (2) | TrackBacks (0) | Add to del.icio.us

BPM Academy, an edumarketing site run by Appian, is offering the fourth in their series of BPM webinars, Roles in Business Process Management, on December 14th. These are fairly basic webinars, but some reasonable free training.

Posted by Sandy Kemsley at 02:03 PM in BPM | Permalink | TrackBacks (0) | Add to del.icio.us

• Pushing String » Bohemian Rhapsody in the key of ID
  What happens when geeks have too much time on their hands
  (tags: music)
• Collaborative Thinking: Social Computing: From LifeStyle to Workstyle
  How social computing and Web 2.0 will impact the corporate culture
  (tags: web2.0)
• Andrew McAfee
  Arguing over what Enterprise 2.0 really means. Social software? New technology? Both?
  (tags: enterprise2.0 web2.0)
• US DoD Business Enterprise Architecture
  Tons of real diagrams of the DoD's business enterprise architecture. Via Lucas Rodriguez Cervera.
  (tags: ea)

Posted by Sandy Kemsley at 06:21 PM in Links | Permalink | TrackBacks (0) | Add to del.icio.us

I missed this story on Friday, but the Globe & Mail (and I'm sure many other sources) reported that new federal litigation rules in the U.S. went into effect Friday whereby emails, instant messages and all other electronic "documents" must be maintained by corporations and available for legal discovery. This includes things such as the contents of removable memory cards, work-related pictures on your cell phone and pretty much anything else that you do on an electronic device. This isn't hugely different than some of the existing compliance requirements, but apparently has a much broader scope in terms of content.

Compliance is one of those areas where content and process overlap significantly: the content is what has to be maintained for compliance purposes, but BPM is often used to route and track the content through the compliance process.

Posted by Sandy Kemsley at 08:23 AM in ECM | Permalink | TrackBacks (0) | Add to del.icio.us

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.

Posted by Sandy Kemsley at 08:10 AM in BPM | Permalink | Comments (1) | TrackBacks (0) | Add to del.icio.us

Mark McGregor (who I know from BPMG) is offering his ebook Winning with Enterprise Process Management for free here. I haven't received my copy yet -- for some reason, the PDF is emailed to you rather than presented for immediate download -- so can't vouch for the content.

Posted by Sandy Kemsley at 06:50 AM in BPM | Permalink | TrackBacks (1) | Add to del.icio.us