The Difference Between Workflow and BPM…

It’s been awhile since I have written to my blog.  ICCM had an excellent show in Dallas, Texas at the ITSMf USA Fusion09 conference.  There was a lot of interest and buzz about our solution.  It also highlighted for us the need to increase awareness and education in areas that on the surface, appear equivalent, but in reality are very, very different.  During the many demonstrations, several Fusion09 attendees asked us; “What exactly is the difference between BPM and Workflow?”.  The obvious observation was that they were one in the same.  This is simply not the case as you will see below. 

Every BPMS and BPM solution set on the market have in common key differentiators from the “embedded workflow” often found within applications.  Some of these differences include;

• Embedded, application based workflow is usually application-specific sequencing of pre-defined activities (ie. in an ITSM context, Change Management workflow is just Change Management)
• Embedded, application based workflow rarely interacts with external processes, systems or data sources
• Embedded, application based workflow often leverages proprietary graphics, execution language, etc
• Embedded, application based workflow effectively provides the ability to choose  the specific order of execution of pre-built activity steps

The purpose of this article isn’t to contrast application specific workflow to BPM in a negative context.  Application based workflow can and is often implemented as a subset of BPM.  The original premise of BPM was to manage and coordinate processes executed in other technologies and on different systems as well as within itself.  The initiatiation, monitoring and termination can be integrated at any point in the process to any application.  BPM allows us to design and execute business process systems without being subject to the constraints of a single application or single location.

One of the value propositions of BPM is how it is often leveraged at an enterprise level to deliver processes and services beyond the company firewall.  Quite often this ability is a driver for BPM within an organization.  This enables processes to extend to and include remote company locations, supply chain and business partners, and agents of your organization.  In this context, there are some other less obvious, but important distinctions of BPM over embedded workflow;

• BPM inherently provides diverse integration and technology support as business and supply chain partners always have different technologies.
• BPM provides the ability to vary process descriptions locally while keeping common touch points for systems to enable collaboration.
• Most BPM Suites typically can leverage industry standards such as BPEL, XPDL, and BPMN

As stated in my previous post; “Optimizing IT with BPM”.  The basic value proposition of BPM is the ability to enable business (or IT) processes with less effort and cost, with higher quality than traditional means. In fact, BPM is intended to respond to the following set of business values;  Agility – The ability to bring new products and services to market more quickly and adapt processes more effectively to changing market demands; Efficiencies – Most processes are inefficient due to manual effort, poor hand-offs between departments and a general inability to monitor overall progress. The deployment of BPM solutions helps to eliminate these problems. The efficiency benefits are typically expressed in the reduced number of Full Time Employee’s (FTE’s) required to perform particular tasks; and Visibility – Providing management insight into process-based performance indicators. This enables an organization to make better business decisions and handle exceptions better.

Gartner research indicates that even without process redesign, a basic investment in a BPM suite yields significant returns. By simply “making the current-state handoffs, timing and responsibilities explicit, productivity improvements of more than 12 percent are normally realized[2]”. In another report, Gartner indicates that 78% of projects see an internal rate of return (IRR) of greater than 15%.  The same report indicates that these projects were deployed in very quick order (67% in less than six months, 50% in less than four months).   Some of these results in more detail;

• Organizations had more than 90% success rates on BPM projects.
• Successful projects had no less than 10% internal rate of return.
• 78% had more than 15%; wild numbers included 100% and 360%
• 67% of the projects were completed in less than six months.
• 50% of the projects were completed in less than four months.
• 77% of the projects had returns greater than $100,000 per project.
• 55% of the projects had returns in the $100,000 to $500,000 range.
• 80% of the respondents felt an increase in competitive advantage.
• BPM’s value to the company was higher than ERP, CRM and SCM.

How are these kind of results consistently possible? Once you understand how BPM works, it becomes clear;

• The ability to design process in a graphical (non-technical) way by the business process owner or analyst;
• the ability of the application to easily integrate with a wide range of data sources and supporting systems, with bi-directional data sharing;
• the ability to quickly execute a new process for evaluation, a facility to “roll back” an executed process if you get it wrong, without having to do clean-ups to data etc. 

In a survey conducted in 2007 by Forrester Research of ITIL adopters in 2007 67% believed they were benefiting from adoption but only 4% reported having means in place to measure that success!  Only 9% of respondents could even link the process changes to performance improvements,  75% could not link process maturity to performance improvements!

When you take the technical capability of BPM, and drive it with a process framework such as ITIL, you end up with a unique, extraordinary solution that is as mature as any company needs, has an inherent roadmap built-in for future process and service integrations, but most importantly, provides the process management and measurement that so many companies have been longing for with their ITSM program. 

In summary;

1. BPM is the definition, improvement and execution of an automated process
2. BPM is rarely limited by technical constraints, and can be used to rapidly deploy solutions within, across and between organizations
3. BPM is flexible enough to quickly adapt to changing business needs without requiring changes to the underlying technology
4. BPM is flexible enough to allow changes in the underlying technology without requiring changes to the business process being  executed

Special thanks to David Elliott of ICCM Solutions Ltd for providing much of the content above.  He shares a Business Process Modeling and IT Management background like myself.

Microsoft Office, Outlook, and Sharepoint Integrations with e-Service Desk

The following web demonstration of Microsoft Sharepoint, Office and Outlook was created by one of ICCM’s key partners in North America; Whitlock IS (www.whitlockis.com)

This short video clip shows how ICCM e-Service Desk is leveraged through Microsoft Sharepoint, as well as the integration available to Microsoft Office through smart-text binding and the MS office ribbon bar capability.  Yes, you could completely operate e-Service Desk through Sharepoint, thanks to its use of webparts technology for it’s interface.  Other integrations;

