Frank's Blog

Business Models in the Internet of Things 

As you might have seen, I'm involved in the shift from Business Process Management to the Internet of Things and Services (IoTS) in the recent years. While the IoTS has many interesting aspects to investigate, one of particular concern is the creation of new business models. In particular, we are interested in investigating whether business models in the IoTS have special characteristics.

A student of mine, Stephan Degen, investigated this particular question and came up with interesting results as well as a guideline for an innovation workshop in the area of the Internet of Things:

"The Internet of Things (IoT) has begun to attract a great deal of attention, not only in the world of information technology, but in other industries as well. In the Internet of Things any physical object can be part of the Internet. The physical world merges with the digital world. The vision of the connection of everyday objects with the Internet is almost unlimited as far as technical and economic opportunities for businesses are concerned. Due to the technological advances in recent years, this vision is technically feasible, but still only exists in a limited number of ways for customers. One reason for this may be the large number of possibilities.

In order to offer more for consumers and increase the value to the Internet of Things, new business models need to be developed. Business models help to illustrate, how a company can create value for themselves and the customer. Furthermore, companies can differentiate themselves among competitors by developing new business models.

Therefore, this thesis presents a method for creating business models for the Internet of Things. The aim of the method is to develop a business model, based on an idea, which considers the specificities of the Internet of Things. Consequently, the essential part of this thesis is the presentation of an approach for the illustration of business models in the Internet of Things, the presentation of a procedural model for creating business models in the Internet of Things and the presentation of a concept for the realization of this procedural model within a workshop. These key points are based on the development of specificities of business models in the Internet of Things and the comparison of existing approaches for mapping business models."

--- Abstract from the thesis by Stephan Degen

I highly recommend taking a look at this very interesting and readable thesis. You can download the full thesis here (German only).

Finally, I would like to thank Bosch Software Innovations for funding the research!

[ view entry ] ( 1447 views ) permalink $star_image$star_image$star_image$star_image$star_image ( 3 / 1465 )
EDOC 2014 Paper - Production Case Management 

