Tag: lombardi

In an amazing reflection of the economic times, Lombardi announced today that their user conference, Driven, will not be taking place in Austin as originally planned, but will be an online conference. From their email update:

For the last few weeks, we have been talking to customers all over the world about Driven – our annual user conference. The feedback has been consistent – people want to come but many companies are under travel restrictions.

So, we have decided to change the format for Driven this year. Instead of you having to come to Austin, we are going to bring Driven to you. Think of it as Driven without the travel. Actually, we are calling it Driven Online.

I assume that this means that the attendance numbers just weren’t shaping up as expected, and they had to make a tough decision to cancel the onsite conference.

It’s still the week of April 20-24th, but the content is severely restricted: a single one-hour webinar each day at 11am Eastern. It’s live, so that there will be a Q&A session at the end of each webinar, but this amount of content doesn’t even begin to come close to what would be at a real conference.

It will be interesting to see what other conferences end up cancelled this year; I can’t believe that this will be the only casualty.

Toby Cappello, Lombardi’s VP of Professional Services, led a breakout session on lessons learned in implementing BPM. He breaks them down into three categories: project/delivery, training/mentoring and program/enterprise.

Project/delivery:

• BPM is about productivity and visibility
• Metrics, KPIs and SLAs should be part of the define phase
• Don’t scope out metrics [i.e., don’t remove metrics from the scope]
• Remember visibility drives improvement
• Integrations, integrations, integrations
• Don’t underestimate and start early
• Don’t forget the focus should be on business value
• Be willing to make a trade-off for the first release
• “One and Done”
• Iterative approach…continuous process improvement
• Phase is NOT a 4-letter word
• Trade-offs, but don’t always trade-off the reports
• Requirements documents are not process analysis
• Consider all options for capturing requirements
• Don’t over-do the requirements (define) phase
• Include process analysis skills on your team early
• A project longer than 90 days is not a failure
• Self-sufficiency can extend project timelines
• Some projects are more complex
• Timelines can be dependent upon the sophistication of the process

Training/mentoring:

• Java (.Net) developers aren’t all you need
• Have the right mix of resources on the team
• Understand the value of face-to-face engagement
• Identify good pools of talent for developers (BPMC’s)
• Self-sufficiency requires dedication and commitment
• Don’t allocate partial FTE’s to the core project team
• Make sure all of the right skills are represented
• Don’t mix self-sufficiency with tight deadlines

Program/enterprise:

• Fund to value, not first release
• BPM is about CPI
• BPM should be programmatic
• Funding model should contemplate projects and the program
• Collaboration between business and IT is critical
• Consider carefully for the first project
• Do not maintain the “wall”, i.e., the physical and/or cultural separation between business and IT team members
• Leverage the playbacks
• Ownership (BPM BPMS, process)
• Processes are business-owned
• BPM is the discipline/program
• BPMS is the enabling technology

Cappello had lots of great anecdotes and examples of how these lessons have been applied at their customers, but they’re all generic enough for any BPM project; in fact, most can be applied to any sort of business-IT project.

Some audience discussion raised the point that integration is the single biggest point of risk in any BPM initiative; I’ve seen this a lot, especially in cases when you could trade off by continuing to do part of a process manually for a while instead of undertaking a time-consuming and expensive integration in the first phase. “Broad, then deep” is the way to go in terms of implementing processes.

That’s my last session for Driven, and my last conference (I hope) until September. Now I’ll have a chance to catch up on my real work (the stuff that pays the bills) as well as the partially-written product reviews that I have sitting in Live Writer.

I attended a panel with two Lombardi customers, Kim Hearn of PHH Arval and Gene Rawls of Wells Fargo, speaking about their experiences with building a cross-functional BPM capability. As it turned out, it wasn’t really a panel, it was two mini-presentations on the same topic with a joint Q&A.

Hearn started out with a list of critical success factors for BPM projects which were not fundamentally different from any project, e.g., strategic alignment, getting the team right, culture, governance. Her slides were dense with text and moved very quickly, so a bit hard to capture many of the specifics while following along, but much of this wasn’t particularly innovative in terms of best practices. By following good practices, however, they were able to reduce their cycle time of their core business process from several days to under a day, redeploy 15% of their headcount, reduce penalties and have a better workforce utilization.

Rawls was up next to discuss Wells Fargo’s experiences. I spoke to some of the Wells Fargo team yesterday, although haven’t had time to document our discussions, but this promises to be a higher-level view of how they’ve worked with BPM. They had a long time frame from their original process improvement initiatives to the acquisition of Teamworks, but eventually developed a set of roles involved in BPM projects: process leader, SWAT (their acronym for BPM initiatives) developer, BI developer, and business process owner. He walked through their process, starting with with the business identifying the need and defining the opportunity. They use an iterative lifecycle and the agile playback technique to engage the end users in the development process, building collaboration and producing new processes faster.

