Warehouse & Logistics
Case Study

Applications Built & Deployed

• Billing – a robust application that connects invoicing to quotes for ease of billing
• Freight Integration – API integration application that connect two servers together – IoT
• Sales – to capture all sales activity
• Delivery – an application used by the drivers to mark deliveries completed and get electronic signatures (similar to UPS)
• Probills and Manifests – used by transportation industry to move goods, also sending customer emails of invoices and related documents.
• Warehousing – inventory capture information
• Reports – all management reporting
• Customer & Quote – tracking customer information and related quotes
• HR & Payroll – simple information capture for resources, used to feed vendor payroll systems
• Fleet – capturing all fleet information
• Customer – embedded in Sokil website so customers can self-serve. See delivery information, retrieve POD documents, invoices and statements.
• Telematics – captures all the data recorded from GeoTab relays – engine data, trip data, driver safety data
• Fuel – since fuel is a large part of a transportation expense special reporting and data capture are needed for reporting taxes
• Courier – they deliver small packages
• A/R & A/P – simple document capture
• Content Management – they store all their scanned documents in the same database, indexed to the entities they correspond to.

Development Process

Kim started by building out a manifesting system and a fuel management system, as these were a couple of systems that were in the most need of replacement from the previous application suite. This went well, and went into production, which provided a great deal of confidence. In early 2016 she committed to a path of full conversion to an AppSynergy-based solution by spring of 2019 when IBM said they would no longer support their legacy AS/400. She is well on track having built the applications listed as of late 2018.

Sokil's systems run on a single database consisting of fewer than 100 tables. There is a very small amount of code for business logic (a few exception routines, triggers and notifications coded as PSMs). She is very intentionally avoiding writing code as much as possible, partly for maintainability and partly to help those to whom she will eventually turn over the care and feeding of the system.

Maintainability

Her AppSynergy applications have all the attributes that are far too often missing in deployments of this type, including ease of understanding and ease of change. I asked about the effort to make a routine change and a difficult change.

By routine change we agreed that something like adding a field to the database, getting that on a form and providing formatting and validation would be a routine change. She said the routine changes typically take an hour or two, and she can slip them into production with no downtime. (The platform is built such that these changes do not require shutting the system down, and she has enough experience with the system to know which changes will not be disruptive.)

An example of a larger change would be something like adding a fuel surcharge feature, which might affect several modules, as it would have to be set up, maintained and carried all the way through invoice calculation and reporting. The larger changes she said typically take 2-3 days.

Team Size

All this functionality was built by Kim herself over the course of a few years. Most would agree that traditional development would have required a medium sized team on each of the more than a dozen modules she has implemented over nearly that same time frame.

Background

The Sokil Group consists of six companies that provide transportation and logistics across Canada. It is a family run company first incorporated in 1951. They have three primary locations across Canada, 200 employees, and almost as many trucks. They haul any type of cargo except liquids, such as petroleum.

Kim Sokil, a granddaughter of founder John Sokil, is the third generation of family to manage the firm. Kim has spent her entire career in IT. In the early part of her career she worked at Sokil for a few stints, but then went off to a career that included Telecom, Medical systems, Government Agencies and IT consulting. Over the years she had implemented many ERP and other packaged applications. She returned to Sokil in 2015 only to find a system that she had helped implement in 1992 was still alive and kicking, but arguably past end of life. That platform was an IBM AS/400 system originally based on a package but highly modified. In the intervening 20+ years the hardware had been upgraded once, but IBM had informed them that it would no longer be supported.

The Evaluation Process

Kim's first priority was to move functionality off their legacy AS/400 system. One of her first decisions, that is shared a lot these days, was to get out of the business of managing computer hardware and move the system to the cloud. It was her second decision that is the focus of this case study. Kim decided she was not buying a package. This is still a minority decision, especially for a small to medium sized business. I asked her why. She told me in her consulting career she had worked on a great many package implementations. In her experience, most didn't deliver the functionality that the client needed. They rarely completed on time and were poor value for money. The base packages that most firms started with were rarely even close to the functionality needed. Further, she said once you commit to a package the vendor will provide upgrades which are often disruptive, and if in the inevitable case that you have modified the package, no longer forward compatible. She knew enough to know what she didn't want.

She set out on a quest to find a platform or an environment or a set of tools where she could build and maintain the functionality they needed. Over the next 6 months she engaged in over a dozen trial implementations. She would bring a product in house, build a representative part of a solution and explore how easy was it to build screens, reports, validation and the like. Most were not up to her expectations.

Then she tried a product called AppSynergy (then ParaSQL). The AppSynergy system is a model driven, data-centric low code environment that runs on top of an advanced federated database that abstracts out the majority of integration complexity. While that wasn't what Kim was looking for specifically, she recognized its capability when she tried it out.