Processes first or Concepts first?
Where do you start when you design an information system? Do you start by making process models of each business process the new system must support? Or do you start with the shared language of your users, insofar relevant for the new system? Either choice starts with users, so you can keep the business/users in the lead. What are the pros and cons for these approaches?
Many argue in favour of processes first. That makes a lot of sense, because users and other business stakeholders can easily relate to their own business process. After all, who better to ask than people acting in the processes being modeled? The process model reflects their consensus of how to work with the new system.
Others argue, however, that you need a shared domain language before you can even think of achieving consensus. And the language of users is specific enough to justify a conceptual analysis that can subsequently be used to create a database structure.
So which is the best approach?
Great post for discussion purposes! I always start with Vision, Shared Believes & Prerequisites for all stakeholders. With that approach I never came to the question posted :-)
Great question. Agree with Bart Coumans that you need a common language to talk about processes. Often processes form from talking about actions that need a common understanding. In that case talking about processes creates the common language. But designing an information system is not only servicing existing processes. The system should also make it possible to have new services that could require new processes. That means existing processes will have to be confronted with new concepts. In that case concepts create processes.
I would say, 'why choose'? When having conversations with business representatives and/or potential users of the system in design you probably won't specifically distinguish between processes and concepts. These people mostly don't 'think' in terms of process and concept. They just 'do things' and 'need and/or provide information'. The analyst derives processes and concepts out of these conversations. In my opinion it is not natural to focus on either first before discussing the other. So, Processes first or Concepts first? Neither of both! (p.s. in my experience, for users, talking about processes is more tangible than talking about concepts).
I like to have shared domain knowledge first. When I was talking to users of the knowledge system I was about to build, we first found common language and built the system upon that. Users understood what the system was doing. Then we designed the processes around the system, which was rather easy considering we had a common language. Also current processes were also re-evaluated and optimized. I found it to be a
I am currently working in the area of warehouse and transport management. The users I am working generally with don't think in concepts, so they won't introduce them. Recently I started with the simple concept of transport: you have stock in a warehouse, you transport it, then you have the stock relocated to another warehouse. Far too simple, but a helpful yardstick for cataloging different types of business processes otherwise you will drown a sea full of details. The business is more complex than captured in a concept. So I opt for a start with a shared domain language. Here are my two cents.