Articles

Spread Sheets versus BPMS for Managing Processes

Author(s):

Anthony Murphy

Director / owner, Lithe IT Ltd

It is common place to find managers of complex, high risk, and business critical processes, making operational decisions using data gathered and manipulated within a series of spread sheets that have grown organically over a period of time.

Technology is clearly not a pre-requisite in developing and maintaining good processes. However, when it is used, I believe that a BPMS should be the first choice for managing processes rather than spread sheets.

Limitations of Spread Sheets

Spread sheets were designed to support modelling and they are fantastic for this purpose. They were not intended to manage operational processes where the requirement is to track task assignment and completion versus targets (granted that many managers would disagree with this). They present a number of key challenges when they are used in this way, including:

Capability mapping efforts not getting you to your destination?

Author(s):

Satya Iluri

Founder, CapabilityArchitecture.com

The drum beats are echoing across the Global 2000 about the value of business architecture, and more specifically business capability mapping. Business capabilities – in other words “What a business does” – are in vogue. Business capabilities, in conjunction with value stream (process layer) mapping and business service to IT service transition (service layer) mapping, are supposed to lead businesses to a state of nirvana.

BPM and Big Data – Why it Makes Sense

Author(s):

Viveka Sinha

Consultant, Independent Consultant

A lot has been written about Big Data in the last few months. Most companies are trying to make sense of the large amount of data they have to serve as an input to both strategic and operational decisions. In this article, I’ll discuss a couple of reasons for the obvious link between BPM and Big Data and how they can co-exist with BPM implementations helping drive adoption of Big Data.

Most BPM platforms have built-in capabilities to collect process parameters and key process related data during process execution. Most also provide some form of rudimentary to sophisticated analysis of the data, perhaps not run time, (yet), but on a post facto basis.

Process owners use this data to gain insight into the process, for example:

Which BPM Modeling Notation Should We Use?

Author(s):

Shelley Sweet

Faculty Member, BPMInstitute.org and President, i4 Process

Should we use flow charts, swim lanes, value stream mapping, proprietary software notation, or BPMN? Yes, there a number of notations you could use, and you want to pick the right one for your organization.

The first question to ask is what is the purpose of the process diagramming notation? Since there are several purposes for process diagramming at different stages of a BPM/ process improvement project, you may switch to one type of notation or another at different times.

Purpose 1: A high level map to scope the project and as part of the charter. Here I suggest using a simple flow chart with 6-10 steps using rectangle for activities/steps, diamond shaped decision diamonds and directional arrows. You could actually create it in PowerPoint, but I usually do it in Visio. The purpose of this map is to get people understanding what a process looks like.

A high level process map is:

Business-IT Aggregation versus Alignment

Author(s):

Drew Guitarte

Enterprise Business Architect, Wells Fargo & Company

Business and Information Technology (hereafter referred to as business-IT) alignment is so passé. Welcome the (relatively) new concept called Business-IT aggregation. The phrase “business aggregation” sometimes refers to a corporation that’s controlled by several key investors tasked to manage the corporation based on a succession plan. The word “aggregation” means the sum of the parts, the totality of components, or simply “the whole”. One dictionary (AllBusiness.com, 2010) defines it as “any bringing together of parts or units to form a collective whole.”

Why Johnny Still Can’t Write Rules

Author(s):

Brian Stucky

Managing Director, Business Decision Management, Allegiance Advisory Group

Business rules administration constitutes the core value proposition of any advanced business rules management system (BRMS) solution and, quite often, represents the holy grail of enterprise BRMS implementations. With the promise of propelling IT into an agile, flexible, and faster policy deployment environment, business rules administration capabilities often serve as key drivers for many cost benefit cases. However, less than 60% of these implementations actually leverage the full promise of BRMS offerings, ending up by managing business rules projects much like any other conventional software project. More importantly, business rules are too often not managed by those who should be empowered to manage them – i.e., business owners and stewards. Why does this happen?

The ‘Understand’ Phase of Development

Author(s):

Larry Cooke

Principal, LH Cooke & Associates

This article covers an issue within Business Process Management (BPM) redesign which is often not fully discussed. Frequently, development groups are eager to get the team fully engaged as quickly as possible. Looking at “as is” situations (examining, modeling) may receive slight attention as being “bygones” – “Let’s start with a clean slate.” The issue is deciding how quickly to begin computerized development after a project or analysis has been scheduled.

There are different aspects of business growth and development. One faction may wish to apply technology to change its business as quickly as possible, while another may prefer to proceed cautiously and methodically, moving only after research and through using a well-tested methodology. Which is correct? The classic answer is “It depends.”

Human Risk Biases

Author(s):

Larry Cooke

Principal, LH Cooke & Associates

Except for natural disasters such as earthquakes, floods, or hurricanes, all risks are man-made. This article is a synthesis of three past Harvard Business Review articles. The bibliography is at the end of the piece. Project Managers (PMs) usually have very little control of the risk circumstances in which they are placed. Taken together, viewing risk from the combined perspectives of the authors cited should help PMs assess risk in their own environments. Summarizing the titles as follows: “Right Risks,” “Is it Real?” and “Hidden Traps” will help us consider the contribution of each, and then meld them into the PM’s decision process.

The Right Risks

Launching a Business Architecture Community of Practice

Author(s):

Atul Bhatt

Principal Archtiect, Wells Fargo & Company

Business Architecture (BA) is no longer just an emerging discipline or an “interesting concept”. It is increasingly being leveraged by enterprises to provide tangible value. And within Wells Fargo, Business Architecture has been gaining momentum, slowly but surely, through the activities of a growing BA community, involved in numerous efforts in or related to Business Architecture.

First, let’s define Business Architecture. The following is a consolidation of several definitions that have been around in the industry, and it captures quite well the quintessence of BA:

Business Architecture is a disciplined approach to creating and maintaining business-specific artifacts that serve as a formal blueprint for the planning and execution of strategy across the enterprise.

BA covers the following major areas: