common patterns when running multiple projects with a BPMS

[Alessio Dragoni]

Hello BPMers,

I'm interested to identify the common patterns when a BPM is used
in more than one project within an organization.

If you have knowledge or experience of similar scenarios please share your thoughts
and if possible remain product independent when answering the questions

1. when a separate installation of a BPMS should be preferred to run a new project
   
2. when two or more projects should use the same BPMS installation
3. how typically an organization proceed from a first implementation to the second
   I'm interested to know if the second initiative is often a completely a new processes or if in some way
   is related to the first
   
4. which is the best way to unify the tasklist, dashboards and reports when multiple BPMS setups are in place
5. what typically is reusable amongst multiple BPMS setups and processes/projects.
6. how much is in percentage the typical re-usability between the first project and the followings
7. list of the 15 most implemented processes you know within the same organization

Thanks,
Alessio

[Sandy Kemsley]

Alessio, I'm interested in this as well. I see a variety of different
configurations, but here's some of what I've seen used successfully. I
work mostly with large financial services and insurance customers, I'm
sure experiences in other industries may vary.

1. and 2. Although in the past, companies tended to implement
individual departmental systems for each project, the trend now seems
to be moving towards a single large installation. This makes
maintenance easier in some ways (only one system to install,
administer and upgrade) and more complex in others (you have to test
all custom applications overlaid on that server for compatibility with
the new version before upgrading). The licensing is also easier, and
often cheaper. If you're running cross-project processes or really see
the BPMS as part of your infrastructure, then it makes more sense to
use a single system so that there's no design decisions about bridging
systems or on which system a particular process belongs. There are
likely still reasons to consider a separate installation, such as
separate divisions of your enterprise that rarely, if ever, share
processes, or if there is an excessive amount of customization that is
specific to a BPMS version and you don't want to have to synchronize
the upgrades between projects.

3. In moving to new implementations, reusability is the key if you
want to get the return on what you've spent on the system. If there
have been web services developed for the new implementation, consider
how they can be reused or extended for use in the new implementation:
at this point, you should be considering the needs of a few other
future projects for those services as well. I don't recommend trying
to do everything for every future project in your first round of web
services (if they are being created specifically for your BPMS
project), but go back and revisit them on the subsequent projects.
Also look at reusability of subprocesses created for the first
implementation: not only may these subprocesses be directly reusable,
but they may indicate some business process improvement that you can
do by combining similar functionality between departments. Third, look
at reusability of any custom UI code that you've development, such as
forms or portals, to see if you can make use of it in the second and
subsequent implementations. In all cases, make sure that you're not
just copying a separate version of these things and modifying them for
your second implementation: much better to create a common code base
with extensions specific to each project if the functionality is
similar enough, since that reduces your custom software maintenance
efforts.

I think that your question is also about how the second implementation
is selected; this varies widely, but I usually see the second
implementation is directed at a business are that has a lot of process
pain and needs to fix it rather urgently; that means that it may or
may not be related to the first implementation. If you use an agile,
iterative implementation style (as I recommend), then your second
implementation is likely starting after the first bit of the first
implementation is up and running, but before the first implementation
is complete, which allows for greater consideration of reusable
components.

4. That depends if you want to unify them or not, and which BPMS that
you are using. Dashboards and reports are the simplest, since they
often use independent software packages that pull monitoring/analytics
data from one or more data sources; if the multiple BPMS' write their
analytics data to the same external database instance, then this
becomes pretty straightforward. If the analytics are tightly tied to
the BPMS (i.e., they are provided by the BPMS vendor and use the
transactional process database rather than an external database), then
you're more at the mercy of the BPMS product capabilities. As for
tasklists, assuming that you're using the out-of-the-box tasklist, I
believe that few vendors have a way to show a consolidated tasklist
across multiple BPMS instances -- you would have to consider a custom
tasklist or use a product that integrates well with MS-Outlook as a
tasklist manager.

5. I think that I covered most of this in the first part of the answer
to #3: web services, subprocesses (and possibly the business processes
and personnel behind them) and UI forms/portals.

6. There's way too much variability to even make a guess at this, but
I'd love to hear anyone else's experience.

7. This is going to depend on the specific industry vertical, although
as you start to move past line-of-business applications, there will be
some administrative applications in common between companies. For
example, when I work with insurance companies, the three big ones are
underwriting, policy administration and claims, which are very
specific to that industry; often they don't even bother to implement
BPM in administrative areas, since their main focus is on the LOB
applications.

Sandy Kemsley
www.column2.com

On Aug 15, 3:25 am, "Alessio Dragoni" <alessio.drag...@gmail.com>
wrote:

> Hello BPMers,
>
> I'm interested to identify the common patterns when a BPM is used
> in more than one project within an organization.
>
> If you have knowledge or experience of similar scenarios please share your
> thoughts
> and if possible remain product independent when answering the questions
>

>    1. when a separate installation of a BPMS should be preferred to run a
>    new project
>    2. when two or more projects should use the same BPMS installation
>    3. how typically an organization proceed from a first implementation to

>    the second
>    I'm interested to know if the second initiative is often a completely a
>    new processes or if in some way
>    is related to the first

>    4. which is the best way to unify the tasklist, dashboards and reports

>    when multiple BPMS setups are in place

>    5. what typically is reusable amongst multiple BPMS setups and
>    processes/projects.
>    6. how much is in percentage the typical re-usability between the first
>    project and the followings
>    7. list of the 15 most implemented processes you know within the same
>    organization
>
> Thanks,
> Alessio