BPM-EAI

It's been an interesting journey in BPM space for me, starting with BPMS for application development to utilizing BPM as a mean to manage and control business process and IT investment.

"BPM aligning Enterprise IT systems with business" seems to be a silver bullet for IT, but an appropriate approach to BPM can actually yield the said alignment.

Here when I am talking about alignment, I am not talking about the typical benefit preached by BPMS product vendor like ability for business users to modify process, or ability for user to manage business rules or ability for business to define the requirement better. These are the typical benefits you will be promised by any BPMS tool vendor. But the alignment I am talking about is much for than these mere tool specific benefits.

BPM addresses business process as a whole and does not merely limit itself to process automation, but a way to manage your end to end business process. Today any IT system an organization implement such as package application, ERP, CRM or bespoke applications is typically a response to business value improvement, subsequently which is attributed to improvement of business process an organization deploy.

Now the issue is these investments are based on certain pre-assumption made on the end to end business process improvement, without clear baseline. This sometime results in not realizing the business benefit from ERP, CRM or any bespoke investment.

This is where BPM plays an important role in identifying the areas for business process improvement, with right amount of quantification of goals.

• Any end to end process in any enterprise would have ERP, bespoke application, legacy application and manual process
• It is important for any BPM adoption to understand the end to end process, divide the process into critical process area (Process breakdown) and baseline process performance (KPI)
• Utilize baseline business process performance to identify end to end process improvement though
• IT Resource leveling
• IT system upgrade
• Any legacy modernization
• ERP rollout
• Utilize BPMS capability for legacy modernization
• Then subsequently monitor the improvement to ensure the identified goals are achieved

Important aspect of BPM is that you can bring in BPM in an enterprise at any given point and start reaping the benefit, and it is never too late for BPM adoption.

Posted by Manas Kumar Sarkar at 06:53 AM | Permalink | Comments (1) | TrackBacks (0)

Some time back I talked about ‘repurposing of technology’ in one of my blogs. Intent there was really to explore the trends of different types of adoption of technology products and question the hypothesis of alignment of the technology usage with the product vendor roadmaps.  That’s more of ‘risk mitigation’ approach since there is considerable threat of lack of support from vendors or lack of future path of the technology if it is not aligned to product utility as lined up by the vendor. Now, that is not a technology issue, it’s business issue and issue of product vendors making good and sustainable business.

If I read into the evolution of products and technology, I get clear sense that various software development platforms are swiftly moving to an integrated IT eco-system development platform. In the Conventional model today, we development separate components/modules/layers of the software in isolation and by virtue of architectural constructs we integrate them together. So in this process, software products have got capability to the level where they can create part of the eco-system with self-sufficient machinery included in the system stack (SAP, Oracle etc. are good example). However, integrating it again with overall IT eco-system and creating unified ecosystem is still a complex ball game. So here is the next wave of software development tooling coming. It is taking the scale to end-to-end enterprise IT solution development on a single platform where constructs like BPM, SOA, Mash-ups etc. are all part of the deal where users of the product will not be worrying too much about it. Now while conceptually such product is easy to think about, but it will take a lot to transform the current practices of software development. All users will have to worry about it the design, configuration and deployment of services. Platform will be lot more usage, monitoring and change management centric than coding, integrating etc.

In that sense, if we were to expand the existing BPM tools to include strong application development features as well as core SOA capabilities in the same product, then they can be self sufficient development platforms to create IT eco-system level solutions instead of creating piecemeal solution that need to be stitched together to make it work. BPM products have this potential as well as packages like SAP, Oracle have strong capability to re-platform current products to make it happen. I feel this is a strong direction to bet the money on. Not to miss that entire IT eco-system development tool might be available on the cloud for organizations to just use it to create the master architecture/configuration that they can simply drag and drop in their environment to deploy the massive enterprise scale solutions. What a possibility we are moving toward….we got to be ready for shocking way of life in the history of Information technology…I’m already feeling old…

Posted by Rakesh Mishra at 11:51 AM | Permalink | Comments (0) | TrackBacks (0)

 Part 1 of 3

Introduction
Industry analysts have repeatedly pointed out that technology is a beguiling proposition and businesses invest expecting to save money or increase revenue, but rarely realize either benefit. 
The rapid investment over the first half of the nervous nineties have placed the CIOs under enormous pressure to  become “Value Creators” and  produce or increase profit from existing company property rather than investing further.  This may be connecting the enterprise's data in new ways to give new insights and improve decisions. However, there is an added mandate to be thrifty and manage internal costs to free dollars to create innovation and value. With highly compressed decision cycles and the need for faster recovery of IT investment, consultants are increasingly being asked for recommendations with ROI cycles in months rather than years.
It is in such uncertain times, that the Enterprise mashup has presented itself as one of the promising technologies for the next decade. Let us take a look at what the mashup is and why do analysts think it will be the growth engine for Enterprise 2.0.

