Ana səhifə

Software Designed For Your People


Yüklə 3.02 Mb.
səhifə2/10
tarix18.07.2016
ölçüsü3.02 Mb.
1   2   3   4   5   6   7   8   9   10

Building a Clear Customer Understanding

In order to build software that is tailored to the work done by specific people and companies it is necessary to have an in-depth understanding of today’s businesses and their employees.


To build this level of understanding Microsoft Corporation as a whole invests significantly in understanding our customers and designing and building great solutions for them.1 Over the course of a year in the 43 Usability Labs on the Microsoft campuses we conduct 1100 usability and research studies per year involving 10,000 participants. We also conduct more 1700 annual site visits where we visit customers in their own environments and observe their real world work style and behaviors.
Within the Microsoft Dynamics R&D team we have a global user experience group with employees located in Copenhagen, Denmark; Fargo, North Dakota; and Redmond, WA. These teams have been engaged in in-depth user research into the requirements customers have for business management solutions over the past three years -- collectively working toward a holistic understanding of how people organized into departments get work done in the real world so we can build software that supports them more effectively. This work has seen the team complete 280 site visits to companies and partner shops where they conducted 1400+ interviews and/or observations with individual people as they went about their daily work.
During this research we have collected the following types of information:

  • People – As part of an observation, individuals are interviewed at depth to collect information on their roles, demographics, psychographics etc. They are then observed as they go about their daily routine to record interactions with fellow employees, software and the company’s processes.

  • Departments – Companies’ organizational charts were collected so that the number of overall departments, the individuals that make them up and the reporting structures could be understood.

  • Work – The specific internal processes a company uses within and across departments and also the external processes they use to interface with suppliers, partners and customers.



Figure 2: Example of an actual process collected during research.

The Microsoft Dynamics Customer Model


The result of this research is something we call the Microsoft Dynamics Customer Model. The Microsoft Dynamics Customer Model describes how people in departments do work within and across organizations.  It is the repository for all of the Microsoft Business division’s information and research regarding processes and people and is used to ensure that we are focusing on a common set of people and processes when we build Microsoft Dynamics solutions.

Definition of the customer model2


The customer model today consists of the following elements:


  • Models of companies for small and midsize businesses3, as well as large and complex departments

  • 61 “personas” or “user profiles” which represent a typical view of the people that can occur within an organization defined primarily by the collection of roles they have. (A role is a specific grouping of tasks that a persona is responsible for or participates in.)

  • Five midsize business departments (Operations, Finance, Human Resources, Sales & Marketing, IT & Partners)

  • 15 typical departmental organization charts showing how the personas are typically organized in these five departments

  • 33 process groups that represent the work people do within business scenarios

  • 155 processes and subsequent tasks and steps defined across the 33 business process groups



Figure 3: The Microsoft Dynamics Customer Model

Utilizing the Customer Model


There are a number of ways that the customer model is used by our development teams within Microsoft:


  • General understanding of customers: Development teams need to have an understanding of customer’s processes, departments, and most importantly people in order to build business solutions that meet their needs. One of the aims of the customer model is to drive customer-centric design into our products. The goal is to have a, rigorous, analytic, data-driven way to do design that will guide and inform Program Management.

  • Repository for customer knowledge: The development teams already have a good base of knowledge that reflects our customers that we can apply to our designs. The customer model is the vehicle to channel all our knowledge about the customer. It is the repository for all information regarding a certain process or persona across all teams. When a team does research for their needs for a release cycle, this is captured for reuse by other teams in a standard way. It also contains the methodologies of how to do research so that future research uses the same materials and guidelines of past research.

  • Language to represent users and work: The customer model is a knowledge base tool. It provides a language to document, capture and share how work gets done. It captures process maps and how they relate to people in crisp way, as well as variations from customers and partners. The aim is to be able to model all possible companies and users that may use our product. Each vertical and instance of our deployments has variations. The customer model provides a language that helps our customers and partner’s document and account for the variations on those people and processes.

  • Targeting of features to users: The customer model provides the mechanism for gathering information regarding which business processes are most common and painful and who they apply to, through a series of quantitative studies. This alleviates debate around which problems are the most important to solve and allows us to focus development on the most painful and important areas.

  • Focus for Program Management collaboration: The customer model provides a focus for problem solving and collaboration across product teams within our development organization. A set of program managers or developers can come together based on a set of people, processes, and departments and ask: “What are you trying to do, what am I trying to do, how can we collaborate?” thereby driving more consistent and efficient designs.



1   2   3   4   5   6   7   8   9   10


Verilənlər bazası müəlliflik hüququ ilə müdafiə olunur ©atelim.com 2016
rəhbərliyinə müraciət