BPM.com
  1. Peter Schooff
  2. BPM Discussions
  3. Tuesday, November 12 2013, 09:54 AM
  4.  Subscribe via email
An idea that Ian Gotts discusses in this blog about social, so when implementing a BPM project, does it still require a leap of faith on the part of the enterprise?
Patrick Lujan Accepted Answer
Blog Writer
No, just the usual stuff it takes to successfully deliver an initiative.


Sponsorship
Business participation
Good project management
Technical acumen
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 1
Garvin Fouts Accepted Answer
Blog Writer
The usual stuff Patrick mentioned. Even then, domain expertise is often overlooked when looking to shave costs on the project. I can't tell you how many projects I am brought in to rescue or correct thanks to going with the 'Vendor' option or a commodity service provider. It almost always comes back to bite the firm and the vendor themselves by having an unhappy client.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 2
Theo Priestley Accepted Answer
Blog Writer
To paraphrase a quote about taking that leap:

"Ultimately, when you're at the edge, you have to go forward or backward; if you go forward, you have to jump together."


And that takes 3 of the 4 points that Patrick makes (not so much the technical acumen), starting a BPM project is a group effort. Faith is only involved when you don't actually plan and have a goal in mind and unfortunately you can't succeed with a project if you don't know what the outcome should look like.
Comment
Sorry, gotta disagree on that last. "Technical acumen," "domain expertise," etc. singularly kills more BPM projects' success than all other factors I've seen over the years combined.
  1. Patrick Lujan
  2. 3 years ago
  1. more than a month ago
  2. BPM Discussions
  3. # 3
Tim Huenemann Accepted Answer
Blog Writer
I think the scale of the leap depends on the scale of the project, just like any other project. What benefits are you seeking or promising? What investment is required? Your faith can be supported and justified. If you're talking about putting in a BPM technology platform without any specific predicted or planned benefits, that is indeed a leap of faith, and often an foolhardy one.

P.S. In all seriousness, I find that it often helps to not call it a BPM project.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 4
Lloyd Dugan Accepted Answer
A BPM project is a journey of discovery and destination. Clearly, as has been said, the goal (destination) needs to be known; otherwise, you're just wandering around. However, the sophistication of the instrumentality for defining the goal (destination coordinates) and mapping the course to it (the journey's direction) have a profound impact on how well the trip can be planned.

It could be argued that the principal difference between ocean crossings today and hundreds of years ago is that the instrumentality is better as is the capabilities of the ships themselves. So should BPM projects be nowadays relative to what such efforts would have been called decades past! But is this actually the case? Or has an over-reliance on instrumentality and vendor-driven pronouncements about capabilities worked against this result? For in the end, every journey is going to run across the unexpected and the non-conforming. One might even be tempted to say that unearthing this stuff (like missed requirements or technical issues) is almost as important as reaching the destination itself.

I would suggest that this is the leap of faith aspect implied in the linked blog entry. Any project will encounter that moment on the journey "map" where it says "beyond this there be dragons" and have to decide what to do. The leap is to launch the project knowing that awaits regardless of what you do.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 5
Keith Swenson Accepted Answer
I certainly does. Any technology that supports the interaction of people will naturally change the way that people interact, which in turn changes the requirements for the implementation, which changes again the way that people interact. We always talk about the "as-is" and the "to-be" vision. It is clear that "to-be" is not the same as "as-is" due to intended change to a better pattern, but what we can't precisely predict is the "as-it-ends-up".