So what exactly is a Mashup ?
Mashups are defined as “Web technology-based lightweight composite applications created by sourcing capabilities from established content and systems functionality.”
The basic technology has been around for quite some time now and in fact it forms the primary foundation for the Web 2.0 applications. In fact, its quite possible that you have been using several mashups already without being aware of it. Here is a quick example.

PackageMapping.com – Gives you the ability to see a visual representation of the tracking of your packages shipped via DHL, FedEX, USPS and UPS. The mashup pulls out package tracking information from the logistic providers and maps them on Google maps.
I chose this example because it demonstrates the ability of mashups to create value from existing technologies. The underlying services were developed based on business cases which were significantly different from that of the mashup, however the mashup has enabled its sponsors to justify their business case without investing in any significant new technology.
The key defining characteristics that set them apart from other forms of application integration are that they ALWAYS source content or functionality from established systems and have no native data store or content repository.

Conclusion of Part 1.
In the next part : The Conceptual Architecture Model for Enterprise Mashups and the Business Case.

Posted by Maloy Patnaik at 11:37 PM | Permalink | Comments (0) | TrackBacks (0)

With recent acquisition in BPM and SOA space, it is clear that those vendors who positioned themselves SOA vendor is feeling the pinch without a solid BPM offering. Now that IBM has acquired Lombardi and Progress has acquired Savvion it will be of interest to see how both of these companies going to use these product to position themselves in BPM space. However it is better to leave the roadmap definition with IBM and Progress. However the discussion point out here is; are these vendors responding to market need...

I guess the reality is; they are doing so. Over the last few years I had been following few emerging trends around BPM adoption and these trends are getting stronger day by day, which clearly indicates that BPM is gaining ground faster than SOA. Some of these trends are

• Usage of BPM to deliver enterprise class application which enables IT to involve business stakeholders closely to deliver the solution with a considerable focus on business process KPI. And SOA being seen as a way of utilizing exiting IT application
  
• Usage of BPM for process standardization, harmonization & continuous improvement, even in cases where ERP strategy is been adopted for process harmonization. Again SOA is seen as an architectural approach to ensure process decoupling to handle variations
  
• Using BPM & BRMS for legacy modernization. Again SOA taking the back seat within organization in these legacy modernization drives
  
• And the most important trend has been using BPM to deliver composite application. I guess this is something even biggies in ERP space like Oracle & SAP are adopting. Both of these vendors are making BPMs capability as an integral part of ERP offering and delivering ERP capability using Composite Application Framework.
  

However this does not mean that IT organization are ignoring the importance of SOA platform and SOA, they are just not positioning SOA in front of business any longer. In short SOA is seen by IT organization as the right approach to make existing system landscape flexible and geared up for change and BPM is seen as the way forward to collaborate with Business to deliver value.

Posted by Manas Kumar Sarkar at 09:01 PM | Permalink | Comments (1) | TrackBacks (0)

Unstructured vs. Unmanaged? That sounds like playing with words. Let us give it a shot even if it seems so. It came to my mind because while reading various comments on the blogs of unstructured process, I  felt that there is lot of mix up. On one side, there is characteristics of the process (or qualification of the nature of the process, if you will) which is recognized in my title of the bloglet by the term “unstructured process”. On the other side is the way that process is being managed which is signified by the second part of the title….

So we can see it like a classical 2x2 matrix  between process type and state of the management of the process. We will end up with 4 classes:

1. Structured process – well managed
2. Structured process – unmanaged
3. Unstructured process – well managed
4. Unstructured process – unmanaged

So hypothesis here will be that BPM (which is really about the state of the management of the process) doesn’t really make a process structured or unstructured. But there is a shade or grey in everything so needless to say that practically it will be mix of different classes to deal with. It means that in the organizations, processes will have mixed characteristics of structured and unstructured and sometime even process will have both structured and unstructured (for example exception handling being unstructured in many cases) parts. Classical approach in BPM is a case of 2) and make it transition to 1). In this case, as I said, we are not really enhancing the ‘structure’ of the process per se, but we are managing it better. In complex transformation scenarios, we will possibly take a class of 4) and transition it to 1) but that’s a big leap. In that, danger is that we may land up in 2) instead. I can’t say with confidence if moving from 4) to 2) is better or more riskier, that’s matter of debate.

