They have direct impact on the attractiveness of products and services, influence customer experiences and ultimately revenue in case of corporations. Processes orchestrate corporate resources to fulfil these external demands and therefore are a key factor determining the cost-to-serve and operational efficiency. In particular, they determine tasks, jobs, and responsibilities and by this, shape the future work of every employee and machine along a business process.
Processes are the arterial system within organisations and in inter-organizational supply networks. Consequently, any process failure can bring corporate life and the entire process ecosystem to a standstill. Processes determine the potential and speed of an organization to adapt to new circumstances and to comply with a fast-growing number of legislative requirements.
However, unlike other corporate assets such as products, services, workforce, brand, physical or monetary assets, the significance of business processes had not been appreciated for a long period. Despite the fact that processes are the lifeblood of an organization, they did not develop the status of a primary citizen in boardroom discussions and managerial decision-making processes until the very end of the twentieth century.
The growing demands for globalization, integration, standardization, innovation, agility, and operational efficiency, coupled with the opportunities raised by digital technologies, have finally increased the appetite for reflecting on and ultimately improving existing as well as designing entire new business processes. In response, a comprehensive body of tools, techniques, methods, and entire methodologies to support all stages of the business process lifecycle has emerged over the past two decades.
It brings meaningful order and consistency into approaches that often have been developed, discussed, and deployed in isolation. It derives its merits from its firm foundation in the latest applied BPM research. Relying on scientifically sound practices means capitalizing on evidence rather than depending on confidence. This clearly differentiates this much-needed publication from many of its predecessors. In particular, it gives BPM the credibility that a still growing discipline requires.
We have traditionally programmed our processes into our software, each one at a time, which is why our costs are high, and changes difficult.
BPM software attempts to enable changes in process to keep track with changes in the business environment. This is the fundamental difference between process software and all other software. We have shifted a level of abstraction above program, to process. In doing so, writing software becomes a process configuration exercise, more uniform, and easier to rework. Thus, BPM attempts to remove software production from the critical path of business change, while reducing costs.
BPM Products To truly replicate the roles people have in business, an automation tool must be a master of the top 5 layers of the work stack in table 2.
Whether it also provides all of the nuances of other programming languages depends upon the product, its intended uses and its maturity. A BPM product is a programming tool created to model and run business processes.
This can be overlooked in the analyst as programmer approach to process automation. Modern programming languages provide much more than the basic constructs. A reasonable list might be sequence, conditional branching, structured loops, con- current threads, inter-thread communication and synchronization, instance initialization, manipulation of variables and data types, throwing and catching ex- ceptions, waiting on a lock and resuming afterwards, testing a predicate on several fields, logical and math operations, subprogram calls, and assigning and freeing up storage, software and hardware resources.
Two industry bodies support BPM. Some vendors use BPML in their products, but it is far from universal. The so-called pure play vendors are under pressure from products reaching in from established operators in the related fields of document management, enterprise applica- tion integration EAI , and from ERP leaders. Many vendors claim to be the leader in the field, but this is confused by a number of factors, including exactly how the market is defined, and without anyone publishing the indicators by which they claim to lead.
BPM offerings are part programming language, part operating environment and part per- son replacement. Despite the array of advanced technologies available, those that employ No. The leaders have products based on workflow, rules engines and process flow. Some automation products use Java or a bespoke language to create their process flows. Others use graphical techniques or flowcharts so that analysts can model rather than having coders code.
There are two major features to a BPM product: the design time, and the run time environ- ments. A mechanism for viewing the activity of the engine must be available for monitoring and support. Workflow management, depending upon its sophistication, allows managers to view the current and historic load on any worker, and reassign work from one worker to another.
Dependencies A BPM solution is usually dependent on external systems for integration with legacy sys- tems and access security. Comparing and Selecting a BPM product To compare BPM products is an extremely difficult task due to unfamiliarity with the me- dium, the vendors, and the wealth of products all appearing to do the same thing. It is rarely as simple as removing the people whose work has been replaced by machine. The list above is a simplified set of questions. Automation Oriented Architecture Two goals of BPM are to do the work that people normally do, and to enable the rapid change of business processes in an agile environment.
The enterprise architecture must facilitate these goals. In this section, we look at an enterprise architecture designed to support BPM, under the name Automation Oriented Architecture. It is a layered construct with three areas of con- cern, where each area is the focus of a different field of expertise. AOA - The big picture The 11 layers of AOA Business focused AOA - Automation, business processes and business services In the business layers, the workers, supervisors and business analysts are concerned with the services the business provides, and how those services are delivered by proc- esses and workflows.
The analyst further defines this into how the flow might be automated and orchestrated. Automation Here sits the automaton human, software or both running through a defined business process. When developing automation functions, it is important from a business point of view to focus on the benefits derived e. There is a great temptation when creating automation solutions to re-engineer the busi- ness processes at the same time. A full re-engineering effort followed by automation will result in statements like "if we knew that beforehand, we wouldn't have re-engineered it that way.
In this context, processing comprises workflow, work procedures, business rules, data defi- nitions and presentation of information to workers and their supervisors. Business Service Services are the core activities of the business.
They are the corporate raison d'etre, and held as tasks and processes on paper, in software, and in the hive mind. The business leaders and BPM champions will focus on the business services to identify what will be automated and when, and what the likely benefits will be. Development focused AOA - Integration, software services, applications and frame- works The role of development in automation solutions is to provide the environment in which the analyst can automate. Developers are not concerned with flows, user interfaces or business logic, but with providing interfaces between the automation software and the legacy or back office systems.
Integration An enterprise automating manual and paper based tasks will be relatively rare. In most cases, some form of integration to legacy systems is required.
If integration is being built as part of the BPM project, it will prove challenging as both are complex undertakings. I have a new order, rather than System X: I have a new order No. Internal integration allows an automator to work on a task regardless of where or how the data representing it is held.
It covers some or all of the integration items listed above. External integration boils down to a four function subset of internal integration, providing addressing, authentication, translation and transformation.
Incoming message struc- tures rarely match the internal business representation. Transformation and translation services convert an external format into an internal format, and vice-versa. Software services These are the services of Service Oriented Architecture.
Each application is exposed to other applications as sets of services. A service typically allows any application to read and write blocks of data and exposes applications' internal functions. Within the service, business rules may be applied to the data, which may, in turn, be supplied by another service.
Most services are of the form create, read, update, delete, search or read and lock any item of business relevance. For example, create sales order, delete customer or read report X12 are services. In a pure service oriented architecture, everything is a service. A service may be required to discover which services are to be used within a given process. Imagine the following scenario: A new request for an insurance quote comes in.
The vehicle is a Volvo FH A human operator might pull out a Volvo brochure, or look in some lists or on the internet to find out that this particular model is a 6x2 axled artic, and needs to be processed by the team at Leeds on the commercial vehicles system. A taxonomy is a system of classification, and would classify the processing mechanism and computer system for each type of vehicle, and also the classification for each particu- lar model.
Applications Applications are anything installed on desktops and servers such as analysis tools, financial systems, ERP systems, search engines, web servers, databases, email serv- ers etc. To make use of these applications, they must be exposed to outside use.
The most common form of exposure is through software services or web services. Other forms of exposure are published APIs or screen scraping for mainframe applications. Frameworks The frameworks provide shared services to applications. Reuse should occur at this low level, rather than expecting it to occur at the application level. There are many frameworks available these days, providing abstractions and services to what lies beneath.
Some come with purchased applications, other are. Many internal software development teams have created their own frameworks. Each technology and piece of hardware utilised must be carefully monitored to maintain the flow. Broken flow will create backlogs and blockages, the freeing of which IT support must expedite. Hardware Servers, networks devices, wires, radio links, laptops, phones, PDAs, routers, switches, firewalls, load balancers etc.
Some use http, others such as the UK national lottery use X. In the murky world of aged legacy systems RS may be the only option. This section lists how each layer is managed, monitored, and what management information MI it will provide. Are services running? What ran when, what was What is blocked? Business processes Do it this way.
What's going on? Who is How many did we do this doing it? How long is it month? Business services This is what we do Which are active, passive? What provides our income, What is taking the most profit? Internal integration What talks to what What is talking? What talked? Software services What can call what What gets called, what are Service hits, exceptions response speeds?
Applications What we use to do Ensure the applications are Throughputs, licences, business available applications External integration Who we talk to. How we Who is talking to who? Is Who talked to who, in what talk. The reason for this is the high level of expensive corporate failures. Governance measures mean less investment risk. Hamaker's[5] definition of governance highlights three areas of focus as follow: 1 Corporate Governance balances the power of the CEO with the board's role as cus- todians of the enterprise.
Within AOA, each layer addresses a different aspect of governance, as detailed in table 4. Some of the aspects of these layers are reflected in our software design patterns[6].
A design pattern is a simple, elegant and recorded solution to a spe- cific problem in software design. As a stack, it would look something like this: Figure 5. The model is the object or data being worked upon, the view is the on-screen presentation of that data or object, and the controller defines the way the user interface reacts to user input to change the data.
In this space, MVC becomes an excellent discussion leader. Most important is: where does your model live? Across an integrated space, the model may exist as a canonical data definition within the integration layer. It may be an ontological or taxonomical element contained elsewhere. A single model needs abstracted or transformed to be able to be persisted in a back end system and operated upon by an automator. Is it running? What is currently running? Or, which step is the process in?
Or, show me the audit trail. The most obvious view of a process is the design time view, often resembling a flowchart. And what of the controller? Is your automation layer the overall controller, or are you passing responsibility off to another service? How is control shared between the automa- tion software and the integration software? Bridge You will almost always need a bridge to link to the back end system.
It may be an estab- lished technology such as web services, HAS ex-SNA , or a service provided by a screen scraping tool. Chain of Responsibility In a chain of responsibility made up of workers, a piece of work will pass from worker to supervisor to manager or to specialists until it reaches a person with the knowledge and authority to do it.
Often these chains are defined within each process as a workflow, but there may be some benefit to decoupling the workflow from the process. Publish and Subscribe Within the integration layer, a subscription service may accept publications from applica- tions, and send out an event to a list of subscribers. All event driven architectures are based on publish and subscribe.
Comparison with Service Oriented Architecture Service Oriented Architecture SOA is a loosely coupled, distributed, coarse-grained col- lection of easily callable services designed to integrate both new and legacy systems, as well as being more flexible in adapting to future changes. No standard definition exists for it, but it can be thought of as a four layer mechanism comprising the business process layer, the business services layer, the application layer and the technology layer.
AOA is derived from SOA, where the automation layer sits atop the SOA layers, integration is inserted into the layers, and technology is expanded out to address the management and governance issues where automation can contribute.
We are working in a service based economy according to politicians and financiers. These services are the business services of the third layer and are delivered using the processes defined in the second layer. SOA uses the term business services to mean the software services that are granu- lar access to the applications. This is confusing, and AOA differentiates them as software services. As an example, a service oriented architecture would allow an application to call a service to see if the fire alarm was ringing.
In event driven architecture, the alarm would raise an event to the integration layer as a publisher. The integration layer would then route that event to a number of subscribers. The service oriented and event driven approaches are compatible, and automation ori- ented architecture is a fusion and expansion of the two, allowing for events and services to coexist.
In AOA, the event mechanism is contained within the integration layer in a publish and subscribe mechanism. In such cases, an event driven approach reduces traffic, while improving responsiveness and overall throughput. Some additional points of interest are noted where hindsight may benefit other travellers.
Creating a cross-functional team BPM requires dedicated resource from legacy teams, integration and the process auto- mation team. To try and deliver by allocating resource as it is required will stretch project schedules. Integration Integrating with legacy systems is hard. Getting integration resources when required, in organizations with mainframe development needs, is never easy. Integration usually comes via a service based offering. If there isn't already a service based approach, it will take more effort.
Testing integrated systems requires a well defined process to effectively test all parts together. Bugs in loosely connected systems are particularly difficult to track down, result- ing in long testing cycles. Tools on the integration side are often promise-ware and rarely work in your environment. The reality is that you often have to roll your own. Re-engineering Don't do it.
0コメント