☰ Menu
Need Tech Support?

Grooper and the Oklahoma Department of Transportation

Taking the Oklahoma Department of Transportation

From Paper to Digital

Grooper’s Million Record Debut


When you’re a state department of transportation with paperwork spread from the panhandle to the tristate region with hundreds of employees needingok_map access to these unique documents, you need a viable, cost-effective way to consolidate, preserve, classify and retrieve the information contained on these documents in order to operate.

That was the situation facing the Oklahoma Department of Transportation on their monumental conversion project.

The Oklahoma Department of Transportation (ODOT) needed to protect and recover information from documents they had that were stored in various locations across the Sooner State.

Many of the records were considered “at risk” because they were the only copies of what ODOT defined as mission critical documents.

The loss or destruction of any of these documents would mean the permanent loss of vital information crucial to ODOT and its mission.


AJ.Records.SvsAs an example, ODOT maintains a set of records known as “as-built construction plans” that contain notations about changes made to plans during the actual construction phase of a project, including vital structural footnotes.

Contained on these “living documents” are notations that aren’t found anywhere else and they were an important part of the records preservation project.

These notations are critical in designing and building future projects undertaken by the department.

Losing one of these documents would cause ODOT to incur major expenses, delays and require substantial manpower to perform new surveys and inspections.

Many of the documents ODOT had were on the verge of being unusable due the environmental conditions where they were being housed.

Several records had mold or water damage while others had tattered and frayed edges.


Logistics played a huge factor in the ODOT conversion project.

Documents were housed in various locations based either on which ODOT Division created the plan or the location nearest where the project actually occurred.

Housing documents in this manner was hugely inefficient and required anyone needing access to specific documents to travel to the location where they were stored.

As a result, the state was incurring additional expenses in the way of travel, time delays and if they were able, in copying, and mailing or faxing plans.

As a side note, many of ODOT’s plan sets were 24” x 36” and the Field Divisions had no way to copy these large-format plans, making mail or travel the only option if someone needed access.


Converting large format paper to electronic records for digital storage isn’t a new concept.

However, the notion of intelligently – and efficiently – capturing data from documents for indexing values (in order to properly classify and/or catalog the documents so they can be later located and retrieved) has been a common stumbling block in similar projects.  

Indexing is as vital a part of the quality control process as image quality. If an image is incorrectly indexed, it is essentially lost forever.

The primary Index Value in the ODOT project was based on what is called a Job-Piece number. This number is a sequential number tied to a database of values about the project from its time of inception.

These values include such things as financial information, location information, project type or contractor, just to name a few. In fact, more than 200 fields are input as these projects are initially set-up.


The typical format for ODOT’s Job-Piece number is a five digit number, followed by two additional numbers in parenthesis – 00000(00). The first five numbers specify the job while the two in parenthesis are the piece.

However, ODOT does not always complete the entire “five plus two” template when notating Job-Piece numbers.

For example, a Job-Piece number that should read 00123(04) could appear as 123(4) or 123 (04); a Job-Piece number that should read 12345(06) could appear as 12345(6).

A key challenge to ensure the highest quality indexing was having the ability to recognize the Job-Piece pattern in its many deviations.

Another factor affecting the quality of indexing the ODOT project was the fact that ODOT had a separate, additional project numbering system based on funding categories, location, type of project and number of projects in a specified area.  

A typical ODOT Funding Code might read F-123(14) or even as 123(14), strikingly similar to the Job-Piece number and adding a level of complexity to properly indexing the documents.

The only way to differentiate between a Job-Piece number and Funding Code is by taking the location of the number into consideration and the information adjacent to it on the document.


Prior to 1976, ODOT projects did not have a Job-Piece number. For these jobs, ODOT required that several other index values be captured for identification purposes.

These were the project number, county name, highway number, project description, control section number and date submitted.

These fields are usually found on the title sheet of the as-built construction sets. However, the location and order of these fields varies greatly across the document collection.


GrooperRobot_1452x956-1024x812When ODOT met with BIS to discuss this conversion project, BIS was well into the development of Grooper, a new information processing and content management platform developed from scratch.

Grooper sprang to life based on customer feedback over BIS’ 30 years of document conversion experience and brought with it many revolutionary features.

BIS had been field testing Grooper in its Records Services Bureau to ensure the software would perform to its full potential. Grooper was designed to improve the way they world converts data and subsequently manages content from documents and data.

Grooper literally gives organizations access to the information contained inside documents like no other platform can.

This means it improves workflow, and saves time and money, especially on massive conversion projects like the ODOT one.

Because Grooper uses modern-day technologies to address the many complex and important issues surrounding back office conversion projects, it was the platform chosen for the ODOT project.


With very little customization Grooper:BIS.Warehouse


It’s no secret that government agencies have limited budgets that are often stressed.

BIS delivered a set of business and financial benefits to ODOT by carefully scoping the project and taking the time understand the complex issues it facing this conversion project.

Learn more about the world’s only information processing platform, Grooper, here.


Bis @BIS_tweets