What is “BPaaS” BPM Adoption Model for BPM Processes deployment?

As commented in one of ours recent posts, by "BPM Adoption" we understand the way that some organizations have undertaken to relieve, optimize, automate and outsource part of their business processes, with the ultimate aim of achieving and maintaining the Operational Excellence that ensure them a sustainable competitive advantage.

To simplify our analysis, we have grouped the various strategies of BPM Adoption usually followed by organizations in four archetypal models, which we have called "Process Team", "Cloud", "Consulting" and "BPaaS".

Each model is characterized by the decision organizations have made in terms of the Mode of Development of the automation solutions, differentiating whether they do or plan to do by internal or external means; and the Mode of Operation of such automation solutions, differentiating if they do or plan to do either on internal systems (on-premises) or external (on Cloud or on an external Data Centre).

Under the “BPaaS” model, the last of the four BPM Adoption Models analyzed in this series of posts, both the development of automation solutions and their exploitation, are external, thus combining the features of the "Consulting" model and the "Cloud" models as it is shown in the next figure:

Under this model complete and integrated services are provide, but with two substantial differences with other models:

• The automation solution, even is available as a more or less standard and packaged solution, although it requires some customization for each client (at least for the initial configuration and integration with corporate applications Client); or, the solution, that was initially developed for a first client, becomes standard, and then can be used in the future for third party customers with similar needs, again with the required customization for each new client.
• Other services called BPO (Business Process Operation and Business Process Outsourcing) can be incorporated into the value proposition of the service provider to provide them in the form of personal services that go beyond pure computer service applications.

In this case then, the main and only external actor, is the so called BPaaS Services Operator Services, who integrates various products and services, and builds a packaged offering, including the development, customization and integration of applications and, in some cases, physical operation of certain tasks in the business process in behalf of the Customer; thus acting as prime contractor in front of the customer, for the various products and services including personal ones, required to automate and operate the corresponding business process.

Under this model, the BPMS Platform used loses most of its relevance (except giving prestige to the Operator and then security and confidence to the Client), since what matters is that the solution is the best suited to the client's needs with effortlessly development and customization with maximum flexibility, and that the operator can meet the SLA (Service Level Agreement) committed to the Customer.

Under this scheme, many other tools appear on stage (OCR, ICR, ECM, DMS, BRMS, DB, ESB, SSO, ...) to build the technological ecosystem required for an automated, safe and efficient operation of the deployed business processes.

The Cloud used in this model can be Public, in which case, the security of Client data and documents are the responsibility of the Operator and this delegates it to the data center providing IaaS and PaaS services.

However, many customers prefer their data and documents remain on their own servers, whether they installed internal (on-premises) or external (Private Cloud), thus the need to operate models Hybrid Cloud appears as a mixture of the Public Cloud certain characteristics of on-premises.

In our opinion, the standardization that allows the reuse of process automation solutions for all business customers requiring this type of solution, is the key for this model being sustainable and so successful, achieving significantly reduction of  both CAPEX (CAPital EXpenses) and OPEX (OPerating EXpenses) regarding to others BPM Adoption Models.

 

What is “Cloud” BPM Adoption Model for BPM Processes deployment?

As commented in one of ours recent posts, by "BPM Adoption" we understand the way that some organizations have undertaken to relieve, optimize, automate and outsource part of their business processes, with the ultimate aim of achieving and maintaining the Operational Excellence that ensure them a sustainable competitive advantage.

To simplify our analysis, we have grouped the various strategies of BPM Adoption usually followed by organizations in four archetypal models, which we have called "Process Team", "Cloud", "Consulting" and "BPaaS".

Each model is characterized by the decision organizations have made in terms of the Mode of Development of the automation solutions, differentiating whether they do or plan to do by internal or external means; and the Mode of Operation of such automation solutions, differentiating if they do or plan to do either on internal systems (on-premises) or external (on Cloud or on an external Data Centre).

The “Cloud” model we analyze in this post is similar to the “Process Team” BPM Adoption Model already analyzed in a previous publication, but characterized by customers transferring the responsibility of supporting the service of the automation solutions to an external actor, the IaaS and PaaS provider. This model is described in the next figure:

Under this “Cloud” BPM Adoption Model, we categorize organizations that choose Development Mode internally (as it happens in the model "Process Team"), but progressing to an external Operating Mode of the developed applications, either:

•  In a Public Cloud (served by a data center) or using a cloud BPMS Platform, served by the BPMS Vendor, applying this case in small-medium enterprise or 
• In a Private or Hybrid Cloud or combination of Cloud and on-premises scheme, which occurs more in large companies and corporations.

 

