BPM and proximity detection solutions

putting proximity in your business process models

BPM engines fit at best , for some category of use cases, for the modeling (and runtime processing) of proximity detection events. When available, BPM models can be also used to identify where to inject location based services in existing processes or simply to answer the question if at all, proximity based services may be an option in a corporate landscape

BPM and proximity detection solutions

Identify proximity detection within business process models

Author: Fabio Trentini, BTC Business Technology Consulting, June 2015

As we all know (we should by now) , mobile proximity detection consists in locating smartphones at pre-defined indoor (or outdoor) locations and iBeacons (used to mark each individual target location) makes this possible to a large community and companies via Bluetooth Low Energy (BLE) technology.

With a custom mobile App, it is possible to automatically react and for example activate services on a smartphone, as soon as a user mobile device comes in proximity of an iBeacon.

It is therefore necessary to keep track of where each individual iBeacon is located in order to correlate the proximity detection with a localized dedicated service and this is typically done by using an intermediate content management system.

That said, we can observe to date an interesting trend. Some countries and companies are already in a post-production phase and use daily iBeacons technology on a daily basis, and others are still in the wondering wake up phase. For companies that made the first step of running a live platform, and our project in Zurich is not an exception to the rule, it becomes clear that proximity detection, although simple from the basic concepts, requires planing, time and resources since, besides the up front user experience, underlying processes are also affected.

I will refer to our BeaconZone platform in this post although the main message has to be understood as generic and independent from the CMS involved in a proximity detection solution. BeaconZone has been designed since the beginning with Business Process Modeling (BPM) in scope since iBeacons basically delivers events, and events can be modeled and processed by current BPM modeling platforms and runtime engines.

As also described below, an effective way to approach the question of if , how, when and for which particular business process, a proximity detection may become relevant, is by analyzing existing Business Process Models, and solutions such as BeaconZone, can be used as a way to validate BPM before a solution (understand for example a final mobile App) would enter the analysis, design and implementation lifecycle.

Proximity User expectations are bound with process optimization

Our BeaconZone content management system and reference mobile App have been used , since the launch of the project in November 2014 at WiedikonValley, to set up and validate a variety of proximity detection use cases after the deployment of roughly 100 beacons servicing more than 30 different locations in Zurich.

For the pilot phase, we opted to design and put on the IOS and Android stores a „generic mobile app“, as opposed to focus on specific use cases, with the goal to serve end users and business coming from different areas and concretely test live proximity detection services under as much situations as possible.

By using a live platform in shops, restaurants, a museum, offices, a multi language audio facility for a railway line and lately an interesting use case for one evening corporate event in a club in Zurich, we had (and still have) the opportunity to identify user expectations and wishes up front, but also to finalize and enhance the backend CMS requirements in order to cope with a broad set of typical proximity detection requirements.

The „Up front“ user experience is of course important since all we aim is actually to solve „proximity oriented user expectations“ and a live platform enables to directly collect feedback based on concrete situations. As the experience shows, expectations are context based. A service activated at a specific physical location may end up in different end user reactions. What may be perceived as annoying for some users, can be considered as valuable service for others.

Another aspect in a proximity detection solution, and this will be the focus of this post, arises behind the scene where up front detected proximity events will need to be integrated and processed within a corporate specific landscape.

In our approach, we designed the BeaconZone platform to integrate within Business Process Modeling (BPM) engines by implementing a configurable mechanism allowing to map low level topology constellations with outgoing BPM events.

putting proximity in your business process models

BPM engines fit at best , for some category of use cases, for the modeling (and runtime processing) of proximity detection events. When available, BPM models can be also used to identify where to inject location based services in existing processes or simply to answer the question if at all, proximity based services may be an option in a corporate landscape. In other words, we may analyse existing models and ask ourselves if the localization of users in a building or target location may bring benefits (which , we all agree, may not be necessarily a must have for every business).

I use for the sake of explanations, and to illustrate this aspect, a very simplistic BMPN 2.0 diagram that we can adapt and run for example in combination with the BeaconZone CMS and App.
Stacks Image 4689
In the example, we assume a simplified process where a visitor entering an exhibition area, would be first manually registered at the reception desk („welcome visitor user activity“) and allocated to an advisor ( within the „validate registration task“) . If available, an advisor would take in charge the visitor and provide personalized services (represented inside the „advice visitor“).

We are not actually scoping here on detailed business process modeling techniques and therefore the sub process called „Pending visitors „ is represented only to recall that we will also need to cope with the situation where all the advisors would be fully booked. (notice that in terms of proximity detection, this will also have implications and I will shortly recall this aspect later in this post).

We are all set and we have a simple process, but still without having considered any proximity related facilities.

