Architettura & Processi

Si è tenuto nei giorni scorsi a Washington un affollatissimo convegno su Architerrure & Processi.

Sandy Kemsley era presente: se volete leggere la cronaca e i commenti sui vari interventi clicate qui

Se volete vedere le presentazioni ckiccate qui

Austin vista con Google Street view

Lombardi Software è a Austin in Texas.

Ecco come si vede la via centrale, Congress avenue, con il nuovo servizio di google Street view.


View Larger Map

Blog dal sudamerica sul BPM

L'attenzione al BPM è ormai un fenomeno mondiale.

Qui il link al blog brasiliano " BPM oggi".

Da notare anche in questo blog il link ai blog di Phil Gilbert e Bruce Silver.

E qui un blog da Caracas, Venezuela

Qui siamo in Cile.

Lombardi Named Overall Leader for BPM

E' appena stato pubblicato los studio di Bruce Silver "BPMS report" con un'analisi dei migliori prodotti BPMS.

Ecco cosa dice Bruce:

"I’ve just finished the BPMS Watch Ratings, a comparative scoring of the 11 leading BPM Suites written up in my BPMS Report series on BPMInstitute.org. Those reports, which are available for free, include
Appian, BEA, Cordys, EMC, FlowCentric, Global 360, Lombardi, Oracle, Singularity, SoftwareAG/webMethods, and TIBCO. I would have liked to get Pega and Savvion - they declined."

Nello studio Lombardi-Teamworks è risultato il migliore prodotto, detto con le parole di Bruce :

"Based on our analysis, the leader whenconsidering a single BPMS for all type of process are Lombardi e BEA"

Qui un'articolo che ne parla.

Se volete una copia dello studio potete scaricarla dal sito del BPM Institute qui oppure chiedetemelo e ve lo invio.

Video-demo di Teamworks6

Qui trovate 5 bei video-demo di Teamworks e Blueprint

http://www.lombardisoftware.com/bpm-software-brochures.php#

 

Buona visione

DRIVEN 2008

La  conferenza annuale utenti di Teamworks si terrà quest'anno a Austin dal  16 al 19 giugno.

Per dettagli e per iscriversi cliccate qui.

Dopo l'annuncio IBM...

Il 7 aprile durante il meeting IBM impact in LAs Vegas IBM ha annunciato  "nuova BPM suite"; eccone un autorevole commento dal blog di Bruce Silver.

Estrapolo alcune delle frasi più interessanti:

...so what is the new offering announced today?  It’s called the “IBM BPM Suite” (look ma, no branding!) and it includes both WebSphere and FileNet (with some Rational and Lotus, as well).  Does that mean they’ve finally integrated the components?  Not really.....

...clearly IBM is interpreting the word “suite” to mean a portfolio rather than an integrated platform...

...one of my biggest complaints about the WebSphere BPM story has been the jarring discontinuity between Modeler and WID - different process metamodels, different data models, different programming models, no roundtripping.....

Se volete leggere la versione integrale del post dal blog di Bruce Silver cliccate qui

Blueprint: screenshot dalla nuova versione

   

Blueprint: nuova versione e 2400 clienti

Nel corso della web conference del 2 aprile Phil Gilbert ha annunciato e presentato la nuova versione di Blueprint e ha comunicato l'attuale numero di clienti: 2400 con 5 utenti ognuno in media.

Le novità più salienti in Blueprint sono:

• Possibilità di riusare processi come sotto-processi
• Nuove funzioni nel disegno dei diagrammi
• Import da Microsoft-Visio

Per accedere a Blueprint (gratuitamente) cliccate qui.

News da Lombardi

Il 2 aprile la Lombardi ha organizzato una web conference aperta agli analisti per presentatre le ultime novità.

Sandy Kemsley era presente e ne ha scritto nel suo Blog qui

BPM sorpassa SOA

