We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.
Start a Discussion

How do you prevent BPM from becoming just a bunch of projects?

Vote 0 Votes
As Dr. Sebastian Stein writes in this ARIS blog, Is BPM just a bunch of projects? "BPM is often not handled as an enterprise-wide effort, but instead just as a bunch of projects. Each project is only concerned with solving its project problem, but not with maintaining an enterprise model." So how do you prevent BPM from becoming just a bunch of projects?

11 Replies

| Add a Reply
  • The assumption here is that "a bunch of projects" is a bad idea. In reading his post again I think what Dr. Stein really cares about is the need for a single repository and that I am wholly in favor of creating.

    So let's explore these two threads: the idea of broad, cross-department, multi-functional, highly integrated business process automation is both exhilarating and terrifying at the same time. Exhilarating because it would be a very exciting project to work on, would last for years and would demonstrate how much can be achieved by end-to-end automation. And terrifying because that much revolution, all at once, is never successful as the human change management is nearly impossible to handle.

    Evolution, "a bunch of projects", is a better approach. Quick wins, celebrate the victories, and have a team in place to drive to common look and feel, a common ontology, a common methodology: all the while keeping an ever watchful eye on the needs of the individual businesses. This works best.

    As for the common repository: this makes a lot of sense. Having a common tool for the implementation of automation makes the common repository not only possible but inevitable.

    But we are often faced with having different automation tools for different needs. High performance, transaction processing tools in the data center, light-weight, usability-centric tools in the business. In this case it is essential to have tools with open, web-services-based interfaces so that a "single virtual repository" (SVP) can be created. A SVP allows data in one tool to be mined from the other, allows events in one to trigger actions in the other and allows dashboards in both to report on states maintained in both.

    Over time, with a web-services-based integration between and amongst tools, tools can be replaced and updated with ease. Once again this is an evolutionary approach. Vendors who talk about "ripping and replacing" the existing infrastructure never factor in the cost of that change. Remember: business first, process second, tool last.

  • It's OK to deliver a local solution for an urgent business pain. Broadening the scope too wide too early is the sure way to hell paralysys by analysys.

    From the other hand, by choosing the quick and dirty solution we get into technology debt which - if not perceived and monitored - may become a problem itself.

    "Time to throw stones and a time to gather stones."

  • I tackled this exact question yesterday with a customer fearful that his very motivated and excited process team would start too many projects and get out too far ahead without the proper training/resources/standards in place. It is a real concern becuase as you know BPM can do lots of things, so without proper guidance/priortization teams get started on projects that should be postponed for others.

    With the customer we talked about creating a COE so as to do three core things: 1) ensure proper training and talent development, 2) priortize projects, and 3) standardize development of process models and web apps.

    Reigning in maverick developers is possible but really requires an active executive team and hands-on project managemnet.

  • Having TOGAF under the belt I know we're not looking into process architectural territory (yet) but it's getting close to it. Entangled in processes are controls, risk and compliance measures, regulation, continuity plans, collaboration with business units, service management, people, change…the list is inexhaustive.

    If I build a house I need a foundation, bricks, cement, timber frames, steel rods yadda yadda. Everything pretty much plays its part in ensuring that the house is stable and robust, and so your enterprise is stable if we translate that into a real process strategy. If you build a house without cement then it's not safe. If you create a process without controls or compliance it's not safe. Similarly if you materially change the house, knock a wall in or extend it for example you're going to need planning and understanding of how that change will affect every part of the house.

    And there's the crux of the argument. With so many processes intertwined to create the fabric of a business entity if you change one without a proper management or planning strategy in place do you know the impact of that alteration across the organisation ?

    Now we get to IT. It's the plumbing system, the heating system, the electrical wiring of the house. It's another level entirely but still integral.

    Then there are the occupants of the house, what happens to them, how are they affected ?
    Rip out a wall and where do all the pipes go, the wiring extend to ? Build a new room and the occupants have something new to explore and utilise.

    You cannot conduct BPM piecemeal as a collection of projects with no connection which is why BPM needs to adopt more a process architecture approach when looking at organisational change. Let the likes of Six Sigma et al pick off the "improvement" projects that look for incremental gains and leave the wider scale impacts for BPM.

  • As with most Enterprise scale questions, there's no single answer to this. I agree with all the answers provided by the experienced practitioners, Kevin, Theo, Garth and Anatoly. You need technological architecture tied to the Business Architecture, which is too vague and long-term-ish, and you need quick wins, singles & doubles to continue scoring and laying down the foundational work in parallel.

    The key also lies in the way Business and IT are structured, and how BPM initiatives are run. Many large successful BPM initiatives are not even named as BPM initiative, but tied to an end goal such as improved customer experience. "The business end-goal ties the projects to Enterprise scale, not a term like BPM."

    I think I summed up some of my thoughts on this here - http://ashishbhagwat.wordpress.com/2010/03/20/how-important-is-it-to-qualify-an-opportunity-or-solution-as-bpm/

    And from a BPM discipline and technology standpoint, Governance is the key, as Garth noted. I know there are many who don't like the word CoE because of so many bad implementations of the same around, but I believe that without a proper governance model that is suitable to your organizational culture and structure, you cannot achieve an Enterprise level BPM success. http://ashishbhagwat.wordpress.com/2010/02/25/which-flavor-of-coe-is-right-for-your-enterprise-bpm-strategy/

  • BPM can be, just a bunch of projects, if you want to fail.

    If you want to succeed it must be managed. If naming semantics are an issue, e.g. CoE, then call it something else. The point is, it is a part of what must be done if the expectation is success.

    The comments around doing projects in isolation are spot on. Projects done in isolation almost always result in unintended consequences. The unfortunate fact is, not even these unintended consequences are realized immediately because the process work isn't a coordinated effort.

    I'm not usually one to get too caught up in terms, but if BPM stands for Business Process Management, which I assume is a common definition, then what is management if not a coordinated effort to plan, control, etc...

    These, one-off, projects happen due to laziness and/or ignorance. The people involved in them either don't want to take the time to do it right, and/or don't know how to do it right. You only need to really understand process to know that nothing in an organization happens in isolation. It's impossible to change one process without effecting others in some way.

    Quick wins are often an excuse to do this "project" work. While it's true quick wins are critical to the success of most process projects for motivation and exposure purposes, they don't need to occur in isolation. Just as many quick wins can be identified and implemented in well organized and "managed" projects as are found in these other type of "projects".

    Back to the point, how do we prevent BPM from becoming just a bunch of projects?

    Process Management starts at the top and the beginning. It starts with understanding the organization's overall strategy, stakeholders and their expectations. That knowledge is then aligned with an understanding of the organizations processes, taking into account the organization structure, human resources(motivation, skills and capabilities), other assets of the organization, technology, business rules, knowledge,and policies. A proper analysis of that alignment results in the exposure of those processes that are not well aligned and require improvement in order to add value to the organization. As a result of that analysis, projects are identified to address these process issues. Those projects become part of a program of overseeing all process work. In addition, those factors (outlined by Garth) normally considered part of a CoE or Center of Excellence are developed and implemented.

    It is true that a common repository for all this information is extremely helpful. However, this work is not dependent on the use of technology. It's much harder to coordinate, analyze and implement without the use of some kind of common repository but it is possible. My fear is that technology becomes part of the conversation too early, and the focus on the business is lost. I have seen this occur over and over with many of my clients. I have seen people buying technology solutions before they even know how they are going to approach the work then gathering information and entering it into "tools" without even knowing why. As with any process solution, the framework for the who, what, where, when, why and how should be in place first, then technology can play a much more valuable role in the success of the work.

    IMHO :)

  • The key to avoiding many small projects is to avoid many small products and many small perspectives. Avoid to think in automation projects that are justified by a cost-cutting ROI. Think in a larger Business Architecture.

    The essential approach must include the continuity of process creation and adaptation by the business users as part of the technology infrastructure and yes, that requires a central virtual repository.

    A Process CoE will do nothing else than to manage all the 'process projects' and simply creates a lot of additional bureuacracy and is thus the anti-thesis to user empowerment.

    As it happens, you need technology as an enabler for such a larger empowerment perspective. You can talk about flying to the moon, but if the spaceship can't be built or if people won't be able to fly it, it will remain all talk. So go and find the technology that will enable and empower your people, not IT, not analysts and not the PCoE. Empower people from top-down and bottom-up.

    And while you are at it, how about empowering your customers to participate in your processes? Once you consider that you can forget all the small process projects. BPM becomes a single larger empowerment perspective. It is no longer about command and control but about giving customers a choice in their outcomes.

  • 2 years ago I wrote a blog post which kind of relates in a way to the same issues: most traditional BPM/ process project attack the problem in a piecemeal fashion with a 'bottom up' approach and no understanding of the end goal at a strategic level.


    So, do we look at BPM from the top down or bottom up ?
    Or somewhere in the middle ?
    Or just not at all and use architecture as the glue and transparency ?

  • As a vendor, when I hear a potential customer proposing an “enterprise modeling” effort or “BPM Platform Section” project I run for the hills! My history shows that this is a road to disappointment, low value and unhappy customers.

    “BPM Platform Selection” IT projects are just that, IT projects— not business projects and not even business process projects.

    The customers who receive the most value from their BPM and modeling investments share two traits:
    1. They begin the journey by fixing a well-known and widely agreed upon business problem or are looking for a strategic advantage. For example, does your organization have 10,000 new customer account processes and want to consolidate to less than 6,000 (a real process problem we are working with a customer on)? Is your sales order processing system still glued together by spreadsheets and e-mails?

    These are two examples of where organizations have come together, agreed on the problem and then turned to modeling to capture, analyze, and optimize the moving pieces and BPM to carry this forward to a repeatable and improved state.

    2. As you are incrementally achieving the first trait, it is critical that you learn how to evolve a Modeling and Process Centers of Excellence (COE). This is where I think Dr. Stein’s point about the cross-process view comes into play. By leveraging a COE, you can use your experience to build a methodology and a cross-organization view as each new modeling and process project proceeds. The COE uses the cross project view to regularly improve the methodology, establish a central repository of re-usable objects, and set flexible standards. I call this “harvest and re-sow,” where the COE harvests models, objects and even whole processes. In my experience you will end up with a hierarchy of repositories – not unlike Mr. Parker’s “SVP” – where objects and information flow “up” to a shared, cross-organizational/project repository while reusable objects, shared goals and measurements, and standards flow “down” to process projects as building blocks.

    It is possible to start a COE from the beginning and we have helped a lot of organizations do this – the key is to maintain the focus on a concrete business problem. One good example is a COE that includes two groups, one focused on building a process portfolio and the other applying BPM to solve a defined business process problem.

    We have customers who have many independent but highly coordinated modeling and process execution projects running. Several of our customers have modeled, optimized, and deployed 100’s of BPM-enabled processes, so I have seen our approach deliver extremely high value.

  • I interpret “BPM”, mentioned by Dr Stein, as “enterprise BPM system” - a portfolio of the business processes of an enterprise, and the practices and tools for governing the design, execution and evolution of this portfolio.

    From the end-users point of view, enterprise BPM system is built as a bunch of projects – different user’s departments will absorb this BPM with different speed and, by definition, in several steps.

    From architecture point of view, enterprise BPM system can be built via PEAS enterprise pattern -- see http://improving-bpm-systems.blogspot.com/2011/04/enterprise-patterns-peas.html


  • I understood the article as not about a bunch of projects, instead the issue is structure of information or the lack of, what BPM strives to alleviate. We have such environments because of the absence of understanding BPM and what it entails…to provide a holistic management approach focused on aligning all aspects of an organization with the wants and needs of clients. It promotes business effectiveness and efficiency while striving for innovation (compliments of wiki). This includes IT. There has to be processes and policy for the management and use of applications to include a central repository for BPM initiatives; an enterprise level process and policy for executing BPI/M initiatives based on an enterprise defined criteria and approach. The latter will remove silo attempts and foster collaboration among business units, to look at the enterprise as a whole, to generate an understanding of corporate culture, business rules, decision flow and the value stream. It is impossible to have an enterprise level strategy for effectiveness, innovation and efficiency with fragmented systems of possible redundant information.

Add a Reply

Recently Commented On

Monthly Archives