SOA e BPM trend in Google

 

Ecco i grafici relativi alle ricerche e alle news su "SOA" e "BPM "così come evidenziati da Google.Trend

 

 

Interessante anche la provenienza: sembra che in Italia ci sia finalmente interesse per l'argomento.

What's Driving BPM Demand? It's the Economy, Stupid

Riprendo integralmente un articolo di Sandy Kemsley, apparso su "Intelligent Enterprise"

The model-driven approach and new SaaS-based offerings are sparking interest in business process management technology, but the recession may send demand over the top.
By Sandy Kemsley

A few key themes are emerging as the latest drivers of business process management initiatives. First and foremost, model-driven applications are increasingly seen as the wave of the future. Second, software-as-a-service-based offerings are starting to emerge, opening up BPM to midsized enterprises. Third, BPM in a technology that can actually thrive in an uncertain economy.

The Appeal of Model-Driven Approaches
Model-driven architecture enables a platform-independent model of business functionality to be created independently of the underlying technology. Importantly, the modeling environment is geared toward nontechnical business people. This decoupling of business logic and technology lets business people get in on the act of application/process definition since the models are understandable and don't require inclusion of the technical implementation details. But model-driven apps aren't just powerful because business people can create a models; they're powerful because those models can actually be translated directly into executable code, sometimes with only minor technical modifications.
BPM suites (BPMS) are a prime example of a model-driven application; graphical process models are typically created by business analysts using a standardized notational format such as Business Process Modeling Notation (BPMN). That model, similar to a flowchart view of the process, is easily understood by business users, yet it contains enough information to support a relatively painless and swift conversion into an executable process in the BPMS engine. If integration with systems are required, an IT person will likely be
involved to connect specific tasks in the process through Web service calls — often just matching of input and output parameters — but generally little or no code needs to written in order to create an executable process.

At Allianz of America, for example, the business owns the process and maps it down to a specific level of detail before turning it over to IT people who "move it over to the BPM tool" says Tim Rofling, IT Director of Allianz of America Shared Services. Relying on an interative methodology and focusing on small projects with a potentially big impact, the company has managed to implement an impressive number of processes, each within a 60- to 90-day timeframe. Examples include securities application processing, money processing for applying premiums and life insurance underwriting. In a new (insurance) product implementation, Rofling says cycle times to implement new products were reduced from more than 50 days down to 12 days largely because the model-driven approach removed IT development bottlenecks.
Moving to a model-driven approach changes the entire application development cycle: not only do business and IT people collaborate on modeling the business processes, the same model is then used to monitor and manage the processes in real time once they're in production.

BPM and SaaS
Software-as-a-service (SaaS) is no longer seen as risky technology. In fact, it's downright mainstream to the many organizations using systems such as Salesforce.com to manage their confidential customer information.
SaaS is used for a number of reasons: to reduce the up-front cost of systems and the IT infrastructure required to support them, to pilot the use of a system or technology without making a major investment, or to
bypass the long cycle time of a new system implementation within a large organization.
A few BPMS offerings are starting to appear via a SaaS model, with more expected during 2008. In some cases, these are pre-packaged applications built on a BPMS platform. For example, Enkata offers a contact center application based on Lombardi's BPM suite while Lawactive has legal applications built on Metastorm powered
workflows. SaaS-based BPMS platforms are also becoming available, such as Appian Anywhere and Fujitsu Interstage.
Although it's unlikely that most large organizations will use a SaaS-based BPMS platform in the near future, the attractive pricing structure allows small- and midsized-businesses to take advantage of technology that might not have been previously within their financial grasp.

BPM and the Economy
Given the increasingly bleak economic projections for 2008, Gartner and other analysts are predicting a slowdown in IT spending in most categories (although they're still expecting nominal growth in IT spending overall). Bucking this trend, however, will be expenditures on BPM and related technologies, which will be significantly above average thanks to interest in running businesses more effectively and efficiently.
The predecessor technologies to BPM, such as human-facing workflow, became popular in previous economic downturns for precisely the same reason: automating tasks and reducing handoffs within business processes can reduce the headcount required to complete those processes. In fact, until 2002 when the drive for compliance struck most large organizations, improving productivity — either for the purpose of reducing headcount or increasing capacity — was the primary driver behind most BPM implementations. The past three
to four years of economic growth have shifted the focus of many BPM implementations to providing greater agility and visibility into business processes, but increased efficiency is usually assumed to be underlying
benefit of every deployment. As belts tighten, the interest in BPM will swing back to productivity improvement.

Sandy Kemsley is an independent systems architect specializing in business process management, Enterprise 2.0, enterprise architecture and business intelligence.

Il suo interessantissimo Blog lo trovate qui

Vince Lombardi

Tutti sapete che il nome di Lombardi Software è stato scelto in onore di Vince Lombardi, il più famoso allenatore di football (americano).
Per saperne di più su Lombardi cliccate qui al link al sito ufficiale

Qual è il valore della SOA

Il "valore" di una architettura SOA deve essere analizzato con due angolature differenti: valore per il Business e per l'IT.

Riprendo da un blog americano:

Business Value
The business gets value when SOA is used as an enabler of BPM. You can reengineer your process all day, but you need to allow these business processes to communicate with your legacy systems. The business can't wait for IT to blow up legacy applications in order to create new user interfaces with robust workflows under the covers. Instead IT must abstract the legacy layer and make it easy to build composite front end applications that leverage years of investments in the legacy applications. This allows IT to deliver huge amounts of value to the business in a relatively short amount of time using the right tools (BPMS).

IT Value
The value for IT is in reuse and speed to market. As your SOA matures, the amount of reuse grows exponentially. If you architect SOA correctly, you will move from creating services to consuming services. Once you have built a good baseline of abstract services, you can quickly meet the business's demands by assembling business services rather then building them from scratch each time. Think of it as Lego building. If you start with a hand full of white and red Legos that are rectangular in shape, you can create a few nice structures out of them.

Then you add more colors, followed by new shapes (circles, squares, arcs, etc.), followed by custom pieces (parts for trucks, trains, buildings, boats, etc.) and soon you can build an unlimited amount of structures.


The Real Problem
What I see as the real problem preventing companies from successfully deploying and realizing value from SOA is they don't fully understand SOA and they underestimate the amount of change to the culture. So here are the list of non technical issues that will kill your SOA project:

• If you don't align SOA with a key business driver, you greatly reduce the odds that you will ever reap the rewards of SOA.
  
• If you don't include BPM in your SOA implementation, then SOA becomes just another IT buzzword for the business and not an enabler.
  
• If you don't take a proactive approach to change management, resistance will prevail and you will spin your wheels dealing with change (been there, done that).

Key take away
The problem with SOA isn't SOA, it's people. People must understand SOA and the importance of aligning their initiative with a key business driver. BPM is the killer application that can get your business sponsors on board.

Definizione di Business Process

Ecco una bella definizione di Business Process, ripresa da un vecchio libro di Thomas Davemport "Process Innovation: reengineering work through information technology" del 1992 (!)


“A Business Process is a specific ordering of Activities across time, space and participants. A Business Process has a Beginning, an End, and clearly defined Inputs and Outputs and Steps.”

BPM hall of Fame

Bruce Silver sul suo blog sta lanciando una Hall of Fame del BPM e tra le prime nomination ecco il "nostro" Phil Gilbert con questa motivazione

"Phil Gilbert. BPMN’s power comes from the fact that its shapes and symbols are intelligible to business, yet expressive and precise enough to serve as the “abstract” definition of executable process solutions. But lacking support for human tasks, subprocesses, and looping back to previous activities in the flow, BPEL turned out to be an imperfect runtime companion for BPMN. Fulfilling the promise of business-empowered implementation actually required a “BPMN engine,” but no BPMS vendor had one. As CTO (now President) of Lombardi, Phil Gilbert elected to break his own shipping product and build one. That’s either nuts or brilliant, but Lombardi’s Teamworks has emerged as the first and best realization of BPM’s promise of business-empowered implementation based on standards and business-IT collaboration"

BPM in ebraico

Sito sul BPM in ebraico.
Notare il riferimento a Lombardi anche qui.

Buona Pasqua a tutti i lettori

Collegare SOA al BPM invece che il BMP a SOA

Il titolo suonerà un po' strano ma vi consiglio la lettura di queste osservazioni riprese da un blog americano.

"SOA has more traction these days than BPM does. SOA tools are more mature, but they are also wildly technical. If you want to model a process in an EAI or ESB tool, don't expect to share that model with the business. BPMN is a visual language invented by people who like flowcharts.

Clue #1: the business hates flow charts.

There is value in connecting BPM to SOA, but it is entirely possible to do one without the other.

BPM can be performed for reasons that have nothing to do with IT automation. You can focus on improving the processes in the assembly of a manufactured product, or make the manual steps in a paper-based order processing system efficient. However, to truly unleash the power of BPM, you need to get past the biggest hurdle to it's effectiveness: the expensive IT project.

Many Business Process Re-engineering efforts die on the vine because the first step is to create a model for a new business process, and the second step is to change the IT applications that support the existing process. Step 2 becomes expensive and time consuming. The business looks at the return on investment for fixing the process, and the annual cost of making the change to IT, and is unlikely to see any real value in making the change at all.

Connecting BPM to SOA makes BPM work. We can deliver a process change FAR less expensively if it means creating a new composite than if a process change was to drive an altogether new IT system. SOA without the justification of business change is a chaotic and expensive animal that should be killed. In many companies, it has been killed as an expensive waste of time.

The only value we can get out of SOA, in the long run, is if we make the business more agile by removing the obstacle of expensive IT development. We don't need pure SOA. We need BPM+SOA.

Unfortunately, most EAI-based tools are written the other way around. We (tool vendors) expect our customers to build the services first, and then attach them to business processes in a great big flow chart. Head's up. Doesn't really work that way. In that model, the process diagram is the last thing you build. It needs to be first. Without the diagram first, you can "describe" the conceptual services you need, and even build the base infrastructure, but you cannot build the enterprise services without starting from the business process and working toward the service. Seamlessly.

In this paradigm, BPMN is a problem. EAI tools support BPMN as a flow chart (see clue #1 above).

If we will see the BPM+SOA concept take off, it won't be because we decided to teach a million businessmen to read BPMN flow chart diagrams. BPM+SOA will take off when we learn to develop SOA models from the business process diagramming standard that business already uses: the swimlane diagram.

Let me repeat for clarity: we should attach SOA to the Swimlane Diagram, not business process to the BPMN flowchart.

There are already tools on the market that take this approach and many more are appearing. This is the direction that many software vendors, including my own, have been slow to understand.

Cracking this nut will require that we start where the business is, enable a higher level of immediate quality and consumability where the business is, and THEN tie in IT where the services are. Starting where the business is requires a new tool. Building the services will use the existing tools. We are half way there.. ... but only half way there.

Update for clarity: Yes, I know that BPMN allows you to model a swim-lane diagram. Swimlanes are a problem in the EAI space, however, because we didn't put people into the process from the start. In many tools that started from the EAI space, the swimlane is the afterthought and human collaboration semantics are not well managed. This includes things like worklist, notification, team assignment, handoff, ad-hoc routing, and other elements that are typical of workflow tools that do not show up in EAI tools"

Un nuovo modo per fare ricerche su web

Dalla mappatura al BPM

ABILAB ha pubblicato, ottobre 2007, un interessante studio, prodotto dal gruppo di lavoro sui processi bancari, dal titolo "Dalla mappatura dei processi al Business Process Management".

Nell documento sono presentate in modo chiaro, anche se in modo sintetico, le tre fasi evolutive verso l'organizzione della banca per processi.

1. Analizzare per conoscere: la mappatura dei processi
2. Monitorare per capire: misuratori e indicatori
3. Gestire per migliorare: implementare un ciclo di miglioramento continuo

Nello studio hanno anche fotografato lo stato dell'arte del sistema bancario italiano attraverso un survey su 29 istituti (che rappresentano il 52% in termini di dipendenti del mercato).

Ben l'83 % ha in essere un processo di mappatura, in mano, nel 73% dei casi all'ufficio organizzazione, mentre solo 2 banche hanno in essere un progetto BPM.

Il documento presenta poi un analisi della convergenza necessaria tra tool di analisi e tool di automazione e della dicotomia tra user e IT.

Teamworks di Lombardi è la soluzione giusta per abbattere la barriera tra Business e IT e permettere un vero lavoro di Team che può essere la chiave di volta per il successo di una inziativa BPM.

Studio IDC su 5 utenti Teamworks

Leggete qui , delle parole di alcuni nostri clienti, intervistati da IDC, come hanno utilizzato tecniche di Business Process Management per implementare e controllare vari processi di Business e perché è stata scelta la soluzione Lombardi.
I processi implementati e i clienti intervistati sono:

• Improving financial reporting, operational efficiency, and managing rapid growth (Lance Armstrong Foundation)
• Data entry and invoice/billing reconciliation (Aflac)
• Onboarding new hires (Lee Memorial Health Systems and a Fortune 100 bank)
• Managing workflow around digitization of a massive genealogical database (Church of Latter Day Saints)

BANKINVEST: nuovo utente Teamworks

Bankinvest Group, società di Gestione Patrimoniale danese, ha implementato Teamworks per gestire in modo completamente automatico il processo del reporting ai clienti.
L'applicazione è stata realizzata in soli 18 giorni e tra le funzioni che il cliente ha apprrezzato maggiormente figura la "simulazione" e "l'ottimizzazione".

Leggete qui il comunicato stampa.

BPM in ascesa

Ricerche specializzate evidenziano il ruolo trainante del BPM in azienda, confermandone la costante ascesa di mercato.
Leggete qui

Alla buon ora!!!!!

Dall'indagine di ABI Lab, contenuta nel rapporto "Dalla mappatura dei processi al Business Process Management" si apprende che "Gestione dei processi: un obiettivo realizzabile" e che "Le banche italiane riconoscono l'importanza di mappare e gestire i propri processi operativi".

Più avanti è scritto anche "La ricerca ha altresì evidenziato che la ricognizione dei processi tramite la mappatura non sia che l'inizio di un percorso, che può porsi come ambizioso traguardo la gestione della banca per processi."
Sembra veramente che la banche italiane, da buon ultime nel mondo, abbiamo capito l'importanza del BPM e che la mappatura da sola non basta. Speriamo!!!!

Se volete leggere da dove ho tratto le affermazioni di cui sopra cliccate qui

Perchè la SOA ha bisogno del BPM

Kaushal Mashruwala on why SOA needs BPM: “If the world’s biggest-budgeted software vendors really want to have sponsors in both IT and business units, and keep selling software, they need to elevate the role BPM plays in their suites.”

Leggete qui