For the basic applications (PaaS) the SaaS (Software as a Service) modality is the most popular option, if the corresponding software vendor provides them this licensing mode.

It appears here a new external actor, the Cloud Services Provider, which operates data centers in which hosts and operates servers; provide SaaS software services (usually no more than operating systems and databases); provides infrastructure of routers, firewalls, load balancers, servers, storage, backup equipment and other necessary equipment; and, moreover, manages the virtualization, high availability, monitoring and 24/7 support, communications and security, both physical and computer, all conveniently led to meet the most demanding SLAs (Service Level Agreements).

This type of services is growing exponentially and already operating in a 100 % "on-demand" and in the case of Public Cloud it has become de facto a "commodity"; first, by easiness of procurement, dynamic and flexible "on-line" management and almost immediate deployability of resources needed to support the client applications and, secondly, by the very high range, very competitive, of which are currently available on the market, leading to a significant cost reduction.

Therefore, under this model they are significantly reduced the system costs, both CAPEX (CAPital EXpenses) and OPEX (OPerating EXpenses), compared with the previous two BPM Adoption Models analyzed in previous posts.

What is “Consulting” BPM Adoption Model for BPM Processes deployment?

As commented in one of ours recent posts, by "BPM Adoption" we understand the way that some organizations have undertaken to relieve, optimize, automate and outsource part of their business processes, with the ultimate aim of achieving and maintaining the Operational Excellence that ensure them a sustainable competitive advantage.

To simplify our analysis, we have grouped the various strategies of BPM Adoption usually followed by organizations in four archetypal models, which we have called "Process Team", "Cloud", "Consulting" and "BPaaS".

Each model is characterized by the decision organizations have made in terms of the Mode of Development of the automation solutions, differentiating whether they do or plan to do by internal or external means; and the Mode of Operation of such automation solutions, differentiating if they do or plan to do either on internal systems (on-premises) or external (on Cloud or on an external Data Centre).

The “Consulting” model we analyze in this post is similar to the “Process Team”BPM Adoption Model already analyzed in a previous publication, but characterized by customers transferring the responsibility of development to an external actor, the Consulting Company.

Then, we categorize under this “Consulting” model to these organizations that choose the External Development Mode, by delegating this responsibility to an external actor having a Business Consultancy, Implementer and/or Integrator profile; and that applies the Internal Exploitation Mode of the developed applications operating them on internal infrastructure and platform resources, just as in the model "Process Team" mentioned above. This model is described in the next figure:

In this “Consulting” model, the main external actor o actors are the Consultant, Implementer and/or Integrator companies contracted by the Client for the execution of the project and, the main project vectors are the business knowledge and the technology skills that have one or more of such companies.

Often the project scope is split between more than one external companies, each of them having specific profiles of the three methodology/technology specialties required: business consultancy, Implementation of automation solutions on BPMS Platforms and integration of these solutions with the corporate applications.

Risk and responsibility for the development of the project are on the external company (ies) side, although the Client follows the project very closely with its own business and IT people.

Some BPMS vendors tread this ground to their distributors (these ones usually called "partners"), making this development work and implementation directly to their end customers, especially when it comes to large companies or corporations or the BPMS vendors are small-mid size in the first stage of their product/business development.

As consultancy companies and, especially, implementers and integrators chosen by the customer to perform the BPM project cannot master all the 400+ BPMS technologies available, the market supplying BPM business consulting and technology services is fragmented by BPMS Platforms.

The BPMS Platform on which to implement automation solutions, is either selected by the customer and from this derive the Consultant / Implanter chosen (either the same BPMS Vendor or one partner belonging to the BPMS Vendor ecosystem) or customer selects the Consultant/Implanter and from this derives the BPMS Platform, among the ones Consultant/Implanter is capable to support (usually no more than two or three).

Under this BPM Adoption Model project costs are very high and often extra-costs appears, either by insufficient prior definition of the project, either by the difficulty of configuring these tools or their functional weaknesses and, in large part, by changes on the initial customer’s thoughts or new process improvement ideas that arise as a consequence of the process optimization exercise done during the course of the project.

Therefore, this “Consulting” model has similar or even higher CAPEX (CAPital EXpenses) and the same OPEX (OPerational EXpenses) than the “Process Team”BPM Adoption Model.

In this regard, we believe that standardization and reusability of BPM automation solutions will be critical issues in the future so that implantation and integration companies could to be more competitive in their BPM projects.

Describing the Process Team BPM Adoption Model for BPM Processes deployment

As commented in one of ours recent posts by "BPM Adoption" we understand the way that some organizations have undertaken to relieve, optimize, automate and outsource part of their business processes with the ultimate aim of achieving and maintaining the Operational Excellence that ensure them a sustainable competitive advantage.

To simplify our analysis, we have grouped the various strategies of BPM Adoption usually followed by organizations in four archetypal models, which we have called "Process Team", "Cloud", "Consulting" and "BPaaS".

Each model is characterized by the decision organizations have made in terms of the Mode of Development of the automation solutions, differentiating whether they do or plan to do by internal or external means; and the Mode of Exploitation of such automation solutions, differentiating if they do or plan to do either on internal systems (on-premises) or external (on Cloud or on an external Data Centre).

The “Process Team” model we analyze in this post could be considered the most "canonical" because the survey, optimization, analysis, development and integration of automation solutions (Development Mode), and its subsequent implementation and operation (Exploitation Mode) is performed with internal resources, both in terms of technical personnel and systems that must support new applications as is described in the next figure:

Under this model, organizations tend to create a team, section or internal department specialized in the functions listed above, regarding the deployment of BPM Processes in the organization.

This team is usually named as CoE "Centre of Excellence" or "Process Team" and traditionally, in a first phase, devotes much effort (from one to three years, depending on the size of the organization) to discover, map and describe the business processes that the organizations are following, often using a BPA (Business Process Analysis) type tool.

This process team uses to depend functionally on the Organization, Quality or Organization and Process Departments, this latter one often is new created department. Rarely the dependency is under the Information Technology Department or equivalent.

This model is often applied to large organizations and corporations whose resources allow them to cope with and to amortize the large cost that represents maintaining said operating unit.

Once the organization has completed their business process mapping then decides the development and implementation of a first automated business process. The main external actor in this project uses to be the BPMS Vendor, and its vector is the BPMS Platform that the organization has chosen for the configuration, development, integration, operation and maintenance of their BPM Processes.

The choice of the BPMS Vendor and its technology is strategic to the customer as it will be captive of them for many years, even decades, and for being so huge the eventual migration costs and time required for a technology change.

That is why organizations that adopt this model tend to opt, among the two or three pure first class BPMS Vendors or, alternatively, generalist market leaders Software Vendors who incorporate BPMS Platforms (usually acquired from third parties) in their value proposition; always taking into account in making their decisions the analysis and recommendations that provide technology analyst like Gartner, Forrester, ...

Automation solutions are developed in a project under the direction of the customer itself, even entirely with internal personal or, most of times, with a mix of internal and external personnel; following in this way the traditional procurement model of IT professionals that is being known as "body shopping" provided by companies called "Consultancy Companies".

In this model, the secondary external actor is the external consultancy company providing the external consultants and technicians, adding value in terms of availability, opportunity and flexibility like, for instance, the easiness of hiring and firing technical staff outside the rigid internal people recruitment patterns that these big organizations and corporations have established.

Traditionally, organizations adopting this model, applications are exploited in Customer's servers, option called "in-house" or "on-premises", this creating an increasing need for investment in equipment and high internal workload, often not quantified or even hidden. From the basic software required side (operating systems, database, BPMS Platform and other complementary applications), it is customary to follow the license purchase and annual maintenance modality.

For all the above reasons, the “Process Team” model is characterized by a high CAPEX (CAPital EXpenses) and OPEX (OPerating EXpenses) and only applicable and sustainable by big organizations and corporations when we talk about massive BPM deployment projects.

 

4 different BPM Adoption Models followed by organizations for the deployment of BPM Processes

By "BPM Adoption" we understand the way that some organizations have undertaken to relieve, optimize, automate and outsource part of their business processes with the ultimate aim of achieving and maintaining the Operational Excellence that ensure them a sustainable competitive advantage.

Our view is that, to go this way, organizations must rely on two master columns:

1.     OPEX (Operational Excellence), BPM and Change Management methodologies, and

2.   A set of technologies that, combined together and integrated with corporate legacy applications, provide efficient solutions to automate its business processes.

For a few years (not more than a decade), organizations have implemented various strategies to make progress towards the adoption of BPM, strategies that we call "BPM Adoption Model" and discussed in this post.

To simplify our analysis, we have grouped the various strategies BPM Adoption Models usually followed by organizations in four archetypal models, which we have called "Process Team", "Cloud", "Consulting" and "BPaaS".

We have based the allocation of an organization to a specific BPM Adoption Model depending on its position in terms of two characteristics that have considered the most essential in relation to this positioning:

1.     As to the mode of development of the automation solutions, differentiating whether they do or plan to do by internal or external means; and