Un recente studio Forrester Research su circa 500 aziende (USA e Europa) ha rilevato che circa il 60% hanno in essere progetti BPM e che altri 19% prevedono di iniziarli entro 12 mesi. Questo 79% ha superato l'analoga percentuale di adozione di SOA.

In un altro survey su 164 aziende (USA e UK) condotto nell'ottobre 2007 più ell'85% delle aziende intevistate aveva in essere o pianificava nei mesi successivi un progetto BPM.

Ecco la ripartizione per settore delle 164 aziende (USA e UK). Notare il 31% di banche e assicurazioni.

Molto interessante anche l'indicazione sul beneficio primario ottenuto dai progetti BPM. La maggioranza delle aziende per misurare il successo di progetti BPM utilizza metriche: eccone la ripartizione.

Se volete leggere il report completo mandatemi una mail e ve lo invio.(giorgio.anselmetti@ariannaconsulting.it)

BPM vs WORKFLOW

Una delle classiche domande durante gli incontri con prospect è sulla differenza tra BPm e Workflow.Qui riporto la posizione di Jin Sinur, a suo tempo guru in Gartner e ora Chief Strategic Officier in Global 360.

Many folks that I have talked to in the past think that there is no difference between workflow and BPM. I would like to examine the arguments around this statement. It’s not quite so simple to say they are the same because of the scope of BPM versus workflow, and it’s hard for folks with a workflow history to see the difference.

The Workflow View:

The workflow view says that work does flow in a process, so BPM is obviously workflow. It might be a bit fancier in the technologies that surround and enable process activity, but BPM is truly workflow. Workflow, as a technology, handled the work that was passed from one human to another.

Early instantiations of workflow were software implementations of passing multi-part carbon-paper-laced forms around, (designed before copiers, carbon paper was fused between multi-colored paper copies to duplicate through pencil/pen pressure on the top form), except these forms are now digitized. We have come far and are saving trees now, so content-based workflow is viewed to be the grand-daddy of BPM.

The Workflow Management Coalition (WfMC) is active in BPM, so BPM must be purely and simply “workflow on steroids”. I even used this analogy to avoid the arguments with workflow types.

The BPM View:

I think to say that workflow and BPM are one in the same is a bit outlandish, myself. Yes, work does flow inside of BPM technologies most of the time. It’s not true that work flows when sharing and collaborating within a case folder for knowledge workers because there is no flow. Each worker does their thing on a shared set of information that may or may not have activities completed on them. I think there are two other fundamental differences.

First, BPM is more than work flowing; it’s a practice and a discipline. BPM is a management practice that treats processes as a corporate asset in order to attain the goal of improving business agility and operational performance while staying compliant. Also, BPM is a discipline that employs methods, rules, metrics, practices and software tools to manage and continuously optimize an organization’s activities and processes in light of management strategies, decisions, policies, goals and tactics.

Secondly, BPM is agile, real time, can include deep system activities, and is visible. Workflow does not employ rules and Service Oriented Architecture (SOA), which are essential for running agile activities. In the pursuit of constant optimization (saving as much time and money as possible under a set of changing conditions), BPM employs real time, complex events that can be initiated outside the scope of the process and allows for management to visibly see the effects of work completion and outside activities’ effect on the results.

Bottom Line:

Like it or not, there is an implicit link between workflow and BPM; but BPM is so much more than just “work flowing” AKA workflow. The discipline is going to a level of sophistication that business professionals demand and the technology is much more than workflow. These concepts are connected in the same family as process activity, but workflow is like the “horseless carriage”. BPM is the high performance vehicle for a number of needs.

Potete leggere il Blog di Jin Sinur con i commenti al suo post qui

Workflow vs BPM

Navigando ho trovato una definizione molto carina. La lascio in inglese dove suona meglio:

Workflow is "doing things right"

BPM is "doing the right thing"

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

Da una ricerca sulle Banche di SAP

