We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.
Start a Discussion

Why Is BPM Lagging Behind Other Applications in Going Mobile?

Vote 0 Votes
Mobile BPM seems like a natural to me, so why isn't it already in widespread use across the industry.  As this ebizQ feature article states, "It is essential to understand why mobile business applications (and in-effect mobile BPM) have lagged behind enterprise applications." So why is mobile BPM lagging behind?

9 Replies

| Add a Reply
  • First we need to go back to "what do you mean by BPM".

    If BPM = automated processes
    - many of these can only be executed when in front of a PC/browser so mobile is not relevant
    - normally the entire end to end process is not mobile
    - there are exceptions (sub-sets of process) e.g. insurance accident assessment or hire car return

    So in this area a search on Google revealed a couple of BPM pure play vendors - AccPol and Appian. Perhaps they are all doing this alphabetically? And there are plenty of custom built or mobile web page driven processes.

    If BPM = non-automated processes / manual
    - there are far more activities that are mobile but need guidance or direction (ie Onlnie Operations Manual) eg tax assessment, running a conference, maintenace check of an oilfield.

    This last one may seem very specific, but it was the example Jim Boots, Senior BPM Advisor, Chevron gave when he was being interviewed by the Financial Times about the potential of Nimbus Control on the iPhone / iPad.

    For more discussion on the role of mobile (iPhone/iPad) in BPM read my blog "The iPad is missing the (business) point" http://adjix.com/yx74

  • First, I disagree with the premise that BPM is lagging behind other apps in going mobile. Yes, there are a zillion mobile apps, but there are very few business mobile apps. I do not see mainstream business applications such as ERP, CRM, EDMS going mobile as yet. So where is the BPM lag?

    Second, when I do see examples of business apps going mobile, they are usually offering a subset of their core functionalityon a mobile device, with the caveat that if the user really wants to use all the functionality he/she will have to use a traditional client such as a desktop or full screen browser. The vendor hopes to get the marketing points and buzz, without having to make the major investment needed for a truly robust mobile offering. For BPM it is hard to have a partial offering.

    Third, going mobile presents major challanges to vendors of most business applications that are document or data centric (and BPM is indeed document and data centric). These include:
    i. Small display size
    ii. Many different mobile devices
    iii. Mobile users work discontinuously and are frequently interrupted
    iv. Bandwidth is still slow on mobile devices
    v. Documents are hard to downlaod and display

    These challanges limit the growth of business applications on mobile devices and BPM is in the same boat.

    Fourth, I believe that SaaS is an essential pre-cursor to mobile enablement. Before going mobile, business software vendors should first adopt the SaaS model. BPM SaaS is still in its infancy. Once BPM goes SaaS in a major way, Mobile BPM will follow naturally.

    My new company offers a unique, patented solution for mobile enabling SaaS applications and we hope to make BPM vendors our customers in order to accelerate Mobile BPM

    Rashid Khan
    Chatty Solutions

  • Last year I banged on about touchscreen enabled BPM tools being rather cool yet completely non-existent in the BPM market right now. Having seen Ballmer and Jobs reveal Windows and Mac flavoured touchscreen devices it now heralds the question whether vendors need to take into consideration a little more seriously this technology trend. I for one would love to roam an office knocking out process models on the fly as I watch the interaction taking place using an easily portable device which supports an environment to draw on (Ok Ok, so I can do the same with a pencil and piece of paper, but it doesn't look cool, and BPM is cool !)

    Often we're forced and constrained to use paper, note pads, post-it notes to convey a process map so imagine being able to draw it up using a tablet enabled BPM tool which connects via wifi to the repository so the information is stored instantly. No more deft trackpad/ nipple weaving using a bulky laptop (let's face it, laptops in the enterprise are a far cry from a MacBook Air in size and weight !). Given the drag-and-drop nature of most process modelling tools and the intuitive feel of sliding your fingers across a tablet screen it's almost the perfect marriage without a shotgun in sight. Knock one up, show it to the business user, they can tweak it there and then, approve, job done.

    I made the prediction this year that BPM should adopt large interactive displays for process communication and workshop environments. I still see this as a reality but perhaps this is the first step in understanding how technology (note: not software) can support BPM in other ways other than mouse/ keyboard/ server combinations.

    If you extend the technical side further you can create a whole raft of mashups involving workflow integration with twitter-style updates and instruction. Stick this on an iPhone/ BB/ iPad and resources may never need to be desk bound again. We are literally on the cusp of something very very big. It will take time for enterprise adoption on a large scale but unless the roadmap is thought out in advance for the industry we're going to fall short of delivering something truly revolutionary and it'll just be labelled a fad. What I would hate to see happen is that vendors just jump on the bandwagon with iPad apps for their suites and dilutes the real value proposition.

    The social and mobile workforce has arrived.....

  • I agree with Rashid -- BPM applications are mobile (or at least ones developed with ActiveVOS are). By using a rich standards-based AJAX client (which doesn't use Flash :-)) it is easy for tasks to be handled on any mobile client that can handle looking at web pages.

    The WS-HumanTask standard even includes the ability to have multiple "renderings" for a task, so that small devices can have a different representation of a task than what would be used on a full-sized screen.

  • Sorry I'm a little late replying to this one, but I like the question.

    I look at it from the point of view of 'need', not technology. BPM grew up in the world of heads-down data entry and call centers. Mobile is irrelevant in that world, and the traditional vendors are still trapped in the back-office.

    BPM applied to true end-to-end processes that start with the customer and finish with the customer, and with accounting, and distribution, and the FedEx guy -- these are the processes that can benefit from mobile technology. But do they need a native iPad app? Or do they just need to make themselves accessible and easy to use by people that have no formal training in how to use them?

    The native i/Droid apps benefit Marketing more than end users (unless you want to make bodily noises that appeal to pre-teen kids). If I have to be heads down at my iPhone or iPad doing some element of BPM work, I'm probably in the minority of worker in my organization and we have to question the value of focusing resources on me more than the ten other people sat at a desk (unless I'm the CEO). After all, I can use a browser, so I can do mobile already.

    As I blogged: Developers are being guided into spending resources on building apps that are just reworks of the mobile website, locking otherwise freely available content into a proprietary interface.

  • As others have also suggested, I don't think the mobile participants of the processes have remained untouched by BPM. The technology adoption for mobile "applications" in the BPM mainstream may not be as sophisticated as, say, gaming; but when needed by a process,available solutions have been leveraged.

    There are various stages of life-cycle and various ways in which the mobile interfaces could be used. For example, alerts & notifications are definitely an area that prominently uses mobile interfaces. Similarly, certain approvals and quick-click activities have also been used on mobile interfaces very frequently.

    Having said that, with technological advancements within communications and mobile devices, the adoption is going to increase automatically as users get better equipped devices and adoption for "actual" work on mobiles gains speed. Whether modeling and reporting uses the same depends on how commonplace and convenient the mobile interfaces become for those roles and the required activities.

    Another point to be noted is that there are many domain areas where the applications are already fully leveraging mobile interfaces, for instance, in payments. It is not necessary for the BPMS or the process engine to be interfacing "directly" with mobile gateways and services as long as the participant application/system for a particular task handles the various media / carriers / interfaces for those activities. So, in some cases, the capabilities of the participant underlying applications may even make the mobile interfacing at Process engine level irrelevant, to think of it :)

    I actually think that the Unified Communications technologies are going to change the way we look at the messaging and interfacing completely. Content would be key, and the rest could be handled through UC. Please see my post on Unified Communications and BPM here --> http://wp.me/pN8i1-2O

    So, actual question is - whether BPM technologies really need to build everything for mobile in the first place. For core functionality, yes, but leveraging the existing or upcoming capability in other *supporting technologies* is very important.

    - Ashish

  • Just to show an example of an approval action running on a iPhone.
    There are many support processes that are candidates for automation by a BPMS system. For example different types of requests that needs a manager approval. It is quite annoying when people are waiting for an approval because the person is on a business trip. For example firewall rule request, user access request to application etc. These processes has been automated with Notes/Domino light weight process databases the last 15 years. Mobile support more or less non existent.

    These processes are not "core" processes and can be automated with a low cost SaaS based BPMS system. Instead of legacy technology like Notes/Domino you can chose a modern consistent workflow/process platform instead. This enables mobile access to the application:

  • Mobile phone are no longer for personal use only. Work is no longer done just in the office. Employees receive company mobile phones to enable them to be online 24/7. Investing in Mobile BPM is not a “nice to have? feature. It is just a necessity for any BPM suite. It won’t increase the revenue. It won’t make processes more efficient and it probably won’t have any real ROI. But pretending it won’t happen and burying your head in the sand won’t help you either.

    Sirena from Mobile Application Development

  • Agreed I don't see a lag, Mobile BPM is very much of the forefront of mobile business applications.

    Let’s face it, it has to be, people engage in process and we don't all sit facing a PC.

    Process have to go where people go and we can't build in latency waiting for desk bound activities. Processes need to be integrated into how and where people work; and integrated across people and their work.

    We also need to reach consumers and place our processes in their context.

    Many 'core' business transactional systems, Finance, HR, ERP are manned by domain users who are so often deskbound and not leveraging mobility.

    Mobile BPM is in the front peloton.

Add a Reply

Recently Commented On

Monthly Archives