About  |  Benefits  |  Join  |  Online Training  |  Training Courses  |  Certification  |  Wiki  |  Contact

All site blogs

Process Excellence - Recap from Dubai IIR Summit

The recent IIRME Process Excellence Summit was a great event. Speakers were drawn from the local region and internationally with a number of compelling real world case studies and highly refined observational perspectives from industry experts.

I was very impressed with the caliber of speakers and the results produced in many of the case studies (no theory here folks, this was real results from life in the BPM trenches!). The EFQM presentation on their quality framework that is making such a big impact in Europe (and beyond) highlighted the focus of organizations as represented by event speakers where more and more we are addressing all of the stakeholders in our process approach-customers, the organization, employees and society in general.

If you were not able to attend this event, you missed a great opportunity to learn a lot about what others are doing, the results they are acheiving and the lessons they have learned. Oh, and the IIRME team did a great job of running the event leaving speakers and participants the freedom to engage in the learning experience, not in being distracted with "non value add" event details :)

For my opening presentation, I presented a simple model for Process Excellence but one that I think highlights the holistic nature of what process excellence is really all about. Much of what I covered was simple "not in our conversation" in preceding years, so I think it was a sign of the times in how we are maturing our approach to process excellence.

The model is presented here, and I'll cover it in quick overview to give you a sense for the perspective taken. But before I do, let me point out that without pre-event colloboration I found that my opening keynote was reinforced throughout the event by the other speakers and participants. I'll chalk that down to "synchronicity" as I certainly didn't influence the presentations of the other speakers-their presentations were prepared long before hearing my thoughts on the matter!

Process Excellence Model

Focus - the focus of the process is an outcome, or better, a desired outcome. This is the strategic component of the process from which we can derive the organizational and/or process consumer's (customer, internal customer) KPIs. Focus often comes from an existing undesirable outcome however, regardless of why the outcome is identified it sets a stake in the ground for defining the process behind the outcome.

Alignment - if we know the outcome-actually, the desired outcome-then we can challenge the process behind the outcome to ensure that everything that is in the process (activities, workflow, rules, assumptions, data integration, automation, and so on) is aligned to achieving the outcome we desire. Alignment is a process improvement activity, and is essential to maximizing process value.

Relevancy - this is a new area for some of us, but it is growing in our awareness a critical aspect of process. Is our process relevant to ALL of the process participants? The PEOPLE who consume the outcome, do the work, conduct analysis, manage operations, make strategic decisions, and develop ongoing strategy? Is the information we provide directly pertinent to their needs and wants? Are interfaces intuitive to their purpose? Does the process make it easier for them to succeed? Relevance is a critical apsect of process; what effectively determines if a process is "functional"or "disfunctional." This is the "place" where work gets done, and relevance to process participants-in many ways-determines whether (or not) our preceding work yields real value (or not.)

Support - finally there is support, which inlcudes our use of technology to support process and when done sucessfully will directly support-and augment-the focus, alignment and revelancy of our processes. This is really where the "gap" between operations and technology exists that is talked about so often, and it (as with each aspect of the model) it is either done right or we subject the entire process plan to a level of risk that could preclude the creation of value from our process initiative.

I know its a very brief overview of the components of process excellence, but I think it helps us place our process intiatives into perspective. The opportunities to achieve significant gains from process practices remain the best place for us to improve our organizational success and I think this model helps us understand what we must do to achieve that success

3 Days in the Bus Lane*

* The CEMM approach is used as part of ITSM On-Ramp Services to establish a Business Lane for ITSM Road Maps. Watch for the second edition of Establishing a Business Lane for your ITIL® Road Map - A Pocket Guide to CEMM for ITIL®

Having recently taught a Certified Process Professional (CPP) class based on IPAPI's Customer Expectation Management Methodology (CEMM) I wanted to log some thoughts on the experience. Since I also teach ITIL® V3 Foundation and Intermediate classes, there were some observations I thought I'd share.

Day 1 Process Optimization

Any class that discusses 'process' is likely to mention people like Deming,  Juran, and Normann and this class was no different in that respect. The ITIL® publications also mention these process legends, including Deming's 'white space', Juran's work on 'fit for use' and Normann's 'value creation'. However I don't recall hearing DaVinci and Einstein mentioned in ITIL®:

"Simplicity is the ultimate sophistication" - Leonardo DaVinci
"Make everything as simple as possible, but not simpler" - Albert Einstein

In an world of never-ending complexity, this should appeal to IT.

