Profile picture for user mrosemann

The Service-oriented View of the Enterprise

The 'service-based view of the enterprise' is an emerging managerial paradigm that defines an organisation as a set of decentralized, autonomous, loosely coupled and interacting capabilities. This is the same approach that currently drives the re-design of IT landscapes in the form of Service-oriented Architectures (SOA). This paper proposes to view and drive process management following the corresponding concept of the 'Service-oriented Enterprise (SOE)'.

In an SOE, two types of services can be differentiated. On the one hand, transactional services are characterized by being highly repetitive and predictable. The execution of these services does not change the structure or processes of the organisation. Examples are payroll, procurement of standard components or accounts receivable. On the other hand, transformational services are those capababilities that impact the organisational structure and processes. Example services are project management, change management or process management. In the following, we will elaborate on the characteristics of such transformational services using process management as an example. As an inspiration for the design of these services, we will refer to four principles that guide services in the world of SOA, namely abstraction, loose coupling, messaging and composability.

Four Principles of Enterprise Services: The Process Management Example

Any senior executive, in his or her aspiration to conduct a major or minor transformation of an enterprise, requires certain services to execute organisational change projects. All process management-related capabilities, methods, staff, tools and methodologies that exist in the organisation can be seen as such a service that is available to the executives for managing the enterprise. If we follow this service-oriented viewpoint, we see that an enterprise service such as process management has to be build based on the following four principles:

1) Abstraction

Consumers of a process management service have typically a limited interest in how the actual process analysis and improvement is conducted. Abstraction means that the service can be described and consumed without deeper insights into the way the service is delivered or executed. It simply should not matter, if process management follows Six Sigma, Lean Management, Total Quality Management, ITIL, good old Industrial Engineering or any combination of these approaches. It should not matter what modelling technique or tool is used. A service-oriented view on process management stresses exactly this abstraction from BPM methodologies and related terminologies that are often confusing for the process-agnostic business world (Figure 1).

Black Boxing BPM methods, tools and techniques

Figure 1: Black Boxing BPM methods, tools and technique

2) Loose Coupling

The service-oriented paradigm emphasises that a single service should be as autonomous as possible. This facilitates wider re-use of this service and allows consuming a service independently of any other service. At the same time, it allows separate make-or-buy decisions about this service. Loose coupling means in particular, that the process management service should in itself have a compelling value proposition and be free of any overlaps with other managerial support services. This means, e.g. that services related to the management of a BPM project would be typically provided by a separate 'project management service'. In other words, the project management service would be responsible for ensuring project deadlines are met, project KPIs are defined, and so forth, while the process management service is solely concerned with the project content, i.e., documenting, analysing, improving and implementing processes.

Loose Coupling of Two Services

Figure 2: Loose Coupling of Two Services

For loose coupling to work, it is important to define adequate and well-defined key interfaces, to eliminate potentially confounding shared interests, overlapping areas of responsibility and goal conflicts. This requirement, in turn leads to the principle of messaging.

3) Messaging

An enterprise service has to have well-defined interfaces that facilitate its interaction with its environment. These interfaces need to be clearly described in a corporate catalogue of enterprise services. For the process management service this would mean that it is listed in such a catalogue with all its potential sub-services (e.g., minor (10%) improvement, radical process re-design, business innovation, process modelling as a service, etc.). It also is clearly articulated what type of information needs to be supplied to the service (e.g. type of service requested, length of service consumption) and what type of outcomes/messages will be provided in return (e.g., deliverables produced, charges for the services, etc.) (Figure 3).

Income/Outcome Messages of a Service

Figure 3: Income/Outcome Messages of a Service

The messaging should further include important KPIs (such as quality of the service, efficiency of service delivery).

4) Composability

Louse coupling leads to a number of autonomous transformational services each with their own capability and promise of a net value provision into the organisation. However, in many cases the consumption of a single service will not be sufficient for the issues that business managers are facing. For example, a large-scale SAP implementation across the enterprise requires services related to IT infrastructure management, process re-design, change management, service level managements, and project management, to name just a few. Thus, it is necessary to compose multiple enterprise services to larger aggregated services with a more comprehensive value proposition. This requires that an overarching approach to the choreography of these services exists. Again, the details of this integration of multiple services need to be hidden to the service consumer ('principle of abstraction'). An example would be a larger, composed enterprise service called 'Organisational Improvement' that is made up of 'Business Analysis', 'Process Management' and 'Change Management' (Figure 4).

Composition of Enterprise Services

Figure 4: Composition of Enterprise Services

The Chief Services Officer

