LeFtOoO

Derek Miers é um dos mais reconhecidos especialistas em BPM no mundo. Participa da especificação de BPMN desde os tempos do BPMI.org, do qual foi Co-Chairman, e mais recentemente atuando junto ao OMG, tendo lançado recentemente o livro BPMN Modeling and Reference Guide. Ele é autor do BPTrends BPM Suites Report, que analisa detalhadamente mais de vinte BPMS, e participa ativamente dos principais congressos mundiais sobre BPM. Mais detalhes sobre a biografia de Derek Miers podem ser obtidos no website do BPM Focus.

Treinamento "BPM Process Modeling Fundamentals"

Com duração de dois dias (16 hs), esse treinamento é ideal para quem está buscando aprender ou aprimorar métodos e técnicas de modelagem de processos, com foco em BPMN e ministrado por um de seus criadores. É um treinamento teórico e prático bastante completo. Mais detalhes podem ser obtidos no website do BPM Focus.

Data: dias 24 e 25 de novembro de 2008.

Local: Sede da FNQ - Fundação Nacional da Qualidade. Av. das Nações Unidas, 11857 - 6o. Andar - Sala Serasa, em São Paulo, SP. Estacionamento gratuito no local. Veja aqui como chegar.

Investimento: valor especial até 31/10/2008: R$ 1.495,00.

As vagas são limitadas. Inscreva-se já através do formulário online e garanta sua participação e de sua equipe.

Treinamento "Developing a Structured Approach for BPM Project Success"

Com duração de três dias (24 hs), esse treinamento é ideal para quem está buscando sólidos conhecimentos em como desenvolver com sucesso um projeto de BPM. Derek Miers apresenta uma abordagem estruturada que contempla metodologia, melhores práticas, desafios e tecnologias que levam um projeto de BPM a ser bem sucedido. Mais detalhes podem ser obtidos no website do BPM Focus.

Data: dias 26, 27 e 28 de novembro de 2008.

Local: Sede da FNQ - Fundação Nacional da Qualidade. Av. das Nações Unidas, 11857 - 6o. Andar - Sala Serasa, em São Paulo, SP. Estacionamento gratuito no local. Veja aqui como chegar.

Investimento: valor especial até 31/10/2008: R$ 2.245,00.

As vagas são limitadas. Inscreva-se já através do formulário online e garanta sua participação e de sua equipe.

Dúvidas sobre os treinamentos podem ser encaminhadas para capacitacao@processmind.com.br.

Inscreva-se já e garanta sua participação e de sua equipe!

Este é meu primeiro post do blog, pretendo falar de assuntos relacionados a BPM (meu trabalho), negócios e tecnologia. Acho que será de bom tamanhoa trocade informações.

Observando tamanha relevância desse assunto, decidi fazer meu TD (trabalho de diploma) sobre SOA, juntamente com Leonardo Alvarenga Garcia e Thiago Felipe de Melo Matias, sob orientação do prof. Enzo Seraphim. Assim a gente tem contato com o assunto e podemos aprofundar um pouco o nosso estudo anteriormente esparso.

Mas o que é SOA?

Não se desiluda, mas isso não se responde direamente, tipo SOA é isso e ponto final. A resposta não é única, não é formal, não é concreta... A gente também queria achar essa resposta assim mas não rolou... :(

Se você procurar vai achar várias definições diferentes, e te digo que todas devem estar corretas: modelo arquitetural, estratégia para aliar negócios e TI, filosofia para integração de sistemas de software, infra-estrutura para comunicação entre sistemas de software, padrões para reutilização de sistemas de software etc....

Bem, nós estudamos um pouco, lemos uns livros, revistas e artigos, e escrevemos uma singela explicação em nosso TD:

A dinâmica do mundo dos negócios exige que as organizações de TI sejam ágeis, flexíveis e simples. Para promover comunicação nessa verdadeira Torre de Babel que tornou-se a área de TI, a Arquitetura Orientada a Serviços (SOA - Service-Oriented Architecture) propõe organização dos ativos de software de forma que eles possam representar Processos, Atividades ou Tarefas de Negócio de forma direta. Tais representações são chamadas de Serviços, que devem ser baseados em padrões e facilmente combinados e reutilizados visando a satisfação dos requerimentos do negócio.

Pensamos que fazer um trabalho acadêmico fosse algo muito desafiante, pois SOA está imerso no mercado de negócios e não no mundo acadêmico. No entanto, nosso grupo vislumbrou certas possibilidades de aplicação de SOA para propósitos que tenham respaldo acadêmico, entre elas a área médica, que nos chamou a atenção.

O nosso trabalho tem por objetivo apresentar o desenvolvimento de uma SOA que contemple a implantação simplificada de um PACS (Picture Archiving and Communication System) de um hospital, com a implementação de serviços para recuperação de informações em sistemas HIS (Hospital Information System) e RIS (Radiology Information System), objetivando obter o serviço de radiodiagnóstico, que pode ser utilizado por exemplo para obter um diagnóstico de mamografia mais rico.

Para tal estudamos conceitos sobre serviços, BPM (Busines Proccess Management), WS (Web Services), ESB (Enterprise Service Bus) e governança SOA. A revisão bibliográfica está quase pronta e será postada aqui em breve.

Nós apresentamos o seguinte pôster sobre o nosso trabalho no I Composium em 23 de setembro na UNIFEI:

Pôster TD - I Composium

Para quem quiser se aprofundar no assunto, recomendo as seguintes leituras:

• OASIS. Modelo de Referência para Arquitetura Orientada a Serviço 1.0. 2006. 33 p.
• JOSUTTIS, N. M. SOA in Practice - The Art of Distributed Systems Design. 1. ed. O'Reilly, 2007. 342 p.
• ERL, T. Service-Oriented Architecture: Concepts, Technology, and Design. 1. ed. Prentice Hall, 2005. 792 p.
• PULIER, H. T. E. Understanding Enterprise SOA. 1. ed. Manning, 2006. 280 p.

Desde então tenho lido e pesquisado sobre SOA e estou aprendendo. Quem quiser trocar idéias a respeito disso, por favor entre em contato :)