(Note to self:  remember to talk more about CEMM's use of pattern recognition in the next class. When I first heard this I admit I kind of rolled my eyes, but the methodology's use of these techniques is much more apparent to me now. It is very easy for processes to get so complex they become a blur; the new templates really helped to visualize the patterns of diagnostics in the process landscape. It's easy for those new to the methodology to miss this.)

In an increasingly complex IT world, simplicity should be a welcome improvement and I will point this out more in future classes.

The second thing that struck a chord was the focus on eliminating the causes of work and/or customer dissatisfaction rather than the effects. Having background in root-cause technologies this naturally appealed to me. Think about it --- does fixing the effects really simplify things?

The last thing about the introduction that was very welcome --- and in fact was specifically requested as an objective for the class by the attendees --- was the prescriptive nature of CEMM. It is a methodology; ITIL® is not prescriptive and is simply 'guidance'. Another welcome improvement!

During the review and case studies for Optimization, there were several observations and comments.

Understanding what we mean by a Moment of Truth is critically important, and reading Jan Carlson's book is highly recommended. It's actually a simple, short read, would help students be prepared, and I was able to get it from my library (no cost).

The last observation I had was the use of Process Actors as an aid in mapping IT systems to business processes. This is not only useful for linking technical and business service catalogs, but the optimization method seeks to simplify and remove unnecessary 'touch points' that only complicate an already complicated IT service infrastructure.

Day 2 Process Alignment

When people involved in ITSM/ITIL® projects hear words like 'alignment' and 'customer' they are often thinking of aligning IT with their (internal) business customers. While the techniques used in CEMM apply to both internal and external processes, its real power comes from 'outside-in' thinking; its focus on the external customer.

Not surprisingly, there an abundance of common ground here with ITIL®, particularly the new Version 3 guidance. Take the Service Strategy publication as an example:

"Customer outcomes, rather than specifications, are the genesis of services." page 4

"Value is defined not only strictly in terms of the customer's business outcomes; it is also highly dependent on customer's perceptions. ... Perceptions of value are influenced by expectations. ... What the customer values is frequently different from what the IT organization (or business) believes it provides. Mind the gap." page 31

Most, if not all, ITSM/ITIL® adoption programs I've seen are IT driven initiatives. Drawing the business' attention inward to 'the system' or 'the process' can increase the natural tendency to have an inward view.

The use of Moments of Truth and Successful Customer Outcomes is fundamental to the CEMM approach. The use of simple formulas to weight these customer 'touch points' is easy to understand and keeps things centered on the customer. This drives "outside-in" thinking throughout any element of the methodology.

This can be used by IT to get focused on their internal (business) customers, but doing so before the business has engaged the methodology to ensure they are focused on external customers simply does not make sense to me.

The Business Lane must start at Level 1 (top-down) business processes and drive optimization, alignment and innovation activities from that point. The CEMM approach is ideally suited for this. It gets the business involved at a strategic planning level and leaves the details to the appropriate IT and business staff.

Using Key Performance Indicators (KPIs) for Successful Customer Outcomes is also an important element of the method, and is consistent with other alignment techniques, such as Cobit and ITIL®. In fact, use of CEMM can help ensure that controls are 'customer aligned' and not inadvertently creating more work or risk to the customer.

At this point we also introduced Process Activity List Modeling, which is pleasantly different than establishing a detailed "As-Is" process model. A great way to keep it simple and get consensus on 'the process' so we can move on to optimization, alignment or innovation as required.

Identification of process risk was also simple and centered on the external customer, quickly identifying potential areas that may warrant further controls or inspection.

 
Day 3 Process Innovation

The last day went by quickly. The way we stated our Moments of Truth suddenly became very apparent. It is likely (and recommended) that an initial optimization and alignment 'pass' be taken prior to an innovation workshop; this enables greater understanding of the process landscape and should bring greater clarity on SCO statements and Moments of Truth.

However, it's easy to see that once an organization has committed to CEMM that an innovation workshop could be conducted anytime. This can help facilitate strategic planning and Service Portfolio Management.

Conclusions

The use of simple worksheets and action plans was extremely effective, and provides simple tools that can be used to facilitate the methodology. The action plans provide a basis for developing a very well targeted business case for improvement, quickly and with laser focus on the external customer.

CEMM is extremely well suited as a simple, effective planning tool for optimizing, aligning and innovating business processes. It could easily be used for internal processes as well, however it seems to me that the business should align with the external customer before too much internal process improvement begins. Otherwise you risk staying mired in an 'inside-out' paradigm.

Services must be defined from the top down. This demands that there be a Business Lane for your ITSM/ITIL® Road Map. For me, the CPP classes and the CEMM approach is that road.

A 'second edition' of the Establishing a Business Lane for your ITIL® Road Map pocket guide is already in the works, and another NY training class is planned for later this year.

I the meantime, any questions or comments about CEMM as it relates to ITSM and ITIL® are more than welcome.

Size Matters for Project Teams in Knowledge Work

When it comes to getting work done, the old saw is to put more hands to the plow.  This makes perfect sense in the classic sense of work.  If you’ve ever moved from one home to another, you understand that, generally speaking, more people make it happen much faster and better.  However “knowledge work”, as it has become known, seems to operate under a different set of wisdom.  In knowledge work, more hands can actually mean less gets done.

The late Peter Drucker introduced us to the concept of the “knowledge worker” in the 60’s.  He made some amazingly accurate observations about that demographic group and how they get work done.  The concept of knowledge work is significantly different than other work; yet we have a tendency to approach all work with the same tactics, and as Drucker explains, this is often flawed.

In addition to the “more hands” approach, many organizations want maximum buy-in for projects and tend to include as many stakeholders as possible in hopes of better results.  Yet our experience is often quite the opposite; research has concluded smaller team sizes are more effective.  Much of the research has said project effectiveness takes an exponential drop at 20 or more people, and the most effective teams were teams of five or less.  Indeed, more hands do not make the project go faster or give us better results.  In fact, the projects tend to take proportionately longer and the results are often convoluted compromises which tend to expand the ineffectiveness.

So is there a magic number for knowledge work project teams? I think there is.  In my consulting and coaching of BPM related content, I have often been asked if there is a magic number and started to think about it.  Yes, I have come to a definite conclusion about this question.  It’s not in any way a clinical or scientific conclusion.  I’ve arrived at it purely by years of observation.  I believe there is a magic number and it is three.  Any more or less and both the team effectiveness and project results diminish.

Why not four or five?  My observation of project teams with four people is that, generally speaking, one person will tend to sit back and let the others do the bulk of the work.  In a sense, they actually seem to check in and out of the project and thereby create “drag” on the project.  They often need clarification, ask questions which have already been asked and answered, or challenge something which has already been challenged by the core group.  A fifth person follows suit with the fourth and drag becomes exponential from there.  If you reflect back on projects where large numbers of people were involved, there were really three people who contributed the majority or core of the work on the project.  Sometimes the comment is made that the project is dominated by those three people.  I now believe there is something much deeper and less Machiavellian at work here.

Why not two or one?  Well, obviously one person does not make a team.  Yet the efficiency of a team of two is incredible.  There is often little disagreement with two because of the normal social pressure to get along.  Two people do not seriously challenge each others ideas and the project suffers.  While I see teams of two crank out more work in less time than any other team size, the work product is consistently lower quality and more highly prone to mistakes or failure.

What about projects so large three people can’t possibly get it done in a reasonable or required time frame?  I firmly believe three people can get a huge amount of work done.  However, I concede there are projects so large more hands are needed.  I recommend breaking up these projects into logical chunks and assigning groups of three to attack the chunks. This seems to work nearly as well.

Indeed, for best results, keep your knowledge work project team sizes to three people and absolutely no more than five. 

Business rules – control versus intent

I recently had some interesting conversation on business rules - how the way we think of business rules has actually created many of the challenges we face in business process management. The essence of the conversation is that there are two categories of business rules that exist in most organizations; those that act to control work and those that act to direct intent.

While I believe the distinction between these two categories of business rules is not something we formally recognize, there is little doubt that they both exist in every organization.

Control

Business rules used for control, as I would define them, are those business rules we expect our organization to follow rigorously. Exceptions for control rules require formal acknowledgement, via a programmatic exception handling sub-process or approval. For the most part, control rules are inviolate. They are the rules we expect the people in our organization to follow based on what each rule tells us we must do.

BPMS, BRMS and enterprise applications products are often used effectively for these rules, creating executable software with these rules embedded within them. For example, the quoting of customized goods or services could follow a specific rule set to determine product price. Exceptions for pricing other than what the rule set dictates, if this option exists at all, would likely be handled through a formalized exception sub-process.

Intent

In contrast, a set of documents that provide a pricing matrix could exist instead of a formalized pricing rule set in software. A given company could operate under an adapted rule that is driven by sales goals, with exceptions (pricing adjustments) commonly ‘ignored’ as long as sales goals are met. I have seen this before, many times, where the organization has a set of unwritten rules that people know and apply on a regular basis.

The intent of the pricing rules in this case could be interpreted as ‘we need to make sales goals and our pricing should be as close to this as possible.’ Exceptions to the pricing rules are driven by what is accepted by management. These exceptions suggest that the definition of the real rule in place is more complex. The rule is really “we need to make sales goals, ideally at a certain level of profit but at the same time to keep a certain volume moving and with the caveat that volume can offset profit percent, and this pricing is what we really want to be as close to as possible.”

What I want you to observe is that this rule can be almost infinitely complex. When sales are down, the rule may be relaxed more. If sales are up, nearing production capacity, the pricing matrix may be more strictly enforced. Closing business with an important new client might skew the pricing model even to a loss. It is, in affect, a subjective rule that acts as a guide line to achieve an outcome of sales levels and related profit.

Another example of intent-based rules relates to operating procedures. It amazes me that all organizations have rules in place that tell us how to do things, yet they are largely ignored and rarely enforced. The intent may be to comply with external regulations or it could be how the organization has decided certain things should get done. These rules are always documented but often times they are not enforced, or if they are enforced that enforcement is the creation of “documentation” to support rule compliance. Let’s face it, when anyone reviews adherence to procedures, how do they do that? They don’t take the time to observe people at work, the audit the “paperwork.”

A rule of thumb

The takeaway I have from this is that codifying control rules makes complete sense while codifying rules of intent has the potential to produce serious negative consequences. While it may seem logical that codifying rules of intent is beneficial, the realty is that doing so will immediately create a need for organizational change and the consequences can negatively impact performance and morale.

Where rules of intent need codification, i.e. “we need to follow that rule,” then there is a need to factor in education and training to the people affected so that we can successfully go through the change process with at worst a temporary negative impact on performance and morale.

Perhaps if we take the time to think about the rules in our organizations we will find that many rules of intent can remain as they are. I suspect that this is necessary, as people are not machines and they will develop unique work patterns as part of human nature. Control rules are relatively easy to deal with. Rules of intent are far more challenging, requiring us to think hard about the purpose of the rule and the best action we can take (which may be no action) to achieve the outcome the rule exists to serve.

BPM Suites: Functional, Cross-functional and Dysfunctional

[note - this article is provided by research/analyst firm Hydrasight who I am working with in respect to process technology research]

Hydrasight research confirms that business process management suites (BPMS) continue to be seen as an important component of functional process improvement in many organisations and, to a lesser extent, for cross-functional processes. However, we also observe that many organisations continue to be challenged by their own immaturity with implementing both functional and cross-functional process improvement. This is due to the difficulty associated in codifying processes that often lack sufficient detail or have complex exception handling requirements.

Hydrasight believes that the use of BPMS technology, on both functional and cross-functional processes, can be an appropriate application area for BPMS products. Most BPMS products now offer capabilities to support complex process flows, systems integration, authoring of business rules, automation, operations visibility and modeling standards needed to successfully implement these business processes. However, we caution IT organisations (ITO) and business professionals to recognise that BPMS products provide little support in respect to defining accurate process models where such definitions do not already exist or where processes may be unsuitable for codification (e.g., discretionary decision points).

Hydrasight observes that leading BPMS vendors offer ‘business friendly’ tools to aid users in functional and cross-functional process definition (e.g., Lombardi BluePrint, Metastorm Provision). However, we note that process definition for complex processes, and/or processes unique to the organisation, remains a challenge with all BPMS products. Our research confirms that developing a process definition that accurately represents the way work is performed and optimized to achieve desired process outcomes is the single most important factor in determining results gained - whether BPMS automated execution is utilised or not. Hydrasight further notes this is symptomatic of a larger issue where improvement practices such as Six Sigma and Lean also experience significant difficulty in producing desired results on processes not already clearly documented and understood. From our research, we believe this a key factor in limiting the potential of BPMS products to become the foundation of the integrated process enterprise and of process improvement initiatives in general.

Hydrasight research shows that organisations successfully adopting BPMS often focus on processes that are already well-documented or where best practice process models are readily available, diminishing the value of the dynamic optimisation capabilities of the automated suites. This is often due to greater availability of best practice models and the disconnect between ad-hoc business processes and those that are already codified/encapsulated in software applications (e.g., human resources management as one example). Hydrasight research shows that having access to best practice and/or existing process definition does not guarantee success. We further observe that even when extensive ‘as is’ research is performed before producing a process model, results may still not be consistent with how the process ‘really works’ due to the subjective nature of the people involved (e.g., both interviewers and interviewees).

We typically observe that cross-functional processes are rarely well documented or clearly understood in the majority of organisations. This is further complicated by multiple stakeholders with different functional perspectives. The rise of interest in business process management has prompted many organisations to begin looking at these processes with the intent to support them in a more programmatic way. While we recognise the value of this approach, and the efforts to bring cross-functional processes under programmatic control, Hydrasight cautions organisations that the challenges are great—and that outcomes often fall far short of business expectations.

Hydrasight foresees that the subjective elements of BPM, such as the interpretation of process definitions and/or execution decision points, will remain one of the greatest challenges for organisations to face in leveraging the potential of BPMS products. We caution ITOs and business professionals to ensure they pay close attention to the importance of designing process models that accurately reflect how work ‘really gets done’—or how it will be done if the process includes moving to a ‘to be’ state of improvement. Moreover, we advise organisations to thoughtfully consider the role of the tool versus the general benefit of process improvement, whether automated or not. In general, we recommend a proof-of-process approach as opposed to a proof-of-concept approach. This assists in avoiding project ‘failure’ being directly linked to the tool, rather than the way the tool has been implemented by the business [what's wrong with a proof of concept]. In either case, Hydrasight observes that codifying an inaccurate process model is likely to lead to failure that extends beyond the intended process goal into issues of diminished confidence with BPMS products, other processes in the organisation and the IT organisation in general—whether they are directly involved or not.

IT needs to pull their heads out... and get in the Cloud

It’s hard to accept the fact that sometimes we are part of the problem. Especially when we have typically been recognized as a key part of delivering solutions. As I teach the CEM Methods around the globe, I hear a consistent message from students when it comes to setting time estimates for Action Plan ideas which involve IT in their companies. The consistent message is they must add at least six months to one year for any project involving the IT Department. This isn’t just bad news; it is sad news for me as one who has spent most of my professional life in IT providing solutions. I cringe when I hear these words, yet I know they’re true. I’ve seen it become more prevalent over the last 5-10 years. It’s now becoming a very serious problem for organizations everywhere; it is at risk of giving IT as a discipline the reputation as the new impediment to organizational competitiveness. IT used to be part of the answer. Now it’s part of the problem and often the bottleneck to necessary change in most organizations.

 

In a practical way this translates to some great process improvement opportunities getting sidelined in deference to non-IT related solutions which can be implemented much more quickly and inexpensively. Frankly, the problem goes even deeper. Processes which have already been deeply embedded in information technology (and now suffering the imminent and immutable need for change), often require resources from the overloaded IT department and thereby languish for lack of attention.

 

Why are IT departments in this overload situation in the first place? Some of the reasons you will hear are: Not enough budget, shortages of skilled personnel. I don’t have the numbers, but I doubt it is really the lack of budget. From what I hear out there, IT spending as a percentage of revenue has never been higher. I think it has more to do with the classic approach of treating symptoms or fixing effects, rather than focusing on and fixing root causes.  And it has even more to do with the misguided idea that nothing can be done better outside as well as it could be done inside. The notion we have to have complete in-house command and control of every bit and code. It’s a nasty form of NIH (not invented here) syndrome.

 

Where does this attitude come from? Some of it comes from fear. Fear that we may become irrelevant in our jobs. This has a natural effect of protectionist behavior. It also comes from pride and arrogance. We are painfully aware of how fast the technology changes, yet just because we have performed well in the past is no indication we will do well in the future. The technology landscape is changing, as is the business landscape, and what worked for us in the past is absolutely no guarantee of future success. There is no room for arrogance or protectionist behaviors if we and our organizations are going to survive.

 

I know this because I witnessed it once before. My career beginnings in IT were in the mainframe world, which was characterized by heavily centralized control.  By the early 1980s, it became unresponsive to change, and slow to provide needed resources.  Along came the Personal Computer, providing flexible and available computing resources as needed. Even IBM didn’t understand what the demand would be when it was developed. IT shops everywhere fought the PC invasion, but in the end had to accept and then support them.

 

It’s happening again, my geeky comrades, and fighting it won’t defer it and won’t further you or your cause. Your internal customers need what you aren’t giving them, and it’s only because they understand what the real customer wants and real customers will go somewhere else if they don’t get it. Instead, we need to embrace what is coming and find what best serves the needs of our organizations and their customers.

 

I'm not one of those in the "IT is Dead" crowd.  IT is not dead or dying. However it is making a huge, if not monumental shift.  Eric Schmidt, the CEO of Google put it succinctly: "Don't fight the Internet."  Its corollary: "Don't fight cloud computing." The sooner you embrace the cloud computing concept, the better off everyone will be. Don’t fight “the cloud.” Embrace it! Bring it on!

 

New Partner BPM International Holds Staff Training in Amman

IPAPI’s newest partner in the Middle East, BPM International (www.bpmintl.com), held both CPP and CPM training courses for their consulting staff in Amman, Jordan last month.  Amman is such a beautiful place and although the weather was on the cooler side, I had the opportunity to enjoy the city scenes as well as its urban beauty.  The food was amazing and the hospitality unmatched.  I had so many wonderful things to eat, which I can’t remember the names of, but I’ll never forget the flavors.  One thing I can remember was something my very gracious hosts called “Explosion.”  It certainly was an experience.  They didn’t ask me to eat it the traditional way (with my hands), but it was an exceptional experience.  I am very appreciative of the outstanding hospitality I had there.

When I was not taking in the Jordanian sun, sights, food and exceptional hospitality, it was my privilege to guide these excellent students through the CPP and CPM course materials.  I was equally impressed with the hard work and attention paid by the BPM International staff in their training.  They gave the case studies their best efforts and proved they could squeeze significant amounts of improvement from these challenges.  These guys will do incredible feats for their customers in terms of process Optimization, Alignment and Innovation.

BPM International CPP Graduates - Amman

Congratulations to the fine gentlemen at BPM International.  I would wish you all luck, but you’re good enough you won’t need it.

 

Financial Institutions and IT Strategy in an Economic Downturn

IT Strategy for Financial Institutions

What should our IT strategy be in financial institutions as we move forward in 2009? Does the current economic downturn change what we do or how we do it? What strategic imperatives should we be embracing and what initiatives (if any) should move to the back burner? For answers to these questions, and more, read on...

1) Support Current Infrastructure

For starters we must continue to service the current infrastructure and we need to look at IT activities behind that service for quick win optimizations. Service the status quo while freeing up any internal resources that you can right now.

2) Improve Customer Satisfaction