There was a question about production support; Hearn said that they rotate people out of the agile development team into production support in order to train the support people. Someone in the audience said that they pulled in their support people during testing, then cycled back to support when the system deploys, which sounds like it would work well, too.

Like the other sessions, there was a lot of great audience participation: everyone realizes that they’re amongst friends and talks quite openly about their issues and solutions.

The second part of the keynote was by Rich Phillips of Maritz Loyalty Programs — I saw him speak last year at the Forrester Technology Leadership conference — talking about business strategy, technology strategy and how those impact market differentiation. Maritz Loyalty Programs runs affinity programs such as credit card points programs, and hence is involved both in establishing long-term relationships with their customers, as well as providing incentives to the end consumers who belong to these programs.

He had some comments about competition and markets in their business, such as the need for speed and agility in offering incentives to consumers, collecting better information in order to make better decisions, and creating more transparency and engaging with customers in social media; he sees BPM as having a role in all of these.

Phil kicked off the second day of the conference talking more about moving from a project focus to a program focus, and reinforced that we need to reach out and engage the business people. Yesterday, when I wrote that the keynotes appeared to indicate that having IT-led BPM projects was a good thing, Phil took the time to comment on one of my posts to say that it wasn’t a good thing, but it was the current reality.

He showed us some of the UI changes to Teamworks 7, including an iTunes-like (his analogy, but quite apt) repository view in the left sidebar that’s much easier to navigate. He showed some other navigation improvements, including snapshots of processes as they are deployed in your environment, and made the point that although this is still in Eclipse, it may be unrecognizable as such: instead of just using the standard Eclipse interfaces as most design tools do, they’ve used it as a platform to build a much easier to use interface.

Teamworks is positioned as a platform for BPM execution:

• Multiple authors working together on dozens of simultaneous process applications
• A new paradigm for source control and deployment
• Built for the implications of massive asset re-use

Blueprint is positioned as a platform for BPM communication:

• Creating a culture of process information
• Rich analysis and diagramming for experts
• Rich documentation for authors and readers alike

I’ve committed to Dave Marquard (and now publicly in front of all of you) to actually spend some time with Blueprint this summer, since I have no travel until September, so watch for my results from my test drive.

Phil went on to discuss the skills that Lombardi’s services team brings to customers, and the BPM roles that they provide: program management, BPM analysis, BPM consultant, and technical consultant. They also have some new roles in their engagement team: a “client partner”, who is a non-billable resource that interfaces with the services group, in addition to the account executive. As mentioned yesterday, they have four fixed-price, fixed-outcome offerings: inventory, assessment, analysis, and playback one (which includes the transition into Teamworks).

This three-part formula — platform for execution, platform for communication, and know-how to make it all work — is the key message coming out of Lombardi at this conference.

The last session of the day was a short one with the two platinum sponsors of the conference,  Michael Melenovsky of Satyam Consulting and Hub Vandervoort of Progress Software, with a quick plug for their products and services. I realize that these guys pay a lot to be here, so I’m not going to fault them for taking advantage of this opportunity.

Something that I discovered partway through the day: the wifi in the conference area is sponsored by Capability Measurement, one of the conference’s gold sponsors. Kudos to Lombardi for coming up with the idea of hitting up one of their sponsors for this essential service. I know that hotels and conference centers charge outrageous rates for wifi, given the tiny actual cost to them to run a wifi network, and having it as a sponsored part of the conference just like the breaks and receptions is a great idea.

All in all, I’m finding the conference well-organized and useful for customers. I think that they underestimated the interest in one of the sessions, which was held in the small of the breakout rooms to an over-capacity crowd, but otherwise the logistics worked well. More importantly, there’s lots of time left in each session for audience Q&A, and the audience is participating in full. This is a small conference — about 200 customer attendees — and that size is great for encouraging people to ask questions. There’s also lots of time between sessions to allow for informal discussions without eating into the session time. The small number of attendees and the relatively narrow focus of the audience does mean that there are only two concurrent sessions so not a lot of choice, although the schedule shows a couple of tomorrow’s sessions with three concurrent sessions.

It’s another episode of The Dating Game, with three customers who mostly don’t want to be named, although I’m sure that you already know about the detailed breakout session agenda. The topic here is how different companies structure their BPM teams.