As stated above, CMS like BeaconZone may enable modelers to elaborate and evaluate/identify if proximity may be an option that could fit in an existing model and, more important, inject proximity events that can be directly tested on the fly.

One potential optimization, (you may have guessed which one), could be for example to consider a business proximity event directly linked with the „validate registration“ task as reported in the following adapted version of the diagram.

Stacks Image 5562
By adding the „Visitor arrival“ event (this event can be configured in the BeaconZone CMS and would be delivered by the BeaconZone mobile App), we implicitly added a proximity detection aspect in the process consisting in detecting a visitor as soon as he/she approaches the registration desk area (or in general in any area of the building, where we would physically place dedicated beacons).

In order to run and validate such models, BeaconZone, combined with BPM engines, enables to adapt process diagrams and test on site the resulting effects (and as the experience shows, the results usually opens additional questions or suggestions that ultimately drive to an optimized solution).

For corporates evaluating the possibility and feasibility of a proximity detection solution in their own landscape, this approach has the advantage of immediately enabling testing and proof of concepts before a dedicated mobile solution (understand here a customized app enabled for proximity detection) would be finalized and designed.

Business Process Modeling collateral aspect

We can let now our imagination fly at this point and adapt or extend the diagram.

We may for example optimize the overall process by assuming that visitors could be detected at one of the building entrances and thus allocate a visiting time and advisor without having the visitor to pass by the registration desk.

In a more advance version of the process, we may for example suggest visiting times and/or advisors based on a visitor profile (if available) or select and expert based on a given visitor field of interest.

Have you the impression that you could do much more better and design a more appropriate process model than the one in the example ?

if yes, you got the idea and aim of this post.

Of course we can extend and elaborate a better and more realistic model, and this is exactly one of the implication that corporates should consider. Models may need time to be optimized, and testing on the field usually brings open questions and situations that are not always apparent at the beginning.

A typical situation is driven by the fact that proximity detection is bound with random movements of users on the field. The example above for examples doesn’t consider returning visitors and in particular situations where users may pass by a location many times in a short period of time (like for example in a club).

There are models and solutions to all those aspects but it is important to be aware that putting proximity on practice is sometimes also bound with unexpected situations.

Why did we build BeaconZone ?

In order to target a BPM integration, we need more than the 20 minutes required to implement the „hello beacon“ classical tutorial out of a starter kit and the reasons have to be found in the low level processing aspects of physical iBeacons detection.

iBeacons are detected for example by a smartphone App with a frequency of roughly once per second on a user mobile device but the BPM modeler will need to focus on a single business Events (i.e. in the above example „a user arrived at the registration desk“). The BeaconZone CMS can be configured to ensure that the related generic App will delivery one single event that is relevant for the modeler.

Visitors may also enter a building from potentially more than one single entrances, and the modeler may want here also to focus on one single business event (ie. „a Visitor has entered the building“) regardless from which specific entrance

The topology on a target location, may need one or more Beacons to be strategically placed and/or fine tuned and this also is bound with configuration aspects.

The last one is a typical situation that usually is bound with changes once the process is running on the field. We may realize that it may be appropriate to enhance the model by considering the specific entrance and for example react and optimize the allocation of advisors and visitor schedules based on the specific entrance (if the building is large, maybe ensure that visitors closer to the reception desks would be processed before visitor far away).

No matter which solution we may think as more appropriate (for the specific example), the experience shows that once models are run on the field, since based also on user movements to be monitored and indoor locations, the underlying processed often need to be optimized accordingly.

In this respect, we targeted a CMS going behind the simple allocation of services and considered also topology and detection fine tuning aspects to be configurable.

Besides what BeaconZone may cover, the main message to retain, is that there are to date on the marked facilities allowing corporates to tackle proximity.

From a strategic perspective, and in particular if beacons or proximity detection are on the pipeline and scope, corporates should carefully consider among the following potential options:

  • Buy in the future a solution that will fulfill all the requirements („all in one approach“)
  • Expect a solution where beacons will be injected in the current process landscape

The second approach, as the above example had the aim to emphasize, will require a deeper analysis and review of the CMS to be chosen, and the internal business processing models to adapt.

The beauty of innovation is that it opens up new possibilities to enhance the user experience and the challenge is to start approaching and adapt processes at the right moment since timing and efforts are also part of the game, and a competitive market.

who we are
BTC Business Technology Consulting offers high level services since 1998

Large consulting expertise in Analysis, Design and Implementation at large customer site.

Fabio Trentini
Email: info@btconsulting.ch
Linkedin Xing

What we do
Consulting services and project coaching for IT-Architectures and Strategy in the Web Mobile and Business Service integration areas