In a “down economy” it is imperative that IT expand their horizons and become involved with improving the Customer Experience. And yes, I do mean the business’s customers not “internal customers.” While this is what we should be doing all of the time, when the economy drops like a chunk of lead in a vacuum it is what we must do to survive.

How can you do that? Start by identifying ways to improve the customer experience. Your customers are the only thing keeping you in business and making sure they are satisfied customers is the only way to keep them your customers.

Rule 1 – Makes things easier. Look for ways to “capture” individual customer interactions that may be repeated, both online and with the front line service people of the business, so that they can be done quickly the next time. For example, if a customer goes through the process of issuing a wire transfer if they need to issue a wire transfer to the same recipient again, don’t make them reenter everything!

Rule – Make things simpler. For example, is there something we could do to reduce the “processing time” for drive-through teller operations? These always seem to take far more time than necessary. Can technology play a role in improving that experience?

Rule 3 – When making things simpler and easier they will reduce operating costs or they ARE NOT simpler and easier. The simple fact is that Customer Satisfaction comes from simplification of “customer processes” and when we simplify customer processes it costs us less to operate and support them (their simpler!). Rule 3 is there to help perform a sanity check on what we “think” means easier and simpler for the customer.

3) Become Involved in Elevating the Customer Value Proposition

Get out your MBA hat and start thinking “business” folks. Who are the stakeholders in the real game and what do they care about? How can you impact that in a positive way?

