Business Intellegence

Many good articles have been written on how to succeed with BPM, particularly related to an enterprise’s first projects. They often cover project selection, tool selection, project team composition, deployment preparation and organizational change. All of these are important factors, successful BPM implementations change the way you do business. Any individual beginning with BPM would be well served by reading several of these.

In this article we will look at BPM project development from the other side and discuss factors most likely to cause failure. By enumerating some of these, we hope to help organizations avoid some of the most common mistakes. These are the issues that we have seen most often, but we are sure that other practitioners could produce different lists. As you read through this you will note that very few of the issues are technical, one of the main benefits touted by BPM vendors is that their product reduce the complexity of building custom business applications. We find that this is largely true. The organizational obstacles are much more significant; particularly while the approach is still unproven. While implementing your first project you will have some supporters, probably a larger number of skeptics who need to be convinced and a few people who oppose or feel threatened by the initiative. The attitudes and actions of these people will have a significant impact on the outcome and acceptance of your early BPM projects. By avoiding these common obstacles, you can give your project much better odds of success.

The rest of this article is a top-ten list of things to avoid.

1. BPM is a new toy bought by IT without a solid business sponsor. IT is forced to search for projects to justify the expense, but the business owners aren’t convinced that they need it. If the business users were not involved in product selection, the chosen tool may not match their needs. The business units don’t have budget or resources for BPM projects. They may resist a new approach being pushed on them. In some cases, IT uses it within their organization in an effort to claim success, but the savings are unlikely justify the expense, or lead to wider adoption.

2. The business decides to implement BPM without support from IT. Note, this is the opposite of the previous item. Success requires engagement from both the business owners who will reap the benefits and IT who will implement and support the solution. BPM is never truly a standalone solution, it is a layer on top of existing applications and infrastructure. Without proper consideration from IT before selection, the tool may not fit well into existing infrastructure.
3. Selecting projects without sufficient benefit. Despite what you hear from the vendors and consultants, implementing BPM is expensive. The BPM suite, hardware to host it and implementation costs quickly add up to several hundred thousand dollars. We define success from the viewpoint of a shareholder. A process can be implemented and operate exactly as planned, but still be a failure if the ROI is negative. This is the most common failure which we have observed.
4. Over-reaching on the first project. If BPM is a new approach for your organization, it is best to start with a relatively simple project. This risks violating the previous item, but there are often high value low risk projects. Look for projects with narrow organizational impact, preferably a single department, but which have high volume or high cost of errors. These can produce significant value while avoiding many of the cross-organizational problems. A variation of this is starting several projects in parallel before completing any. The few knowledgeable resources are stretched across multiple projects, and each project makes similar mistakes without the opportunity to learn from prior activities.
5. Too many dependencies outside of the BPM project. While most BPM projects require interfaces to existing systems and infrastructure try to minimize external dependencies. Look for projects which can be implemented with existing interfaces. If possible, defer some of the integration to a second release. It will be much easier to get the budget and cooperation needed to modify existing systems after you have proven the value of BPM. If your organization has a mature SOA architecture, leverage that for all of your external interfaces. This will simplify your development task, and win key allies.
6. Poorly defined measures of success. Before starting any process improvement initiative, it is essential to measure the current performance, and the expected benefits. At the end of the project, management will expect a proper accounting of costs and benefits to determine whether to continue with additional BPM projects. Reduced cost is often the most obvious benefit, but also consider expanded business opportunities, better ability to respond to change and other improvements. Expanding revenue is often more beneficial than reducing costs.
7. Lack of high level, high visibility measures/reports. Too often, BPM developments do not include reports/dashboards/measures that can easily speak to senior management and decisions makers. These items are usually simple reports or charts and can include individual user/team performance metrics, statistics of use per product/product line, overall completion time of processes, etc... Taking the time to define these key metrics before starting the BPM implementation and designing the processes around the collection of these metrics is crucial in proving the added value and ROI of BPM.
8. Absence of an executive sponsor. We have suggested keeping the scope of the early projects narrow both organizationally and in terms of IT impact, but it is inevitable that any BPM project will require resources outside of the core project team. These will include IT resources as well as business experts to define the correct processes. An executive sponsor at a sufficiently high level to ensure timely availability of these resources is critical.
9. Underinvestment in training. BPM is a fundamentally different style of application development than traditional approaches. In particular it brings Business Analysts and other less technical people deep into the development process. Many companies skimp by training just a few core resources and expecting them to train the rest. But these resources are just developing their first BPM solution and do not have the expertise necessary to effectively train others.
10. Absence of proper in-house resources to develop and maintain the BPM software and applications. Contracting out the implementation of the first BPM projects is usually the fastest and more reliable way to start using BPM. However, without in-house resources that actively participate in this process and take ownership of BPM from both the functional and IT standpoints, the project may experience issues that are not properly and timely handled; resulting in undermining the end users confidence/buyout into the application and destroying the reliability/reputation of the project

For as long as businesses have used computers, there has been a continual tension between the business end users and the IT application providers. End users are rarely satisfied that the available applications fully meet their needs. If they contract for custom development, it is often no better. By the time a custom application is deployed, the business has evolved and the new application is less than satisfactory. The major cause of this is the understanding gap between business users and IT developers. Neither fully understands the other’s domain. Users don’t completely understand technology capabilities and constraints, resulting in sub-optimal requirements and specifications and developers don’t completely understand the business.

Many business users have felt that the solution to this was to eliminate the IT dependency and develop applications themselves. Of course few business people have the skills or time to develop a modern application, but there have been a few breakthrough computing platforms which allowed ordinary business people to develop their own tools, without IT support. This gave them the freedom to implement exactly what they wanted and to modify at will as circumstances changed. In this article, we consider whether BPM tools can provide another step in satisfying this desire.