For all of you interested in the next evolution of BPM/Case Management, we now have an accepted full paper at the EDOC conference taking place later this year in Ulm (http://www.edoc2014.org).



The paper revisites and enhances the ideas presented in one of my most viewed blog entries on Production Case Management (PCM).

While the ideas of PCM can be easily explained in a live demo with a running prototype, writing a scientific paper about a new kind of idea is a different beast. Actually, we (Jan who wrote the Master thesis and I) submitted a first version for the BPM 2013 conference but got rejected.

The feedback of the reviewers made me rethink the ideas and presentation, moving away from the informal style that we originally thought was best to introduce something new. I also introduced the topic to some smart researchers of the Business Process Technology Group of the Hasso-Plattner-Institute, who really adopted the ideas and worked together on the next version.

As we needed to learn the hard way, however, also our "professional" supported try to publish the paper at this years CAiSE conference failed.

We once again took the feedback of the reviewers and rewrote the paper another time, creating the final version that got accepted after three tries tackling the topic of PCM from different angles.

We also have a lot of follow-up ideas---stay tuned!
[ view entry ] ( 1853 views ) permalink related link $star_image$star_image$star_image$star_image$star_image ( 3 / 1562 )
Impressions from Beijing 

While I was at the BPM conference in Beijing, China, I had the chance to do some sightseeing.


At our first evening we found Houhai Bar Street, the most obvious Tourist Trap in Beiijing.


A view from the subway station Wudaokou nearby the conference hotel.


A view of the Tiananmen Square---with rigorous security checks (passport required & x-ray for your bags).


Inside the Forbidden City.


A view from the Jingshan Park's Temple over the Forbidden City.


Wangfujing Street---One of Beijing most famous shopping streets.


Somewhere on the way to the Temple of Heaven (Zhushikou Street).


The Temple of Heaven (in the background) with the Long Corridor.


The conference's Social Event within the Summer Palace.


A three-level street crossing somewhere near Guomao.


World Trade Center Tower 3---Beijings tallest building.


Yep, you can also find something like this...


And finally, Beijing has a quite tremendous spaceairport; this is just half of the entrance area of Terminal 3.
[ view entry ] ( 4432 views ) permalink $star_image$star_image$star_image$star_image$star_image ( 3 / 2037 )
BPM 2013 - Agile BPM Methodology 



Today I'm blogging directly from the International Conference on Business Process Management 2013, taking place in Beijing, China. While not really anything on the net works as expected, at least my blog does :-)

Since I'm not sure what I'm allowed to write about from this conference (no, hopefully just kidding), I'll simply focus on promoting our conference paper that Christian Thiemich and I wrote about An Agile BPM Methodology.

The paper is a really nice summary of Christian's Master Thesis updated with recent results. Best of all, it's written in English, so anyone who is interested in an agile BPM methodology can finally take a closer look.

Edit (Sep 01, 2013): You can find the corresponding presentation here.
[ view entry ] ( 3939 views ) permalink $star_image$star_image$star_image$star_image$star_image ( 3 / 1984 )
Production Case Management 

Motivation


During the last decade, Business Process Management (BPM) has gained lasting acceptance as a discipline for modeling, executing, and monitoring business processes. Especially in the area of structured and repeated work, a high level of standardization and automation can lead to high gains in profits. Nowadays, however, BPM is often extended to areas of (partly) unstructured work. Our experience shows that—depending on the type of company—around 50-70 per cent of all processes are not well structured and cannot easily be modeled in standard notations as BPMN. Nevertheless, since in many companies these processes also represent mission-critical core processes, there is a high interest in gaining the BPM advantages as done for structured workflows.

Traditionally, the area of unstructured work is investigated in the field of Case Management. Case Management can be split into two different kinds: Adaptive Case Management (ACM) and Production Case Management (PCM), see Keith Svenson's blog. ACM focuses on unstructured work, where the activities are tied together at runtime via a central case document. Production Case Management, in contrast, focuses on pre-defined processes that typically only represent so-called ”happy paths”. While the former one has been investigated in depth during the last years, the latter one is not yet well investigated. Based on strong demands from our customers, we developed a certain kind of Production Case Management.

The idea is based on our experience that the business departments of companies have difficulties modeling processes that are not strongly structured. This is especially difficult, as the industry-standard BPMN 2.0 does not support the modeling of Case Management besides very basic concepts like the Ad-Hoc Sub Process. What can easily be captured by business departments, however, are so called ”happy paths” or 80 per cent process diagrams. These diagrams can also be easily represented in BPMN 2.0.

A student of mine, Jan Oehlert, investigated the idea of providing a framework that is able to combine a set of these ”happy path” diagrams and merge them together to provide a superset of the state transitions that are contained within the single diagrams. This raises several research questions, such as analyzing the ”merged” process diagrams for correctness, so that they can be executed correctly. It raises the question of how to integrate documents (data models) into the process diagrams. It raises the question of how to integrate additional state transitions that should explicitly not be modeled in a process diagram. It also raises questions about best-practices how BPMN 2.0 can be employed to model the set of diagrams and data models required.

Example


We would like to motivate our research with a simple example. Production Case Management is best applied on businesses with semi-structured business processes that are difficult to capture in a single diagram. The approach is most fitting, when there exist many variants with many instances of the business processes. One example are the back-office processes of large travel agencies that handle complaints from agencies and customers. Another, more simplified example, is a classical sales process.



As shown in the figure above, a ”happy path” sales process is made up of only two sequential activities, ”Create Offer” and ”Approve” offer executed by different roles. Attached to the process is a business (data) object that runs through different states. Since it is convenient for many business people to describe such a happy path diagram, it could easily be captured and agreed upon. Nevertheless, in most case already a huge amount of instances (cases) is handled by this simple business process diagram.

The first part of a process that needs to be defined in order to be executed via a PCMS is the process diagram or, to stress the core idea of our framework, multiple process diagrams. This approach may sound like traditional BPM but, in contrary to it, the process diagrams in PCM do not represent strictly to be followed execution paths. Therefore the diagrams are not required to be complete or need to include every possible execution step. They aim to be what we call ”80 per cent diagrams”, showing only the most likely paths and leaving out those that are not expected to appear very often. We also present the idea of leaving out ”every time possible” activities or events and placing them into separate diagrams instead. Once all diagrams of a process are merged together, the functionality of those separately modeled activities or events will be available without expanding other diagrams. In conclusion, process diagrams in PCM act more as supporting guidelines for the knowledge worker than as restrictive execution paths. We aim to keep them simple and comprehensible.
For instance, additional paths, either extensions or variants, are then simply modeled in different diagrams belonging to the same business process.



An example is shown in the figure above. Corresponding to the BPMN 2 standard, both activities ”Create Offer” and ”Approve Offer” are re-using the activities found in the first diagram via call behavior. Please note that an additional task ”Insert Technical Details”, executed by a different role, together with an additional state of the business object has been added.

In the second step of modeling processes for PCM, we extend our process diagrams by process data. As we have learned from numerous customer projects, there is typically one central data object, containing all case-relevant data (with arbitrary complex structures). We define this data object with its attributes in a separate Business Object Diagram (BOD) and use the BPMN node ”Data Object” to represent it in the earlier or simultaneously created process diagrams. The data model uses to grow whilst the modeling of the process diagrams as the need for further attributes is discovered during this phase. The BPMN node ”Data Object” can carry a state, what we make use of to define the different states a case can be in.

Examples of data objects have already been given in the examples. We assume our data object ”Offer” to only have three attributes ”Creator”, ”Price”, and ”Approved” for highlighting the principle.

From its instantiating to its termination, a case runs through a number of different states, typically like ”new”, ”in process” and ”closed”. In order to keep our framework as flexible as possible, we do not limit the number of potential case states to a pre-defined set. We rather allow the user to self-define them by placing data object nodes in a specific state into the process diagrams and associating them with sequence flows. Whenever a certain sequence flow is followed at runtime, the case is meant to take over the state which is carried by the data object connected to this sequence flow, denoted as case state transition. Later on we will introduce the concept of initial and final states to distinguish the beginning and the ending of the business processes and the individual start and end events found in the process diagrams.



States are also used to link different process diagrams together. An example is shown in the figure above. This part of the process is available if the state of the data object is ”Approved”.

Once all process diagrams are defined and modeled soundly, a case state life cycle is created, consisting of states and state transitions. To provide even more flexibility to our framework, we also support additional state transitions that are not based on any process diagram but exist as further requirements. How those ”additional state transitions” are specified, e.g. by forms or a special type of diagram, is left to precise implementations.



For the execution of the business process consisting of multiple process di- agrams, all possible state transitions of the business object are merged into a single state-transition-graph, representing the Case State Lifecycle, shown in the figure above for the example. Solid lines represent state transitions derived from the process diagrams, whereas dotted lines represent additional state transitions not depicted in a diagram. Regarding the sales process, it should be possible to rework ”Approved” offers, as denoted by the dotted transitions.

If we teased you enough, you can get the full story in all its glory right here (Jan's Master Thesis). Sorry, German only.
[ view entry ] ( 4043 views ) permalink $star_image$star_image$star_image$star_image$star_image ( 3 / 2236 )

<<First <Back | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | Next> Last>>