Whenever one hears about BPM software (BPMS) these days, particular importance is attached to the early involvement of the business division in the development of a solution. This is understandable – who knows the processes better than the business division? Putting together solutions to the challenges in question as quickly and efficiently as possible is not only a matter of time and money, but also fundamentally a question of the acceptability of the BPMS used.
If you look at marketing statements more closely, there is something rather striking about the approach that says: “Just let the business division develop the applications independently.” “Sounds good, why not?” one might reasonably say. Perhaps a better question would be “why?” What is the motivation for this course of action and what value do providers and users of such approaches hope to gain?
The status quo
At the heart of any BPM solution are, of course, the demands of the business in question. These demands might be organisational, business-related, or technical (functional or non-functional) in nature. Business divisions are very familiar with the organisational side of things; indeed, they define most of the organisational work within a business. It is this division that has most of the expertise in organisational matters and to which a large part of the knowledge of a given business process can be attributed. Business divisions are often able to implement process modelling tools just as efficiently as an IT specialist, if not more so. Furthermore, business process modelling often incorporates additional dynamics that would be less relevant for the technical implementation, and the same is also true the other way round. For example, responsibility for modelling the documentation of a business-wide process would lie with the business division, whereas modelling the use of a specific systems interface would be something for the tech division. Each would be carried out by members of the corresponding team.
The use of information technology in general is obviously not the sole preserve of IT specialists. Business divisions are often filled with IT-savvy employees who enjoy going that extra mile to address their demands with the help of appropriate tools. Instruments that allow for user interface modelling are nothing new and have been deployed in a large variety of scenarios for many years. Most users are aware that data plays a role, thus they are more than capable of developing appropriate applications. One might cite the example of Microsoft Excel or Access. It is likely that the vast majority of business users have had experience of such applications and have some idea about their advantages and disadvantages.
Applications developed independently by the business division are by nature exclusively aimed at meeting organisational and business requirements. This approach certainly has some advantages – at first, at least. Extensive planning and, where applicable, long-winded technological discussions can be avoided. Since business requirements are often not yet understood in full detail, this approach allows for the collection of first experiences, and the requirements of the business can thus be gauged further and more accurately.
Is that it?
In the rarest of cases, however, the business processes that are to be modelled are so idiosyncratic that they do not need to be integrated into the existing IT landscape. It is unlikely that the business division has sufficient knowledge of all the technical parameters and requirements to incorporate them into the modelling process.
Business applications typically go through a process of quality control that tests both functional and non-functional requirements, such as performance and system stability. Support for the application must be assured. Last but not least, the application needs to survive testing before being launched.
BPM systems are highly demanding in terms of scalability, traceability, serviceability and security. This results in a plethora of technical questions and requirements which simply ask too much of a typical business division. Why should a business user concern himself in detail with these sorts of questions, given that solving the problems they raise frequently extends far beyond his area of influence?
Ultimately, there are many factors that determine whether a solution produced solely by the business division is workable or not. What is certain, however, is that such a solution is highly idiosyncratic or consciously limited to a small number of factors.
The challenge starts here
The real challenge is the continual integration of organisational and technical factors. If these factors have not been sufficiently taken into account from the beginning, they can start to become a significant barrier to progress. What started out as something agile and lightweight rapidly becomes tough and ponderous. If more comprehensive IT expertise is only sought at this late stage, the solution produced by the business division is likely already at the end of its life cycle and can at best serve as a prototype. Such a prototype can certainly provide some amount of value, but it is not what the user wanted.
Fear of IT specialists
For a number of reasons, business divisions are often afraid of involving IT prematurely; they would much rather take matters into their own hands. In the eyes of many business users, IT overcomplicates things unnecessarily. There are various reasons why business personnel think this way: a mix of objective facts and subjective opinions. But is it the right approach to sacrifice essential know-how just because that makes the first steps seem easier? Is there anyone who would seriously consider building as much of their house as possible with their own hands, only to call in architects and workmen when they could not progress further alone? A small number of people must have tried this approach. Watching the workmen start by tearing everything down must have been painful for them.
It is unlikely that a BPM system will ever integrate every aspect, thereby allowing the business user to create robust and integrated solutions independently. This can certainly work for a limited number of aspects, but in many cases the user wants to cover more than just a few of them.
Why make application development increasingly abstract?
Like most people, IT specialists are glad when they don’t always have to build everything from scratch. They are expected to deliver effective, high-quality solutions in a short period of time. BPM applications are not normally abstract pieces of programming; rather, they depict use cases in a concrete, professional way. Thus an IT specialist needs to have a good understanding of both worlds – both the business and the technical. If he spends so much of his time on technical issues that he has no room for anything business-related, this will be reflected accordingly in his work. Both developers and consultants appreciate the value of tools that complete repetitive tasks (even if only partially), reduce technological diversity and produce quick results. In many cases it is only these tools that allow them to perform the assignments they have been given.
Conclusion:
Without a doubt, BPM is a proven means of raising the efficiency and transparency of business processes. We urgently need to start simplifying BPM applications, both in terms of how they are developed and in terms of their functionality. This is something of which BPMS providers are increasingly aware, since long-winded design and implementation phases do not do justice to the desire for agility and speed.
Our aim needs to be to support business divisions from the outset by providing them with the necessary IT resources and, with the help of IT specialists, develop solutions quickly and efficiently.
Whilst functionality can be fairly clearly delineated in business modelling, limited functionality in application modelling can be extremely cumbersome and counter-productive when it comes to deeper integration. On the technical side of things, there are already widely accepted, fully developed standards in existence; adhering to these standards offers significantly more than proprietary, manufacturer-specific tools and approaches.
Statements that over-simplify things such as “graphic programming/modelling,” “no programming skills necessary,” or “the business division will model the application on its own” should be treated with scepticism, or, better yet, reviewed in a more complex environment.
BPMS are not only suitable for organisations with distinct IT departments; they can be used by organisations of all sizes. What really matters is that business-orientated and tech-minded staff work closely together to develop solutions. BPMS tools need to be made appropriate to the tasks and knowledge of the user/ business role in question. Tools that do neither of these things are more of a hindrance than a help and are ultimately a waste of money.
Follow