• Tasks resulting from process orchestration can be revealed through Microsoft Outlook.
• Planned Service Outage calendars can be shared through Outlook.
• Microsoft Word and Excel documents can be linked to folders within e-Service Desk (folders are Incidents, Changes, Problems, etc).

Microsoft Integration Demonstration

A BPM Example using the ITIL v3 Event Management process

As noted in my blog entry “The Difference between traditional IT Service Management Applications and a BPM Based IT Service Management Solution” there are many benefits that result from a Business Process Management (BPMS) based Service Management solution such as ICCM e-Service Desk. The following demonstrates and highlights an example of how BPM technology is applied to the ITIL Event Management process.  Event management existed in the vendor specific reference process models that I used prior to the introduction of ITIL v3.  Fortunately, Event Management survived and was included in the final drafts of ITIL v3.  Incident Management, when integrated technically, and from a process perspective, is where a good deal of technical integration and automation takes place.  Unfortunately, this automation sometimes leads to unintended results and a ton of effort.

Traditionally, when integrating monitoring systems that generate events into a Service Management or Service Desk solution, they most often “dump” alarms directly into the Incident Management process.  This integration is often very complex as well.  The resulting “process problem” creates the need for “mass deletes” and purges to deal with incidents that aren’t actually incidents.  This is an obvious waste of resources, but more importantly, it creates a number of inaccuracies that get recorded and consumes time for agents and/or managers to fix the problem for reporting.

Prior to joining the ranks of ITSM consultant, I used to work in Enterprise Systems and Network Management solutions.  It was always best practice, and still is, for correlation, summarization, filtering and suppression to occur as close to the source as possible and within various element managers such as the Network, System, and Application management platform.  Normally, only events that are necessary for service reporting, and/or require operational intervention should be recognized.  If that is properly configured (which is rare but does occur), then the next step is to manage and control what enters the Service Desk.   Event management is about managing and monitoring events, resulting from alerts,  as objects with a lifecycle, similar to Incident, Problem, and Change management.

Some terminology first;

• Folders – A folder is the object that progresses through the procedure. Each time a business process (i.e. BPM procedure) is initiated; the system creates a folder containing one or more electronic pages of information. When an end-user opens the folder, these pages of information are displayed on separate tabs.  At the bottom of the window, action buttons are displayed. Users can add or edit the information on the folder pages by clicking on actions. A folder can also contain documents. These documents are attached to the folder using a Clip.
• Stages - A stage is where the folder is in the process. Stages can be thought of as the place where the folder stops, awaiting an action like where a paper form stops on a managers desk before they approve or reject it.  There are six types of stages in BPM;
  • User – where an action is required by a single, specific user, a user stage is specified.
  • Group  - where an action is required by one (non-specific) member of a group such as a support team or a receptionist pool, a group stage is used.
  • System – where no user intervention of any type is required and where system validation/ automation is required, a System stage can be used.
  • Sub-procedure – interrelated processes may need to complete in parallel rather than sequentially. Sub-procedure stages are used for this, linking additional maps (called sub maps) back to the main map. Sub-procedure stages can be queued to continue when one or all of its sub maps have finished.
  • Common – actions from a common stage can be applied to multiple stages on the same map, eliminating the need for duplicate actions around several different stages.
  • Archive – when a folder reaches an archive stage, the process is completed and when the folder is no longer active and cannot be viewed by the Client. This information s still in the underlying database, and can be reported on using reporting tools.
• Actions – Actions represent the activity that happens to a folder as it progresses through a procedure. Actions can loop back to the same stage or can link stages which would cause the folder to move from the originating stage to the recipient stage.  There are five types of actions in BPM;
  • User – Actions performed by a user, such as entry of data and making decisions via buttons associated with a form. These actions automatically appear as buttons at the bottom of a form in the Client.
  • Timed – Actions that are triggered by a date-time condition. Timed actions are triggered after a set time period before or after a specific event.
  • Conditional – The Process Engine can test a condition and performs actions based on the result. Conditional actions are executed when their only start action if property is met.
  • Rendezvous – Once a sub-procedure has been completed any folder waiting at a sub-procedure stage can be moved on using a rendezvous action. This action can be set to be dependent upon any or all of the sub-procedures being completed. This action can only be drawn from a sub-procedure stage.
  • Flagged – Flagged actions are used to link maps and external applications with a BPM procedure. A procedure may contain more than one map, allowing actions in one folders life cycle to influence actions performed upon another.  Flagged actions are triggered by flags, which can be raised to declare that an event has occurred and to pass data between maps.
• To Do List – Each users “To Do” list contains folders on which the user is required to perform an action. The BPM Engine automatically updates this list whenever a folder reaches a stage for which the user is defined on the To Do List.
• Watch List – The Watch List is similar to the To Do List. However, users do not normally have to perform an action on folders on their Watch List the folders are just displayed there so that the user can monitor the status of the folder as it progresses through the procedure.  Just like the To Do List, the BPM Engine automatically updates the Watch List whenever a folder reaches a stage for which the user is defined on the Watch List.

The following diagram is the event management process within ICCM e-Service Desk.  This is a “Map” which essentially shows the stages and actions in a given process.  The important thing to note is that this diagram isn’t just a picture.  It is the model that is used to drive the application. 

ICCM e-Service Desk Event Management Process Map

As you can see, the process is defined from start to finish and is not embedded into an event management application.  If you wish to change any flow, integration or activity, it is done to this map.  Forms are also associated to each of the stages and actions. 