Inté!

Let us first make clear what BPM SaaS is not. First, the ability to run a hosted version of one aspect of BPM is not BPM SaaS. BPM is a combination of applications used by different stakeholders. Offering only one of these in a hosted, subscription-based model is not SaaS. For example, offering process modeling tools in a subscription-based hosted model is “process modeling software-as-a-service”; it is not “BPM software-as-a-service.” However this would be a very good first step towards BPM SaaS which can offer customers as well as vendors not only the benefits of SaaS but also the experience necessary to move towards full-fledged BPM SaaS. Second, creating customer-specific automated processes and then enabling the end-users of the customer to participate in the process using a browser/Internet is also not BPM SaaS. There is nothing new about this and customers and vendors have been doing this ever since the early days of the Internet.

In my judgment BPM SaaS has to have the following characteristics as a minimum. First, it must have the ability to model and modify executable processes in a hosted application. The ability to design executable processes, in contrast to simple flow diagram, is pretty challenging. Many vendors will start by offering pre-designed process templates and then allowing users to modify them in a hosted model. This is a good way to start and over time an increasing number of parameters (rules, flows, user interfaces and integrations) can be exposed to modification by users. Second, BPM SaaS must have the ability to allow customers to integrate with their inside-the-firewall data and other applications. This is crucial because BPM deals with company’s data and interacts with other applications. Without effective integration only the very simplistic BPM processes are candidates for SaaS, and CxOs are reluctant to invest money or mindshare on simplistic processes. Integration is the Achille's heel of BPM SaaS and solutions for this will evolve only gradually. Perhaps the best approach for BPM vendors is the emerging class of “application appliances” that leverage virtualization technology to deliver inside-the-firewall solutions on a SaaS basis. This has the potential of solving the integration problem. I will discuss it in another blog as this is a topic on its own. Third, and easiest, is the ability for end-users to participate in business processes using a browser. This is easily accomplished by most vendors and the growing using of AJAX and Rich Internet Application (RIA) technologies will make it even easier and richer for end-users. Fourth, BPM SaaS must provide a means for customers to monitor and administer their processes over the Internet. Again, with the emergence of AJAX and RIAs, this is not a challenging obstacle. And fifth, BPM SaaS must provide some web-based reporting, BI and BAM capabilities.

With these five capabilities, BPM SaaS can empower customers to design, integrate, deploy, use, administer, monitor and measure their business processes. It provides the full value-proposition of BPM in a SaaS model. Vendors will move towards this in small steps and the more agile ones, who adopt SaaS and new technologies such as RIAs and application appliances, will have the competitive and time-to-market advantage. The key challenges are modeling/design of executable processes and integration. I will use other blog posts to elaborate on likely approaches to tackle these challenges.

Dá certo e quase sempre é mais rápido.

Muitas vezes me pergunto se é mais fácil implantar a gestão de processos em grandes organizações ou em pequenas e médias empresas (PME). Apesar de haver prós e contras nos dois cenários, depois de já ter realizado projetos para empresas de diferentes portes e segmentos, acredito que os resultados aparecem com maior rapidez e eficácia em empresas de menor porte.

Entre as vantagens dos programas de processos em PME, posso citar:

1. Agilidade na Tomada de Decisão: a gestão de processos depende sempre que haja uma priorização dos trabalhos e das implantações das melhorias nos processos. Na PME o acesso direto a alta direção faz com que esta decisão seja tomada rapidamente, sem a necessidade de diversas alçadas de aprovação e diversas reuniões de validação e consenso. Da mesma forma, as mudanças de rota, caso as coisas não estejam dando certo, também é feita de forma bem ágil.

2. Autonomia Corporativa: normalmente a PME não precisa se reportar a nenhuma matriz ou holding para aprovar novos projetos em processos. A decisão é tomada diretamente pelo dono da empresa, desde que este esteja consciente dos benefícios que a gestão de processos pode trazer.

