I often refer to the analogy between DBMS and BPMS:

1. Once upon a time computer programs consisted from algorithms only.
2. Then at some moment it became clear that algorithms and data are different entities. Professor Wirth wrote his famous book “Algorithms and Data Structures” and a conclusion was finally made that data need special tools. So a new class of software emerged called DBMS.
3. Similarly there is now an understanding that it’s better to consider process as an independent entity and not to reduce it to algorithms or data. Hence it requires special tools, i.e. BPMS.

Now let’s recall how user interfaces to databases progressed:

1. Initially each DBMS came with its own toolset. For example, Informix 4GL for Informix database and Oracle Forms for Oracle DBMS.
2. Then universal tools able to work with different databases appeared. For example, Unify released Accell 4GL in 80’s that was pretty similar to Informix 4GL and Oracle Forms with the key difference that it could work with Unify’s own database as well as with all leading DBMS of that time: Informix, Oracle, Sybase. At that moment it was achieved simply by embedding support for evry DBMS into the product. The benefit of such tools for the client: he could switch to another DBMS painlessly. And this is not an abstraction: for example Sberbank (the largest financial institution in the country) managed to switch from Unify database to Oracle and keep millions of lines of code written in Accell. Even if Sberbank made a bet on Oracle from the beginning it would be in a serious trouble because, unlike Unify who continues releasing new Accell versions, Oracle cancelled Forms. (Let me remind that we are talking about the application system counting millions lines of code.)
3. At the end of the day a tool vendor appeared who was powerful enough to make DBMS vendors standardize on API: it was Microsoft with ODBC. Then JDBC followed the way. Yet DBMS vendors wasn’t quite happy so they do everything to make their proprietary interfaces run faster or give access to some non-standard extensions. Hence it’s not uncommon to see a tool supporting, say, Oracle and MS-SQL via proprietary interfaces and all others via ODBC.

Although Microsoft Studio and Oracle JDeveloper are quite popular, many applications developed for Microsoft and Oracle databases utilize tools like Delphi, PHP and God knows what else. So majority of application developers prefer option 3.

Now how things are going regarding BPMS? We are now at step 1 and that’s no good.

Customers choos BPMS by the engine charcteristics mostly. As a result, one have to utilize whatever interface tools the vendor provided. It may have ugly look-and-feel, poor usability and/or non-standard programming language - you have no choice. Well in theory one can use a general-purpose tool and communicate with BPMS through its API. But it’s too expensive and most importantly - time-consuming. Agility is the king in BPM projects so they require rapid development tool with ready-built visual components e.g. to access  process attributes.

I’d like to have a third-party user interface development tool supporting a range of leading BPMS. Preferably from the vendor with a proven record in producing development tools.

It’s enough for the beginning to follow the option 2, i.e. to use adapters to particular systems. If the product was successful, the vendor would be able to offer a standard API for BPMS engine similar to ODBC and increase his market share.

The product should offer the following functionality:

• Introspection, e.g. a list of attributes of the target process to choose from.
• Two modes: rapid prototyping and production development. The former is for analysts - it’s enough to specify a list of attributes and set the read-only / editable / mandatory flag for each and the form will be automatically generated. The latter is for programmers: visual components are placed on the canvas and programmer is able to write code for input validation, background calls to the engine etc.
• Same two modes for the portal. A standard out of the box portal for the prototyping and a portal composed by the programmer from the high-level components for the production (see “Demo vs. Production BPM-based Systems“).
• Two types of clients: a browser and a smartphone. I’d love to have a development environment producing forms that execute both in a desktop browser and iPhone. Ideally it’d be the same form. As a minimum, let the forms be different but have similar look-and-feel and development environment.
• Support of routine database and webservice jobs.

Would you use such a tool? Or there is one already? Or are you going to / already work on something similar?

Janelle Hill from Gartner asked: “Do You Understand the Difference Between Workflow and BPM?“. I enjoyed the comment saying that her answer “makes it easy to show that BPM is not just workflow on steriods as some call it.”

