BPM.com
  1. Peter Schooff
  2. Sherlock Holmes
  3. BPM Discussions
  4. Thursday, 15 November 2018
  5.  Subscribe via email
From Emiel Kelly: When a customer orders something, you might ask him a lot of information, but it might be possible you don't need all this information at the start of a process. Maybe you need it later, or it might even possible (because of some decisions) you don't need that information at all. What do you think is the best approach? Overask (and maybe annoy) the customer at the start of the process or contact them every time (and maybe annoy) you need more information?
Accepted Answer Pending Moderation
Typically, we try to get a lot of information in the first few weeks of analysis, but the reality is most customers don't truly know their process when we first start engaging with them. Other information will come out later as we "play" the process back to them and they get "aha" moments. That is a big part of the "process" of process analysis. One thing we always try to get up front is customer expected outcomes along each step of the journey, and the overall expected outcome (some people would could this capturing the value you want to deliver). This helps guide the process analysis and keep us pointed in the right direction.

So, for us, I guess the answer is yes to both parts of the question :)
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 1
Accepted Answer Pending Moderation
Great question Peter...

Participant input can come at any time, no matter what the process owner desires.
Looking back over my experience implementing processes with BPMN-based tooling, I think that's been the number one limiting factor to success.

There aren't clear cut "phases" for preparation vs. evaluation... During the evaluation the parties may realize that they're missing something that requires them to prepare a bit more... Messy as hell, but that's the reality that we have to deal with.
Founder at John Reynolds' Venture LLC - Creator of ¿?Trules™ for drama free decisions
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 2
Accepted Answer Pending Moderation
The question is very case sensitive and depends a lot of the type of delivery/ordering process we are talking about. If the case is simple so that the customer knows what he wants or needs and the service is simple something like delivering a dress, food or books.... we may want to design the ordering process so that it is easy and fast.... the aim is one "click". To design this type a process we might need think about, how the process gathers information and learns customer preferences and earlier touch points.

If the service is more complicated such as delivering customized and personalized services such as health care or banking, we really need to look into the customer data and try understand the specific situation and goals of the customer. We may need to design a interview (or needs assessment) phase before even thinking the delivery.

And in even more complex cases such as delivering IT-system or housing we need to design the delivery process as a learning process. At the beginning we and the customer don't know what are the real needs. In this case the agile approach with prototypes, demos and small experiments might be best.

An other aspect of designing the customer interaction in delivery or any other process is to think about emotional perspective... we should design the process so that customer feels herself respected and valued. e.g. I'm very enjoyed if the supplier ask me something they should already know or I have feeling, that this is irrelevant in my situation....


br. Kai
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 3
Accepted Answer Pending Moderation
I gather “orders something” implies providing a deliverable, possibly:

1) a BPM process map
or
2) a workflow/workload run-time platform where users will see efficiency improvements as a result of some of the work (structured work portion) being guided by background BPM (instances of a compiled, rolled-out BPM process map template).

If my interpretation is right, we can exclude from this discussion management consulting engagements where the deliverable is a study report (lots of info would be needed here, up-front) and we can exclude on-site “work-for-hire” engagements (very little up-front information needed).

Re deliverable #1 – the info needed here is who are the process stakeholders?, how often can they meet?, for how long? Can they provide images of all forms relating to the process that are currently in use?

I am not a fan of putting a consultant on-site to gather information, then going off-site and coming back days/weeks later with a mapped process.

Better to dispatch a facilitator to the site for a day or so to host live process mapping sessions with stakeholders, with the balance of mapping done off-site in GoToMeeting sessions, 2-3 times a week or, every day, for, say, one hour. (most customers want/expect instant gratification; most customers have short attention spans).

As @Brian points out, “ . . .most customers don't truly know their process when we first start engaging with them”.

This is especially true in the area of putting in place “branching decision boxes” along a workflow and even if a customer can explain when/why the processing needs to go this way instead of that way, it’s unlikely many will be able to build the required rule sets on their own.

Re deliverable #2 – this is a traditional “make/buy” exercise and needs LOTS of info up-front plus advice on the dangers of any “make” option.
References
  1. http://www.kwkeirstead.wordpress.com
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 4
Accepted Answer Pending Moderation
As a customer I would like that any communication from a service provider is well justified from my point of view.

Thanks,
AS
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 5
Accepted Answer Pending Moderation
Excellent UX question.

The default should always be to minimize the up-front collection of data. When determining what information needs to be collected at the earliest stage, ask yourself these questions:

  • Necessity: Do you need this information right now?
  • Inevitability: Are you going to eventually require this information, no matter what transpires in the course of the transaction?
  • Relevance: Is the need for the information obvious to the customer at the beginning of the transaction?
  • Perceived Effort: Does the customer perceive the additional effort involved in providing the information to be minimally burdensome, so as not to impact the likelihood that they will want to continue the transaction?

The degree to which you should resist the impulse to request information up-front is proportional to the number of "no"s in your answers.
http://www.bplogix.com/images/icon-x-medium.png
-Scott
Comment
  1. John Morris
  2. 1 month ago
  3. #5810
+1 @Scott re: "Perceived Effort". The cost of the work required!
  1. more than a month ago
  2. BPM Discussions
  3. # 6