3. Menor Existência de "Feudos": as áreas de uma empresa de menor porte se comunicam de forma mais ágil e dependem muito mais umas das outras. Ao iniciar um trabalho de processos, esta maior interação facilita muito o mapeamento e implantação dos processos e diminui a resistência à mudanças.

4. Facilidade na Mudança de Cultura de Trabalho: contando com uma força de trabalho menor, na PME conseguimos envolver todo o corpo de colaboradores em um espaço de tempo menor com atividades de mapeamento e treinamento em processos, por exemplo. Torna-se mais simples também mostrar para as pessoas a visão dos processos multifuncionais que cruzam toda a empresa e, assim, quebrar as barreiras que existem entre as áreas.

Por outro lado, podemos citar também algumas desvantagens no cenário das PME. Sabemos que na PME a capacidade de investimento é menor e precisa ser bem controlada, o que pode atrasar a implantação de algumas mudanças. Além disso, possuindo uma força de trabalho menor, também o tempo das pessoas é escasso para poder se dedicar a gestão de seus processos. Este acúmulo de atividades, porém, já é uma realidade também nas grandes empresas.

Com este argumentos, não quero dizer que não existam casos de sucesso de implantação da gestão de processo também em grandes empresas. Existem e são bem relevantes. Entretanto, me atrevo a dizer que a incidência é maior em empresas menores. De qualquer maneira, independente do porte da empresa, sabemos que o caminho para o sucesso não é simples e exige bastante dedicação e persistência dos que estão envolvidos no programa.

E você ? O que acha ? Qual sua experiência em implantação em pequenas e médias empresas ? Comente.

L’azione di oggi prosegue il censimento dal basso degli stabili abbandonati che consegniamo pubblicamente al Tavolo sull’emergenza abitativa promosso dal prefetto Mosca.

L’unica sicurezza possibile è quella che allarga i diritti e gli spazi di libertà per tutt@, non è certo la guerra contro i poveri scatenata dalla destra e dai sindaci-sceriffo di centrosinistra. La militarizzazione del territorio serve soltanto a zittire ogni forma di dissenso e di conflitto sociale, mentre la crisi economica colpisce i diritti acquisiti e ruba il futuro alle nuove generazioni.

Nel giro di poche settimane è caduto il bluff del sindaco Alemanno e della sua giunta che si è inchinata agli interessi dei costruttori e della speculazione. Il Piano casa del Campidoglio regala demanio pubblico ai privati, non blocca il caro affitti e i mutui selvaggi, e seppellisce definitivamente ogni idea di edilizia sociale pubblica.

Anche in questo quartiere, troppi studenti e studentesse sono ricattati da affitti da rapina e in nero che garantiscono ai proprietari di casa enormi profitti. Oggi diciamo basta.

>>>Unders/Blocchi Precari Metropolitani/Horus Occupato

En este artículo desarrollaré los siguientes tópicos: Características del BPX y Razones de la necesidad del BPX.

Características del BPX
El BPX es un profesional que por una parte es experto y conocedor de las enormes implicancias de los requerimientos de un proceso de negocio [2] sobre la performance, volúmenes de datos, tráfico de la red, infraestructura computacional y criterios para seleccionar las tecnologías adecuadas como ser: sistemas, interfaces, plataforma de aplicaciones, seguridad, etc.

Por otra parte un BPX es una persona que entiende los procesos de negocios, la estrategia organizacional y los sistemas legacy, de modo que canalice la innovación en la introducción y uso de las mejores prácticas –best practices- que van más allá de los límites naturales de un área o departamento. El BPX necesita estar enterado de la historia de su organización, de su cultura y de la política interna.

Dadas las razones descritas en los dos párrafos precedentes, se dice que el BPX necesita habilidades soft y hard , esto es necesita ser conocedor de la terminología de los negocios y de la tecnologías informática, como también debe poseer un conocimiento profundo de la disciplina del modelamiento de procesos.

Requerimientos Básicos

• Arquitectura Se refiere a la estructura de los procesos de negocios y en particular trata del entendimiento de la enterprise SOA. La arquitectura provee la visión holística del proceso de negocios.
• Modelamiento, Es la capacidad de describir todos los aspectos de un negocio en un lenguaje descriptivo que permita eficientemente generar los procesos administrativos y sistemas informáticos que den el sustento operativo para tener un negocio eficiente.
• Procesos de Negocios End-to-End, Conocimiento detallado de los procesos de negocios tales como: Venta, Servicios, Producción, Logística, Contabilidad, etc.
• Experiencia, se refiere a que un profesional recién graduado no califica para el rol BPX, se necesitan personas con varios años de experiencia profesional, idealmente en distintas industrias o distintas áreas de una industria.[3]

Requerimiento Adicionales

• Sistemas, Se refiere a los sistemas que cubren las distintas necesidades de un negocio, como ser los sistemas transaccionales como los ERP, CRM, SRM, base de datos, etc, Los sistemas para cubrir demandas analíticas como data warehousing, data mining, análisis estadístico, etc. Y, los denominados sistemas de soporte: portales, mecanismos de integración, master data, gestión del conocimiento, etc.
• Aplicaciones y Herramientas de Modelamiento, se refiere a conocer mecanismos para modelar, generar programas, gestionar proyectos y en general herramientas que contribuyan a la implementación de los procesos de negocios.
• Habilidades Comunicacionales, son fundamentales para poder establecer vínculos de trabajo adecuados con los niveles gerenciales y operativos de las áreas de negocios, con el personal del área informática y con los proveedores de servicios.
• Liderazgo, dado que la función de BPX esta directamente ligada a la innovación es indispensable la capacidad de liderazgo para mover a la gente a utilizar nuevas prácticas de trabajo.

Gráficamente SAP platea la siguiente evolución:

Razones de la necesidad del BPX

La agilidad es el equivalente a éxito en el hiper competitivo mundo de los negocios, y esta se manifiesta por medio de la innovación en los procesos de negocios. La velocidad para generar nuevos procesos de negocios requiere de una capacidad de comunicación y trabajo en equipo ente las áreas de negocio e informática, aquí esta el origen de la necesidad de contar con el BPX:

Históricamente las comunicaciones entre las áreas de negocios y la de informática ha sido marginales – en el mejor de los casos- y beligerantes en el peor [4]. Esta tradicional incomunicación es la causa de la lentitud en la innovación en los procesos de negocios, y del desalineamiento de la estrategia con la tecnología informática. Se pretende que el BPX ayude a superar esta situación.

El desarrollo de la Arquitectura Orientada a los Servicios –SOA- desde la programación orientada al objeto ha significado que el diseño de sistemas necesita ahora un nuevo enfoque y en consecuencia profesionales con una nueva combinación de habilidades y conocimientos. [5]

Este tipo de profesional es impulsado fuertemente por la necesidad de implementar procesos de negocios utilizando nuevas plataformas informáticas, en particular tenemos el caso de SAP que ha creado la BPX Community, donde se ha desarrollado ampliamente este concepto, al punto que ya existe una certificación BPX.

Referencias

[1] Business Process Expert http://en.wikipedia.org/wiki/BPX

[2] § Proceso de Negocios http://msaffirio.wordpress.com/2006/05/07/bpm-business-process-management/

[3] Business Process Expert, Mario Harger, http://www.sapdb.info/wp-content/uploads/2008/07/business-process-expert-part-3-what-are-the-skills-and-tools_.pdf

[4] The Rise of Business Process Experts, Sam Sliman, http://www.optimalsol.com/NE-Thought-The-Rise-of-Business-Process-Experts.html

[5] SOAs may spawn “Business Process Experts”, Kathleen Lau, http://www.computerworld.com.au/index.php/id;2146667244

Paper may never go the way of the Dodo bird. However, there are solutions that can help bring your office a few steps closer to the "paperless dream". I recently found read an article on Forbes.com describing how small or mid-sized business may find it easier to make the transition (Here is the link to the article).

Here are a few bullet points to consider:

• Small and mid-sized businesses have advantages over lager businesses when it comes to moving to paperless. There is less bureaucracy. They can be much more nimble with their IT projects.
• Electronic is faster. Accounts payable invoices may require several weeks to process. Especially, if the invoice needs to be approved before payment or a discrepancy is found against the purchase order. Shuffling paper takes time. An electronic process can reduce the lifecycle of the payment process.
• Don't forget about security. A document scanned and password protected on your server is much more secure than sitting on your desk.

Bruce Silver asked the question, "What do you really need for model portability?" He points to four key principles:

1. Assignment of MUST-SUPPORT requirements to a subset of flow elements and semantics.

2. The rules for the serialization must be precisely defined.

3. BPD validation rules.

4. There should be some facility for testing compliance and for publicizing tools that meet the requirements.

This is all good common sense.  For #1, we remember that BPMN is designed to be "Methodology Agnostic".  This means that there are a variety of different shapes and symbols, the meaning of which is clear, but are not necessarily all required to implement a particular method.  This agnosticism is absolutely essential to the broad adoption of the standard, but it flies in the face of model interchange.  Since the BPMN dictionary includes a wide range of symbols for any occasions, it is neither expected nor reasonable to expect all tools to cover all cases.  Studies are being done today at the Department of Defense and universities on what symbols are needed most often, and what can be left out.  We know that some symbols are redundant, and that there are multiple ways to do things.  It is critical then that the standard specify a MUST-SUPPORT subset, which represents the least common denominator of all process modeling programs.

Items #2, #3 and #4 should not be controversial.  The definition for serialization must be reduced to a form equivalent to programming logic, with all ambiguities removed.  If there are ambiguities, it means that different packages might interpret the parts differently, and you will fail to have portability.  This goes hand in hand with validation rules.  And if you are going to specify this precisely, you might as well provide a validation facility, at a very minimum to prove that the specification is complete enough to produce such a test.  In many ways, if this validation program does not exist, then the specification is "untested" in any real sense.  I am not from Missouri, but I still want to see that such a program exists, before I believe that it is possible to build one.