Today, general mindset is that unstructured has to be unmanaged and hence most of the time 4) is a starting point for unstructured processes. As we get to understand the nature of the unstructured processes (see my other blog on it: Unstructured business processes - creating differential BPM strategy is the wise thing to do), I find its better (BPM) strategy to move from 4) to 3) first which will provide sufficient capability/insight to be confidently move from 3) to 1). In simple terms, we should learn to manage the unstructured processes before we try to make them structured.

Taking example that Jacob shared in my previous blog: RFP management scenario. There are many unstructured segments of this process that can be moved from unmanaged state to managed state:

• Qualifying the RFP for response – while some RFP may be disqualified on the basis of well-defined policies/mandates, there may be RFPs where business sense will be used to reject them. There may not be any guidelines/policy defined to make those decision and it may not necessarily happen in the same manner every time the same scenario occurs (due to person dependency). So in a way, this is an unmanaged and unstructured process where depending on who is handling the RFP, decision will be made on the basis of the business sense of that person. Now transitioning this unmanaged part to managed part will mean identifying the variables of the situation and formulate the logic/rationale that has been used in past to make some of those decisions. Using that, RFP qualification process can be matured to include recommendations that can be quickly reviewed by the person qualifying. If he/she agrees to the recommendation, it is validation of the policy that was proposed and if it doesn’t, it needs to be captured to refine the policy design. Similarly, in some cases, person qualifying the RFP may refer the RFP to specialists and experienced business managers. That also could be happening in ad-hoc manner. When converting unmanaged state to managed state, such practices can be formalized as best practices and can be given as option to person performing qualification so that if person decides to do reference reviews, there is a framework for doing it (in this case, we could have list of subject matter experts and reference points being made available and also a workflow to perform such reviews).
• Pricing discounts to be given to client – there may be policies around discounts that can be offered but as we all now, depending on the criticality of the RFP and negotiation positioning, exception discounts could be applied. Here again, there may not be any well-structured guidelines. To convert it to managed state, we can start capturing the assessment input that went into deciding to raise the exceptional discount, policies or thought process that went into deciding the quantum change of the discount and associate the same with the variable of the RFP scenario and finally figuring out who were the additional players involved in the decision making and for what they were involved. With that, next time when such scenario happens, there is lot more help/support available to person taking decision on the exceptional discount.
• Managing time-crunched RFPs or  Managing situation of not having appropriate person available to handle/manage the RFP – in both of these cases, there is no process in most of the organizations that can predictably handle the outcome. In both the cases, manager will typically make a business call what to do (including the decision of dropping the RFP). So to manage the situation better, we should be able to capture the possibilities and have most recommended actions planned. Also, any possible support that person might need to execute the action plan in such situations should be integrated with the main process flow to enable the better execution of the process.

So in my other bloglet when I talked about the differential strategy of BPM, this is precisely what I meant:

• Part 1 of the strategy:  move a structured process from unmanaged state to managed state
• Part 2 of the strategy: move an unstructured process from unmanaged state to managed state

Posted by Rakesh Mishra at 10:26 AM | Permalink | Comments (0) | TrackBacks (0)

“why to adopt business value focus seriously and how to go about it”

As I see, BPM is all about business and hence it needs to be grounded on what’s most valuable to the business – ‘Business Value’. For the rest, neither the business people want to understand really nor they care about (BPMN, SOA, XML and the endless list that all of us know) it. That’s fair I suppose. How many times people really care what technology the digital camera or mobile phones work upon when they buy it? How many times do we bother about the technical wizardry of microwave ovens when we buy it and use it? So we all need to listen to the message.  No point in wasting time in selling technology nuts and bolts to business. We need to take the business realization to them. I will be surprised if that is a news to anyone.

Moving forward with the business value thinking, I came across a fairly crisp blog by Sandy Kemsley on BPM that talks about changing expectations on BPM (you can read this blog here). She says “…ROI might still be used to sell BPM projects (necessary in these budgetary times), but the final metrics will be business value-based, since ROI doesn’t necessarily measure the actual business improvement…”. Those of you who have had first hand experience of dealing with the top secret ROI calculations, I’m sure this is going to be something very close and interesting to you. Let me bring another important reference here. Jim Sinur from Gartner says on his short blog (that you can read here) says “…BPM, in the future, will be goal driven and will orient itself around goals…”. So it’s pretty much the same thing, little different wording, slightly different orientation…

Now how is this approach different than conventional approach? Not just for BPM but for otherwise too, Business value focused approach differentiates itself by way of having design strategies/principles that are governed by the business value goals and not just creating solutions against some functional specifications that are built for ‘user requirements’. In my experience, there are less than 40% of the specifications are mostly driven by what business users want while those specifications may not have a direct link/relationship with the business value that organization cares about. So this is the shift of moving from pure functional specification based design to business value linked design.

So how does this business-value-linked design thing works? To simplify this, let us break it down into complete value chain as shown below.

 

 

 

 

 

 

 

 

Figuring out what values to create – this is where I think problem starts. While businesses are fairly clear what are the business values they want to achieve, this rarely appears in any of the matters that IT is dealing with. Business value in BPM context are the metrics that businesses use to define how well their business and operations are going on. These are driven by the overall organizational business goals. For example, in an order management process, # of orders that are stuck in the validation stage could be important metric that governs how many orders can be processed in a day and that defines how much revenue potential organization can have in a day on an average. These metrics (as driven by the organizational goals) can be of various types as the diagram shows, i.e., efficiency metrics, compliance metrics, cycle-time related metrics, cost metrics etc. It also has metrics that are not direct business process outcomes, for example, business user satisfaction, business capability reuse etc. Organizations care about them so should the solutions that businesses adopt.

Figuring out where to create the value – a solution like BPM has multiple dimensions as we saw in the first bloglet. Different capability areas of the solution provide different type of opportunity to create the business value. Alternatively, I can say that these capability areas have different influence/impact on the business values. Also, different capability areas of the solution will impact various business values in different ways and to varying levels.

Figuring out how to create the value – this is what is missing majorly in the solutioning practice in many organizations. IT task forces are really not geared up with necessary methods, approaches and design strategy that can have differential guidelines/mechanisms for different business value needs. And as I said, prime reason is because most of the time solutioning is done purely based on the functional specifications that reflect just the user needs but not necessarily the business goals.

In the diagram below I have attempted to provide the summary view of the capability areas of the BPM and the categories of various business metrics that BPM can influence.

 

 

 

 

 

 

 

 

 

 

 

 

 

In the next bloglet, I will try to uncover more life-cycle specific views of practices that business value centric BPM can adopt.

Posted by Rakesh Mishra at 07:59 AM | Permalink | Comments (0) | TrackBacks (0)

"Why BPM is critical to build the future of the Business"

This blog series is on building the future with BPM so we must realize with clarity why we believe BPM is going to be critical for the business in future. This realization is important because this is what will drive your investments, strategies and core values adopted for the BPM program. Here I’m not talking about basic need or fundamental business case for BPM, I’m sure most of you understand that very well. Instead what I want to share are some of my observations and perspective of the global trends that mean a lot for BPM going forward.

Before I begin this bloglet, let me close something from the last bloglet of this series. Here are set of clarifications based on questions/suggestions from the readers who reached out to me:

• Is Policy/rules execution as mentioned in my blog is same as BRM? – Yes, it is indeed the same. Business rules management is integral part of the BPM even though some organization chose not to focus on externalization of BRM within scope of BPM. Nothing good or bad in that, its just that organizations need to have clarity on the impact that BRM-less BPM will have. To read more about externalization strategy, you can refer to my another blog that I wrote recently: Externalization based design strategies - another angle for SOA principles?
  
• How is process scenario intelligence different than the performance monitoring? – I think that was a great question, I’m glad that some cared enough to think about it and asked. If I were to give simple analogy, I would say it is the same difference as how BAM and BI are different. Focus of the process scenario intelligence is more about getting to know the business insight through the patterns of the business events/activities/behavior and use that in the decision making (operationally and strategically both). At the same time, performance monitoring is more about monitoring the pre-defined KPIs of the processes, measuring and monitoring it against the service levels defined and if service levels are not being met or there is a warning of SLAs not meeting in future looking at the performance trends then taking appropriate measures/actions to address the performance bottleneck.  Hope that clarifies. There is detailed blog by James Kobielus, Forrester on Predictive power of the enterprise (read it here and you will find some interesting details that James has highlighted in the context of BPM)
  