The first breakthrough in end user programming was Visicalc, the original spreadsheet. More than any other category of application, spreadsheets made the PC an indispensable business tool. Today nearly all businesses have spreadsheets which they use to model and manage their businesses. Most could not imagine life without them. For the first time, ordinary business people could create exactly the tools they needed. The next breakthrough was 4GL database tools such as PowerBuilder. These allowed non-programmers to access corporate databases and create quality user interfaces and reports. They could quickly develop and deploy new applications to meet new demands. They represented a big step up from spreadsheets, since they provided access to the assets in existing databases. Of course, these required a little cooperation from IT for database access, but functionality and schedule were completely in the end user’s control. Unfortunately nearly 20 years have passed with no significant additional progress. If anything the barriers have been raised by the internet and the expectation for browser based access from any location. The PC is no longer a suitable platform for hosting most business applications.

Business Process Management Suites have evolved as a powerful platform for enterprise change. One of the primary advantages of BPM platforms over other forms of application development is the very high level of abstraction. BPM systems model the solution directly in terms of the business activities, not programming constructs. This allows non-technical business people to understand, and even develop process solutions.

There are several necessary requirements which a platform must satisfy to be viable for end-user programming. Perhaps the most important is that it must work directly with concepts from the business domain, and hide computer implementation details. Business users will not invest the time required to master low-level programming constructs. Spreadsheets were immediately accepted because users were accustomed to using paper based tabular calculations. Visicalc made those activities both more powerful and productive. The 4GL development tools used graphical layout and declarative definitions to allow construction of rich user interfaces without knowledge of the underlying event model and graphics sub-systems. Users defined the result, rather than the process for achieving the result.

A second requirement is that it be sufficiently expressive. It should include in a single package, tools for all of the required components of a complete application. Traditional programming tools are general purpose, and able to solve problems from many different domains, but their richness creates a large barrier to learning them. On the other extreme, tools with too little functionality fail to solve many important problems and become applications rather than development platforms. A platform for end-user programming should be targeted at a specific class of problems. Domain specific tools can achieve sufficient expressiveness while remaining accessible to non-experts.

A third requirement is that it be able to be developed, deployed and managed with little or no IT support. Most IT departments are reluctant to take support responsibility for applications developed by people that they consider to be amateurs. IT may help install Excell, but they are not expected to debug the business formulas. Finally, it must be cost effective. It is not possible to justify a million dollar enterprise platform for personal productivity.

Modern BPM suites can score well on all of the above criteria. The primary programming element is the process. This is a graphical representation of the flow of activities and information through an organization. It is represented directly in business terms, and typically configured by filling in a few properties in a dialog box. The user does not realize that they are actually programming. Supporting elements such as users, groups and documents also directly correspond to real world artifacts that business people use to describe their work. They also score well on expressiveness. They have evolved over many years and the current generation of systems include a sufficient set of standard activities to support a wide range of applications. The support and cost issues will be addressed shortly, but more context is required.

BPM platforms have been primarily designed to support enterprise wide, mission-critical applications. Clearly these are not candidates for end-user development. However, one of the central tenets of the BPM community is that everything that a business does should be thought of, and if possible implemented, as an explicit process. For an organization to fully achieve a process-centric culture, process modeling tools must be available for any legitimate business purpose, not just strategic initiatives.

Just as it is not appropriate for end users to develop enterprise solutions, it is often not cost effective for IT to develop departmental level solutions. One of the most common failure modes of BPM solutions is the negative ROI that results from applying enterprise level tools and development methodologies to small local problems. In most organizations, these problems are never addressed. Individually, the value of each solution is too small to justify automation, but collectively they present huge opportunities for improvement.

There appear to be several characteristics which make a problem a candidate for a user developed BPM solution. First, it must be a human-centric problem. Solutions which require system integrations require professional developers. SOA tools have made integration much easier, but it still remains in the domain of professional programmers. Second, the organizational and geographical scope should be limited. The ideal case is that all actors are in a single department at a single location. Although all current BPM systems have web based interfaces, deployment across multiple locations will require involvement of the network and security experts. In most organizations, it would not be allowed for any application not owned by IT. A third desirable characteristic is that it not be expected to be the system of record for any regulated data. It is good to automate a current manual document approval process, but the result should still be maintained in the same repository as with the current manual process. Finally, there should always be the possibility of reverting to the previous procedures if the system fails or is not available. It is not acceptable to put the enterprise at risk based on an end-user built solution.

Having narrowed the problem scope, it is now appropriate to revisit the key platform obstacles, support and cost. Process applications, are by definition, multi-user solutions. The activities within a process need to flow from one participant to the next. This suggests that some type of server based solution with a web interface is necessary. The typical BPM suite is a multi-tier application with a database, a BPM server and a web server. For enterprise solutions, they are typically deployed on different servers. None of these are things that a typical business user can or wants to support. Because of the operational complexity, many BPM platforms are clearly not appropriate for small scale projects.

A better alternative is a SaaS solution such as Appian Anywhere. With this model, the platform support is outsourced to professionals, without involving corporate IT. Support and availability will match traditional IT supported applications. This completely mitigates the third and fourth constraints listed above. With a SAAS model, there is no up-front cost, and the monthly fee can be much lower than the cost of owning a system. As more solutions are deployed and more users added, it can scale seamlessly and at a cost directly proportional to the benefits.

In this article, we have explored the possibility of using BPM suites for development of local solutions by end users without IT involvement. We have demonstrated that at least in some cases it can be both technically and economically feasible. In a follow-up article we will consider whether or not it should be done.

About the Author
Glenn Smith is a Principal Consultant with Appian. He has more than 20 years of software development experience including more than 10 years implementing enterprise BPM solutions. He can be contacted at glenn.smith-at-appian.com