Tell us about your background and your role here at Anaplan.
Pierre: For the past 4 years, I’ve been helping design, implement, and connect a number of internal use cases across multiple lines of business within Anaplan. Currently, I serve as the Senior Manager of Business Operations, where my primary responsibility is to lead the Anaplan on Anaplan team to create the best-in-class Connected Planning ecosystem. In addition to standing up the best in class connected planning framework, my team’s other primary responsibilities are to:
Jon: In my four years here at Anaplan I’ve dipped my toes in a lot of different departments within the organization. I started my tenure off on the Apps team where I developed SPM, Supply Chain, HR, enablement, and integration models for the AppHub. From there, I did a stint on the Customer Success team actually implementing Anaplan at a customer. After that rotation, my goal was to evangelize those data and hierarchy management best practices and scalability to the broader PreSales org. I’ve also supported builds for our internal Anaplan on Anaplan team as well as internal initiatives like Value Insights. My current role is Global PreSales Operations Consultant. Our key charters are to support technical POC builds for our larger customers, run connected planning workshops to show prospects the “Art of the Possible” within Anaplan, and play a key role in enabling and selling new product functionality like Optimizer, Machine Learning, and our new UX.
What’s your favorite thing about working at Anaplan?
Pierre: The people! The collaboration, creativity, and willingness of everyone at Anaplan to GSD is incredibly inspiring. I’ve learned a tremendous amount by the extremely talented people around me!
Jon: The people. Everyone truly cares. Everyone is on the same team. I have never been discouraged from going down a new path here. It’s always been “what can we do to help you get there.” We have a lot of smart, hard-working, passionate people here. They push you, they encourage you, they help you, they go to bat for you day in and day out. Everyone is in this together and wants everyone else to succeed here and it’s awesome.
Note: The live Q&A session is now closed.
The AMA is now open. Select the Reply button to post your questions today through Wednesday. If you haven't participated here before, now is your chance to connect directly with Anaplan's Dynamic Duo. Pierre and Jon are looking forward to your questions!
Hi, I have a dashboard with 3 views of the same module with 3 different levels of the list in the row.
I would like to synch them ie by choosing any levels all the respective views gets synched.
I understand that the only way to get working is to create 2 additional modules with only the level needed and this will synch.
The only issue with this seems a bit inefficent as you duplicating data for the purpose of synching.
Is there a better way to address in a more efficent way?
Thanks for taking my questions.
relationships in my model:
Region is 1 to many Sites.
Site is 1 to many Grape Programs.
Site is 1 to many Containers.
Site is 1 to many Harvest Profile Types.
Harvest Profile Type is 1 to many Grape Programs.
Family is 1 to many Grape Programs.
Grape program is 1 to many Draw Programs.
Container is 1 to many Fill Rate Winelots.
Grape deliveries are tons by week by grape program, profile type, & site (I calculate down to Draw Progam level).
Family is a way to group grape programs by site.
Inventory is by week, container, & fill rate winelot.
Here is the hierarchy I've constructed:
Just wondering your opinion, best practices....should I make changes to my hierarchy? Thanks.
Hello Jon & Pierre,
I wanted to have your view on flat hierarchies (+ mapping) vs built-in Parent/Children hierarchy.
I understand the benefit of level hierarchies but some times it feels the numbers of calculations (hence the impact on performance and size) outweights the benefits, in particular in a module dimensioned by lists having multiple levels (6 for GEO>Region>...>Rep, 2 for product, 3 for channel, etc.)
Do you have any suggestions or rule of thumb on how to proceed?
Today is the last day to get your questions in for Pierre Kerkinni & Jon Mavetz's AMA. Check out the questions that have already been posted, give Kudos to those you like, and then add your question here. Now is your chance to ask Anaplan's Dynamic Duo anything!
What should we do to build models that will be maintainable for those who inherit our stuff in the future? What have you seen that stands the test of time such as naming conventions, comments, "info only" line items, etc. ?
Could you share some high level best practices, examples, conceptual dashboards and ideas on Cost Allocation solutions ?
Due to the way Anaplan handles sparsity it seems we had to introduce heavy customisation and complex technical workarounds to ensure model size is acceptable, performances are acceptable and output requirements can be met.
Key considerations :
1) We had to create an allocation model (allocation engine) that is crunching numbers and producing an output for a specific allocation cycle/iteration.
Issue : Limited flexibility in terms of working with multiple versions/iterations at the same time. We are trying to keep things simple and basically have one single live version/model at the time.
2) We had to create a separate model to enable the reporting (allocation reporting model). We are transposing our allocation iteration from standard modules (from the allocatione engine model) into transactional modules, which are then imported at the most granual level into the reporting model.
At this point we would then derive versions and periods creating higher level reporting modules and variances with drill to transactions enabled.
- We aren't too sure on the design of this model when it comes to create/maintain lists and modules and enabling versioning and time period analysis on specific allocation iterations and, more importantly on variance analysis between two different periods/versions.
eg would you have several smaller lists and modules where the module itself is a specific version or use one master list/module?
- Have you got any practical examples on very large models that are using the transactional reporting strategy with modules that have millions of records ? Are there any known issues ?
- Any best practices on how to prevent/resolve performance issues when creating the views to transpose the allocation outputs into transactional reporting views ?
3) We had to combine several dimensions together to reduce sparsity, model size and improve performances, using as many subsets as possible
Issue : Increased technical complexity and maintenance
4) Extra complexity comes into place while dealing with Reallocations/Multi stage allocations which requires traceability on the various stages. Are there any best practices/design ideas and considerations that you could suggest to deal with this requirement?
- Technical complexity on model size, performances and reporting to present multi stage allocations/reallocations
Having worked with Hyperion/Essbase and Tm1 I find that the Cost Allocation use case on complex/large requirements in Anaplan is way more complex and I'm not sure it's the right tool for both allocation and reporting.
It would be very helpful to hear from the experts and receive specific design guidance based on large implementation, ideally seeing some examples of end result dashboards as well.
Hopefully this is a nice challenge for Pierre and Jon ;-)
Is it possible to assign multiple parents to an item in a list? If not, what is the get around solution. For example, I would like to assign a product line to 2 different teams as they both contribute to the sale of the product.
Our latest AMA video with Pierre and Jon is now live! Watch the entire video from start to finish, or select the question topic you're most interested in from the drop-down menu to begin there. Check back anytime to listen to the complete session. Thank you for your participation in the AMA! Be sure to watch for updates on the next session!