2.     As to the mode of exploitation of such automation solutions, differentiating if they do or plan to do either on internal systems (on-premises) or external (on Cloud or on an external Data Centre).

This dual classification allows us to define the following BPM Adoption Model quadrant:

Obviously, it could happen that a determined organization has applied or going to apply a strategy that, in fact, is a combination of several of the above listed  archetypal models.

Nevertheless, the simplification achieved by segmented the BPM Adoption Model analysis into the four models mentioned in previous paragraphs, will help us better understanding the scenario and to make a qualitative attempt and quantitative description of the situation of organizations in BPM Adoption Model and foreseeable future developments.

We have to keep in mind the fact that many organizations have evolved their initially established BPM Adoption Model depending on the results that they have been progressively obtained and the successive brakes and barriers they have been found along their BPM Processes implementation journey.

IT scenarios before & after OPEX BPM µBPO or from user dependency to control by the system

Although it is really heavy to accept, in fact everybody prefers better not to talk about, after enormous efforts that lasted not less than 30 years, one full generation, and veritable fortunes spent; the day to day operations of most of the traditional business depends, essentially, on what people is doing even manually or manually transferring information from one to another silo of information.

The following figure reflects this typical current scenario:

One could say, OK, no problem: “our competitors are more or less in the same situation”, “we have been very disciplined buying every single new miraculous tool that hardware and software vendors have recommended us, then, we are 100 % automated, really at the technological edge”, “why to change when we are leaders in our market, our sector, our segment, our town, our neighborhood or our “whatever”? 

Remember my words, one day these people will wake-up, have a look at the window and see a Google or Amazon drone knocking at the window glass trying to sell them at half the regular price the product they are so proudly and profitable selling in their close, protected, comfortable niche for years when not decades. 

This is not a nightmare, is just happening quarter after quarter in many different sectors they have been till now feeling fully protected forever with apparently indestructible barriers (distance, taxes, lack of information, human-local service required, language, regulations, size, excellent personal service or whatever, …). What happens that has destroyed this Arcadia? We could easily say: “Is the technology stupid”!

The question is: What do we have to do to compete with business born already 100 % automated? Surrender? Go on vacations? Retire yourself to the mountains? Just waiting this fashion will pass away? Change to another sector not yet under threat … for a while? 

The answer is very easy, innovate in business process automation, fight with the same arms, use your advantages being small flexible, quick deciders, imaginative … 

“But this requires very sophisticated knowledge out of our scope and supposes big investments affordable only for the biggest corporations, …”

Excuses! Look at the next figure:

 

You need only to install an additional technological piece between your current silos of information and your users, the BPM Layer, and make an intelligent use of your business knowledge and innovation skills by continuously applying the OPEX > BPM > µBPO value chain to your operations reducing your indirect personal costs by a 70 % as we resume in this last figure:

“But Sir, to follow your recommendation we would need to buy the different software and hardware pieces, integrate it, contract consultants technicians to develop our BPM applications and support all this infrastructure on a 24/7 level of service but we can’t afford this!” 

Not at all! Go BPaaS (Business Process as a Service), everything served from the cloud paying a monthly fee just for the demanded consumption of the required resources. With no investment at all, no delays, no minimums, no complications, no short-mid-long term compromises, paying on a monthly basis not more than one fourth (< 25 %) of the tangible savings obtained. 

Does it sounds good? Go ahead now! Don’t lose time, remember, a drone is on the way to your backyard, if you allow it to invade your business niche by not drastically improving your operations now, with no delay.

The Paradigm Shift - from Function in traditional organizations to Process in Extended new organizational scheme

Globalization, improvement in communications and the universal availability of mobile devices have boosted a dramatic paradigm shift on the way organizations are acting and on the IT architecture that has to support their operations. 

This change is summarized in the following diagram where we represent the evolution form the traditional pyramidal organization based on the Function assigned to each person to a new extended concept of the organizations where each person is acting in different processes with different roles.

 

In the new extended organization paradigm, internal applications are interconnected with external ones belonging to suppliers, clients and services outsourcing companies; communications are essentially structured and internal and external users are interchanging data and contents in real time from everywhere and being all this constant traffic governed by BPM processes.

The reason for that is clear: the actors in an organization and their behavior has completely changed to an opposite situation as is summarized in the following table:

 

This new paradigm has a big impact on the IT concept and architecture passing from having its focus on assuring the log of transactions to a new main mission consistent on supporting the automation of the procedures; or, in other words, passing from a very “solid” imperative way to manage the organization to a collaborative model that we could qualify like “liquid” or even “gaseous”.