In an interview with The Banker in September 2007, Thomas Balgheim, the head of SAP's global banking line of business, mentioned the lack of progress in banks' ability to execute on strategy. In the 2007 EFMA/SAP research, 46% of the responding banks said that they believe that their IT systems fall short in supporting the achievement of business strategy. That's a significant increase from 2004, when 36% thought their systems fell short. But banks expect to do better: The 2007 study found that only 6% think that their systems will fall short three years from now.

The 2004 study found that banks had high expectations for their systems at that time, and yet, their dissatisfaction actually increased in the ensuing three years. There are a variety of reasons that might explain that disconnect. For example, we might assume that:

* Banks weren't able to execute as planned.
* New types of customer behavior had a strong impact on the services delivered by the banks, which required banks to adjust their IT support.
* The market environment changed more, and in more unexpected directions, than banks thought they would.

Looking at banks' actual situation in 2007 and their plans for 2010, the research shows that:

* Banks think that the gap between expectations and reality will largely disappear due to recent adjustments to IT services.
* The momentum of market development could be built into the business strategy on top of the 2004/2007 gap resolution.
* Preparations made between 2004 and 2007 have not yet contributed to IT service, but should do so in the 2007-2010 timeframe.

Meanwhile, IT is being called on to support business targets that have changed, and continue to change. For example, banks now tend to see cross-selling as key to growth, as opposed to the past emphasis on mergers and acquisitions. Customer-focused strategies aim to understand and manage customer behavior and the customer's perceptions of the bank, which supports cross-selling, retention and new customer acquisition. These factors have helped bring analytics and business warehouse support to the forefront-something that wasn't widely foreseen in 2004. Banks are also interested in the synchronization of customer engagement across different channels, which requires the reduction or elimination of siloed data management.

The research also provides a sense of what banks need to do to support their business goals, and to keep the gap between IT expectations and reality from growing larger. For example, it seems clear that strategies built entirely on in-house systems don't guarantee competitive advantage. Meanwhile, standard applications are less cost-intensive in terms of development and maintenance, and can typically be implemented fairly quickly. They also don't tie up as many internal resources, so banks can focus more on innovation. Most of the respondents said they are open to using standard software, especially in human capital, supplier management and financial processes.

As they consider these issues, banks should look at the experience of other industries that have made the transition to standard software and used it to achieve greater efficiency while preserving the ability to create competitive advantage. Banks face significant and growing IT issues, and the lessons learned in those industries could help them move more quickly from strategy discussions to execution.

Trend di mercato

Le iniziative per migliorare i processi di business stanno diventando una priorità per manager di business e IT
Quello del BPM è un mercato in forte crescita: IDC stima che tra il 2006 e il 2011, il suo valore aumenterà di dieci volte, passando da 500 milioni a 6 miliardi di dollari. “Ci aspettiamo una crescita rapida del mercato sia a causa dall’ampliamento delle implementazioni vecchie che dalle nuove”, spiega Maureen Fleming, program director for business process, integration and deployment software di IDC.
Dopo il forte consolidamento avvenuto nel 2006 il numero dei fornitori di software di BPM è passato da 150 ad appena 25 nel 2007; e i grandi vendor di software si stanno sostituendo ai piccoli 'pure play' con un'offerta che unisce il BPM a collaborazione, portali, gestione dei documenti, SOA, architetture event-driven e business intelligence.
Il BPM è sempre più usato per gestire processi che abbracciano diverse applicazioni: la ricerca di BEA dimostra che il 65% delle implementazioni di BPM integra tre o più sistemi e il 60% dei clienti completa la prima implementazione in meno di sei mesi.
Tra i fattori critici di successo, indagini di mercato e ricerche sui clienti mostrano che le sfide organizzative - come le politiche interne, la gestione del cambiamento, la mancanza di competenze degli analisti business e l’allineamento organizzativo - pesano più dei cambiamenti tecnici che possono ostacolare l’implementazione BPM.
La principale evoluzione tecnologica del software di BPM è rappresentata dall'integrazione di strumenti di collaborazione e social computing, che permettono agli utenti di partecipare alla realizzazione, gestione e monitoraggio delle applicazioni come mai prima d'ora. Le principali soluzioni BPM supportano oggi funzioni per i processi collaborativi e sociali che oggi sono dispersi in e-mail, documenti e discussioni.
testo ripreso da CW

