Wdata adoption planned - What did you wish you thought about at the start?
固定された投稿 回答済みHi all,
Starbucks Financial Reporting currently uses Workiva Wdesk for our SEC reporting solution. Our process has been fairly manual and we took steps this year to embrace import and synch functionality as incremental improvements. We are in process of engaging with Workiva and our Technology team to operationalize Wdata. First will be Tech helping us connect to source system data, then our Financial Reporting team will lean into the new module to get as much efficiency and automation out of it as possible.
Is there anything your company wished they knew or thought about when initially setting up and optimizing Wdata? Would love to learn from you if willing to share.
Thanks,
Nick Bilotta
Financial Reporting, Starbucks
-
Hi Nick,
Thanks for contributing to the community and looking to spur conversation. I'm a VP of Customer Success here at Workiva and I joined the organization by way of acquisition of OneCloud. As a person that has spent the better part of 20 years in the Financial Systems space, I will offer a bit of my learnings. Data is such a critical component to the success of every financial systems project. While it may sound obvious, so often it is given less attention in the planning and execution phase. This results in poor testing results (best case scenario when deprioritized) or worse, a bumpy go-live or poor user adoption.
The fact that you are thinking about data now is a great thing. Here are a few things to consider:
- Take the time to do data discovery. This includes:
- evaluating from where the data will come to support the reporting needs (i.e., systems)
- understanding what is the data requirement frequency & timing but more importantly the data availability to address those requirements
- what is the data structure (layout)
- what is the level of grain needed versus what is available
- define the relationships between the data models of the systems (think of this as the mapping)
- Develop a testing plan for the integration. While you may have some testing as part of the Conference Room Pilots or User Acceptance Tests, a more rigorous System Integration Test plan is something you will not regret having developed and executed
- Look at the tools available holistically. In Wdata, you have tables/queries/views, Chains, and Data Prep. Each serves a role in the integration and automation process and architects can help develop a plan to use the "right tool for the right job" where each is complimenting one another
I hope that helps and by all means, feel free to comment back if you have follow-on questions.
-1Tony, Thanks for the prompt response and thoughts. It appears we are on the right path currently where we have been working internally with our Tech partners to document requirements around 1 to 4 above. Regarding 5, data mapping and relationships, our Team is operating under assumption that once we have the connectors and can query data within the platform, we would be able to use data prep and chains to go from there as a functional requirement for our team is that we maintain flexibility to establish new relationships and use data in a variety of ways as our disclosures evolve over time.
0Data Prep is the perfect tool to use for mapping. One point of clarification, Data Prep & Chains generally lands data in the Wdata tables already transformed, utilizing an ETL approach. What you have described with querying data in the platform and using Data Prep would be more of an ELT approach. The way Wdata tables, Chains, and Data Prep work, you need to employ a more traditional ETL approach.
That's not to say that you can't extract data from a Wdata table and use Data Prep to transform it but you'd then have to inject the transformed data back into another Wdata table and that wouldn't be the most efficient solution in my humble opinion.
I hope that helps.
0サインインしてコメントを残してください。
コメント
3件のコメント