Comments on his post suggest that this goal might have to wait for BPMN 2.1.  If you release a serialization spec that is ambiguous without formal validation criteria, then you are inviting vendors to implement it, and risk the very real possibility that when the validation rules are finally published, that their original interpretation might be wrong.  There might be multiple products out there that interpret the ambiguous aspects differently, and no matter what you do, some of them are going to "lose".  It is even worse for consumers: you might designing processes and save them in a format which ends up being a dead end.  It seems strange to be suggesting that you wait for 2.1 before 2.0 is even out.

Making a solid standard that will stand the test of time is hard work.  I applaud the goals of the BPMN group to attempt to make something better than has existed before, but going only half-way to a broad scope can be worse than nothing at all.  It is certainly less attractive than doing a good job on a diminished scope.  Bruce ends his post in a resigned tone: "I have no expectation this would ever be in the BPMN 2.0 spec.  But I can dream."

And so we all must dream.  If you know someone involved in BPMN work, please ask them about what is being done to insure BPMN "Model Portability".  And then ask them to prove it.

But I'm not very good at web development and this was almost my first Ruby on Rails application. Time passed, I worked a lot on Ruote-Rest, a Ruby web application based on Rack (not Rails). Ruote-rest is meant to be consumed by HTTP clients that are not browsers, you could say it's a RESTful webservice.

It is time for a second take at Ruote-Web. I started with a Rails plugin for easy integration of Ruote into a Rails application, it's simply called ruote_plugin. It provides at first migration generation (workitem storage mainly, but also engine persistence via ActiveRecord instead of the filesystem if necessary) and then helper scripts for installing the engine and its dependencies under vendor/plugins/ or as gem.

The next step was building ruote-web2 on top of the ruote_plugin. Let's note that the initial implementation of a "ruote plugin" was done by Tomaso Tosolini (who also wrote the rdbms based persistence for the process engine, Thanks a ton Tomaso !).

Ruote-web2 is way simpler than ruote-web, and it adheres to the resource structure laid by ruote-rest. It adds user and group resources though. For the user resource I didn't look very far, I used the ultra-classic restful-authentication.

This will be an interesting packaging of Ruote for people of want to "just replace the Ruote logo and place theirs" to benefit immediately from a simple and robust open source workflow engine/suite (I'm quoting someone in the community for the "just replace the logo" thing).

Ruote process definitions can be expressed as XML, Ruby and now even JSON (or YAML if you push). I plan to integrate process definition tinkering into ruote-web2 (as I did in ruote-rest) and maybe more. That should mean edition of process definitions in the process portfolio and edition of definitions of processes in-flight (already implemented in ruote-rest).

The hardest part part of this implementation work is the QA, not only the classical QA but also the QA triggered by this goal : I'd like to have the same (RESTful) interface for ruote-rest and ruote-web2. The "connectedness" aspect deserves a big share of the design (and then QA) work.

Ruote-web2 is more perhaps "ruote-rest on Rails" than "ruote-web take 2". There is a consequent amount of work left, but I'll probably be done in three or four weeks.

It's open source after all, so here are some links to the source of these tools :

http://github.com/jmettraux/ruote_plugin
http://github.com/jmettraux/ruote-web2

http://github.com/jmettraux/ruote

And finally to the mailing list :

http://groups.google.com/group/openwferu-users

Organisations need to change their focus from being functionally driven to being process driven to be really successful in their adoption of BPM. This is not always as hard as it first sounds.

Most of the organisational and technical building blocks almost surely already exist within the organisation in some form or other. The challenge is to align them together in a consistent and continuous way i.e. using business processes, a BPMS  and ensuring that cultural and human behavioural changes are well managed.

Paraphrasing Gartner, the typical characteristics of functional driven organisations include the following:

• Organisational roles and responsibilities are functionaly aligned
• Managers have visibility that is limited to their functional areas
• Business is very dependant on IT to schedule application changes
• Functional tasks and process hand offs are implied causing fragmentation
• Costs are managed by functional area
• Risk management is done using gut feel and relies greatly on experience with limited numeric evidenece due to lack of integrated and trusted reporting information

The organisational characteristics for a process centric organisation typically include:

• Roles and responsibilities are aligned to process acitivities
• Management visibility is based on an end to end business process understanding
• Business is less dependant on IT for small changes to business rules and process tasks
• Functional tasks and process hand offs are explicit, therefore reducing the occuraence if inefficient and broken processes
• Risk management is done using operational metrics and simulation ensusing a proactive approach rather than reactive

So what's the problem? Traditional development works, doesn't it?
 
IT always has the undesirable position where it has to be responsive to business needs but not negatively impact Business as Usual operations or exceed its operational and development budgets.
 
In most organisations IT infrastructure largely consists of a plethora of silo applications on various types of technologies. They form islands of information and functionality which in many cases are duplicated. These types of applications are required to solve specific departmental and functional requirements but not flexible and easy to integrate with each other in a consistent and repeatable way.

Integration on this scale is an expensive and complicated issue due to the fact that information is duplicated in systems, and the points of integration and maintenance increase exponentially for any new application added. In addition, doing integration in this ‘point to point’ way means changes to one interface can impact other applications and the wider business in unforeseen ways. This directly increases business risk, delivery risks, costs and the need for ongoing expert skills for any new or existing IT projects.

Traditional application software development practices and the integration of silo applications are generally a challenging and costly exercise for the following reasons:

• Requirements’ gathering is a long and intense process and can be very labour intensive due to the complexity and variety of application impacted for any single project.
• Many times a detailed design has been completed, a project started but the business may have already moved on and therefore has different priorities requiring changes to the original design.
• Armies of developers are the norm for traditional development scenarios due to the fact that various application specific skills are required to develop and maintain the plethora of diverse applications and technologies.
• Integration of silo applications are typically application specific i.e. proprietary rather than open standards based. This makes reuse a problem and long term maintenance/enhancements difficult due to the ongoing need for specialist external/internal skills.
• Integration is point to point and is devoid of the business process context i.e. it is done based on a very low level technical view of the capabilities of the product(s) rather than using the business processes to define the final solution.
• Silo application enhancement projects typically have no end. The solutions delivered have very little potential for reuse as they are inflexible, brittle, restricted to the features and functions that are part of a specific release and inherently create islands of data that is not easily accessible by other systems or users.
• Data can’t be normalised due to it being held in the individual applications data repository. This has a huge impact on being able to reduce data duplication and data availability for consistent reporting purposes.
• Data errors are more common as data can’t be categorised to identify what is master data and what is not. This means that inconsistencies are all too common and leads to people not trusting corporate systems and the well known Excel spreadsheet database becomes the norm.

So what the answer?

Process automation and more specifically a Business Process Management System (BPMS) is the solution that will help alleviate and solve many of the business and technical problems described thus far.

Long and short term benefits can be gained by using business process automation as the common way to understand the business, solve tactical business problems and integrate departments, divisions and core systems in such a way to deliver realisable and measurable business value.

Using a BPMS will give an organisation the ability to build and deploy sustainable and targeted solutions in very short timeframes, using less development resources than traditional development projects. It has the ability to integrate into existing silo applications, data bases using open standards and various other integration capabilities.

This approach is based on the premise of starting small by identifying a key business pain, understanding the value it will deliver and solving it using a project based delivery technique. Longer term, as each new individual projects delivers value, a natural momentum is created and therefore this low risk and high value approach can be used as a vehicle for organisational and behavioural transformation.

Where to start?

Many opportunities exist in an organisation to start delivering business process related benefits. Some of the more obvious processes are those that relate to:

• Finance - Purchasing, Time Sheets, Expenses Claims
• Sales – Bid Management, Sales Pipeline Management
• Customer Relationship Management - Customer Help Desk
• Human Resources – Starter, Movers, Leavers, Self Service processes
• Project Management – Project start up, document approvals, time tracking etc.
• IT Operations – ITIL processes, IT Help Desk

The benefit of choosing any one of these processes is that it will create the ability for the business to become more in control of their ability to drive business change rather than be reactive to changes placed upon it. IT will have more flexibility to integrate existing systems that deliver solutions in line with business needs and end user expectations.

As new iterations of the same process or new processes are brought onboard, a momentum is created and what started out as a tactical solution becomes a strategic and dynamic process platform. In addition, the various systems that are currently used to deliver a silo capability to the various functions inside each of the organisations divisions can be exposed to other divisions (if appropriate) and therefore improve IT reuse and drive consistent working practices across the wider business.

Taking an incremental and iterative approach ensures that value is delivered while recovering any cost that may have been made in terms of an Enterprise BPMS Platform.

This work is licenced under a Creative Commons Licence.

Contemporaneamente circa 400 famiglie del Coordinamento cittadino lotta per la casa e del Comitato Obbiettivo Casa hanno occupato l'assessorato alle politiche della casa contro la mancata consegna di 246 alloggi popolari già assegnati nel quartiere di Ponte di Nona. «Ci opponiamo, inoltre, all'intenzione manifestata da Antoniozzi di rimuovere l'occupazione dell'ex-ospedale Regina Elena» sostengono i movimenti «simbolo di una volontà politica di sgomberare senza risolvere il problema». In tarda mattinata i rappresentanti delle famiglie hanno presentato le proprie richieste al direttore dell'Ufficio interdipartimentale Casa del Comune Raffaele Marra e al Vice Capogabinetto Tommaso Profeta che hanno strumentalmente assicurato la loro disponibilità ad inviare una lettera all'Ater per sbloccare entro lunedì l'assegnazione degli alloggi a Ponte di Nona e fissato un tavolo di trattative con i movimenti per il 2 Ottobre. «Aspettiamo questa data che dovrebbe definire nuove assegnazioni» dichiara il consigliere comunale Andrea Alzetta presente all'incontro, che ribadisce come «non accetteremo inerti lo sgombero del Regina Elena senza l'assicurazione di una politica abitativa che soddisfi le richieste dei nuclei familiari che vi abitano». Nella giornata di mobilitazione per il diritto alla casa di ieri i movimenti hanno sbloccato una situazione in fase di stallo dall'11 Aprile.

Per l'ennesima volta i movimenti hanno dimostrato di agire nell'interesse di tutta la Città, anche di quella parte che vuole criminalizzarli: «con questa occupazione - spiegano dal Coordinamento - abbiamo infatti permesso a duecento famiglie romane di poter finalmente entrare nelle abitazioni che spettano loro visto che sono solo 40 i nuclei familiari presenti nelle nostre liste che beneficeranno di questa decisione».

Ylenia Sina

1)Diagramador de procesos
Sirve para generar los diagramas con una interfaz sencilla, usable e intuitiva, que hace que visio se vea por momentos mal,este diagramador genera código al cual se le pueden asignar pantallas siendo exportables al servidor de procesos.

2)Servidor de procesos
Esta es la aplicación a la que se suben los procesos generados con el diagramador.

3)Servidor de flujos
Aqui es donde todos esos diagramas, flujos y ese trabajo de backend cobra vida,es la aplicación donde accede el usuario y puede ver todos los procesos en los que el esta involucrado, si tiene tareas pendientes,¿quién le esta atorando el trabajo?,¿a cuántos le está atorando el trabajo? y ¿cuanto se tarda en hacerlo?, una chulada!!!

Pero aqui no acabo todo, como administrador puedes ver todos los procesos que se estan corriendo y ¿qué procesos se estan atorando?, ideal para detectar cuellos de botella o a Juanita la " not my job".

Así es que si tienen oportunidad, implementenlo Intalio
Solo recuerden que no se puede hacer un sistema si no hay un proceso, si no van a sistematizar el desmadre y contra eso ni con Peter Senge,Steve Jobs y Chuck Norris entrenado por Yoda

I went to listen to a number of sessions, spoke to a few participants and tried to connect with some more analysts. I could not get hold of Kyle McNabb, but after a phone tag game with Connie Moore she found me sitting there a bit forlorn. I had one key question for her: 'How do you see the current rigid flowchart BPM model evolve, especially in the light of content and rules integration?"

Connie Moore's answer suprised me: 'I don't believe in rigid process models.' So we ended up discussing the Forrester concept of Dynamic Business Applications that focuses on 'Design For People. Build For Change.' I feel that DBA is very close to what we offer with the Papyrus Platform. She said that most BPM vendors are unhappy with Forrester's segmentation of the BPM market into integration, document and human centric process management systems, but that at least gives businesses some way to understand what a system is good at. I can go along with that as much as I do not like the market segmentations myself. She said Papyrus could be rated as a document centric process system with our UTA process training and the Web 2.0 capabilities as clearly distinguishing factors to the others. Makes sense too. She said that we are not a typcial BPM system if we do not focus on flowcharting. I totally agree there. We once again created our own marketplace that we can not be compared in. That actually was a relief to me. On the other hand Papyrus is much better suited to adress process issues than your typical BPM product, mostly because of the powerful content, GUI and integration features. But how will we make that understood?

The other two very prominent subjects in Orlando were SOA and Web 2.0. IBM's Sandy Carter offered her book 'The New Language of Business - SOA and Web 2.0' published by IBM Press(!). I did get a signed copy and read it on the flight back from Orlando to Frankfurt. Well, she has some good points in there but I think the title is misleading. There is no 'language' aspect to neither SOA nor Web 2.0 and it certainly is not a language that anyone involved in business will understand. That is the reason why Sandy clearly recommends that you need a strong partner (IBM obviously) to make it work. Sandy is clever enough not to use 'agility' but creates a new word 'flex-pon-sive' as a mix of flexible and responsive. In the end she offers nothing new or a true insight as to how to combine SOA and Web 2.0. 

So we are back to the problem of a huge gap between what the business needs and how they can describe what it is. SOA and Web 2.0 in their current forms ARE NOT solutions that address that. They are technical concepts that may play a part in actually creating a total solution but require a huge manpower investment. One thing shocked me though. IBM had on their booth a big sign, claiming that they have 700 (yes, SEVEN HUNDRED) patents related to SOA. Which means that if YOU are involved in SOA today you are already infringing and liable to lawsuits. I am sure that Microsoft and Oracle have as least as many patents. Another reason why I think that SOA as a technology is DOA despite its good concepts. If I were you, I would stay away from SOA and do something for my users!

A related subject I had discussed with Forrester's Mike Gilpin, namely 'federated SOA'. As far as I understand it, it relates to the problem that businesses are unable to create a single SOA infrastructure and thus need to federate SOA interfaces. No surprise there. I had a similar discussion with Dr. Dorn of the Technical University Vienna who was the mentor for a study project into our User Trained Agent. He said that the main purpose of SOA was linking backend services together and not a single homogenous infrastructure. 

Right! If SOA is not only about WebServices and not about a single homogenuous infrastructure (that should handle GUI and process) then SOA ends up being a very broad term for loosely coupled service interfaces. What a waste of time and money all the advertising and buzz is. 

