Is BPM just a bunch of projects?

So far I've advocated only the single database approach and in the projects I managed, this was applied without exception. I can't imagine what would be the benefit of having more databases. Especially when you can fine tune user rights so well in ARIS.  All modelling conventions, meta-models, example models etc should be maintained in that single database as well.

One important clarification: single database might sound a bit confusing because actually you have several databases with "the same" content but in different lifecycle phases and with different modification rights (apart from user right management, locking of objects is very handy). Classical approach is to have modelling DB, review DB, release (read-only) DB and archived DBs. I personally don't see the point of having separate modelling and review DBs but it any case, even that falls under "single database approach". 

Hi Ivo,

I think there are some clear advantages of not having a single database. For example, instead of loosing time with coordinating with other teams, you can just get your work done. But I agree that in the long run there are many disadvantages. Therefore, I'm asking the community why so many people are still doing it? There must be a hidden secret here :-)

Sebastian, that is a valid reason, but as you know this will create more problems in the long run (read: after a second team joins and the content shall be merged). One solution might be to create a base setup that only covers a subset of models/objects/attributes, similar to Express. Then you can hand out this DB to a project and let them start while you educate them about the advantages of a single DB and train the users in the higher concepts and details.

One thing I noticed in my projects is, that organizations with a low maturity don't understand the method in the beginning and everything seems to be too abstract. Some of them rather give up modeling than learning the higher concepts (e.g. using variants for End-to-Ends based on definitions in the functional process hierarchy to track the changes in multiple implementation projects while maintaining a stable process branch in the functional hierarchy).

What you need is a good example with relevant content for the organization, that you don't have in the beginning of a project. This can become a catch 22 in impatient orgs who just want to use ARIS as "Visio on Steroids".

It would be great if we could gather some reference content for standard processes (e.g. "Create PO") here in the community that can be assembled and used as initial content. What about initiating a new contest?

Dear Sebastain,

Single Database Systems are easy to implement,but difficult to manage in the longer run, if we factor in the scale of implementation within multinational businesses  which are spread across 100+ countries.

In my company, we are using Master - Child - Grand Child cascading concept along with complete set of customised developed scripts for doing reconciliation during this cascade everytime we have a new release.

Master database : Is a centrally managed db, with complete process repository of released business processes.

Child Database : This belongs to each country, having variant copy of master database, so maintaining the relationshp with master database all the time.  Life gets really complicated now, as countries are allowed to customised the processes at lower level or plug in local processes. We also have to manage the cascade of newly updated / released specific set of process  groups from Master to child databases.  The demand for this cascade can vary from country to country depending up type of business priorities/ project priorities and process maturity they have achieved. Trying to implement this concept in a single database is either not possible or very difficult to manage.

Grand Child Database : There are chances where each country could have wide variations within process structure bcos of types of businesses they we involved in, resulting in the need for third cascade. This would inherit top master process attribute  + local country speficific processes and attributes  and third variant to have further variations specific to a business type.

Hope this helps.

thanks

regards

Gopal

Hi Gopal,

this is very interesting! You say, your child databases are first copies of the master database, but afterwards countries change the processes according to their needs. Are countries just allowed to create variants of existing processes or can they completely restructure the processes (for example having new sub-processes, etc.)?

What happens when a change is done in master database?

I am aware of at least one scenario where I wished that there were multiple databases instead of just one - for not a technical but governance reason; a stakeholder influence threatened the entire governance bit. As Roland said above the BPM maturity is the key.

Cheers,

Sebastian

Interesing article. We have a number of different databases and this is going to cause a number of different headaches when the projects have run their course. Initially the reason was the sensitivity of the work being done by the projects and the lack of a good access management function within the tool was the reason the separate databases were set up. This led to two sets of conventions with large differences the main one being how the model was created one being left to right in swimlanes and using groups to contain leveling whilst the other goes top to bottom and the levels are maintained in the numbering in the title. This is going to be fun when the models need to be consolidated into one set of diagrams. Not! So one databse gives better goverance control but if a number of databases are to be used then it is essential that there is a team set up who control it well.

Hi Sebastian,

It is interesting that you see this as an ARIS problem (i.e. 2 dbs or more), and not a user problem. Our users don't care about how many DBs, or the structure, or the approach taken within ARIS, in fact, when we raise such concerns they just say "thats your problem to fix, it's your tool". We are trying to run a single DB solution, but the challenges we have had so far are:

• "I only want to see my processes, not everyone elses"
• "I don't care if my processes share content, if it's on my process I can change it when I want"
• "I don't want other people seeing my processes"

Echoing what most of the others on this forum are saying, "the business" simply want a version of visio that makes their life easier, maybe with a few extra features,

We already have the project problem you discuss - a major new project is starting, led by an external company, using contractors and internal staff, and they want to reuse existing processes to either recreate a version of it for their project, change the exsiting process by producing a "to-be" version  for replacing the current later, and creating brand new processes. In practical terms we can't let them do this in the master DB as they have neither the ARIS experience or BPM mind-set, so we have to give them a project DB. Our current headache is how to merge the changed, rewritten, and new content back into the master at some later date, bearing in mind the original has probably changed anyway while the project has been in flight.

So to answer your original question, I think it is more to do with the ability of the ARIS team to ensure the tool meets the business needs. If they accept the single DB approach then great, but my experience is that you need mature ARIS users for this to work, but multiple DBs for projects are easier to launch, easier to manage, easier to train users for, but difficult to merge back into a master.

As a final note, it is my experience that the benefits users of this forum see in a tool like ARIS (i.e. end-to-end process centric views) are oftern not those required or desired by "the business", who only want to see "their stuff", which makes a lot of this discussion academic. If you don't support the business needs, you have already failed.

Hi Peter,

thank you for bringing in a completely different view on the topic. In fact, your arguments completely contrast what Roland and Ivo said before. Still, I think your points are very valid. However, I fear that nobody has really solved the challenge of providing a tool as easy to use as Visio while still having an enterprise use-case and not just drawing some simple pictures.

I think, we basically have 2 approaches to the problem:

1. Work with a single database, but make sure that people can work as independent of each other as possible. This approach is almost impossible to implement as all objects in the database are interconnected (e.g. the same function is used in a process model and and function tree model).
2. Work with multiple databases, but merge them together as soon as projects complete their work. This approach is also challenging, because people might have to deal with co-evolution of databases and merging might get impossible, too.

Have I missed a third approach?

Hi Sebastian,

I'm newby to ARIS about to undergo the training, but I've been doing some reading and I'm interested by the question, so here goes...

In order to avoid the 2 approaches, it seems that you have some centralized body which produces the process hierarchy for the whole organization to ensure consistency of use of objects.  Is that the recommended way to develop the business model in ARIS?  That would avoid the issues when you have bottom-up type developments as you've mentioned.  

But is this style of working actually practical? It might take years for a larger organizations to model their processes by which time they could be out of date.  

I liked Peter's post too. I suppose businesses like to kid themselves that by buying ARIS they don't work in silos :-)

Hi Anthony,

I think in a multi-national corporations, it will be impossible to establish such a centralized body taking care of the modelling. Also, sub-organisations won't accept what this body comes up with. In my personal view, if you approach it like that you will run into many political issues, e.g. a country manager not willing to be told how to operate his local business.

Hello All,

First thing which has to be considered is an operational model of the organization. Approach for EA management has to follow this operational model. Based on this you can start thinking about content and modeling governance.

Josef