Highly required at Lululemon: They have 15 different test models corresponding to 15 different situations and configuration of the model. Fixing 1 bug and manually syncing to 15 models is unsustainable. Please consider this as a high priority. Thank you
... View more
Anaplan users are often moving from an Excel environment (with the flexibility to filter, search, and sort data according to their specific criteria) into a new Anaplan environment that is much more standard, structured and based on pre-defined dashboards.
Although our Anaplan dashboards and platform provide a lot of benefits in terms of speed, power of calculation, standardization, and collaboration, it is likely, at first, that users can’t customize their views and filters as they used to, and, therefore, ask for the ability to export the dashboard’s data into Excel. In Excel, they would use the necessary filters and searches to review their numbers, and/or edit the plans, before re-importing the modifications in Anaplan.
Exporting data out of dashboards to work in Excel not only takes time, but it also creates potential misalignments. Data changes often in Anaplan models, which makes all previous exports obsolete, leading users to make decisions or discuss business issues on potentially outdated numbers (see disconnected planning). In some cases, it might even create potential performance issues due to the blockage of models during these import/exports.
The problem we are trying to solve for: How do we keep our users in the Anaplan platform to do their work, which requires a higher level of advanced customization, faster and more easily than their previous Excel environment?
The solution is called “smart filters.” These smart filters have proven to make a significant impact on the adoption of the Anaplan platform in some of our key customers.
How Do We Solve This with Smart Filters?
The Anaplan platform provides a set of functionality for modeling filters in a smart way, using the multi-dimensional power of Anaplan combined with the new native user's dimension, to calculate very advanced and user-specific, data-driven exceptions.
Planning based on data-driven exceptions are best practices and are used to help users find outstanding data such as out of thresholds, missing, flagged, changed, unexpected variances, etc.
What is different from standard filters is the ability to make the value of each filter criteria specific to each user (as it was in user’s private Excel workbook), but with the full power of the Anaplan platform. In addition, these user-specific criteria are made persistent in the Anaplan model; the next time a user opens a dashboard, he/she can find the latest used criteria and does not have to enter them again and again.
In short, smart filters are enabling multi-dimensional, exception-based planning, customized by the user.
This customer is doing manual assignments of accounts to territories; 2 million accounts across 2,000 territories are to be assigned and verified.
Users need to constantly check and adjust these assignments and have business questions such as:
Show me all accounts belonging to a specific region.
Let’s see and adjust how all subsidiaries of “Account ABC” have been assigned through the territories.
Show me all accounts in my regions where the re-allocation to new territory is awaiting approval.
Show me all the accounts where the planning group is still missing.
Show me all accounts, just modified by the assignment process.
The filtering is key in the above cases, as users need to use many criteria, and some of them are advanced hierarchical-based calculations, such as “include all descendants and ancestors of this given set of accounts matching these criteria.”
And, of course, the criteria used for verification differ from one user to the next.
Here’s a screenshot where up to 12 criteria can be used: Customer 2
This use case is Global Accounts Quota plans; users need to edit and review accounts quotas, based on criteria such as country, region, but also accounts where the quota has been ‘overridden’ by other users and accounts where the quota is greater than a threshold.
Customer 2 also had another use case on Comp Planning; users need to filter reps based on their attribute or their assigned comp plan attributes, or based on what sales org they have been assigned to. Attributes are based on booleans, or formatted list items as drop-downs, or free text:
Supply chain plan: users need to dynamically display “seasons” they want to plan on or review.
Some users need to see the summer season, some need to see the full four seasons, some need to see the spring season, and some need to see the full plan horizon.
The smart filter allows the user to pick the season selection once, and all grids of a dashboard will filter based on this custom selection.
This use case is demand planning by product and customers; customer 4’s demand planning users need to filter their product lists based on 13 criteria as shown below.
Because entering up to 13 criteria can take some time, and more importantly, because users need to often switch from one set of criteria to another one, we implemented a solution to allow users to save multiple instances of the 13 criteria and give a name to each instance. Then they can easily pick a filter by its name, which will use all related criteria.
This implementation had a positive impact on usability by significantly reducing the number of clicks compared to what users had to do in Excel and by eliminating potential mistakes in filtering.
See below, where the user chooses “filter 1,” applies the filter, and all 13 of the criteria are filled in.
Then, the user chooses “filter 2,” applies the filter, and sees different criteria.
This can be easily extended with having user-specific filters, where everyone can create their own set of criteria and name it, or a common set of filters.
How to Model Smart Filters
3 easy steps are required:
Create the filter module.
Add the user filter line item(s) and set their formula.
Apply the user filter to the dashboard.
First, create one module that you’ll name “My Filters,” that is dimensionalized by users only.
Then create one line item per filter criteria you want to use across the model.
Create one module only, even if you’ll use smart filters in many dashboards.
Example (Customer 1): User Filter Module
Next, create a new module that you’ll need to filter the dimension(s), based on the criteria you just created in the “My Filters” module.
Dimensionalize this module by these dimensions, and by the native “Users” dimension, and create one line item of type boolean that you’ll name “user filter.”
Here is a basic example: In some cases (Customer 2 Global Accounts), the filter criteria are based on the data of a module, so it should apply to more than one or two dimensions; a smart filter such as “Quota $ is greater than,” where "Quota" is by account, product and time implies that the user filter is by account, product and time and User.
This type of data-based smart filter should be used only if the model size allows it.
User Filter Formula
There is a very simple way to generate the user filter formula and keep it simple and readable even when there are 20 criteria used.
Let’s use a generic example, where we want users to filter a list of cost centers based on country, industry, and size, and view a few KPIs.
My filter module is:
The module to be filtered where we use the user filter is:
The user filter formula (in the New user filter module) based on the three criteria is:
(ISBLANK(My Filters.Country) OR Cost Center Details.Country = My Filters.Country) AND (ISBLANK(My Filters.Industry) OR Cost Center Details.Industry = My Filters.Industry) AND (ISBLANK(My Filters.Category) OR Cost Center Details.Category = My Filters.Category)
In short, each criterion is within an AND clause.
The clause is True if there is no filter criteria entered (it’s best to show all if no filter is entered than show nothing) OR if the criteria entered equals the attribute: Cost center.Country = UK
With such formula structure, you can add as many criteria as you need by copy-pasting and adjust to the next criteria, and you’ll keep it maintainable.
If you add a fourth, the criteria to the smart filter of type boolean, such as “Is Inactive,” then you’ll add a fourth clause to the formula, separated with an AND statement. This fourth criterion is true if the new criteria is unchecked (false), or if the criteria is checked and the cost center is set as inactive.
(ISBLANK(My Filters.Country) OR Cost Center Details.Country = My Filters.Country) AND (ISBLANK(My Filters.Industry) OR Cost Center Details.Industry = My Filters.Industry) AND (ISBLANK(My Filters.Category) OR Cost Center Details.Category = My Filters.Category) AND (NOT My Filters.Is Inactive OR Cost Center Details.Is Inactive)
From a usability perspective, it’s important that, by default, filters return all items so that the grids never show empty the very first time. All filters are empty or unchecked.
This is why having a user filter of type boolean should return all items when the criteria are false. This is why we’re creating the above filter as “Is Inactive” and not ”Is Active.”
You can add a fifth criterion of type Text. This is used for a wild card search/filter, such as “Show me all accounts, which name starts contains “Bank of Am.”
In that case, add a new line item of type text in the “my filter” module, and add an AND clause to the user filter using the FIND function combined with the UPPER() function, which allows finding the text string regardless of lower case/upper case.
Here’s the example:
AND (ISBLANK(My Filters.Name Contains) OR FIND(UPPER(My Filters.Name Contains), UPPER(Cost Center Details.Cost Center Name)) > 0)
Another frequent requirement is the ability to enter multiple text strings in the criteria. In our example, it could be “Show Me Cost centers A, B, and C.” In that case, just change the order of the find function to:
AND (ISBLANK(My Filters.Name Contains) OR FIND(UPPER(Cost Center Details.Cost Center Name), UPPER(My Filters.Name Contains)) > 0)
Here you’ll find all the cost centers whose name is included in the text string “A,B,C.”
This only works if the text string contains the full name (or code) of the list item (in this case cost center). Customer 2 was using employee codes; users know the exact four employee codes they want to edit. As a result, they copy and pasted these codes to the filter grids and the dashboard returned all details of the corresponding four employees.
Adjust the Dashboards
Once your boolean is working as expected, use it as a filter in the grids of your dashboards as needed. Here’s an example: Notice that users have “Current User” automatically selected. This allows the filter to be user-specific, even though the user's dimension is not applied to the module, but it's just in the user filter module boolean.
This functionality is only possible if you use this native user dimension.
Next, publish the “my filters” module to the dashboard, to provide users with all criteria, just above the grids they want to filter. You can apply a “Clear” style to it to distinguish it from other grids. Keep in mind that the dashboard requires it to be refreshed when the filter is changed. You’ll need to educate users to find the refresh button on the menu bar:
Although the alternative is to create a refresh button, that is actually reopening the same dashboard, which we don’t recommend using for the following reasons:
Because it takes extra time to create, publish, and reposition the button.
Because button names need to be unique across the model, so you’ll end up with Refresh A, Refresh B, Refresh C, etc.
Because it’s a good opportunity to expose users to the menu bar where they can find additional features, especially the “undo” feautre, that many users aren't familiar with in the platform. Learn more in the Undo an Opertation Anapedia article.
Size & Performance Considerations
Applying smart filters has a cost in terms of model size, but it’s very reasonable compared to the benefits these bring to users and to adoption in general.
First, the user filter line item is a boolean, which costs 1/8 th of the memory footprint compared to a text line item, and 1/4 th of a list formatted line item. So even if we add several million cells, the memory impact is not that large.
For example, on one of the largest models, Customer 1’s user filter boolean took 2MM accounts * 100 users = 200MM boolean cells. It worked perfectly fine in terms of performance.
Customer 2’s global account user filter is applied to quota data, so dimensionality is: region, account, product family, users => The size was only 1.5MM cells, as this model was on summarized levels of accounts and product. Performance of applying the filter was excellent.
We obviously would not apply such filters if we had 2MM accounts * 2000 products * 8 regions. Remember, the line item cannot exceed 2.1B cells without time or versions
Be aware that the native user's dimension does not support subsets, so, it’s important to remove non-active users from the model as these will take up cell space. Learn more in the Work with the Users Lists Anapedia article.
Fine Tune Model Performance
In large models where the smart filter can be complex with 20+ criteria, such as Customer 1, we had to split the user filter into multiple line items, in order to keep the performance of changing filters to less than 3-4 seconds.
Following up on the filter example above, where user filter initially is in one formula:
(ISBLANK(My Filters.Country) OR Cost Centers.Country = My Filters.Country) AND
(ISBLANK(My Filters.Industry) OR Cost Centers.Industry = My Filters.Industry) AND
(ISBLANK(My Filters.Category) OR Cost Centers.Category = My Filters.Category) AND
(NOT My Filters.Is Inactive OR Is Inactive) AND
(ISBLANK(My Filters.Name Contains) OR FIND(UPPER(NAME(ITEM(Cost Centers))), UPPER(My Filters.Name Contains)) > 0)
What works faster, but takes more cell space is to create one user filter per criteria:
User Filter 1 = (ISBLANK(My Filters.Country) OR Cost Centers.Country = My Filters.Country)
User Filter 2 = (ISBLANK(My Filters.Industry) OR Cost Centers.Industry = My Filters.Industry)
User Filter 3 = ISBLANK(My Filters.Category) OR Cost Centers.Category = My Filters.Category)
User Filter 4 = NOT My Filters.Is Inactive OR Is Inactive)
User Filter 5 = ISBLANK(My Filters.Name Contains) OR FIND(UPPER(NAME(ITEM(Cost Centers))), UPPER(My Filters.Name Contains)) > 0)
Then, create a sixth line item for your dashboard that you’ll call ”final user filter,” which is calculated as ‘User Filter 1’ AND ‘User Filter 2’ AND ‘User Filter 3’ AND ‘User Filter 4’ AND ‘User Filter 5.’
This is performing better as the final filter only recalculates what is required based on what user is changing, instead of recalculating the whole thing.
Learn more in the Formula Structure for Performance article in the Community.
In the near future, we should see an improvement to the dashboard filters which also allows you to address custom filtering by end-users. The quick filters will work similarly to Excel filters, where the user can right-click on each column of a grid and select values to filter on. Once available, these quick filters should be used for simple filtering on the grid.
Smart filters, as described here, are recommended for:
Centralized master filters–defined once and applied in many grids in one or more dashboards.
Data-driven exception filtering.
Filtering online items not necessarily displayed in the grids, or not necessarily present in the module that is being filtered.
Filters that need to stay persistent per users, on one or more instances (like for Customer 5 above).
In conclusion, smart filters are a proven solution to keep our users in the Anaplan platform to do their work and provide them a high level of advanced customization, therefore reinforcing adoption and customer satisfaction.
You can design smart filters through the implementation of standard Anaplan modeling functionality using formulas, dashboard filters, and implementation of the native user's list.
Be cautious of model size impact, but don’t be intimidated by it. Smart filters have been deployed to production on very large customer models successfully.
Please help us make these smart filters even better by sharing your experience. Thanks for reading!
- Guillaume Arnaud
... View more
Thanks David! following up on your example, does it make a difference if one dimension (product) is way bigger than the other? I think I remember to put them in the smaller to larger order (and keep the consistency across module as you indicated), but was not sure if that makes a difference or not.
... View more
Very useful article @david, that I used to teach best Practices at Nike.
When we combine this with DISCO, it becomes very clear to model builders, that calculating once (in System or Calc) then reuse in either Input or Output gives better results: Better performance and better maintainability.
... View more
If you’re familiar with Anaplan, you’ve probably heard the buzz about having a data hub and wondered why it’s considered a “best practice” within the Anaplan community. Wonder no more. Below, I will share four reasons why you should spend the time to build a data hub before Anaplan takes your company by storm.
1. Maintain consistent hierarchies
Hierarchies are a common list structure built by Anaplan and come in a variety of options depending on use case, e.g., product hierarchy, cost center hierarchy, and management hierarchy, just to name a few. These hierarchies should be consistent across the business whether you’re doing demand planning or financial planning. With a data hub, your organization has a higher likelihood of keeping hierarchies consistent over time since everyone is pulling the same structure from one source of truth: the data hub.
2. Data Optimization
As you expand the use of Anaplan across multiple departments, you may find that you only need a portion of a list, rather than the entire list. For instance, you may want the full list of employees for workforce planning purposes, but only a portion of the employees for incentive compensation calculations. With a data hub, you can distribute only the pertinent information. You can filter the list of employees to build the employee hierarchy in the incentive compensation model while having the full list of employees in the workforce planning model. Keep them both in sync using the data hub as your source of truth.
3. Separate duties by roles and responsibilities
An increasing number of customers have asked about roles and responsibilities with Anaplan as they expand internally. In Anaplan, we recommend each model have a separate owner. For example, an IT owner for the data hub, an operations owner for the demand planning model, and a finance owner for the financial planning model. The three owners combined would be your Center of Excellence, but each has their separate roles and responsibilities for development and maintenance in the individual models.
4. Accelerate future builds
One of the main reasons many companies choose Anaplan is for the platform’s flexibility. Its use can easily and quickly expand across an entire organization. Development rarely stops after the first implementation. Model builders are enabled and excited to continue to bring Anaplan into other areas of the business. If you start by building the data hub as your source of truth for data and metadata, you can accelerate the development of future models since you already have defined the foundation of the model, the lists, and dimensions.
As you begin to implement, build, and roll out Anaplan, starting with a data hub is a key consideration. In addition to this, there are many other fundamental Anaplan best practices to consider when rolling out a new technology and driving internal adoption.
... View more
What drives the need for a Center of Excellence? The need for a Center of Excellence comes after businesses have successfully implemented Anaplan into their organization and are ready to become self-sufficient in ongoing Anaplan development and support. Organizations will establish a Center of Excellence to proactively handle the increase in use cases that the company can expect in the near future. Once established, the Center of Excellence can provide the following benefits to the organization:
Many organizations will significantly grow within Anaplan after their first release. As such, they will want to maintain control of the product with the introduction of more use cases and departments in Anaplan. Creating a Center of Excellence will help organizations to maintain control of Anaplan, including the implementation of new releases and training of new users, from a centralized, internal group or team.
Establishing a Center of Excellence early will help organizations to drive consistency across Anaplan. As more data, models, and modules are created within Anaplan it’s important to ensure that everything stays consistent across the application. Doing this will help to ensure that four key elements stay consistent in Anaplan:
Data and metadata
The Center of Excellence will help drive consistency in data and metadata by eliminating duplicate data and avoiding shadow integration processes.
The Center of Excellence will help drive consistency in model design by providing best practices in model architecture, calculation, performance optimization, and usability across the different Anaplan models deployed in the organization.
The Center of Excellence promotes the consistent execution of business processes and methodologies.
The Center of Excellence drives consistency across the application for all users involved. This means that users new to Anaplan can expect nearly the same experience across each model and dashboard they interact with as they have all been developed and deployed using the same process and guidelines.
Creating a Center of Excellence promotes knowledge sharing within an organization. The Center of Excellence may ultimately be responsible for the initial and ongoing training of end users in the Anaplan platform. Additionally, the Center of Excellence may also be responsible for maintaining the processes, procedures, and best practices that the organization uses within Anaplan, which may be provided directly through the platform.
Upstream / Downstream Development
Creating and maintaining a Center of Excellence within an organization will also empower the business to develop more upstream and/or downstream processes within the Anaplan platform. For example, an organization may first deploy a T&Q model, and then decide to develop an upstream HR-based model that contains employee details and compensation data to manage their sales team. The potential to expand upstream and downstream from an initial model in Anaplan is endless.
The Center of Excellence creates a "service" for the business to become more efficient in developing, releasing, and maintaining models within Anaplan, supporting a business group to build and own its own model. This means that an organization may rely on an internal Center of Excellence as a single source to implement new applications, promote platform use, share Anaplan best practices, and handle all training needs.
Finally, a Center of Excellence provides a central point of governance for the Anaplan projects across the organization. In a centralized mode, the Center of Excellence is responsible for maintaining the platform, as well as all other necessary elements involved with the creation and maintenance of an organization’s Anaplan products. The Center of Excellence will have the final say in platform updates and developments, which further drives consistency and efficiency in Anaplan. In a federated mode, the Center of Excellence will assist local teams in their implementation and application roll out efforts as needed.
In both cases, the Center of Excellence will communicate the progress, update and value of the Anaplan applications to executive sponsors across the organization and highlight the value of the Anaplan investment.
Return to: Introduction to Centers of Excellence
Jump to next: Benefits of Establishing a Center of Excellence
... View more
Problem to solve:
As an HR manager, I need to enter the salary raise numbers for multiple regions that I'm responsible for.
As a domain best practice, my driver-based model helps me to enter raise guidelines, which will then change at the employee level.
Usability issue addressed: I have ten regions, eight departments in each, with a total of 10,000+ employees. I need to align my bottom-up plan to the down target I received earlier.
I need to quickly identify what region is above/behind target and address the variance. My driver-based raise modeling is fairly advanced, and I need to see what the business rules are. I need to quickly see how it impacts the employee level.
Call to action:
Step 1: Spot what region I need to address.
Step 2: Drill into the variances by department.
Steps 1 & 2 are analytics steps: "As an end user, I focus first on where the biggest issues are." This is a good usability practice that helps users.
Step 3: Adjusting the guidelines (drivers)
There are not excessive instructions on how to build and use guidelines, which would have cluttered the dashboard. Instead, Anaplan added a "view guideline instruction" button. This button should open a dashboard dedicated to detailed instructions or link to a video that explains how guideline works.
The chart above the grid will adjust as guidelines are edited. That is a good practice for impact analysis— no scrolling or clicking needed to view how the changes will impact the plan.
Step 4: Review a summary of the variance after changes are made. Putting steps 1–4 close to each other is a usable way of indicating to a user that he/she needs to iterate through these four steps to achieve their objective, which is to have every region and every department be within the top down target.
Step 5: A detailed impact analysis, which is placed directly below steps 3 and 4. This allows end users to drill into the employee-level details and view the granular impact of the raise guidelines.
Notice the best practices in step 5:
The customer will likely ask to see 20 to 25 employee KPIs across all employees and will be tempted to display these as one large grid. This can quickly lead to an unusable grid made of thousands of rows (employees) across 25 columns.
Instead, we have narrowed the KPI list to only ten that display without left-right scrolling.
Criteria to elect these ten: be able to have a chart that compares employees by these KPIs.
The remaining KPIs are displayed as an info grid, which only displays values for the selected employee. Things like region, zip codes, and dates are removed from the grid as they do not need to be compared side-by-side with other KPIs or between employees.
... View more
These dashboards are absolutely critical to good usability of a model. Dashboards are the first contact between the end users and a model.
What SHOULD NOT be done in a landing dashboard:
Display detailed instructions on how to use the model. See "Instruction Dashboard" instead.
Use it for global navigation, built using text boxes and navigation buttons.
It will create maintenance challenges if different roles have different navigation paths.
It's not helpful once users know where to go.
What SHOULD be done in a landing dashboard:
Display KPIs with a chart that highlights where they stand on these KPIs, and highlight gaps/errors/exceptions/warnings.
A summary/aggregated view of data on a grid to support the chart. The chart should be the primary element.
Short instructions on the KPIs.
A link to an instruction-based dashboard that includes guidance and video links.
A generic instruction to indicate that the user should open the left-side sliding panel to discover the different navigation paths.
Users who perform data entry need access to the same KPIs as execs are seeing.
Landing dashboard example 1:
Displays the main KPI, which the planning model allows the organization to plan.
Landing dashboard example 2:
Provides a view on how the process is progressing against the calendar.
Landing dashboard example 3:
Created for executives who need to focus on escalation. Provides context and a call to action (could be a planning dashboard, too).
... View more
Note that this article uses a planning dashboard as an example, but many of these principles apply to other types of dashboards as well.
Building a useful planning dashboard always starts with getting a set of very clear user stories, which describe how a user should interact with the system.
The user stories need to identify the following:
What the user wants to do.
What data the user needs to see to perform this action.
What data the user wants to change.
How the user will check that changes made have taken effect.
If one or more of the above is missing in a user story, ask the product owner to complete the description. Start the dashboard design, but use it to obtain the answers. It will likely change as more details arrive.
Product Owners Versus Designers
Modelers should align with product owners by defining concrete roles and responsibilities for each team member.
Product owners should provide what data users are expecting to see and how they wish to interact with the data, not ask for specific designs (this is the role of the modelers/designers).
Product owners are responsible for change management and should be extra careful when dashboard/navigation is significantly different than what is currently being used (i.e. Excel ® ).
Pre-Demo Peer Review
Have a usability committee that:
Is made up of modeling peers outside the project and/or project team members outside of modeling team.
Will host a mandatory gate-check meeting to review models before demos to product owners or users.
Committee is designed to ensure:
Best design by challenging modelers.
Consistency between models.
The function is clear.
Exceptions/calls to action are called out.
The best first impression.
Exception, Call to Action, Measure Impact
Building a useful planning dashboard will be successful if the dashboard allows users to highlight and analyze exceptions (issues, alerts, warning), take action and plan to solve these, and always visually check the impact of the change against a target.
Example: A dashboard is built for these two user stories that compliment each other.
Story 1: Review all of my accounts for a specific region, manually adjust the goals and enter comments.
Story 2: Edit my account by assigning direct and overlay reps.
The dashboard structure should be made of:
Dashboard header: Short name describing the purpose of the dashboard at the top of the page in "Heading 1."
Groupings: A collection of dashboard widgets.
Call to action.
Info grid(s) : Specific to one item of the main grid.
Info charts: Specific to one item of the main grid.
Specific action buttons: Specific to one item of the main grid.
Main charts: Covers more than one item of the main grid.
Individual line items: Specific to one item of the main grid, usually used for commentaries.
A dashboard can have more than one of these groupings, but all elements within a grouping need to answer the needs of the user story.
Use best judgements to determine the number of groupings added to one dashboard. A maximum of two-to-three groupings is reasonable. Past this range, consider building a new dashboard. Avoid having a "does it all" dashboard, where users keep scrolling up and down to find each section.
If users ask for a table of contents at the top of a dashboard, it's a sign that the dashboard has too much functionality and should be divided into multiple dashboards.
Call to Action
Write a short sentence describing the task to be completed within this grouping. Use the Heading 2 format.
The main grid is the central component of the dashboard, or of the grouping. It's where the user will spend most of their time.
This main grid will display the KPIs needed for the task (usually in the columns) and will display one or more other dimension in the rows.
Warning: Users may ask for 20+ KPIs and need these KPIs to be broken down by many dimensions, such as by product, actual/plan/variance, or by time. It's critical to have a main grid as simple and as decluttered as possible. Avoid the "data jungle" syndrome. Users are used to "data jungles" simply because that's what they are used to with Excel.
Tips to avoid data jungle syndrome:
Make a careful KPI election (KPIs are usually the line items of a module).
Display the most important KPIs ONLY, which are those needed for decision making. Hide the others for now.
A few criteria for electing a KPI in the main grid are:
The KPI is meant to be compared across the dimension items in the rows, or across other KPIs.
Viewing the KPI values for all of the rows is required to make the decision.
The KPI is needed for sorting the rows (except on row name).
A few criteria for not electing a KPI in the main grid are (besides not matching the above criteria) when we need these KPIs in more of a drill down mode; The KPI provides valid extra info, but just for the selected row of the Dashboard and does not need to be displayed for all rows.
These "extra info" KPIs should be displayed in a different grid, which will be referred to as "info grid" in this document. Take advantage of the row/column sync functionality to provide a ton of data in your dashboard but only display data when requested or required.
Design your main grid in such a way that it does not require the user to scroll left and right to view the KPIs:
Efficiently select KPIs.
Use the column header wrap.
Set the column size accordingly.
It is ok to have users scroll vertically on the main grid. Only display 15 to 20 rows at a time when there are numerous rows, as well as other groupings and action buttons, to display on the same dashboard.
Use sorts and a filter to display relevant data.
Sort Your Grid
Always sort your rows. Obtain the default sort criteria via user stories. If no special sort criteria is called out, use the alphanumeric sort on the row name. This will require a specific line item.
Train end users to use the sort functionality.
Filter Your Grid
Ask end users or product owners what criteria to use to display the most relevant rows. It could be:
Those that make 80 percent of a total. Use the RankCumulate function.
Those that have been modified lately. This requires a process to attach a last modified date to a list item, updated daily via a batch mode.
When the main grid allows item creation, always display the newly created first.
If end users need to apply their own filter values on some attributes of the list items, such as filter to show only those who belong to EMEA or those whose status is "in progress," build pre-set user-based filters.
Use the new Users list.
Create modules dimensioned by user with line items (formatted as lists) to hold the different criteria to be used.
Create a module dimensioned by Users and the list to be filtered. In this module resolve the filter criteria from above against the list attributes to a single Boolean.
Apply this filter in the target module.
Educate the users to use the refresh button, rather than create an "Open Dashboard" button.
Color Code Your Grid
Use colored cells to call attention to areas of a grid, such as green for positive and red for negative.
Color code cells that specifically require data entry.
Display the Full Details
If a large grid is required, something like 5k lines and 100 columns, then:
Make it available in a dedicated full-screen dashboard via a button available from the summary dashboard, such as an action button.
Do not add such a grid to a dashboard where KPIs, charts, or multiple grids are used for planning.
These dashboards are usually needed for ad-hoc analysis and data discovery, or random verification of changes, and can create a highly cluttered dashboard.
The main chart goes hand-in-hand with the main grid. Use it to compare one or more of the KPIs of the main grid across the different rows.
If the main grid contains hundreds or thousands of items, do not attempt to compare this in the main chart. Instead, identify the top 20 rows that really matter or that make most of the KPI value and compare these 20 rows for the selected KPI.
Location: Directly below or to the right of main display grid; should be at least partially visible with no scrolling.
Synchronization with a selection of KPI or row of the main display grid.
Should be used for:
Comparison between row values of the main display grid.
Displaying difference when the user makes change/restatement or inputs data.
In cases where a chart requires 2–3 additional modules to be created: Implement and test performance.
If no performance issues are identified, keep the chart.
If performance issues are identified, work with product owners to compromise.
These are the grids that will provide more details for an item selected on the main grid. If territories are displayed as rows, use an info grid to display as many line items as necessary for this territory. Avoid cluttering your main grid by displaying all of these line items for all territories at once. This is not necessary and will create extra clutter and scrolling issues for end users.
Location: Below or to the right of the main display grid.
Synced to selection of list item in the main display grid.
Should read vertically to display many metrics pertaining to list item selected.
Similar to info grids, an info chart is meant to compare one or more KPIs for a selected item in the rows of the main grid.
These should be used for:
Comparison of multiple KPIs for a single row.
Comparison or display of KPIs that are not present on the main grid, but are on info grid(s).
Comparing a single row's KPI(s) across time.
Place it on the right of the main grid, above or below an info grid.
Specific Action Buttons
Location: Below main grid; Below the KPI that the action is related to, OR to the far left/right - similar to "checkout."
Should be an action that is to be performed on the selected row of the main grid.
Can be used for navigation as a drill down to a detailed view of a selected row/list item.
Should NOT be used as lateral navigation between dashboards; Users should be trained to use the left panel for lateral navigation.
Individual Line Items
Serve as a call out of important KPIs or action opportunities (i.e., user setting container for explosion, Container Explosion status).
If actions taken by users require additional collaboration with other users, it should be published outside the main grid (giving particular emphasis by publishing the individual line item/s).
Call to action.
Serves as a header for a grouping.
Short sentence describing what the user should be performing within the grouping.
Formatted in "Heading 2."
Directly located next to a drop-down, input field, or button where the function is not quite clear.
No more than 5–6 words.
Formatted in "instructions."
Use Tooltips on modules and line items for more detailed instructions to avoid cluttering the dashboard.
... View more
Deal with monthly dashboards
Many FP&A dashboards will need to display all 12 months in the current year, as well as Quarter, Half, and Total Year totals. Doing this is likely to create a very large grid, especially if more than one dimension is nested on the rows.
The grid displayed here is what may be requested when Anaplan is replacing a spreadsheet-based solution. The requirement being "At minimum, do what we could do in the spreadsheets".
Avoid the trap of rebuilding this in Anaplan. Usually, this simply creates an extra requirement to export this into Excel ® , have users work offline, and then import the data back into Anaplan, which kills the value that Anaplan can bring.
Instead, build the dashboard as indicated below:
Have end users view the aggregated values on the Cost center (the first nested dimensions) that will provide an overview on where most OPEX are spent
Have end users highlight a cost center, and enter its detailed sub-accounts
Visualize the monthly trend using a line chart for the selected sub-account
... View more