According to Gartner, the ideal BPMS implements 10 technologies of which workflow is only one:

1. Process Execution and State Management Engine - a component that implements workflow.
2. Model-Driven Development Environment. But workflow products usually has a graphical modeling tool too. Limited (usually only the orchestration without choreography), not following standards (BPMN), but it’s there. Hence the score should be 2/10 instead of 1/10.
3. Document and Content Management. In my opinion, there are structured data, unstructured content and processes. For each of them we have, respectively, DBMS, ECM and BPMS. It’s better to respect the borders: neither manage content via BPMS nor manage processes via ECM. After all we do not include Data Management into BPMS because DBMS is perfect fit for this task, so why the content should be different? 2/9.
4. User and Group Collaboration. Yes indeed, but again - why considering this as part of the BPMS? Do we only collaborate within the process context? Of course not - there are projects for example. It’s absurd to have separate collaboration environments for processes and projects. 2/8.
5. System Connectivity. BPMS treats the work done by people, document processing activities and actions performed by automated systems consistently, without bias towards the first (human workflow) or second (docflow). I’d place items 3 and 4 above here too as integration with content management and collaboration tools.
6. Business Events, BI and BAM. Strictly speaking, only BAM is tightly coupled with BPMS, the other two can be used independently.
7. Inline and Offline Simulation and Optimization. I guess only Gartner knows what “inline and offline” means here but it’s OK.
8. Business Rules Engine. In theory it can be used as a global variables repository by any (preferably by each) corporate application. But in practice it’s mainly used by BPMS.
9. System Management and Administration. Well any system has one form of it or another: 3/8.
10. Process Component Registry/Repository. There is some kind of process repository in a typical workflow system, too. On the other hand it’s probably not the best idea to have a process repository within BPMS separated from SOA services repository. 4/8.

The final score I got is 4:8 rather than 1:10. But the scoring idea is silly indeed: there is something more than just technology at BPM side. Before comparing BPMS vs. Workflow one should stress that BPM != BPMS. BPM consists of:

1. Methodology: hierarchy of organization’s goals, value chain, cross-functional business processes, process discovery, cycle of continuous improvement.
2. Implementation: a program comprising a series of projects, agile development.
3. Technology (BPMS).

Without the competence in methodology or implementation a BPM project is doomed even with the best BPMS.

You just won’t figure out how to use it right. BPM is integral and holistic discipline where three parts above perfectly fit to each other. For example:

• There is no efficient process discovery (methodology) without rapid prototyping (technology).
• There is no continuous improvement (methodology) without agile development (implementation).
• There is no agile development (implementation) without process notation acceptable by business analysts (technology).

Unfortunately most of those who doesn’t see the difference between BPM and workflow believe “methodology” is a dirty word. The arguments above won’t impress them because they only believe in the technology of their own:

• Continuous improvement? Nonsense, we must design carefully and most importantly - specify requirements thoroughly!
• The graphical process diagram? The true program is made of the code, not by arrows and boxes.
• We automate whatever business says.
• Agile Development? Our users agree to work only with a system having full functionality.

Since workflow is nothing but technology it’s more comfortable for these kind of people than obscure, overhyped and overcomplicated (from their point of view) BPM.

Yet being limited by just technology is a weak spot of workflow. It’s typical usage is the automation of routine operations at the department level. It saves efforts and brings more order to the office but the company’s bottomline is not affected, the competitive advantage is not gained. In order to reach these targets we must deal with the value chain and end-to end processes, resolve resource conflicts around cross-functional processes, design a network of communicating processes…

So complexity doesn’t come from BPM but rather from business processes. The complexity of BPM is adequate to the complexity of business and the complexity of workflow is insufficient. Since the complexity of the control system can never be less than the complexity of the system being managed the complex task of business transformation in case of workflow is inevitably reduced to the office automation.

