To a Finance team, one of the more exciting aspects of having access to an internal Cloud environment, is the prospects of driving significant transformation to their internal and external reporting processes through creation of a Data lake. When done right, this will help make massive changes to reporting processes and enable initiating bolder changes to the skillset mix in the function – essentially, fewer people overall, with a higher mix of technically skilled team members to replace conventional accounting and number crunching profiles.
However, this transition takes time, and it is important for organizations to stay invested in what is likely to be a multi-year journey (at least 3 years for a Finance HC of 250 people in a single country). For regional and global functions, it will take longer, while the adoption and roll out can be clustered based on complexity and size.
Below are some key variables that is bound to impact pace of delivery
|1||Tribe composition||A variety of skills need to come together to build a new infrastructure – a bit like breaking down an old house and building a new one.|
Lineage study: This involves digging their way from an existing source to the primary source system where such information is housed. This requires skilled BAs who can use a variety of methods, including digital audit trail to determine where a piece of data comes from. Lineage is the foundational component of work.
Design and architecture: A key area of expertise to design a data model that enables development at scale, and one that includes control elements to manage remediation efforts.
Solution development: the most critical lot, and the largest composition of tribe strength responsible to source, enrich and transform data into the golden zone
Testing: this involves rolling out risk-based testing strategy, applying intelligent testing methods for SIT and UAT
Report creation: finally, a group of developers who will enable creation of a self-service world through automated reporting and visualization of data sourced straight from the lake
|2||Development approach||While there is no right or wrong answer, there are options with pros and cons that must be calibrated before embarking on a detailed deployment plan. The key options to roll out are|
Business led: This approach enables focus on an area of work, and enable lineage and build effort to be channeled towards delivering capability to a business unit, product by product
Source led: This approach is prudent only when a majority of the source data comes from few source systems, thereby eliminating the need to get back to the system to assess data needs for every business or product.
Output led: This approach, while inefficient, addresses appetite for immediate stakeholder facing outputs which requires sourcing, remediation and report build activities to happen sequentially, capturing all data attributes needed for a particular stakeholder.
|3||Planning and effort assessment||The scale of work involved will require intelligent clustering of work packages that considers unique building blocks within a tribe, overlaying complexity against each such MVP. A typical approach to determine overall effort is to T-Shirt size based on subjective complexity, and apply a mathematical factor to such complexity|
Small: Those which involve fewer data attributes, and fewer remediation rules.
Medium: Those involving more lineage effort driven by numerous source systems
Large: MVPs with significant challenges including manual ingestion of source data, and other offline data sources