Bachelor #1 (from a large US-based automotive company) discussed how their BPM team is a split of business and IT working collaboratively. Bachelor #2 (from a global, Fortune 500 heavy equipment manufacturer) is part of a process center of excellence, also made up of business and IT working together. In both cases, they stressed how having the business and IT people on the BPM team collocated is important in ensuring that there’s the right degree of collaboration: if you’re right beside each other, it’s much easier to take advantage of the casual interactions that can occur.

Bachelor #2’s company is starting to push the creation of processes further into the business side of the team; he said that they have some processes now that are not touched by IT at all until final review and deployment, which is the rarely-realized vision of every BPM vendor and customer.

Bachelorette #3 (from a global semi-conductor company) is using the playback session technique for working with their users in order to float new ideas and get early feedback, which they have found to be a key to success. This is similar to Agile methodologies where users are involved early and often in order to fine-tune the development to meet changing user needs and wants, set priorities on customizations, and avoid any huge surprises when the system deploys.

The issues that they have include insufficient internal resources, trying to standardize processes across business units (especially in different countries), and the division of labor between the different team members, although none of these appeared insurmountable. There was a discussion around the problem with upgrades and changes to the business process, and seem to have found that they have to flush out their process before upgrading the process; this is expected to be addressed better in future versions of Teamworks, but this is a difficult problem that not many BPM vendors do well.

We had a short session just before the morning break with He-Who-Must-Not-Be-Named from a large US-based automotive company discussing their BPM projects. They’re implementing multiple BPM projects, including an engineering resource change management system, and are even using BPM to run the program of BPM projects.

Next up was a panel with Rod Favaron, Phil Gilbert and three customer executives. One of the panelists made a crack that this was either like the Dating Game or Oprah, so I’ll just refer to them as Bachelor #1 (from the afore-mentioned automotive company), Bachelor #2 (from a global, Fortune 500 logistics and relocation company) and Bachelor #3 (from a mid-western US travel company). Instead of prepared presentations, this was structured as an audience Q&A session.

Bachelor #3 responded to a question about the teams required for BPM by stating that you don’t need your “best” developers (by which I think that he means the hard-core Java developers) to do BPM development, since the development is lightweight compared to other development projects that you might have going on. Interestingly, I had a conversation with a customer at the break who has found that they have had to do a lot of custom UI work not because the Lombardi tool lacks functionality, but because their user community is accustomed to having a specific look and feel for certain applications, and is willing to pay more and wait longer to have custom interfaces developed that will eventually result in longer and more expensive maintenance cycles. I’m not at all surprised by this, since I see it all the time at my customers; although I always try to put forward the “take it out of the box and use it naked” philosophy, some companies don’t consider the trade off between the one-time hit of having employees learn a new system versus the ongoing costs of custom systems.

In response to a question about using a BPMS versus off-the-shelf software versus custom build, Bachelor #2 talked about how they use the BPMS to manage change and manage risk better, since there’s little off-the-shelf software that addresses their core business needs. They had 23 different processes across 3 legacy applications plus manual procedures, and are gradually replacing the processes in the legacy systems. #3 added that BPM also gives them connectivity across the enterprise, that is, connecting up the siloed packaged applications within different functional areas. #1 said that there are many areas where BPM should be a part of a complete solution that will combine custom-built services and packaged applications in more of a hybrid solution.

An audience member asked what to you do when the BPM projects start to move from being a business-led process improvement project to an IT development tool. This was interesting, because of Rod and Phil’s earlier statements that we’re in an era of IT-led BPM programs, and they seemed to think that this was a good thing. The customers, however, still think that business should be driving this: #3 feels that bringing together business and IT and eliminating the boundaries between them is the key to pushing this to a collaborative effort, and #2 concurred and stated that both the business and IT parts of the BPM projects report up to him, the CIO. Phil chimed in that there’s a need to break the usual application development mentality; the key thing is that if IT sees BPM as just another application development tool, it will fall into the domain of IT, but if business and IT both see BPM as a tool for collaborating on process implementation, then it will remain a cross-functional responsibility.

There was a question about failures and lessons learned during their Lombardi implementation. #2 said that they were too ambitious in terms of project scope, trying to take on too much in their first projects. #1 agreed with this, saying that the minor exceptions during those initial implementations slowed them down and forced them to reduce scope. #3 said (pointing out that this was more of a lesson learned than a failure) was that they should have started the process instrumentation earlier.

The final question was about using the BPMS as a system of record: #1 said that it’s their philosophy not to use the BPMS in that way, but to push all permanent data back to the core systems, although transient data may be persisted in the BPMS until a process instance completes. I agree completely with this, and am always uneasy when a lot of data is unnecessarily replicated into a BPMS and not synchronized back to the core operational systems.