Getting back to technology, I would not say that BPMS wins workflow 10-to-1. But it doesn’t need to because there is another important aspect: BPMS is generally the next generation of technology. Thin client, XML and web, modern standard platforms (J2EE or .NET) and standard notations (BPMN, BPEL) instead of proprietary ones. In the rapidly changing IT world even a relatively small technology gap is fatal: when the majority of developers start treating some direction as obsolete, it quickly becomes marginal simply because nobody wants to deal with it without extra reward or pressure. Whether you like workflow systems or not, only those will survive who can switch to the mainstream: migrate to a modern platform, accept standard notation, implement the missing features from Gartner’s list, i.e. become a BPMS.

Banking and telecom were the first BPM adopters. How valuable is these pioneers’ experience for other industries?

Let’s consider a manufacturing company. Roughly speaking, it consists of a shopfloor and an office. The demand for BPM comes from the office: the customer-centric business processes, the issues of cross-functional cooperation, the interaction between people and automated systems are all here.

The shopfloor has processes, too. But these processes have specific issues, specific methods and technologies: production lines, automatic machines, process control software. There is no cross-functional issues - it’s a single function after all. There is no need for BPM here, rather industrial automation and robotics.

Now look at the bank. It has the office, too. The processes here are basically the same as at the manufacturing company’s office: interactions with clients, personnel on/off-boarding, advertising campaigns planning and execution, computers maintenance, bookkeeping etc. Therefore we may expect that BPM is applicable in pretty same way.

The bank’s ”shopfloor” is a place where accounts and transactions are stored and processed. The principal difference from the real shopfloor is that it doesn’t need people: only servers, databases, automated systems and networks. Computers instead of humans and machines, ATMs and SWIFT instead of delivery service. Unlike the real shopfloor, it’s possible to fully automate the bank’s shopfloor.

Since a single automated system can’t satisfy all needs and besides we interact with other banks’ systems, there is a need of processes at the bank shopfloor to coordinate actions performed by different computer systems. A human is either not involved at all (STP - straight-through processing) or only handles relatively rare exceptions.

No humans - no pain: the most part of the process complexity goes away with humans. Therefore the complexity of bank’s shopfloor processes is much less than the complexity of the office processes. On the other hand the shopfloor processes’ performance, reliability and scalability requirements are much higher. The process consisting of calls to three or four systems and databases, several business rules and couple of logical gateways is relatively easy to model, it doesn’t change frequently due it its simplicity but it must be processed in milliseconds and the system must handle a huge flow of such processes. This is a perfect fit for BPEL while process methodology and agile implementation are of no use. It is a pure IT project.

A telecom company has a human-less “shopfloor”, too: a client makes a phone call - the process runs from the beginning to the end - the data are stored into one or more systems of one or more (e.g. in the case of a roaming call) companies.

Historically, both the systems used to manage specific processes at banks and telecoms “shopfloors” and the systems designed for office processes are called BPMS. It pleases those vendors who have chosen a strategy to satisfy the banks’ needs first and then try to adapt the product for the rest.

So when a vendor reports on successful BPM implementation at the bank or telecom, it is often about the “shopfloor” processes really. But due to the human-less nature of these processes such experience is hardly applicable to other industries. We may call such projects “BPMS without BPM”: BPMS is involved but the other two components of BPM - a process methodology and agile implementation - are absent.

I don’t mean that all BPM implementation in banks and telecom are of this kind. For example the initial phases of “Issue a Loan to an Individual” (application processing, customer verification, decision making) is a typical office process with human activities and complicated logic, long-term yet relatively low-intensive. When the credit is approved and the contract is signed, the end-to-end process continues at the “shopfloor”: the information is stored in information systems, the SMS notification is sent to the client etc.

So better get deeper into vendors’ cases, try to figure out whether it’s BPM or just BPMS.

There is confusion in the classification of software used to manage business processes:

• Enterprise Architecture (EA) tools target the following aspects of enterprise architecture:
  1. Business architecture - business goals, organizational structure, functions, processes, roles, etc.
  2. Application Architecture - enterprise systems and interfaces
  3. Data architecture - logical and physical
  4. Technology infrastructure - hardware, software, networks
