powerobjects: A Day in the Life of a Dynamics 365 Data Expert
At PowerObjects, we have found that one of the most essential roles on any Microsoft Dynamics 365 team is devoted specifically to the data needs of the project – the data experts. Any enterprise is only as good as the data that it has available to support itself.
Therefore, critical to the success of any D365 project are each of the following:
The work performed by a data expert varies from day to day, depends on the specific phase of the project.
The data expert enters a normal solution build during the PowerObjects’ planning phase, beginning with the efforts to transition from the Sales to the Delivery team – designed to explain/refine the tasks to be performed and to introduce, define the roles of, and empower the members of the combined client team.
Clients are encouraged to identify key indicators and functionality during the planning phase. These indicators will quickly identify the entities, fields, and relationships important to the customer and define the solution developed. Specific subject matter experts (SMEs) on the client side will quickly be identified or make themselves known during early discussions.
This phase focuses on setting the expectations of the client; translating the functional requirements of the client into the technical requirements and design of the solution; and identifying the new/modified/retained business processes involved. Together, this planning will define and refine the scope, cost, and timeline of the D365 project at hand. The planning phase aids the client team in understanding their own requirements, as the structure of D365 encourages process improvement. However, D365 should not be considered or presented as “the process.”
Each data migration/integration effort requires great care, thoroughness, and detailed planning. The work of the data expert normally begins in earnest during this phase – with the identification of unique identifiers of all source data, identification and definition of all source data elements to be migrated, and the mapping of the source data to be migrated and/or integrated into specific entities and fields within the D365 solution.
Simply put, mapping the data is determining the destination of the data currently stored in the current legacy system(s) into the corresponding D365 data structures, while confirming the format of the source and destination data. Most of the time, we use a series of spreadsheets to build out and refine this mapping work. The more specific these documents, the easier it will be to execute the migration/integration work.
Note that not all legacy data will be migrated. Historic data stored in a customer’s legacy system is often found to contain duplicate, inconsistent, incomplete, or outdated information. The data expert may identify risks associated with certain “dirty” data while working with a client’s data set. They will offer client team members assistance in data quality and data cleansing methods and best practices; but data cleansing work is normally the domain of the client. History has proven that it is better to resolve data quality/cleanliness issues PRIOR to migrating data – ensuring only the most useful and cleanest data will be moved into the D365 instance.
Furthermore, data in the source systems may not be aligned exactly with the destination D365 entity receiving the data. This requires that the entire “column” of data be manipulated to match what D365 is expecting to receive. These individual steps are sometimes described as “transformation formulas.” For example, the existing name field may need to be cut up or “parsed” into the D365 firstname and lastname fields, or all telephone numbers must be presented in a certain format (e.g., “###.###.####”).
Powerful data integration tools, such as SQLServer Integration Services (SSIS), KingswaySoft, Scribe Insight, and the Microsoft Azure
products and tools, are available to the data expert to do the migration/integration work. While data migration/integration are two different processes, the methods and skill sets used are very similar.
Data Migration is the process of moving data from one system to another. Considerations include:
The integration mapping will often follow that of the migration mapping, which can be used as the starting point of integration mapping efforts. The mapped-to destinations will often coincide, but the source of data and the processes to get to that destination will vary. Therefore, integration and migration processes should be conceived and developed as separate functionality.
The most satisfying part of the data expert’s work is seeing the populated data entities’ data joined with the work of the application developers – representing the visualization of the client’s expectations on screen. Once data is merged with forms, reports, and dashboards of the application, and then viewed by the customer through the eyes of the D365 toolset, the connections of the functional and the technical requirements are seen. his is also the opportunity to fine tune the components of the solution. Fine tuning allows our team to deliver the solution originally envisioned, prepare the solution and the client for user acceptance testing, and ultimately deploy the data migration and integration components as integral components of the overall D365 solution to the client’s production environment.
We hope this gives you a view into what being a data expert is like! We’re always looking for great talent at PowerObjects, check out open roles and apply on our website here.
Happy Dynamics 365’ing!
Расскажите о новых и интересных блогах по Microsoft Dynamics, напишите личное сообщение администратору.
|powerobjects: Visualizing Data in Dynamics 365||Blog bot||Dynamics CRM: Blogs||0||03.01.2018 05:45|
|powerobjects: Configuring the Dynamics 365 App for Outlook||Blog bot||Dynamics CRM: Blogs||0||08.11.2017 01:12|
|NAV Team: How to: Set up your Microsoft Dynamics NAV installation for Single Sign-on with Office 365 using Windows PowerShell||Blog bot||Dynamics CRM: Blogs||0||19.12.2013 15:10|
|crminthefield: Podcast and Overview: Microsoft Dynamics CRM 2011 Update Rollup 14||Blog bot||Dynamics CRM: Blogs||0||12.07.2013 07:13|
|german_nav_developer: Buildnummern-Übersicht Microsoft Dynamics NAV 2009 SP1||Blog bot||Dynamics CRM: Blogs||0||11.06.2010 16:33|
|Опции темы||Поиск в этой теме|