• Does the diagram shown in the blog signify low level of human intervention for the ‘document centric processes’? – not really if I were to be honest. As I had mentioned, this is generic representation. As I see, we could have scenario (and very valid scenario like insurance claims) that are heavy document centric as well human activity centric. Trick is that in that diagram, focus is on the pure process type as described. So you will see that in the document centric process, document administration is very high while other characteristics are moderate. In real life, what you may find that some processes have hybrid characteristics, especially when part of the process is heavy on one characteristics while other part could be heavy on some other.

So thanks to those readers who bothered to reach out to me, that helps a lot to bring some important points in the light. So let us move on to the next segment.

To start with, one of the major change that we see in the business processes of today and tomorrow is the sheer complexity. Due to evolution of global standards in the businesses and their practices, entire eco-system that makes up the business process for an organization has complicated stuff inside including various roles that interact, multitudes of policies and rules, duplicate/redundant processes, overlapping department activities and what not. (on lighter side, it just reminded me of a good article on difference between complex and complicated. Did you think they were different? Read on here if you want to explore). This complex as well as complicated network of processes is a direct hindrance for the business innovation. In one of the Harvard business review articles, professor Rosabeth Moss Kanter (read her article here) says “...The world is complex enough without human actions making it more so. We have been paying a price for too much complexity, creating -- or allowing so much variety that it is hard to sort through it, and adding so many loops to the chain that no one feels personal responsibility for the whole system or even comprehends it fully..”

• BPM is an answer to simplify the chaos and complicated web of processes by bringing an overarching control and boundary view of the processes. So basically it will allow us to first create large end-to-end processes so that overall chaos is broken down by those large segments. And then complications within each end-to-end process is further attacked to simplify through externalization, service orientation etc. This will help organizations to bring back the process efficiencies (in their otherwise complicated world of business) and create greater capability of decision making in terms of speed and strategic impact through accuracy and timeliness of what’s happening in the business process.

Next very important shift in the businesses is an attitude towards ‘change’. Those who have been on receiving ends in the business organizations, they know how much really they hated all sorts of change all along, be it people change, vendor change, software change, product change etc. Everyone ran away as much as they could from the evil of change but with changing times what businesse are realizing that this is the change that will drive their opportunity and competitiveness. So more you run away from it, farther you are getting from the chance to succeed in this unfair marketplace. Today’s businesses are being built for the change and not just barely managing the change. You need to halt on this sentence and spend some time on it, its so important. Business find that they need to build more processes, more often and change them even more often. Consider it inevitable till we see next wave of market transformation (may be another decade).

• Consider BPM as a good foundation to ‘deliver’ the change (once again, I’ve carefully and deliberately avoided to write ‘manage’ the change). A properly designed BPM framework to deliver end-to-end business process will simplify the process of change and decouple the complexity of technology change from business change to some extent (not entirely of course). Externalization brings flexbility, configuration driven systems bring ability to change on the move what we may call as dynamic process management.

And now the IT side of the story. Today IT is a a great dependency for business performance, fortunately or unfortunately. Variability and flux in the IT landscape  seems to be worsening every year and that raises singificant challenge and threat for business. Given that majority of business today is executed in the machinary of IT and is embedded inside the complicated network of systems and data hubs. As systems change and the IT landscape changes, how do we protect the ‘business process’ that is implicitly residing somewhere in the fabric of IT?

• BPM allows a top down business view to be built, managed and protected from the impact of flux in IT fabric. BPM (partially if not fully) allows to secure the state of the business process knowledge decoupled from what otherwise will be fragmented inside system. I know BPM possibly is not a complete solution to this problem, but surely is very important part of the solution.

Last but important aspect to consider is the rising trend of the business process outsourcing. BPO in my view is really all about process management at its core. As BPO is becoming inevitable strategy for enterprises to improve the process efficiencies (and to reduce costs), BPM will get its play stronger. BPM has promising capabilities to make BPO transformation, transition and management simpler and faster, both for the organizations as well as for the BPO companies. In the context of organizations, BPM enabled oranizations will find a great deal of relief while integrating the BPO-enabled processes to rest of the processes in the organizations. In the context of BPO companies, they will be able to create a great deal of efficiency and reduce the risk of managing business operations through BPM enabled processes (and systems). There is a nice article in ciozone.com (you can read it here) that elaborately talks about role of BPM in BPO context. Check it out.

So if you look at all four forces that I tried to present from my perspective here, its very clear to me that investing into BPM and investing strategically now will be on the charter for most of the organization (if not already) by middle of 2010. And as it gets serious, focus on value-driven BPM will become more and more important both for the organizations as well as for the IT service vendors. In the next bloglet of this series, I will break into the focus of ‘business value’ for BPM to explore why to take business value focus and how to go about it. Till then, may be read my bloget once again and let me know what’s going inside you.

