<aside> đź“Ś Relevant Links
</aside>
Problem Summary (current state) Process level reports are fully customized, housed, and shared off platform. We have visibility into what we are reporting, but we have few if any standards about what information to share and when to share it.
Here is a list of the client reporting questions we currently answer.
Consequence The lack of structure tempts our teams and our clients to imagine needs that may not actually be relevant in the worse case scenario. In the best case scenario, generated reports are exactly what the client needs, but they are produced, updated, and shared with a lot of administrative effort. Every client is treated as a unique reporting context.
Short Term Context and Approaches
Context
Scott
Q: We need a clear engagement model for how to get Analytics into the game. A: Analytics works on Metabase->MTC reports during migrations
Q: We need Junaid’s reporting components to be usable within the core Manticore app. The same thing he’s asking for from PC and MDX is something he needs to provide A: Update reporting components as needed. Maintain backlog.
Q: What frequency should reports cover?
A: Process level reports are covering “real time” data and update frequently. Account Level or Cross Process reports can update on a daily basis. What’s our stake in the ground?
Q: Where should data come from? A: Current implementation sources data from our warehouse. Reports may need to be able to be sourced from alternate datasources (not just warehouse).
Q: How are reports related to processes? A: Reports should be able to be tagged against specific processes but not required to be. If they are tagged, they show up in the process level pill: