Process Is The Main Thing

@ Anatoly Belaychuk’s BPM Blog

Demo vs. Production BPM-based Systems

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.

09/30/09 | Notes | ,    

Comments (11)

  1. Дима 09/30/09 08:10 PM

    Ох как Вы правы, на своей шкуре все пункты кроме 2,9 и 10 очень прочувствованы.

    Хочется добавить еще к пункту 5 проблемы с временем отклика системы при большом объеме данных, т.к. данные форм хранятся в БД BPMS “как пришлось”, т.е. как генератор форм придумал, или вообще в виде XMLя, без индексов и.т.д. Кстати именно эта проблема с моей точки зрения делает промышленное внедрение BPM систем без доработок невыполнимым. Интерфейс убогий терпеть можно (работают же сейчас пользователи с интерфейсами аля 90е и не гундят), а вот если форма открывается больше минуты, на 30й секунде ген директор может потянуться к телефону 8),

    Еще не написано (ну от части п.7), что полноценный BPM подразумевает под собой интеграцию систем над которыми он висит. Т.е. нужен MDM и синхронизация справочников и.т.д.

    При этом, не очень бы хотелось чтобы сейчас производители BPM дальше двигались в сторону поиска решений тех проблем, которые описаны. Честнее было бы выделить те функции, которые есть сейчас у лидеров в отдельный продукт для бизнеса и позволять бизнесу запускать процессы в эксплуатацию в том виде, в котором они его отрисуют. И не обещать, что потом не придется платить 8), это может отпугнуть. Все описанные проблемы решаются грамотным применением уже существующих инструментов. Это будет дорого, но оно того стоит. Некоторые проблемы нельзя решить без BPM, как нельзя решить проблему хранения данных без СУБД и интеграции без систем гарантированной доставки сообщений и управления распределенными транзакциями.

  2. Scott 09/30/09 08:47 PM

    Anatoly -
    Another very well-thought out posting. I’d say you should put your “don’t be scared” disclaimer at the top so that people don’t give up as they read :)

    Also, I’ll note that many companies are successful with only *some* of the changes you point out - for example, for some processes, the stock forms are good enough (usually, internal processes), for some processes the portal is “good enough”, and for some processes the data management baked into the BPM tooling is “good enough”. But, each process will stress a BPM platform in different ways, and push the boundaries on different parts of the solution. A good BPMS isn’t as good at forms design as a good forms designer… or as good at data management as a good OR mapper or the Spring framework… but BPM platforms should bring down the level of expertise required to get the basics working, and give you options to get more advanced as required by your process (or as required over time with your process). I think the magic of BPM is making all these myriad items play well together, making the whole greater than the sum of its parts - but that doesn’t mean you can’t upgrade some of the parts when you need to :)

    Great food for thought -

  3. Anatoly Belychook 09/30/09 09:09 PM


    Мне особенно импонирует последняя фраза. Абсолютно верно: к определенным проблемам без BPMS лучше даже не подступаться. Ну а то, что при этом возникают новые проблемы, так это всегда так: много знания - много печали, а с увеличением площади круга растет длина окружности :)

  4. Anatoly Belychook 09/30/09 09:20 PM

    Good advice, Scott :) But as Russian proverb says, “one beaten is worth two unbeatens”. Or rather “one warned” for this case.

    And you are absolutely right - I put “at some point” everywhere having exactly this in mind. Good BPMS lets you catch the process and deliver the value to the business amazingly fast and this creates the BPM magic: it’s the unique atmosphere of early success giving the way to even bigger success etc. In such atmosphere any issue from the post isn’t a big deal.

  5. AS 10/01/09 11:59 AM

    Bravo, Anatoly.

    This is an excellent overview of some problems originated in mixing of “BPM as software” (a.k.a. BPM suite) and “enterprise BPM system” (what is implemented within an enterprise to manage its business processes). See also —

    Sure that a modern BPM suite is necessary, but not sufficient for a good enterprise BPM system - “an aircraft carrier should never operate alone”.

    In the absence of agreed reference models and proper standards, creating good enterprise BPM systems implies serious architecting efforts. Below I comment your list from the architectural point of view.

    1. Your own enterprise “worklist” application has to be considered regardless of a BPM suite “web portal”. The users want to handle business processes in conjunction with their business objects, e.g. business cases.
    2. Business events (receiving an order) are often already available somewhere in your enterprise systems. Just associate them with your processes.
    3. Automatically generated forms are usually considered only for quick prototyping.
    4. Existing reports are usually considered only for quick prototyping.
    5. By definition, business objects as BPM artefacts have to be externalised. Dreaming to keep them within a BPM suite is wrong from the beginning.
    6. Audit trails and KPI are other BPM artefacts — put them out of a BPM suite, by definition.
    7. Documents are yet another BPM artefacts. Keep them out and do not forget about records management.
    8. Handling of roles (also a BPM artefact) is usually difficult. I recommend to create a set of groups oriented to processes, e.g. process owner, activity workers, etc. and to populate these groups from available resources (processes are useful for that).
    9. Agree - patterns and anti-patterns are necessary for constructions of complex processes (see my blog for some practical process patterns).

    I think that any discussion about the architecture of enterprise BPM systems is step from the current vendor-centric BPM to customer-centric BPM.


  6. Anatoly Belychook 10/01/09 12:19 PM

    Thank you, Alexander

    I always supported your point that BPMS-centric approach gives biased perspective and that wider architecture-centric view is essential.

    Yet this sounds somehow abstract for many of us so practical illustration won’t hurt - hence my post.

  7. David French 10/02/09 12:35 AM

    Spot-on. I have annotated your comprehensive list in my post.

  8. Алексей 10/09/09 07:24 PM

    Немного откланясь от темы.
    По каким критериям можно определить что перед нами система класса workflow не способная реализовать полностью задачи и возможности BPM?

  9. Anatoly Belychook 10/09/09 07:45 PM

    1. Проприетарные нотация и язык. (Критерий не абсолютный - в некоторых BPMS тоже можно найти своеобычные языки. Но они хоть стараются реализовывать нотации, похожие на BPMN.)
    2. Отсутствие средств межпроцессной коммуникации (запуск одним бизнес-процессом другого, посылка сигналов и сообщений между ними).
    3. Устаревшая проприетарная платформа (читай - не J2EE и не .NET), не поддерживающая современные технологии и интерфейсы (те же вебсервисы, например), как вариант - являющаяся придатком прикладной корпоративной системы.
    4. В демороликах сплошной документооборот. (Критерий неформальный, но полезный.)


  10. Алексей 10/09/09 08:58 PM

    1. Кто не BPMN тот против нас?
    3. Об интерфейсах пускай голова болит у интеграторов. Для систем сделаных с учетом особенностей текущей ИС (вышеназванных корпоративных придатков) это не самый острый вопрос.
    С остальным соглашусь.
    Но это вы описываете рудиментарную наколеночную скрепленую соплями и 200мм гвоздями для понта сделанную ..
    А если подойти с другой стороны?
    Workflow сделанная из соображения что не только програмист должен видеть и понимать логику работы, прохождения документов и.т п. Тесно-интегрированнную с местной ИС, поэтому java-net-etc-ewb-services не актуальны. Запуск процессов присутсвует, Взаимодействие процессов тоже (не во всех точках процееса правда). Демок документооборота тоже нет:) Процесс отображается графом. Присутвует хореография процессов, насколько я ее понимаю. Програмист и аналитик (он же тех директор, он же..) работают над процессом совместно (точнее аналитик висит над плечом програмитса и выдает соображения как оно должно быть).
    Так вот вы приходите в эту фирму с проектом внедрения BPM (как парадигмы управления, не конкретной системы)
    Варианты действий
    1) Отрвать все от ИС, переписать на web-сервисы, внедрить что-другое, поскольку все что было показно на BPMS не тянет.
    2) С помощью местных ITишников выявляем места которых нехватает для BPM/
    Вопрос в том где проходит грань между системой управленя потоком работ и системой упрвления бизнес-процессами?
    Одну из таких граней я вижу в бизнес-аналитике который сам рулит процессами, но наверное есть и другие аспекты которых я еще не вижу.
    Что-то вопрос получился очень длинный, но очень хотелось задать правильный контекст.

  11. Anatoly Belychook 10/09/09 10:22 PM

    1. BPMN - это как SQL образца начала 90-х. Никто строго не придерживается, но все как-то пытаются соответствовать. И это правильно и хорошо.

    3. Программу, следующую принципам объектно-ориентированного программирования, в принципе можно написать и на фортране. На C++ теоретически лучше, но бывают разные ситуации. То же и здесь: при желании можно сконструировать ситуацию, в которой теоретически “плохая” workflow-система “здесь и сейчас” будет лучше самой совершенной BPMS.

    Да, вы правы, четвертым (а лучше первым) пунктом стоит добавить, что workflow - это, как правило, “автоматизация”, а BPM (и BPMS, как инструмент) - технология бизнес-трансформации. Сделали паузу, почувствовали разницу… BPM, не выходящий на уровень бизнеса, “заказчика заказчика”, цепочки создания ценности и тому подобных вещей - это не BPM. Но, опять-таки, если очень постараться, можно этих целей достичь и при помощи workflow-системы.

    Пятым пунктом можно добавить интегральную характеристику - способность быстро менять бизнес-процесс, agility. Впрочем, формализовать этот критерий еще труднее, чем остальные.

    И последнее: BPM (и SOA) - это не “оторвать и переписать”, а “сохранить и приумножить” - повысить эффективность использования уже имеющихся баз данных и корпоративных систем, подключив их к бизнес-процессам, затрагивающим на порядок больше сотрудников, чем только пользователей из бухгалтерии и финансов.

Comments are closed

Copyright © 2008-2023 Anatoly Belychook. Thanks to Wordpress and Yahoo.  Content  Comments