Accepted Answer Pending Moderation
"From Emiel Kelly: When a customer orders something, you might ask him a lot of information, but it might be possible you don't need all this information at the start of a process. Maybe you need it later, or it might even possible (because of some decisions) you don't need that information at all. What do you think is the best approach? Overask (and maybe annoy) the customer at the start of the process or contact them every time (and maybe annoy) you need more information?"

Some of the answers appear targeted at projects (when in the project should i ask for the information). But I think the original post is directed at someone's final customer. When ordering something on my website, when should I ask for their information, and for how much at each stage? And what if I ask for too much information too early that turns out to be wasted?

The best answer is to conduct some research with real people going through the process and documenting how they feel about the information requests. Pilot various approaches of collecting that information and see which ones yield the best result in terms of the consumer's/user's feelings about the experience.

Failing that, or having less budget, say for a less consumer-oriented approach, we can take some other principles in mind. From lean-six principles, overproduction is one of the kinds of waste to be avoided. So don't ask for the same information more than once, and don't ask for redundant information (which could be entered differently if entered manually), and don't ask for information you may not need. Lean-flow might argue that we should only ask for information when we need it.

Having said that, we have to balance that "just in time" approach with not making our consumer feel like they're being harassed by constant requests for dribs and drabs of info - they might prefer to provide it all at once.

Compromises: request the minimum information, and offer the consumer the opportunity to enter more comprehensive information at any time. When asking for more information for, say, the third time, have a team member reach out to them to apologize for the necessity but to personalize the experience and make them feel welcome.

The goal is not to ask for information before the consumer has indicated that they are ready to provide it. If you ask for contact information before someone can read your blog - no one will read it. If you ask afterward, as in having them subscribe to receive it in your inbox - maybe they'll have a basis for judging whether the exchange of value is fair. Where exactly that line is in any process is a judgment call - but it can be verified or improved upon with a little A/B testing and research... (pssst, this is work that our team is qualified to do if you need help) : )

scott
Comment
  1. John Morris
  2. 1 month ago
  3. #5811
+1 @Scott -- applying principles of manufacturing to the question of feeding an information process. But not stopping there -- re: the customer's "feelings" -- in other words the process participant's perception of participation costs is not the same thing as actual costs.
  1. more than a month ago
  2. BPM Discussions
  3. # 7
Accepted Answer Pending Moderation
Funny to see how this question is interpreted in 2 ways. I meant it as Scott Francis stated: 'But I think the original post is directed at someone's final customer'

Also nice to see how a day to day problem (at least for me) is tackled.

Thanks all
Sharing my adventures in Process World via Procesje.nl
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 8
Accepted Answer Pending Moderation
Here's a perspective based on the "Scott Francis Interpretation" of the question. What can be said about the timing of the acquisition of process-driving information as the process unfolds?

Consider "#customerJourney" and "#jobsToBeDone" and "uncertainty". For a customer to participate in one of our processes is a cost to the customer. The customer balances this perceived cost against the value of the outcome of a successful process.

Example (from Scott): We've learned not to ask for too much information from a visitor, when offering a white-paper. 20 fields? Cost too high. Goodbye. Cost higher than perceived benefit.

To acquire information is to reduce uncertainty. We need some information in order to move the process forward. To do our job in support of the customer doing their job. The process is from the customer's perspective the customer journey. Note that customer journey is still "our POV". The job to be done is the customer's POV. But we can only indirectly imagine the customer's POV.

So, early or later information acquisition? How about: The minimum required information in support of both parties moving the process forward "with certainty".

This rule however must be adjusted to account for information acquisition cost. As mentioned by Scott above, ( "dribs and drabs" ), the cost to information provision may be much lower if we do it all at once. Which presumes a level of trust and commitment on both sides.

An extreme example of information provision "all-at-once" is the dreaded RFP. Very high cost -- and very high uncertainty. (Unless a lot of golf has been played.) Another early collection example is income taxes. High costs. Little choice. Low uncertainty.

The point is that information acquisition timing is balance of trust, cost, perception, utility, uncertainty -- and power.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 9
Accepted Answer Pending Moderation
OK , going with the "Scott Francis interpretation", and "When is the best time. . . " . . .

It looks like Emiel's question resolves to how do we handle "need-to-know" communication (inbound and outbound), with reasonable consolidation of questions to reduce the number of interruptions.

So, the scenario is: I have a workflow, comprising steps, with a "skill" attribute at each step, where some of these steps happen to be customer reach-out or reach-in steps.

Why does it matter whether a party we are trying to communicate with is a member of the organization, a supplier, or a customer?

Here is what we know about customers . . .

- Customers don't like to hear "Your call is important to us . . . " as and when they call in to provide information;

- Customers HATE to have to repeat data they have already provided.

- Customers are comfortable with logging into portals or, for bulk data, linking to/from FTP sites.

Accordingly, my answer to the clarified question becomes "why the question?".

Getting need-to-know information involves nothing more than ensuring that a process step becomes current at the right time and that the step has the right skill and data collection form attributes.

Your run-time platform should be able to seamlessly handle out-reach and in-reach to any class of user, so any concerns, assuming an overall "need to know" communication policy, should focus on deficiencies relating to the workflow/workload platform/architecture.
References
  1. http://www.kwkeirstead.wordpress.com
Comment
  • Page :
  • 1


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