BPM.com
  1. Peter Schooff
  2. BPM Discussions
  3. Tuesday, July 19 2016, 09:07 AM
  4.  Subscribe via email


Do you think people with a background in processes are the best at customer journey mapping?

Emiel Kelly Accepted Answer

I always let the customer do it.
Common Sensei at Procesje.nl
Comment
Patrick,

As always it was with a little sarcasm. But, wouldn't it be weird that a company maps a customer journey without the customer speak up?

I am assuming now that we talk about the as-is customer journey ("dear customer how do you experience the way we deal with you?)

Having said that, asking the customer how he would like to be dealt with, brings us easily to a to-be customer journey.
  1. Emiel Kelly
  2. 4 months ago
But is anybody holding their hand(s), helping them, facilitating, eliciting? If not, I think you get the "cowpath" from John Morris below. @alecsharp's "handoff diagrams" come to mind with an occasional, well-timed "why" interjected.
  1. Patrick Lujan
  2. 4 months ago
  1. more than a month ago
  2. BPM Discussions
  3. # 1
George Chast Accepted Answer

My favorite part of the job, whether focused on those abstract things we call "processes" or focused on the customer or just on the 'things we do' - is to go to the whiteboard with as many of the constituent groups as possible. Inevitably, going back to the days of DFDs, there will be places where the arguments erupt. There are people in all groups who know what should happen and others who know what does happen. There are multiple groups who have their separate dates for any given milestone that actually have different meanings to different people. This is the messy arena of customer facing work. I love it. The customer journey will be a part of that, hence Emiel's response is good for it. But, to nail down the exceptions takes a village.



Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 2

It is NOT important that someone with a background in process does the customer mapping journey.



The fundamental difference between internal process mapping and customer journey mapping is that the level of detail is likely to be less in the case of the latter.



At one end of the customer journey, we have a customer who buys a product like an air conditioner, takes out annual maintenance and unless issues arise (warranty, bad service), there is little contact needed. At the other end of the scale we have e.g. job shop operations where there can be a need for customer contact on a daily basis in the early stages of custom manufacturing.



The best resource for development of internal process maps is a facilitator whereas the best resource for development of customer journey maps is a customer relations specialist.
References
  1. http://www.kwkeirstead.wordpress.com
Comment
Helpful, to have some process background, yes. Not important though if you can send out a facilitator, at least to start things off. You can facilitate at a distance using Webex or GoToMeeting but for any mission critical project, it is best to appear on site for 1-2 days.

And, yes, as well, for "the customer does the execution himself" - however, we tread easily in healthcare (no inreach option), because some patients would upload 50 inquiries per day and seriously reduce the doctor's productivity.

Re outreach, given the near impossibility of hard-coding outreach, we accommodate outreach to a customer at a portal from ANY BPM step or ad hoc step.

One home healthcare services delivery agency has staff who work exclusively in the field - the software posts their daily schedule (2-5 visits per day) - they type in progress notes and upload.

Time is of the essence because one staff member can come in as another leaves - the incoming staff member needs the progress note from minutes ago for continuity of service purposes.
  1. karl walter keirstead
  2. 4 months ago
And even sometimes the customer does the execution himself for a large part.

Customer Journey: All the effort a customer has to take, so we can execute our processes.
  1. Emiel Kelly
  2. 4 months ago
To me the customer and the executor are all stakeholders in the same process, so some process background (not the same as "good in processs mapping") would be helpful, I think
  1. Emiel Kelly
  2. 4 months ago
  1. more than a month ago
  2. BPM Discussions
  3. # 3
Scott Cleveland Accepted Answer

It may not make a difference in mapping their journey, but it can be helpful if you want to improve that process. They may see things that you can't because you are too close to it.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 4
Jose Camacho Accepted Answer

I think it's important to have background in processes for two reasons:



1) Because the Costumer Journey Mapping translates into a process, it is necessary to have knowledge to convert and sort customer contact points with the company in a sequence of activities and decisions, such as a process, which should be modeled on the basis of rules to identify patterns behavior. Otherwise, I do not think that's possible to identify the potential pursued, i.e., to know the patterns of customers behavior in order to provide them with the best offer and increase revenues;



2) Consideration should be someone with knowledge of the internal processes which respond to customer interactions, in order to facilitate the optimization of alignment between customer preferences and responses that the company can offer.
Comment
It seems pointless to try to anticipate all manner of customer contact (reach in and reach out) and set up touch points plan side.

