Skip to main content
Version: 10.3.2

Project types

When you start a project, you first identify its type, timelines, and goals, then you can make up a plan, a strategy of data analysis, and other activities accordingly.

Typically, use cases can be delivered as Proof of Concept or Production. The scope, goals, timeline, and approaches differ for each delivery type.

Proof of Concept​

Proof of Concept (POC) projects are usually delivered to new clients to demonstrate product capabilities and prove some assumptions:

  • The end value is sufficient to warrant the effort and investment in the project.
  • A chosen plan of workflow is correct.
  • A solution is technically feasible.
  • A proposed solution matches expectations.
  • Limitations for the solution are known and accepted.

POC projects explore and validate how well a particular business problem can be solved by AI and with the help of the Work.AI platform capabilities.

POC helps a company to verify the solution without investing too much time and resources. A company can find out whether it already has the data needed for AI, bottlenecks of processes, technical limitations, and overall readiness for automation.

POC can become the first step of a change management process that does not generate immediate value but can also cause long-term value. With its help, the business gets an opportunity to know how to build processes effectively, structure them, or collect data and receive positive side effects of these changes.

POC often takes place in a competitive atmosphere when a client considers different options and vendors for automation. The aim of a POC project is a quick win in addressing customers' needs, building trust in the proposed solution for automation, and leading customers in their automation journey. POC projects usually have the following features:

  • Short timelines: 4-8 weeks to deliver a quick solution and demo the value that can be added by the WorkFusion products.
  • Complexity level: a solution is concentrated on the straightforward business flow with no complex business rules and a minimum integration with third-party systems.
  • Scope: the list of fields is limited to key values, the scope of documents is reduced to key vendors, and complex cases and templates are excluded.
  • Development: SMEs often are not involved in tagging as it is a Data Analyst's responsibility. A project can have only one iteration of model training and limited model tuning.
  • Input and output data: data delivery can be manual, for example, in the spreadsheet format, when in production solution connection to third-party systems is required to obtain or deliver data.
  • Success criteria and user acceptance can include:
    • 90% accuracy and 60-70% automation rate
    • Testing business process throughput with a defined number of records (~1,000)
    • Statistics of the amount of manual time, total elapsed time, and cost required to process an average record through the WorkFusion Business Process
    • Manual processing time reduction per record, for example, less than 1 minute 34 seconds (30% reduction)

A POC project is a regular project but at a smaller scale. It doesn't deliver complex automation solutions because it is not a priority for such projects. For POC, it is worth planning and discussing with a client future improvements for an ML model, the process in general, workarounds for corner cases, and exception-handling processes. There is no need to invest much time and effort in building workarounds for some exceptions or tuning OCR for a particular template. Instead, it is recommended to negotiate them with a client, descope for the current implementation, and gather more details to plan the handling of these cases in production.

The main aim is to deliver a sufficient result as soon as possible, collect the requirements, and prepare reusable artifacts for future process scaling.

Production​

Once you successfully implement a POC project and an overall win to build trust with the business in your solution, you can move forward to scale the project, and create a production solution. Usually, the difference between POC and Production use cases is that a proof of concept is just a concept. It is not a production workhorse that can cover a full workflow scope, handle exceptions, and adhere to the best practices and established patterns. POC is a tool to convey an idea in a short amount of time when the technology brings value to the business.

Compared to POC where the development complexity is usually low, Production brings a solution that should cover a complex business logic, increased scope (for example, all the vendors compared to top vendors in POC), processing of complex or additional data formats and templates, integration with third-party systems, and complex exception handling.

Exception handling is especially critical in Production use cases. The Data Analyst is responsible for figuring out all potential exceptions scenarios so that they are included in the solution and will not require additional workarounds when delivered.

Production projects can have the following features:

  • Longer timelines: from 12 weeks to 18 months depending on the scope.
  • Complexity level: a solution should cover not only a happy path but also all potential exceptions and complex business rules.
  • Scope: can include multiple document types, a combination of Classification and Information Extraction, and a large variety of documents to process.
  • Development: can have additional phases of SMEs' training and enablement. Data tagging and model training can have multiple iterations. Model enhancements can include heavy customization and enrichment with features.
  • Input and output data: a connection to more than one third-party system to obtain or deliver data is a frequent case.
  • Success criteria and user acceptance can include the same metrics as for POC and additional ones or a combination of them.

In successful Production implementations, clients also receive side effects of automation:

  • Increase of volumes that can be handled by the same team
  • Release of a team for more expertise demanding tasks and exception handling
  • Time savings on data entry
  • Transparency in tasks in the queue, quicker pickup, and handling
  • Decrease in costs due to a human mistake
  • SLA improvements

Thus, there are different aims in POC and Production projects, and your team should select different strategies to address them. For POC, the speed of delivery is in focus, and it usually allows to skip certain business flows. At the same time, Production requires code to be polished, all cases considered, and best practices integrated into the solution.