HIGH LEVEL PROCESS MAPPING and KPI’s – Part 3

September 14, 2009

In contemplating the next step in defining our KPI’s and Process Maps it makes sense to determine the various levels of decomposition and their value to your process project.

While there are varying degrees of process descriptions; from Enterprise process frameworks to the finest grained process level map, not all have the same value in relation to the success of your business process automation projects. For instance in our last instalment we offered the notion that for most BPM process automation projects Enterprise mapping initiatives have little value as they are almost impossible to complete effectively and are almost immediately obsolete. That being said Enterprise maps can be assembled but we see such a picture evolving from a more iterative design process and be a natural function of a well executed Center of Excellence.

Process Level Hierarchy

So let us take a look at these varying levels of process decomposition.

The hierarchy is broken down into levels. The top two levels are focused on the entire organization and contain logical processes unconstrained by any organization construct or capability. These usually help define your business category and help develop vision and strategy. While important at some level and help set overall direction, these maps usually are utilized at the highest level of the organization, are prohibitively costly in terms of the actual value they can provide to effective execution of your BPM project. These maps are usually defined and assembled with the help of a strategic consulting partner and can run into the multi-millions of dollars for such an engagement.

The intermediate levels define logical processes focused on what the enterprise does and interactions between customer and organisational entities. It also contains physical models focused on operational activities. These mappings again are usually defined with the help of high level strategic consultants, are part of long engagements and costs

The detailed levels contain physical processes defining the lowest level of operational tasks transforming inputs and outputs. These maps contain a mixture of tasks and sub-processes required to accurately reflect the Activity.

As you can see, with the varying levels of Process Definition there is varying levels of value, to us as BPM implementors.  Some process maps have a high level of value and can help us in terms of speed of project completion and are integral (and maybe expensive) value BPM consultants can play for us, while other maps are prohibitively expensive, provide little value to the granular execution of BPM projects (although maybe NOT to the larger part of the organization) and for us are a waste of resources.

In the next installment let’s define what is a process and the difference between modeling and mapping.

High Level Process Mapping and KPI’s – Part 2

August 23, 2009

This week, we want to continue on the thought of helping you define and discover KPI and high level process mappings to help jump start your BPM project. We will start this series by focusing on planning activities to ensure you have a solid foundation to support process modeling activities and continue into modeling best practices and approaches.   .

Pre Project Activities:

In an effort to include structure and governance as part of your overall BPM program we recommend the adoption of a standardized taxonomy framework. Frameworks are used to assist organizations with describing, scoping and classifying their business processes.

  • Taxonomy – provides a detailed framework for scoping boundaries of processes

However initially this provides little value but do aid in the long term success of BPM. So an informal approach is typically your best bet for early projects.  

Process Decomposition:

It is important however to understand process decomposition as you under take your first attempts at process modeling. One process may be made up of several other lower-level processes. The breakdown of a group of processes, into its lower-level processes and eventually to a series of tasks, is known as process decomposition. Decomposition provides several initial benefits such as:

  • Shows linkages between different process levels.
  • It is used to define and communicate project scope.
  • It is used as the foundation for more detailed process documentation like mapping..

The importance of individual process maps is of course that they illustrate the flow of work of a process at a single process decomposition level.  A series of process levels enables a business process to be depicted from a high-level view, or a more granular view depending on the project need or team need. It enables a process to depict an entire value chain of a business with high level components without too much detail, or a subsection of the value chain at a lower level, with more detailed views.  The goal of any process mapping exercise or the goal of any team involved in process mapping exercises should be to start and capture process information at one of these levels, then endeavor over time to branch out both to more detailed or finer grained levels of process mapping and to higher level enterprise mapping exercises.  In our experience capturing  a generic process level detail with KPI’s and high level process maps is a great place to begin, followed by decomposition to finer and finer levels of process description.  After value and understanding has been shown at these levels (a.k.a. you’ve got some process project wins that have shown value to the greater organization) and the business has the stated direction of process improvement through automation of business process, then the higher level enterprise mapping exercise makes sense.  Very rarely have we ever encountered high level enterprise level process mapping exercises which returned value over the short term or retained value to the organization over the long term…therefore were of little value at all in and of themselves to any organization.

Next installment:  Defining process levels, their scope and definition and value and the difference between business process mapping and business process modeling.

Starting a BPM project – High Level Process Maps & KPI’s – Part 1

August 21, 2009

Today we start a series of blogs that will help you actually begin to implement BPM projects in a smart and consistent manner.  We feel it is logical to begin to review the art of gathering high level process maps and key performance indicators (KPI’s).  Enjoy!

As discussed in prior blogs selecting a implementation methodology, identifying projects with the best ROI, selecting a software platform and making organizations changes to embrace BPM are just a few of the initial hurdles faced as you start down the BPM path.