Key stakeholders are Shareholders, Executive Management and Customers. So we need to raise the CVP (Customer Value Proposition) in a way that increases shareholder value and fits into Executive strategy – oh, and that makes our customers love us...

Reversing that we have the real success formula. Make our customers love us in a way that helps increase shareholder value. With that you have executive strategy. Add in the fact that companies who do this will be perfectly positioned for expanded market growth in the economic boon to follow and we have a very enticing formula for success.

4) Innovate, Innovate, Innovate

What can we do? Innovate my friend, innovate. What do customers care about now? They are worried about retaining their assets, lifestyle and financial position.

Could we offer programs on a bi-monthly, weekly or daily basis for automatic withdrawal loan payments that would reduce their monthly outlay without affecting our cash flow negatively? That’s possible.

What about offering one, two or three months of no payments on certain loan types to our loyal customers by pushing loans out a bit further? Could we do that? Capital One has done so on a number of their products. If our position is strong enough to do things like this it would certainly improve our customer loyalty.

What else can we do to make our customers’ lives simpler, easier and more successful? Have you seen the recent move by Virgin? (here goes Sir Richard – AGAIN) Virgin Money. They are using the knowledge, systems and experience of a commercial business to manage other people’s money without ever taking on the debt themselves. What a novel – and compelling – idea.