You will notice the flagged action (green flag) which would be the flag raised by monitoring systems to generate an event.  As indicated before, flagged actions are how external systems, such as monitoring systems, as well as processes within the system, integrate with one another.  This is done via web service, API, database or any number of other triggering mechanisms.  Subsequent to these, you can see the manual actions (a hand), timed actions (a clock) and conditional actions (a question mark) that identify filtering and suppression that takes place.  As long as the monitoring system could raise this flag and pass data, it could easily be integrated to e-Service Desk.

The Event Manager would actually use a role based “Rules configuration” form such as the following.  Administrative forms allow for the modification of non-folder data, such as administrative data;

ICCM e-Service Desk Event Management administration form.

From this, you can see the Event manager (the person) has the ability to identify events that should be suppressed, filtered, closed, turned into an Incident, Change or Problem, etc.  It’s very easy and you have the ability to quickly modify the rules that the process executes against.  With the Enterprise nature of BPM, handling 40,000 new folders a day is easily handled with two process engines and more could easily be teamed if needed should that volume grow. 

Hopefully this blog entry has provided you with an idea of how easily and quickly e-Service Desk is leveraged for Event Management.  The same holds true for any of ITIL v3 modeled processes within ICCM e-Service Desk.  This is also how new processes are designed, rendered, orchestrated and integrated as well. 

If you have any questions or would like to see Event Management and/or any of the other processes, please send an email to jclark@iccmco.com to setup a web demonstration.

Have a great day!

The Difference between traditional IT Service Management Applications and a BPM Based IT Service Management Solution

As ICCM continues to grow in North America, and around the world, our focus is on raising the awareness of BPM and its impact on IT Service Management.  Customers in the United Kingdom and Europe already understand the value proposition of e-Service Desk, and typically state there is no comparison between a traditional ITSM application and ICCM e-Service Desk.

Yet here in the United States, customers still take the traditional “application specific requirements approach” to RFP’s and solicitations, comparing e-Service Desk on a functionality basis to other “vertical” ITSM solutions on a requirement by requirement basis.  While this approach is fine, and we are more than happy to engage that way if that is what is required; if these customers considered for just a moment, what BPM technology provides to any business process, including those defined by the ITIL framework, they would quickly realize any process requirement can be met out of the box, or through process design, as that is exactly what BPM was created to do. 

I have outlined below some of the key differences between traditionally developed (from the ground up) IT Service Management applications, and BPM based IT Service Management solutions, whether purchased from a vendor such as ICCM, or developed in-house with current BPM technologies such as Metastorm and other BPM solutions;