Dear business user: Do you know who is paying for all that? YOU ARE! Nearly 50% of most IT companies revenue go into 'cost of sales'. You get nothing for that at all!

The KPI Library describes themselves as follows:

"The free Key Performance Indicator (KPI) Library is a community of business professionals that provides a catalogue of KPIs for identifying & prioritizing the KPIs that really matter for your organization's success. Login or register for access."

A link can also be found on my Resource page. I would be interested to hear how useful it is.

Enjoy!

[caption id="attachment_81" align="aligncenter" width="140" caption="Empresa"][/caption]

[caption id="attachment_82" align="aligncenter" width="140" caption="Productos"][/caption]

[caption id="attachment_83" align="aligncenter" width="140" caption="Servicios"][/caption]

[caption id="attachment_84" align="aligncenter" width="140" caption="Contacto"][/caption] ]]> http://isispapyrus.wordpress.com/?p=45 Sun, 21 Sep 2008 16:41:36 +0000 Max Pucher http://isispapyrus.fr.wordpress.com/2008/09/21/cmis-content-management-interoperability-services/ Since 2001 we have been making businesses aware that there is a need for Inbound/Outbound business content to be managed in a consolidated business process with common business rules. We never saw these as separate processes.

Finally, EMC, IBM and Microsoft have announced a jointly developed specification called CMIS, which uses Web Services and Web 2.0 interfaces to enable applications to interoperate with multiple Enterprise Content Management ‚repositories‘ by different vendors. (Psst - an archive is not a repository ...)

They intend to submit the CMIS specification to OASIS (Organization for the Advancement of Structured Information Standards). The ultimate goal of CMIS - Content Management Interoperability Services - is to dramatically reduce the dramatic cost for multi-vendor, multi-archive environments. Businesses spend a huge amount of time and money to create and maintain custom integration code and one-off integrations for ECM systems as we proposed for so long.

Now with CMIS we can push the clunky archive systems to the server back-end and give the business users the consolidated, easy-to-use, user front-ends for ECM, BPM and CRM with the Papyrus Platform that they actually need.

We can now use CMIS (an SOA like interface spec) to link multiple existing archives (repositories in their diction) to unlock content they already have by adding modern Web 2.0 or RIA user interfaces that exhibit the business processes (ideally trained with the UTA) and the related boundary business RULES.

We are already working to define the CMIS specification for the Papyrus Platform in sync with the available information. Because of our powerful integration features it is fairly easy to do so. As soon as our analysis is complete and we can estimate an availability date, we will officially announce support for the CMIS specification.

What BPM is?

"BI by itself lacks context," says Howard Dresner, chief strategy officer at Hyperion Solutions, a maker of BPM software. Dresner explains what BPM is in this way: "There are four phases in the management cycle: concept and vision, goals and objectives, managing execution, and evaluating strategy afterwards. The connective processes in between those four things are BPM."

BPM is more of an innovation in management, not technology. However, technological innovation is at the core of any good BPM plan. Ken Vollmer, a principal analyst at Forrester Research, sees BPM as the convergence of integration-centric process management out of IT with the more human-centric process management from the work flow-oriented business side. Vollmer enumerates the many ways a good BPM strategy can make a difference:

• Supports cross-functional processes among departments
• Transparency -- allows business users or customers to monitor status, preferably in real time
• Agility -- adapts and changes business processes frequently
• Captures process knowledge for analysis
• Reduces human error or labor intensity in work activities

Getting started
For the CIO starting at square one, the question is where to begin when putting together a BPM strategy. Experts recommend taking the following steps:

• Talk to key people on the business side Dresner recommends approaching them informally when people tend to be more candid, or as he puts it, "tap into that black market of information."
• Take an inventory of processesWhat processes are already in place? What's working and what's not working? As Hill points out, most companies measure success in terms of function, not process. For example, a manufacturer may determine success by the amount of inventory delivered and pay less attention to the cycle time between order and cash received. "Functional excellence needs to become subordinate to process excellence," says Hill.
• Determine how decisions are made Who are the key players in decision-making? What needs to happen to reach consensus and begin execution? "Organizations tend to do either too much or too little," says Dresner. "Find the pain points so you can build a roadmap of BPM."
• Talk to the CFO At the C-level, the CFO is typically the person most likely to understand BPM just by the nature of what he or she does (e.g., tracking financial processes across departmental lines). The CFO can be a great resource in assessing the organization's current BPM, as well as being a CIO's best ally in making improvements.

A Golden opportunity
Many CIOs fear becoming entangled in BPM strategy, sometimes seeing only encroachment on their departmental turf, or perhaps preferred IT projects getting short-changed. It's actually a great opportunity to be a company-wide hero and have a tremendous impact on the organization.

"A CIO very often has that enterprise perspective, because he or she already works across departmental lines so much," Hill says. "They really are in great position to be an agent of change in business process management."

Renee Oricchio is a freelance writer in Norwalk, Conn. For the past 20 years, she has been writing and producing news segments about technology and business for CNN, MSNBC, Ziff-Davis, CNET and a variety of Silicon Valley-based local news outlets.