Level 12

In this project we inspect power generation windmills with drones. We are responsible for the software that launches the drones, pulls the data off the drones, and then sends that to Microsoft Azure where we spin up huge GPU instances to process the images through a machine learning model that can identify blade defects. That all then gets automatically added to a graphical interface for the client to interface with that shows them the severity of the damage, which blade, etc. so they can schedule repairs.

In this project we provided CTO as a Service to help guilde the overall develpoment direction of the Red E App SaaS product, as well as some developer support. Our high level guidance and software development expertise helped Red E App scale up their platform as well as accelerate the internal development lifecycle.

With many years invested in a legacy analytics tool that was no longer supported, our client needed to find a replacement that would allow their business users to continue to analyze and evaluate Key Performance Indicators (KPIs) and to pull reports for organizational activities and data.

The legacy application included approximately 20 business “views” that needed to be converted for use in the new tool.  As their business continued to grow and change, there would be the need to add new data and views, so flexibility and adaptability were important.

The tool itself would need to:

• Provide high level summaries, multiple types of visualizations, and also be able to drill down into the details.
• Be web-based so that access to the tool was not hindered by location or worksite.
• Have a very flexible permission system that would accommodate our customer’s multi-level multi-site management structure without making sensitive data available to the wrong people.
• Be very user friendly for non-technical business users. Pushing important data deeper into their organization would be a big win for our customer.
• It needed to remain flexible and powerful for more advanced users and business analysts.

We worked with our client to research potential options and chose to implement Pentaho as the solution.  We were responsible for installing and customizing the Pentaho application to meet their business needs.  This included configuring the application to connect to Microsoft Active Directory for authentication as well as writing custom Java plugins for Pentaho in order to incorporate row level filtering for data access.

We designed and built a data warehouse and developed numerous (ETL) processes to organize and move data from their operations database into the data warehouse. We built an ETL framework that shared libraries with the operations database to cut down on development time and prevent errors caused by the ETL data models and operations data models getting out of sync.  Most of the ETL pipeline and data cube configurations are covered by automated tests.  Those tests help us catch errors early in the development process and give us confidence that the data these systems are providing to our users is correct.

As we converted each data view from the old tool to Pentaho, we worked with our customer to make sure the data that was being provided by the view was still relevant and accurate.  Due to this attention to the current & real needs of our customer, their BI landscape changed considerably, for the better.

Today our customer uses Pentaho for most of their business intelligence needs.  We have setup almost 50 different data cubes for their use. Those cubes cover a wide range of domains inside the organization including:

Operations

• Asset meter readings & utilization
• Asset Maintenance
• Customer Management
• Operational Efficiency
• Fuel Tracking
• Load Tracking
• Labor Efficiency
• Revenue Validation
• Safety
• Service Quality

Financial

• Asset Tracking
• Sales & Revenue
• P&L
• Vendor audits

Human Resources

• Staffing Goals
• Retention

A Fortune 500 leader in banking and payment technologies needed to streamline the process involved in onboarding new merchant accounts.

This process needed to be improved for both their internal operations team as well as the internal and external sales teams who were submitting the applications.

Having already built a platform for processing residuals for this customer, they asked us to work with them to add on to that platform a portal that would:

1. Notify the sales agent and/or team when an update to the merchant application was available.
2. Provide the sales agent and/or team with reporting and statuses for each merchant application submitted.

An interesting twist on this project was that all the data for this system would eventually come from a different application workflow system that was being built by another vendor.  Unfortunately, that system would not be ready for 3-6 months and our customer needed to provide merchant application updates ASAP.  Therefore, the project was broken into two major phases:

1. As fast as possible, get the notification and reporting portal up and running so sales agents and teams could login and get updates. In order to get data into this system, a “back-end” would also be created for the ops team to be able to login and manually update application records, set statuses, and leave notes.
2. When the other vendor brings the application workflow system online, our system would provide an API that the workflow system would use to update our data.  Once that link was established, we would remove the back-end code as the ops team would no longer use our system to update merchant applications.

Sales agents and teams would need to be able to receive updates by email or SMS text messages and would need to be able to choose the frequency of receipt of those messages.

Even though we already had a relatively small project specification, we followed our standard process of delivering a minimum viable product (MVP) as soon as possible.  This minimizing allowed us to deliver the most important features of the portal system within a few weeks!

