In the transition from the Information Age to the Process Age, we need new thinking and methods to design products and services for the agile business environment. Processes demand a new paradigm that expects more from managing a business and creating solutions than the current information-oriented paradigm. We need methods that are fit for working with processes to replace our methods for working with information, as they aren’t built on the necessary concepts.
Articles by: BPMInstitute.org
Service Oriented Architecture – A Service Contract Design Template
Introduction
Service-Oriented Architecture (SOA) is a highly collaborative paradigm, and attempts to break down the invisible barriers between IT and business. A critical step to be undertaken when implementing a SOA is to identify, specify, catalog and document candidate services. Given the sheer complexity of the task, this is more of an art, rather than a science. However, there do exist some common-sense principles and best practices for this purpose.
Technology Does Not Matter, Methodology Does
Does it still matter what matters in Enterprise IT? Even before the current harsh times the field seemed to be a land of confusions and illusions, from CIOs greatly overestimating their departments’ and their own role in the eyes of their CEOs1, to business analysts continuously unable to get exactly what they need when they need it from their IT counterparts. And to a respectful analytical firm putting as much confusion as possible in one sentence: “Although the word ‘SOA’ is dead, the requirement for service-oriented architecture is stronger than ever” (sic!).
Structuring a Process Management Center of Excellence: the Value Chain
1. INTRODUCTION
Over time, organizations have been increasing their interest in process management institutionalization. The growing complexity and scope of processes, and the frequency with which process modeling, improvement, deployment, integration and coordination occur require companies to structure in such a way as to manage their processes [2][5]. In such a context, organizations have sought concepts and guidelines towards structuring a process center of excellence [1][3].
The Systems Viewpoint
Systems thinking has been around for quite a while; in the 1960’s it was the subject du jour. Very good articles and books were written then bringing cogent ideas from academic study to the rest of the world – two of my favorite books were C. West Churchman’s The System’s Approach and The Design of Inquiring Systems. But times change, and there is good reason to look again at the systems approach.
From BPM to Management By Process
In one of my first courses about Business Process Management, the chairman, an expert in Total Quality Management, was making a major difference between Process Management and Management by Process.
For me it was just a question words. Some years after, making a return on experience from my first BPM initiative, I really understood this difference when I discovered the remedy had been worst than the disease.
Four Pillars for Business Process Automation
“If we want to enter in an automated processes schema, the principle problem that we must resolve is the modeling of the current and proposed context. Based on my experience in process automation I can say that there exists a high-priority necessity for the correct evaluation of the current activites of the process one wishes to automate in order to assure the successful future implementation of the automation of the said process, based on four fundamental factors: maturity, process definition, organizational culture, and managerial drive.”
How to Select the Right Tools for your BPM Initiative
So you finally sold the value of your BPM initiative to your company’s executives. Now it is time to deliver. Selecting the right tools is a critical step to help you succeed. This may not sound that difficult but if the proper amount of effort is not directed toward this decision point, you could find yourself spending more time with your vendor than with your business partners.
BPM Implementation – An Application Reduction Strategy
Many companies today are looking to reduce the number of installed/supported applications as a way to save money and reduce complexity. Money is saved via reduced licensing, support and integration costs. However, many do not have a clear execution strategy, even while investing in application portfolio management solutions to get a better understanding of the application portfolio and tracking existing applications.
One obvious route to application reduction is standardizing on a single application globally if possible and if not, to a single application in a given region.
SOA Readiness – A Perspective
What is SOA?
To be ready for something you first need to understand what it is. SOA is often defined in technical terms about the composition of services. Whist technically correct this encourages people to become caught up in technologies and constraints very early on.
I prefer to think of SOA as a solution approach that helps IT solve business problems by sharing and re-using:
- Information and data e.g. user directories
- Functionality e.g. quote generation
- Know how e.g.
