1. A BPM based Service Management is not “hard walled” and limited to original process scope.  Traditional IT Service Management solutions are confined to the processes and “process modules” included or purchased, often times “digitized” in multiple technology platforms that are loosely integrated through complex integration mechanisms.  Conversely, a BPM Service Management solution provides the infrastructure for an organization to add customer (or bespoke) processes, beyond those defined by ITIL v3.  And these new, custom processes are as easily integrated into the ITIL processes, and measured in the same form and fashion.
2. A BPM Service Management solution is driven by a graphical process model from start to finish rather than manually “coded” to support a process requirements specification.  Traditional IT Service Management solutions may try to implement processes from models and may use UML models for requirements definition, but the solution is “developed” or “customized” to support the process requirements.  A human being (typically referred to as a developer) must convert the model or requirements specification into code or configuration settings to “imitate” the process.  BPM allows for models used for documentation, to be used for defining how the application executes.
3. A BPM Service Management solution inherently is self-documenting.  Traditional IT Service Management solutions may provide some documentation, but many, including the “leaders” in the Gartner Magic Quadrant, require extensive manual documentation effort.  The resulting documentation almost always ‘atrophies’ over time as the application is modified.
4. A BPM Service Management solution inherently provides “workflow” as a means of controlling application.  BPM is essentially a superset of workflow, taking traditional workflow technology way beyond and incorporating integration, roles, forms, attachments, handshakes, timings, etc as part of the workflow.  Traditional IT Service Management solutions may provide embedded workflow within specific hard-walled processes, and are typically used for status or field control.
5. A BPM Service Management solution is an integrating platform by nature.  BPM technology was developed many years back to solve a specific business problem; managing and optimizing business processes that thread though a number of heterogeneous systems.  Why train users on six different interfaces for systems that do not measure the overall business process?  Isn’t it more optimal to leverage one technology to provide a single interface, controls and measure the handshakes and transitions among the systems, and provides the necessary process foundation for making any kind of improvements.  This heritage of BPM is not lost in today’s BPM technologies, which make integration to virtually any system “out of the box”, cost effective and easy.  The only hard and fast requirement is that you understand the process.  Traditional IT Service Management solutions typically require integration products and projects, which in some cases are as elaborate as the implementation of the solution themselves.  And because they lack the overall process awareness, they typically are not capturing the necessary process data to do any kind of process improvement.
6. A BPM Service Management solution provides a “process orchestration engine” sometimes referred to as an Enterprise Orchestration Engine (EOE) that can be leveraged for other processes, not just IT Service Management processes.  Customers have the option of implementing BPM tactically or strategically.  With a tactical implementation, the Service Management solution is essentially identical to traditional IT Service Management solutions in that the technology is only orchestrating ITSM processes.  However, with a strategic implementation, IT Service Management can be the first of many business processes to be implemented and can become the foundation on which to build an Enterprise Orchestration Engine.  A pre-designed solution, based on ITIL v3 best practices, such as ICCM e-Service Desk, can service as not only your Service Management platform and initiation point, but a launch pad for a BPM environment within your environment.
7. A BPM Service Management solution doesn’t require extensive administration, designer or user training.  As BPM technology typically “walks” a user through a process, preventing mistakes and errors, monitoring timings and conditions, the amount of training required for a user is minimal.  Furthermore, with a common interface for any process, as user only needs to understand process specific information, as they will understand navigation almost immediately.  Traditional IT Service Management solutions often times have entirely different interfaces by process, requiring process specific training for both administration and navigation.  A BPM trained administration/designer resource can be leveraged for any process.  Traditional ITSM solutions typically have multiple training curriculum for each process and/or module, and typically at extensive cost.
8. A BPM Service Management solution, depending on the BPM technology, typically incorporates document and forms management. Another by-product of leveraging BPM technology is that it typically supports document or form management, allowing for easy forms modification, document storage, indexing, etc.  Traditional IT Service Management solutions usually can add this capability through third party add-ins, or custom development.
9. A BPM Service Management solution costs significantly less to purchase, maintain, administer, change and support.  The benefits of developing and executing processes within a BPM environment are well known and documented.  See my first blog “Optimizing IT with Business Process Management” (http://tinyurl.com/l9l847) for an outline and reference to this research.  As an ITSM solution provider, we are able to incorporate our experience, customer feedback and improvements to our system in very little time.  This savings is obviously passed along to our customers in that we don’t have to charge for long development, QA, testing cycles, nor do we have to have a large organization to do the design.  Traditional IT Service Management solutions are encumbered by their own legacy application technology.  According to Gartner, this is one of the reasons they cite that there is no innovation in the industry, as it is too expensive and time consuming to “add” capabilities to existing solutions.  So they acquire other companies and solutions from other vendors but the “suite of solutions” still looks like 6 different boxes shrink wrapped together.
10. A BPM Service Management solution results in greater visibility into business metrics and response time to business needs.  BPM technology provides common process architectures, process metrics, performance indicators, audit trails, timings, etc.  Because this architecture can be leveraged into the business, either integrated to existing business systems or as a full business process orchestration solution, visibility and integration into the business is almost inherent in the solution.  Traditional IT Service Management solutions focus just on IT Service Management and often miss opportunities to integrate, at a process level, with business processes important to the business.
11. A BPM Service Management solution provides quick and reliable compliance with regulations and improved communication between business and IT silos.  BPM customers have been able to demonstrate PCI, Sarbanes-Oxley, FDA and other compliance in a very short amount of time.  Evidence required by the control objectives of any compliance framework typically are the result of process execution, which is easily mapped and measured within the BPM environment.  There are plenty of examples available of how customers within and outside of IT Service Management, has been able to demonstrate many forms of compliance, in a very short amount of time, and significantly reduced cost.
12. A BPM Service Management solution provides improved transaction reliability and seamless B2B integration with partners, suppliers.  Thanks to BPM technology integration, measurement, validation, and auditing, it is almost impossible to miss transitions or drop information.  Typical “objects” within BPM technology contains various mechanisms to ensure that the objects flow through the process with measurement and assurance.  Traditional IT Service Management solutions typically provide “records” which can be lost and modified to bypass process orchestration.
13. BPM Technology and Architecture lends itself to several flexible pricing models.  BPM based ITSM solutions are inherently “web 2.0″ and require little to no modification to a customers clients or systems.  This architecture lends itself tremendously to some very flexible pricing structures, making the solutions even more affordable to a customer.  This includes Software as a Service (SAAS), Application Service Provider (ASP) as well as Subscription and Traditional licensing models.
14. A BPM Service Management solution can be implemented “in whole” or modularly, depending on the existing systems and processes of a customer.  Traditional ITSM solutions tend to “fall down” if part of their process is contained in outside systems.  A BPM solution, thanks to the integration architecture, process focus and measurement, and flexibility, allows for a BPM based ITSM solution to be implemented modularly, or completely, depending on the customers needs.

Other smaller differences that customers make comments about;

• Less mouse clicks to get through a process
• Web Client and web interface, no client installation or configuration
• Integration to outside tools

It’s time for the ITSM industry to recognize a new and proven approach to process execution, one that provides;

• Process Focus: eService Desk is designed with process in mind first, not as an afterthought
• Process Creation: You have the ability to design and orchestrate specific processes to your organization, as extensions to e-Service Desk completely stand-alone.
• Ease of Administration: Process Owners have ability to configure the system without the need of specialized technical resources
• Low Cost of Acquisition, Rapid Implementation Time , and Minimal Support Requirements and a Considerably Low Cost of Ownership
• Microsoft Integration: SharePoint workflow/attachment, Office Plug-ins, Tasks and Calendars in Outlook.

All it takes is a demonstration to see what this is all about!  For a complete set of “Frequently asked questions (FAQ’s)” about e-Service Desk, download our FAQ document; http://tinyurl.com/dj9zmz

Questions you should ask ANY IT Service Management Vendor

Having been a consultant and IT Manager for so many years, now to join the ranks of ITSM Software vendor, I find myself asking…Myself…  “Why did I make this switch?” 

Obviously, I found that the solution I currently represent, ICCM e-Service Desk, to be an extraordinary and compelling means of process orchestration.  However, prior to joining the “dark side”, I had been working on business process modeling, architecture modeling, and model driven orchestration of process underpinning applications for a number of years, and e-Service Desk approached that capability, especially around IT Service Management.  But it’s more than that. 

I have watched, observed and read about so many failures around IT Service Management and believe there has to be a better way.  I have a genuine concern that ITIL/ITSM could become a flash in the pan if it doesn’t start showing more demonstrable successes than failures.  I wrote in my last blog entry “Why ITSM programs fail” (http://tr.im/nTYb) highlighting many of the reasons ITSM programs fail, or do wonderful things, but fail to achieve the objectives that they were started for in the first place.  I think part of this is because people in IT expect non-traditional results from traditional approaches.

Over the past twenty years, I have written RFP’s, responded to RFP’s, met with many ITSM vendors, delivered a good many ITSM projects (people, process and technology) and implemented a good number of ITSM solutions.  I have found some fairly common characteristics in how customers and vendors interact- which leads to me writing this blog entry. I thought I would offer some basic information, suggestions and guidance that may help you in selecting the appropriate solution to address your ITSM program needs, and avoid the failures.

Some of the key tenants…

• “Don’t trust your ITSM vendor…” .. There, I said it.  Don’t trust me, don’t trust HP, BMC, Service-Now, CA, Frontrange, EMC, or any other vendor.  Start with that, and you will be on your way.  Yes, this makes the RFP process very difficult because you don’t know if the information is truthful.  Here’s some insider information; While ICCM doesn’t practice this, other traditional software vendors will answer “yes” to all the questions on your RFP response in hopes to get to the “next stage”.  Once there plan on a “kabuki dance” around those requirements that they don’t entirely meet.  At this point, they usually try to convince you out of your requirement, or propose a costly and complex solution that they hope never is realized.  Guidance: Obviously, trust should be earned, not something given because of brand name or stature.
• Pink Elephant or OGC Certification Only speaks to effectiveness – None of the certifications I have seen so far test anything other than process effectiveness.  If two solutions orchestrate Incident management identically, but the second cost 10 times as much and requires three times the resources, they will still be seen as equivalents.  The certifications do not factor in cost of ownership, complexity, etc.
• Check References – I worked with one of the larger ITSM software companies on the planet.  We had a great many references but rarely did we have any contact information, quotes/comments, from the specific customers.  Sales would often use customer comments and quotes from other products or services out of context.  Guidance: If it were me talking to ITSM software vendors, I would not only check references but ask very specific and direct questions of their customers (examples that I will provide below).
• Look beyond Waves and Quadrants.  This was a great webinar title conducted by Third Sky a few months back.  They made some very good observations about the IT think tanks.  Gartner and Forrester do highlight very well, the issues with the industry, but do very little, in my opinion, to drive and support innovation and new approaches.  They wonder why the industry hasn’t advanced – could it be because they continue to recommend the 800lb solutions as “leaders”?  Most of the information they provide are lagging indicators (looking in the rear view mirror), vs. leading indicators (looking to the future).  Guidance: Use the Gartner and Forrester research as a data point, not philosophy.  It’s interesting but not significant.  I don’t think even Gartner analysts expect you to consider their research infallible and it should be used in context.
• Request a Trial/Proof of Concept – I think this is the single best way to differentiate solutions.  An RFP provides a static, two dimensional, myopic view which as I stated before, may not be honestly responded to.  The state of modern technology and software should allow for quick “Try it before you buy it” scenarios and use cases.
  • If you don’t have the time to invest in understanding “What’s behind the curtain”, I wouldn’t invest anything at all in any solution.  If you do select a solution that doesn’t pass the tests of efficiency, you may be spending a lot of time (usually billable to a consultant) figuring out how to make what’s behind the curtain work for you.
  • If the software vendor doesn’t have the time to invest in you as a customer, they either aren’t interested in your business, or they have something they would rather you not see before you purchase.

Since RFP’s tend to be process/technology specific, and vendors can dance around the responses, I thought I would provide structural/context questions to ask any ITSM vendor, rather than drill them on requirements.  Their responses, but more importantly how they respond should be noted.  Hopefully, these questions allow you to answer most of your specific RFP/Requirements yourself.  Since we are talking about process solutions, I have included questions about effectiveness, efficiency, usability, and administration/maintenance. 

With regard to all these questions, it is important to note they are subjective, requiring elaboration – a simple yes/no will not suffice.  And if you get yes/no, follow it up with “How?”.

1. What is the “Design Basis” of your solution? In other words, can I see the process and/or architectural documentation, which drove the out of the box configuration?  This way you can determine how much gap exists between your processes and the solution processes.
2. Can your solution be used “Out of the box”?  This means, other than linking it into your people, locations, roles, etc, can the solution be used “as is”?  Many customers anymore want to take a more “Adopt and go” strategy as their current processes aren’t well documented and managed.
3. Are customers using it like this?  Can we speak to them?  Very important to understand what it means to use “Out of the box”.
4. Can your technology efficiently be used for purposes other than that of IT Service Management?  In other words, can I use it strategically with my business, vs. tactically, just within IT?  Does your solution support other processes I define without “major effort”, or do I need to adopt your processes as my design basis?  (Major effort meaning I will need to hire consultants to make it work)?
5. Does your solution orchestrate processes I need in the near term AND long term on my roadmap, or is it just geared at the processes I am looking to implement in the next six to twelve months?  Consider your ITSM roadmap and what processes you hope to implement and by when.  This will keep you from optimizing near term processes and sub-optimizing far term processes.
6. Does your solution provide a consistent set of metrics and measurement around process execution?  For example, can I easily determine lead times, wait times, queuing, etc.  Metrics needed for process optimization.
7. What is the reporting capabilities available from the solution and what reporting will have to be obtained from third parties?
8. How am I be able to perform process improvement activities efficiently?  Where do I get the data?  Will it be leading or lagging indicators? 
9. How many process improvement engineers will be needed to be able to perform any analysis across a number of processes?
10. How does your solution provide a means of version/source control from a process perspective?  Can I move “processes” around as a single object?
11. Does your solution have a common look and feel across all processes?  How much will my users have to train on different modules or components or can I train them once?
12. Does your system integrate to my common desktop tools such as Microsoft Office, Excel, and Word?  For example, can I link documents to objects in the ITSM database?  What options are available to integrate to SharePoint?
13. How much does your solution walk me through a process, vs. how much do my users have to know in order to get through the process?  This is probably an effectiveness question as well.
14. What technology add-ons will my users need on their desktops or laptops to utilize your solution?
15. Change Management is always an intensive process.  How many key clicks, mouse clicks, forms and data elements are included in getting an RFC from start to finish?
16. How many Administration resources will be needed to implement your solution? How many to support and operate it ongoing?  Are the fully loaded, or can they be shared in other areas of my organization/business?
17. When a major or minor release comes out, how much of my process design basis will be affected?
18. Can my “Configuration” be moved and provided via SAAS/ASP or vice versa?  How difficult is it to move my specific configuration (design basis) and data between environments?

Why ITSM Projects Fail…

It’s sometimes laughable reading blogs, LinkedIn group discussions and Tweets about ITIL and it’s successes and failures.  With ITIL, it seems, there are detractors, zealots, philosophers and practitioners.  And then there are those who just want to be able to associate success with what they are doing…

There are many examples of where ITSM projects fail to fulfill the objectives set forth.  There are plenty of reasons why this happens;

1. Goals and Objectives aren’t defined ahead of time.
2. ITIL for ITIL’s Sake
3. Process Only Focus – Processes are defined that cannot be executed within the given (or standard) software
4. Technology Only Focus – Misplaced trust/expectations in the software vendor that a single process design basis drives the way the tool functions
5. Missed Management of Change or Organizational Change Management
6. Failure to define what “success” is or knowing “we have arrived”

 Other than #2, these are reasons that many IT programs and projects fail.

I would argue that these are symptoms of a larger issue that plagues many in the Information Technology organization.  ITIL is about running IT “like a business”.  This presumes a profit/loss mentality, managing expenses, and being measured real time and managing to that.  Unfortunately for many in IT, they have never actually operated a business before.  They have not had to “make payroll” this month.  They have not had to deal with the up and down business cycles.

Historically, IT has been a safe place to be regardless of economic or business conditions, and waste can abound without being noticed.  Only until recently, has there been real pressure to focus and measure IT.  The number of IT Service Management consultants now looking for work is a testiment to the fact that ITIL is no longer a blank check or guarantee of success.  It still requires smart, intelligent, data based decision making on the part of those desiring the end results (and actually defining those end results in business terms ie. contribution to the bottom line).  In organizations where making a profit is not criteria for success, efficiencies that drive down the cost of operations and drive up operational revenue are foreign concepts (gov’t, IT, etc).  This is why there is often so much waste in government—“what gets measured gets done”, and the profitability or efficiency of operations (they are the same thing) doesn’t get measured.  In private enterprise (like business units) you literally don’t exist without profit; therefore, survival is predicated on constant attention to costs and revenue and efficiency.

As long as IT is a cost center – this divide will continue to exist, and finding efficiences to drive down costs of operations or increasing operational revenue will be as foreign to IT as the fundamentals of private enterprise.  As long as the same urgency for profit is absent in IT, I don’t expect IT business alignment to happen overnight.

When you start a business, you define what your product or service is, who are the customers, what is the marketplace, and THEN focus on support and returns.  This is standard Supply Chain best practices (Supply chain council), but IT typically implements this business model in reverse (starting with Incident and problem management). 

My suggestions on how to think about and approach things differently and with a business (profit) focus;

1. Define Business goals and drivers, linking principles to be realized to those goals and drivers – assessment!   Make sure these principles align closely with your business partners.
2. Start with defining your customers and the services you provide to them.  For anything else that doesn’t have a direct or indirect customer, ask “What value is this bringing to my business?”
3. Do NOT label it your “ITIL project”.  It’s your improvement, quality, or efficiency program, brand it accordingly…  ITIL is simply an input and set of books. Don’t make it about ITIL.
4. Make sure process and technology teams are aligned and incorporated.  Their success criteria should be highly coupled (they both succeed or fail together).
5. Remember “Organizational Change Management” (OCM).  Process and technology, especially when there is a considerable “People” component to it, often succeeds or fail because of OCM.
6. Select process and service supporting technology that not only supports Incident and Problem management (those are “return” processes of a business supply chain, and not what a normal business would start with), but also provides the service design, transition, and improvement processes as well.  Most important; with a focus on efficiency ie – not a lot of different products bundled, doesn’t require a PHD to implement, doesn’t require a ton of time to implement, etc.

It’s really not that hard – but the answers aren’t always in a chapter of the ITIL books.  The answers are all over the Internet, taught at most business schools, and most likely someone in your organization already has these fundamentals down, or you wouldn’t be in business to begin with.

Optimizing IT with Business Process Management (BPM)

Executive Summary

“It is not the strongest species that survives nor the most intelligent, but the one most responsive to change.” – Charles Darwin

 The economic conditions of 2008 and undoubtedly 2009 will go down in history as the worst economic slump since the Great Depression.  And since Information Technology wasn’t around in 1929, this is arguably the worst economic downturn for IT in history. 

Like others my age, many in IT will recall the economic downturns over the past 20 years (or more, but I am not going to date myself), where the IT organization was considered a safe haven for employment, and viewed by the company as the life boat, providing innovation to help the business position itself properly for the next business upswing. 

Now that organizations have options and alternatives such as IT outsourcing, off-shoring, new business models and IT service delivery mechanisms, it is incumbent on any vestiges of remaining IT to optimize its own processes and itself in order to validate and confirm its contribution to the value chain of the business it serves.  As many in the industry painfully understand now, the IT organization is no longer immune from this or future recessions and/or business cycle downturns. 

A wise man once told me; “It takes ignorance to take something simple and make it complex, but it takes a genius to take something complex and make it simple”.  ITIL isn’t necessarily a complex subject, but it has been made overly complex leading to misapplication and misguidance resulting in a number of failures.  The current “back to basics” trend suggests people and organizations want real lasting strategies, approaches, methodologies and technologies that make sense.

This whitepaper is intended to provide insights and ideas into how Business Process Management, or BPM, an already established process enabling technology, can be applied to IT processes as a means of simplifying, driving costs from, and optimizing your IT organization. 

BPM Explained

Most people guess the “BP” correctly but opinions vary on the “M”.  Some say “Modeling”, “Monitoring”, and others “Measurement”.  Actually – Business Process Management encompasses all these things and typically at the root of it all is the concept of models.

Business Process Management (BPM) is a set of methodologies and technologies designed to support explicit business processes, right from analysis and definition to orchestration/execution, monitoring and optimization of business processes. The BPM market was formed from the opinion that business must be managed from a process point of view.  The rest of the business world actually drove the creation and demand for BPM.  BPM vendors provide technology that deliver “Model driven process execution” as opposed to code-based execution.  Gartner Group advises that this is the best way to enable business and IT professionals to manage and change processes collaboratively, especially in a volatile business environment^[1].

ITIL® is about formalizing and optimizing the way in which we (in IT) behave and work.  Process execution and improvement requirements are often unique to each organization, even when adopting ITIL® best practices. This obviously favors a “Build” vs. “Buy” approach to supporting technology.  Unfortunately, time frames and costs are not compatible with this level of process improvement.  BPM is the alternative approach to “Build” and “Buy” that delivers flexibility and uniqueness of “Build”, while at the same time providing the time value, standardization and reduced cost of “Buy”.

The basic value proposition of BPM is the ability to enable processes with less effort and cost, with higher quality than traditional means. In fact, BPM is intended to respond to the following set of business values:

• Agility: The ability to bring new products and services to market more quickly and adapt processes more effectively to changing market demands
• Efficiencies: Most processes are inefficient due to manual effort, poor hand-offs between departments and a general inability to monitor overall progress. The deployment of BPM solutions helps to eliminate these problems. The efficiency benefits are typically expressed in the reduced number of Full Time Employee’s (FTE’s) required to perform particular tasks
• Visibility: Providing management insight into process-based performance indicators. This enables an organization to make better business decisions and handle exceptions better.

Gartner research indicates that even without process redesign, a basic investment in a BPM suite yields significant returns. By simply “making the current-state handoffs, timing and responsibilities explicit, productivity improvements of more than 12 percent are normally realized[2]”. In another report, Gartner indicates that 78% of projects see an internal rate of return (IRR) of greater than 15%.  The same report indicates that these projects were deployed in very quick order (67% in less than six months, 50% in less than four months). 

BPM has proven in almost every case to increase efficiency, effectiveness and agility.

As a management discipline, BPM emphasizes modeling the business from a cross-functional process perspective and establishing performance goals from that perspective as well. Years ago Dr. Geary Rummler called this “managing the white space in the organization chart,” and it remains central to the process perspective today.

To some management consultants, BPM begins and ends with process modeling, but there’s much more. Business Process Management Suite (BPMS) solutions provide the technology platform that takes models and metrics, defined by the business, turning them into an orchestrated and executable implementation. This platform actually automates the human workflow, integrates data between disparate backend systems, and executes the business rules, defined and controlled by the process model. And while it’s executing the business process, the system continuously records snapshots of data that allow the process to be measured end-to-end, as well as in real time, and corrected easily when the need arises.

Modeling as a Science (and art)

Modeling is a formal means of documenting the artifacts, relationships, goals, steps and states of the end-to-end process.  Documenting processes in a way that can be understood across functional units, geographic units and divisions of the enterprise.  Processes can easily be analyzed for cost, quality and efficiency improvements which is a key feature of BPM as a new management discipline.

Process modeling is inherently a business function, and modeling technologies empower the business to define the steps, and the performance metrics.  While there is an art to model layout and construction, methods and standards are employed and followed for consistency and structure.  The most important thing to understand is that a model is not just an illustration or graphic.  The objects and links in a model represent objects and relationships that are re-usable, can be abstracted, related, measured, etc.  In other words, a model is a window of something larger that cannot be viewed in two dimensions in its entirety.

Most modern modeling tools support not only publishing complete and consistent process documentation in various formats, but also provide a means of process analysis through various tools such as simulation.  This allows “what if” analysis and process improvement initiatives that yield real business analysis metrics – resources, cost, units, etc.

Inefficiencies in IT (why IT needs “Optimized” in the first place)

Business Process Management technologies obviously cannot solve all issues that result in IT “sub-optimization”.  Some are rooted in poor management practice, organizational challenges, and barriers that completely derail optimization efforts.  Obviously management support and involvement is necessary for optimization to take place.  Other “usual suspects” of IT sub-optimization include:

Lack of adoption and understanding of a process culture

Obviously the “people” component of processes and IT optimization require that where there are human “actors” or customers of the process, they must understand their part in the processes and workflows, the metrics, control objectives, goals, owners and most importantly, their role within the process.  Process defects are usually a result of people incorrectly executing a process, or supporting technology that does not enforce or detect process controls.

Processes operating in isolation

As Dr. Geary Rummler stated in his book “Improving Performance – How to manage the white space on the organization chart”, it’s the organizational white space often missed as technology and process are implemented in vertical, stove pipe fashion.  Process integrations and opportunities to integrate are often missed, and there is little to no process improvement possibilities where processes have been organizationally “stove piped” or implemented within vertical technologies.

Atrophied process initiatives that have failed to demonstrate value

Many ITSM programs start with Incident, Problem, or Change and Configuration Management and then stop.  Why this happens is subject for debate.  One reason might be that technology solutions are selected based on the requirements of the upfront processes that are known at the beginning of the project.  Since processes to be implemented later aren’t included in the requirements, tool selection results in an optimized tool for the initial processes – but a technology that sub-optimizes or completely omits support for future processes.

Managing artifacts but not processes

The problem with implementing many different solutions to address process execution is that integrations typically transfer artifacts such as incidents, changes, and configuration items, but miss process metrics and information – metrics that are typically used to measure and manage the process itself.  As a result, process metrics and measurements are not typically incorporated into the integration design.

BPM for Service Strategy and Design

Modeling Strategy through Principles.

When ITIL® Version 3 was kicked off, the road show actually included a model that decomposed the Deming Circle (Plan-Do-Check-Act) into sub-domains.  One could argue this is a “meta-model” (model of a model) describing the “supporting” artifacts within the scope of each step of the Deming circle. 

From a Strategy perspective, these items can be captured in model and object form, reused in other models, and related in different ways to other models for other purposes.  For example: Policies and Principles can be captured, related, grouped, categorized and prioritized in strategy models.  This provides the basis of future states, what is to be accomplished, and in what priority.  Later, those principles and policies can be related to workflow activities that will explicitly identify where policies, goals and objectives are met by the processes being implemented. 

Various types of models can be leveraged for Service Design such as goal, capability, organizational, class, and use case models – to name a few.  Again, these can be related to objects of the strategy model’s policies and principles, and become the basis for yet more downstream models.

One advantage to using models is that they provide a bridge to Enterprise Architecture and other areas as well.  For example: Enterprise architects will often refer to “Capabilities” of an organization, depending on the EA framework they leverage.  If you look at the definition of capabilities, it aligns closely to what ITIL practitioners call a service.  They are similar and through modeling, it is very possible to align and integrate your Enterprise Architecture initiative with your IT Service Management initiative.

BPM for Service Transition and Operations

Process mapping and execution through BPM

Business process models and maps are valuable tools for understanding organizations and how they operate.  Dr. Geary Rummler summarized the inherent value of developing business maps with the simple phrase, “If you can’t draw it, you don’t understand it.”

By using several types of models such as organization, workflow, state and goal models, with relationships to one another, you can capture the verbs (what gets done) AND nouns (what artifacts that work is done on).   But most importantly, how all of these activities and objects will be measured and managed. And this happens at levels that are meaningful for the organization.  Within the modeling environment, these models can be related back to strategy models to reference and answer the question “What are we doing, and why are we doing it?”

From an orchestration perspective, many BPMS technologies have reached the point to where graphical models actually ‘orchestrate’ the service management application.  Process orchestration is a growing business technology that can be leveraged stand-alone or across disparate systems to make a process appear as one despite the many systems involved in supporting the process. 

The benefits of leveraging BPM for IT Service Management include;

• Consistent and standardized process measurement across all ITSM processes (lead time, queuing time, cycle time), resulting in decreased cost and effort to produce process dashboards and reporting.
• Cost effective implementation of preventative process controls vs. detective controls resulting in reduced training requirements, and less after the fact documentation and reporting.
• Reduced reporting demands as actionable process metrics and preventative controls result in immediate actions such as escalations, messaging, and artifact modification prior to process defect or service impact.  Process improvements can be identified before a poor service experience with your customer has happened and implemented in a remarkably short amount of time.

BPM and Continual Service Improvement

By this point, Continual Service and Process Improvement is implicit as the process has been designed, modeled and linked based on strategy defined by the business customers with appropriate goals and metrics.  If BPMS technology then is being leveraged for process orchestration, continual service and process improvements are easily spotted, adjusted, modified in orchestration, and monitored.

The whole point of BPM is to optimize and improve processes that quickly and easily can be change based on changes of the customer, the business, or the organization.  By leveraging simulation capabilities available with process/workflow modeling tools, “what if” analysis is easily performed against proposed changes to a process based on real metrics. Once a process improvement has been identified, it can be modeled fairly quickly for orchestration among users of the process.  Measurement then is immediate once the new orchestration is implemented.

Summary

Never before has business and IT been under such tremendous pressure to transform itself and make decisions based on actual value contribution to its customers.  This new reality requires a level of IT optimization that is no longer an optional decision.  Business Process Management Suites (BPMS) have been providing demonstrable value to the business process and application side of the house for years.  Why it hasn’t made inroads into IT Service Management until now is an interesting question.  The majority of BPMS vendors rarely target internal IT organizations for IT process design and orchestration, missing out on huge opportunities for them to reduce cost and increase agility.

IT process documentation is costly to create, often ineffective and inconsistent, difficult to maintain, and usually ends up on a shelf or in an electronic store never to be touched again.  Technologies implemented to support these IT processes often fail to achieve alignment with the business, resulting in sub-optimization of the IT organization as a whole.  By leveraging BPM within the IT organization itself, opportunities to truly reduce operational costs, improve quality and capabilities, and increase capacity, will surface.  This is something organizations that have already leveraged BPM external to IT operations have already experienced.  As a result, not only is operational IT process documentation maintained and kept current – but is aligned with the business and actually drives the process orchestration technology.  This then results in a measureable means of optimizing IT.

---

[1] Source: Gartner Research: Magic Quadrant for Business Process Management Suites, ID:G00164485 Date:18 Feb 2009

[2] Source: Justifying BPM Projects, Gartner Group 2004