Showing posts with label iPaaS. Show all posts
Showing posts with label iPaaS. Show all posts

Thursday, August 23, 2012

Cloud demands a new way to run Business Processes


My invoices / purchase orders / quotes / leads are stuck!
Does any of these sound familiar? Have your ever had a situation when you are working with a cloud service and another application and you realize that your business is stuck somewhere in between because of an IT issue either on your IT or the cloud providers IT? How many times you have been interrupted because xForce upgraded their API or your ERP was undergoing maintenance or the DB went down over the weekend towards the end of the quarter – just when you needed it the most and you could not provide that crucial analysis or report.
If any of these scenarios strike a chord then you are looking at the new way of doing your IT business.  Where services will go down or will  do an upgrade with or without notice and you have to redo some steps while not redoing others – sounds familiar? I want to push all my quotes again to SalesForce, but I don’t want to submit all the invoices again into my SAP. Welcome to a world where when you define a business process, it may not work exactly as expected because of a myriad of reasons – some you can control some you cant. How do we get around these? We have seen the argument of on-premise vs on-cloud play out and currently the answer lies somewhere in between. And that is going to be the reality of our world for at-least the next decade.  How do we prepare ourselves for this reality and ensure that we are not sitting in conference calls between Friday and Sunday AM.
What you need is a solution that lets you make these various applications talk to each other and be prepared to hold the line when one of the parties is not reachable. Also it must allow for reconnection when the call drops – almost all of the things that you expect from … common sense!
I remember talking to a tire selling company last year when they had put a system in place which was holding a few hundred  of invoices in flight but there was no way to move them forward. Engineers on both sides spent hours trying to “fix it”, understand how we got there in the first place but it was a tedious task. Those invoices were critical for the sales team to hit their monthly target but there was little respite from the “system” issues.
When we started building out the next generation business process platform, we were acutely aware of these requirements. Our belief was confirmed when talking to our early adopter customers that they have this pain and it is a recurring pain. Therefore, we built a very agile business process engine which can react to such events as and when they occur. Earlier research around BPMN execution semantics came in handy for our design. And the result was Roubroo – a light weight, cloud based graph enabled business process platform which could execute structured and unstructured processes, accommodate ad-hoc process definition and instance state changes with a WYSIWYG control – much like the control panels in more evolved machines like Hydroelectric plants – more on this another time.

Monday, July 23, 2012

BPM 2012 Demos

Hey guys - A quick note, there is the most significant BPM academic event BPM 2012 is coming up soon. It is hosted at the University of Tartu this year and Prof Dumas is the General chair. Industry stalwarts Alistair and Stephen White are the other people that I have had the pleasure of working with at the BPMN 2.0 task force. The most interesting part is that there are a whole bunch of  industry relevant research papers. I have my favorites but I will hold on until the conference.  Here is the list of accepted papers. Roubroo wont be present in this years conference, however, we are plugged in to what is the latest and greatest in the BPM world; in terms of paper review and more.

Saturday, July 07, 2012

Crossing the chasm

What do businesses do? Or what makes the businesses successful.
The ability to deliver a  quality product (goods / services) efficiently  and consistently. The reason why Walmart is such a phenomenal success as a business is because it can deliver a specific product efficiently, hence at a cheaper price, than any other competitor. Success in business means being efficient and have economies of scale. And I can speak some more here but lets desist the temptation:
Why did I start with the above because a business is a business so that it can deliver "" repeatedly. We have annual IT budgets that run into billions so that businesses can execute their function - deliver a specific product to their customers again and again. The importance of the word repeatedly and again is where I am going with the reason why businesses need business processes. Whether they execute in a person's mind ( a SMB owner) or in a BPM system, there are business processes that repeat on a daily basis so that business can deliver the product or service custoemrs expect. Making these processes efficient and improve them rapidly is the goal of every CEO.

At the same time, there are professionals who have to deal with unique problems everyday - a doctor tending to a patient in ER, a lawyer dealing with a criminal case, a golf player on Pebble beach golf course with El Nino winds for a change...most of these examples are unique and being able to document each of these processes might :

1. Defeat the purpose (the patient might die) while the process is being documented.
2. Wont be cost effective - a doctor documenting the case (not patient history notes) and how he arrived at the differential diagnosis and then choose a specific antibiotic over another will not be cost effective as this decision making intellect has been honed over at least 10 years of med school and practice thereafter. It would be impractical to design for every permutation and combination.
3. It would not be repeated - I dont think the speed and direction of the wind at pebble beach is going to be the same again.
4. Each of these is unpredictable, you never know what to expect.

I think that the reality of businesses lies somewhere in the middle of these two. There may be certain processes which are so mundane that any investment would be a kill (and I wont give an example on purpose); there are certain processes critical and core strength of the organization, the procurement process for an automotive manufacturer, or order to cash come to mind immediately, which can benefit from a BPM approach. Even within these critical processes, 60-80 percent of instances follow a well defined path ,depending on maturity model of the organization, certain instances may need adaptive processes or segments thereof, or processlets as I would call them, and then again there are cases which happen in rare instances. 
As a CIO where should I put my money in - 
a) in those 60-80% process instances which can be automated, done faster better and cheaper; 
b) in those 20-15% instances where parts of the process are defined but not the whole process, 
c) or in those capabilities which are rare and in between - wherein even after the investment I might find that it was insufficient.
I think the choice is really between 1 and 2. But what if, <...pause>, there is a software that can do both. One that can execute my 60-80% process instances, support cheaper operational models for these, continuously measure performance of key tasks, improve  the process based on feed back ....
AND  with the turn of a switch, take those specific 20-15% instances and create an adaptive process model, modify them on the fly and execute segments of process as and when needed.
Time for my sales hat - please feel free to ignore
Fortunately, such a system exists and that is called Roubroo. It lets you model your business processes using BPMN 2.0 - executes them as per the semantics defined and alo lets you modify specific instances as and when needed. Please reach out to intro@roubroo.com for details.







Friday, June 08, 2012

The BPM pattern challenge?

Dear Readers
   I have been doing some deep thinking about the value proposition of BPM. The modeling environment, the execution engine, the admin console, the user tasks engine, the reporting and the list goes on...
In this laundry list of features, users may often overlook the very reason why they needed a BPM tool in the first place. The reason people decide to do BPM is to run their business - with accuracy, promptness and absolute fidelity; and they want the ability to change their business based on new market conditions "VERY" rapidly.
    If this is the reason why you are doing BPM - to run your business process with absolute fidelity - then dont be fooled by the laundry list of features - go for the kill. Can the BPM tool in Question run your business process with "ABSOLUTE FIDELITY" - can it "CHANGE RAPIDLY"?
   I argue that most tools cannot. And I am doing so with the experience and conviction that I have.
   And the reason we started building Roubroo was exactly the above - to be able to execute what your business process is with absolute fidelity, sometihng that we call "WYDIWYE" for the past couple of years. Sometimes, it is difficult to articulate the value of process fidelity and WYDIWYE - but probably it is easier to articulate the value of not having it. Ask the following Questions:
1. Does your tool let you model the process you want to draw? Or does it draw extra gateways etc as you model, trying to "help" the modeler?
2. Does your tool execute the process as is?
3. Do you have to call in your IT folks to code wait conditions or other checks to work around the limitations or as they say "features" of the said tool?
4. How rapidly are you able to add or remove steps?
5. How easily can you change the order and dependency of the steps - change the flow logic of your process?

I think if the answer to any one of these questions is No or the estimate of change is more than a matter of day (I wanted to estimate minutes but to be more benevolent, or couple of days) - chances are you are dealing with the wrong tool.

And the reason is not that someone made a mistake, its simply that these tools were built without the correct execution semantics. This basic and fundamental power is buried under layers of tooling and feature lists which is hard to argue around - every vendor claims they have all of these items in their feature list. What they dont tell you is what is at the core of the engine. What are the mathematical fundamentals around which they built the process engine?

I will leave today with a few examples and I will ask you friends to enlighten me if your BPM tool can build these patterns in a matter of minutes or not?

Take a look at these patterns - I have built only 4 for now, to see if the tool you have chosen can support your business process with "ABSOLUTE FIDELITY". And mind it these are the simplest of examples with no more than 4-5 steps required to demonstrate the BPMN 2.0 pattern. When we start modeling the real business processes there will be combinations of these patterns at play.

http://roubroo.com/resources/process-patterns


Sunday, April 01, 2012

Activiti - PVM - a closer look

Recently a team member pointed me to this white paper evaluation of PVM - the process virtual machine which is the heart of jBPM and Activiti. Apparently, the support for various patterns is pretty week in PVM:
Who is betting the future of their workflow on Activiti? Take a deep look at Roubroo

Maturing BPMS to Case management

http://www.bpminstitute.org/resources/six-features-look-bpms-support-case-management-processes

This article is an excellent summary of what to look for in a BPMS that can allow for the flexibility of supporting case management. The ideal solution which kill two birds with one shot. It will create a set of defined process(s) for the 90 % of throughput but will also allow to turn this into a case for the remaining 10%