However from real world experience I have found these are just bumps in the road compared to the issues that arise with execution of your first BPM real projects.

I am the lead architect for a mid sized company that realized a couple of years back that BPM was the key to our success. Our adoption was supported and embraced by both IT and business executives. Prior to under taking out first project we spend many months defining methodologies, selecting software vendors, creating organizations to lead and support the BPM effort. Finally we were ready to under take our first project….

Even with all the preparation, planning, software tools and education our first process definition session came to dead stop after about ten minutes when it became obvious that we could not get pass the current state process. Not sure if this is something unique to our company or not but our process owners just could not think outside the box. After many starts and stops we found that the best way to stimulate out of the box thinking was to start our discussions with industry best practice models.

Currently we have been defining our own by pulling bits from various sources to create a what if type model. To date this seems to work well but it takes a lot of upfront effort from knowable resources. If we had access to industry specific models our analysis time could be greatly reduced and our cost and time to market savings increased.  Double that figure if you are using consultants.  Vendor supplied models were either too large, too expensive or incomplete relative to cost. 

In the next few blog I will sort through our methodology and best
practices to help you understand how we define high level processes, the KPI’s around these processes and then use these high level models to generate successively finer grained business process models to then run on our BPM platform.

Ichiro Ishikawa’s Seven Tools of Quality

August 10, 2009