• Modeling abilities of Business Process Analysis (BPA) tools cover a subset of EA: business architecture. But in addition to modeling BPA may include specialized tools like process simulation or statistical analysis.
• Business Process Management Suite (BPMS) must include business processes modeling, execution (process engine) and monitoring/analysis. Optionally it may include simulation, business rules and much more.
• Some vendors define their product as “BPM Software”. Usually this means that the system doesn’t fit into BPMS category - for example there is no engine - but marketing wants it to be labeled with BPM.

BPMS enthusiasts (including myself) believe in the power of executable business processes, in “what you model is what you run” principle. The process engine is a must for them so they can’t live with EA tools only.

On the other hand, enterprise architects have no idea how to handle business processes apart from the organizational structure, data and applications architecture. While many BPMS allow modeling the organizational structure, roles and external systems, it is fragmented to the level of “project” - that is, a logical business process (there may be several physical processes in the project) and do not cover the entire organization. Therefore BPMS doesn’t fit architect’s needs.

Now what shall we do about it? Maybe it’s a temporary issue and BPMS will eventually grow up to EA or EA will include the BPMS functionality some day?

I’d be glad to be wrong but I won’t expect this. Let’s forget about processes for a moment and look at the data architecture. DBMS is much more mature technology compared to the BPMS yet the divide between EA and DBMS is not going to disappear. Enterprise architecture deal with databases but their internal structure is modeled by specialized tools.

Getting back to the processes: they can be modelled both in EA and BPMS. As for today BPMN may be used in both. Typical business analyst knows EA/BPA tools better so the natural way to go for him is:

1. Draw BPMN diagram within EA
2. Two possible options:
   • If BPMS directly executes BPMN, export-import via XPDL
   • If BPMS supports BPEL, translate BPMN->BPEL

For example, model in ARIS and export to WebMethods. Or model in Casewise and translate to Oracle BPEL.

This workflow is simple, logical, but… not working well. Both options work only if we consider a single pass: draw - handover - execute. Yet BPM is not a one-time process automation excercise but management of ever-changing business processes.

What does it mean in practice? Once the model is loaded into BPMS, the developer edits it to specify certain details required by the execution engine. At the same time the original process model in EA tool doesn’t remain unchanged because analyst improves it continually. (I strictly recommend a series of posts started with “Model Strategy: Preserving vs. Transforming” at Keith Swenson’s blog to anyone interested in the matter.)

Now we must either transfer the details of physical implementation back to EA and find a room in the repository for them (so-called “round-trip” problem) or merge changes made in both models (like branch merging in version control systems). In theory the problem can be solved but as a matter of fact it wasn’t for years. Shall we wait more?

I propose to accept that:

1. EA-BPMS divide exists and will remain for the foreseeable future.
2. There will be no satisfactory automatic artifacts passing between them in the foreseeable future.

So where should we draw this division? There is certain freedom because the tools overlap. It’s better indeed to minimize the volume of information transmitted.

Suggestion: let’s divide at the level of a single process -

• The value chain analysis and inter-process communication (via events and/or data) modeling is done within EA tool
• The internal process logic is modeled within BPMS

This way only the list of processes and their interfaces will be transferred from EA to BPMS. Automatic export-import is not necessary for this task, we may utilize “export-import via the printer”.

Every business analyst should obey the red line: never use EA tools to model business process internals if BPMS is present.

There is better application for BPMN capabilities of EA tools. BPMS mostly focus on modeling the internal logic of the processes (orchestration), it’s poorly suited for interprocess communication modeling (process choreography). But the orchestration alone can only solve the tasks at the “office automation” level; as soon as you target the end-to-end business processes - i.e. the processes of real value - you can’t do much without choreography. (See process anti-pattern “End-to-End Process Orchestration”.)

Interprocess communications can be modeled by EA tools using the so-called “black box BPMN diagram” - modeling technique presenting each process as a blank BPMN pool. Communications through messages is modeled by message flow, communications through the data is modeled by associations.