What’s stopping us from thinking about things like this? What’s stopping us from looking at the sweated assets we have created in new ways that limit our risk while helping our customers to be successful?

The only thing that is stopping us is our own bad habits.

5) Build Systems Agility... the Right Way

BPM, SOA and other “process & service” centric technologies need to be deployed, but they must be deployed very carefully. Why do we need to deploy these technologies (or employ their concepts in existing technology)?

We need to take process and service centricity seriously because our businesses will place greater and greater demands on us to support different product offerings and ways of interacting between (and within) those products for our customers.

When we talk about agility and flexibility in IT systems, what we are investing in is the ability to quickly align IT systems to changing business directives – and we don’t know what many of those are yet. With IT investment, realize that much of what we do has no “ROI” until the business defines a change we can support that we couldn’t support before, or that we can support quickly and at a much lower cost than before we made the investment.

That requires a balancing act between how much we invest now against what we “think” might be the return later (and how much later). This is sunk cost so it’s a lot like other business decisions, deciding how much we can invest in an “opportunity” with an unknown return means we have to be able to do so without return at all - otherwise it is too risky. The current weak economy makes this even more important than before.

The one safe place to go is improving the customer experience. Anything - and I mean anything - we can do to make the experience of our customers better than it is today, and ideally better than our competitors offer, will protect our current customer base. Improving the customer experience now is a great way to soften the impact of the slow economy while building the business offerings that will position us for greater success when the economy comes roaring back in a boom.