BPM Basic for Dummies

Che il BPM stia diventanto un fatto assodato è dimostrato anche dal fatto che è appena uscito negli US il libro "BPM Basic or Dummies" .

Sostiene Gartner

"BPM (Business Process Management) is THE big idea for 2008 and beyond.
Why?
Because enterprises that put processes front and center consistently outperform those that don't. They're quicker to adapt to changing business conditions.
They're more responsive to their customers.
And they're seizing opportunities that are lifting revenue and profitability to a whole new place"

TeamWorks in ALLIANZ

Dal summit Gartner di Las Vegas ecco il riassunto dell'esperienza ALLIANZ ,scritto da Sandy Kemsley:

Presented by Tim Rolfing IT Director of Allianz of America Shared Services on how they use (Lombardi’s) BPM. Allianz Life is a 3000-person life insurance organization that’s part of the huge Allianz group of companies.

Their initial drivers for BPM date from 2005:

• The ability to scale efficiently, based on projected increases in premiums and employees.
• Leveraging common processes, since they had a number of duplicate functions due in part to their growth through acquisitions. They also had 500-700 systems that were in use throughout their organization that needed to be rationalized.
• Need for transparency into operations, both to have a view of the end-to-end processes in order to look for areas of process improvement, and for real-time operational process monitoring.
• Employee job enrichment, by automating some of the routine tasks done by people, thereby allowing people to focus on customer-centric activities. This also allowed the human-facing tasks to be done anywhere in the world, certainly a bonus for a company that’s part of a global organization.

They’ve implemented an impressive number of processes in a short time:

• Securities application processing
• Money processing for applying premiums
• Life insurance underwriting
• Survey response tracking
• New (insurance) product implementation, which improved the cycle time to implement a new product from over 50 days to 12 days, and removes IT from the critical path
• Application document search, sort and prioritization within specialty queues to allow SLAs for specific applications to be met; failure to meet the SLAs can result in financial penalities
• Service recovery and customer complaint handling, including some historical analytics to determine if these have detectable patterns, such as product or broker

They have a number of other ones lined up for implementation in 2008

He ended with some lessons for success:

• Look for small processes with significant impact
• Plan for a deployment time frame of no more than 60-90 days
• Keep the first pilot project simple
• Follow an iterative methodology rather than trying to boil the ocean in the first version

They keep the BPM project teams small, and have found a great deal of improved efficiency through their implementations. They have a BPM center of excellence that they use to train the business side. The technical teams have done the Lombardi technical training, and found that the week-long training was adequate for their needs. He wouldn’t talk openly about their vendor selection process, but stated that there were significant differences between BPM products. The business owns the process and maps it down to a specific level of detail (in Blueprint, I believe) before turning it over to IT who “move it over to the BPM tool” — presumably, they’re using Blueprint for modeling by the business, which still requires export/import to get to Lombardi’s TeamWorks execution environment, so round-tripping would definitely be impacted.

Allianz presenta la sua esperienza con Teamworks al Gartner Meeting

Come sapete in questi giorni a LasVegas si sta svolgendo il "BPM Gartner summit" .

Sandy Kemsley sta seguendo in real time le sessioni sul suo blog.

Qui l'intervento di Allianz.

Referenze Teamworks

Progress 'vede' il BPM

Progress Software annuncia nuova versione di Actional, la loro piattaforma ESB/SOA integrata con Teamworks.

leggete qui

Sandy commenta i risultati 2007 di Lombardi

Sandy Kemsley ha pubblicato sul suo blog un commento al comunicato Lombardi sui risultati ottenuti nel 2007.

