Main | February 2007 »

January 2007

January 31, 2007

Forrester on BT

I heard the term for the first time last week – Business Technology (BT) versus IT.  I think it is great in that it symbolizes the challenge many companies face in doing more than symbolic coordination of IT and Business.  In my view, process creates the abstraction layer that will integrate these two areas. 

In the past 24 hours, I asked two BPM executive sponsors why they hire consultants and the answer was strikingly the same – we can’t find anyone that understands technology and process and has experience in both.  That is the skill set that everyone is looking for.

In the article by Forrester on CIO.com called IT Execs Boost Focus on Business in 2007, there are several interesting points made to support this focus:

  • 71% of respondents say that business and IT collaborate equally in setting IT direction
  • 36% said IT governance was top of mind
  • 34% said prioritization of tech investments was near the top
  • 35% identified marketing and communicating IT value as a top priority

The responding executives were focused on business efficiency, cross-unit business initiatives, migration to shared services, and BPM (17%).  This is very different focus than five years ago and a key reason why a lot more CIOs are business leaders while the traditional technologist has become the CTO.  This is also enabled because a lot more businesses are dependent upon technology so every business person has to have a deeper understanding of their core technology than they traditionally did. 

January 30, 2007

Letter Approval Process

In a previous job, I managed a direct mail program where we mailed several million pieces per year.  It was a complex process which included getting client sign offs, interrogation of data against a customer segmentation model, managing several hundred letter variations, and coordination with a inbound call center for responses.  Although we had a decent Visio diagram for our process and well defined SLAs (Service Level Agreements) and rules, a BPM system would have been ideal.

Let me just focus on the letter approval process.  Several things drove letter changes - regulatory changes, corporate branding changes, lessons learned from our campaign results, client requests, physician requests, and consumer requests.  Each letter change went through my product manager who had to sign off.  It then went to marketing for sign off which often took at least one revision back to product management.  It then went to account management for sign off.  It then went to legal to sign off.  And, many of them then went to clients for sign off with many edits in between.

If someone was out of the office or busy, this could take weeks if not months to complete while the total time of the task was probably about one day from start to finish.  The challenges were the need for discussion and supporting documentation around each change (e.g., why is it better to call someone a patient versus a member); access to the previous versions to understand other changes; and a way to know who had signed off to date.  With a BPM system, this could have been managed very easily taking advantage of the workflow, the business rules for routing and escalating tasks, reporting for understanding the status, document management, and collaboration for a discussion tagged to the process instance.

Process Rules - The Apprentice

For now, I will stick with the reality TV genre.  If you watch The Apprentice on NBC, the one thing that I notice is there is always a chaotic team versus a well executed team.  Much of this could be attributed to leadership, but a lot of it can be tied to process.  I think this gives all of us an important voyeurism opportunity.

Imagine if you could take any of your tasks at work and put two teams on each task.  One you gave little direction and a basic objective.  The other you gave clear directions, assigned roles, developed some rules, and executed against a process map.  Of course, the second would win.  The first might get lucky occasionally (a true management pitfall).  This is exactly where BPM as a management theory plays.  And, this is an insight you can get from the show.  You see how much better one team is with some process.  Imagine where you get with a fully documented and optimized process.

BPM helps you to capture the process.  It forces you to articulate what sits in your head and the head of your team.  You translate qualitative decisions into decision trees.  You allocate tasks to people which begins to define roles.  You select and articulate metrics which become reports and shared objectives.

Surprisingly, each episode offers a good nugget of business advice along with some quick lessons in management challenges.  These include:

  • Being faithful to your team
  • Focus on delivery
  • Getting organized
  • Being respected
  • Know your customers; know your market
  • Be decisive
  • Know yourself
  • Listen to your team
  • Be quick but careful
  • Winning is everything
  • Keep your eyes on the prize

January 28, 2007

The Biggest Loser

We are doing a Biggest Loser competition at work which go me thinking about applying this type of competition to processes.  BPM (process and/or technology) is about driving tangible value through process management.  This could be reduced cycle time, lower transaction costs, higher customer service, greater quality, or better compliance. 

