Business Process Modeling - Science topic

The answer to this question is not easy, because it depends on why are you modeling the processes.

BPMN provides great flexibility on the cost of complexity. The more you model, the more complex it gets and harder to comprehend. If you need a glimpse of what the administration is doing, it might do the work. However, if your goal is to simplify the operation of the organization, unify it, and make it clear for both employees and customers, then think twice.

In my experience, I've used many different tools to provide an understanding of organizations' processes and operations. I've always kept my goal clear and chose the tools accordingly. Sometimes it was BPMN, UPM, UML, or just a simple block diagram set.

ARIS

BPM Academic Initiative (BPMAI) dataset : https://zenodo.org/record/3758705#.XrZDamgzbDc

A relevant paper is listed below for your ready reference:

SOA: a new way to design the decision in SOA—based on the new standard Decision Model and Notation (DMN)

‏F Boumahdi, R Chalal, A Guendouz… - … Oriented Computing and …, 2016‏ - Springer‏

Hi.,

business processes has include: Manufacturing – an product assembly process, a quality assurance process, a corrective/preventive maintenance process. Finance – an invoicing process, a billing process, a risk management process. Health – a medical assessment, a drug approval. Banking – customer on-boarding, credit check.

different types of business processes. ... System Overview Diagram

Hello,

Thank you for your insight. Can you explain more precisely what do you mean by "BPM is applied primarily in non-creative art, restrictive, precision, and impersonal"? Benjamin Huynh

Simply check Amazon research papers and the KPMG report related to that

Thanks a lot for your answer Johannes. This sounds like an interested topic for research. It would be great if you could post here the results of your further explorations on the subject as I'd be interested in following this.

Best of luck!

Adrian.