We must realize that our people are the most important part of this equation. Making the choices of where we will adapt our systems to more agile design and how we choose to draw the lines on services and processes is the difference between real payback and a loss few of us can afford to take.

Going too detailed is one example of service and process oriented error. While having the smallest building blocks possible may lead to the greatest possible set of combinations by which we could reassemble these to support a business imperative it can be the difference between building a city from bricks and mortar to setting pre-assembled buildings in place. Determining the right line to draw in regards to how services and processes are broken out in our IT systems is the biggest factor in determining the success, degree of success, or failure such initiatives produce. If you’re going to be on your game in leading IT to support the creation of business success this is your most important challenge.

There are a number of other critical factors in helping IT systems be a business enabler rather than a boat anchor. More and more IT leaders are being tasked with understanding the business in great detail, as good as or better than their MBA colleagues! Being able to balance the stakeholder perspectives of Shareholders, Executive Management, Functional Management, the Customer and IT as a tightly woven ecosystem is no longer an idealistic want – it is a basic necessity.

Support, improve, elevate, innovate and build. I suppose that’s enough to keep most of us busy for awhile...

Terry Schurter

My Personal Process Insights List Sign-up: http://tschurter.com/lists/?p=subscribe&id=1

IPAPI Moments of Truth Newsletter Sign-up: http://ipapi.org/newsletter.php

Forget stimulus… What we need is courage!

There is talk everywhere recently about “Stimulus.”  The word is so pervasive.  Even the most reclusive people are bound to hear this word at least once in any given day.  Yet what does it mean and can it really help us in these current economic challenges?  Stimulus, in the way I hear it being applied, assumes the economy is some kind of pump; by priming the economic pump, our economy will start working again.  I think not.  Our economy is not a pump and priming isn’t the answer. 

Our economy is by no means simple, but it is based on one very important ingredient: CONFIDENCE.  Show me a strong economy and I’ll show you a high level of confidence by the participants.  Conversely, show me a weak or unstable economy and I’ll show you very low confidence by the participants of that economy.  It doesn’t take a genius to understand what is lacking in our economy right now.

So what happened to our confidence, and more importantly, how do we get it back?  This time it started when poor lending practices of the last ten years caught up to the financial industry and they could no longer hide the problem.  By the way, I heard many a wise voice predict with uncanny accuracy those lending practices would blow up in the faces of everyone involved.  The institutions involved started failing and then our government suddenly realized there was a problem.   As is often true of politicians with an opportunity, they ran around yelling “the sky is falling” if we don’t jump in and save everyone.  Then the media stirred the pot even more and next thing we know, everyone hears and reads we have a full-blown financial crisis.  Within a short period of time, as if on cue, we actually start feeling a true full-blown crisis.  So I have to ask what came first; the actual crisis or the thought of one?  Perception becomes reality.  If you think about it, it doesn’t add up.  Poor lending practices of one industry leads to the collapse of an entire economy?  I don’t think so.  We talked ourselves into this mess.  We gave up our confidence and it won’t be as easy to get it back.

How do we get back our confidence?  Courage!  The Merriam-Webster Online Dictionary defines courage as the “mental or moral strength to resist opposition, danger, or hardship. It implies firmness of mind and will in the face of danger or extreme difficulty to support unpopular causes.”  My own spin on courage is the willingness and ability to do what we know to be the right thing, in spite of what everyone else is saying or doing.  As I talk with people in the business community, I hear a common theme which troubles me deeply and explains why the problem appears to be worsening.  Over and over again I hear the words, “We know we need to… (plug in some business activity here) and we have the budget to do it, but we are waiting to see what happens.”  Or, “we are waiting to see what everyone else does.”  This is the opposite of courage; it is full-on cowardice whether complicit or explicit!  To know what you need to do and not do it is cowardly and a travesty for everyone; the company, the employees, the shareholders, the community and the economy.  Cowardice is really the best word I can use to describe this behavior, but fear is at the root.  Susan B. Anthony said, “Cautious, careful people, always casting about to preserve their reputation and social standing, never can bring about a reform.” Think of it this way; courage builds up while fear tears down.