So we have had great response post on “A Comprehensive Approach to BPM.”  The whitepaper from that blog post can in the whitepaper section of www.processgenie.com   In the previous post, to Mitch Gooze of the Customer Manufacturing Group ( http://www.customermfg.com/  and  http://valueaccelerationblog.com/ ) touched upon Ichiro Ishikawa’s “Seven Tools of Quality.”  Some of you asked if he could briefly review them.  At ProcessGenie…your wish is our command…Enjoy!

We all talk about the Seven Tools of Quality.  We all know they are comprised of:   

Cause and Effect Diagram

Histogram

Check Sheet

Pareto Chart 

Control Chart

Flowchart

Scatter Diagram

Althought all are fundamental tools of process. Let’s walk through each briefly.

Histogram.  A histogram is a bar chart used to present visual data from a process over a period of time. Using a visualization of the data a person is more likely to see and understand issues relating to the process which are not as obvious from a bunch of data elements.

For the purposes of business process management a histogram is a useful tool to help make better decisions. As with all visualizations of data you must be careful to create a visualization that helps make better decisions as opposed to supporting the decision you want to have made. (We have all seen graphs that have been scaled to make it look like either huge changes or no changes have occurred based on how the graph is scaled. Histograms are no exception.)

How many bars in your bar chart?

To create a useful histogram you need at least 50 data elements and 100+ is better to make useful decisions. The number of “groups/bars” that you review is based on the number of data elements. The rule of thumb to determine how many columns or bars to have is to take the square root of the total number of data elements and round to the nearest whole number. For example if you have 150 data elements, the square root of 150 is 12.25, so we round to 12 columns or bars.

If you wanted to create a histogram of website hits over time, then the time interval of interest would be based on the number of web site hits you get. If you are low volume website you may get 100 hits/day, so you may want to view a histogram by hour, or maybe even by day of the week. If you are a high volume website that gets thousands of hits per hour, you may want to view a histogram by 5 minute intervals.

You look at the shape of your histogram to determine where is it is centered and what is its shape (though some processes are naturally skewed). How variable is it. If you are running a call center and your midpoint is 100 calls per period and it ranges from 2 to 200 that is obviously much more variable than if it varies from 180 to 220. Is variability a problem and if so, how can you correct it? For example, in call centers they will often monitor “hold time.” However, the acceptable hold time from the company’s perspective for a customer wanting to place an order may be much different than the hold time they find acceptable for a customer wanting to complain. Either way, is the process meeting the stated requirements.

Like most good process monitors, you would expect your histogram to follow a 6-Sigma distribution such that virtually nothing fell outside +/- 3 sigma from the mean.

Cause and Effect Diagrams (also know as Fishbone Charts because of what they look like) are a graphic representation of the possible causes of a particular problem or condition in a process. The purpose of the Diagram is to help find the root cause problem. Using the fishbone approach the team
looks at possible causes in increasing levels of detail. The tool is effective for a team to use to brainstorm possible causes of non-performance or under-performance of a process or of particular failures within a
process. For example, if leads (prospects) are periodically entered incorrectly into the system, what might be causing that to happen? The Cause and Effect Diagram focuses the team on causes not symptoms and keeps the conversation focused on the problem and not personal agendas.

Alternatively to brainstorming, which is a very common approach to creating these diagrams, data from Check Sheets can be used to provide useful insights into the actual causes.

Check Sheets. A Check Sheet is a simple and easy method to collect, accumulate or count data from a process of interest. While it does not seem sophisticated (which it isn’t) and it is easy to master, with one critical issue, these do not mitigate the effectiveness of Check Sheets. Check Sheets are easy to use and
understand, the key is to agree in advance on what you are observing and counting. All you are doing with a Check Sheet is collecting, accumulating or counting data from a process over time to observe or learn what the data tells you.

For that reason, while the task (counting) is easy, it is useless if you do not agree on the definition of what is being counted. If you are counting website hits per hour, define what you mean by a hit. For example is that unique hits or all hits? If you are counting trade show visitors, how long do they have to be in the booth to be considered a “visitor?” If they just drop their business card in the bowl for a chance to “win” does that constitute a visitor or do they have to talk with someone. While it is useful if the definition passes a reasonableness test, it is understanding, acceptance and agreement on the definition that is critical. Once you agree on what to count, then you just count it and tabulate it on the Check Sheet. Check Sheet forms should be simple, clear and easy to use.

You can use the data collected from the Check Sheet directly by observation. For example, collecting errors on order entry forms can show that a particular portion of the form generates most of the errors. Alternatively, you may use the data collected to create a Pareto Chart or Histogram for more complete or complex analysis.

Pareto Chart.   A Pareto Chart is a bar chart in which the measured values are arranged in descending order, and it is usually accompanied by a line graph over-laid on the bar chart showing the cumulative category percentages from right to left. Like other of Ishikawa’s tools, the Pareto Chart provides a visual interpretation of data.

The Pareto Chart takes advantage of what has become known as Pareto’s Law, also commonly referred to as the 80/20 rule. In many cases when you graph the causes of “problems” with a process using a Pareto Chart you will find that the 80/20 law is alive and well and you can quickly see where to focus your efforts in process improvement to gain the greatest impact.

A simple use of a Pareto Chart could be to graph causes of customer defection or lost opportunities. When we have done that for our customers, the 80/20 rule has proven to hold true.

Control Charts.  Control Charts are used to provide a visual indication of variance in a process. All processes have variances. The question is how much variance is acceptable. The 6-sigma folks use that metric as their guideline, but many processes need a much lower variation (if airplanes landed safely only at a 6-sigma rate, nobody would fly), and some can allow more variation. Though sometimes we accept too much variation based on an assumption that better control is either not possible or too expensive. Japanese car manufacturers created cars with much tighter tolerances than their U.S. counterparts and actually saved money in the process. To use Control Charts effectively, you must decide how much variation is acceptable in the process of interest. That sets your upper and lower control limits. By charting variations in the process over time you can determine if your process is in control or not. If not, then the key is are the variations due to common causes which are inherent in the process and if they produce unacceptable performance require a process redesign; or special causes which must be eliminated to keep the process under control.
Scatter Diagrams. Scatter Diagrams are a visual tool used to determine if two variables are related. While it is a visual tool, done correctly it is also a valid statistical tool to determine the strength of correlation (if any) between two variables. Scatter Diagrams are created using a simple two dimensional graph, with one variable on the x-axis and one on the y-axis. They are often used as a follow-up to a Cause and Effect Diagram to determine if there is actually a valid relationship between two variables as postulated during the Cause and Effect brainstorming session. For example, you could test whether errors in order entry were correlated to the training given to the order entry person. Scatter Diagrams do not predict cause and effect; they only show the strength of any possible correlation between two events. It is also possible that a Scatter Diagram will show a negative correlation between two variables. For example, there have been studies done in the past that showed that some ads actually reduced business for a company.

Flow Charts.  Flow Charts are also called Process Maps. They are the most commonly used tool in business process improvement. Simply put they are a graphic representation of the process of interest. The key to Flow Charts or Process Maps is to create them at a level of detail necessary and sufficient to allow improvement to the process. No more and no less. The first step in Flow Charting is to create a picture of the “as is” process. It is very tempting to try to change the process when charting it because too many processes, once visualized, are quite silly in some of the steps they include. Resist the temptation and map the “as is” process before attempting to improve it and creating a “should be” or “to be” process. There are many graphic representations of Flow Charts or Process Maps that are useful, so pick the one that is appropriate for your needs.

But don’t just use Flow Charts.  Using all Ishikawa tools is a great way to begin working to improve your existing processes.

 PS Download the  Pareto Charts whitepaper at www.processgenie.com

How does “BPM Process Scenario” affect approach and tool choice?

August 10, 2009

Today our guest blogger is Garth Knudson from Handysoft (www.handysoft.com).  Garth is going to speak today about how the process project you are tackling should dictate the tool you use to automate them.  Interesting and comprehensive.  Also please feel free to download the latest whitepaper from Volkmar Volzke and New Pace Consulting on “People, Process & Execution”  at http://www.processgenie.com.  Enjoy  

BPM software has progressed from a niche solution-enabler for automating administrative processes to a strategic business platform for standardizing and optimizing mission-critical operations.

As a result, organizations around the world view BPM as a way to create visibility into and control over many types of business processes. But as they begin applying the principles of BPM, they discover that “designing” or “modeling” some processes is difficult or next to impossible because of their dynamic nature

Our experience suggests that 20-30% of business processes adhere to formal or structured workflows. The other 70-80% are semi-structured or completely dynamic.

If your experience mirrors ours, then business processes fall into 3 major buckets:

  • Structured – You know all the rules, policies, procedures, roles and responsibilities of every process participant. Rules are locked and loaded. Process scenarios may include procurement, T&E, and accounts payables.
  • Structured + Ad-Hoc - Particular work items require outside opinion. You punch-out of the structured workflow into an ad-hoc sub-process, then jump back-in once obtaining the right information and/or approval. Process scenarios may include case management and policy development.
  • Dynamic – You know where the process starts and ends, but the steps in the middle depend largely on the requested task. Scenarios include action tracking, correspondence management, and project management.

Unlocking the value of BPM for structured processes – visibility, control and productivity – to the other 80% of work that is ad-hoc or completely dynamic requires that organizations determine the right approach to process automation as well as the right BPM platform to support the methodology selected.

Approach

Since processes are innately different, organizations should consider adjusting their approach to business process automation based on the above business process scenarios.

Approaches may include:

  • Formal Approach: Discover (Requirements)à Define (Model, Rules) à Execute (Deploy) à Optimize (Analyze, Improve)
  • Dynamic Approach: Execute (Deploy Dynamically) à Optimize (Analyze, Improve) à Add Structure (Model) à Execute (Deploy in Structured/Dynamic Process Definition)

Notice that the formal approach requires modeling prior to execution. Modeling is one of the most expensive steps to business process automation. If the dynamic nature of your business process undermines quick/efficient modeling, then the ROI of BPM becomes distant or untenable.

The dynamic approach is more like email – there exists no structure more than knowing the people involved in their essential roles. But with email, you quickly lose visibility and accountability, the two real benefits of BPM.

BPM Tools

If the above premise – processes are not all alike but all should be open for automation and tracking – is true, then the BPM platform you select should enable process execution despite process type.

  • Structured BPM – These tools give you a modeling environment where you can design the workflow, add business rules, develop and tie-in forms, which together ultimately create process-driven applications. This is the norm. Most if not all BPM Suites offer such functionality.
  • Ad-Hoc BPM – Semi-structured BPM tools extend process design and execution flexibility to support ad-hoc jump-outs from process activities. They may also offer discussion groups, wikis and other features for human-to-human collaboration. Keep in mind that an ad-hoc workflow is normally serial: only one participant can act at a time. While retaining process-related forms and data within the process instance, it cannot create parallel tracks like email. Ad-hoc process management increases the overall flexibility of process execution, but sometimes does not go far enough to keep process participants completely inside the process instance in order to retain overall visibility across structured and dynamic work.
  • Dynamic BPM – Dynamic process management lets you execute a business process without prior design or modeling. You initiate a process just like you would in a formal BPM setting. However, you let the users, those you select to participate, determine how they reply and whether they include others to help completed their respective tasks. As a result, the business process definition may determine process initiator, but business process instances vary based on process source, category, deadlines, and user participation. Dynamic BPM is really a paradigm shift.

Ultimately, you want your approach to ensure success in the most cost-effective way. Most BPM tools can help you with the structured workflows, but very few can help you support and capture dynamic workflow execution.

Processes and People: A contradiction? or Prozesse und Personen: Ein Widerspruch?

August 10, 2009

Welcome, today our guest blogger is Volkmar Völzke, President and Business Process Principle at NewPace Consulting (http://www.newpaceconsulting.com/) and we are going to try something a bit different. Because of our large following in countries that also understand German, we are going to supply the blog today in both English and German.  The German version follows the English version.  It’s something new we hope you will like…let us know!  

One of the common denominators of business managers and experts in discussions on an organization’s performance is:  It’s all about our people!”  Or, if you come from the IT-perspective: “It is all about Information Technology,” but that is another story for which I ran a discussion on LinkedIn some weeks ago, see here.

Another common statement heard with companies contemplating BPM projects is: “People are restricted and discouraged by too much business process management!”  Wow! Nothing can be farther from the truth!

I would agree there is one specific example where too much process work can be frustrating and this can happen to any company where people are restricted and discouraged by business processes, if these processes are managed in a wrong way, ignoring people or acting even against them.  A great example of a disastrous practice impacting BPM is “management by policy.”  

So if this is the case with your company, where bad or short sighted management has brought about a lack of enthusiasm for BPM, the question becomes “Who will win if people and processes don’t fit?”   I believe the answer is in almost all the cases:  People over process.  People will always find ways to work around messy processes regardless of its impact on company performance or they decide to leave the company Both outcomes do not improve the organizations’ performance sustainably.

Here is my first rule of Process and People: People can and will collaborate effectively, efficiently and sustainably for the sake of an organization’s performance only if their tasks are based on effective, efficient and sustainable business processes.

This statement sounds simple, and yet, many organizations often ignore it.

Keep in mind these two supporting points:

  • Business processes are created and run by people anyway, no matter if explicitly defined or documented.

If the “officially” defined processes are too complex, not working or not understood, people will create their own ones, which better serve their needs – but not necessarily the company’s objectives. So the question for an organization is not: “Should we run business process management?” Instead, the right question is: “Should we manage the business processes in order to ensure the achievement of organization’s objectives through real process execution?”

  • Business process management creates a framework for employees’ creativity to achieve better business results.
    In most organizations people are continuously distracted by weird or non-coordinated processes. Those distractions have an enormous effect on productivity: not only working hours will be wasted. More importantly, this burns energy and motivation. A good example is seen in the simple disruption taking place when a laptop fails and the IT process takes too long to solve the problem, users lose access to important data and applications, the work stagnates, productivity declines, output suffers, customers find other more responsive organizations, etc.

Similar problems which effect corporation’s  output occur when processes are not focused on effectively supporting the most effective way to do business AND support the employee to do his/her job most efficiently. Processes should not be designed just to keep an employee utilized or busy. Streamlining and cleaning up these supporting processes brings an immediate positive effect on the organization’s performance and on the motivation and energy of people. They can focus on the tasks for which they are employed.  As Michael Hammer has said: “Process is not the opposite of creativity, it is the opposite of chaos.”

Now then, the question becomes how does one achieve the implementation of business process management to effectively maximize employee output, energy and time? There are many parameters and prerequisites.  The two I feel are most important and would like here are:

  • Business process management is not a technical but a human topic.
    In almost all organizations – even in highly automated ones – the majority of process steps run still manually or with important manual support. As a result, business processes need to be designed right from the beginning in a way that people can handle them – and not as a vehicle to ensure the implementation of IT systems. Unfortunately, the latter seems to be promoted by a wrongly understood SOA and is common practice in most IT implementation projects.
  • Business processes improve the organization’s performance only if they are really executed by the people.
    Sounds simple but it is not. Real process execution (or fidelity) is not the design of some presentation slides or process flows in BPM software. It is the day-to-day execution of each process step by the people “in the trenches”. Of course, these people will only execute processes that match their needs or get at least their understanding.

That’s the way I see the link between people, processes and Business Process Management.  Of course (and maybe no surprise to this audience) it is not what I see in the reality in 80% of the cases I encounter. So let’s change this current status and improve the performance of organizations. Business Process Management – if practiced in the right way – is the best means of improving business performance and unlocking people’s creativity and energy at the same time.

 

Prozesse und Personen: Ein Widerspruch?

 

Manager und Experten sind sich meist in einem Punkt einig, wenn es um die Leistungsfähigkeit ihrer Organisation geht: „Es hängt alles von den Mitarbeitern ab!” Oder, aus der Perspektive von IT-Vertretern: „Alles hängt von der

 

Informationstechnologie ab”, allerdings ist das ein anderes Thema, zu dem ich kürzlich eine Diskussion auf LinkedIn geführt hatte, siehe hier.

Eine andere Aussage zu Geschäftsprozessmanagement ist häufig: „Mitarbeiter werden eingeengt und demotiviert durch zu viele Prozesse!” Erstaunlich! Kaum eine Aussage kann irreführender sein!

OK, es gibt natürlich schon den Fall, dass Geschäftsprozesse zu Frustration und Demotivation führen. Das passiert immer dann, wenn Prozessmanagement falsch angewendet wird, also die Prozesse so angelegt sind, dass die Mitarbeiter ignoriert oder gar in ihrer Arbeit behindert werden. Ein einfaches Beispiel ist leider oft „Management durch Arbeitsanweisungen”, das eben nichts mit wirklichem Prozessmanagement zu tun hat.

Ein interessanter Punkt, der häufig ignoriert wird, ist, dass Mitarbeiter fast immer clever genug sind, Prozessvorschriften und Arbeitsanweisungen zu umgehen, wenn sie nicht zu den Arbeitsabläufen passen. Sie schaffen dann eine eigene Prozesswirklichkeit, die zwar für den Einzelnen funktioniert, aber nicht unbedingt viel mit den Unternehmenszielen zu tun hat (und schon gar nichts mit dem, was die Vorschriften bezwecken). Eine andere Konsequenz für intelligente Mitarbeiter ist die (innere oder offene) Kündigung. Auch das trägt nicht zu den Unternehmenszielen bei.

Als Konsequenz hier meine erste These über „Prozesse und Personen”: Mitarbeiter können und werden genau dann effektiv, effizient und nachhaltig die Leistungsfähigkeit der Organisation steigern, wenn ihre Arbeit auf effektiven, effizienten und nachhaltigen Geschäftsprozessen basiert.

Diese Aussage klingt einfach und wird doch in vielen Fällen ignoriert.

Zwei Punkte illustrieren meine These:

  • Geschäftsprozesse werden sowieso von Mitarbeitern durchgeführt, unabhängig davon, ob sie explizit definiert oder dokumentiert sind.

Wenn die „offiziellen” Prozesse zu kompliziert sind, nicht funktionieren oder nicht verstanden werden, entwickeln die Mitarbeiter selbst welche, die zu ihren Aufgaben passen – aber nicht immer mit den Unternehmenszielen übereinstimmen. Die Frage für ein Unternehmen ist also nicht: „Sollen wir Geschäftsprozessmanagement einführen?” Die richtige und sinnvolle Frage lautet vielmehr: „Sollten wir die Geschäftsprozesse so steuern, dass das Erreichen der Unternehmensziele durch tatsächliche Ausführung der definierten Prozessschritte unterstützt wird?”

  • Geschäftsprozessmanagement bietet den Rahmen für die Kreativität von Mitarbeitern, damit sie die Erreichung der Geschäftsziele maximal unterstützen.

In den meisten Organisationen werden die Mitarbeiter immer wieder von unverständlichen oder unkoordinierten Prozessen in ihrer eigentlichen Arbeit gestört. Der Effekt auf Produktivität ist enorm: Es werden nicht nur Arbeitsstunden verschwendet, sondern – und das ist viel wichtiger – Energie und Motivation wird zerstört. Ein bekanntes Beispiel sind Computerprobleme, deren Lösung zu lange dauert wegen unklarer IT-Prozesse: Anwender kommen nicht mehr an wichtige Daten und Programme, können ihre Arbeit nicht zu Ende bringen, Produktivität nimmt ab, eventuell springen sogar Kunden ab wegen längerer Bearbeitungszeiten von Anfragen etc.

Ähnliche Probleme treten auf, wenn Prozesse nicht so gestaltet sind, dass sie gleichzeitig die zu den Unternehmenszielen beitragen UND Mitarbeiter in ihrer Arbeit unterstützen. Manchmal hat man den Eindruck, Prozesse sind dazu da, Mitarbeiter beschäftigt zu halten. Vereinfachung und Vereinheitlichung von Prozessen hat meist einen unmittelbaren positiven Effekt auf Motivation und Energie der Mitarbeiter: Sie können sich voll auf ihre eigentlichen Aufgabe konzentrieren.

In den Worten von Michael Hammer: „Prozess ist nicht das Gegenteil von Kreativität, es ist das Gegenteil von Chaos.”

Wie implementiert man also Geschäftsprozessmanagement so, dass die Arbeitsergebnisse, Energie und produktive Zeit von Mitarbeitern optimiert werden? Hierfür gibt es viele Parameter und Voraussetzungen. Ich sehe die beiden folgenden als essentiell:

  • Geschäftsprozessmanagement ist kein technisches, sondern ein menschliches Thema.

In fast allen Organisationen – auch in hochautomatisierten – wird die Mehrheit der wichtigen Prozessschritte nach wie vor manuell ausgeführt oder zumindest manuell unterstützt. Folglich sollten Geschäftsprozesse von Beginn an so gestaltet sein, dass Personen sie optimal bedienen können – und nicht als Hilfsmittel für die Implementierung von IT-Systemen. Letzteres scheint leider durch eine falsch verstandene SOA unterstützt zu werden und ist die Regel bei den meisten IT-Implementierungsprojekten.

  • Geschäftsprozesse verbessern nur dann die Produktivität von Organisationen, wenn sie tatsächlich von den Mitarbeitern ausgeführt werden.

Das hört sich banal an, ist es aber nicht. Tatsächliche Ausführung der einzelnen Prozessschritte hat nichts mit hübschen Prozessdarstellungen auf PowerPoint-Folien oder anderer Software zu tun. Es ist vielmehr die tägliche Ausführung jedes einzelnen vorgesehenen Prozessschrittes durch die Mitarbeiter „an der Front”. Und natürlich werden diese Mitarbeiter die Prozessschritte nur dann ausführen, wenn sie ihren Anforderungen entsprechen und verstanden werden.

Das ist meine Sichtweise auf den Zusammenhang zwischen Mitarbeitern, Prozessen und Geschäftsprozessmanagement. Natürlich (und das ist sicher keine Überraschung für die Leser hier) ist die Realität in mindestens 80% der Fälle leider noch eine andere. Also gibt es genügend Potential, die Realität zu ändern und die Produktivität von Organisationen zu verbessern. Geschäftsprozessmanagement – richtig angewendet – ist das beste Mittel, um gleichzeitig dauerhaft Produktivität zu steigern und die volle Kreativität und Energie der Mitarbeiter zu nutzen.

IT is from VENUS/LOB is from MARS – Aligning IT and Business

August 10, 2009

Let’s face it.  The ultimate criteria of project success should be business value AND the relevance of each project to the stated future vision.  Most organizations The Genie deals with, function along the lines of IT is from Venus and Business is from Mars.  They have no common language for communicating or understanding each others needs, goals, reasons for timelines and success factors. Often times too, there are real personality difference that hamper communication (extrovert vs. analytical). That leads to frustration and ultimately a breakdown in effective communication to keep projects on scope and providing maximum return.

A not so radical idea for most organizations is to cross pollinate.  Put together a 2 person team of business analysts. One with a business background and one from IT together as your IT/Business liaison for projects.   Make sure these teams have a mix of experience and a deep curiosity on how the “other half” lives and don’t leave them their forever.  Rotate these teams and their members to help keep the BPM/SOA vision proliferation throughout your organization AND keeping input fresh.

BPM or ERP or BOTH?

August 10, 2009

BPM or ERP or BOTH?

Today at www.processgenie.com we have a guest blog from Garth Knudson Managing Director at Handysoft, with a common question we all get from our business side executives.  Enjoy!

I just got back from travels in the Middle East. What I discovered is that the MEA Region (Middle East & Africa) is about 3 years and 7 years respectively behind the market in its access to and evaluation of BPM and ERP solutions.

MEA not withstanding, many people have asked me about the differences between ERP and BPM.

Questions include:

  • How does BPM compare with ERP?
  • Does BPM compete with ERP, does it replace ERP, or can it co-exist with ERP?
  • What is the value of BPM to me?
  • Which should I do first?

I would like input on this matter.  But I submit the following:

ERP:  In simplified terms, I see ERP as a way to integrate the data layer of different processes (e.g. AP/AR, Payroll, Order Entry) within larger processes (e.g., Financials, HR, SCM). Although workflow is an embedded part of any ERP system, it is not intended to support enterprise processes. The workflow itself is functionally-driven (e.g., materials management) vs process-driven, where the process can potentially span many different functions (e.g., requisitioning, recruiting). The value ERP provides is an integrated system and single view into customer data. The data is updated on demand. Customers expect ERP to support their processes, but often they have to change their process to match ERP best practices. As a result, ERP software and implementation costs are significant. In 2007, the Aberdeen Group found that the average costs (software + services + maintenance) per user ranged from $2K/user (a company with on average 3365 users, 14 modules) and $18K/user (a company with on average 195 users, 11 modules).

BPM : In contrast, BPM enables users to create business applications incorporating different people, data and documents, which in turn span multiple divisions, systems and/or data sources. Process function is almost irrelevant. In a structured BPM scenario, workflow activities derive from specific rules (i.e., roles, responsibilities, policies, procedures, deadlines, escalations). In a dynamic BPM scenario, users completely control routing in run-time. The value BPM provides is a platform to create multiple applications that improve productivity (effectiveness, efficiency), greater business agility (traceability, innovation, optimization), and ensured compliance (auditability). Furthermore, process definition components are reusable and changeable.

Many BPM vendors provide templates that do not mandate workflow but act as accelerators to process execution. I could find no study like the one above, so I will base costs on experience. Say user-based pricing ranges from $500/user to $1500/user. A simple workflow is likely to cost $10K-$25K in professional services to execute, a mid-sized $40-$75K, and a sophisticated workflow $100K-$500K. Because the BPM platform is reusable, the customer only requires an investment in services to create new applications. If the average customer has 200 users with 5 mid-tier live applications, then the cost per user is $1K/user to $3K/user.

BPM might compete with and/or replace ERP on smaller scale projects. BPM absolutely compliments ERP by creating a “single view” into processes spanning multiple groups/systems (e.g., customer on-boarding, purchase requests). BPM also covers processes that fall completely outside of ERP systems such as Correspondence Management, Project Management, and Action Tracking.

Examples: BPM & ERP Working Together

  • PT Medco Indonesia - MedcoEnergi (MEDC) is the first Indonesian company operating in the oil and gas exploration and production business. Subsidiary PT Medco E&P Indonesia heads up exploration, production and support services for oil, natural gas, and onshore and offshore drilling. Often the company would need to change orders based on project changes or delays. While PT Medco uses ERP, project managers could not make changes to requisitioning and procurement processes based on new expectations. These processes spanned multiple ERP modules. PT Medco decided to use BPM to manage project life-cycles. Now project managers can initiate and track work items that span contract negotiations, procurement of new equipment, and changes to project deadlines. ERP manages the data. Together management has a single view into data and process.
  • Glaxo Smith Kline Latin America – GSK Latin America distributes healthcare products throughout Central America, South America and the Caribbean. They use ERP as an “Address Book” to manage customer, supplier and employee accounts. However, there was no standardized process for creating and/or modifying these accounts. Imagine different departments (e.g., HR, IT, Procurement) in all the different countries (e.g., Guatemala, Dominican Republic, Venezuela) approaching Address Book changes in a different way. Having little control over the process, they had little visibility into workflow status and thus often lost items, missed deadlines and compromised customer service. The IT team, supported by the Controller’s office, initiated a project to standardize Address Book changes across all regions. Following a Six Sigma methodology, they used BPM to create a new model and set of business rules to improve overall effectiveness and efficiencies. The result is a BPM application that streamlines the add/change/delete process in ERP. Once logged-in, users initiate a work item. Initiators can represent virtually any department such as HR, sales, IT or Purchasing. The initiator fills and submits the form, which is sent to the appropriate approving authority within the Accounts Payables Department. The work item then moves through Finance and Pay Control for additional reviews and approvals. From Pay Control, the work item is passed via XML to the ERP system where the actual record is created or modified. Upon completion, ERP replies via XML, which is picked up by BPM, which in turn triggers an email notification to all workflow participants that the process has been completed. When modifying a record, the process starts by allowing the initiator to search for a name within ERP. Matches are returned to the initiator who then selects one, which populates the corresponding BPM form. Subsequent steps are the same.

In summary:

  • ERP provides very good embedded workflow, but poor enterprise workflow. BPM supports both functional and enterprise workflow scenarios.
  • BPM is far more agile than ERP systems, where BPM requires on average 3 months to implement versus 20 months for ERP. Change management is also faster with BPM.
  • ERP often needs BPM to help realize its full value.
  • If BPM isn’t for use with ERP, why do so many vendors provide adapters?

So again I ask, BPM or ERP or both?

IS SOA DEAD? And 5 Ways to Revive It!

August 4, 2009

Is SOA dead?   Could be!  The Genie is referring to the most recent blog by Andrea Thomas Manes of the Burton Group  http://apsblog.burtongroup.com/2009/01/soa-is-dead-long-live-services.html and her assertion that SOA has been killed by the economy and lack of success. Please if you have not read this very interesting blog installment…go out and read it now.  Andrea is on The Genie’s “must read” BPM blog list.

But The Genie would not call the florist and get the casket out yet.  In fact SOA has proved to be an effective and highly leveraged methodology.  Remember SOA is just an architectural pattern to accomplish goals.  Many people are effectively leveraging SOA as an architectural pattern to some success.  Unfortunately, most companies The Genie interacts with have done little more than leveraged SOA as a standardized way to implement large application development and integration projects.

Most companies have gotten too caught up in the component debate of which ESB, repository or governance methodology to use and have not focused on the ultimate goal which was flexibility and decoupling of components for faster/better response to BUSINESS NEED.   So SOA has been little more than a science project in some organizations and provided little value outside a science project in most.  So, we ask again…is SOA dead? 

Well if so, The Genie thinks one way to resurrect SOA is to apply it to BPM.  By implementing BPM using the architectural pattern of SOA, companies may actually attain the very real current and future benefits of reusable process components that can be assembled and reassembled in a fast, flexible manner to meet business needs and make a more responsive organization.  Implementing BPM via SOA also means you can incorporate the newest IT ideas like cloud computing while leveraging the work you have already done.

But applying SOA to BPM is not in itself a recipe for success.  For any SOA/BPM project to succeed “The ProcessGenie 5 Key SOA/BPM Success Factors”TM need to exist in and around your project and company (or you need to be actively getting them in place) in order to succeed.

PG Success Factor 1 – For enterprise success you need enterprise vision and control.

PG Success Factor 2 – Don’t start from a software vendor perspective. 

PG Success Factor 3 – Start small

PG Success Factor 4 – Think BIG

PG Success Factor 5 – Make sure you are providing business value

We’ll elaborate on each of these points in upcoming blogs.  In the meantime, The Genie has always felt that none of us is as smart as all of us…so chip in your thoughts, feelings and experience.  If you feel strongly about it and have more to say than the comment field allows, reach out to us and we can have YOU share your feelings via this blog either under your name or through The Genie alias!

Hope to hear from you and good luck in your projects!!!


Follow

Get every new post delivered to your Inbox.