Da leggere qui

Lombardi annuncia i risultati 2007: +60%

Lombardi Software ha reso pubblici i risultatti ottenuti nel 2007:

• crescita delle revevue rispetto al 2006: +60%
• clienti in più di 70 nazioni

Clienti BPM nelle aree:

• financial services
• manufacturing
• insurance
• healthcare
• domestic and international government agencies
• automotive
• logistics
• retail,
• consumer packaged goods (CPG)
• energy
• technology
• hospitality and leisure

Per saterne di più cliccare qui

Teamwork conquers BPM

Leggete qui una "product review" di Teamworks da parte di InfoWorld.

Oracle acquisisce BEA

Dopo qualche mese Oracle è riuscita ad acquisire BEA.

L'offerta è cresciuta a 8.5 Billion U$ e a questo punto sembra cosa fatta.

Leggete qui cosa dice Oracle sul proprio sito e qui un commento dal blog di Sandy.

Leggete anche cosa ha detto Jin Sinur qui

e qui un commento dal Sole24

Lombardi vince il premio come miglior BPM

Teamworks 6 di Lombardi Software ha ricevuto il premio "BEST BPM of 2007" da InfoWorld.
Leggete qui

Lombardi nel quadrante "LEADER" di Gartner

Gardner ha pubblicato il "Magic Quadrant for Business Management suite 2007 report" con la valutazione di 22 produttori e per il secondo anno consecutivo Lombardi Software è posizionato nel quadrante "leader".

Per saperne di più cliccate qui

Buon Natale e auguri per un prospero 2008

ci ritroveremo a gennaio 2008...

Sante parole!!!!!

Un utente americano:

"While all BPM/Workflow and BPMS products look the same at the surface there are some major differences that you dont get to "experience" untill you really start using the product. Everyone demo's the "Purchase Request" scenario really well, but only a couple of vendors perform so well in real life situations. This has what has prompted us to migrate from an existing BPMS vendor to Lombardi/ Teamworks BPMS"

Nuove brochure Teamworks e Blueprint

Sono disponibili le due nuove brochure di Teamworks e Blueprint.

Trasformare il business con BPM e SOA

Interessante post di Mike Kavitz su come è possibile trasformare il proprio business, mediante l'utilizzo di BPM & SOA, senza dismettere le vecchie applicazioni.

per accedere al post cliccare qui

BPM e Darwin

Sull'importanza del POC

Michael Kavis dal blog della rivista CIO fa delle interessanti considerazioni sul POC.
Eccole qui di seguito:

The Proof is in the Pudding

When evaluating software vendors, make sure that a Proof of Concept (POC) is part of your process. We just completed an intense vendor assessment between three BPMS (Business Process Management Suite) vendors. All three vendors have great products and plenty of successful customers. It wasn't until we entered the Proof of Concept phase when one of them separated from the pack.

In our POC we made the vendors start with a blank screen and build a sample process flow that we modeled on paper. We chose a model that exposed various features and functionalities of the BPMS tools. We where looking for ease of use, how quickly each vendor could complete the POC, and how the tools integrated with our existing .Net services.

What we found is that only one of the vendors could actually complete the POC in the one day event and that same vendor was the only one who could even figure out how to connect to our services. In fact, it was so easy for this vendor that we gave them additional services to connect to and they were able to accomplish that also.

The lesson learned here is you need to do more then just submit and analyze RFI's and RFP's. Vendor demos are not enough either. If we had not asked them to do a POC we would have selected a different vendor who could not easily integrate with our infrastructure. This would have raised our Total Cost of Ownership (TCO) and reduced our ability to improve speed to market.

When it is all said and done, the proof is in the pudding!

Cosa si è imparato dalla prima applicazione BPM

Nel blog di Sandy Kemsley viene referenziato un interesante articolo sulle lezioni che un utente ha appreso dopo aver realizzato la prima applicazione SOA/BPM.
Consiglio di leggerlo qui.