Given there will be no end to a need for on-demand reach out or reach in ,why not just make the run time environment capable of accommodating reach out/reach in at any point along the corporate Case timeline?

Nothing wrong with data mining to identify high-frequency in/out transactions and update process maps to include these
  1. karl walter keirstead
  2. 4 months ago
  1. more than a month ago
  2. BPM Discussions
  3. # 5
Walter Bril Accepted Answer

Well... I always "map processes with the end in mind". And the end in my capturing exercises always mean:
[b]A happy customer, no exception[/b]
.


Efficiency gains are a derivate and never a goal. So... the customer drives the journey, and the process guy facilitates. In other words, drives or captures the WHY...
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 6
John Morris Accepted Answer

If you want to
[u]pave the cowpath[/u]
, by all means then let end-users map the customer journey. At best you'll get
[u]a new cowpath[/u]
.


On the other hand, if you want your process to fail, have IT do it all by themselves. You'll get
[u]a nice road but no cows[/u]
.


So we are between the proverbial "rock and a hard place" (and being unfair to both end-users and IT).


Our answer comes when we ask "
[u]What does 'map' mean?[/u]
" We actually want to map but then
[u]go beyond[/u]
"as-is" to "rationalization" and "innovation". And that means the special skills of the
[u]process technology-savvy business analyst who also is a domain expert[/u]
. The analyst works with both IT and end-users. And provides insight and leadership in dialogue with business. And sometimes business people even do their own analysis (because it's a "role", not a job description). And everyone contributes. 


The analyst knows both sides of the house but (and this is important, because
[u]it means that coders and programmers do not play a big role[/u]
in business process automation) the technology now permits business and analyst to focus most of their attention on business semantics. 
Comment
+1 for "nice road, no cows".
  1. E Scott Menter
  2. 4 months ago
Or "Emiel wants to build a house"


(read on)
  1. Emiel Kelly
  2. 4 months ago
;-)
  1. Emiel Kelly
  2. 4 months ago
Emiel,

All good journeys, for sure! And on these journeys you are the "animated red dot" moving along the in-flight BPMN-based process model diagram (designed together by a business analyst and merchandising manager).

I only wish I had your budget! : )

John
  1. John Morris
  2. 4 months ago
John,

That's indeed another vision on customer journey. To me it's journeys like

- emiel goes shopping at walmart

- emiel buys a new motorcycle

- emiel buys a book at amazon

- emiel buys Chinese rubbish at Alibaba


(Emiel is the customer in these cases)
  1. Emiel Kelly
  2. 4 months ago
Hi Emiel. We could try and define more precise terminology I guess. I'm using "end-user" as a proxy for "vendor business staff", especially non-IT staff. And the "suffering subject actor" of any given customer journey instance is "a customer".

I'm for business "designing and evolving business processes" certainly. Should customers have options, thus de facto enriching their customer journey? By all means, if practical and if it makes business sense.
  1. John Morris
  2. 4 months ago
John,

Looks like you look completely different at what a customer journey is. To me it is "emiel wants an insurance an what does he have to suffer untill he is insured? "

It looks like you see it as something like letting the end users design their own app in a bpm system
  1. Emiel Kelly
  2. 4 months ago
In the context of the question, it's worthwhile to compare business process management automation to accounting.

There are accounting roles ranging from fully accredited accountants (both external and internal) all the way to bookkeepers. But all business people understand accounting and finance fundamentals, in varying degrees.

How does this model of accounting roles compare to what is needed to realize the promise of business automation technology?

My prediction: In the future a similar set of roles will also characterize the technology of business automation. And the technology to which we are referring goes beyond business process to also include business rules, business information (i.e. data) and business analytics technologies, all collectively known as the technologies of business semantics.

There will be both strategic and tactical technology specialists (consultants and business analysts), there will be domain specialists (business analysts), and all business people will know these technologies -- AND HOW THEY APPLY SPECIFICALLY TO THEIR BUSINESS -- in varying degrees.

Commodity semantic technology functions will be either open source or bought off-the-shelf (COTS); but unique semantics or differentiation will be achieved by hands-on specification and evolution of semantic artifacts performed directly by business people and business analysts. Just as business people and divisional accountants manage accounting today. (And of course the question of governance and fraud is never far away...)

