Skip to main content
Version: 10.3.2

Data Analyst's checklist

Checklists are helpful as quality control techniques for documenting requirements. They can include a standard set of quality elements to capture the requirements. The purpose of a checklist is to ensure that items defined by the organization or the project team are essential and included in the final requirements or that issues determined by the project team are addressed.

The Data Analyst's checklist can include:

  • Current manual process details:

    • High-level process scheme or brief description

    • Process triggers

    • Process pain points

    • Process metrics (volumes at a unit of time, time to process one record, number of STP records, number of people involved, and so on)

    • Process input and output

      The Data Analyst needs the information on the current manual process to understand the entire automation workflow and clearly identify automation benefits for the client. You should analyze a manual process in comparison to the future process with a clear statement of what and how to modify in a future process. If needed, communicate the changes to the client Ops team and educate them on the future process.

  • Data specification:

    • Business type(s) or classes, how a class is defined

    • Document formats (email body, PDF, images, excel, word, and % of each format)

    • Language of the documents (one language, multilingual, bilingual documents, and so on)

    • Processing volumes per each type (at a unit of time)

    • Variability (how many clients send documents, top clients, and their % in the volume)

    • Business rules (keywords to identify the class, rule-based or system-based logic, and so on)

      This initial analysis of the input data helps the Data Analyst to understand the input data and its complexity, identify the project scope on a high level, and the effort to build ML models depending on the number of classes identified and their variability. Then, the analysis should be more precise for information extraction regarding document quality and fields.

  • Quality level:

    • Document structure (table or non-table format, if it is a standard or non-standard table, if there are any checkboxes that influence extraction, and so on)

    • Document quality (if there are blurred documents or documents contain misprints, vertical or horizontal lines, recognition while scanning is low, and so on)

    • Handwritten text (% of handwritten text and if there are handwritten fields to be extracted)

      It is critical to check document quality because low-quality documents can affect success criteria and increase implementation time. It is necessary to adjust success criteria or add a note in BRD that these documents can be below the required criteria due to their complexity.

  • Fields details:

    • Samples of all fields

    • Line items (if there are any, how many of them, and any interrelation between them)

    • Required and optional fields

    • Field mapping in the end system (define if field values are not the same as stated in the documents and depend on the criteria not specified in the documents)

    • Reference data (if any field has historical data or a dictionary that can be utilized)

      During the field analysis, the Data Analysts need to make sure they can clearly identify each field and find it in the documents. Fields should be analyzed in terms of complexity for model extraction: particularly if the field is well-defined and unambiguous if it is not a rare field, and if there are enough samples of the documents to train a model. Then, if there is any interrelation between fields that the model cannot capture. For example, there are always two options for the field provided in the document: regular price and price with a discount. The actual price to select (with or without discount) is identified by a checkbox or handwritten mark, and so on.

      You should document corner cases with assumptions listed where applicable. Success criteria should be stated with the caveat for corner cases. If they cannot be addressed and where possible, corner cases should be descoped, which should also be clearly stated in the documentation.

      Additionally, the Data Analyst determines how documents will be received for model training and in the future process, if document classes for classification are provided as input or if documents should be identified inside WorkFusion, split, and so on.

  • Metrics:

    • Expected rates of Precision and Recall per field and document type

    • % of STP records expected

    • SLA for each document type (client), if applicable

    • Average time to process one document end-to-end manually

    • Expected time to process one document end-to-end in the automated flow

    • Expected time to review documents manually in the automated flow

    • Daily and monthly processing volumes and periods of peak processing volumes

    • Any increase in volumes expected

    • Throughput (how many documents should go from the beginning to the end within the limited period)

      Metrics play a significant role at the UAT stage when the finalized process is delivered to the client, and it is necessary to measure its effectiveness. Not all the metrics mentioned above are used simultaneously, but they should be analyzed and might influence the final success of the project.

  • Additional business information:

    • What benefits from automation are expected by the client, and how quickly?
    • Are there any automation side effects that the client can receive (reduction in data entry mistakes, increased volumes processing with the capacity of the same team, and so on)?
    • What are the most critical business and technical mistakes? What mistakes need to be avoided in the future solution?