The roles in service-oriented architectures as discussed above are not completely
filled in typical enterprise scenarios. The specification of services is typically
done by the provider of the service, i.e., by the system architects
responsible for service-enabling the particular application.
The service registry is installed locally, and its access by other companies
is usually disallowed. The most striking difference to service-oriented architectures
as defined by Burbeck is the absence of dynamic matchmaking. As
enterprise services are developed, they are specified and registered in a local
registry. When a new composite application is developed, the designers consult
the registry to find suitable services that can be used to perform certain
tasks in the composite application. This search is a manual process, which in
some cases is assisted by a taxonomy and a textual description of the services.
There are a number of hard problems in this context that are unsolved
today. One of the main problems regards the scoping of services: the functionality
provided by one or more application systems that is suitable for an
enterprise service. If the granularity is small, then the level of reuse is small
too, because many enterprise services need to be composed to achieve the
desired functionality.
If on the other hand the granularity is large, then there might be only
few scenarios where the enterprise service fits well and where using it makes
sense. Tailoring of services of large granularity is also not a valid option, since
extensive tailoring hampers reuse. As in many related cases, there is no general
answer to this question. The choice of a suitable service granularity depends on
the particular usage scenario and on the properties of the application systems
to integrate and the composite applications to develop.
In enterprise services architectures, each enterprise service is typically associated
with exactly one application system. This is a limitation, since building
an enterprise service on top of a number of related back-end application
systems involves system integration, so that reuse is simplified.
To illustrate this concept, an example is introduced. Consider a purchase
order enterprise service in which an incoming purchase order needs to be stored
in multiple back-end application systems. In this case, the enterprise service
can be used with ease, since it is invoked once by a composite application and
it automatically provides the integration of the back-end system by storing
the purchase order�with the relevant data mappings to cater to data type
heterogeneity�in the respective back-end application systems.
An integration of legacy systems can be realized within an enterprise service.
This allows using enterprise services at a higher level of granularity, so
that integration work can actually be reused in multiple composite applications.
Tuesday, September 1, 2009
Process Support Without Workflow Systems:
Not all environments ask for a workflow management system. In cases where
no changes to the process structure are envisioned, a coding of the process
flow can be an attractive and adequate choice.
In database administration there are predefined procedures that are enacted
following a process model. Similar developments can be found in publishing
environments where print workflow is a common tool to describe and
perform the steps that lead to publishable results. Most enterprise resource
planning systems feature a dedicated workflow component that allows us to
model new processes and enact them in the system environment. Due to their
close link to particular applications, these systems are also called embedded
workflow management systems.
Business processes are also realized in online shops, such as train reservation
systems or electronic book stores, where steps of an interaction process
are depicted in graphical form. This graphical representation guides the user
in his interaction with the Web site. In a train reservation online shop, for
instance, there are interaction steps for querying train connections, for getting
detailed information on the connections, for selecting connections, for
providing payment information, and for booking and printing the train ticket.
Since this type of interaction process can easily be realized using traditional
Web page design, workflow management systems are not required. However,
these examples show that the business process paradigm is helpful also in
application scenarios that do not require dedicated workflow support.
Enterprise application systems, such as enterprise resource planning systems,
realize literally thousands of business processes. These processes can be
customized to fit the particular needs of the company that runs the system. In
most cases, the business processes are realized within the system, so no integration
issues emerge. If the predefined business processes cannot be tailored
in a way that fits the needs of the company, then integrated process modelling
functionality can be used to model new processes.
no changes to the process structure are envisioned, a coding of the process
flow can be an attractive and adequate choice.
In database administration there are predefined procedures that are enacted
following a process model. Similar developments can be found in publishing
environments where print workflow is a common tool to describe and
perform the steps that lead to publishable results. Most enterprise resource
planning systems feature a dedicated workflow component that allows us to
model new processes and enact them in the system environment. Due to their
close link to particular applications, these systems are also called embedded
workflow management systems.
Business processes are also realized in online shops, such as train reservation
systems or electronic book stores, where steps of an interaction process
are depicted in graphical form. This graphical representation guides the user
in his interaction with the Web site. In a train reservation online shop, for
instance, there are interaction steps for querying train connections, for getting
detailed information on the connections, for selecting connections, for
providing payment information, and for booking and printing the train ticket.
Since this type of interaction process can easily be realized using traditional
Web page design, workflow management systems are not required. However,
these examples show that the business process paradigm is helpful also in
application scenarios that do not require dedicated workflow support.
Enterprise application systems, such as enterprise resource planning systems,
realize literally thousands of business processes. These processes can be
customized to fit the particular needs of the company that runs the system. In
most cases, the business processes are realized within the system, so no integration
issues emerge. If the predefined business processes cannot be tailored
in a way that fits the needs of the company, then integrated process modelling
functionality can be used to model new processes.
From Business Functions to Business Processes
To provide a more detailed view,
these top-level business functions are broken down to functions of smaller
granularity and, ultimately, to activities of operational business processes.
Functional decomposition is the technique of choice. where a value system represents t
he highest level of aggregation. Each value
system consists of a number of value chains
The functional decomposition of the value chain of enterprise E is exemplified
for one particular path of functions in the marketing and sales top-level
business function. Among many other functions, marketing and sales includes
a business function, OrderManagement, that contains functions related to the
management of incoming orders. Order management is decomposed further
into business functions for getting and checking orders. To check orders, they
need to be analyzed, and there are functions for simple and advanced checking
of orders. Traditionally, functional decomposition was used to describe enterprises
based on the functions they perform. As discussed in Chapter 1, concentrating
on the functions an enterprise performs and neglecting their interplay falls
short of properly representing how enterprises work. Therefore, functional
decomposition is used as first step in the representation of enterprises based
on business processes. Operational business processes relate activities to each other by introducing
execution constraints between them. In principle, relating functions to
business processes can be applied for different granularities of business functions.
In case high-level business functions are considered, a textual specification
of the process is used, since concrete execution constraints between their
constituents are not relevant in coarse-grained business functions.
Consider, for instance, the business functions incoming logistics and operations.
At this very coarse level of functionality, no ordering of these business
functions is feasible: both business functions are performed concurrently, and
only at a lower level of granularity does a concrete ordering make sense.
For instance, when the operations business function orders additional material,
then there are concrete activities that have a concrete ordering. Within
operations, an internal order is created and sent to incoming logistics. On arrival
of this order, raw material is provided to operations. In case no raw material
is available at the manufacturing company, an external order is created
and sent to a supplier of the raw material. Therefore, business processes relate
fine-grained business functions, typically the leaves of the business function
decomposition tree.
these top-level business functions are broken down to functions of smaller
granularity and, ultimately, to activities of operational business processes.
Functional decomposition is the technique of choice. where a value system represents t
he highest level of aggregation. Each value
system consists of a number of value chains
The functional decomposition of the value chain of enterprise E is exemplified
for one particular path of functions in the marketing and sales top-level
business function. Among many other functions, marketing and sales includes
a business function, OrderManagement, that contains functions related to the
management of incoming orders. Order management is decomposed further
into business functions for getting and checking orders. To check orders, they
need to be analyzed, and there are functions for simple and advanced checking
of orders. Traditionally, functional decomposition was used to describe enterprises
based on the functions they perform. As discussed in Chapter 1, concentrating
on the functions an enterprise performs and neglecting their interplay falls
short of properly representing how enterprises work. Therefore, functional
decomposition is used as first step in the representation of enterprises based
on business processes. Operational business processes relate activities to each other by introducing
execution constraints between them. In principle, relating functions to
business processes can be applied for different granularities of business functions.
In case high-level business functions are considered, a textual specification
of the process is used, since concrete execution constraints between their
constituents are not relevant in coarse-grained business functions.
Consider, for instance, the business functions incoming logistics and operations.
At this very coarse level of functionality, no ordering of these business
functions is feasible: both business functions are performed concurrently, and
only at a lower level of granularity does a concrete ordering make sense.
For instance, when the operations business function orders additional material,
then there are concrete activities that have a concrete ordering. Within
operations, an internal order is created and sent to incoming logistics. On arrival
of this order, raw material is provided to operations. In case no raw material
is available at the manufacturing company, an external order is created
and sent to a supplier of the raw material. Therefore, business processes relate
fine-grained business functions, typically the leaves of the business function
decomposition tree.
Conceptual Model and Terminology in business process modelling foundation:
The business process modelling space as laid out in Chapters 1 and 2 is organized
using conceptual models. Figure 3.1 introduces a model of the concepts
at the core of business process management. While the terms mentioned have
been used in the previous chapters informally, the concepts behind these terms
and their relationships will now be discussed in more detail, using conceptual
models. These models are expressed in the Unified Modeling Language, an
object-oriented modelling and design language.
Business processes consist of activities whose coordinated execution realizes
some business goal. These activities can be system activities, user interaction
activities, or manual activities. Manual activities are not supported by
information systems. An example of a manual activity is sending a parcel to
a business partner.
User interaction activities go a step further: these are activities that knowledge
workers perform, using information systems. There is no physical activity
involved. An example of a human interaction activity is entering data on an
insurance claim in a call centre environment. Since humans use information
systems to perform these activities, applications with appropriate user interfaces
need to be in place to allow effective work. These applications need to
be connected to back-end application systems that store the entered data and
make it available for future use.
Some activities that are conducted during the enactment of a business
process are of manual nature, but state changes are entered in a
business process management system by means of user interaction activities. For instance,
the delivery of a parcel can be monitored by an information system.
Typically, the actual delivery of a parcel is acknowledged by the recipient
with her signature. The actual delivery is important information in logistics
business processes that needs to be represented properly by information systems.
There are several types of events during a logistics process. These events
are often available to the user as tracking information. While the activities
are of manual nature, an information system�the tracking system�receives
information on the current status of the process.
System activities do not involve a human user; they are executed by information
systems. An example of a system activity is retrieving stock information
from a stock broker application or checking the balance of a bank
account. It is assumed that the actual parameters required for the invocation
are available. If a human user provides this information, then it is a user
interaction activity. Both types of activities require access to the respective
software systems.
Certain parts of a business process can be enacted by workflow technology.
A workflow management system can make sure that the activities of a business
process are performed in the order specified, and that the information systems
are invoked to realize the business functionality. This relationship between
business processes and workflows is represented by an association between
the respective classes. We argue that workflow is not a subclass of business
process, since a workflow realizes a part of a business process, so a workflow
is not in an �is-a� relationship with a business process, but is an association.
With regard to the types of activities mentioned, system activities are associated
with workflows, since system activities can participate in any kind.
using conceptual models. Figure 3.1 introduces a model of the concepts
at the core of business process management. While the terms mentioned have
been used in the previous chapters informally, the concepts behind these terms
and their relationships will now be discussed in more detail, using conceptual
models. These models are expressed in the Unified Modeling Language, an
object-oriented modelling and design language.
Business processes consist of activities whose coordinated execution realizes
some business goal. These activities can be system activities, user interaction
activities, or manual activities. Manual activities are not supported by
information systems. An example of a manual activity is sending a parcel to
a business partner.
User interaction activities go a step further: these are activities that knowledge
workers perform, using information systems. There is no physical activity
involved. An example of a human interaction activity is entering data on an
insurance claim in a call centre environment. Since humans use information
systems to perform these activities, applications with appropriate user interfaces
need to be in place to allow effective work. These applications need to
be connected to back-end application systems that store the entered data and
make it available for future use.
Some activities that are conducted during the enactment of a business
process are of manual nature, but state changes are entered in a
business process management system by means of user interaction activities. For instance,
the delivery of a parcel can be monitored by an information system.
Typically, the actual delivery of a parcel is acknowledged by the recipient
with her signature. The actual delivery is important information in logistics
business processes that needs to be represented properly by information systems.
There are several types of events during a logistics process. These events
are often available to the user as tracking information. While the activities
are of manual nature, an information system�the tracking system�receives
information on the current status of the process.
System activities do not involve a human user; they are executed by information
systems. An example of a system activity is retrieving stock information
from a stock broker application or checking the balance of a bank
account. It is assumed that the actual parameters required for the invocation
are available. If a human user provides this information, then it is a user
interaction activity. Both types of activities require access to the respective
software systems.
Certain parts of a business process can be enacted by workflow technology.
A workflow management system can make sure that the activities of a business
process are performed in the order specified, and that the information systems
are invoked to realize the business functionality. This relationship between
business processes and workflows is represented by an association between
the respective classes. We argue that workflow is not a subclass of business
process, since a workflow realizes a part of a business process, so a workflow
is not in an �is-a� relationship with a business process, but is an association.
With regard to the types of activities mentioned, system activities are associated
with workflows, since system activities can participate in any kind.
Modelling Process Data in business Business Process Modelling Foundation:
Data modelling is at the core of database design. The Entity Relationship
approach is used to classify and organize data in a given application domain.
The Entity Relationship modelling approach belongs to the metamodel level,
as depicted in because it provides the required concepts to express
data models. Data modelling will be illustrated by a sample application
domain, namely by order management.
In a modelling effort, the most important entities are identified and classified.
Entities are identifiable things or concepts in the real world that are
important to the modelling goal. In the sample scenario, orders, customers,
and products are among the entities of the real world that need to be represented
in the data model.
Entities are classified as entity types if they have the same or similar
properties. Therefore, orders are classified by an entity type called Orders.
Since each order has an order number, a date, a quantity, and an amount, all
order entities can be represented by this entity type. Properties of entities are
represented by attributes of the respective entity types.
The entities classified in an entity type need to have similar, but not identical
structure, because attributes can be optional. If the application domain
allows, for instance, for an order to have or not to have a discount, then the
amount attribute is optional. This means that two orders are classified in
entity type order even if one has a discount attribute while another does not.
Entity types in the Entity Relationship metamodel need to be represented
in a notation by a particular symbol. While there are variants of Entity Relationship
notations, entity types are often represented by rectangles, marked
with the name of the entity type. Figure 3.24 shows an entity type Orders at
the centre of the diagram. Other entity types in the sample application domain
are customers and products. The attributes are represented as ellipsoids
attached to entity types.
Entities are associated with each other by relationships. For instance, a
customer �Miller� requests an order with the order number 42. These types of
links between entities are called relationships.
Just as there are many customer entities and many order entities,
there are many customer-order relationships.
To represent these relationships, a relationship type requests classifies them
all. In Entity Relationship diagrams, relationship types are typically represented
by diamond symbols, connected to the respective entity types by edges.
The complex nature of data in a given application domain can be well
represented by Entity Relationship Diagrams. These diagrams can be used to
create relational database tables, using transformation rules. Once the respective
database tables have been created in a relational database, application
data can be stored persistently. The data can be retrieved efficiently using
declarative query languages, for instance Structured Query Language.
While this discussion focuses on data modelling in the context of database
applications, the same data modelling method can be used to represent data
structures in business process management. Based on these data structures,
data dependencies between activities in business processes can be captured
precisely.
Data modelling is also the basis for the integration of heterogeneous data.
In the enterprise application integration scenarios discussed above, one of the
main issues was the integration of data from heterogeneous data sources. Once
data models are available for these data sources, the data integration problem
can be addressed. There are advanced data integration techniques that also
take into account data at the instance level, but explicit data models in general
are essential to addressing data integration.
Data integration can then be realized by a mapping between the data
types. For instance, there might be applications on top of database systems A
and B, such that these systems have tables CustomerA and CustomerB, respectively,
that differ. For instance, while CName is the attribute of the CustomerA
table, referring to the name of the customer, CustN might be the respective
attribute in the CustomerB table. In order to integrate both tables, the attributes
need to be mapped. In this case, CustomerA.CName is mapped to
CustomerB.CustN.
approach is used to classify and organize data in a given application domain.
The Entity Relationship modelling approach belongs to the metamodel level,
as depicted in because it provides the required concepts to express
data models. Data modelling will be illustrated by a sample application
domain, namely by order management.
In a modelling effort, the most important entities are identified and classified.
Entities are identifiable things or concepts in the real world that are
important to the modelling goal. In the sample scenario, orders, customers,
and products are among the entities of the real world that need to be represented
in the data model.
Entities are classified as entity types if they have the same or similar
properties. Therefore, orders are classified by an entity type called Orders.
Since each order has an order number, a date, a quantity, and an amount, all
order entities can be represented by this entity type. Properties of entities are
represented by attributes of the respective entity types.
The entities classified in an entity type need to have similar, but not identical
structure, because attributes can be optional. If the application domain
allows, for instance, for an order to have or not to have a discount, then the
amount attribute is optional. This means that two orders are classified in
entity type order even if one has a discount attribute while another does not.
Entity types in the Entity Relationship metamodel need to be represented
in a notation by a particular symbol. While there are variants of Entity Relationship
notations, entity types are often represented by rectangles, marked
with the name of the entity type. Figure 3.24 shows an entity type Orders at
the centre of the diagram. Other entity types in the sample application domain
are customers and products. The attributes are represented as ellipsoids
attached to entity types.
Entities are associated with each other by relationships. For instance, a
customer �Miller� requests an order with the order number 42. These types of
links between entities are called relationships.
Just as there are many customer entities and many order entities,
there are many customer-order relationships.
To represent these relationships, a relationship type requests classifies them
all. In Entity Relationship diagrams, relationship types are typically represented
by diamond symbols, connected to the respective entity types by edges.
The complex nature of data in a given application domain can be well
represented by Entity Relationship Diagrams. These diagrams can be used to
create relational database tables, using transformation rules. Once the respective
database tables have been created in a relational database, application
data can be stored persistently. The data can be retrieved efficiently using
declarative query languages, for instance Structured Query Language.
While this discussion focuses on data modelling in the context of database
applications, the same data modelling method can be used to represent data
structures in business process management. Based on these data structures,
data dependencies between activities in business processes can be captured
precisely.
Data modelling is also the basis for the integration of heterogeneous data.
In the enterprise application integration scenarios discussed above, one of the
main issues was the integration of data from heterogeneous data sources. Once
data models are available for these data sources, the data integration problem
can be addressed. There are advanced data integration techniques that also
take into account data at the instance level, but explicit data models in general
are essential to addressing data integration.
Data integration can then be realized by a mapping between the data
types. For instance, there might be applications on top of database systems A
and B, such that these systems have tables CustomerA and CustomerB, respectively,
that differ. For instance, while CName is the attribute of the CustomerA
table, referring to the name of the customer, CustN might be the respective
attribute in the CustomerB table. In order to integrate both tables, the attributes
need to be mapped. In this case, CustomerA.CName is mapped to
CustomerB.CustN.
Modelling Operation in Business Process Modelling Foundation:
While business process management organizes the work that a company performs
by focusing on organizational and functional aspects, the realization
of business process activities also needs to be taken into account. Activities
can be distinguished depending on the level of software system support. The
terms system workflows and human interaction workflows were introduced to
characterize the different kinds of business process enactment.
A classification of activities in business processes was introduced in Figure
3.1, consisting of system activities, user interaction activities, and manual
activities. To recapitulate, system activities are performed by software systems
without user interaction, user interaction activities require the involvement of
human users and manual activities do not involve the use of information systems.
During the enactment of human interaction workflows, knowledge workers
perform activity instances. When a knowledge worker starts working on a specific activity,
the respective application program is started, and the input
data as specified in the process model is transferred to that application program.
When the knowledge worker completes that activity, the output data
generated is collected in the output parameters. These parameter values can
then be stored in the application program. They can also be transferred by
the business process management system to the next activity, as specified in
the business process model.
Business process modelling aims at mapping high-level and domain-specific
features of the application process; the technical details�the main components
of the operational perspective�are taken into account in the configuration
phase of the business process management lifecycle. The heterogeneous
nature of information technology landscapes led to various kinds of interface
definitions, most of which did not prove to be compatible. With the advent of
service-oriented computing, the operational aspects of business processes are
represented by services, providing the required uniformity.
This section discusses how activities realized by software functionality can
be modelled. Conceptually, the same levels of abstraction apply to modelling
the operational perspective as to modelling the other perspectives: at the
metamodel level, interface definition languages reside. They describe specific
interface definitions at the model level. At the instance level executing software
code is categorized.
This approach fits the modelling of activity instances (and, therefore, also
to process instances) well, because activity instances can be realized by executing
software code. It also fits the organizational perspective in which persons
reside at the instance level. Persons are�at least in human interaction
workflows�responsible for performing activity instances.
In order to automatically invoke this software functionality, business
process management systems require concepts and technology to access these
systems. The operational perspective of business process modelling provides
the information that equips a business process management system with information
required to invoke the functionality of external application systems.
The operational perspective includes the invocation environment of application
programs, the definition of the input and output parameters of the
application program, and their mapping to input and output parameters of
business process activities. Therefore, functional requirements need to be detailed
in order for us to evaluate whether a certain software system provides
the required functionality in the context of a business process.
This perspective is not limited to functional requirements. Non-functional
requirements also need to be represented, for instance, security properties
and quality of service properties of the invoked applications or services, such
as execution time and uptime constraints. In service-oriented architectures,
these properties are typically specified in service-level agreements between
collaborating business partners. These service-level agreements are part of a
legal contract that the parties sign.
by focusing on organizational and functional aspects, the realization
of business process activities also needs to be taken into account. Activities
can be distinguished depending on the level of software system support. The
terms system workflows and human interaction workflows were introduced to
characterize the different kinds of business process enactment.
A classification of activities in business processes was introduced in Figure
3.1, consisting of system activities, user interaction activities, and manual
activities. To recapitulate, system activities are performed by software systems
without user interaction, user interaction activities require the involvement of
human users and manual activities do not involve the use of information systems.
During the enactment of human interaction workflows, knowledge workers
perform activity instances. When a knowledge worker starts working on a specific activity,
the respective application program is started, and the input
data as specified in the process model is transferred to that application program.
When the knowledge worker completes that activity, the output data
generated is collected in the output parameters. These parameter values can
then be stored in the application program. They can also be transferred by
the business process management system to the next activity, as specified in
the business process model.
Business process modelling aims at mapping high-level and domain-specific
features of the application process; the technical details�the main components
of the operational perspective�are taken into account in the configuration
phase of the business process management lifecycle. The heterogeneous
nature of information technology landscapes led to various kinds of interface
definitions, most of which did not prove to be compatible. With the advent of
service-oriented computing, the operational aspects of business processes are
represented by services, providing the required uniformity.
This section discusses how activities realized by software functionality can
be modelled. Conceptually, the same levels of abstraction apply to modelling
the operational perspective as to modelling the other perspectives: at the
metamodel level, interface definition languages reside. They describe specific
interface definitions at the model level. At the instance level executing software
code is categorized.
This approach fits the modelling of activity instances (and, therefore, also
to process instances) well, because activity instances can be realized by executing
software code. It also fits the organizational perspective in which persons
reside at the instance level. Persons are�at least in human interaction
workflows�responsible for performing activity instances.
In order to automatically invoke this software functionality, business
process management systems require concepts and technology to access these
systems. The operational perspective of business process modelling provides
the information that equips a business process management system with information
required to invoke the functionality of external application systems.
The operational perspective includes the invocation environment of application
programs, the definition of the input and output parameters of the
application program, and their mapping to input and output parameters of
business process activities. Therefore, functional requirements need to be detailed
in order for us to evaluate whether a certain software system provides
the required functionality in the context of a business process.
This perspective is not limited to functional requirements. Non-functional
requirements also need to be represented, for instance, security properties
and quality of service properties of the invoked applications or services, such
as execution time and uptime constraints. In service-oriented architectures,
these properties are typically specified in service-level agreements between
collaborating business partners. These service-level agreements are part of a
legal contract that the parties sign.
Saturday, August 1, 2009
Degree of Automation:
Business processes can diverge in the level of automation. There are business
processes that are fully automated, meaning that no human is involved in the
enactment of such a business process. An example is ordering an airline ticket
using Web interfaces. While the process is fully automated on the side of
the airline, the customer is involved with manual activities, such as providing
address information via Web browser interfaces.
Enterprise application integration is another area where automated business
processes can be found. The goal is to integrate the functionality provided
by a heterogeneous software landscape. While there are different techniques to
integrate enterprise applications, process technology is an important technology,
especially since the emergence of service-oriented software architectures
that allow composing services to processes.
Many business processes require manual activities; but they also include
automated activities. Processing an insurance claim is an example of such a
process. Manual activities enter the customer data and determine the settlement
of the damage, while automated activities are used to store data on the
damage in the software systems of the company.
The interaction with the human user is essential in these settings. Early
approaches that prescribe to human users �what to do next� often failed.
User interfaces that accept the knowledge worker as an important source to
improve and control the process provide more user acceptance.
processes that are fully automated, meaning that no human is involved in the
enactment of such a business process. An example is ordering an airline ticket
using Web interfaces. While the process is fully automated on the side of
the airline, the customer is involved with manual activities, such as providing
address information via Web browser interfaces.
Enterprise application integration is another area where automated business
processes can be found. The goal is to integrate the functionality provided
by a heterogeneous software landscape. While there are different techniques to
integrate enterprise applications, process technology is an important technology,
especially since the emergence of service-oriented software architectures
that allow composing services to processes.
Many business processes require manual activities; but they also include
automated activities. Processing an insurance claim is an example of such a
process. Manual activities enter the customer data and determine the settlement
of the damage, while automated activities are used to store data on the
damage in the software systems of the company.
The interaction with the human user is essential in these settings. Early
approaches that prescribe to human users �what to do next� often failed.
User interfaces that accept the knowledge worker as an important source to
improve and control the process provide more user acceptance.
Subscribe to:
Posts (Atom)