Oh -- and accounting and business semantic technologies will "eventually" collide too . . .
  1. John Morris
  2. 4 months ago
  1. more than a month ago
  2. BPM Discussions
  3. # 7
Ian Gotts Accepted Answer

Does a one-legged duck swim in circles....
Comment
Does a bird fart in the woods?
  1. Patrick Lujan
  2. 4 months ago
  1. more than a month ago
  2. BPM Discussions
  3. # 8
Patrick Lujan Accepted Answer
Blog Writer

Give me a good facilitator who can elicit any day.
  1. more than a month ago
  2. BPM Discussions
  3. # 9
Bogdan Nafornita Accepted Answer

All you need to do a customer journey mapping is a little bit of common sense.


And that is not, statistically speaking, residing more with people with background in processes.
Managing Founder, profluo.com
Comment
The act of performing a "customer journey map" quickly becomes reified (OK, why did I have to use that word?) as THE customer journey map. Or how about "cast in stone"?

One needs a little theory beyond common sense in order to break through from the cowpath. Why isn't software better than it is? For many reasons, but of relevance here because sometimes common sense isn't so sensible. Examples abound. : )
  1. John Morris
  2. 4 months ago
  1. more than a month ago
  2. BPM Discussions
  3. # 10

As John mentioned “house”, I will use the example of house architecting.


Before talking to an architect, a person or a family must be clear about why they want to build a house and how this house will fit their life, e.g. do they plan to have kids? do they expect a lot of long-stay visitors? do them plan to move to another place?, etc. Of course, some people contact an architect before answering to these questions thus wasting their money and taking a huge risk (a good architect will ask them these questions and a bad architect will offer a solution which may be not suitable for them, e.g. by asking how many floors they want).


So, the mapping of customer journey is about anticipation (by a good process architect, of course). See variant 5 from the ref1 about multiple scenarios.


Thanks,

AS



References
  1. http://improving-bpm-systems.blogspot.ch/2010/12/illustrations-for-bpm-acm-case.html
Comment
"Anticipation" is such a nice word. And gets to the positive hopes associated with sales too!
  1. John Morris
  2. 4 months ago
  1. more than a month ago
  2. BPM Discussions
  3. # 11
E Scott Menter Accepted Answer
Blog Writer

Is it important that they DO the mapping? No.


Is it important they they PARTICIPATE in the ([url="http://bpm.com/bpm-today/in-the-forum/is-it-important-that-someone-with-a-background-in-processes-does-the-customer-journey-mapping#reply-3903"]facilitated[/url]) process of mapping? Yeah. Otherwise, entropy will set in hard and fast when that information is transferred to the application team for implementation.
http://www.bplogix.com/images/icon-x-medium.png Scott
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 12
David Chassels Accepted Answer

No an easy skill to quickly learn more important being a good listener and communicator?
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 13
Amit Kothari Accepted Answer

Isn't this exactly what the discipline around
[b]service design[/b]
does - with a strong focus on user experience? In that case it's not "anyone" that can do it - as you need someone really good on user experience to re-think customer experiences in various stages (see Wikipedia link). The codification after the thought process is of course, easily done.


Wikipedia has an article about it, but in the references we wrote a little bit about that too - and partnered with a bunch of people in that area. They look at the customer experience more holistically before diving into the weeds of process mapping.
References
  1. http://tallyfy.com/service-design-software/
  2. https://en.wikipedia.org/wiki/Service_design
Comment
Totally agree, John. In this metaphor, we're talking about concrete that's neither level not flexible for changes after plumbing and codification is in place. Nor does concrete have any soft spots that "give" easily without stubbornly refusing to budge :)

Fortunately, for modern cloud platforms, integration-as-a-service is now a commodity. For old-school legacy and on-premise - well, good luck!
  1. Amit Kothari
  2. 4 months ago
"The codification after the thought process is of course, easily done."

So is pouring concrete . . .

. . . which characterizes the inevitable if one is not working with a modern BPM platform. (And if the platform isn't "modern", then codification itself to the back-end is itself a real challenge.)

If I misunderstood your comment Amit, I'm happy to correct myself! : )
  1. John Morris
  2. 4 months ago
John - I would have to disagree with you there. We cannot live without Zapier in our business. It automates away a ton of things and is incredibly flexible, since you can change any integration at any time in just 4 clicks. Old-school integration is currently being re-defined by apps like Zapier, and we're going long on that future. Zapier has many millions of users (many of them paid) and they're growing because it actually works. In our company, the least techie people use it and love it.

I don't know what "semantic richness" means in terms of getting work done and easing hooks between apps. Could you elaborate?

Amit
  1. Amit Kothari
  2. 4 months ago
Integration-as-a-service all too easily ends up in h*ll. API h*ll and data management h*ll. IFTTT or Zapier or more robust alternatives, it doesn't matter. They aren't ("yet"?) scaleable in multiple important dimensions (transaction volume, security, semantic richness, manageability). This lack of scaleability might not matter if you are tracking large volumes of sensors communicating only every 15 minutes, and where you don't care about losing a certain percentage of messages. But I'm not convinced that ideas + code + APIs lead to anywhere else than a sea of concrete. : )

The challenge for humans is ultimately semantic richness, and to manage the semantic richness of reality one needs technologies where domain semantics are first class citizens of that technology. That means the irreducibly complementary technologies of business process, business rules, business analytics and business data. And UX, etc.
  1. John Morris
  2. 4 months ago
Hi Amit,

Integration-as-a-Service is certainly a welcome topic and as you point out a lot can be done already (in just a few years too since becoming more widespread).

As for business semantics, you can find lots of lengthy definitions around, including in even already Wikipedia (although my use of the phrase is more general than this definition):

https://en.wikipedia.org/wiki/Business_semantics_management

How about "a common formal language of the work of business, specifically where the irreducible concepts of work, particularly business process, business rules, business data, business narrative and business models are first class citizens of that language"?

Note "formal", which implies "usable in software". One could argue that all software is already doing these things. Business semantics just makes our goal explicit.

Note "common" which refers to the chaos of meaning between conflicting meta data between and even in business systems.

A synonym could be perhaps "formal business language". COBOL was probably intended to be this (i.e. COBOL being an acronym for "common business oriented language".) But the computer science wasn't mature enough during COBOL's heyday to enable direct business semantics.

Why bother?

Because being able to work directly with business semantics is enormously beneficial to business people.

The payoff is that as software gets smarter, business people can work directly from idea to new business tool. It's what we do already in accounting for a long time.

There's so much today about "agility". Agility only is possible if you can build out your ideas in "agile-time".
  1. John Morris
  2. 4 months ago
John - agreed, but the devil is in actually "doing" this.

That's what we've done - we've built something that actually "does this" in a way that anyone can understand and use, since I would guess that 99.9% of people don't know what "business semantics" means.
  1. Amit Kothari
  2. 4 months ago
  1. more than a month ago
  2. BPM Discussions
  3. # 14

@Amit


Excellent example of a situation where a facilitator is not going to help.


The key to "service design" is to log and tally all service tickets and then up to the service provider to decide whether they direct customers to an FAQ database or let them private chat.


I am not a fan of FAQ databases where my response to "Did you find what you were looking for?" is NO !, 99.999% of the time.


For me, 'service design" is more of a data mining exercise as it is extremely difficult to anticipate service calls for what designers feel are the most elementary capabilities of a product.


Who would think, for example (unless you are a driving instructor) to tell a new driver of an automatic car, that they need to use the same foot for the gas and the brake (as opposed to trying to use both feet) i.e. "Whenever I stop the car, the engine makes a funny noise" ?


 
Comment
Hey Karl, good points.

I must admit I am not a service design practitioner - I dream about amazing products and user experience when I sleep at night! I did post this question however which had interesting responses in the one of the largest Service Design communities on LinkedIn:

https://www.linkedin.com/groups/1856454/1856454-6158304918227734531

They would perhaps engage better with the comparison.

Hope it helps!
Amit
  1. Amit Kothari
  2. 4 months ago
  1. more than a month ago
  2. BPM Discussions
  3. # 15

Process thinking and collaboration thinking is an helpfull skill to capture the complete "journey" of the customer in the product or service offer you have.
Comment
+1 reference by Mr. Chassels to accounting practices in the 70s.
  1. John Morris
  2. 4 months ago
Indeed but a very easy skill to pick up apprentice accountants were doing it in the 70s ....nothing new!
  1. David Chassels
  2. 4 months ago
  1. more than a month ago
  2. BPM Discussions
  3. # 16
  • Page :
  • 1


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