Dear Loubna, I wuold suggest to take a look to the bpFM modelling tool (http://www.omilab.org/web/bpfm). Business Process Feature Model notation (BPFM) is an extended version of Feature Models named BPFM proposed to deal with Business Process Variability. The BPFM notation permits to model a family of business processes. Starting from a BPFM model using the tool you can generate a set of variant in BPMN. Let me know if you need more information. 

Dear Elahe,

Many different types of models are used in various scientific and engineering fields, reflecting the subject matter and the kinds of understanding that is sought in each field. Conceptual modelling techniques in software and information systems engineering have in the past focused mainly on describing and analysing behaviours and structures that are implementable in software. As software systems become ever more complex and densely intertwined with the human social environment, we need models that reflect the social characteristics of complex systems. This chapter reviews the approach taken by the i* framework, highlights its application in several areas, and outlines some open research issues.

In the philosophy of language is any language which arises I* an unpremeditated fashion as the result of the innate facilities for language possessed by the human intellect. A natural language is typical used for communication and may be spoken, signed or written.

i* (pronounced "i star") or i* framework is a modelling language suitable for an early phase of system modelling in order to understand the problem domain. i* modelling language allows to model both as-is and to-be situations. The name i* refers to the notion of distributed intentionality which underlines the framework. It is an approach originally developed for modelling and reasoning about organizational environments and their information systems composed of heterogeneous actors with different, often competing, goals that depend on each other to undertake their tasks and achieve these goals. It covers both actor-oriented and Goal modelling. i* models answer the question WHO and WHY, not what.

i* provides the possibility to achieve information in an early phase of the software engineering process. In former days UML was used to make information visible, but as UML often focuses on organisational objects, which are not so important in the early phase, when the emphasis should be on helping stakeholders gain better understanding of the various possibilities for using information systems in their organizations.

i* provides the possibility to achieve information in an early phase of the software engineering process. In former days UML was used to make information visible, but as UML often focuses on organisational objects, which are not so important in the early phase, when the emphasis should be on helping stakeholders gain better understanding of the various possibilities for using information systems in their organizations.

i* provides an early understanding of the organizational relationships in a business domain. The Use Case development from organizational modelling using i* allows requirement engineers to establish a relationship between the functional requirements of the intended system and the organizational goals previously defined in the organization modelling.

i* is used for the early requirements and UML for late requirements. Thus you have to transform the i* model into a UML model. You can do this by using the following guidelines:

There has been a proliferation of various clones of stakeholder engagement in modelling, or, rather, of the use of modelling in support of a decision-making process that involves stakeholders. In many cases the differences are quite subtle and it may seem that various agencies or groups come up with a new term to serve as a recognised trademark for their efforts. In essence they tend to be doing more or less the same things.have recently proposed literature reviews on participatory modelling: below is a brief overview of various types of stakeholder-based modelling, as well as some stakeholder processes that do not rely on modelling.

regards,

Prem Baboo

I don't know of about the business aspect, but there are a number of Excel-based models of international trade theory available at the link below.

Dear Emiliano,

I am not quite sure what is it that you want to know. BPV usually is conducted to see weather the set of processes meets the requirements. So there should be specific requirements before the design of the business processes within the organization, and then validation. On the other side, business process benchmarking (BPB), many times seen as a tool of TQM, can be very useful for verification process. Here are some articles that can help (http://www.orau.gov/pbm/pbmhandbook/articles.pdf). Hope you find it useful. 

SBVR is a landmark for the OMG, the first OMG specification to incorporate the formal use of natural language in modeling and the first to provide explicitly a model of formal logic. Based on a fusion of linguistics, logic, and computer science, and two years in preparation, SBVR provides a way to capture specifications in natural language and represent them in formal logic so they can be machine-processed.

Methodologies used in software development are typically applied only when a problem is already formulated and well described. The actual difficulty lies in the previous step, that is describing problems and expected functionalities. Stakeholders involved in software development can express their ideas using a language very close to them, but they usually are not able to formalize these concepts in a clear and unambiguous way. This implies a large effort in order to interpret and understand real meanings and concepts hidden among stakeholders' words. Special constraints on syntax or predefined linguistic structures can be used in order to overcome this problem, enabling natural language to well represent and formally define problems and requirements.

The main purpose of natural language modelling is hence to make natural language suitable for conceptual modelling. The focus is on semantic aspects and shared meanings, while syntax is thought in a perspective based on formal logic mapping.

Conceptualization and representation play fundamental roles in thinking, communicating, and modeling. For each concept there is a triad of 1) the concept in our minds, 2) the real-world things conceptualized by the concept, and 3) a representation of the concept that we can use to think and communicate about the concept and its corresponding real-world things. (Note that real-world things include both concrete things and representations of those concrete things as records and processes in operational information systems.)

A conceptual model is a formal structure representing a possible world, comprising a conceptual schema and a set of facts that instantiate the conceptual schema. The conceptual schema is a combination of concepts and facts of what is possible, necessary, permissible, and obligatory in each possible world. The set of facts instantiates the conceptual schema by assertion to describe one possible world. A rule is a fact that asserts either a logical necessity or an obligation. Obligations are not necessarily satisfied by the facts; necessities are always satisfied.

SBVR contains a vocabulary for conceptual modeling and captures expressions based on this vocabulary as formal logic structures. The SBVR vocabulary allows one to formally specify representations of concepts, definitions, instances, and rules of any knowledge domain in natural language, including tabular forms. These features make SBVR well suited for describing business domains and requirements for business processes and information systems to implement business models.

The reference below is not a direct answer to your question but can give you some ideas:

Text of the article: http://bit.ly/1ljSVX2 slides and recording of a presentation http://slidesha.re/1qEVcz1

Hope It helps

Cheers Ilia

P.S.: I guess you question "that affect the business process model." is not about business process model (as a piece of paper), but about how the process is actually run.

Giuseppe, just a thought, in my world the secret part of any information is how you got it but a "truth" is a truth and the results of the information which is the important aspect to begin with should always be available.  My rationale is that truths are universal and not owned by anyone, but processes can be owned and for various reasons are held close to the vest for some organizations.  Therefore what you want to share should be a truth statement, in my opinion.

Dear Bhawesh,

you can add an attribute to each entity (through the Attribute module). In this case you can create an attribute and assign the values 'new customer' or'old customers', or just '1' and '0'. Then when the entities are waiting in a queue, you can order the queue on the basis of the attribute value.

There is a problem of terminology here: whereas meta-models are used to translate from one language to another, stereotypes are used within a language and therefore have nothing to do with meta-models.

So you agree: whereas validation is out of reach counter examples can still be used to disprove models.

hi Shweta...i agree, but to an extent.... Workflow Management is well advanced in Developed Countries (USA etc), whilst still maturing in Developing Countries such as India, and perhaps even Africa etc....but yes, it does then allow for it to become fertile grounds for some good research ideas from a developing country perspective...

Sachin

The workflow paradigm, early adopted in the business context is also useful for modeling scientific applications on multiple science domains and allowing flexible mappings between the application abstractions and the underlying computing infrastructures namely large distributed infrastructures such as big clusters, Grids and Clouds.

However, currently, most of the existing scientific workflows tools do not offer adequate support to facilitate the development of several challenging scenarios that are becoming more important for emerging large-scale, distributed, and dynamic applications. As examples of currently open issues, existing workflow approaches still exhibit critical dependencies on a centralized enactment engine, and they lack flexibility in supporting the execution of long-running workflows with multiple iterations or even infinite iterations and allowing their structural and behavioral dynamic reconfiguration.

That is a very interesting question, which we investigate for a while! In order to create a more clear terminology, we name two paradigms: 1) activity-based and 2) artifact-based processes (explanation in short words follows).

In the activity-based paradigm (this is what you call imperative), the focus of the process is the activities (the methods) to carry out certain tasks. A process is then defined by a sequence of activities (a workflow). Artifacts, which represent any piece of produced/consumed data in a project, are the inputs and outputs of activities. Dependencies between artifacts are expressed by the combination of activities in the workflow.

In the artifact-based paradigm (this is what you call declarative), the focus is the artifacts. Artifacts have type, structure, content, responsibilities, and dependencies among each other. For every artifact, there are several methods that can be used to create the artifact, e.g., a requirements spec can be created using plain text, structured text, diagrams and models, and so forth. That is, a process is defined by a set of artifacts to be created, and a context-specific selection of appropriate methods.

What we learned so far:

- There is no absolute distinction between these paradigms; you always have a mixture.

- Activity-based processes better reflect the way of work.

- Artifact-based processes provide better means to assess project outcomes.

- Artifact-based processes are more flexible, as one can select different methods to create an artifact.

However, in an experiment, we learned that artifact-based approaches are easier to analyze, design, and implement processes (which means: this paradigm seems to better support SPI projects), while process users do not care, and prefer more detailed guidance. Experience from practice also shows that artifact-based processes are more difficult to teach, as they require a certain level of abstract thinking.

So, are declarative more intuitive? It depends. For just enacting a process in a project, the imperative process is more intuitive as it contains more guidance. If you have to analyze and design processes, then the declarative approach is more intuitive as you can talk about process artifacts, their properties, and so on. In the end, neither is simple. It always depends on the users and their intention.

You can have a look at the (Open) process handbook developed by the MIT. The handbook database can be accessed through a dedicated tool, which is freely available from the project website http://ccs.mit.edu/ophi/index.htm.

Hi Sergio,

This is a highly relevant topic. In Software Engineering (my perspective), it is, however, under-researched. Nevertheless, we have some approaches. It started with Dieter Rombach's paper on integrated software product and process lines (https://www.researchgate.net/publication/221421676_Integrated_Software_Process_and_Product_Lines), which is the basis for some research on process variability. Among other, process line approaches address organizational change and capability improvement (from the SE perspective, e.g., development, testing, and management).

Basically, we distinguish between two approaches:

1) variability analysis (of past projects/actual processes) to develop new/improved processes to better address company needs. Contributions on that topic were made, e.g., by the group around Jürgen Münch (https://www.researchgate.net/profile/Juergen_Muench). For example:

2) pro-active and directed variability. This is closer to Dieter's proposal, i.e. variability instruments are part of a process metamodel. Variability instruments are then used to derive a particular process variant from a reference process. A good overview of variability instruments can be depicted from:

A concrete implementation and empirical study on the feasibility of such constructors can be found here:

If you are interested in this topic and how it is handled from the process perspective, hurry up and attend this year's ICSSP (http://www.icsp-conferences.org/icssp2014/). There will be a special panel on that topic (the introduction of the panel can be found here: https://www.researchgate.net/publication/261798570_Towards_Context-Specific_Software_Process_Selection_Tailoring_and_Composition?ev=prf_pub).

Hope this helps a bit.

Peter, I will comment on how I understand and use the concepts

What I am about to say needs not be generally agreed :)

although it is aligned with the vision we have in project CaaS.

Capability can be understood as the combination of the ability and the capacity to achieve some goal. The ability is related to the knowhow (skill, knowledge...), and the capacity is related to the resources (people, time, money, tools...).

This already gives the relationship between both concepts.

As I understand it, the willingness comes with the fact that there is a goal. So, If we actually want to achieve the goal, we will indeed apply our abilities and use our capacities.

Of course, when used informally, the terms capacity ability and capability are often used indistinctly.

Any thoughts? other visions?

LEGO (R) is a good comparison or metaphor:

Your process models are the LEGO sets (or individual LEGO constructions), each composed of different LEGO bricks (your business services). How did LEGO decompose to maximize reuse, replaceability and flexibility? The LEGO nops are the secret. We call it the business object model for the application domain. Without the nops you need many adapters and/or glue, which reduces flexibility and reuse.

The shapes of most bricks (their interfaces) need to be regular, but additionally you need special purpose bricks for special applications. For services of course their semantics is an additional dimension, not covered by the LEGO metaphor.

It is important to have a glossary. However, in these days of agile, such artifacts are not valued by the client unfortunately.

Would this one work? http://dx.doi.org/10.1080/14783363.2013.791114

Hello Arash,

I think you are right about BPMN having a stronger focus on orchestration and choreography.

On the other hand SoaML is more detailed in the technical aspects of Services and SOAs.

Another great benefit is the independence of SoaML. While BPMN is targeting on business processes SoaML is free of any subject area. This is really fantastic when you try to model Services for domains outside of the Enterprise Software and Web Services domain. For example I was able to use it it for developing driver assistance systems. With BMPN I would have had to violate some of the semantics of the language in order to create the model I wanted to have.

I published a paper about how I used SoaML together with an adjusted version of the IBM SOMA process model. It's titled "Model-driven development of SOA-based Driver Assistance Systems" and freely available through my profile here on Research Gate.

Marco

The person who practice business. This means that this practitioner is currently in business.

My idea its to model a Business perspective and move to business processes and after that, to technological processes... In this approach I am trying to start with the vision, mission, capabilities, before going to processes areas, related to that capabilities - to have alignment and context. This initial assessment will be made with board members, using the concept of Capabilities instead of Macro Process or Process Area. Because I feel its easier to explain a Business Capability to a Board Member, than Macro Processes. Because of this, I am trying to support this decision in a more scientific way, than empirical....

Thanks for the tools suggested, I will try it! For the business layer assessment, I am using Excel and Powerpoint and I don't like it :-)

Business Processes are basically collection of activities cutting across various departments, producing a valuable output for the customers (e.g Sales Process, Procurement Process). Workflow is used to automate these repetitive activities and hence business processes. So workflow will bring automation and efficiency to the business process.

Hi Pierre-Yves! You can have very nice processes on paper that do not reflect reality. A real assessment requires interviews and study or documents, tools used, etc. To compare, could you automate the assessment of your students ?