Once a company has demonstrated the success of BPM and begun to drive conversion to this framework, it would be interesting to tap the internal competitive spirits in a Biggest Process Loser competition.  I envision a series of Work-Out (GE's famed Six Sigma process) where each team takes a process and has a 1-2 day period in which to innovate and drive out process improvements.  The team that improves whatever critical metric (cycle time, cost, service) the most wins. 

The prize could be inconsequential, or it could be something like corporate PMO or COE support to implement this process improvement.  Just a thought.

The New Bakeoff

I was talking with a company about their BPM vendor selection a month ago.  They used a smart approach to their final vendor evaluation.  Given the flexibility of the systems today and their ease of use, it is possible to select a small process and ask the vendors to build it out real-time.

So, what they did was select a process, identify some of the reporting needs, pull up some sample reports, and brought the final two vendors to them.  They gave each vendor one day to build as much of this process into the system as possible with them sitting in the room watching the process.  It taught them about each of use for the tool.  I would also introduce a few complexities to the process such as changing the process flow midday or asking for a new report at the end.

Not something you could ever do in the ERP world. 

January 27, 2007

Timing of Process Metrics

I recently read an article by Bruce Silver on Measure than Model? An Alternative Process Lifecycle.  It is a good article and one of many by Mr. Silver that you will find on the web.  He provides both a short summary of how things are supposed to work and an interesting point on a common problem.  Having come from a $16B company, the prospect of taking on Enterprise process modeling would have scared me and everyone else.  But, Bruce is right that there are processes with which you have no great visibility.  Using a BPMS to simulate these and understand the process metrics, could help provide a strategy for prioritization.

When I clicked the link, I thought I knew what the article was going to say which I think is another point.  After working with lots of clients on their KPIs (Key Performance Indicators) over the years, I believe companies may want to attack their BPM processes from a metric perspective.  Do you know the reports you want?  Do you understand what data might help you make different decisions?  If you weren't limited by your legacy environments, what reports would you look at daily, weekly, monthly to manage a process?

If you could answer all of this and understand the correlation between metrics (i.e., training drives customer satisfaction which drives sales which drives revenue), you can design and automate a process using the right process variables to capture data along the way.  Just like you don't want to automate a process you have never documented before you don't want to automate a process without understanding the metrics.

The other reason for this focus on metrics is simply the business case.  You have to have a baseline to demonstrate value to your management team. 

Ubiquitous BPM

Taking a business user's perspective, I can't help but think that driving massive BPM adoption includes making it part of our standard workflow.  Now there are still (amazingly) some executives who assistants print their e-mails for them to hand write responses, but in general, e-mail and mobile phones are the two adopted tools of the business professional.  I could argue MS Office is the third.

When I think about where BPM is going, I imagine being able to send e-mails to initiate processes.  I imagine never seeing any BPM application since everything happens through Outlook (or my e-mail system).  I imagine being able to call up and respond to tasks on IVR (interactive voice response).  I imagine getting reports e-mailed to me or being able to dial in and hear key metrics.  Some of this is starting to happen, but over the next two years, I expect to see some radical changes.   

I compare BPM to where CRM (Customer Relationship Management) was in 1999-2000.  It has a good install base and good client references, but it is just starting to get the right momentum.  I can still use the acronym and get a blank look back from people.  When I went to work for Firepond (a CRM software company) in early 2000, it was the same situation.  Two years later, most people knew what CRM was (primarily driven by Siebel's marketing machine).  Now, anyone knows CRM, and you no longer have to spell it out. 

I draw the parallel because we went through many of these same debates in 2000 with CRM.  Who is the right buyer - IT or business?  How do you make this seamless?  Does this have to change the user's workflow?  Will they use it?  Are business users technically savvy enough?  What changes need to happen to a company's infrastructure and architecture?  What industries are most interested?  What products should use CRM?  How to use these tools with your external constituents?

January 26, 2007

Power Facilitation

Back at E&Y, we had a process called the Accelerated Solution Environment (ASE).  For $250,000, we took clients through an amazing 2-3 day facilitated event that got months worth of work done with creative thinking and fostered huge buy-in across the groups.  Tons of clients did it, but it was expensive.

I lost touch with the group, but I just found them the other day.  They are now a standalone entity called Wildworks Group which offers a portable environment at a fraction of the cost...but with the same results and amazingly quick product. 

This is great for rapid requirements gathering, strategic visioning, project kickoffs, or other activities that require cross-functional participation and buy-in.

BPMG Training Comes to STL

Score one for the MidWest.  We are moving up in importance for BPM and will have several BPMG classes taught regionally along with one locally in St. Louis – May 21-24.  I have been talking with Howard Webb (www.stratisltd.com) who teaches the US classes for BPMG and am glad they will be offering the class here.

He has a great approach and leverages the 8 Omega approach that BPMG offers.  This takes a wholistic approach to BPM looking at people, process, technology, and strategy. 

To learn more about the class go to http://www.bpmg.org/gbpf_registration.php.

Process Opportunity Prioritization

The challenge we all hope to have is what to do with all the BPM opportunities.  Gartner talks about it in one of their reports.  We are working with a client that is experiencing it now. 

Once people see the simplicity and value of a BPMS (Business Process Management Suite), they start to think about all the other processes to which it can apply.  The general rule of thumb that I use is to look at processes with:

  1. High number of transactions
  2. High number of handoffs
  3. Lots of humans involved
  4. Need for compliance

But, the item I wanted to share in this write up is a tool that I downloaded from Ultimus.  It is a business process prioritizer.  It is very straightforward and looks at:

  • Sponsor's priorities
  • Process suitability
  • Technical suitability
  • Human factors
  • Business alignment

Obviously, you still need to facilitate this information from your audience and not be 100% dictated by the tool.  BUT, it is a good framework for discussion.

Download here - http://www.ultimus.com/products/prioritizer_05312005.

Lessons Learned

Healthcare Experiences

AddThis Social Bookmark Button
Blog powered by TypePad

Snap.com

  • Thanks to Snap.com, you can move your mouse over any of the links on the page and see a preview of the page before clicking on the link.