BPMN diagram of interprocess communication (black box diagram) produced by EA tool may look like this:

For each process of the above diagram a BPMN diagram is created in BPMS. It deals with the internal logic of the process (white box diagram):

Sorry, this entry is only available in Русский.

An example:

We can draw whatever we wish of course but as soon as we tried to make this diagram executable we’d find out that in the real world the payment doesn’t always arrive. As well as in the case of “one-way activity” antipattern, we communicate with an independent subject having a free will (the buyer) and we can’t assume that it will follow our prescriptions.

We should consider at least three outcomes in this example:

1. payment arrived
2. buyer informed about refusal to pay
3. neither payment nor refusal arrived in due time

There is a special BPMN construct exactly for such a case called “exclusive event gateway”:

The beauty of this construct is that the process executes in parallel after passing the gateway, expecting all three events simultaneously. But as soon as one event happens, the other branches stop executing automatically and immediately.

The big regret is that BPMS vendors tend to consider the event gatway as luxury. I know several systems being declared as supporting BPMN yet not supporting this construct.

This is mistake I’m afraid because alternative messages processing can’t be avoided! The only possible way to solve the task in the absence of the event gateway is parallel gateway. But here we hit the problem of stopping other routes as soon as one of possible events happens. It can only be resolved with ugly diagram constructs and/or program code. Of course the process visibility and standard compiance become lost on the way.

This antipattern is special because it comes not from process analysts but from BPMS developers. On the other hand, it’s BPMS vendors will to eliminate this antipattern - they only need to change their attitude towards the event gateway.

As long as particular BPMS does not support the exclusive event gateway, one cannot effectively utilize the message flow. The software supports orchestration but not choreography. An old good workflow to me, whether it has the BPMN label or not.

Sorry, this entry is only available in Русский.

This anitpattern is almost trivial. Yet watching how different people make the same mistake at different projects I come to conclusion that it’s quite popular

Example 1: Concluding a contract. The draft must must be signed on behalf of our company by CEO:

Please respect the boss by giving him the opportunity not to sign the contract - put the gateway immediately after “sign by the CEO” activity.

Example 2: while processing a customer’s order, an agent company places an order with a partner:

Recognize that the partner has a free will and take into account the the possibility that he will not accept our order - add the gateway to the process.

One-way modeling is OK at early stages of process discovery, it’s the so-called “happy path”. On the other hand, is there any activity with the predetermined outcome? Maybe it’s better to check the result after each and every activity?

Putting gateways everywhere will clutter the scheme. The lesson learned from this antipattern is this: as a minimum, put the checks after activities where the free will is clearly visible - for example, assigned to decision makers or organizations independent of our.

BPM conquers the new territory which is called in different ways: Dynamic Processes, Unstructured Processes, Knowledge Worker Processes, Barely Repeatable Processes, Case Management.

BPM now reached the maturity level where the management of repetitive and predictable processes has become a matter of technique. It grants reliable process execution by unreliable employees - low-paid, with low skills and low motivation. Such processes are common for state and semi-state organizations and also for businesses following an extensive path of development.

But only “very talented” individuals can believe that every process can be rigidly structured:

Leaving aside the extremes - fully structured and completely ad-hoc processes - there are two combinations: either a structured process launches the ad-hoc or vice versa.

