Process management blurs the line between IT and business

IT must fill the void when insufficient attention is being paid to business process optimization.

Business process management (BPM) and more specifically business process optimization (BPO) is about fully understanding existing business processes and then applying agreed-upon improved approaches to support market goals. Rather than exploring BPO from the viewpoint of the business, here I’ll briefly explore some of the motivations and benefits from an IT perspective.

Almost every business change has a technology impact

There are very few IT systems today that exist in isolation within an organization. Systems interact because they often require data from each other and they are interdependent in terms of sequential steps in a business and technology process. As a result, a change in one system invariably has a downstream impact on one or more other systems or processes. Often, the consequences of these changes are poorly understood by both IT and business stakeholders. Put another way: in interdependent complex systems and processes, there is seldom the notion of a small change.

Once both IT and business stakeholders recognize this, there is an opportunity to turn it into a highly positive outcome.

IT must be perpetual teachers and learners

As is the case in achieving many of the objectives of an IT strategy, it begins with communications. Every contact between IT and the business is an opportunity to teach and to learn. This is a reciprocal interaction. When I hear or read a sentence that begins, “Could you make a small change for me…” I know we’re already starting from a bad place. Unless the requester fully understands the internal complexity of all the interdependent systems and the potential impacts (which is rare), it’s presumptuous for him or her to estimate the scale of the change. Conversely, any IT person who minimizes the impact of a change without fully understanding the potential impact does a disservice in setting expectations that may not be met.

For IT requests, it’s best and safe to assume that a change will have impact, but the scale of that change will not be known until reasonable diligence is performed. That’s a much better starting point.

Let’s now assume that the change is not inconsequential. Two opportunities present themselves.

IT is an important business facilitator

First, stakeholders that are impacted by the change should be brought together to discuss the impact. I’m always surprised how these meetings reveal gaps in everyone’s understanding of business processes between departments. To me, this is where IT can shine as the connective tissue within an organization. More than ever, technology forces organizations to better understand and agree on processes — and that’s often well before the subject of supporting technology is even relevant to the conversation.

Use this opportunity to surface the entire process and for everyone to understand the impacts of any change. Improvements to the process very often emerge. IT has suddenly motivated business process optimization.

There is no such thing as too much process documentation

Second, assuming no documentation exists, this is the right time to map the process. If you’re like many organizations, your IT systems grew organically with little emphasis placed on business process design. My guess is that comprehensive, high-quality, current process documentation is uncommon. It’s never too late to start. If you have business stakeholders in a room discussing and agreeing on the current and future process, this is the time to document it. There is a burgeoning market for tools and support to help enable and simplify this work.

Ultimately, documented processes make it easier to build the right software and to make changes with less overhead activities in the future.

The essential roles of business analyst and solutions architect

It’s this emphasis and attendant benefits of understanding and documenting business processes that supports the expanded roles of both the business analyst and solutions architect. These two roles, and having the right amount of capacity for your organization’s demand, will be essential to succeeding with your IT strategy and in growing the business. In many organizations, the business analyst for this work may or may not be in IT, thus further blurring the lines between where IT starts and ends and where business responsibilities start and end.

Perhaps it’s possible that in the not too distant future we’ll look at IT as part of the business and not as a separate entity in the manner it is today. It just might be the increased emphasis on business process management that acts as the catalyst.

Related:

tags: , , ,
  • NNM

    “Ultimately, documented processes make it easier to build the right software and to make changes with less overhead activities in the future.”

    This is actually false in my daily job. No matter how much you document processes, or how detailed the processes you receive are, there is always an infinite amount of “exceptions”. And these “exceptions” are really 95% of the job. The simple main processes are clear, perfect, and are easy to understand. Bt the exceptions ruin everything: you cannot assume anything from clearly documented procdesses.

    When starting a project, it works out much better to focus on the users, the people who know what they are doing, to listen to them, and make sure their needs are all met, and that you are aware of the big picture. What I call “the big picture”, is what you call “documented processes”.

    But interesting article, even if I disagree with “overoragnizing”; I still see it as a huge waste of time that managers love.
    Take it as it comes, improvize, ADAPT.

  • Ultramog

    +1 for NNM
    More extensive docs are less relevant by the time process is implemented. Business requirements come first, dev needs to meet those needs ASAP for speed-to-market advantage. If you’re good you can deliver before the requirements change. Otherwise you’re in documentation limbo and nothing gets finished.

  • Peter Elias

    Some nice thoughts here. I like the idea of IT as perpetual learner/teacher. But I believe the underlying premise is absolutely untenable.

    “Rather than exploring BPO from the viewpoint of the business, here I’ll briefly explore some of the motivations and benefits from an IT perspective.”

    BPO should be evaluated FIRST from the perspective of the client/product, then the perspective of the user, and only LAST from the perspective of IT or management. In my field, primary care medicine, all processes need to be based on the product (care) and the consumer (patient). The user (physician) is only important as relates to providing care. And management and IT are there to make it possible for physicians to provide care to patients. It drives me nuts to see this reversed, as in this article.

    “More than ever, technology forces organizations to better understand and agree on processes…”

    This is correct but not always good. It is useful to study and understand processes, but the focus must remain on the product and customer, not on the algorithm/process.

    “Ultimately, documented processes make it easier to build the right software and to make changes with less overhead activities in the future.”

    True, in settings where there is a single (or very small number of equivalent) solution(s). In this setting, ‘rule driven’ processes can efficiently and reliably generate the ‘right’ answer. But many fields (such as medical care) require finding or creating a nearly infinite number of individualized solutions for individual patients.

    An article like this should make it clear that this approach is usable only in specific types of business with specific types of product.

  • http://radar.oreilly.com/edd Edd Dumbill

    Great thoughts. I’d like to see you expand more on the ever changing nature of process. One of the difficulties with capturing it is that the day you finish the document, it becomes out of date.

    And if IT facilitates agreements between departments on process, isn’t there a risk that it disables their agility as a by-product?

    What kinds of approaches can provide agreement and understanding, while recognizing and preserving the evolving nature of products and markets?

  • http://radar.oreilly.com/reichental/ Jonathan Reichental

    Excellent comments. Here are some light responses:

    NNM: Sounds like you have some governance challenges at your organization. BPM is not the opposite of agility, but often an important prerequisite to succeed in developing large, complex projects.

    Ultramog: The trick is to find the right balance in your doc creation for the project. For speed-to-market you might go light and do some high-level process maps.

    Peter Elias: I agree that BPM should start with the customer. I took the opposite angle just to illustrate how it is valuable to IT stakeholders too.

    Edd: I address your very point about documentation currency in my previous point on knowledge management:http://oreil.ly/htJAIO. Documenting a process is not an end-state; it needs to evolve at the speed of business.

    Contrary to the traditional interpretation, when done right, BPM enables innovation, it doesn’t hinder it.

  • http://bpmforreal.wordpress.com Chris Taylor

    Governance in particular is critical for any BPM success. That is, having a single, trusted source of truth that all employees can turn to for the answer to the question, “how do I perform this task or activity”. I think a lot of the cynicism towards BPM comes from initiatives tha lacked process governance so that there are multiple ways that employees are being told to do the same task due to fragmented process mapping or documentation.

    And this relates to the second point about innovation. It turns out that employees are actually excited when shown how to do their jobs in properly rather than having to fumble through multiple possible ways to do a task. This leads them to be creative and innovative in ways that matter to the customer rather than reinventing the wheel every time they perform a task or activity.

  • Joel

    Without nitpicking, I find this to be a refreshing view. Professionals with both business and IT backgrounds are quite rare to the extent that they can function as an expert on both sides of the table. Stakeholders would greatly benefit from such a person.

    As for governance, this is most easily overcome by specific, talented project managers for different parts of the project. Don’t forget that the end goal is making it to production, and in order to do so with a great product, you need to provide workers some autonomy and a good feedback mechanism. Too much process stifles creativity. A great team of PMs on a large project would go a long way in keeping messages clear both upstream and downstream.

    The most clearly true point you bring up is to not be a stickler for documentation when timing is everything. Google has proven to us that being agile and first to market can be far more important than complete documentation.

  • http://peter.evans-greenwood.com/ Peter Evans-Greenwood

    +1 NNM

    BPM (with it’s PSI calc and graphical notation) is the last gasp of Taylorism. We’ve spent the last 100 years working under the assumption that you should “define the perfect task, and then fit the man to the task”. This is a view of business – business as programmable machine writ large – which relies of a stable environment to succeed, as it’s focused on the monotonic improvement of capabilities.

    We’ve hit a point where the environment is no longer stable. As NNM points out, most valuable processes are 80-95% exceptions, with few instances following the cow path. It’s not surprising that in the new instability we seem to be living in, that those high-level, end-to-end process diagrams are largely irrelevant before they’re completed. Adding more governance, as some suggest, is not a solution, as it just slows the rate of business change down (that is, after all, its entire reason for being) to a pace that Taylorism can cope with.

    The mismatch between BPM (“one true task”) as implemented and business as practiced (“exceptions define our value”) is the reason that many BPM programmes deliver a solution which “works” in IT’s view, but which the business views as “inoperable” (and then they go back to running the business on email and spreadsheets, as these are tools they can control).

    If we want BPM to move forward then we need to change metaphors, setting aside the idea of BPM as a programming challenge. We need to treat it as a real time planning problem. Some of the newer developments in this space, such as Adaptive Case Management, are a tentative step in the right direction, but there is still a long way to go. It’s interesting that the vendors pushing these products generally target the business, getting BAs to work with business SMEs above the line to define the process (build), with IT focusing managing the platforms (run) below the line.

    As Taylorism fades away, we need to starting thinking about “defining the goal, and then assembling the perfect team to achieve the goal”. There is no one true way to perform a task, and we need embrace the ability to match the way to the goal, given the context we’re currently working in.

    r.

    PEG

  • http://www.taraneon.com Thomas J. Olbrich

    On the face of it, I could agree with most of the statements made here. Anyone who understands that business value is created through processes knows that managing those processes is essentiel – hence the need for business process management.

    But – regardless of who introduces and drives BPM in an enterprise – any BPM intiative comes to a standstill if process awareness among employees is undeveloped. What’s the value of a BPM or BPO project if it’s not understood and handled accordingly during process operations? The numbers we collected last year on process awareness don’t suggest that we are anywhere near a solid basis that could lead us to expect BPO success: http://taraneon.de/blog/2011/03/25/bpm-process-awareness-levels-still-too-low/

    As long as processes are regarded as a one-off affair (design, implement and forget) things are bound to fail. It’s more an issue of developing the right process mindset before setting out on any improvement tasks.

    Thomas