Breaking news from around the world
Get the Bing + MSN extension
Now Available in Community - MBAS 2019 Presentation Videos
Catch the most popular sessions on demand and learn how Dynamics 365, Power BI, PowerApps, Microsoft Flow, and Excel are powering major transformations around the globe. | View Gallery
2019 release wave 2 Discover the latest updates to Dynamics 365Release overview guides and videos Release Plan | Early Access Availability
Ace your Dynamics 365 deployment with packaged services delivered by expert consultants. | Explore service offerings
Connect with the ISV success team on the latest roadmap, developer tool for AppSource certification, and ISV community engagements | ISV self-service portal
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Program | Finance TechTalks | Customer Engagement TechTalks | Talent TechTalks | Upcoming TechTalks
By Jukka Niiranen, Senior Consultant (CRM Solutions) at Anvia
In the previous two
parts of this series I wrote about the changing direction of how CRM solution
vendors are increasingly targeting
the end user with the functionality they are developing, rather
than the top level managers who consume the metrics produced from CRM data.
Now it's time to look at what functionality in Microsoft Dynamics CRM can make
it more "viral friendly".
Today we already have
the tools to build quite comprehensive applications for managing various
business processes through the declarative programming model of Dynamics CRM
and the ever growing portfolio of ISV add-ons and ready-made integrations to
popular third party applications & services. These pieces can be combined
in so many different ways that the amount of custom code needed for meeting the
business requirements of CRM customers is continuously shrinking, which I consider
a highly positive development.
With this ever
expanding toolkit in our hands, we still need to keep in mind that building the
business logic into the system gets us only half way. The ultimate goal of a
CRM system implementation is to drive business process changes and realize the
resulting performance improvements - not just to offer data processing
functionality. In order to achieve such results it is not enough for the
technology to just support the processes, it must also take part in communicating them to the users. Yes,
the machine should preferably tell the man what is expected of him to get the
In a CRM system
implementation project, after the ideal usage patterns of the new application
have been mapped out in the analysis phase, it's time to plan not only the
technical functionality to be developed but more importantly the behavioral
change to be delivered and the available means for it. At this point the
boundaries of the project team's resources can often start to feel quite
constraining. As an implementation consultant, I can't worry about every little
detail of the user interface components. As a system owner, I can't create an
extensive user manual with screenshots & instructions for every single use
case, nor get people to discover and read it at the time of need.
Let me reduce your
anxiety of the overwhelming training and documentation task envisioned for any
large scale CRM system deployment by letting you in on a little secret: in the
real world, there are no manuals. Or, to be more specific, a manual may exist
somewhere, but it might as well not. In the words of Seth Godin, "no one is going to read the whole
thing, ever again".
Did you read a manual
for Foursquare before you performed your first ever check-in? Did you have a
printed guide to assist you in creating your Facebook profile? It's obvious
that you didn't and quite frankly the whole concept of a user manual feels
foreign when talking about these types of modern social applications. Remember:
these are prime examples of viral apps.
What should a CRM
application designed for the same kind of low or non-existing barrier of entry
look like? First of all, it needs to be highly visual and intuitive enough so I
can trust the users to interpret the presented information in the same way as
the system designers. It needs to show the expected process flow to the user,
without the need to reference a printed flowchart of what to do in which order.
Machines excel at repeating tasks based on the instructed pattern, humans are
better off using their brain capacity for something other than memorizing
coming to Microsoft Dynamics CRM starting from the Fall 2012 release include a
new Process Driven UI. The fundamental change that this new approach aims to
deliver is displaying the previously well hidden business logic of workflow and
dialog processes to the end user. We've spent nearly a decade building
intricate workflow logic under the hood of Microsoft's CRM application and now
it's finally time to bring them out into the open.
The extent to which
the initial UI functionality will support presenting conditional branches and
other complexities of everyday processes remains to be seen, but I've got a
positive feeling about the direction this will take the CRM platform,
regardless of the inevitable limitations in the first iterations. That is
because I believe that once you reveal the processes on the front-end, there's
no pushing them away into the back-end anymore.
While we're at it,
let's not stop with the process visualization. Ultimately, system customizers
need the ability to offer proper signage to the end users to inform them about
the right things at the appropriate time. I'm not talking about completely
re-skinning the application or pulling any content management/publishing type
of tricks. Why not start from the basic things, such as allowing us to show
meaningful tooltips for users wondering about what a particular form field is
used for? Or by displaying different kinds of forms for records based on their
field values, since we know all accounts are not meant to be alike (why show the
customer rating for a partner organization, for example?). It's this type of
attention to detail that can have a more significant impact to user adoption
than adding yet another feature button for the users to ignore.
Yes, with enough
Jscript you can already do wonders through supported or unsupported form
modifications, but that's not a valid excuse if you're really aiming to change
the user experience of the core Microsoft Dynamics CRM product into something
that transparently communicates the business processes it is used for managing.
There's a clear distinction between making something possible and making it
obvious, with the latter often being the results or reducing options rather
than increasing them. As an example, Android smartphones allow the user to
tweak every possible setting, but the iPhone delivers a more enjoyable user
experience with far less options or user control. That is the power of applying
a well thought-out, consistent user language.
In the final part of
this series I will analyze the impact of different client versions coming for
Microsoft Dynamics CRM and how they are shaping the process of designing a CRM
system that's ready for the age of viral user adoption.
Business Applications communities