Courage has built many of the most successful companies past and present.  Courage has shaped many a personal career and fortune.  Thankfully, I am starting to hear wiser voices pointing out that smart businesses and leaders are taking advantage of the situation and not only surviving this economy, but thriving in it.  They will do this with action and not sitting back to see what others are doing.  They will be the ones “doing” while the others watch.  What we need right now is courage!  Be courageous my friends.  Do what you know to be the right thing in spite of those who tell you otherwise.  Robert Frost said, “The best way out is always through.”  Only your courageous acts will bring back the confidence we need for a healthy economy.  

Risky Business: How much are your processes pushing back on the customer?

How many of you have experienced or heard of someone who paid for an airline ticket, and upon check-in discovered it was going to cost extra for any checked luggage?  It’s a common story these days. It is not uncommon for customers everywhere to experience nasty surprises or what I call “nasty’s,” which leave the customer feeling duped, cheated, or at a minimum, wanting.  These surprises happen when the customer realizes they didn’t transfer as much of the risk as they thought.  It’s the Grim Reaper of customer loyalty. 

It is a fundamental principle in business that every transaction is a transfer of risk.  A customer pays for goods or services with the expectation the risk of achieving the desired outcome of their own efforts, or from any other alternative, is lowered.  An example I like to use in my coaching is the choice of dining out. There are two very diverse desired outcomes in dining out I use to illustrate the point.  The first is fast food.  Sometimes we are short of time or the opportunity to prepare nourishment for ourselves or those we need to feed. We are willing to pay the cost of fast food when the risk of taking the time or making the effort to put together a meal in any other way is higher than the cost.  We are transferring the risk of time either in gathering and/or preparing a meal in exchange for the price of the fast food.  

Another example at the other end of the spectrum is when we choose to go to an upscale restaurant. Our motivation for this may be to entertain friends, celebrate a special event, or impress someone.  Our expectation is that a professional chef and wait staff will create a much better experience than we could do ourselves.  We are transferring the risk our homemade meal will be less gratifying than the upscale restaurant will provide.  I hope you can see even the simplest of business transactions are all about the transfer of risk.  Our customers are indeed paying us to take on their risk.

Yet in actuality, many companies push a lot of risk back on their customer in subtle and sometimes, as in the airline case above, not so subtle ways.  There is a way to analyze your customer facing processes to see where you are putting risk back on the customer.  There are two components of a process which carry varying levels of risk for the customer which we can identify and assess that risk.

The first component is any place in the process where the customer touches the process or the process touches the customer.  Richard Normann called these Moments of Truth and the name we have adopted for them as well.  The second component is what Dr. W. Edwards Deming called the “handoff-points,” or what we call Break Points. These are any place in the process where work is handed off or information is transferred.  It is at these places in the process where risk can be pushed back onto the customer. 

So how do we know how significant the risk transfer can be in a given process and then reduce it?  Well, we ask for each and every occurrence of a Moment of Truth or Break Point, “if that particular part of the process were to fail, how much risk does that represent to the customer?”  We simply rate each one high, medium or low.  How do we determine that?  A simple test of how likely the customer will leave us if:

·         it fails many times and the customer is only annoyed = Low

·         it fails once and the customer is annoyed, but after repeated failures the customer leaves = Medium

·         it fails even once = High 

The customer’s willingness to tolerate failure is directly related to how much risk they are willing to sustain in the relationship.  If one or more of these components of your processes are “High” risk, you are very likely putting too much risk back on your customers.  In some cases, an aggregate of “Medium” risk interactions can also be putting too much risk on the customer. 

So how do we reduce the risk in the process?  We simply find actions which will eliminate all the high and some of the medium risk interactions in the process.  Once we have the eyes to see what is really going on in the process, it actually becomes fairly easy to see solutions.  By the way, that is not a misprint.  I specifically meant to use the plural “solutions” because we often can find multiple ways to affect the desired changes once we see the process as it really is.  This is the magic the CEM Method brings to process analysis and improvement. 

In closing, your customers are engaging you because you are the supposed experts at mitigating the risk they seek to reduce.  The natural evolution of processes for all organizations is to push back certain amounts of risk.  We need to see it and reverse it.  It can be fixed and you can do something about it.  Your organization’s success depends on it.