The application of these four principles can guide the definition of transformational enterprise services. Once defined, they need to be resourced from the existing organisational units. Following the four service design principles above will leave the organisational structure with increased flexibility as it facilitates easier integration of new or retirement of services that are no longer required or are outsourced. Like in SOA, the definition of enterprise services leads to a de-coupling from the actual organisational structures. Thus, rather than starting with an argument on who owns process management within an organisation, the first focus should be on the actual design of 'process management as a service'.

The clear distinction between transactional and transformational services could have even wider implications when these two groups of services form the main organisational entities. A Chief Services Officer (CSO) for transformational services would be in charge for a comprehensive set of advanced services, incl. process management, that together lead to larger business transformations. A Chief Services Officer for transactional services would take over responsibilities for all well-defined processes across all classical services domain. Such a service-centred design would in consequence influence the existing portfolios of Chief Information Officers (CIO), Chief People Officers (CPO, HR Directors) and Chief Financial Officers (CFO). These portfolios could be potentially reduced to the relevant highly transactional services only (Figure 5).

Splitting Transformational and Transactional Services

Figure 5: Splitting Transformational and Transactional Services

Is a Service a Process, and vice versa?

For the BPM-community, everything seems to be a process ('process as the ultimate first class citizen'). Thus, there is a high level of scepticism that the service notion can add new insights. In fact, every of the exemplary services mentioned above, could be described as a composition of processes.

'Process' and 'Service' are two complementary views on the same capability of an organisation. As two distinct 'sensitizing devices', however, their associated viewpoints stress alternative facets of organisational capabilities. A process view sharpens the understanding for the operational model of a capability. It provides the required analytical foundation to reflect on the current and potential future performance of a capability as far as this performance can be impacted by the way it is delivered. As such, a process-view can be seen as an approach to 'white box a corporate capability'. In contrast, a service-oriented (external) view on a corporate capability can be regarded as a 'black box' perspective. The emphasis is, as described above, on the conscious abstraction of the internal operations of this capability. Instead, the focus is on the overall value proposition (what can the service provide?), the related costs, the underlying governance model ('what happens when the service fails, i.e. service continue management') and further non-functional service properties as part of a service level agreement ('response time, quality standards, etc.).

Dr Michael Rosemann is Head of the Information Systems Discipline at Queensland University of Technology, Brisbane, Australia. He can be contacted at m.rosemann@qut.edu.au.

by Alexander Samarin
Posted on Tue, 12/07/2010 - 15:32

From - http://improving-bpm-systems.blogspot.com/2009/11/linking-concepts-and-expressions-used.html

 

Next, two overused terms


Service is an explicitly-defined and operationally-independent unit of functionality. Service is a black box to produce some assets. Service is an external perspective of a function. One or many distinct functions can be fulfilled by a service.

Process is an explicitly-defined coordination of services to create a particular result. Process is a white box to produce some assets. Process is an internal perspective of a function. Process is a composite from many different artefacts (roles, rules, assets, functions, etc.).

Remark: Services and processes can be considered to be intimately related since in real terms

  • all processes are services,
  • some functions of a service can be implemented as a process, and
  • a process includes services in its implementation.



So, at an enterprise we may have many elementary nano-services which are organised into a mega-service, i.e. the whole enterprise.

 

See also, http://improving-bpm-systems.blogspot.com/2010/02/bpm-reference-model-fragment-01.html

 

Thanks,

AS

0

Featured achievement

Rookie
Say hello to the ARIS Community! Personalize your community experience by following forums or tags, liking a post or uploading a profile picture.
Recent Unlocks

Leaderboard

|
icon-arrow-down icon-arrow-cerulean-left icon-arrow-cerulean-right icon-arrow-down icon-arrow-left icon-arrow-right icon-arrow icon-back icon-close icon-comments icon-correct-answer icon-tick icon-download icon-facebook icon-flag icon-google-plus icon-hamburger icon-in icon-info icon-instagram icon-login-true icon-login icon-mail-notification icon-mail icon-mortarboard icon-newsletter icon-notification icon-pinterest icon-plus icon-rss icon-search icon-share icon-shield icon-snapchat icon-star icon-tutorials icon-twitter icon-universities icon-videos icon-views icon-whatsapp icon-xing icon-youtube icon-jobs icon-heart icon-heart2 aris-express bpm-glossary help-intro help-design Process_Mining_Icon help-publishing help-administration help-dashboarding help-archive help-risk icon-knowledge icon-question icon-events icon-message icon-more icon-pencil forum-icon icon-lock