Software Designed For Your People

Reflecting the Model in Software

• 
  Microsoft Dynamics Client – Some people spend most of their day working within the Microsoft Dynamics client and really have no need or interest in leaving it. They would like information from other systems and applications such as Office to be surfaced directly in their Microsoft Dynamics client.
  
• 
  Microsoft Office – Some people spend all day in Office applications but on occasion need information from backend systems. They would prefer this to be available to them in Office directly so they do not need to learn additional applications.
  
• 
  Business Portal – Some people only interface with backend systems in the context of a specific process. They would like an experience specific to that process that leads and focuses them in an optimal manner. For these people we can combine all the elements they need in a set of simple web based screens.
  

Microsoft Dynamics Client

• 
  The information architecture of the UI (how information and tasks are organized) will be based on the customer model. The goal is to organize the UI so that it matches each individual’s work.
  
• 
  The information and tasks presented to users in the UI will be based on the customer model.
  
• 
  Although current products are based on the customer model ,we are working toward shipping a configurable customer model within the product with a goal of letting customers maintain their specific customer model which in turn drives the UI
  

The industry a company operates in and the complexity of the department in question are key influencing factors in what specific roles an individual holds and therefore the processes they will participate in. It also determines how intricate a process is - which parts of the theoretical maximum process are used and how the process breaks down into activities and tasks. We will ship a default definition of this based on department complexity and partners and customers can customize this and modify it over time for their specific industries.

Here is a more detailed view of how we do this:



Figure 5: Detailed view of processes and roles surfacing into User interface design

To the far right of this diagram you can see how the navigation structure in the application itself is derived from the model:

At the highest level, the combination of roles a user has translates into a Home page - with links to the processes they participate in. Within the navigation structure on the home page, a user can access a variety of “Activity Centers” with all the tasks the user performs in a specific process. Finally the tasks for each process step are available in a Task Page.

For example if you looked at the work that an accounts payable clerk (April⁴) typically does and apply the methodology above to the customer model definition of April, her full experience will look like this:

• 
  Activities – The activities part gives April a visual representation of the key work she does. The stacks of paper in the different categories easily allow her to see how much is outstanding and she can set alerts and notifications if certain thresholds are reached as you see in the case of Due Invoices.
  
• 
  Outlook – As April typically spends all day in the Microsoft Dynamics client, we are surfacing key office information from Outlook here so April can see it without having to switch context.
  
• 
  Contextual Business Intelligence – April has key information she needs to see to be able to make informed decisions in her work. In this case she is interested in balancing the discount she can get by paying different invoices versus keeping sufficient cash on hand. Rather than being required to hunt out a variety of reports she is presented with the information she needs most on her home page.
  
• 
  Alerts – This part shows April the exceptions to the standard processes and workflows she participates in that need her immediate attention.