When we were finished, the ops team could login into the portal to add and edit merchant applications to move them along in the onboarding process. The system ensured that users could only see and receive notifications for applications that were relevant to them or their sales team. The ops team were the only users that could modify application records, all other users of the system were read-only.  As the merchant applications were updated, we created an audit trail so that an application’s movement through the process could be visualized.

Sales teams and agents could receive email notifications immediately or by daily digest.  They could also receive SMS texts for events if desired.  Each user of the system can update their notification preferences personally.

The system was made timezone aware so that portal information and notifications were reported in the user’s home timezone.

We worked with the other vendor to define the API for the application workflow system and then built the API it into the portal.

A merchant processing company had retained us to build and maintain their residual (commission) reporting system since early 2008.

As time went on, the system was regularly expanded to handle additional calculations and logic related to the payment residuals.  Unfortunately, the way the system was originally built was not ideal for the volume and complexity of calculations that were eventually asked of it.

As the system aged and the size of data grew, the calculations began to take longer and longer and the server resources used grew larger and larger. In addition, the needs of the customer were changing. Their monthly residuals process involved manually editing the Excel reports after they were generated to handle edge cases that the residuals calculator didn’t know about or didn’t have the data to handle. This meant that the actual residuals amounts paid to the customer would vary between the file and that data in the database, leading to difficulties when trying to report on residuals.

As time progressed, our customer desired to extend their residual reporting with more complex pricing options than the original system could support. In addition to this, their residuals team was constantly stretched to complete their monthly reporting cycle due to the amount of manual intervention needed. Reducing this workload was a priority, and would require a new reporting process. The need to be able to ensure that the calculated residuals numbers were correct, as well as the reports themselves, also rose in importance.

In 2014, after years of recommending an overhaul of this system, our customer was able to allocate the funds necessary to begin working on the project. The top priorities were:

• All residuals related calculations had to happen in the system.  No more edits to the Excel reports after they were generated.
• The final residuals calculations would need to be stored in the database for easy reporting.
• Performance would need to be increased significantly.
• Feature enhancements that would make the calculation process more accurate and prevent or detect errors.
• Add non-bankcard payment products to the residuals reports.

Our solution was broken up into three main components and stages so we could use an iterative development process:

1. The residuals calculator
2. Report generation
3. Everything else

We began working with the customer to fully spec the residuals calculation process, in order to determine what calculations and types of records would need to be supported. We then began coding with a full rewrite of the data model and calculator for residual records. Tests were written at the same time for automated confirmation of the calculator’s results, to prevent changes from having unintended results or bug regressions.

When the calculator was completed and “covered” with testing, our focus shifted to the reports. Again, tests were created to ensure that each cell on each worksheet was checked for accuracy. The reports generated from the new system were compared to the reports generated by the old system, plus any manual adjustments, to verify accuracy. Any discrepancies were debugged and fixed. This proved to be an incredibly valuable process as we sometimes found that the new system was correct and the older system and/or the manual changes being applied were creating errors.

At the point that the calculator and reporting process were determined to be significantly stable, we went to work on all the additional functionality. This included:

• Modifications to make it easier to enter and report on one-off monetary adjustments
• Pricing profile UI and database cleanup
• Emailing of residuals reports
• Improved monthly finalization logic
• Exception reporting
• Audit trail for pricing: if any rate, fee, adjustment, etc. is changed by a user, the customer has a record of that change so that calculations could always be reconstructed if necessary.
• The inclusion of residuals calculations for a number of different payment products beyond credit and debit cards.

Our customer is an industry leader and top-tier provider of rail related services.

They engaged us to develop custom software to help them track the training their 1100+ employees required and completed.

Training managers would need to be able to add and group training requirements together to create and monitor qualifications. Those managers would also need to be able to monitor expiration dates for both requirements and qualifications so employees and their site managers are notified when an employee needs to renew portions of their training.

It was important that the system had the ability to upload and attach documents for the purpose of:

• Distributing training materials to managers and employees
• Uploading certifications of training completion

Due to the large number of employees, worksites, and departments in the company, automation and other labor saving features were important to the success of the project.

Finally, our customer needed to funnel this data into their business intelligence solution so they could analyze the data for compliance and trends across their 1100+ employees.

We took the initial project requirements and produced the intial production ready version in a matter of weeks.  The training managers really benefitied from our iterative development process as they made frequent changes to the system as they learned more about the software and what they really wanted it to do.  We were able to quickly respond to many change and feature requests, each time delivering an operational production version for continued use and review.

The resulting application:

• Tracks all training requirements
• Tracks qualification statuses of all employees
• Allows managers to record training
• Ability to assign training requirements either by groups or individually
• Allow employees to be exempted from some qualification requirements when necessary
• Notifies managers when employees’ qualifications are near expiration
• Manages training documents
• Managed qualification certification document requirements

Additionally, for reporting and business intelligence:

• Extract Transform Load (ETL) processes were created to move the data from the operations database to the customer’s datawarehouse.
• OLAP data cubes were created for data analsis

The Challenge

This project is for a Fortune 500 leader in banking and payment technologies.

When the leaders of their Merchant Services (credit card processing) division made plans to grow, they knew that new software systems would need to be put in place to facilitate the growth.  One of the systems that would need to be built was a residuals (commission) calculator.

The residuals calculator is responsible for taking input data from the credit card processing companies, combining that information with payee profiles, and finally calculating the income, fees, and net payout for each merchant and payee in the system.  When the customer first came to Level 12, that process was handled manually in Excel spreadsheets.  But, they knew that process would not scale and a fully automated system would need to be created.  In addition, they wanted their customers (the payees) to be automatically notified by email when residuals reports were ready and to be able to login to the web application to download their monthly payout statements.

In addition to the core functionality requested, the application would need to conform to a number of corporate IT policies that covered:

• the handling of Non-Public Information (NPI)
• user login and passwords policies and expiration
• encryption standards for sensitive information
• expiration of sensitive data

It would also need to have a flexible permission system to accommodate different user types and have hierarchy aware access to residuals and payee data.

The Solution

Due to our prior experience building software for the merchant services industry, we were able to jump into the project quickly and begin working on a Minimum Viable Product (MVP) of the residuals calculator system.  That MVP included:

• refining and further documenting the specification of how residuals were calculated in the then-current manual system
• automated and encrypted transfer of data files from the customer’s servers to ours
• parsing of multi-line, fixed-width record format input files (holdovers from the mainframe era)
• creation of payee profiles and related payment settings for all payees
• creation of the residuals calculator engine
• generation of payee residuals reports

After the MVP was delivered, we started to validate the system’s residuals calculations against the data that was being calculated manually in Excel.  All discrepancies were noted and fixed and this process was repeated for several months to ensure that all variations in the residuals input data were accounted for in the new calculator engine.  This iteration was necessary because our customer did not have a formal specification for how to calculate residuals.  The residuals calculation process was very ad-hoc and had been created over time.  Therefore, it took several months of running the calculator against live data to find the many edge cases.

Approximately six months into development, the calculator reached a stable state and was able to replace the manual process in use at the time for calculating residuals.  We then got to work on building out the customer facing side of the application, enhancing reporting, and implementing the rest of the features that were needed for corporate IT compliance prior to the application being made generally available.

About nine months into this project, our customer awarded us three additional projects for the following year.

The Challenge

Our client is a manufacturing company specializing in the reconditioning of industrial parts.

Their reconditioning process is broken down into two steps:

1. Part intake, evaluation, and repair estimates
2. Part repair

Once an estimate is made and repair is approved, our client uses an ERP system to track the repair through their plant.  However, the intake step was being managed with paper forms.  That proved to be very inefficient and our client did not have a good way to track parts that were on-site but not yet approved for repair.

They were looking for a software solution that would:

• make the intake process more efficient and streamlined
• ensure the data was captured electronically
• generate PDFs in place of the paper forms
• offer data validation and error checking
• set the stage for data integration with the ERP at a later date

The Solution

We worked with the client to review the paper forms and understand what steps were actually taken during the intake process.  Unsurprisingly, the actual intake process in use had outgrown what the paper forms reflected.  We then built a custom web application with a multi-page form that would do everything the paper form did and more.

Features of this application included:

• Mobile optimized for primary use by tablets in the shop area
• The intake form is dynamic and certain fields are hidden or shown depending on the part type to make filling out the necessary fields as easy as possible
• Fields that track roller measurements automatically convert standard to metric for easy reference and validation
• Common part form factor schematics are stored in the system and, when chosen, show the user which measurements need to be taken
• Multiple pictures can be taken right from the tablet’s camera and included with the form for easy reference
• Once submitted, the data is formatted, converted to a PDF, and emailed to the office
• All data is saved in a database so it will be available for additional phases of this project