Any good BPM project will recognize that it is a journey, a voyage of discovery. Will you discover something better than you had before? That requires faith that when you get in the middle of change, you will be able to take advantage of the benefits, and to leave behind the things that do not work. It is a real collaboration, and it may lead you, as Lloyd puts so well, "off the known map". The biggest enemy is fear of failure, and that is where a healthy dose of faith can make the difference between success and getting lost.
References
  1. http://social-biz.org/2011/01/06/social-bpm-vs-collaborative-planning/
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 6
David Chassels Accepted Answer
Certainly should not be. Armed with a tool that reflects how people really work and interpretation in their language to build the process will quickly remove the general fear and cynicism that come with most "IT" projects!
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 7
Bogdan Nafornita Accepted Answer
For me - no, there should be no leap of faith, unless one believes that BPM is one of those magical, unexplainable technologies that has suddenly descended from the immortals.

But, at the same time, I feel the discussion should be richer.

What if, for a customer, the project requires a leap of faith because of completely different reasons from the BPM technology itself:
1/ political positioning inside the organization
2/ lack of C-level sponsorship
3/ resistance to change
4/ lack of resources for both implementation and support
5/ lack of understanding of the project benefits

Does it make sense to still do the project if the customer is not ready?

A possible answer is: it depends on your sales model.

If you have a high-touch sales model, with sales reps visiting decision makers, running slide decks and selling big, one-time projects, it probably makes sense to invest in customer readiness.

Conversely, if you have a no-touch or touchless conversion sales model, you shouldn't invest a cent in sales and just go with marketing, inside sales techniques, freemium arrangements and let the customers / employees talk up your product.

At least that's what Clayton Christensen recommends and I am not going to disagree with him any time soon :)
Managing Founder, profluo.com
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 8
E Scott Menter Accepted Answer
Blog Writer
If it's your first one: sure. You may have a vendor you haven't worked with before, an untested technology, and an imperfect understanding of your business process and how it will translate into a set of BPM forms, workflows, business rules, etc. You may be uncertain as to the level of skill required on the part of your staff, or how you will divide implementation between your team and that of the vendor. You may be trying to understand the trade-offs between deploying in the cloud versus on-premises; even if you've settled on the cloud, you may be working out the difference between multi-tenant, single tenant, and business process as a service.

The magnitude of the leap (on a scale of, say, hopscotch to Snake River Canyon) depends primarily on the amount of advance effort you've put into understanding these questions and the resulting level of confidence with which you embark on the project.
http://www.bplogix.com/images/icon-x-medium.png Scott
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 9
Scott Francis Accepted Answer
Blog Writer
If you don't understand what you're doing, it takes a leap of faith. If BPM looks like magic, its a leap of faith.
By way of example, for some of our customers, they have rational and logical reasons for believing in BPM, and reams of data to support their reasons. But they have had a bad experience with, agile development, for example. And so it is a bit of a leap of faith that this NEW vendor can do agile the right way, or that this new vendor can teach them the basics so that agile isn't just "an excuse to be undisciplined."

Ideally the leap of faith isn't required, but when it is, try to scope it down to as small an area of concern as possible, and then explain the path to demystifying that leap of faith ASAP.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 10
Any sufficiently advanced technology is indistinguishable from magic.
Arthur C. Clark.


This is the quote with which I began my book on BPM (in spanish; http://www.BPMteca.com). Since I read it, I always thought it was very appropriate for BPM.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 11
Michal Rykiert Accepted Answer
Sure it does, but which investment doesn't? The great thing about (most) BPM platforms is, that you can start with one simple process, make people comfortable with a new solution, then implement another, more complex ones.

From my perspective, this is very common scenario and a wise one. People are usually reluctant when it comes to change something. But when change brings improvement, then its way easier to introduce another changes with the same tool. Therefore BPM(S) requires certain level of trust, but at the same time it doesn't have to be 'all in' project.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 12
I would add to Patrick's list a still "unusual" stuff in the BPM domain - architecture. Thanks to the nature of BPM as a "coordinator" of many things (or artefacts) within an enterprise, a proper BPM architecture helps to explicitly link and enact/animate their work together thus making the expected result more tangible and more probable.

Thanks,
AS
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 13
  • Page :
  • 1


There are no replies made for this post yet.
However, you are not allowed to reply to this post.