Posted by Rakesh Mishra at 06:49 AM | Permalink | Comments (0) | TrackBacks (0)

As discussed in Part 1 the key motivations behind delivering Integration Platform as a private cloud are

• Minimize environment management overhead
• Uniform configuration accross environments 
• Basic integration platform QoS is delivered to all business initiative including capacity management
• Automated deployment of services with minimal intervention by Integration team
• Optimum utilization of hardware infrastructure 
• Apportion Integration Platform cost based on 
• Integration solution complexity
• Solution type
• Volumetric
• Application to be integrated
• Usage of Integration Platform

Considering Integration platform forms the enterprise backbone, the motivation presented above becomes the key input for architecting & engineering Integration Platform for deriving better ROI using a private cloud based hosting model

Today enterprises are far from achieving this, due to the basic fact that stringent governance around managing Integration platform is missing

• Integration Platform Architecture & patterns remains on paper and the realization link to the integration platform is missing - Project team are reinventing solution design for implementing similar patterns
• Runtime component standardization is missing - No common implementation of Technical services like error handling, logging, auditing exists and every project builds it from scratch
• No comprehensive capacity model in place, Capacity analysis is done with project view and not enterprise platform view - As a result coexistence of integration solution components delivered by different program is seen as a performance degradation or stability risk
• Comprehensive automation is missing - Environment & solution component provisioning is time consuming and human error prone (requiring regression testing to ensure environment build)
• 360 degree governance for Integration Platform missing - Today governance focus is not extended to the management of Integration platform (read runtime behavior). Typically exception raised by project team or support team on the core integration platform is not seen as an opportunity to improve Integration Platform run time behavior

However in most of the cases some amount of standardization exists but an overarching view is missing. However a detailed analysis showed following levers could provide the basic framework to approach this

• Architecture standardization - Establish a platform architecture to address enterprise needs without being constrained by product, followed by detailing of various implementation pattern with adequate detailing
• Component Consolidation - Based on the architecture ensure consolidation of technology to present an uniform view of the Integration Platform
• Maximize re-use - Ensure platform design ensures re-use at every level design, development and runtime, to maximize benefit
• Platform capability improvement - Focus on continuously adopt implementation best practices as platform capability to improve overall platform maturity
• Improve Infrastructure fungibility - Look at opportunity to utilize the hardware infrastructure optimally through virtualization and partitioning
• Improving Automation and imbibe Self Service philosophy for Integration Platform - Bring in automation to remove human error to the fullest extent, this forms the basic building block for self servicing Integration platform
• Formalize SLA/OLA management - Identify measures for SLA & OLA and identify sources for measurement to bring right amount of intelligence to manage adherence

However it is important to sequence your approach in the right manner to ensure maximum benefit and the diagram below provides a view of the approach I am recommending to our clients for establishing Integration Platform as Private cloud

 

Posted by Manas Kumar Sarkar at 09:51 AM | Permalink | Comments (0) | TrackBacks (0)

Finally BPM has found some spicy angle to its existence in form of what is being called as managing ‘unstructured or ad hoc processes’. That’s a good sign that progressive discovery of new concepts/ideas related to real-life stuff is still happening.

Various sources on the net estimate that 60-70% of the business processes in an enterprise are unstructured or ad hoc unfortunately. Can’t really say how much true that is because no reliable study or research is available to make conclusive view on it. But at least there is fairly reliably observation that reasonable part of the business process today apparently is what we call unstructured. Hang on with me, I will come to elaborate on what an unstructured process is if you have not been initiated into this new fancy stuff so far. Do we really consider the segmentation of structured and unstructured processes in the BPM strategy today? Largely not and that’s because they way BPM programs are run, there is hardly any visibility in most of the organizations about all the business processes in totality. So default assumption is that processes are all well structured. That may be the reason when some time unstructured processes are picked up for BPM implementation that see great challenges meeting the requirement. Irrespective of who is finally blamed for the failure, just think about it…it something new, something different, something we really didn’t pay much attention to...

(I expect to hear “I did it 10 years ago” as usual but we are not talking about exceptional wizards here, those could excuse me with all due respect)….

So what really is this unstructured process stuff or alternatively called ad hoc process? Here are some characteristics that are being considered as the DNA of such a process:

1. Most importantly, activities or steps in such processes are not pre-determined and may not be (or need not be) repeatable either
2. Process steps are majorly controlled and governed by the sequence, nature and even the interpretation (that may not be static) of the events as received by the users
3. New process steps might have to be defined on the fly by the user based on the event. Sometime defining such a step itself could be a step in the process which might take days to complete.
4. Might involve certain judgmental decisions that are not based on the ‘codified policies’, instead based on the subject matter expertise/domain expertise applied on the situation/scenario at hand (you might like to read this blog - http://www.column2.com/2009/09/micro-workflow-gestural-analysis-bpm2009-bpms209/ )
5. Set of users/actors involve (or who could be involved) is not formally defined. It is discovered as event/process scenario unfolds. Scenario dictates who should be involved and who is the right person to execute a particular step.
6. Number of iterations of the processes steps is unpredictable and largely dependent on the scenario at hand.
7. Collaborative interactions among the users typically is a major part of such unstructured processes. (you might like to read this article - http://www.softwaremag.com/L.cfm?Doc=1102-12/2007 )
8. As the nature of the process suggest, it is difficult to tie in KPI of the process to the process design since there is no pre-defined view of the process. This is still an evolving area of research focusing on how to manage the performance of the unstructured process while tweaking all the variables involved.

General assessment is that unstructured processes are not managed adequately (since there is little handle on performance management of such processes) and cost a lot in terms of poor productivity of the users involved. There are emerging debates on if the management of the unstructured process is within the scope of BPM or not. While keeping product (that is BPMS) in mind, yes, we might debate if current BPMS should be tried for unstructured process but as far as BPM is concerned, I don’t see any reason why management of unstructured process needs to be outside the boundary of the BPM. BPM itself means management of the business processes, whether structured or unstructured. Current BPM approaches/strategies/methodologies might be effectively tuned for the structured processes but as we are progressing into advance BPM, even the management of the unstructured processes needs to be conquered within umbrella of BPM.

Interestingly enough, if you observe carefully, you will find that ‘exception management’ of the structured processes in many organization remains to be an unstructured process actually. It means that once exception is identified (which is an event that triggers the unstructured process), there will be someone who has responsibility to monitor the exception event and who will look at the exception and then do one or more of things (that are not clearly defined as process flow but could be bound by few formal or informal directives) in terms of a) Validating the exception b) figuring out what it means c) figuring out who needs to do what with it d) Forwarding the details and actionizing request to identified authority e) monitoring the state of exception as actions move from one person to other (on system or through email exchanges) and finally f) certifying the exception to be closed after all iterations are closed and exception is resolved. It’s not that there are no exception management software/tools/modules but due to the fact that exception management process itself is not clearly defined (or may not be defined) in the organization, there is very little that such tools/software can really help. So in a way, we really have had encounter with the unstructured processes in the form of exception management processes but I think the problem of unstructured process in the organization seems to be much larger than just the exception processes.

Engineering of the unstructured processes is far from being mastered (keep in mind that even the BPM for structured processes is far from being mastered across the globe) so of course approach toward it is slightly experimental as well as open to new best practices. There are couple of them that are slowly gaining importance based on whatever trials that have been done so far. I’m putting down what I have learnt from our own laboratory as well as gathered from advancements happening across the globe:

• When processes discovery/modeling is being done, classify them into structured (or pre-defined/static) and unstructured (dynamic/variable) right in the beginning so that we can take differential strategy of BPM (to be realistic) for each type of process portfolio.
• To start with, don’t over-engineer the unstructured processes to try to turn them into structured processes else they lose their edge of flexibility and responsiveness. Focus only on managing them better. This will involve aspects like identification of patterns/events, notification to users, provision of necessary information to make the decision, tracking the process foot print and recording the outcomes, providing tools/utilities that support the adhoc activity like email based interactions, ability to take actions directly from Microsoft documents using smart right click menu links etc. (you might like to read this blog - http://www.column2.com/2009/02/actionbase-adds-structure-to-email-based-processes/ ). As you manage such process better, you will get better handle on the behavior of variables involved and provide you better understanding of the improvements that can be brought.
• Methodically plan to transition the unstructured process to regularized structured process (even partially is fine) if the patterns of the process become repeatable over period of time. Recording of the process flows of the unstructured processes is important to discover the process patterns.

Actionbase is one of the emerging products that are trying to address the space of managing unstructured processes (read more about it in the article - http://www.bpm.com/actionbase-launches-version-60-to-manage-unstructured-processes-in-organizations.html ). There are other players like Itensil (http://www.itensil.com/) and Handysoft (http://www.handysoft.com/) that are proposing additional capabilities but as I see, space of unstructured processes is far from being clearly understood, profiled and domesticated. This space looks very exciting and brings new hopes of innovation.

I’m hunting for strong real-life examples/use cases of the unstructured processes. So if you got any in your organizations, it will be great if you could drop a note on that on this blog or to my email (rakeshmishra@infosys.com).

Posted by Rakesh Mishra at 11:58 AM | Permalink | Comments (8) | TrackBacks (0)

2010 is already here, for some reason I feel this time it has come very quietly, yet to sink in that there is something new in the new year…anyways, wish all the readers a very brighter, happier and safer year ahead….

In the series of business value focused blogs, I’m starting a new one for BPM since that is possibly very close to business and business value (in principle at least). I also felt that despite it being so close to business value capability, most of the BPM programs unfortunately are not so much business value driven today. I do not mind if BPM implementations are driven by technology capability deployment, even for those cases, it must have a clear view of what business value it is going to deliver. So with that emphasis, I’m picking up this chain of 6 bloglets. For me blog is really a thinking process, its thinking aloud, it’s lab to present the seeds and test their viability in an open platform. So feel free to drop in your side of story that will collectively help all of us to evolve together.

In the first bloglet of this series, I would like to just focus upon getting arms around what really BPM is. It may be basic stuff for some but I think creating that baseline is important before value creation is spoken for BPM.

BPM as a discipline has five key capability areas:

1. Codification of the business process design and knowledge to formalize the business process blueprint – in this focus area of the BPM, organizations discover and formalize the blueprint of their business processes, codify it in some formal notation (BPMN is one of them) and reuse it later.
2. Process scenario intelligence through business process analytics, scenario simulation and predictive modeling – in this capability, organizations develop mechanism to gain insight into the behavior and the state changes of the important business activities. Such insights helps organizations to reduce the risks, proactively response to gainful business opportunities and improve the business efficiency/effectiveness of the process
3. End-to-end integrated delivery of the business processes  including system and human activities (both structured as well as unstructured processes) – this is probably the core of the BPM. This capability brings end-to-end wire-frame of the process execution and integrates all business activities/functions under unified umbrella of the business processes.
4. End-to-end business process performance monitoring – Business KPIs are the integral part of the business process and this capability of BPM monitors the performance of the business processes /activities to ensure that processes are performing to required (or better) service levels.
5. Business process change management – last but not least, BPM also focuses on managing the continuous changes in the processes. Changes are inevitable and to large extent are actually important part of the nature of the business going forward. Conventional wisdom always had the stability as the value around which solutions were designed but as things stand today, we don’t build anything for it to stay as it is for years. Capability to deal with the change has to be in-built strength in anything that we build today. BPM enforces the same from business process perspective.

Looking closely into variety of business processes, we find few important characteristics that distinguish different process patterns from one another. These characteristics are:
a) Automated Business flow execution – This is more of straight through processing. Here entire process step is executed in a system in real-time or batch mode without needing human intervention.
b) Human interaction – this is entirely human activity that may involve a human operating on a system or doing some activity absolutely manual (like paper checking etc.)
c) Document administration – this basically involves administration of digital documents in terms of validation, processing, creation, transfers etc.
d) Policy and rules execution – as part of the business process, it will require execution of pre-defined rules and policies.

Different types of processes will have mix of intensity of all 4 characteristics described above. For example, claims process will have very heavy document administration while say leave approval is very heavy human interaction. So based on variation of intensity, there are 3 basic patterns of business processes identified:

• Type 1 – Workflow centric processes: In these types of processes, there is heavy element of the human activities.
• Type 2 – System centric processes: In these types of processes, there is very little or no human activity, mostly system
• Type 3 – document centric processes: In these types of processes, very heavy document administration

All three types will have mix of all characteristics but as I said, intensity levels will be different. A generic representation of intensity levels for 3 types of the processes across all the 4 characteristics is shown in the diagram below.

 

 

 

 

 

 

So how does this help as we move forward in the value articulation? Well, this is important because each pattern of the process and each characteristic of the process has its own mechanism to create business value. We need to profile different processes to discover how values need to be administered for them and the way values are driving the process design/profile in one type of process could be very different than the way values are driving the design/profile of the process in other type. So if we want to design the future business platforms with business value as the core, we need to clearly understand how these values drive different types of process differently.

Next bloglet will focus on debating why BPM is critical for the future of the business so that we realize the need to invest in this area.

Posted by Rakesh Mishra at 11:47 AM | Permalink | Comments (0) | TrackBacks (0)