1. “A Little Help From a Friend” pattern: a structured process launches ad-hoc subprocess. An example: system integrator’s “request-to-order” process. Let’s assume that sales rep’s meeting with a client was positive meaning that he found  ”pain points” - issues that the client will pay for if they were resolved by the integrator. The next step of the process is finding a solution. However, the client’s problems may vary at very wide range (note that integrator’s value is exactly his ability to solve a wide range of problems) starting from the simplest need of a boxed software to complex projects. In the latter case the process will follow a trajectory unknown in advance that may involve an architect, developer, sales manager, systems engineer, vendor’s tech support etc. Traditional BPMS can only represent this unpredictable subprocess as a single task (see “Process Antipattern: One Man Show“). This is a poor-man’s solution indeed because it isn’t visible who is addressing the issue at the moment, what progress has been made and what the current timeframe is.
2. The opposite situation, the “Process Toolset” pattern: unpredictable process at the top launching well-formalized subprocesses. An example: a law firm having client’s case as the top-level process. It’s absolutely impossible to predict in what direction the case will turn next day, e.g. a new document may be submitted by the opposite party that will change radically both  the case prospects and our plan for actions. Yet many of the actions initiated within the case are standard, making it possible to formalize each as a subprocess. They are mostly preparing applications or other documents for the court. Such subprocesses is executed by a dedicated specialist - a common resource not assigned to a specific case. From business perspective it’s interesting to monitor performance not only of the case as a whole but also of subprocesses and resources usage.

Going down from the top-level business processes (company’s value chain) to the lowest level (micromanagement) we must be prepared to encounter both structured and ad-hoc process. Support for the latter in today’s BPMS is far behind but this subject is widely discussed by researchers, analysts and vendors:

• The following estimate was made at Gartner’2009 conference: as much as 60% of an organization’s processes are unstructured – and probably also unmonitored, unmanaged, unknown and unruly. These 60% are like “average temperature by the clinic” but the “invisibility” of these processes can indeed be the major issue from business standpoint.
• “Tapping into Collective Knowledge Will Drive Unstructured Process Activity” - Jim Sinur predicts that organizations acceptance of collective knowledge, industry networks and even social networks will result in fundamental changes in BPM. His another post on the same subject: “White-collar and unstructured processes go together like cheese to wine“.
• The boom of social networks pushes the idea to borrow approaches evolved there for communication within dynamic processes - see the Workshop on BPM and social software at BPM conference in Ulm. For example, when confronted with a problem, I can publish the question on the corporate social network (”a help from a friend”). It’s visible to my “friends” including the project manager and team lead. The best answer gets a bonus.
• SAP shows how Google Wave collaboration technology can be used - not for process execution but for modeling. SAP Gravity is a BPMN modeler implemented within Google Wave. Taking into account that the ability to redesign a process on the fly is essential for dynamic process execution, SAP makes progress not only in process modeling and discovery but in the the execution too.
• Oracle talked about collaborative and dynamic BPM at Oracle OpenWorld’2009. They emphasized commitment to SCA that makes possible to combine different kinds of processes with business rules, analytics, etc. That’s no surprise taking into account that they have acquired about 50 companies in two years and hence face huge integration challanges.
• HandySoft, ActionBase and other vendors claim dynamic processes support in the latest versions of their products.
• The most authoritative industry experts gather to discuss dynamic processes in general and their support in BPMN.

So we can see a number of minds attacking the problem from different directions. Well the more alternative approaches, the better final solution should be.

Yet for BPMS vendors that may be a bloody battle. There is probably more BPM vendors than the market needs and now a new front  opens for the competition: dynamic processes. It’s quite wide front if all aspects of dynamics are taken into account so I’m afraid not all vendors will be able to fight it in the current economic situation. But at the end of the day those who provided full support to dynamic processes will posess a competitive advantage clearly visible for the users.

When downloading a BPMS trial or demo, keep in mind that when it comes to production, the resulting system will differ from out-of-the-box version in many essential aspects:

1. The user portal - web application that starts processes, displays the list of tasks assigned to the user, manage activity forms for these tasks, monitors and administers processes. It will have different design in production and most likely different functionality too. If you’re lucky you will be able to customize out-of-the-box portal but be prepared to rewrite it from scratch at some point. Or to get away from a standalone BPM portal completely and wire process functionality into corporate applications. The reason: users typically do not accept BPMS suppier’s opinion that BPM should be the center of user’s universe.
2. In particular, you should eventually get rid of “start process” button. From user’s perspective, he doesn’t “start a process” but do something real e.g. accepts the incoming order or submits a request for vacation. The system must start the appropriate process transparantely.
3. Be prepared that activity forms generated by BPMS in few mouse clicks will no longer meet the functionality, usability and design requirements at some point. So it’s better to have an idea how will you eventually develop these forms in terms of tools, labor force and costs. The importance of this issue can not be overestimated: what good is that the process scheme is depicted in two days if forms development for this process then takes say two months? (I do not play down the importance of rapid prototyping of screen interfaces - it’s the must for BPM, one won’t even come close to production without it.) By the way you probably would like to use the same tools to rewrite the BPM portal.
4. Similarly you will no longer be satisfied with out-of-the-box reporting and monitoring tools at some point.
5. Demo and pilot processes typically store all data in process attributes, process variables or operands (different systems use different terminology) but only relatively insufficient and/or temporary information will be stored this way in production. Most data will go into a traditional database and only the primary key of the corresponding record will be stored within the process. Considering the process of client purchase order negotiation as an example, the information about the client and the order items are likely to be stored in a database while customer and order identifiers will remain in process attributes together with the deadline date for the call to the client. The reason to act this way is obvious: data which may be of interest after the process instance has ended must be stored so that they could be accessed independently from the process instance. This also means a separate user interface to this data independent from process screen forms. As for the process screen forms, they should access both process attributes via BPMS API and database fields via DBMS API.
6. Building on the previous item, most likely the part of the long-term information (but usually not all) already have a room at your existing enterprise applications. Accordingly, the process attributes will store only the identifiers of the appropirate business objects and process screen forms will access the data stored within the application. (The latter isn’t an absolute requirement - the total integration is often very time-consuming so partial integration may be more justified.)
7. Similarly, while a demo or pilot most likely will store related documents (usually Word or Excel files) as attachments to a process instance, you’ll have to consider something more solid for production. The reason is the same: if the document may be of interest after the process instance has ended, then it must be kept independently from the process instances and user access to it must be provided independently from the user interface to the process. However you don’t need the full-blown ECM system: because BPMS takes care about the workflow you need only documents storage functionality with basic interfaces (user’s and programming) and services (search, archiving, security).
8. Users authentication and authorization in a demo or pilot is usually done via independent LDAP directory, database or even a static list stored in the XML file. It is obvious that production system should utilize your existing user directory. But a bad surprise may be the amount of effort it requires. To start with there are usually several such directories. A typical example: an Active Directory, a separate authorization system within the legacy accounting system and a database keeping the users of remote offices and partner companies. As the project evolves additional requirements may arise e.g. the planned absence and automatic rerouting of the tasks. It is known that for a company having about a hundred of users Active Directory implementation alone is a non-trivial project and now we are facing more difficult task. As a result as much as 50% of total BPM project costs are spent on authorization and authentication issues at some projects. Imagine for a moment that it happened in your project and you didn’t take it into account in project schedule: you are out of schedule and budget for as much as 100%!
9. For obvious reasons not the most complex business processes are taken for demos and pilot projects. That would be all right but worse than that, they are usually technically implemented as a single process thread. But in reality even the relatively simple employee onboarding process technically consists of several processes communicating with each other (it’s enough to notice that processing the incoming resumes is not directly related to the publication of vacancies). This is even more true for end-to-end processes that are of greatest interest in terms of business (see “End-to-end Process Orchestration” antipattern and “Internal Order” pattern). Accordingly, you will need more functionality from your BPMS pretty soon - not only the orchestration but also choreography. Modern BPMS are fine with that but if a rudimentary worflow and/or document management built into your accounting system is all what you have then you may be in trouble.
10. And finally, a production system differs from a pilot by reliability, performance, security … but these are standard requirements not specific to BPM.

But don’t be scared: these issues are typically resolved one by one in incremental fasion; all companies that are successfull in BPM (and any vendor can provide dozens of references) did the job. It’s just better to know in advance what’s awaiting you after successful BPM pilot and to address the appropriate questions to yourself and to your supplier.